Getting started
This section provides guidance on developing with the Limits Module.
Provided is a minimalist ActivePivot project built with Spring Boot for you to edit, customize, and use as a base for your ActivePivot projects.
Details
This project aims to be an example of how to run the Limits Module with an ActivePivot Spring Boot application.
This project is a starting point for your own projects and implementations. You should be able to take this, customize it, and get a cube up and running in a few minutes.
📦 Installation
Requirements
- Java 11
- Maven 3
- ActivePivot (AP5.10) JAR files
- Running the application requires a license for the ActivePivot software.
Distribution
Limits backend source
To access the Limits backend source zip folder, click here.
Unzip this repository and run mvn clean install
.
This will generate a JAR file, which can be run using standard java commands.
Limits UI
- The Limits Module contains customized UI widgets
- Download the Limits Module from https://activeviam.jfrog.io/artifactory/activeviam-accelerators-artifacts/limits/0.3.0/limits-ui-0.3.0.zip
- Update public/limits-env.js
- Run
yarn install
- Run
yarn start
onhttp://localhost:3000
- Run
yarn build
for building a production-deployable package under the “build” folder.
💻 Usage
The Limits Module can be intergrated with any ActivePivot instance with the same AP version. For more information, see How to Integrate Limits to ActivePivot.
As Of Date
The file as_of_date.csv sets the asOfDate for the limits application. This asOfDate is used for evaluating limits against connected accelerators.
Limit definitions
The files limits_approve_frtb.csv and limits_approve_mra.csv load the LimitsDefinition store, and can be found in src/test/resources/data-samples/data/
. Limit
definitions which have the same Name, CubeName, and ServerName fields create a single KPI on a connected server via REST calls.
Currently limits_approve_mra.csv is being ignored because the ETL will skip un-configured accelerators. To load MRA limits, modify acc.url.map prop
in src/main/resources/properties/limits.properties
to include MRA. (
Example: {'MRA': 'http://localhost:10010/risk-activepivot/pivot/rest/v5/cube', 'FRTB': 'http://localhost:8080/frtb-starter/pivot/rest/v5/cube'}
)
AlertTasks and Alert Definitions store
AlertTasks are created for each limit definition in the LimitsDefinition store, which evaluates whether a limit is in breach or warning state. The
PollingFrequency field of a limit definition determines how often an AlertTask is run. When limits are in breach or warning status the AlertTask writes to a file named alert.csv. You can find this file in today’s date folder inside the directory src/test/resources/data-damples/data/alert
. The files generated here will populate the AlertsDefinition store via a listening topic.
Limit definition Scope matching
A Limit Scope is a list of Level Name to Level Member pairs. Each Level Name/Level Member pair defines where a Limit applies to. For example, for a Limit to apply when “Trade1” is expressed for the “Trade” dimension, the Value/Pair “Trade=Trade1” can be defined in the Limit Scope. The Scope can consist of many Level Name/Level Member pairs separated by a Pipe ("|") for CSV input files.
A Scope can only be defined once for each Level of the Cube. To define a Limit for multiple Level Members of one Cube Level, you need to define multiple Limit Definitions, each with a different Level Member value in the scope.
A Scope can consist of both explicit and wildcard Scopes.
Explicit Scopes
An explicit Scope value is one where the Cube Level and Level Member are explicitly defined. For example: “TradeLevel=MyTrade1”.
Wildcard Scopes
A Scope’s Level Value can also be applied to all Level Members of a given Cube Level. This is done by specifying a Scope where the Cube Level Member is a ("*") wildcard. This will match all Members of the given Cube Level.
Parent Child Scopes
A Parent-Child scope is a scope defined on Parent-Child hierarchy, which is a multi-level hierarchy where a parent/child relationship exists between the hierarchy’s levels. For example, the BookHierarchy, in FRTB, hierarchy consists of levels Level 1, Level 2, Level 3,…, Level 15 and each level has a parent/child relationship with the next level (Level 1 is a parent to Level 2, etc.).
In order to create valid Parent-Child scope’s via initial CSV loading, the property parent-child.levels
must be set, declaring all Parent-Child scopes to be processed. The format of the property value is: parent-child.levels=FRTB@StandardisedApproachCube=BookHierarchy@Organization
Limit lookup
Because this can potentially cause multiple Limit Definitions to be applied to any location in the cube, Limit definition collisions are resolved by the following logic:
We take the Limit Definition that has:
- A higher Precedence
- Matches a location with more explicit scope matches.
- Matches a location with more wildcard scope matches.
- Has a lesser value.
Limit workflow
In the resources/processes folder, there are three Activiti workflow bpmn files out of box.
- limit-process-definition.bpmn
- limit-process-four-eyes.bpmn
- limit-process-simple.bpmn
Other
If running as a JAR file, the limits_approve.csv file may not be found, and you will need to explicitly point to it.
- ActiveUI, ActiveViam’s user interface for exploring the cube, will be available from
http://localhost:9090/ui
The default security credentials are admin:admin
, but can be modified in the SecurityConfig
class (we use Spring Security).