Texas Nodal Market Redesign
Market Information System Web Portal
Messages, Alerts, and Notifications
Version .02
MIS – Alerts and Messaging
ERCOT Confidential
Document Revisions
Date
Version
Description
Author(s)
10/16/2006
.01
First draft
Ganesh Narayan
10/17/2006
.02
Edits for clarity and re-format
Pat Harris
© 2006 Electric Reliability Council of Texas, Inc. All rights reserved.
MIS – Alerts and Messaging
__________________________________________________________________________________________________________________________________________
Table of Contents
1. Introduction .................................................................................................................................... 2
2. Definitions........................................................................................................................................ 2
2.1.
Messages ................................................................................................................................... 2
2.2.
Alerts ......................................................................................................................................... 3
2.3.
Notifications .............................................................................................................................. 4
2. Diagrams ........................................................................................................................................... 5
2.1.
Messages ................................................................................................................................... 5
2.2
Alerts ......................................................................................................................................... 6
2.3
Notifications .............................................................................................................................. 7
3. Strategy ........................................................................................................................................... 8
3.1.
Messages ................................................................................................................................... 8
3.2.
Alerts ......................................................................................................................................... 8
3.3.
Notifications .............................................................................................................................. 8
4. Frequently Asked Questions ....................................................................................................... 11
4.1.
Are Alerts and Notifications Point to Point or Publish/Subscribe? ......................................... 11
4.2.
What is the advantage of using the Messaging System? ......................................................... 11
4.3.
How does one interface to the Messaging System? ................................................................ 11
4.4.
Can one go point to point, if the situation demands? .............................................................. 11
4.5.
What happens in case the consumer goes down during the data exchange? ........................... 12
4.6.
Who takes care of the message data validation and transformation? ...................................... 12
4.7.
Are notification messages persisted? ...................................................................................... 12
4.8.
What does Asynchronous messaging mean?........................................................................... 12
© 2006 Electric Reliability Council of Texas, Inc. All rights reserved.
i
MIS – Alerts and Messaging
___________________________________________________________________________________________________________________________________________
1. Introduction
Throughout the Nodal Protocols are references to moving information from one system to
another, whether it be between source systems, a source system and a Market Participant system,
or source systems and the MIS web portal. Information is moved in many ways depending upon
purpose and data types.
Primary among this movement of data are Messages, Alerts, and Notifications. Generally these
are small informational bits of data whose purpose is to inform of important activities and events.
Their purpose is to attract your attention to critical situation so that you don’t have to search for
them. The Messaging System embedded within the Nodal system will handle the delivery,
validation and routing of these messages between sources, participating systems and the MIS
portal.
2. Definitions
2.1. Messages
A message is a form of data exchange between 2 or more participants within the domain of the
Messaging System. All messages are constructed of 1 or more sections, where each section is
specified as an XML document.
Message
--Required----
Header
---------------------------Optional-----------------------------
Payload 1
Payload 2
Payload n
All messages exchanged between ERCOT and Market Participant systems should be sent over a
secured platform, whether HTTPS protocol over a secure TCP/IP or access to a secured URL.
Header
The first section of the physical message is a header, used to describe metadata about the data
payload being carried. Commands, errors, and time stamp information, environment types, and
data types are examples of header metadata that may be included.
Payload
Subsequent sections contain data payload specific to the message. There can be 0 or more data
payload sections. A minimum message can consist of the header section only, as in the case of an
acknowledgement. The payload data section is driven by an XML Schema Definition, or XSD.
Like a database defined by a schema, the layout of the payload is defined by the XSD.
The XML payload itself will contain the location of this XSD
file.
© 2006 Electric Reliability Council of Texas, Inc. All rights reserved.
2
MIS – Alerts and Messaging
___________________________________________________________________________________________________________________________________________
2.2. Alerts
When a Nodal source system needs to notify a participating system of an important event a
defined alert event is posted to the Messaging System. ERCOT source systems must send
periodic notifications to the Market Participant systems asynchronously as defined in Nodal
Protocols. Following are some examples of alerts:
 A/S Obligation Alert
 Congestion Alert
 Emergency Condition Alert
 Down-Balancing Energy Percent Requirement Alert
 Resource Plan Invalid Alert
 Market-clearing Price Alert
 Market Schedule Alert
 Schedule Mismatch Alert
 Selected A/S Bids Alert
 Selected Replacement Capacity Service Alert
