Dispatcher Callbacks

The Execution Engine’s Dispatcher Interface provides six callback functions in total. Their purpose and API is explained in the following sections:

Service Started Callback

Service Finished Callback

Task Started Callback

Task Finished Callback

Data Callback

Service Finished Event Callback

These callbacks are not called from the Execution Engine, but from the integrated dispatcher. That means, the dispatcher controls the behavior of the Execution Engine, which only reacts to the invocation of the callbacks. (besides the Service Finished Event Callback)

From these six callback, the execution engine only requires the Service Started Callback, Service Finished Callback and the Service Finished Event Callback to execute processes. The additional callbacks are optional and only need to be considered, in case that it is required by the custom dispatcher.

Service Started Callback

The Service Started Callback is executed to start a service execution and takes a OPC UA Client from the Execution Engine’s Control Interface, which the connects to a target resource and executes the specified service. The Service Started Callback requires the following input parameter:

**Service Started Callback**
Argument	Type	Explanation
name	str	Name of the Service to be executed
service_uuid	str	UUID that uniquely identifies the Service
task_context_uuid	str	UUID of the context (a Task) in which the Service is started
input_parameters	list[union(str, EngineStruct, list[str])]	List with input parameters. Each List element is either a string with a variable name that should be read from the Execution Engine Data Object or a literal value that is provided in the EngineStruct format. It’s possible to hand over an empty list. It’s also possible to hand over a “browse list” to access a field of a structure type. For example with [“value”, “field”, “[10]”], the input value is the “10th” element of the array “field” in the structure “value”.
output_parameters	ordered_dictionary	Ordered Dictionary that specifies all output parameter that should be returned from a Service. The ordered dict contains strings in the format OrderedDict([(variable_name, data_type_name)])

Service Finished Callback

The Service finished callback is executed after the completion of a Service execution and attaches output variables from the service execution to the Execution Engine Data Object. It requires the following input arguments:

**Service Finished Callback**
Argument	Type	Explanation
name	str	Name of the Service that is finished
task_context_uuid	str	UUID of the context (a Task) in which the Service is finished
service_uuid	str	UUID that uniquely identifies the Service

Task Started Callback

The Task Started Callback is executed to add Figure 2: TaskObjectType to the Execution Engine Data Object. In this context, specified input variables are attached to the newly added Figure 2: TaskObjectType. It requires the following input arguments:

**Task Started Callback**
Argument	Type	Explanation
task_name	str	Name of the Task to be executed.
task_uuid	str	UUID that uniquely identifies the Task.
task_context_uuid	str	UUID of the context (a Task) in which the Task is started
task_input_parameter_names	ordered_dictionary	Ordered Dictionary that specifies all input parameter that should be added to the Task. The ordered dict contains a list with strings in the format: OrderedDict([(variable_name, data_type_name)])
task_input_parameter_instances	list[union(str, EngineStruct, list[str])]	List with input parameters. Each List element is either a string with a variable name that should be read from the Execution Engine Data Object or a literal value that is provided in the EngineStruct format. It’s possible to hand over an empty list. It’s also possible to hand over a “browse list” to access a field of a structure type. For example with [“value”, “field”, “[10]”], the input value is the “10th” element of the array “field” in the structure “value”.

Task Finished Callback

The Task Finished Callback is executed to remove Figure 2: TaskObjectType from the Execution Engine Data Object. In this context, specified output variables are extracted and added to the Tasks Context’s Figure 2: TaskObjectType. It requires the following input arguments:

**Task Finished Callback**
Argument	Type	Explanation
name	str	Name of the Task that is finished
uuid	str	UUID that uniquely identifies the Task
task_context_uuid	str	UUID of the context (a Task) in which the Service is finished
output_parameter	list[str]	List with variable names. Each listed variable read from the current Task and attached to the Task context. It’s possible to hand over an empty list.

Data Callback

The Data Callback is executed to return a variable from the Execution Engine Data Object to the dispatcher. It requires the following input arguments:

**Data Callback**
Argument	Type	Explanation
variable_name	str	Name of the variable, which value should be returned to the dispatcher.
task_id	str	UUID that uniquely identifies the Task from which the variable should be read.

Service Finished Event Callback

In contrast to the other callbacks, the Service Finished Event Callback is actively triggered from the Execution Engine. Here the Service Finished Event Callback provides information to the dispatcher that a service execution was completed. It requires the following input arguments:

**Service Finished Event Callback**
Argument	Type	Explanation
service_uuid	str	UUID of the service, which execution is completed.