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, which 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 properties are available:
  • execresourcegroup (string): The execution resource group to use for this execution mode. The execution resource group defines the resources (threads and memory) that the model should consume when running in this mode. If you do not specify an execution resource group, the execution mode uses the DEFAULT resource group.
  • preferredservice (string): The execution service to map this execution mode to when importing the app. If an execution service of this name does not exist on the server, the app is still imported, but no automatic mapping is made to an execution service. If no mapping is specified, the execution mode uses the server's default service.
  • clearinput (boolean): Specifies 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.
  • Deprecated: 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.
    Important: This attribute is supported only for backward compatibility with existing apps that have not yet been updated to use execution resource groups. You cannot use threads and execresourcegroup in the same model. If your model contains any execution mode definitions that specify execresourcegroup, threads is not supported for any execution mode in that model.

For more information about resource-based capacity scheduling, see Scenario Execution and Job Scheduling.

Limiting the Resources Allocated to a Job

The execresourcegroup annotation specifies an execution resource group, which determines the number of threads and the amount of memory that the model should consume. A job using this execution mode is only scheduled on an execution worker that has the specified resources available; otherwise, the job is queued.

If a thread capacity or memory capacity are configured for the execution worker and the execution service mapping on the ADMIN > Execution Services page, the minimum of both are available to the job being executed. Note that multiple execution services can map to the same worker.

The execution resource group specified by an execution mode specifies default resources (threads and memory) for the execution mode. However, these defaults can be overridden by an administrator. Your model can query the actual resources available at run time; for more information, see Querying Runtime Resources.

If you do not specify an execution resource group for the execution mode, the DEFAULT resource group is used. This resource group specifies 1 thread and no memory limit.

Note: If your model has not yet been migrated to use execution resource groups and instead still specifies the threads property for execution modes, Insight automatically generates an execution resource group (with no memory limit) for each unique thread count found in an execution mode definition. These automatically generated resource groups appear on the ADMIN > Execution Resource Groups page.

For more information about execution resource groups, see Defining Custom Execution Resource Groups.

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)
  • No execution resource group is specified, so the DEFAULT resource group (1 thread and no memory limit) is used.
  • The clearinput parameter (@clearinput false) allows you to specify whether the custom execution mode behaves like 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.

© 2001-2025 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.