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 waiting 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. When multiple listeners are defined, they are executed in the specified order and triggered by the event associated with the previous action. The listener is started only when the triggering (received) event contains the same Job Status Tracker (JST) as the action triggered by the previous listener. The Wait for Previous Step option can be turned off to disable waiting for the previous step's completion. 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 complete these steps:

1. https://pricefx.atlassian.net/wiki/spaces/PMDEV/pages/edit-v2/4512350334#General-step

2. https://pricefx.atlassian.net/wiki/spaces/PMDEV/pages/edit-v2/4512350334#Source-step

3. https://pricefx.atlassian.net/wiki/spaces/PMDEV/pages/edit-v2/4512350334#Action-step

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

Here you can define specific events that allow workflows to bypass certain steps under predefined conditions.

Skip Events have a higher priority over standard Source Events, meaning that if a Skip Event is received, it will override any other events for that specific step. Skip Events follow the same structure and format as Source Events.

When a step in a workflow receives a Skip Event:

• No Action Triggered: The step will not execute any associated actions.

• Pass-Through to Next Step: The Skip Event passes to the subsequent step in the sequence.

• Condition Fulfillment Check: For the next step to proceed, it must fulfill the conditions of the initial event in the Source Event section; otherwise, it will also be skipped.

You can:

• Start a workflow with a Skip Event: Allows you to define conditions where the workflow starts, but certain steps can be immediately skipped.

• Skip multiple steps: Each step evaluates the Skip Event condition, if met, the step will not execute and will be passed over, continuing the workflow without interruption.

• Finish a workflow with a Skip Event: Ends a workflow when triggered. If the Skip Event condition is met, the workflow will bypass any remaining steps and finish.

Adding a Skip Event

1. Navigate to Skip Event settings: Within the listener configuration, go to the Source tab and click Add Skip Event.

2. Define Source Event parameters:

   • Source Type: Choose the type of integration, partition, or PlatformManager (PFM)

   • Source Name: Select the specific source instance.

   • Event Type: Specify the event type.

3. Apply Filters:

   • Use filters to further define the conditions under which the Skip Event will be triggered. Set Parameter and Value pairs as needed.

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. 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. The target names of Data Feed and Data Source are displayed in parentheses.

     • 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 overall number of attempts (where 1 is the original/first attempt, 0 is not allowed) 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.