The Event Process Life Cycle Management refers to the deployment of an Event Process in various environments like Development, Testing, Staging, and Production. The user does not have to create different Event Processes for different environments; instead the user can simply specify the properties for service instances comprising Event Processes for various environments in a single Event Process.

Setting Properties of Service Instances for Different Environments

When a Service instance is dragged and dropped in the Orchestration editor, the default environment is set to development. To configure a different environment, select the Target Environment in the Environment Properties tab of the Event Process comprising the service instance.


Click somewhere in the Orchestration editor away from the service/route/port to find the Environment Properties tab in the Properties view.

Hereafter, the environment dependent service properties will be written to the corresponding env.xml file and will be picked up from that file when Event Process is launched in that particular environment.

You can specify these properties for more than one environment by switching the Target Environment label in the properties of an event process. Configuring service instances for different environments is made easy as the configuration properties of the service instance in a new environment will be picked up from the previously configured environment when the CPS is opened.

This way service instances can have a different set of properties while running on different environments. For example, a File Reader instance can be configured to read from a dev.txt file in a Development environment and from a test.txt file in a Testing environment.

Figure 1: Environment Properties Tab reflecting FileReader configuration


The Environment Properties appear after configuring the microservice. The configurable properties appear under Environment properties, which can be further configured to set environment specific configuration by accessing from this section.


Refer the How to Utilize EPLCM section to work with a sample.

Defining Named Configurations for Different Environments

While defining a named configuration, the environment in which the configuration should appear can be defined in the Configuration details page. Different versions of the configuration can be defined for different environments.

In addition to defining configurations manually, when the target environment of the Event Process is changed, a dialog is displayed where the user can choose to copy configurations from the old environment if they are missing in the new environment.

In the figure below, the environment of the event process is changed from Development to Testing. A pop-up is shown asking the user if any missing configurations should be copied to the new environment. If the user chooses Yes, the configuration used in the event process, here test (Port) and ConnectionConfig (Resource) are copied to Testing environment.

Figure 2: Message dialog pop-up when changing the target environment of an event process

Running Event Process on an Environment

To run an Event Process on a particular environment, follow the steps as mentioned in the example below:

  1. Take a flow containing File Reader and Display components. Configure the File Reader providing different inputs in different environments as mentioned in the above section. Select the Target Environment in the Environment Properties tab of the Event Process. The environment specific properties for the service instances in the flow can be viewed from the Environment Properties table view present below the Target Environment section.
  2. Do the CRC and launch the flow. When the flow is launched in development environment, the contents from the dev.txt will be read and these messages can be viewed in the display. Similarly when launched in testing environment the contents from the test.txt will be read and these messages can be viewed in the display.

Refer the How to Define Named Configuration section to work with a sample.

Adaptavist ThemeBuilder EngineAtlassian Confluence