Initializing help system before first use

Defining Custom Execution Modes

Custom execution modes are defined using annotations in the model.

The insight.execmodes annotations would normally immediately precede the subroutines that implement the execution mode. Alternatively, the relevant subroutine declarations along with the execution mode annotations can be grouped into a declarations block before the actual definitions of the subroutines.

Every app is assigned two standard execution modes: LOAD and RUN. A model can also define any number of additional custom execution modes—they can offer your app two additional forms of control:
  • Executing different model code paths based on the execution mode selected by a user.
  • Routing different kinds of Xpress Insight jobs to different worker resources configured on the server.
When defining custom execution modes, or when modifying the characteristics of the standard execution modes, the following attributes are available:
  • threads-(integer) The maximum number of threads that the model should consume when running in this mode. Defaults to unspecified which is interpreted as 1 by the Insight scheduler.
  • preferredservice-(string) The execution service to try and map this execution mode to when importing the app. If an execution service of this name does not exist on the server when importing the app then the app will still be imported but no mapping will automatically be made to an execution service. If not specified the execution mode will try to use the server's default service unless later mapped.
  • clearinput-(boolean) Flags whether:
    1. model data should be loaded directly by the model rather than populated from the Insight server into the model.
    2. after model execution, all Insight input entity data gets populated to Insight from the model.
    Defaults to false. Set to true for LOAD, while RUN has clearinput set to false.
  • descr-(string) A description of the execution mode to help a systems administrator determine the purpose or requirements of the execution mode. Defaults to empty description.

For more on thread based capacity scheduling please, see Scenario Execution and Job Scheduling in the Insight Developer Guide.

Limiting the threads allocated to a Job

An execution mode definition that includes the optional threads annotation will limit the number of threads the model should consume. A job using this mode will only be scheduled on an execution worker that has the specified number of threads available, otherwise the job will be queued.

In addition, if the Thread Capacity is configured in the Execution Worker and Execution Services Mappings in the Execution Services ADMIN page, the minimum of both will be available to the job being executed. Note that multiple execution services can map to the same worker.

Calling a Custom Execution Mode

Custom Execution Load and Run Modes cannot be triggered from the Scenario pill menu, they require an extra button in the Xpress Insight user interface.

Code Snippet 

uses "mminsight"

!@insight.manage=input
public declarations
  !@insight.alias Years
  Years: range 
  !@insight.alias Cities
  Cities: set of string  

  !@insight.alias Input array of integer
  InputArrInt: array(Years) of integer 

  !@insight.alias Input array of string
  !@insight.update.afterexecution=true
  ! Updated after model execution
  InputArrStr: array(Years) of string 
end-declarations

!@insight.manage=result
public declarations
  ResultArr: array(Years) of real 
end-declarations

Example Custom Run function 

(!@insight.execmodes.CUSTOM_RUN.
  @descr Custom run execution mode.
  @clearinput false
!)
public procedure customrun
  writeln('CUSTOM_RUN mode...')
  ! Populate with Insight scenario data
  insightpopulate

  ! Calculate results
  forall(t in Years) ResultArr(t):=InputArrInt(t)*2.0
  ResultCol(2020):=999999
  StrCol(2018):= 'Updated after CUSTOM_RUN mode'
end-procedure
This is the most common way to create an additional run mode. In this example:
  • The name is explicitly stated (CUSTOM_RUN)
  • The clearinput parameter (@clearinput false) allows you to specify whether the custom execution mode behaves like to the built in load or run mode. In this case, it behaves like the built-in run mode.
  • When it is executed, all inputs are initialized (by a call to insightpopulate), and all results are extracted and written to the database. Additionally, any inputs marked as 'update after execution' (insight.update.afterexecution) are also updated—This is normally used when pre-processing data prior to final calculation.
Parent Topic Custom Execution Modes

© 2001-2024 Fair Isaac Corporation. All rights reserved. This documentation is the property of Fair Isaac Corporation (“FICO”). Receipt or possession of this documentation does not convey rights to disclose, reproduce, make derivative works, use, or allow others to use it except solely for internal evaluation purposes to determine whether to purchase a license to the software described in this documentation, or as otherwise set forth in a written software license agreement between you and FICO (or a FICO affiliate). Use of this documentation and the software described in it must conform strictly to the foregoing permitted uses, and no other use is permitted.