Copyright © TIBCO Software Inc. All Rights Reserved
Copyright © TIBCO Software Inc. All Rights Reserved


Chapter 7 Working with Events : Using Event Handlers

Using Event Handlers
Event Handlers are supported in Business processes and Pageflow processes. You can use event handlers to execute a flow that is separate from the main flow of the process (for instance to update process data used by the main flow).
Event handlers can be triggered zero or more times during the life of a process instance.
While an event handler allows you to do something multiple times during a process, it does not have to happen for the process to complete.
An event handler is a catch intermediate event with no incoming flow. Event handlers with no specific trigger type will normally be triggered through a destination-specific API or utility. See the BPM Developer's Guide for more information.
Using Event Handlers in Pageflows
You could use the event handler to update the process data as shown in the example below. Another way to use it would be to add to the runtime identifier array and associated input mapping arrays to add instances to a dynamic sub-process invocation.
In this example, a pageflow process is used to manage an order request. The event handler is used to update exchange rate information regularly. This updated exchange rate information is then used as input to the task Issue Invoice.
Using Message 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.
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:
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. See Using Throw and Catch Signal Events for more information on non-cancelling signal events.
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..
Migration and Upgrade when using Event Handlers
Migration:
See Design Considerations for Process Migration" for information on process migration considerations when using event handlers.
Upgrade:
Adding, deleting or modifying event handlers from which web-service operations are generated affect the interface and therefore prevent upgrade, but subsequent event handler changes are valid. See "Application Upgrade" in the BPM Implementation Guide for more guidelines.
 

Copyright © TIBCO Software Inc. All Rights Reserved
Copyright © TIBCO Software Inc. All Rights Reserved