Message/Global Signal Event Handlers in Business Processes

Message event handlers allow you to process a separate flow in an existing process instance via a web-service operation. As with any incoming message activity, correlation to a process instance has to be configured.

Note: Catch Global Signals have event handler controls similar to those of catch message event handlers and the behavior is the same as that of catch message event handlers.

Blocking and Non-Blocking Message Handlers

You can configure what happens when an event handler is triggered prior to completion of the flow from a previous triggered instance.

They can be one of the following:

  • Blocking: The Serialize concurrent flows for this event handler option means that further event triggers are queued until an existing event handler flow completes (unless the main process flow completes).
  • Non-blocking: The Allow concurrent flows for this event handler option means that if the event is triggered multiple times, the flow from each can be processed in parallel.

The configuration options are shown under Event Handler on the following screenshot:

Initalizing Event Handlers

You can specify a list of activities after which the event handler will be initialized (or reset if already initialized). You need to do this because if the value of correlation data associated with the event handler is changed during the life of the process then existing event handlers will not be triggered according to the new correlation data value unless they are initialized.

You also need to do this if the initial correlation values are set in the complete script of the message start event or any other script activity, as opposed to initializing on the message start event mapper.

You will also need to do this if the correlation data required for the event handler is not explicitly initiated in mapping on all process start activities (otherwise the event handler will be initialized when correlation data may not yet have been set).

Select initalizers for the event handler using the Initalizers: selection under Event Handler (see screenshot above). You can select any task, embedded-sub-process or event activity (except those attached to task boundary, or events that are themselves event handlers). This includes activities on event handler outgoing flows.

If you do not specify any activities then the event handler will initialize during processing of the first start-activity but before the start-activity's Complete script. For this to happen one of the following must happen:

  • The correlation data associated with each event handler must be initialized in correlation data mappings in each start activity.
  • For any event handlers in processes with non-message start activities (such as sub-processes) you must explicitly state the activities after which the event handler(s) are initialized. Once any activities are explicitly stated in this way, then the event handler will only be initialized after those activities complete .

    Even if the correlation data is initialized in the Complete script of a start activity, if you wish an event handler to initialize correctly you must use this method of explicitly stating the initialize-after activities on each event handler (that is, if the event handler is to be initialized at start of a process instance then the start activity must be explicitly stated).

Example: Using Event Handlers in a Business Process

The following simple example covers updating work item data using an event handler and a non-cancelling signal event.

In this example, a business process is used to manage a request. The event handler is used to update information related to the request . This updated information is then used as input via a non-cancelling signal event to the task Register Request.