1. InterOp Events
Scott Neumann
October 25, 2009

2. Introduction
The purpose of this presentation is to describe technical details of events for the interoperability tests for IEC
Definition: Events are messages that are published asynchronously to indicate a condition or transaction of potential interest has occurred. Event messages use the EventMessage structure with past tense verbs (e.g. created, closed, canceled, changed)

3. Event Example
ESB

4. Event Communication
Processes that may receive events are referred to as ‘Listeners’
The InterOp ESB can publish events in two ways:
To a JMS topic
By invoking a web service for a registered client
Note: There are variations that can be allowed for products and project implementations, where some event generation can be delegated to the ESB as in the case of event auto-generation to report transaction execution to potentially interested listeners
Warning: Aside from the use of WS-Notification, there are many technical issues related to publishing events through the use of web services that would need to be considered for a production implementation

5. Event Generation
Events can be generated by the ESB in the following ways:
As directed by a service process that sends an event to the InterOp ESB for distribution
Auto-generation by the ESB to reflect a ‘create’, ‘change’, ‘cancel’ or ‘close’ transaction that was processed through the ESB
By a test simulator process within the ESB

6. Simulated Events
The ESB has processes which will periodically generate events for testing purposes
Events currently simulated include:
Created EndDeviceEvents
Created MeterReadings
The EndDevice Assets for simulated events will use mRID values in the range of 1-10
Simple events are currently generated every few (3-5) minutes with some minor randomization of content

7. Example EndDeviceEvents
<?xml version="1.0" encoding="UTF-8"?>
<ns0:EventMessage xmlns:SOAP-ENV=" xmlns:ns2=" xmlns:jms1=" xmlns:ns0="
<ns0:Header>
<ns0:Verb>created</ns0:Verb>
<ns0:Noun>EndDeviceEvents</ns0:Noun>
<ns0:Revision>1</ns0:Revision>
<ns0:Timestamp> T20:07:50-04:00</ns0:Timestamp>
<ns0:Source>TestEndDeviceEvent</ns0:Source>
<ns0:Comment>This is a test event that is periodically triggered within the ESB for testing purposes</ns0:Comment>
</ns0:Header>
<ns0:Payload>
<ns1:EndDeviceEvents xmlns:ns1="
<ns1:EndDeviceEvent>
<ns1:mRID>43167</ns1:mRID>
<ns1:category> </ns1:category>
<ns1:createdDateTime> T20:07:50-04:00</ns1:createdDateTime>
<ns1:description>Periodic Test EndDeviceEvent</ns1:description>
<ns1:severity>1</ns1:severity>
<ns1:Assets>
<ns1:mRID>3</ns1:mRID>
</ns1:Assets>
<ns1:status>
<ns1:dateTime> T20:07:50-04:00</ns1:dateTime>
<ns1:reason>Testing</ns1:reason>
<ns1:value> </ns1:value>
</ns1:status>
</ns1:EndDeviceEvent>
</ns1:EndDeviceEvents>
</ns0:Payload>
</ns0:EventMessage>

8. Example MeterReadings
<?xml version="1.0" encoding="UTF-8"?> <ns0:EventMessage xmlns:SOAP-ENV=" xmlns:ns2=" xmlns:jms1=" xmlns:ns0=" <ns0:Header> <ns0:Verb>created</ns0:Verb> <ns0:Noun>MeterReadings</ns0:Noun> <ns0:Revision>1</ns0:Revision> <ns0:Timestamp> T20:06: :00</ns0:Timestamp> <ns0:Source>TestMeterReadings</ns0:Source> <ns0:MessageID>43164</ns0:MessageID> <ns0:Comment>This is a test meter reading that is periodically triggered within the ESB for testing purposes</ns0:Comment> </ns0:Header> <ns0:Payload> <ns1:MeterReadings xmlns:ns1=" <ns1:MeterReading> <ns1:MeterAsset> <ns1:mRID>5</ns1:mRID> <ns1:status> <ns1:value>0.0</ns1:value> </ns1:status> </ns1:MeterAsset>

9. Example MeterReadings (cont.)
<ns1:Readings> <ns1:timeStamp> T20:06: :00</ns1:timeStamp> <ns1:value>6.4E-1</ns1:value> <ns1:ReadingQualities> <ns1:quality>0.0</ns1:quality> </ns1:ReadingQualities> <ns1:ReadingType ref=" "/> </ns1:Readings> </ns1:MeterReading> <ns1:ReadingType> <ns1:mRID> </ns1:mRID> <ns1:aliasName>15-minute IntervalData Forward Energy (kWh)</ns1:aliasName> <ns1:defaultQuality>0.0</ns1:defaultQuality> <ns1:intervalLength>9.0E2</ns1:intervalLength> <ns1:kind>demand</ns1:kind> <ns1:multiplier>k</ns1:multiplier> <ns1:name>15-minute IntervalData Forward Energy (kWh)</ns1:name> <ns1:unit>Wh</ns1:unit> </ns1:ReadingType> </ns1:MeterReadings> </ns0:Payload> </ns0:EventMessage>

10. Event Listeners
The ESB is configured to identify a set of event listeners
However, the configuration is only used by the ESB for those using a web service (WS) transport (i.e. no pre-configuration needed for JMS listeners)
When an event is published, an adapter within the ESB will send a copy to each active WS listener using the ‘PublishEvent’ operation

11. WS Event Publisher in TIBCO
When JMS event is detected, a database query is used to identify the URL of each active WS event listener and send to each
Note: This approach would have many well known shortcomings if used in a production environment, where the use of WS-Bnotifications would be one alternative

12. Receiving Events via JMS
No pre-configuration is needed
Connection to TIBCO EMS (JMS) server is at the provider URL tcp://<host name or IP address>:7222 (the specific hostname will be supplied privately to test participants with the TIBCO JMS driver jar files)
JNDI and XA are not used
Events are published to topics named TESTING.EVENTS.<noun>, allowing for the JMS-based listener to filter by noun
JMS listeners subscribe to specific topics (e.g. TESTING.EVENTS.EndDeviceEvents) or by wild card (e.g. TESTING.EVENTS.*)

13. Receiving Events via WS
Vendor wishing to receive events by web services must do the following:
Implement the PublishEvent service as described by the abstract WSDL and Message.xsd
Open firewall to allow access from ESB server (hostname/IP address to be provided on request to test participants)
Provide the URL of the service, in the form or IP address>:<port>/PublishEvent (e.g.
All types of events (i.e. many combinations of verb and noun) will be sent to the specified URL, where it is the responsibility of the listener to ignore events that are not of interest

14. WSDL for WS Listener
There are two options for WSDLs and Message envelopes:
Abstract.wsdl and Message.xsd
Abstract5.wsdl and Message4.xsd
The latter has some other simplifications that provides better interoperability with some tool sets, e.g. does not include definitions for SOAP faults
Both options are interoperable (has been tested), so long as the elements for ReplayDetection are not used
The following WSDL fragment is the definition of the PublishEvent operation:
<wsdl:operation name="PublishEvent">
<wsdl:input message="ns:EventMessage"/>
<wsdl:output message="ns:ResponseMessage"/>
<wsdl:fault name="fault1" message="ns:FaultMessage"/>
</wsdl:operation>

15. More Information UISOL web site: http://uisol.com
TIBCO:
EPRI Technical Report: ESB Implementation Profile Using IEC 61968