__Model Logics

In a Model Class, two types of logics can be used: evaluation logics and calculations logics.

Evaluation Logics

Evaluation logics are used in tabs and configurators, they are always used in a given step and a given tab, as declared in the Model Class.

They can do anything read only related to the Model Object where they are executed, including accessing previous steps inputs, previous calculations outputs, querying Model Tables, reading attachments, etc., via the model binding.

Those logics are made to be evaluated synchronously when the user interacts with the UI, their results are never persisted but their inputs are saved with the model. To ensure that this synchronous experience is always smooth and reactive for the user : a good practice is to set the elementTimeout property of all the logic elements to 0.

Evaluation Logic API

Logic Nature: model_evaluation
Execution Types
- Syntax Check
  - For normal logics – Defines the input fields for the tab.
  - For configurator logics – Not used.
- Standard
  - For normal logics – Calculates the results (e.g., charts) based on the inputs, previous steps inputs and previous calculations outputs.
  - For configurator logics – Builds the input fields based on the inputs, previous steps inputs and previous calculations outputs.
Information provided to the logic:
- In the Syntax Check and Standard modes:
  - model in the logic context, including Model table, inputs from previous steps and outputs from previous calculations.
- In the Standard mode:
  - Values of all inputs provided by the user via api.input
- See also the https://developer.pricefx.eu/pricefx-api/groovy/develop/net/pricefx/formulaengine/optimization/ModelEvaluationFormulaContext.html interface and its methods.
Expected logic execution outcome:
- For normal logics – Any type of results that can be shown to the user, e.g., data, charts, data tables
- For configurator logics – Configurator entries

Calculation Logics

Calculation logics are used in model calculations, they are always used in a given step as declared in the Model Class and executed at the beginning of the step, that is before any of the tabs of the same step could be evaluated.

They can do anything read and write related to the Model Object where they are executed, including everything that can be done with Evaluation Logics as well as writing Model Tables, starting new Job Trigger Calculations, etc., via the model binding.

Those logics are meant to be executed asynchronously for potentially long running calculations, data crunching, data preparation, wrangling, machine learning, AI optimization, etc. Their outputs are in the form of Model Tables and logic results. The logic results are persisted to the database and are not meant to hold big quantities of information (that is what Model Tables are for).

There are two natures of logics for formula-based model calculations: simple calculation or parallel calculation.

Simple Calculation

Logic Nature: model_calculation
Execution Types:
- Syntax Check – Not used.
- Standard – Calculates (e.g., produce data in Model Tables) based on the inputs, previous steps inputs and previous calculations outputs.
Information provided to the logic:
- In the Standard mode:
  - model in the logic context, including Model Tables, inputs from previous steps and outputs from previous calculations.
- See also the https://developer.pricefx.eu/pricefx-api/groovy/develop/net/pricefx/formulaengine/optimization/ModelCalculationFormulaContext.html interface and its methods.

Expected logic execution outcome:
- Building Model Tables, starting new Job Trigger Calculations, returning simple information as logic results.

Parallel Calculation

These calculations are executed in a 3-step fashion and are mainly used to implement use cases where it is required to calculate many independent items in parallel. In practice, those items are calculated in a distributed manner (see also Distributed Calculation).

See for a simple procedure on writing and using such logics.

Logic Nature: model_parallel_calculation
Execution Types:
- Syntax Check – Not used.
- Init Context – Prepares the list of items to be calculated in parallel.
  - Can also do everything a simple calculation can do, except starting Job Trigger Calculations.
  - A failure of this step means a failure of the whole calculation.
- Item Context – Executed for each item previously prepared.
  - Can do everything an evaluation can do, i.e., everything is executed in read-only mode.
  - A failure of one item will not prevent other items to run nor the summary to run, but the whole calculation will still be considered as failed.
  - See also .
- Summary Context – Post-processes the calculated items.
  - Can also do everything a simple calculation can do.
  - A failure of this step means a failure of the whole calculation.
Information provided to the logic:
- In the Init Context:
  - model in the logic context, including Model Tables, inputs from previous steps and outputs from previous calculations, as with a simple calculation.
  - It is augmented with methods to create items to be calculated.
  - See also .
- In the Item Context:
  - modelin the logic context, including Model Tables, inputs from previous steps and outputs from previous calculations, as with an evaluation (as it is a read-only context).
  - It is augmented with methods to access the item inputs.
  - See also .
- In the Summary Context:
  - model in the logic context, including Model Tables, inputs from previous steps and outputs from previous calculations, as with a simple calculation:
  - It is augmented with methods to access the calculated items inputs and outputs.
  - See also .
Expected logic execution outcome:
- Building Model Tables, starting new Job Trigger Calculations, returning simple information as logic results.