Note: This is not a complete list of the alerts defined in NODAL requirements for MIS, but
provided as example data only.
Alerts are used for alerting a participating system to a critical event and expect a return
acknowledgement from the participating system that the alert was received successfully.
Alerts are posted to the Messaging system from the source system (i.e.:CRR). The Messaging
system identifies the Market Participant system URL and posts the alert to the URL.
ERCOT
Source
Systems
Alert message
M
E
S
S
A
G
I
N
G
Alert message
Market
Participant
Systems
Acknowledgement
Message
S
Y
S
T
E
M
The Acknowledgement does not go back to the source system. The Messaging System
receives the acknowledgement from the Market Participant system. If the
© 2006 Electric Reliability Council of Texas, Inc. All rights reserved.
3
MIS – Alerts and Messaging
___________________________________________________________________________________________________________________________________________
acknowledgement is not received, then the message is resent from the alert queue. If the
acknowledgement is received, then the message is pushed to archive and deleted from the
alert queue.
2.3. Notifications
Notifications are messages specifically intended for the Market Participant user logged in to the
MIS Web Portal, and do not require an acknowledgement. The Notification is sent from the
source system to the Messaging system and the messaging system in turn notifies the MIS Web
Portal. The portal server receives this notification and presents the notification within the context
of the Web portal. The MIS Web Portal does not send an acknowledgement back to the
Messaging system nor to the source system.
The Messaging system also handles the delivery of the notification message data to the Market
Participant user in an e-mail format by means of the Messaging system’s common services. For
a notification message, the messaging system invokes a web service URL and posts the
notification there.
Source systems may also send e-mail notifications to the Messaging system which handles the
actual delivery to the participant’s inbox.
ERCOT
Source
Systems
Notification
message
M
E
S
S
A
G
I
N
G
Notification
message
Market
Participant
Systems
S
Y
S
T
E
M
© 2006 Electric Reliability Council of Texas, Inc. All rights reserved.
4
MIS – Alerts and Messaging
___________________________________________________________________________________________________________________________________________
2. Diagrams
2.1.
Messages
MESSAGING
Push
Messaging
System
NODAL ENTERPRISE SYSTEMS
Publish Queue
Source pushes data to the
Messaging System
Ackowledge
Queue
Messaging System
pushes data to the
Market Participation
system invoking web
services
Market Participant Systems
Web
Services
Market Participation system
sends acknowledgement to
messaging system
Request/Reply
NODAL ENTERPRISE SYSTEMS
Messaging system sends the
request message to the
source system
Messaging
System
Request Queue
Reply queue
Source system sends the
reply message back to the
messaging system
© 2006 Electric Reliability Council of Texas, Inc. All rights reserved.
Market Participation
requests source
systems for data
invoking web services
Market Participant Systems
Web
Services
Messaging System sends
the reply message to the
market participant systems
5
MIS – Alerts and Messaging
___________________________________________________________________________________________________________________________________________
2.2 Alerts
ALERT MESSAGING
(PUSH)
Market Participant Systems
Market Participant
system consumes
the Alert Message
Market Participant
system issues an
Acknowledgement
Message
Web
Services
Alert Message is
delivered to the
participant’s web
services
Web services propagate
Acknowledgement
Message to the
Messaging System
Messaging System
Alert Queue
ACK Queue
TIBCO EMS Queue
TIBCO EMS Queue
Alert Message is
delivered to the
Messaging System to
a queue
Source Systems post
ALERT Message
NODAL ENTERPRISE SYSTEMS
© 2006 Electric Reliability Council of Texas, Inc. All rights reserved.
6
MIS – Alerts and Messaging
___________________________________________________________________________________________________________________________________________
2.3 Notifications
NOTIFICATION MESSAGING
(PUSH)
MIS Web Portal
MIS Portal Server
MIS Web Portal
consumes the
Notification Message
E-Mail
Web
Services
Notification Message is
delivered to the MIS Web
Portal Web services
Messaging System
TIBCO EMS Queue
Notification
Queue
TIBCO EMS Queue
E-Mail
Queue
Notification Message
is delivered to the
Messaging System to
a queue
Source Systems posts
E-Mail Notification
Message
NODAL ENTERPRISE SYSTEMS
© 2006 Electric Reliability Council of Texas, Inc. All rights reserved.
7
MIS – Alerts and Messaging
___________________________________________________________________________________________________________________________________________
3. Strategy
3.1. Messages
Request/Reply messaging strategy
 Market participant sends request message to ERCOT via an URL that serves a web
