Event Routing 10.11 | Communicating between Software AG Products Using Event Routing | Understanding Event Routing | Event Types | Event Structure
 
Event Structure
Each event on the messaging bus is composed of the following parts:
*Header
The following table lists the system-defined event attributes that a header contains and the respective attribute descriptions:
Event Attribute
Description
Start
Start date and time of the event.
End
Optional. End date and time of the event. The use of this field depends on how the event is being used. If the value is absent, the consumer application may set a default one, such as start time plus one millisecond.
Kind
Optional. Indicates whether the event is a new event (Event) or a heartbeat (Heartbeat). A heartbeat event indicates the temporal progress of the stream. If a value is not specified, the default is Event.
Type
The unique identifier of the event type. Event types use qualified names (QNames) as the mechanism for concisely identifying the particular type. The event type combines the URI and local name as a string. For example: {http://namespaces.softwareag.com/EDA/WebM/Process/2.0} ProcessStepInstanceChange is the event type identifier that reports changes to a process instance.
Note:
Event types without a namespace use only their local name as event identifier. For example, the noTns.xsd event type’s identifier is noTns.
Version
Optional. The version of the event type with which the event instance is compatible. Users specify this value if they have chosen to support event type versioning. An event should not specify a version if the event type supports versioning.
CorrelationID
Optional. A unique identifier used to associate the event instance with other event instances.
EventID
Optional. A unique identifier of the event. EDA clients can distinguish between different event instances.
Priority
Optional. The priority of the event. Possible values are:
*Normal (default value)
*High
ProducerID
Optional. A unique identifier of the event producer.
UserID
Optional. A unique identifier of the user who emitted the event.
FormatVersion
Optional. The version of the event format. Event Routing creates automatically a value for this attribute. Check the value in the received event to see if the event body contains headers and payload.
*If this attribute is not present in the event headers, the event body contains both headers and payload.
*If this attribute is present in the event headers, and its value is 9.0, the event body contains only payload.
CustomHeaders
Optional. A parent header element for any user-defined headers included as sub-elements.
All messages support the same set of header fields. Header fields contain predefined values that allow clients and providers to identify and route messages. Each of the fields supports its own set and get methods for managing data; some fields are set automatically by the send and publish methods, whereas others must be set by the client. The header contains the start and end timestamp of the event.
*Filterable Properties (optional)
Event Routing supports the so-called filterable properties. If you mark a field node in the event type as filterable, its value is added to the header properties of the event. For example, for the BoothDemo event shown below, if the Producer and the Presenter fields are marked as filterable, the following key-value pairs are added:
PulseCommon$Producer=”Event Generator”
Presenter=”dada”
At run time, when events are delivered to the routing services, event consumers may apply a filter, so that only events that match certain selection criteria are consumed. These criteria can be, for example, whether the event type is a normal event or a heartbeat, or whether the value of an element from the body of the event exceeds a certain value.
Event header elements are always added to the filterable properties with an additional prefix $Event$ in the key. If a node in the event schema is marked as filterable, the element is added to the filterable properties when the event is published. This allows event receivers to use filterable properties based on element values.
*Body
The body contains the payload of the event. The body contains the data fields of the event, as specified in the event's schema.
Here is a sample event:
<evt:Event xmlns:evt="http://namespaces.softwareag.com/EDA/Event>
   <evt:Header>
     <evt:Type>{http://namespaces.softwareag.com/EDA/WebM/Sample/Pulse}Pulse
     </evt:Type>
     <evt:Start>2019-05-20T16:53:46.918-06:00</evt:Start>
     <evt:End>2019-05-20T16:53:47.918-06:00</evt:End>
     <evt:Kind>Event</evt:Kind>
     <evt:EventId>0f375801-dbd4-4a46-9f70-7015deca6c80</evt:EventID>
   </evt:Header>
   <evt:Body>
     <p1:BoothDemo
      xmlns:p1="http://namespaces.softwareag.com/EDA/WebM/Sample/Pulse">
     <p1:PulseCommon>
     <p1:Producer>Event Generator</p1:Producer>
     <p1:Subject>Pulse Test Event</p1:Subject>
     <p1:Coordinates>
       <p1:Longitude>87.44988659217529</p1:Longitude>
       <p1:Latitude>83.11056319477842</p1:Latitude>
     </p1:Coordinates>
     </p1:PulseCommon>
     <p1:Presenter>dada</p1:Presenter>
     <p1:DemoTopic>Demo2</p1:DemoTopic>
     <p1:Date>2019-04-05T17:09:33.112+03:00</p1:Date>
     </p1:BoothDemo>
   </evt:Body>
</evt:Event>