Use the Event Emitter mediation primitive to emit significant business events from inside a mediation flow.
The Event Emitter mediation primitive sends out events, during a mediation flow. Because the events are generated in the form of Common Base Events (CBE) they have a standard XML-based format. The events are sent to a Common Event Infrastructure (CEI) server. For information on CEI resources and services refer to the runtime product documentation and runtime online help.
You can decide whether generated events contain the message being processed, or not.
The Event Emitter mediation primitive has one input terminal (in), one output terminal (out) and a fail terminal (fail). The in terminal is wired to accept a message and the other terminals are wired to propagate a message. The out terminal propagates the original message. If an exception occurs during the processing of the input message, the fail terminal propagates the original message, together with any exception information contained in the failInfo element.
If a generated event contains the message being processed, the event format can be version 6.1 or version 6.0.2. By default, Event Emitter mediation primitives emit events in version 6.1 format, when running on a version 6.1 system.
The version 6.1 format, stores the message as an XML element in the xsd:any slot of a CBE. Because the message is stored in an xsd:any slot, you can retrieve it as an XML instance and use existing XML technologies to process it in an efficient way.
The version 6.0.2 format, stores the message in CBE extended data elements, after either shredding the message or serializing it as a hex value. You can choose to emit events in the version 6.0.2 format, by choosing the appropriate setting in WebSphere® Integration Developer.
To fully utilize Event Emitter information, event consumers need to understand the structure of the CBE. The mechanism for modeling this data is described in more detail in the Detailed event contents section.
Element | Sub-elements | Description | ||
---|---|---|---|---|
event | eventPointData | ModuleName | The name of the module instance | |
MediationName | The name of the Event Emitter instance | |||
EventEmitterLabel | The Label property value | |||
Root | The Root property value | |||
applicationData | content | value | Application data |
Extended Data Element | Description |
---|---|
ModuleName | The name of the module instance |
MediationName | The name of the Event Emitter instance |
Root | The Root property value |
Extended Data Element | Description |
---|---|
Message | Contains the section of the SMO specified by the Root property. This extended data element can contain other, nested, extended data elements corresponding to elements in the specified section of the SMO |
The Event Emitter mediation primitive enhances your monitoring capability by allowing you to send business events from a mediation flow component. You can then view the Event Emitter events using the CBE browser, on the application server, or other CBE consumer applications.
The recommended best practice is to use the Event Emitter mediation primitive to indicate an unusual event. For example, notification of a failure in the flow or an unusual path in the flow. When you place event emitters in a flow you should consider the possible number of events that can be generated, and the size of the message that will be stored in the event. Placing an event emitter in the normal flow path generates many events compared to placing it in an unusual event or failure path. In addition, consider configuring the emitter to store only significant message data, rather than the complete message, to reduce the overall size of the event.
You can use the Event Emitter mediation primitive to record a failure in another mediation primitive, and then continue processing. To do this you wire the fail terminal of the previous mediation primitive to the input terminal of the Event Emitter mediation primitive; and wire the output terminal of the Event Emitter mediation primitive to the next step in the flow.
You can also use the Event Emitter mediation primitive, in combination with the Message Filter mediation primitive, to generate business events based on message content. To do this you wire one of the output terminals of the Message Filter mediation primitive to the input terminal of the Event Emitter mediation primitive; and wire the output terminal of the Event Emitter mediation primitive to the next step in the flow.
Property | Valid Values | Default |
---|---|---|
Label | String | Combination of module name, flow name and flow type. The flow type indicates whether the flow is a request or a response |
Enabled | Clear the checkbox if you want to suspend mediate action. | Selected |
Transaction mode | String: Existing, New or Default | Default |
Root | String: an XPath expression representing the root of the SMO that is stored in the event |
Consider the following when using the Event Emitter mediation primitive:
The events emitted by the Event Emitter mediation primitive conform to the CBE 1.0.1 structure. The CBE specification is part of the IBM® Autonomic Computing Toolkit. For more information about the specification, see: http://www.ibm.com/autonomic/.
The following elements are common to all Event Emitter events:
<esb:ModuleName>Test2</esb:ModuleName>
<esb:MediationName>EventEmitter1</esb:MediationName>
<esb:EventEmitterLabel>Test2_Test2_EventEmitter1_Req</esb:EventEmitterLabel>
<esb:Root>/body/operation1/input1/field1</esb:Root>
<wbi:content wbi:name="Message"> <wbi:value xsi:type="xsd:string">hello</wbi:value> </wbi:content>
<xsd:complexType name="MyBO"> <xsd:sequence> <xsd:element name="value1" type="xsd:string"/> <xsd:element name="value2" type="bons0:MySubBO"/> </xsd:sequence> </xsd:complexType> <xsd:complexType name="MySubBO"> <xsd:sequence> <xsd:element name="value1" type="xsd:string"/> <xsd:element name="value2" type="xsd:int"/> </xsd:sequence> </xsd:complexType>could produce the following example Message element:
<wbi:content wbi:name="Message" wbi:businessObjectName="MyBO" wbi:targetNamespace="http://Test" > <wbi:value xsi:type="p:MyBO" > <value1>hello</value1> <value2> <value1>world</value1> <value2>1234</value2> </value2> </wbi:value> </wbi:content>
<extendedDataElements name="ModuleName" type="string"> <values>CustomerMediation</values> </extendedDataElements>
<extendedDataElements name="MediationName" type="string"> <values>ServiceFailureEvent</values> </extendedDataElements>
<extendedDataElements name="Root" type="string"> <values>/body/operation1/input1/customerID</values> </extendedDataElements>
<extendedDataElements name="Message" type="string"> <values>ABCDE12345</values> </extendedDataElements>If the Root property evaluates to a subtree in the message, the Message extended data element contains child extended data elements corresponding to the message tree structure. For example, the message defined by the following XSD type definitions:
<xsd:complexType name="MyBO"> <xsd:sequence> <xsd:element name="value1" type="xsd:string"/> <xsd:element name="value2" type="bons0:MySubBO"/> </xsd:sequence> </xsd:complexType> <xsd:complexType name="MySubBO"> <xsd:sequence> <xsd:element name="value1" type="xsd:string"/> <xsd:element name="value2" type="xsd:int"/> </xsd:sequence> </xsd:complexType>could produce the following example Message extended data element:
<extendedDataElements name="Message" type="noValue"> <children name="value1" type="string"> <values>ABCDE</values> </children> <children name="value2 type="noValue"> <children name="value1" type="string"> <values>ZYXWV</values> </children> <children name="value2" type="int"> <values>12345</values> </children> </children> </extendedDataElements>