Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

A Model Class is the central configuration point of the Optimization module. It defines the structure and the look and behavior of Model Objects. The user workflow consist of sequence of Steps. In each Step, the user can run a Calculation and then explore and evaluate the results on multiple Tabs.The Model Class definition is stored in a table with type code MC, which has following fields:

View/edit rights can be defined for Model Classes and they are then inherited to Model Objects (and can be further restricted on the model level). For more details on permissions see Module Categories.

Fields

  • uniqueName* – Unique name of the Model Class. It is used in Model Object to reference the Model Class they instantiate. Note , that you can modify the uniqueName, but the references won’t will not be updated automatically.

  • label – Human readable name of the Model Class, displayed to the users, when they select which Model Class they want to use for creating a new Model Object.

  • definition – Defines , how the Model Class instances will look and behave. It stores definitions of Calculations, Steps and Evaluations in a JSON text format.

  • hideFromNewModelDialog – If set to true, the Model Class is not available for selection in the Create New Model dialog or in the quick filter drop-down list for the Model Class column in the Models table.

  • workflowFormulaName – Name of the workflow logic (with workflowType = “model”) which is responsible for building the approval workflow steps , when the user clicks Submit. If not set, when the user submits the model, it is auto-approved and marked as “No Approval Required”.

...

  • then the workflow feature is disabled for those Model Objects.

  • moduleCategoryUN – Defines which Module Category should display a list of Models which are based on this Model Class. User groups defined in this Module Category will be applied to the Model Class, see also Module Category > Access Rights - Roles and User Groups.

  • elementsUserGroupViewDetails – Comma separated list of user groups' unique names. Users can view Model Objects of this Model Class but not edit them.

  • elementsUserGroupEdit – Comma separated list of user groups' unique names. Users can edit Model Objects of this Model Class but not create/delete them.

  • elementsUserGroupManage – Comma separated list of user groups' unique names. Users can create/edit/delete Model Objects of this Model Class.

Definition

Model Class Definition defines how the Model Class instances will look and behave.

In a Model Class, the definition field is contains a JSON document that contains three has main root elements: calculations, steps and , evaluations, actions, tasks.

Calculations (calculations)

A list of calculation. A Calculation defines a calculation process , which can be started from a Step.

Example:

Code Block
languagejson
{
  "definition": {
    "calculations": [

     {
        "name": "calc1",
 
      "type": "formula",
        "formulaName": "POAI_Test_Calc1"
 
    },

     {
        "name": "seq",
 
      "type": "sequence",
        "calculations": [
 
        "calc2", "calc3"

       ]
      },
 
    {
        "name": "calc2",
 
      "type": "formula",

       "formulaName": "POAI_Test_Calc2"
      },
 
    {
 
      "name": "calc3",

       "type": "formula",
        "formulaName": "POAI_Test_Calc3"
      },
      {
        "name": "calc4",
        "type": "parallel",
 
      "formulaName": "POAI_Test_ParallelCalc"
      }
    ]  
}
}

Fields:

  • name* – Name of the Calculation, unique within this Model Class. Must use only alphanumeric characters or dash (no white spaces).

  • type* – Accepted values:

    • formula – Simple calculation, all actions in the provided logic are done in a sequential order.

    • parallel – Parallel calculation. The calculations done by the logic can be split into more parts (called Items) and the calculation of those Items will be done in parallel.

    • sequence – This calculation does not have a logic, it is only reference to a list of other calculations , which should be executed one by one.

  • formulaName* – Unique name of a Logiclogic. Used only for formula and parallel types.

  • sequence* – List of Calculation names defined in this Model Class. Used only for the sequence type.

...

Step (steps)

A list of steps as defined by the following fields.

Fields

  • name* – Name of the step, unique in the Model Class.

  • label – Human readable name of the step, shown in the UI, it defaults to name if not specified.

  • description – Description of the step, shown in the UI.

  • calculation – Name of the calculation associated to this step, optional.

  • tabs – List of tabs as defined below.

Tabs

A list of tabs as defined by the following fields.

