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

« Previous Version 8 Next »

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

  • Execution Context (EC)
  • Service Context

Execution Context

An EC will stop execution if the connection with the Platform is lost, but for realtime workflows you can configure the workflow to run as a standalone, which will allow it to continue running even if the EC looses connection with the Platform. See 3.1.8 Workflow Properties for more information. All the Execution Contexts will register themselves as available in the system at startup.

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 that have not been configured to run as standalone workflows will abort as soon as information supplied by the Platform is missing, e g when a transaction is finished. A realtime workflow configured to run as a standalone workflow 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 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 be 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.

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 in the 6.7 Execution Manager.

For further information about the different types of workflows, see Workflow Types.

Service Context

An SC provides a place to host services that workflows running in ECs can share, independently from the Platform. SCs complement the ECs 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 /wiki/spaces/MD82/pages/3768338 in /wiki/spaces/MD82/pages/3768324.

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.

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

  • No labels