Load Plugin provides the ability to start model execution either on local server or on remote Runtime servers from a load model - a model that orchestrates execution of models in desired sequence.

It uses the concurrent modeling features TestOptimal provides to orchestrate the model executions and start/stop model executions through modeling notation. It also provides inter-model communication to monitor model execution on the remote server. The execution stats collected for each model executions are organized together and can be accessed through SvrMgr.

Load plugin must be executed on Enterprise Edition or Enterprise Runtime Edition.

See a simple example of model orchestration:

In the example model, the model describes two groups of model executions to run in parallel. Within each execution group, there are 3 model executions to be executed simultaneously on a set of Runtime servers. At the end of each execution group, the executions are checked and appropriate actions can be tagged to the states or transitions when the execution group is completed.

Although you can still use mScript to perform the model execution start, LoadPlugin provides a convenient way to start model executions via naming of the state and transitions as described next.

Load Model is a concurrent model specifically created to orchestrate the execution of multiple models. It is essentially the same as any concurrent model except that it optionally follows certain naming convention for the states and transitions to simplify the automation script required.

Name the states with the following prefix:

• _group_- to start an execution group with the name of execution group following the prefix.
• _wait_ - to wait for all model executions in the execution group to complete

• by default LoadPlugin will try to look for the model with the name that matches the transition name. If no models are found with the transition name, it treats the transition as a regular transition. If it finds a model with the matching name, it will start the model execution automatically.
• name the transition with prefix _run_ to start the model execution. The name of the model is specified after the prefix. This is equivalent to the first method with one difference that it will trigger the failure if the model is not found.

You can write mScript as you would normally do for each triggers in the states and transitions to control the model execution. See LoadPlugin mScript Functions for a list of available mScript functions.

For each state, you can choose an Activate Type and Trigger Type to control the flow of the model execution as described in StateNode. For example, we use Transition count type in the example model so that when all models in the group are submitted to execute, until then we wait for their execution to complete. This way, all transitions triggered from the group state are merged back into a single action.

You can use loop back transitions to repeat sections of the model as required or place a complex logic to only execute certain models.

NOTE: Unlike FSM models, any transitions in the concurrent models can be running at the same time and one transition can result in many more transitions to be executed concurrently. When you have a loop in the model, there is a potential that too many transitions may be triggered and executed. Be sure to use appropriate Activate Type and Trigger Trans setting accordingly for each state.

One other thing to watch out is the use of Debug mode. Be aware that even though the model is paused as shown in IDE, other concurrent transitions not involved in the pause are still executing in the background.