Understanding the Data Object Model (DOM)

Note:

Platform features can be extended further depending on the project requirements. For more details, please refer to Chapter Extending the Application Features.

The Data Object Model (DOM) is a set of classes that is used to handle scenario data in memory when writing complex processing. The Platform provides internal mechanisms to map this data model to the Data Service relational database and most extension points related to data processing will receive the data they need in the form of a ready-to-use generated class called Collector. The DOM is available for the Java and the Python programming language.

A collector provides the following functions:

  • Creation and deletion of an instance of a given entity,

  • Access to all instances of a given entity,

  • Access to a specific instance using its business key, and

  • Read/Save its content into/from a snapshot text file.

DOM classes are generated from the JDL Business Data Model description and can be found in the gene-model-dom and gene-model-dom-python libraries of the generated application projects.

The Platform assumes that all scenario data processing code uses a collector as input and provides a collector as output.

Typical examples include:

  • Model Checking

    • A collector containing the scenario data to be checked is received as input of the checker.

    • The checker code uses the collector API to browse through the different instances and to detect potential issues.

    • When problems are detected, the checker creates GeneIssue instances in the provided collector.

    • The collector in then saved back into the scenario data.

  • Optimization Engine Computation

    • A collector containing the scenario data to be processed is received as input of the engine.

    • The engine code uses the collector API to set up the optimization engine constraints and objectives.

    • The solution is extracted from the engine and appropriate instances are created in the provided collector to store the solution.

    • The collector in then saved back into the scenario data.

This principle allows to hide the scenario data mapping complexity and enables developing the processing features without concerns on the future context of execution:

  • Unit tests rely on collectors manually created from snapshot files.

  • Deployed code rely on collectors automatically created by the Platform in the backend/worker task contexts.