Adding New Cube Measures

This page provides a description of how we can add a measure. It features an example in which we use the ‘CustomProjected’ field from a store which we previously added. For a walk-through on how this store was added to the cube, see Adding New Data Loading or Unloading Topics. The techniques employed are generic examples that can be extended, adapted and repeated for any use case that we need. In all cases, we make minimal changes to the Reference Implementation.

 

Step 1 - (Optional) Modify the selection description

If the field we want to turn into a measure is not currently in our schema selection, then the first step is to add it.

The cube selection is made by retrieving all fields from a datastore except unwanted ones, so adding an extra field to an existing store will add it to the selection. Only extra datastore fields will need a change on the selection.

Fields are added to the schema selection by creating a Spring Bean with type UnaryOperator<CanUseOtherReference> and qualifier SchemaSelection_CUBENAME_ (for example, SchemaSelectionStandardisedApproachCube).

For example:

    @Qualifier("SchemaSelectionStandardisedApproachCube")
@Bean
    UnaryOperator<CanUseOtherReference> extraSchemaSelections() {
		return builder -> builder
		.usingReference(storesToPath(TRADE_BASE_STORE_NAME, "TESTSTORE"))
		.withAllFields()
		.except(AS_OF_DATE, RISK_CLASS);
		}

Step 2 - Define measure

 

In this case we need to extend the SAMeasureBuilder class for creating measures.

public class ExtendedSAMeasureBuilder implements SAMeasureBuilder {

    @Override
    public void measures(ICopperContext context) {
        return Copper.sum("CustomProjected");
		super.measures(context);
    }
}

To read more about creating measures with Copper, see Creating and publishing measures.

Step 3 - Application config

Navigate to the configuration class where the original MeasureBuilder class (SAMeasureBuilder) was being used, in this case com.activeviam.frtb.ref.cfg.applications.cubes.impl.SACubeConfigurer, and replace the old MeasureBuilder class with the newly extended one

/frtb-starter/src/main/java/com/activeviam/frtb/starter/cfg/impl/

@Configuration
@Import(value = {
...
        ExtendedSAMeasureBuilder.class,
        //      SAMeasureBuilder.class
...
})

Measure Beans

note

This is currently only supported by InternalModelApproachCube, StandardisedApproachCube and StressCalibrationCube.

Below is an example of a measure bean definition for the SA.

/frtb-starter/src/main/java/com/activeviam/frtb/starter/cfg/impl/

@Qualifier(CUSTOM_MEASURE)
@SAMeasure
protected CopperMeasure customMeasure() {
	return Copper.sum("CustomProjected");
}

When creating measure beans this way, be sure to include our configuration class which contains our beans in the application config class FRTBConfig located in /frtb-starter/src/main/java/com/activeviam/frtb/starter/cfg/impl/

When using DirectQuery

When using DirectQuery, perform the steps as listed above. There are no additional requirements. However, you must ensure that your remote database and datastore description are configured correctly. For information on how to add tables and fields to the remote database when using DirectQuery, see the dedicated section in Adding New Data Loading or Unloading Topics.

Perfomance impact of datastore lookups

Datastore lookups and GetByKey queries are not recommended when using DirectQuery. If you have data coming from a DirectQuery remote table and you need to perform frequent datastore lookups or any GetByKey queries, then it is more efficient to cache the table in an InMemory datastore store. For more information on caching tables with DirectQuery, see Caching Remote Tables.

Suggested further reading

Adding New Cube Hierarchies

Adding New KPIs