The Execution Zone consists of one or several Execution Containers. There are three types of pico instances that may run in these containers:

• Execution Context (EC)
• Execution Context Stand-Alone (ECSA)
• Service Context

Execution Context

An EC can execute any type of workflow, but will stop execution if the connection with the Platform is lost. An ECSA, on the other hand, can only execute real-time workflows but keeps the workflows active, even if it has temporarily lost connection with the Platform. Similarly, services on an SC continue to run even if connection to the Platform is lost. All of the Execution Context types will register themselves as available in the system at startup.

You can run all types of workflows on an EC, that is both batch, real-time and task workflows. Since batch and real-time processing has different characteristics and requirements, workflows of different types should be executed on separate ECs.

If an EC loses contact with the Platform, workflows will abort as soon as information supplied by the Platform is missing, e g when a transaction is finished. A real-time workflow running on an unreachable EC can continue to run as long as it does not require any information from the Platform.

The EC property ec.backlog.dir determines whether you want events and error messages, occurring when the contact is lost, to be logged in a backlog or not. If the property is not set, events and messages will not be logged. The value of the property states where the backlog resides. The default location is the MZ_HOME/tmp directory. For further information about this directory, see 1.5 Software Environment.

When the connection between the EC and the Platform is restored, the backlog will be transferred to the Platform. The System log entries will contain a timestamp from when they were transferred, that is the time when the connection was reestablished. In case the EC is shutdown during an unreachable state, the backlog will removed and will never be transferred to the Platform.

An unreachable EC will be deregistered, and after 45 minutes it will be removed from the Pico Viewer, if a manual deregistration has not been made before that time has passed. For further information, see 6.10 Pico Viewer in the Desktop User's Guide.

When an EC is deregistered, the workflow will be considered to be aborted on the Platform. In reality, however, it can still be running on the EC. In that case, the workflow needs to be stopped manually via the EC Web Interface.

For further information about the different types of workflows, see Desktop User's Guide.

Stand-Alone Execution Context

An ECSA is less dependent on the Platform compared to a normal Execution Context (EC).

ECSAs are used when workflows must be able to continue to run even if the connection with the Platform is temporarily lost. This is typically required for real-time processing.

ECSAs can only run real-time workflows, in which case the agents' (e.g. Aggregation and Inter Workflow) file storage handling must be done on the ECSA host.

The choice of EC vs. ECSA for real-time workflows in the architecture should be done on a case by case basis.

All events and error messages occurring when the contact with the Platform is lost will be logged in a backlog.  The EC property ecsa.backlog.dir states where the backlog resides. The default location is the MZ_HOME/tmp directory. For further information about this directory, see 1.5 Software Environment

When the connection between the ECSA and the Platform is restored, the backlog will be transferred to the Platform. The System log entries will contain a timestamp from when they were transferred, that is the time when the connection was reestablished. In case the ECSA is shutdown during an unreachable state, the backlog will removed and will never be transferred to the Platform.

An unreachable ECSA will remain registered in the Pico Viewer until it is manually removed or restarted.

Service Context

An SC provides a place to host services that workflows running in ECs and ECSAs can share, independently from the Platform. SCs complement the ECs and ECSAs and are part of the Execution Zone.

During installation of the Platform Container or an Execution Container, you can select a default template that includes installation of SCs. For further information, see 3.1.3 Updating the Installation Properties in Installation Instructions.

The introduction of SCs in is part of a larger architectural initiative, which will span several releases. SC processes have the following objectives:

• To facilitate the use of embedded services, such as Kafka and Zookeeper through a centralized approach to configuration and lifecycle management
• To support running traditional Control Zone services outside the Platform to improve the availability and scalability of

It is planned that services will gradually be moved out of the Platform process to decrease the load on the Platform and to allow the scaling out of relevant services. The SC psc1 is designated for Platform type of services is installed by default together with the Platform Container.

Similar to ECSAs, services executed in SCs continue to function without connection to the Platform, which  is only required when you start an SC.