This page aims to help you create and run a simple Optimization logic. An Optimization logic is assigned to an Optimization model and defines its inputs, calculations and results. For more detailed information about the Optimization logic see Optimization Model Logic (DEPRECATED).

Logic Configuration Options

The first step is to decide on the logic configuration:

1. Single-logic: In a single-logic configuration, the whole calculation is defined within a single Optimization logic. It is suitable for logics with a smaller number of relatively simple calculation steps.

2. Sub-logic: In a sub-logic configuration, there is one main logic and several sub-logics with different suffixes separated by an underscore. Each calculation step must have its own sub-logic, with the suffix corresponding to the name of the step. Additionally, you can also have a library logic with the suffix _Lib that can be accessed from all the other logics using the lib API binding. A sub-logic configuration is more suitable if you have a larger number of calculation steps, or if some of the steps are more complex.

Running Optimization Logic

In general, it is recommended not to run an Optimization logic in the Debug mode. It is usually better to create a model, assign the logic to that model and run the logic directly from the model using the Calculate button on each calculation tab. There are multiple reasons why you wouldn’t want to run the logic in the Debug mode:

• Some API bindings (such as lib) are not available in the Debug mode and their usage will result in an error.

• Several API functions commonly used in Optimization logics (such as creation or update of Company Parameter tables) do not have any effect in the Debug mode.

• It is not possible to select a calculation item as context so it is not possible to run calculation from an existing calculation item.

You can, however, run the logic in the Logic Test Drive mode.

Logic Examples

Here you can download example logics and use them as templates for your logic. You will need to change the names and implementation of the calculation steps and also the model definition.

Open

There are two logics - SingleLogic and SubLogic, the second one consisting of 4 separate logics. The source code of the two logics is basically the same, just differently organized. Both logics define exactly the same behavior – in the definition of the model, you need to choose the source table (a Datamart or DataSource) that you will be working with. The model will have two calculation steps – CountDistinct and Average. Each step has an input parameter where the user picks a field from the source table and after clicking the Calculate button, it runs the calculation and computes the corresponding metric.

SingleLogic Example

In this configuration, both the Definition and Calculation elements are defined in the same logic. To assign in which phase an element should be executed, we can set a Calculation Context attribute to that element. A good practice is to use the element’s Condition attribute to limit the execution of that element to a specific calculation step.

SubLogic Example

This logic consists of 4 individual logics – the main logic SubLogic, library logic with shared functions called SubLogic_Lib and calculation step logics SubLogic_Average and SubLogic_CountDistinct. The exact naming of these sub-logics is very important. The connections between these sub-logics are only identified when running the calculation from a model. Therefore, the SubLogic_Lib cannot be accessed in the Debug or Input Generation mode.

When creating a model with sub-logic configuration, the main logic needs to be selected as the model’s logic.