Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Current »

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.

Execution Context Stand-Alone

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.

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 inis part of a larger architectural initiative, which will span several releases. Service Context 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.

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

 

  • No labels