Skip to main content
This page describes how solutions in the Atoti Enterprise Risk Suite are distributed, how they are structured internally, and how they can be customized.

​
How are solutions distributed?

Solutions are distributed as Maven libraries, not as standalone applications. Each cube provides a Spring Boot starter (for example var-cube-starter or pfe-cube-starter) that auto-configures everything needed to run that solution. To use a cube, add its starter as a Maven dependency to an existing Atoti Spring Boot application. This automatically enables the cube and pulls in the required Atoti Server dependencies. See the setup guide for each solution for dependency coordinates.

​
How to add a solution to a project

The simplest way is to add the solution’s starter as a Maven dependency. This auto-configures the cube, dimensions, measures, and data loading with sensible defaults. For more advanced use cases, solutions also expose finer-grained modules:

​
What is the public API?

Only classes in .api. packages are part of the public API and are stable across releases. Classes in .internal. or .private_ packages must not be referenced, as they are implementation details that may change without notice.

​
What is the ISolutionCube pattern?

Every cube in an Atoti Enterprise Risk solution exposes an ISolutionCube<T, L, M, P> interface as a Spring bean. This interface provides type-safe access to:
  • name(): the cube name as a string
  • databaseModel(): the tables and joins of the cube, typed as T
  • levels(): dimension level identifiers, typed as L
  • measures(): measure collections, typed as M
  • aggregateProviders(): the names of the partial aggregate providers the solution adds, typed as P
For example, the VaR cube in Market Risk (Enterprise Risk) exposes IVaRCube, which gives access to IVaRCubeLevels and IVaRCubeMeasures. Inject this bean to access cube components programmatically without hardcoding string identifiers.

​
How are solutions customized?

Solutions support two customization mechanisms.

​
Configuration properties

Spring Boot properties control the runtime behavior of each solution. Properties cover feature flags, display currencies, confidence levels, scenario counts, and other runtime settings. Properties that apply to common data model are nested under atoti.solution.model.*. Cube-specific properties are nested under atoti.solution.model.cubes.<cube-name>.*. See the configuration properties reference for each solution for the full list of available properties.

​
IModelConfigurer

For customizations beyond what properties offer, implement the IModelConfigurer interface in the consuming application. The solution archetype generates a ModelConfigurer class ready for this purpose, described in How to customize the application. This is the Atoti Configuration API entry point for structural changes:
  • Adding fields to existing tables or creating new tables
  • Adding custom dimensions and hierarchies
  • Adding custom measures
  • Adding new cubes
For the underlying API, see the Atoti Configuration API reference for database configuration and cube configuration. See the developer guide for examples:

​
How do shared tables work?

Common table creation is idempotent: if a table already exists at startup, the existing instance is reused rather than recreated. This allows multiple solutions to start up without conflicting over shared tables. Each solution adds its own fields to the shared tables. Customizations are strictly additive: no solution removes or modifies fields added by another, so different solutions can extend the same table without conflicting. Cross-cutting concerns that span tables, joins, and dimensions (such as the Counterparties feature) are encapsulated in feature implementations. Feature flags in the configuration properties control which features are active.