Common Fields

  • name* – Name of the tab, unique in the step.

  • label – Human readable name of the tab, shown in the UI, it defaults to name if not specified.

  • type* – Accepted values:

    • dashboard – The content of the tab will be rendered as a dashboard, i.e. input fields on left side, and portlets on the right side.

    • simple – The content of the tab will show the inputs generated by the logic on the left, and on the right side there will be results from the visible elements NOT as portlets, but rather one after another, as a simple list of values (e.g. similar to quote item calculation results).

    • configurator – The content of the tab will be rendered as the Configurator form, i.e. as a list of various input fields, whose values typically have dynamic dependencies.

    • filtertree – The content of the tab will be rendered as a tree (used for example to visualize the Segmentation Tree in the Negotiation Guidance Accelerator), and when you select/click one node, it will show details of the node on the right side, visualized as calculation results (e.g. similar to quote item calculation results).

Dashboard Tab Fields

  • formulaName* – Unique name of an existing Formula of nature model_evaluation, see also Model Evaluation Logic .

Simple Tab Fields

  • formulaName* – Unique name of an existing Formula of nature model_evaluation, see also Model Evaluation Logic .

Configurator Tab Fields

Filtertree Tab Fields

  • treeName* – Name of the tree to be displayed in the tab. It is used to fetch the tree from the backend.

  • formulaName* – Unique name of an existing Formula of nature model_evaluation to be evaluated when a node of the tree is selected (when the user clicks the node of the tree), see also ​Model Evaluation Logic.

  • selectedNodeIdsInputName* – Name of the input passed to the evaluation formula, containing the array of selected node ID.

...

Steps and their Calculations, Tabs and their Evaluation logics.

Example:

Code Block
languagejson
{
  "definition": {
    "steps": [
      {
 
      "name": "step1",
        "label": "First Step",
 
      "description": "This step has 1 calculation and 1 tab.",

       "calculation": "calc1",
        "tabs": [
          {
            "name": "tab1",
 
          "label": "First Tab",

           "type": "dashboard",
            "formulaName": "POAI_Test_Dashboard1"
 
        }
        ]
 
    },

     {
        "name": "step2",
 
      "label": "Second Step",
        "description": "This step has 1 sequence calculation and 3 tabs.",
 
      "calculation": "seq",

       "tabs": [
          {
 
          "name": "tab1",
            "label": "First Tab",
 
          "type": "simple",

           "formulaName": "POAI_Test_Dashboard2"
          },
 
        {
 
          "name": "tab2",

           "label": "Configurator Tab",
            "type": "configurator",
            "formulaName": "POAI_Test_Configurator"
          },
          {
            "name": "tab3",
 
          "label": "Visual Tree",
            "type": "filtertree",
            "treeName": "Segments",
            "formulaName": "POAI_Test_FilterTreeNodeEval",
            "selectedNodeIdsInputName": "selectedNodeIds"
 
        }
        ]
 
    }

   ]
  }
}

Evaluations (evaluations)

These standalone evaluations (their logics) are not used/linked/referenced directly by the tabs, but can be called from another logic when they need to access model results from outside of the model itself, for example in another module (e.g. from Quotes).

Info

See Query Optimization Engine Results to execute an evaluation from another logic.

...

}

Each Step has the following fields:

  • name* – Name of the step, unique in the Model Class. Must use only alphanumeric characters or dash (no white spaces).

  • label – Human readable name of the step, shown in the UI, it defaults to name if not specified.

  • description – Description of the step, shown in the UI.

  • calculation – Name of the calculation associated to this step, optional.

  • tabs – List of Tabs as defined below.

Each Tab has the following fields:

  • name* – Name of the tab, unique in the step. Must use only alphanumeric characters or dash (no white spaces).

  • label – Human readable name of the Tab, shown in the user interface. It defaults to name if not specified.

  • type* – Determines how the Tab will present the content to the user.

    • dashboard – The content of the tab will be rendered as a dashboard, i.e. input fields on left side, and portlets on the right side.

    • simple – The content of the tab will show the inputs generated by the logic on the left, and on the right side there will be results from the visible elements NOT as portlets, but rather one after another, as a simple list of values (e.g. similar to quote item calculation results).

    • configurator – The content of the tab will be rendered as the Configurator form, i.e. as a list of various input fields, whose values typically have dynamic dependencies.

    • filtertree – The content of the tab will be rendered as a tree (used for example to visualize the Segmentation Tree in the Negotiation Guidance Accelerator), and when you select/click one node, it will show details of the node on the right side, visualized as calculation results (e.g. similar to quote item calculation results).

  • formulaName* – Unique name of an existing logic. Depending on the field type (see above), the logic will serve different purposes, and it must be of different Natures.

    • For dashboard type – It must be Model Evaluation Logic which is expected to return input fields (filters) and content for portlets.

    • For simple type – It must be Model Evaluation Logic which is expected to return mostly simple types of values.

    • For configurator type – It must be Model Evaluation Configurator Logic which is expected to return the definition of form sections with input fields.

    • For filtertree type – It must be Model Evaluation Logic. It will be used when the user clicks a tree node, so the logic is expected to return detailed information about the selected node.

  • treeName* (only for filtertree type) – Name of the tree to be displayed in the Tab. The tree is expected to be stored in the model.

  • selectedNodeIdsInputName* (only for filtertree type) – Name of the input parameter passed to the evaluation logic, containing the list of selected node IDs.

