Scenario handler
Overview
A script handler is an algorithm for interpreting scripts as subroutines. Each instance of the script handler is a standalone virtual machine process.
A script as a high-level algorithm declaration consists of components. The script handler as a lower-level interpretation algorithm includes algorithms for implementing component functionality.
The script handler process is a state machine and performs event processing. Events can come in the form of messages from the outside, or be generated by executable components.
process
The workflow of the scenario handler can be visualized in the following sequence of actions:
-
loads the script,
-
creates data areas to store the variables declared by the script,
-
Finds the component Start with the main branch type in the script,
-
maps the component declaration to the component’s interpretation algorithm,
-
passes control to the component algorithm, passing the parameters for the component from the script and the accumulated context as input,
-
directs the events received during the component’s operation to its processing queue and passes control to the component for processing this queue,
-
processes the component’s response:
-
continuation of the component’s operation, then it stands waiting for events to arrive;
-
postpone processing of the next event, then move the event to another queue;
-
terminating the component’s operation. When the component completes, it returns:
-
identifier of the next component, then the process is repeated with the new component starting from the stage of its search in the scenario, expanding, however, by applying delayed events;
-
code of the next script, then it is loaded and the process is repeated from the beginning;
-
error, then the script is terminated and possibly a post-processing branch is started;
-
command to return to the previous scenario in the stack from the nested one, then the context of the previous scenario and the position in it are restored;
-
stop command, then the script is terminated and a post-processing branch may be started;
-
-
Thus, each component is executed in a scenario handler process, takes as input the accumulated context and the component declaration from the scenario.
The execution of a component can proceed synchronously and asynchronously. In the asynchronous case, all events received by the script handler (internally and externally) are passed to the current executable component for processing. He in turn can:
-
to process the message,
-
to throw it away,
-
set aside for the next component.
At any time the handler may receive an external command to terminate, in which case the currently executing component is terminated. If an appropriate post-processing branch is available, control is transferred to it, and if not, the script is terminated.
Autoclose transition branches
The component selects one or another transition branch for control transfer based on the obtained result. Most components separate successful and unsuccessful performance outcomes by mapping different transition branches to them.
If an alternative transition branch is not specified (no property is selected), components generally pass control along the main branch. Thus, the scenario has the possibility to continue if the component has failed, but the corresponding transition branch is not set.
This behavior of branching components is called transition branch closure. Branching components are divided into closing and terminating on an unassigned branch.
Post processing
Script termination can occur for several reasons (described in component Start). However, the script handler can continue executing the script in the same context on an alternate branch created by the administrator in case the script terminates for one reason or another.
Executing a post-processing branch at completion no longer involves switching to another branch.
To avoid cluttering CPU power and RAM, a limit is imposed on the execution time of the post-processing branch. It can be enhanced in the Start component that initiates the corresponding branch.
Scenario substitution
The script handler provides an outward facing interface for script spoofing. With it, at any point of execution and at any point in time, a new script can be loaded into the current context and start executing from its beginning. The component being executed at the time of the swap is terminated.
Default values for variables
Local variables can be given default values when the script is created. Initial values are passed externally by the owner of the script handler, i.e. the process that started it.
The script handler itself can also fill in the values of local variables if values for them have not been set previously.
This happens immediately after loading if the script entity in options (opts.variables) contains default values for the variable names declared by the script. This operation occurs when loading each script, including nested scripts.
Next, the Start component can also fill in the values of local variables, if the values for them have not been set earlier. This is done with the corresponding settings of the component.
A script can contain the Value Assignment component immediately after the Start component or later.
In any other case, local variables are left blank and cannot be used as value providers.