Model instances are runtime versions of models–executable modules with all their module imports. When you create a model instance, you "run a model". You can run multiple instances of a model possibly with different parameters to have the model instance adapt to different circumstances.
Each model instance holds a set of properties along with its context and context data. For detailed information on behavior of Model instances, refer to the GO-BPMN Model Language Guide.
You can temporarily stop the execution of a model instance or terminate it when required, update the model it is based on, and update its data.
You can also export the runtime data as a raw XML and import such data back.
To list the model instances on an LSPS Server in the Management Perspective, connect PDS to the LSPS Server and open the Management perspective: the list of modules is available in the Module Instances Management view.
Note that you can copy the displayed model instance information with the Copy to Clipboard option in their context menu. To copy multiple model instances to the clipboard, select them and press Ctrl + C.
To list the model instances on an LSPS Server in Management Console, log in to the console and open the Model Instances page.
To list the model instances on the LSPS Server from the Command Line, use the modelInstanceList command.
Long Option | Short Option | Description |
---|---|---|
--host * | -h | host URL |
--username * | -u | user name |
--password * | -p | password |
--modelInstance | model instance ids, for example 8002 9000 | |
--modelInstanceFile | file with model instance ids | |
--filterModelId | IDs of the models | |
--filterModelName | model name pattern (supports ? and * wildcards) | |
--filterModelVersion | model version (supports ? and * wildcards) | |
--filterStatus | models in the defined execution status (CREATED, RUNNING, SUSPENDED, FINISHED) | |
--filterFrom | model instance(s) initiated after TIMESTAMP, format: yyyy-MM-dd HH:mm:ss | |
--filterTo | model instance(s) initiated before TIMESTAMP, format: yyyy-MM-dd HH:mm:ss | |
--filterProps | model instance properties defined as key1 value1 key2 value2 | |
--filterExpression | boolean expression; Only the model instances for which the expression evaluates to true are returned. |
* required parameters
Example with a text file with model instance IDs
When you run a model, a model instance based on the executable module a model instances is created. In the model instance, a module instance of the executable module and module instances of all its imported modules recursively are created. For more details, refer to section Model Instance in the GO-BPMN Language Guide.
To create a Model instance of an uploaded model from the Management perspective, do the following:
To create model instances of uploaded modules from Management Console, do the following:
To create a model instance of an uploaded model from the Command-Line Tools, use the startModelInstance command.
Long Option | Short Option | Description |
---|---|---|
--host * | -h | host URL |
--username * | -u | user name |
--password * | -p | password |
--modelName | model name | |
--modelVersion | model version | |
--modelId | model ID | |
--properties | model instance properties defined a list of key-value pairs |
* required parameters
When restarting the server of the application, model instances need to be restarted as well. If your models make use of the start monitoring mechanism you can check if the instances started up correctly from all the management tools.
To inspect the start status of model instances from the Management perspective, display the Application Restart view: go to Window > Show View > Application Restart
To inspect the start status of model instances from Management Console, log in to the console and open the Application Restart page.
To list the start status of model instances from the Command Line, use the appRestartInfo command.
Long Option | Short Option | Description |
---|---|---|
--host * | -h | host URL |
--username * | -u | user name |
--password * | -p | password |
--onlyStatus | returns only overall restarting status |
* required parameters
A model instance holds a set of properties and details of its execution status. You can view the details and manage the data where possible.
To display the details of a model instance, double-click the model instance in the Model Instances view.
You can visualize the current status of Model instance resources in their live diagrams: Live diagrams are diagrams of Process resources as defined in their Model (process, goal, plan, or sub-process diagrams). Individual execution states are indicated by colors. Diagram legend can be displayed by clicking the legend button in the view toolbar.
To visualize the history of the execution flow on the live diagram, click the History button in the view toolbar: You can then use the slider at the bottom of the view to view the execution workflow.
Using the buttons in the toolbar of the model detail, you can in addition do the following:
To display a model instance detail from Management Console, click the model instance ID on the Model Instance page in the Model Instance ID column.
To display a live diagram with the execution, do the following:
Important: The diagrams in the Management console do not display hyperlink, lane and pool diagram elements.
The context of model instances can be generally changed in the Expression Evaluator: to change variable values, evaluate an assignment expression, for example, x:=2
, to send a signal, use sendSignal()
, for example, evaluate sendSignal(true, {thisModelInstance()}, "My signal object")
, to deactivate a goal, use deactivate()
, for example, deactivate({StockMaintainGoal})
, etc. Refer to the Standard Library for further functions.
For some context manipulations, such as, change of variable value, goal activation and deactivation, and signal removal, dedicated management features are provided for convenience.
To evaluate expressions using the current context values of a Model instance, use the Expression Evaluator in the Model instance detail:
The context of the Expression Evaluator is set to the selected context: you can check the current context in the Expression Evaluator view.
The expressions can be executed in persistent or non-persistent mode:
Information on the selected context is displayed in the Expression Evaluator: this is by default the Model instance context. To change the context to a Module, Process, Sub-Process context, select the respective element in the Model instance tree.
To evaluate an expression in the context of a model instance from Management Console:
Unselect Persistent to evaluate the expression without changing of the data in the database.
If the Persistent flag is selected and the expression changes the value of an entity, for example, a global variable, the change is reflected on the runtime data, that is, the variable takes the newly assigned value.
To remove evaluated expressions from the table, select the expressions and click the Remove (X) button in the upper-right corner.
To change values of variables during execution, you can either enter an assignments expression, such as, myVar:="new value"
, in the Expression Evaluator of the model instance or change it in the context tree in the model instance detail.
You can change values of variables during execution either from the Expression Evaluator using assignments or from the Model instance detail.
To change the value of a variable in a running model instance, do the following:
Note: Depending on the variable type (basic, record, collection, etc.), the Update Variable dialog box shows relevant buttons. For basic values, provide the desired value directly; make sure you follow the Expression Language rules. Collection and record values are edited recursively, that is, if you click Edit, there are gradually "split" in less complex values, until basic values are displayed.
You can change values of variables during execution either from the Expression Evaluator using assignments or from the Model instance detail.
To change the value of a variable of a running model instance from the Model Instance detail, do the following:
When a goal is deactivated, it becomes deactivated along with all sub-Goals and execution of any plans is halted; activation is the opposite action: a goal that is deactivated, achieved, or failed becomes ready and further execution can follow. The mechanism applies to both Maintain and Achieve Goals. Further information is available in the Modeling Language guide.
Changing execution states of Goals during execution can help you to direct the flow of the execution. Note that you can activate or reactivate only achieved, failed, deactivated or inactive goals, and deactivate only ready or running goals.
To deactivate or activate a Goal, do the following:
Alternatively, you can call deactivate()
and activate()
functions from the Expression Evaluator of the model instance.
To deactivate or reactivate a Goal of a running model instance from the Model Instance detail, do the following:
Alternatively, you can call deactivate()
and activate()
functions from the Expression Evaluator of the model instance.
To remove a waiting signal of a model instance from the Management perspective, do the following:
To remove a waiting signal of a model instance, do the following:
To amend the runtime data of running or suspended model instances in critical situations, you can export the state to an XML file, modify them in the XML and upload the XML with the new state.
You can modify only the context data of the model instance that are not persisted: if you modify data that is persisted in the database, including model-instance properties, such as, the initiator, the changes are ignored: it is only the context of the model instance that changes.
Important: Importing a corrupted model instance XML can cause fatal failure on the server.
To export and import a model-instance XML, do the following:
Edit the exported XML files. Do not modify data that is persisted in the database, including model-instance properties, such as, the initiator, the changes are ignored.
If you changed such data, fix the XML and import it again.
Important: Importing a corrupted model instance XML can cause fatal failure on the server.
To export a model-instance XML and import it with modifications, do the following:
Save and edit the export XML file. Do not modify data that is persisted in the database, including model-instance properties, such as, the initiator, the changes are ignored.
If you changed such data, fix the XML and import it again.
To export a model-instance XML and import its modified version, use the export
and import
commands:
export exports a model instance as an XML file;
Long Option | Short Option | Description |
---|---|---|
--host * | -h | host URL |
--username * | -u | user name |
--password * | -p | password |
--modelInstance | model instance ids, for example 8002 9000 | |
--modelInstanceFile | file with model instance IDs | |
--location | output location and file prefix (model instance IDs are appended to the prefix) |
* required parameters
Important: Importing a corrupted model-instance XML can cause fatal failure on the server.
importRaw imports a raw model instance state;
Long Option | Short Option | Description |
---|---|---|
--host * | -h | host URL |
--username * | -u | user name |
--password * | -p | password |
--modelInstance * | model instance ids, for example 8002 9000 | |
--file * | file with model instance |
* required parameters
When you suspend a running model instance, it becomes read-only and its execution is halted: All running elements become suspended including any to-do which become read-only. Suspended model instances can be resumed. More information on suspend is available in the GO-BPMN Modeling Language Guide.
To suspend a running Model instance or resume a suspended Model instance, do the following:
On detailed behavior of Model instances, refer to GO-BPMN Model Language User Guide.
The command is available also in the context menu of individual model instances.
A suspended model instance stops its execution. On resume, the instance continues from where it was suspended.
To suspend or resume a suspended model instance, do the following:
suspend suspends model instances;
Long Option | Short Option | Description |
---|---|---|
--host * | -h | host URL |
--username * | -u | user name |
--password * | -p | password |
--modelInstance | model instance IDs, for example, 8999 8899 | |
--modelInstanceFile | file with model instance IDs to be requested | |
--filterModelId | IDs of the models | |
--filterModelName | model name pattern (supports ? and * wildcards) | |
--filterModelVersion | model version (supports ? and * wildcards) | |
--filterFrom | model instance(s) initiated after TIMESTAMP, format: yyyy-MM-dd HH:mm:ss | |
--filterTo | model instance(s) initiated before TIMESTAMP, format: yyyy-MM-dd HH:mm:ss | |
--filterProps | model instance properties defined as key1 value1 key2 value2 | |
--filterExpression | boolean expression; Only the model instances for which the expression evaluates to true are returned. | |
--testFilter | boolean expression; displays the model instances affected by the command (the command is not executed) |
* required parameters
resume resumes suspended or updated model instances;
Long Option | Short Option | Description |
---|---|---|
--host * | -h | host URL |
--username * | -u | user name |
--password * | -p | password |
--modelInstance | model instance IDs, for example, 8999 8899 | |
--modelInstanceFile | file with model instance IDs to be resumed | |
--filterModelId | ID of the model | |
--filterModelName | model name pattern (supports ? and * wildcards) | |
--filterModelVersion | model version (supports ? and * wildcards) | |
--filterFrom | model instance(s) initiated after TIMESTAMP, format: yyyy-MM-dd HH:mm:ss | |
--filterTo | model instance(s) initiated before TIMESTAMP, format: yyyy-MM-dd HH:mm:ss | |
--filterProps | model instance properties defined as key1 value1 key2 value2 | |
--filterExpression | boolean expression; Only the model instances for which the expression evaluates to true are returned. | |
--testFilter | boolean expression; displays the model instances affected by the command (the command is not executed) |
* required parameters
When you finish a model instance, the running elements stop their execution immediately and the status of the model instance becomes finished.
To finish a running Model instance from the Management perspective, do the following:
To finish a model instance from Management Console, do the following:
finish finishes model instances
Long Option | Short Option | Description |
---|---|---|
--host * | -h | host URL |
--username * | -u | user name |
--password * | -p | password |
--modelInstance | model instance IDs, for example, 7888 7887 | |
--modelInstanceFile | file with model instance IDs to be resumed | |
--filterModelId | ID of the model | |
--filterModelName | model name pattern (supports ? and * wildcards) | |
--filterModelVersion | model version (supports ? and * wildcards) | |
--filterFrom | model instance(s) initiated after TIMESTAMP, format: yyyy-MM-dd HH:mm:ss | |
--filterTo | model instance(s) initiated before TIMESTAMP, format: yyyy-MM-dd HH:mm:ss | |
--filterProps | model instance properties defined as key1 value1 key2 value2 | |
--filterExpression | boolean expression; Only the model instances for which the expression evaluates to true are returned. | |
--testFilter | boolean expression; displays the model instances affected by the command (the command is not executed) |
* required parameters
When you restart a running model instance, its module instances finish and module instances are created anew within the same model instance: the instances are running under the same model instance which preserves the ID of the model instance. Context of the finished module instances does not impact the context of the new module instances.
On restart, you can select the model the model instance will use, be it the same or a different one.
Important: The persisted data structures used by the original model and the model used on restart must be compatible; for example, if you remove a column from a database table which was used by the original model and is not used by the model after restart, the restart fails: the column has to be present in the database. To resolve such a situation, use the Do not change strategy for update of the database schema and remove the redundant structures from the database after the restart.
To restart one or multiple model instances from the Management perspective, do the following:
To restart one or multiple model instances, do the following:
restart restarts running or suspended model instances
Long Option | Short Option | Description |
---|---|---|
--host * | -h | host URL |
--username * | -u | user name |
--password * | -p | password |
--modelId | ID of the model used for the restarted model instances (if not specified, each instance is restarted without model change) | |
--modelInstance | model instance IDs, for example, 7848 7687 | |
--modelInstanceFile | file with model instance IDs to be restarted | |
--filterModelId | ID of the model | |
--filterModelName | model name pattern (supports ? and * wildcards) | |
--filterModelVersion | model version (supports ? and * wildcards) | |
--filterFrom | model instance(s) initiated after TIMESTAMP, format: yyyy-MM-dd HH:mm:ss | |
--filterTo | model instance(s) initiated before TIMESTAMP, format: yyyy-MM-dd HH:mm:ss | |
--filterProps | model instance properties defined as "key1 value1 key2 value2" | |
--filterExpression | boolean expression; Only the model instances for which the expression evaluates to true are returned. | |
--testFilter | boolean expression; displays the model instances affected by the command (the command is not executed) |
* required parameters
On invoke, a Model instance attempts to continue its execution: this feature is helpful if a Model instance remains in a state where it is waiting for an event which cannot occur, typically due to manual adjustments (for example, change on timer events or variable values), you can invoke the model instance to make the instance check if it can continue.
To invoke a model instance, go to Model Instances view, select the model instance and click the Invoke button.
To change the model used by a running or suspended model instance, use model update: During model update, the underlying model is substituted with a new model and updated according the model update configuration file, which is created in PDS.
Before performing model update, make sure you have a model update configuration at hand. Also make sure that the underlying database is in the correct target state. Note that any changes to the database must be backwards compatible.
Important: Model update can result in inconsistent data and corrupt model instances. Make sure to have a backup of your environment before performing model update.
Important: If your changes include incompatible changes to your data type model, you need to suspend any running model instances and migrate your business database before update.
Before updating model instances, make sure the new Model (target) is uploaded. Note that only model instances that are Running, Suspended, Updated, or Update Aborted can be updated. During update, the model instance is suspended and becomes read-only. Such a model instance cannot be resumed manually.
When updating Model instances their IDs are preserved and the rules defined in the Model update configuration are applied.
Important: Old and new model must use the same version of Standard Library.
Note that you can perform model update on model instances from the Management perspective of PDS as instructed here, or alternatively from the Management Console or command line with the Command Line.
To update model instances, do the following:
On the Filter page, define the filtering criteria for model instances and click Apply Filter if applicable.
You can apply also a previously defined filter. However, status and model criteria are ignored since the model is defined in the Model Update Configuration.
The selected instances go through the model-update process. Check their detail views and the Model Update Logs view for details. Depending on the model update settings, the update process may be waiting for manual triggering of its transformation or post-processing phase: To resume a model update of a model instance, click the Continue Model Update ( ) button in the Model Instances view in the Management perspective.
After the update has finished, the model instances remain in the status Updated and are still not running. To resume the instances, click Resume in their context menu.
To resume all model instances returned by the Filter of the view, click Resume All Updated in the context menu.
Note: If resuming a large number of instances, make sure the resumed action was applied to all of them. Resume any instances that failed to resume.
You can abort model updates from the Management perspective: Click the Abort Model Update button ( ) in the view toolbar.
The feature is available in Management Console as well.
The logs from a model update procedure are available in the Model Update Logs view. The view displays information on source and target models and details on updated model instances (below the list of model updates).
The Model Update Detail view contains details about the update of a model instance.
To display the view, click the model instance ID in the Model Update Logs view.
To download a model update configuration from the LSPS Server, do the following:
To update a model instance, do the following:
When calling any of the model update command, the command is executed by default on all model instances of the model according to the update rules defined in the muc file. However you can define the id of a model instance you want to update using the --modelInstance
parameter. or to perform the command over multiple instances, use the filter parameters:
--modelInstanceFile
parameter with a file with the IDs (each ID on a new line)--filterStatus
, filterFrom
and filterTo
, --filterProps
, etc. for multiple model instances based on their properties.Consider using the --testFilter
parameter to trigger a dryrun and check the resulting set of model instances.
Note: To acquire the model update command, you can set up a test model update and use the Show command line script feature in PDS.
For information on model update, refer to Modeling.
Example model update command
modelUpdate updates models instances based on the provided muc file
Long Option | Short Option | Description |
---|---|---|
--host * | -h | host URL |
--username * | -u | user name |
--password * | -p | password |
--muc * | muc file | |
--datamapping | data mapping definition | |
--modelInstance | model instance IDs, for example, 8341 8432 | |
--modelInstanceFile | file with model instance IDs to be updated | |
--filterStatus | only model instances in the defined execution status are updated (RUNNING, SUSPENDED, UPDATED, UPDATE_ABORTED) | |
--filterFrom | model instance(s) initiated after TIMESTAMP, format: yyyy-MM-dd HH:mm:ss | |
--filterTo | model instance(s) initiated before TIMESTAMP, format: yyyy-MM-dd HH:mm:ss | |
--filterProps | model instance properties defined as key1 value1 key2 value2 | |
--filterExpression | boolean expression; Only the model instances for which the expression evaluates to true are returned. | |
--testFilter | boolean expression; displays the model instances affected by the command (the command is not executed) |
* required parameters
continueTransform triggers the transformation phase of update on the model instances;
Long Option | Short Option | Description |
---|---|---|
--host * | -h | host URL |
--username * | -u | user name |
--password * | -p | password |
--modelInstance | model instance IDs, for example, 8346 8436 | |
--modelInstanceFile | file with the model instance | |
--filterModelId | ID of the model | |
--filterModelName | model name pattern (supports ? and * wildcards) | |
--filterModelVersion | model version (supports ? and * wildcards) | |
--filterFrom | model instance(s) initiated after TIMESTAMP, format: yyyy-MM-dd HH:mm:ss | |
--filterTo | model instance(s) initiated before TIMESTAMP, format: yyyy-MM-dd HH:mm:ss | |
--filterProps | model instance properties defined as key1 value1 key2 value2 | |
--filterExpression | boolean expression; Only the model instances for which the expression evaluates to true are returned. | |
--testFilter | boolean expression; displays the model instances affected by the command (the command is not executed) |
* required parameters
continuePostprocess triggers the postprocess phase of model update;
Long Option | Short Option | Description |
---|---|---|
--host * | -h | host URL |
--username * | -u | user name |
--password * | -p | password |
--modelInstance | model instance IDs, for example, 8355 8443 | |
--modelInstanceFile | file with the model instance | |
--filterModelId | ID of the model | |
--filterModelName | model name pattern (supports ? and * wildcards) | |
--filterModelVersion | model version (supports ? and * wildcards) | |
--filterFrom | model instance(s) initiated after TIMESTAMP, format: yyyy-MM-dd HH:mm:ss | |
--filterTo | model instance(s) initiated before TIMESTAMP, format: yyyy-MM-dd HH:mm:ss | |
--filterProps | model instance properties defined as key1 value1 key2 value2 | |
--filterExpression | boolean expression; Only the model instances for which the expression evaluates to true are returned. | |
--testFilter | boolean expression; displays the model instances affected by the command (the command is not executed) |
* required parameters
abortModelUpdate aborts update of model instances;
Long Option | Short Option | Description |
---|---|---|
--host * | -h | host URL |
--username * | -u | user name |
--password * | -p | password |
--modelInstance | model instance IDs, for example, 8308 8529 | |
--modelInstanceFile | file with the model instance | |
--filterModelId | ID of the model | |
--filterModelName | model name pattern (supports ? and * wildcards) | |
--filterModelVersion | model version (supports ? and * wildcards) | |
--filterFrom | model instance(s) initiated after TIMESTAMP, format: yyyy-MM-dd HH:mm:ss | |
--filterTo | model instance(s) initiated before TIMESTAMP, format: yyyy-MM-dd HH:mm:ss | |
--filterProps | model instance properties defined as key1 value1 key2 value2 | |
--filterExpression | boolean expression; Only the model instances for which the expression evaluates to true are returned. | |
--testFilter | boolean expression; displays the model instances affected by the command (the command is not executed) |
* required parameters