Event handlers are part of the process definitions and they can be defined at either the scope (local) or process (global) levels and they remain active as long as their enclosing scope or process remains active. Event Handlers define how the process will deal with events that occur independently of the process itself. An Event Handler's event is triggered when a defined event occurs, either a message event or an alarm event. The message events are triggered by an incoming message, whereas Alarms are triggered by either a deadline or duration. A definition of an event handler has two parts:
A sample Event Handler Syntax has shown below.
<eventHandlers>? <!-- Note: There must be at least one onEvent or onAlarm. --> <onEvent partnerLink="NCName" portType="QName"? operation="NCName" ( messageType="QName" | element="QName" )? variable="BPELVariableName"? messageExchange="NCName"?>* <correlations>? <correlation set="NCName" initiate="yes|join|no"? />+ </correlations> <fromParts>? <fromPart part="NCName" toVariable="BPELVariableName" />+ </fromParts> <scope ...>...</scope> </onEvent> <onAlarm>* ( <for expressionLanguage="anyURI"?>duration-expr</for> | <until expressionLanguage="anyURI"?>deadline-expr</until> )? <repeatEvery expressionLanguage="anyURI"?>duration-expr </repeatEvery>? <scope ...>...</scope> </onAlarm> </eventHandlers>
It has an onEvent definition section and an onAlarm definition section. It is required to have either an OnMessage or an OnAlarm defined for an Event Handler. The Event Handler section can have a Correlation Set as the Event Handler is part of the conversation with one of our partners and the Correlation Set will continue to maintain the ongoing conversation's integrity. The onEvent section is followed by an "onAlarm" activity definition. The OnAlarm can be based on either a duration (eg: wait for 2 hours) or a deadline (eg: wait until 2 PM) and has an optional "repeatEvery" setting which allows a duration alarm to reset after being triggered.