Adding a Field

This page provides a description of how to add new fields to a Atoti CVA Risk Capital project. It features an example in which a ‘TestField’ is added to Atoti CVA Risk Capital. It also explores additional steps needed for adding data to stores that are populated through a custom publisher. The techniques employed are generic examples that can be extended, adapted, and repeated for any use case.

Editing the Data

This example shows modifying files currently populating the Vega store (files which match a naming scheme of sa-cva-cva-vega-sensitivities.csv), by adding a column to them. In this case, the new column’s header is ‘TestField’. Here’s an example of the contents of one such file. (This new column was added to all files matching such naming scheme):

AsOfDate NettingSetId RiskClass RiskFactorId Sensitivity SensitivityCcy ReferenceName ExplicitBucket BucketSuffix TestField
2018-12-05 ActiveBank EU_10 commodity whey_Implied volatility -12352.9 EUR whey Data1
2018-12-05 ActiveBank EU_101 interest rate CHF.IBOR3M_Implied volatility 7896.9 EUR CHF.IBOR3M Data2
2018-12-05 ActiveBank EU_12 foreign exchange CAD_ATM Implied volatility 5068.05 EUR CAD Data3
2018-12-05 ActiveBank EU_12 interest rate CHF.IBOR3M_Implied volatility 4782.93 EUR CHF.IBOR3M Data4
2018-12-05 ActiveBank EU_12 commodity wheat_Implied volatility 32805.05 EUR wheat Data5

Step 1 - Define datastore field via the customisations config

Before you can load this new column into the cube, your datastore needs a field that can accept it. To add a new field to an existing store, edit the addModifications() method in DatastoreCustomisationsConfig at cvarc-application/src/main/java/com/activeviam/cvarc/application/cfg/DatastoreCustomisationsConfig.java. This class lives in your project’s cvarc-application module and is intended to be edited directly.

@Override
public void addModifications(IDatastoreConfigurator configurator) {
    // Append "Vega" store with a new field "TestField" of type STRING
    configurator.appendField("Vega", new CustomField("TestField", ILiteralType.STRING));
}

Step 2 - Add the column to the topic’s parser

Extend the relevant *SourceDescription class to add the new column to the topic’s parser column list. Place the extension in cvarc-application/src/main/java/com/activeviam/cvarc/application/cfg/extensions/.

Because CsvTopicDescription is an immutable record, the override needs to rebuild the topic’s parser with the extra column. Use .toBuilder() to inherit the parent topic’s channel and file pattern, then call .parser(...) to replace just the parser.

package com.activeviam.cvarc.application.cfg.extensions;

import com.activeviam.cvarc.starter.cfg.impl.dlc.SASourceDescription;
import com.activeviam.io.dlc.impl.description.topic.CsvTopicDescription;
import com.activeviam.io.dlc.impl.description.topic.parser.CsvParserDescription;
import com.activeviam.io.dlc.impl.utils.NamedEntityResolverService;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.context.annotation.Primary;
import org.springframework.core.env.Environment;

import java.util.ArrayList;
import java.util.List;

@Configuration
@Primary
public class ExtendedSASourceDescription extends SASourceDescription {

    @Bean
    @Override
    public CsvTopicDescription cvaVegaTopic(
            NamedEntityResolverService namedEntityResolver,
            Environment env) {
        CsvTopicDescription base = super.cvaVegaTopic(namedEntityResolver, env);
        List<String> columns = new ArrayList<>(base.parser().columns());
        columns.add("TestField");
        return base.toBuilder()
                .parser(CsvParserDescription.builder().columns(columns).build())
                .build();
    }
}

The super.cvaVegaTopic(...) call inherits the parent topic; .toBuilder() produces a mutable copy; the parser is replaced with a copy that includes the additional column.

Step 3 - (Optional) Custom publishing logic

If the new column needs custom logic on the publisher side (for example, the field requires lookup or transformation before being written to the store), override the publisher target in TargetDescriptionsConfig (in cvarc-starter). Subclass it in your extensions package and override the relevant target with @Primary. Mirror the existing publishers in TargetDescriptionsConfig.java as templates.

If your field is a plain pass-through — the publisher just writes the parsed value into the matching store field — no override is needed; the DLC framework will route the column to the matching store field automatically.

Step 4 - Wire the extension into ApplicationConfig

Add ExtendedSASourceDescription (and any extended TargetDescriptionsConfig subclass from Step 3) to the @Import list of ApplicationConfig in cvarc-application/src/main/java/com/activeviam/cvarc/application/cfg/ApplicationConfig.java. The @Primary annotation makes Spring prefer your overridden beans.

To expose fields as hierarchies or measures, see the examples in Adding a Hierarchy and Adding New Cube Measures.