service.
 A Web service is invoked to deliver request data to the messaging system queue.
 Messaging system provides the transport mechanism of the data from the queue and posts
the data to the source system.
 Messaging system parses and validates message format. Validation of message is limited
to the fields, data-types, and semantic-type validation including data range checking.
 If parse and validation are successful, the Messaging system dispatches the message to
the source system which responds with a reply message that is fulfilled by a response
data. The response data is posted to the messaging system reply queue. The messaging
system then picks up the data from the queue and sends it to the requesting participating
system invoking its web services.
 If parse and validation are not successful, the Messaging System notified the source
system with an error message.
Push messaging strategy
 ERCOT Source systems sends message to the Messaging System queue.
 Messaging system parses and validates message format. Validation of message is limited
to the fields, data-types, and semantic-type validation including data range checking.
 If parse and validation are successful, the Messaging System transports the data from its
queue to the participating systems invoking their web services
 Market Participant receives the message data.
 Market Participant sends acknowledgement message to the messaging system.
 If parse and interpretation are not successful, Messaging system sends an error message
to the source system.
3.2. Alerts






ERCOT Source systems will push message to the Messaging System queue.
Messaging system parses and validates message format. Validation of message is limited
to the fields, data-types, and semantic-type validation including data range checking.
If parse and validation are successful, the Messaging System transports the data from its
queue to the Market Participating system invoking their web services.
Market Participant receives the Alert Message data.
Market Participant system sends acknowledgement message to the Messaging System.
The message is delivered to the return message queue specified in the alert message.
If parse and interpretation are not successful, the Messaging System sends an error
message to the ERCOT Source system.
3.3. Notifications

ERCOT Source systems will push message to the Messaging System queue using its web
services.
© 2006 Electric Reliability Council of Texas, Inc. All rights reserved.
8
MIS – Alerts and Messaging
___________________________________________________________________________________________________________________________________________





