Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Aim of this section

Shows how to create or edit an event workflow. 

Related sections

Event Workflows (Reference Manual)

Required permissions

Event Orchestration - edit

...

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

Info

A notification is displayed when the Wait for the event from the previous step option is automatically disabled in the background due to a step being moved or removed.

...

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

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:

    filters01 .png

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.

...

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. Multiple actions (with different targets) can be defined within one listener.

...