Creating an Event Definition to Handle Events from the EMQA

You must create your own custom event definition for handling the events generated by the EMQA in SBM. An event definition is a WSDL file derived from the ALF Event Manager WSDL and the ALF event base schema. The event definition specifies custom types and events. It also defines the orchestration workflow (declared as a service flow service) that handles these events. An event definition created by Serena Business Manager is used to generate events from an application workflow. You can create a custom event definition or import a customized event definition into SBM Composer, which lets SBM Composer create orchestration workflows that can handle the events, and configure the events so that the Event Manager will expect them.

Events – A Quick Introduction

An event is a SOAP message that corresponds to the Serena Business Manager event schema. The message includes five elements that are used by the Event Manager for event matching:

<EventType>
<ObjectType>
<Product>
<ProductVersion>
<ProductInstance>

The values of these elements determine which orchestration workflow or workflows run when the event is received. The values are declared in the event definition, which is imported into SBM Composer and used to create mappings between the event and the orchestrations that are implemented to process the event. The event definition can also declare event-specific extended data that is sent with the event, enabling the orchestration to extract the additional data.

How the EMQA Creates the Event SOAP Messages

The adapter reads the XML document messages from the JMS queues specified in the EMQA Setup Service and constructs an event message using the following information:

The root element of the document

Because the root element determines the document type, the type of event that is sent varies dynamically depending on the type of document that is read from the queue. Specifically, the values for the <EventType> and <ObjectType> elements are determined from the name of the root element of the XML document that is read by the EMQA from the JMS queue.

For example, if an XML document has the root element <MyDocument>, as in this example:
```
<?xml version="1.0" encoding="UTF-8"?>
<exmpl:MyDocument xmlns:exmpl="urn:MyDocumentSchema">
  <exmpl:One>data1</exmpl:One>
  <exmpl:Two>data2</exmpl:Two>
</exmpl:MyDocument>
```
then the value of both the <EventType> and the <ObjectType> element will be set to MyDocument.
The values specified in the event_dispatch.properties file

The values of the <Product>, <ProductVersion>, and <ProductInstance> elements are set according to the values in the event_dispatch.properties file.
The contents of the XML document

The contents of the XML document, including the root element, are inserted into the event message structure as the value of the <Extension> element of the event. Using the <MyDocument> example from above, the <Extension> element will look something like this:
```
…
<ns1:Extension>
  <exmpl:MyDocument xmlns:exmpl="urn:MyDocumentSchema">
    <exmpl:One>data1</exmpl:One>
    <exmpl:Two>data2</exmpl:Two>
  </exmpl:MyDocument>
</ns1:Extension>
…
```
Note: If the document being sent in the queue has a pre-existing schema, you might be able to construct the event definition by including the document schema in the event definition and declaring an appropriately typed element as the content of the Extension element. Make sure that the element has the same namespace as the root element of your document. Typically, you must use an element reference that points to the root element of the document.