Skip to main content
The drill-down functionality is partially handled on the server side since the 1.2.0 release of Atoti FRTB. It can be configured using the corresponding configuration file: drillInConfig.json, located in the frtb-application/src/main/resources directory. This section contains an explanation of the structure of the new configuration file and provides a detailed example.

How it works

A drill-down has two configuration layers, owned by different sides:
  • The client-side config decides whether the drill-down menu item appears for a given cell (based on the cell’s measure name and the table layout).
  • The server-side config decides what the drill-down returns (which measures and which hierarchies on rows) once the menu item is clicked.
End-to-end sequence:
  1. The user right-clicks a cell. The UI evaluates its drilldownOperations rules against the cell to decide which drill-down menu items to display.
  2. When the user selects an item, the UI sends the cell’s column key (and a drillInType discriminator if the rule specifies one) to the server endpoint GET /drillin/rest/mdx/drillinmdx.
  3. The server matches the measure name against the entries in drillInConfig.json and returns a JSON DTO describing the target measures and the hierarchies to put on rows.
  4. The UI generates the new MDX from the DTO and opens a new dashboard page with the result.

Client Side

The client-side rules live in the UI SDK, in frtbSettings.drilldownOperations (see FRTBSettings.ts in packages/frtb-sdk). Each rule is a DrillDownOperationSetting object — refer to UI settings → drilldownOperations for the field reference. Each cell is tested against every rule. A menu item appears only when all of these conditions hold:
  • The cell’s measure name contains at least one of the strings in measureMustContainOneOf (substring match).
  • The cell’s measure name does not contain any of the strings in measureMustNotContainAnyOf (used to exclude variants such as Euler, Pro-Rata, Incremental).
  • If isRiskClass is true/false, the current view’s row axes do/don’t include a Risk Class level. null skips this check.
  • If checkDoubleSums is true, the cell’s measure must belong to a Double Sums-aware view.
When more than one rule matches the same cell, the rule’s type field ("", "QIS", "notQIS", "riskClassTable", "notRiskClassTable") is forwarded to the server as the drillInType query parameter so the server can pick the right entry.

Server side

The drillInConfig.json configuration file consists of an array of json objects. A particular entry will have the following pattern:
drill-down entry in the config.json file
After extracting the measure name from the column key passed in from the UI, an entry is selected based on pattern matching. Assume that the measure passed in is GIRR Delta Risk Position High and the additional drillInType parameter set to QIS, so that this entry is selected.
If a drillInType parameter is not passed in, the drillInType part of the json entry is ignored.

Constructing the drill-down measure(s)

A common pattern in the drill-down measures is that, in order to construct the measure name, only a small part of the input measure name string needs to be updated. By using captured name groups, it is possible to extract specific parts of the match and update them. For the GIRR Delta Risk Position High example: Hence, the two measures in the drill-down are: GIRR Delta Risk Position, Sums and GIRR Delta Risk Position Correlations High.

Constructing the hierarchies used on the rows

In the case of the hierarchies on the rows, the risk class often appears in the name of the hierarchy. Therefore, taking advantage of the named capture groups again, wherever the string {riskClass} appears, it will be replaced by the string matched by the capture group <riskClass>. For the GIRR Delta Risk Position High example, the <riskClass> capture group matches the string GIRR. Hence, after the string manipulations, the hierarchies on the rows are: [Buckets].[GIRRBuckets].[GIRR Bucket], [Double Sums].[GIRR Delta Double Sums].[Curve].

Example without named capture groups

Named capture groups make it possible to group similar use cases (e.g. similar type of action for different risk classes). However, you can specify the drill-down functionality without using named capture groups.
drill-down example without named capture groups
The above entry will only match the measure IMCC.D2D and passes the measures [IMCC], and IMCC.D2D together with the hierarchy Risk Classes back to the UI without modifications.

Defaults

The accelerator ships with the following drill-down operations enabled out of the box. Use these tables as a starting point when extending the configuration — the menu item and the server response must both be configured for a drill-down to work end to end.

Client-side (menu items)

Defined in frtbSettings.drilldownOperations (see FRTBSettings.ts in packages/frtb-sdk).

Server-side (drill-down responses)

Defined in frtb-application/src/main/resources/drillInConfig.json. {riskClass} is the named capture group riskClass matched from the source measure name (e.g. GIRR, Equity, FX, Commodity, CSR non-Sec, CSR Sec non-CTP, CSR Sec CTP).

Extending the defaults

To add a new drill-down, both layers must be updated:
  1. Add a DrillDownOperationSetting to frtbSettings.drilldownOperations so the menu item is shown.
  2. Add a matching entry to drillInConfig.json so the server returns the target measures and hierarchies. Use named capture groups in measureNamePattern to share a single entry across risk classes; the {groupName} placeholders in onRows and drillDownTo are substituted from the named groups.
If the menu item is shown but no server entry matches the measure, the server responds with an error — the menu item must not be enabled until the server entry exists.