Messaging system parses and validates message format. Validation of message is limited
to the fields, data-types, and semantic-type validation including data range checking.
If parse and validation are successful, the Messaging system pushes the notification
message from its queue to the MIS Portal invoking a web service that is pre-registered
with the messaging system as a part of discovery process between the MIS web portal
and the Messaging system.
MIS Portal web service validates the message and parses its contents.
Contents are then delivered to the alert pane in the Portal context.
If requirements dictate, notification messages are also pushed to the e-mail queue. The
messaging system uses its common services module to deliver the message from this
queue to the market participant user’s mail inbox.
© 2006 Electric Reliability Council of Texas, Inc. All rights reserved.
9
MIS – Alerts and Messaging
___________________________________________________________________________________________________________________________________________
Market Participant Systems
MIS Web Portal
Web
Services
Web
Services
Alert
Message
ACK
Message
Messaging System
Notification Queue
Publishes
Notification
Message
E-Mail Notification
Queue
4
Return
Queue
3
Alert Queue
Common
Services
1) Source system pushes an Alert Message to the Messaging
system Alert Queue. The Messaging System will then dispatch
the message from the alert queue to the Market participants
system invoking their web services.
1
2) The market participant system will then acknowledge the
alert message by sending a return acknowledgement to the
messaging system return queue. The messaging system then
dispatches this ACK message to the Messaging system
ERCOT Source Systems
Publishes
Alert Message
© 2006 Electric Reliability Council of Texas, Inc. All rights reserved.
Publishes EMail
Notification
Message
3) Source system pushes a Notification message to the
Messaging system Notification Queue . The Messaging system
will then dispatch the message from the Notification queue to
the MIS Web Portal invoking the portals web services
4) Source system pushes a E-Mail Notification message to the
Messaging system E-Mail Notification queue invoking its web
services. The Messaging system will then dispatch the message
from the E-Mail Notification queue to its Common Service which
sends the email to the Market Participant user.
10
MIS – Alerts and Messaging
___________________________________________________________________________________________________________________________________________
4. Frequently Asked Questions
4.1. Are Alerts and Notifications Point to Point or Publish/Subscribe?
Alerts and Notifications are published or pushed from the source system to the messaging system.
These events are pushed into defined queues, for ex. an Alert queue and a notification queue.
From the queue, the events are dispatched based on the priority and queue member weight, to the
market participant systems which subscribe to the content. Thus Alerts and Notifications fall
under the Publish/Subscribe messaging category.
4.2. What is the advantage of using the Messaging System?
A Messaging System provides an infrastructure that removes any direct connection between
service consumers and providers. Consumers connect to the messaging system and not the
provider that actually implements the service. This type of connection further decouples the
consumer from the provider. A messaging system also implements further value add capabilities
like message persistence, common services etc.
4.3. How does one interface to the Messaging System?
Protocols such as Web services define a standard way of describing the interface to the
Messaging System.. Web services consume or service data that is wrapped in a standard, predefined XML message format. The XML when received is validated against a schema on the
receiving end to ensure the integrity of the data. The message headers contain metadata
information as to who the expected consumer is, and what type of data is included, and
environment instances and return queue names to hold acknowledgements.
4.4. Can one go point to point, if the situation demands?
A Messaging system abstracts the service provider (the source system) from the consumer
(Market Participant system). Although it is relatively straight forward to build a direct link (a
point-to-point link) between a consumer and provider, these links can lead to an interaction
pattern consisting of multiple point-to-point links that perform specific interactions. This could
turn complex for key performance factors like routing control, logging, monitoring because of the
large number of Market Participants receiving messages from each source system. This
environment is difficult to manage, and would require multiple system changes when a new
message is added or an existing one is changed.
Thus the Messaging System should be used whenever possible. However, time driven notices that
require no or very little latency may require a point-to-point delivery connection. If the protocols
demand performance that is driven by time and this performance cannot be met by the Messaging
system, there should be a tight coupling between the service consumer and provider. In short a
Messaging System is more flexible and easier to manage, but point-to-point may be called for in
specific instances. These will be called out during development of Technical System
Specifications.
Provider A
Consumer A
Provider A
Provider B
Consumer B
Provider B
Provider C
Consumer C
Provider C
Point to Point
Consumer A
Messaging
System
Consumer B
Consumer C
Messaging System
© 2006 Electric Reliability Council of Texas, Inc. All rights reserved.
11
MIS – Alerts and Messaging
___________________________________________________________________________________________________________________________________________
4.5. What happens in case the consumer system goes down during the data
exchange?
In case of the consumer going down, while message data is being dispatched from the queue, the
messaging system persists the ‘lost’ data in the queue. A message is deemed as transacted only
when there is an acknowledgement back from the consumer or the time set for the expiry of the
data is passed. Until then, the data is persisted on a storage device. When the consumer goes
down during a data exchange, there is no acknowledgement back to the queue manager. Thus the
message data is not considered ‘delivered’ and is persisted. When the consumer comes back
online, the message data is re-delivered by the messaging system. After a set point in time, the
persisted data can either move to an archive location or deleted from the queue. This is also the
functionality of the messaging system.
4.6. Who takes care of the message data validation and transformation?
When a consumer requests the provider for specific data, the provider has the responsibility of
sending the data in the contracted format. There is no intermittent ‘Message Brokering’ occurring
between the consumer and the provider. The message is then validated against a pre-defined
XSD. This is the functionality of the Messaging System. If the source data is incorrect and fails
the validation, the Messaging System sends an error to the source system. The error is logged and
the error data is deleted from the queue to avoid duplication of data. If the validation check is
successful, the messaging system dispatches the data to the consumer.
4.7. Are notification messages persisted?
Notification messages are persisted by the Messaging System in a queue until the time associated
with the message expires. The notification message is basically a method to notify the Market
Participant user of certain events. If the deadlines of these events are passed, the messages are
deleted from the notification queue. The only reason of maintaining notification messages in the
queue is to guarantee delivery to the MIS User. If the notification time is past or if the notification
fails to make any sense at that point in time, there is no need to persistence of data.
4.8. What does Asynchronous messaging mean?
Push or asynchronous messages are used to notify participants of various events or conditions.
Asynchronous messaging is operation independent of any timing mechanism or sequence of events,
such as an ordered sequence of messages. In this specification, the term ‘asynchronous’ is
synonymous with push-style messaging where the message is pushed by ERCOT to the Market
Participant. The Market Participant does not request for any alert messages to be delivered to them.
Instead, ERCOT systems push these messages whenever an event occurs that requires these messages
to be delivered to the Market Participants.
© 2006 Electric Reliability Council of Texas, Inc. All rights reserved.
12