Model Object (MO)

Owned by Victor Noël
Last updated: Oct 24, 2024
3 min read

Model Object represents an “instance” of a Model Class. It is the thing, which is actually being used by the user in the user interface when they work with Optimization module. It keeps the input values provided by the user, it keeps the data calculated by the Steps' Calculations.

Model Object behavior is described by the Model Class. The Model Object persists data about:

  • input values from user

  • results of Model Calculations logics elements

  • tables and their records (Model Tables and Parameter Tables)

  • attachments

  • trees

For details about those persisted data see below.

Model Object Fields

  • uniqueName* – Name of the Model Object, used in other parts of the application to reference a Model Object when using api.model(String). It can be modified but the references will not be updated automatically.

  • label – Human readable name of the Model Class, displayed to the user.

  • modelClassUN* – Unique name of the Model Class describing what the Model Object will look like and how it will behave. User groups defined in the Model Class as well as the Model Class’s Module Category will be applied to the Model Object, see Module Category > Access Rights - Roles and User Groups.

  • state – JSON representation of all the inputs that were saved while manipulating the Model Object. This field is not to be manipulated directly by users but only by the frontend and read in logics by the special methods on the model context.

Model Object States

  • DRAFT – The model is not fully calculated.

  • CALCULATING – The model is being calculated.

  • ERROR – There was an error in the last calculation.

  • READY – The model is fully calculated and/or is submitted/approved/denied.

  • INVALID – There is something is wrong with the configuration, for example a ModelClass contains incorrect JSON or a ModelObject refers to a ModelClass that does not exist. If a user sees this state, it is best to contact the project CEs or support.

Associated Domain Objects

Model Tables

Model Table is data table of type DMTable, which is Analytics table (e.g. similar to DataSource). But they’re owned by the Model Object (their unique name is local to their Model Object), so if the user wants to see them, they must use the Tables button on the Model’s page.

Step’s Calculation logic can create the Model Table, can populate the table with data and can also query the table, in the same way, as you are querying DataSource or a DataMart.

Model Tables are deleted when their Model Object is deleted.

Parameter Tables

Model Object’s Parameter Tables work the same as Company Parameters. But they’re owned by the Model Object, so to see them and manipulate their data, the user must open the Tables button on the Model’s page. These tables inherit the “User Group (View Details)” and “User Group (Edit)” settings defined for their Model Object.

Step’s Calculation logic can create the Parameter Table, can populate the table with data and can also query the table, in the same way, as you are reading data from other Company Parameter tables.

Contrary to Model Tables (and for legacy code reasons) their unique name is always post-fixed by the MO Typed ID. Nevertheless, from the point of view of MO logic API, they are handled (created, deleted, accessed) exactly as if their name is local to its owning MO. Thus, in order to use the table with Public Groovy API methods (like findLookupTableValues()), you can retrieve the “absolute” unique name of a MO Parameter table using: model.lookupTablesContext().lookupTable("myLocalTableName").uniqueName()

Parameter Tables are deleted when their Model Object is deleted.

Attachments

Attachment can represent any binary data you need to have attached to the Model Object. Common example of attachment is a trained machine learning model stored in PMML format.

Attachments are added to a Model Object manually by used and can be used by the Step’s Calculation.

They are deleted with the Model Object.

Trees

Tree represents a tree structure with parent-child relationships. It can be used, for example, to represent a Segmentation Tree. 

Step’s Calculation logic can create a tree and populate it, and then a Tab can visualize the tree.

Tree is deleted when their Model Object is deleted.

Calculations

All the calculations executed from a Model Object will have a corresponding Job Status Tracker that:

  • Have the Model Object typed ID as the target object.

  • Have a calculation context containing the step name and the calculation name.

They are deleted with the Model Object.

Calculation Items

Parallel calculations (see Model Parallel Calculation Logic) have Parallel Calculation Items attached to their Job Status Tracker. They have the following fields:

  • jstId* – ID of the owning Job Status Tracker

  • key* – Unique key associated to the item, per jstId.

  • status* – One of CREATED, CALCULATED, FAILED

  • inputs* – A dictionary of key-value used as inputs for the calculation of the item

  • outputs – A list of Calculation Results representing the outputs of the logic executed for the calculation of the items

  • messages – A list of messages emitted by the backend during the calculation of the item

They are deleted with their Job Status Tracker and thus with the Model Object.

Found an issue in documentation? Write to us.