Versions Compared

Key

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

...

See Workflow Group States[hide]2.2[/hide] for further information about workflow group states.

Filtering

In the Event Setup tab, the values for all the event fields are set by default to All in the Match Value(s) column, which will generate event notifications for all state changes for all workflow groups. Double-click on the field to open the Match Values dialog where you can click on the Add button to add which values you want to filter on. If there are specific values available, these will appear in a drop-down list. Alternatively, you can enter a hard coded string or a regular expression.

...

The following fields are inherited from the Base event, and can also be used for filtering, described in more detail in Base Event[hide]2.2[/hide] (2.2):

  • category - If you have configured any Event Categories, you can select to only generate notifications for Group State events with the selected categories. See Event Category[hide]2.2[/hide] (2.2) for further information about Event Categories.

  • contents - The contents field contains a hard coded string with event specific information. If you want to use this field for filtering you can enter a part of the contents as a hard coded string, e g the state you are interested in Idle/Running/Stopping/etc. However, for Group State events, almost everything in the content is available for filtering by using the other event fields, e g groupName, groupState, etc.

  • eventName - This field can be used to specify which event types you want to generate notifications for. This may be useful if the selected event type is a parent to other event types. However, since the Group State event is not a parent to any other event, this field will typically not be used for this event.

  • origin - If you only want to generate notifications for events that are issued from certain Execution Contexts, you can specify the IP addresses of these Execution Contexts in this field. However, since the Group State events are only issued from the Platform, this event field should typically not be used for filtering.

  • receiveTimeStamp - This field contains the date and time for when the event was inserted into the Platform database. If you want to use timeStamp for filtering, it may be a good idea to enter a regular expression, for example, "2012-06.*" for catching all Group State events from 1st of June, 2012, to 30th of June, 2012.

  • severity - With this field you can determine to only generate notifications for state changes with a certain severity; Information, Warning, Error or Disaster. For example, a state change from Idle to Running will typically be of severity Information, while a state change to Abort state will typically be of severity Error.

  • timeStamp This field contains the date and time for when the Execution Context generated the event. If you want to use timeStamp for filtering, it may be a good idea to enter a regular expression, for example, "2012-06-15 09:.*" for catching all Group State events from 9:00 to 9:59 on the 15th of June, 2012.
     

Note
titleNote!

The values of these fields may also be included in the notifications according to your configurations in the Notifier Setup  tab.

Examples Group State Event Configuration

Info
titleExample - Group State Event sent to Database

 

This configuration will give you the following notification setup:

  • When the workflow group MyGroup, located in the Default folder, changes state to either Aborted or Stopping, a Group State Event notification will be generated.

  • When this Group State Event is generated an entry will be added in the groupStates table in the database:

    • The workflow group name will be inserted in the wfg column in the database table.

    • The state will be inserted in the state column in the database table.

    • The timestamp from the EC will be inserted in the timestamp column in the database table.

...