Evaluation (evaluations)

This is used mostly for integration of the model with other modules. When another module (e.g. Quoting) needs to access the model results, it can either read the model data tables directly, or rather call the Evaluation to provide the data in a certain way. So, in a way, you can think of it as an API for reading the model.

Note that these Evaluations are not the same as the evaluations used to provide content for Tabs.

Example:

Code Block
languagejson
{
  "evaluations": [
    {
      "name": "query-results",
      "formulaName": "POAI_Test_QueryResults"
    }
  ]
}

Each evaluation has the following fields:

  • name* – Name of the evaluation, unique in the Model Class. Must use only alphanumeric characters or dash (no white spaces).

  • formulaName* – Unique name of an existing Formula logic of nature model_evaluation, see also Model Evaluation Logic.

Info

See Query Optimization Engine Results to execute an evaluation from another logic.

Actions (actions)

When you need to run recalculation of certain Steps or Calculations of a Model Object regularly, you can configure a list of available actions which could be scheduled. The end user can set up a calculation schedule of those actions via UI on the model object detail page. The scheduling can also be done via SchedulesContext available using the method schedulesContext() on the Model Context.

Example of actions definition:

Code Block
languagejson
{
  "definitionactions": [
    {
      "name"    : "scheduled-steps",
      "label"   : "Execute Both Steps",
      "type"    : "evaluations": [
 steps",
      "fromStep": "schedule",
      "toStep"  : "summary"
    },
    {
      "name" : "scheduled-task",
      "namelabel": "query_results",
 Execute the Scheduled Task",
      "type" : "task",
      "formulaNametask" : "POAI_Test_QueryResultsscheduled-task"
    }
  ]
} 

Each action has the following fields:

  • name* – Name of the action, unique in the Model Class. Must use only alphanumeric characters or dash (no white spaces).

  • label* – Description of the action, visible to the end user on the model object Schedule page.

  • type* – What type of action is performed. Available options are:

    • steps – This action will perform calculations from a range of Steps. It can be performed only if the model is editable (i.e. not submitted/approved).

    • task – This action will perform a specified task.

  • fromStep – (Only for the type steps. Optional.) Name of a Step. When specified, the action will process Steps starting with this one. When not specified, the action will process Steps starting from the first one.

  • toStep – (Only for the type steps. Optional.) Name of a Step. When specified, the action will process Steps until, and including, this one. When not specified, the action will process Steps until, and including, the last one.

  • task* – (Only for type task.) Name of the task to be performed. The task must be defined within the same Model Class.

Tasks (tasks)

Info

Since version 11.0

When you need to run calculations regularly by using an Action of the type task, the Task must be defined in the Model Class as follow.

Example of tasks definition:

Code Block
languagejson
{
  "tasks": [
    {
      "name"       : "scheduled-task",
      "label"      : "Scheduled Task",
      "type"       : "post-approval-calculation",
  ]    "calculation": "scheduled-task"
    }
  ]
}

Each task has the following fields:

  • name* – Name of the task, unique in the Model Class. Must use only alphanumeric characters or dash (no white spaces).

  • label* – Description of the task, visible to the end user on the model object Schedule page.

  • type* – What type of task is performed. Available options are:

    • post-approval-calculation – For executing a Calculation after the Model Object has been approved. If the model is not yet approved, the task will be ignored.

  • calculation – (Only for type post-approval-calculation.) Reference to the name of a Calculation defined in this Model Class.