InterOp Events Scott Neumann October 25, 2009

Introduction The purpose of this presentation is to describe technical details of events for the interoperability tests for IEC 61968-9 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)

Event Example ESB

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

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

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

Example EndDeviceEvents <?xml version="1.0" encoding="UTF-8"?> <ns0:EventMessage xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns2="http://tibco.com/namespaces/tnt/plugins/soap" xmlns:jms1="http://www.tibco.com/namespaces/tnt/plugins/jms" xmlns:ns0="http://www.iec.ch/TC57/2008/schema/message"> <ns0:Header> <ns0:Verb>created</ns0:Verb> <ns0:Noun>EndDeviceEvents</ns0:Noun> <ns0:Revision>1</ns0:Revision> <ns0:Timestamp>2009-10-24T20: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="http://iec.ch/TC57/2009/EndDeviceEvents#"> <ns1:EndDeviceEvent> <ns1:mRID>43167</ns1:mRID> <ns1:category>3.26.1.185</ns1:category> <ns1:createdDateTime>2009-10-24T20: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>2009-10-24T20:07:50-04:00</ns1:dateTime> <ns1:reason>Testing</ns1:reason> <ns1:value>3.26.1.185</ns1:value> </ns1:status> </ns1:EndDeviceEvent> </ns1:EndDeviceEvents> </ns0:Payload> </ns0:EventMessage>

Example MeterReadings <?xml version="1.0" encoding="UTF-8"?> <ns0:EventMessage xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns2="http://tibco.com/namespaces/tnt/plugins/soap" xmlns:jms1="http://www.tibco.com/namespaces/tnt/plugins/jms" xmlns:ns0="http://www.iec.ch/TC57/2008/schema/message"> <ns0:Header> <ns0:Verb>created</ns0:Verb> <ns0:Noun>MeterReadings</ns0:Noun> <ns0:Revision>1</ns0:Revision> <ns0:Timestamp>2009-10-24T20:06:26.016-04: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="http://iec.ch/TC57/2009/MeterReadings#"> <ns1:MeterReading> <ns1:MeterAsset> <ns1:mRID>5</ns1:mRID> <ns1:status> <ns1:value>0.0</ns1:value> </ns1:status> </ns1:MeterAsset>

Example MeterReadings (cont.) <ns1:Readings> <ns1:timeStamp>2009-10-24T20:06:26.016-04:00</ns1:timeStamp> <ns1:value>6.4E-1</ns1:value> <ns1:ReadingQualities> <ns1:quality>0.0</ns1:quality> </ns1:ReadingQualities> <ns1:ReadingType ref="2.6.7.1.0.12.0.0.0.3.72"/> </ns1:Readings> </ns1:MeterReading> <ns1:ReadingType> <ns1:mRID>2.6.7.1.0.12.0.0.0.3.72</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>

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

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

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.*)

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 http:<hostname or IP address>:<port>/PublishEvent (e.g. http://70.90.76.57:7799/PublishEvent) 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

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>

More Information UISOL web site: http://uisol.com E-mail: sneumann@uisol.com TIBCO: http://tibco.com EPRI Technical Report: ESB Implementation Profile Using IEC 61968