Differences
This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
model_orchestration_with_loadplugin [2020/04/26 03:33] 127.0.0.1 external edit |
— (current) | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | ===== Load Plugin ===== | ||
- | //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 // | ||
- | |||
- | //Load plugin// must be executed on [[enterpriseedition | Enterprise Edition]] or // | ||
- | |||
- | [[http:// | ||
- | |||
- | ---- | ||
- | ==== Load Model Example==== | ||
- | See a simple example of model orchestration: | ||
- | |||
- | {{http:// | ||
- | |||
- | 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, // | ||
- | |||
- | ---- | ||
- | ==== Load Model Modeling ==== | ||
- | //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. | ||
- | |||
- | |||
- | === State ==== | ||
- | Name the states with the following prefix: | ||
- | |||
- | * // | ||
- | * //_wait_// - to wait for all model executions in the execution group to complete | ||
- | |||
- | ===Transition=== | ||
- | * by default // | ||
- | * 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. | ||
- | |||
- | === MScript === | ||
- | You can write mScript as you would normally do for each triggers in the states and transitions to control the model execution. See [[http:// | ||
- | |||
- | === Flow Control === | ||
- | For each state, you can choose an Activate Type and Trigger Type to control the flow of the model execution as described in [[StateNode|StateNode]]. For example, we use // | ||
- | |||
- | You can use loop back transitions to repeat sections of the model as required or place a complex logic to only execute certain models. | ||
- | |||
- | ==== Comments ==== | ||
- | 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. | ||
- | |||