How to Create Event Workflow

Prerequisites

1. Make sure the required event types are enabled at your partition.

2. Check out the general event configuration in PlatformManager. Especially pay attention to the MQ field: if it is empty, the setting is taken from the instance and it will most likely point to the PROD instance of RabbitMQ (which can only see events from PlatformManager PROD but not QA).

Creating Workflow

1. Go to Account > Event Workflows > Workflows. 

2. Click Create Event Workflow.

3. Fill in the following fields: 

   • Enter Workflow name of your choice and Description (optionally).

   • In Execution order define the priority of the workflow. The higher number, the higher priority. This can be handy if there are more workflows with listeners for the same event.

   • In Global Timeout define in how many minutes the event workflow should be cancelled if it was not executed.

   • In Workflow Type select one of the following:

     • Single-source – The workflow takes place within a single entity (e.g. partition).

       • Source Type: Select Partition, Integration, or PFM.

       • Source Name: Select the source name. This will be displayed under the Target column in the Event Orchestration > Workflows table.

     • Multi-source – Allows for the combination of events/actions in multiple entities (partitions or integrations).

4. Define one or more listeners. You can enable or disable individual listeners by toggling the switch in the Enabled column. If multiple listeners are defined, they are executed in the specified order, triggered by the completion of the previous action. Waiting for the completion of the previous step can be disabled by turning off the Wait for Previous Step option. A listener can depend on an event triggered by the previous listener. Each listener can consist of a group of events.
   To add a listener see the https://pricefx.atlassian.net/wiki/spaces/PMDEV/pages/4512350334/How+to+Create+Event+Workflow#How-To-Add-Listener section below.

How To Add Listener

Click Add Listener and follow these steps:

1. General

2. Source

3. Action

General step

• Fill in Listener name of your choice and Description (optionally).

• In Listener Timeout define in how many minutes the listener should be cancelled if it was not executed.

Source step

Here you define one or more events which should trigger the listener. You can use a filter to make a more specific selection. You can also set up timeout and delayed trigger for the events.

Source Event

1. Click Add Source Event.

2. Select Source Type (either Partition, Integration, or PFM) and Source Name (specific partition or IM instance). 

3. Select which Event Type should trigger an action.

   1. At a partition, not all events happening there are supported, so always check out this list here first. 

   2. For integrations, only custom events (intentionally emitted by custom code in a route) can be selected.

4. Optionally apply a Filter to the event records. It can be a multi-expression. Use a JSONPath value in the Parameter field. The JSON can be different for each use case—see the log to find out the correct values, for example $.jobName, $.trackerType, $.status.
   Example of the filter expression:

   Open

   

    

Skip Event

Source Events Combination Logic

If there are multiple Source Events, define what Source Events Combination Logic should be used:

• All – The listener waits until all defined events are received and then continues with the action.

• One of – The listener continues with the action as soon as any of the defined events is received.

Timeout

Specifies time between the first and last event in case of the "All" option for Source Events. If this timeout is exceeded, the listener will stop waiting for events and the current workflow run will be terminated.

Delayed trigger

If a delay is specified, the workflow will wait for the selected amount of time before processing begins. This delay will start when the first event is received.

Wait for the event from the previous step

If checked, the listener becomes dependent on an event from the previous listener. This option is available only for the second and subsequent steps.

Action step

Here you define where the triggered action should take place. The action will be triggered with an empty payload as default. You can define a custom payload if needed. Multiple actions (with different targets) can be defined within one listener.

1. Select Target Type (either Partition, Integration, or PFM) and Target Name (specific partition or IM instance).
   The Target Type and Target Name fields are only editable for multiple source workflow type.

2. Action Type: Defines what should happen at the target partition / IM instance.

   • Options for a partition:

     • If Logic is selected, in Action ID select a logic from the target partition to run.

     • If Calculation is selected, in Action ID select a Calculation Field Set (CFS) from the target partition to run. (Support for other types of calculation will be added in future releases.)

     • If Dataload is selected, in Action ID select a Data Load from the target partition to run.

     • If Calculation Flow is selected, in Action ID select a Calculation Flow from the target partition to run. The Calculation has to be already created in the Pricefx app (Administration > Configuration > System Configuration > Calculation Flows).

     • If PFM Workflow is selected, choose a workflow from the target partition in the Action ID field to execute.

     • If Data Download is selected, choose a download from the target partition in the Action ID field to start.

   • Options for an IM instance:

     • If Route is selected, in Action ID select a route from the target IM instance. The route must be of the type direct.

3. Fallback: Enable this function to define alternative actions if the initially set action fails to execute.

   • Number of attempts: Specifies the number of retries the system should make if the initial action fails. After the number of attempts is reached, the Fallback action is triggered.

   • Fallback Timeout: Defines the wait time (in minutes) before each retry attempt. If the response is not received in the defined number of minutes, the Fallback action is triggered.

   • Fallback Action: If the number of attempts is reached, one of the following action is triggered:

     • Terminate the Workflow: Stops the workflow entirely if the initial action fails.

     • Skip the Action: Continues the workflow by bypassing the failed action without triggering the fallback action.

     • Custom Action: Allows you to specify a custom fallback action to be executed if the initial action fails. Select the Action Type and Action ID of the desired action to be executed.

4. Click Save Action.

Open

5. To add the listener, click Finish Listener. Save the new workflow by clicking the Create button.

6. Optionally, set up notifications. For more details see How to Create Event Orchestration Notification.

Timeouts

Each workflow has several timeout settings:

If a timeout occurs the request/step/workflow is considered to be in an error state and appropriate action are being taken.