Content Comparison

...

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).

...

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 lower the number, the higher the priority. For example, if there are two workflows, first has Execution order = 1, the second = 5, the workflow with “1” will be executed first. The 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. If When multiple listeners are defined, they are executed in the specified order , and triggered by the completion of event associated with the previous action. Waiting for the completion of the previous step can be disabled by turning off the 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 . A listener can depend on an event triggered by the previous listenercan 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 follow complete these steps:

1. General

2. Source

3. Action

...

1 – 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.

2 – 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.

...

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:

   

Skip Event

Click > Skip Events to expand the configuration of skip events. 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 triggeredreceived, it will override any other events for that specific step. Skip Events follow the same structure and format as Source Events.

...

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

3 – 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. 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 retries 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.

...