Lrs External Web Services Specifications PDF
-
Upload
shafeek-siraj -
Category
Documents
-
view
216 -
download
0
description
Transcript of Lrs External Web Services Specifications PDF
July 9th, 2009
Version: 1.4
PJM LRS
External Web Services
Design Specification
REVISION RECORD
Date Version Description Author(s)
LRS – External Web-Services Design
Confidential and Proprietary Page 3
CONTENTS
1 INTRODUCTION .......................................................................... 6
1.1 PURPOSE ................................................................................................................. 6
1.2 SCOPE ..................................................................................................................... 6
1.3 DEFINITIONS, ACRONYMS, AND ABBREVIATIONS ................................................... 7
1.4 REFERENCES ........................................................................................................... 9
1.5 OVERVIEW .............................................................................................................. 9
1.6 PROGRAM-LEVEL STANDARDS ................................................................................ 9
2 SERVICES ORGANIZATION ..................................................... 11
2.1 COMMON MESSAGE STRUCTURE .......................................................................... 11
2.1.1 Message Header Structure ............................................................................ 11
2.1.2 Request Message Structures ......................................................................... 13
2.1.3 Payload Structures ........................................................................................ 14
2.1.4 Response Message Structures ....................................................................... 16
2.2 COMMON SECURITY IMPLEMENTATION ................................................................ 17
2.2.1 Secure the Transport layer............................................................................ 17
2.2.2 Application Level Authentication .................................................................. 18
2.3 MODELING AND CONVENTIONS ............................................................................ 19
2.3.1 Use of the IEC CIM....................................................................................... 19
2.3.2 Representation of Time ................................................................................. 20
2.3.3 Other Conventions ........................................................................................ 21
2.4 DELIVERY APPROACH ........................................................................................... 21
2.5 TECHNICAL INTEROPERABILITY ............................................................................ 22
2.6 SERVICE LEVEL AGREEMENTS .............................................................................. 23
2.7 AUDITING, MONITORING AND MANAGEMENT ...................................................... 23
2.8 VERSIONING .......................................................................................................... 23
2.9 GOVERNANCE ....................................................................................................... 24
2.10 WEB SERVICE CONFIGURATION STANDARDS ...................................................... 24
3 LOAD RESPONSE OBJECTS .................................................. 25
3.1 LOCATION ............................................................................................................. 25
3.1.1 Location Fields ............................................................................................. 25
3.1.2 Location Diagram ......................................................................................... 27
3.1.3 Location XML Example ................................................................................ 27
3.2 REGISTRATION ...................................................................................................... 28
3.2.1 Registration Fields ........................................................................................ 28
3.2.2 Registration Diagram ................................................................................... 30
3.2.3 Registration XML Example ........................................................................... 30
3.3 EVENT ................................................................................................................... 32
3.3.1 Event Fields .................................................................................................. 32
3.3.2 Event Diagram .............................................................................................. 33
3.3.3 Event XML Example ..................................................................................... 33
3.4 SETTLEMENT ......................................................................................................... 33
3.4.1 Settlement Fields ........................................................................................... 34
LRS – External Web-Services Design
Confidential and Proprietary Page 4
3.4.2 Settlement Diagram ...................................................................................... 35
3.4.3 Settlement XML Example .............................................................................. 35
3.5 PROCESS ............................................................................................................... 36
3.5.1 Process Fields ............................................................................................... 36
3.5.2 Process Diagram .......................................................................................... 38
3.5.3 Process XML Example .................................................................................. 38
3.6 DAILY DATA ......................................................................................................... 39
3.6.1 Daily Data Fields .......................................................................................... 39
3.6.2 Daily Data Diagram ..................................................................................... 39
3.6.3 Daily Data XML Example ............................................................................. 39
3.7 INTERVAL DATA ................................................................................................... 40
3.7.1 Interval Data Fields ...................................................................................... 40
3.7.2 Interval Data Diagram ................................................................................. 40
3.7.3 Interval Data XML Example ......................................................................... 41
3.8 ALERT DATA......................................................................................................... 41
3.8.1 Alert Data Fields........................................................................................... 41
3.8.2 Alert Data Diagram ...................................................................................... 42
3.8.3 Interval Data XML Example ......................................................................... 42
4 LOAD RESPONSE INFORMATION .......................................... 43
4.1 INTERFACES PROVIDED ......................................................................................... 43
4.2 INTERFACES REQUIRED ......................................................................................... 44
4.3 MESSAGE SPECIFICATIONS .................................................................................... 45
4.3.1 Location ........................................................................................................ 45
4.3.2 Registration ................................................................................................... 46
4.3.3 Event ............................................................................................................. 47
4.3.4 Alert............................................................................................................... 48
4.3.5 Settlement ...................................................................................................... 49
4.3.1 Process .......................................................................................................... 50
4.3.2 Measurement Data ........................................................................................ 51
5 LOAD RESPONSE TRANSACTIONS ....................................... 54
5.1 INTERFACES PROVIDED ......................................................................................... 54
5.2 INTERFACES REQUIRED ......................................................................................... 55
5.3 MESSAGE SPECIFICATIONS .................................................................................... 57
5.3.1 Location ........................................................................................................ 57
5.3.2 Registration ................................................................................................... 59
1.3.2 Event ............................................................................................................. 62
1.3.3 Settlement ...................................................................................................... 62
1.6.2 Process .......................................................................................................... 65
1.6.3 Measurement Data ........................................................................................ 66
APPENDIX A: WSDL FOR DR REQUESTS ................................... 68
APPENDIX B: XML SCHEMAS ...................................................... 71
APPENDIX C: PAYLOAD COMPRESSION EXAMPLE ................. 88
LRS – External Web-Services Design
Confidential and Proprietary Page 5
FIGURES
Figure 1 - Message Header Structure ........................................................................... 12
Figure 3 - Request Message Structure .......................................................................... 13 Figure 3 - Message Request Parameters ....................................................................... 14 Figure 4 - Message Payload Container Structure ........................................................ 15 Figure 5 - Response Message Structure ........................................................................ 16
Figure 6 – Example class diagram ................................................................................. 20 Figure 7 - LR Information Request Sequence Diagram .............................................. 43 Figure 8 - LR Transaction Request Sequence Diagram .............................................. 55
LRS – External Web-Services Design
Confidential and Proprietary Page 6
1 Introduction
This document describes the message structure for machine to machine interfaces for
Load Response (LR) Participant applications that need to interact with PJM
Interconnection Load Response System (LRS). The intended audience of this document
is developers that will be integrating PJM customers applications to the PJM
Interconnection Load Response Systems through the use of the interfaces described
within this specification.
Where sections 1 and 2 of this document apply to all interfaces, sections 3 and beyond
describe specific groupings of interfaces. The appendices provide XML Schemas,
WSDLs and additional examples.
The interfaces and related interactions described by this document define the externally-
visible (black box view) perspective of the services provided by this project. It is the
intent of this specification and interface architecture to shield PJM Customers from the
details of systems integration internal to PJM.
1.1 Purpose
The interfaces described by this document are intended to be used by PJM Clients for
machine to machine integration. This document is intended to provide all the details of
the message structures and technical interoperability standards required for the machine
to machine interface.
1.2 Scope
The scope of this document is to describe web services provided for integration by PJM
Customers from the perspective of external integration. This document has program level
scope as related to web services that would be used by PJM Customers for machine to
machine interaction with PJM Demand Response applications as detailed in an agreed list
of interfaces to be managed by the project. The intent of this design is to leverage the
integration layer (IL) to expose web services needed for external integration by PJM
Customers.
The following are specifically outside the scope of this document:
Interactions with application User Interfaces (UI)
Reports that might utilize the web-services framework
Asynchronous web-services notifications or alerts
Valid runtime data codes (zones, weather stations, organization names, etc)
Business rules regarding read/write privileges for objects, organizations and users
LRS – External Web-Services Design
Confidential and Proprietary Page 7
1.3 Definitions, Acronyms, and Abbreviations
Term or
Acronym
Definition
AC2 Advanced Control Center, a PJM initiative
AJAX Asynchronous Javascript and XML
Alert A message sent to a user to indicate a condition where action may be
required, commonly communicated using e-mail
API Application Programming Interface
AS Ancillary service market
BPM Business Process Management, where Savvion is the BPM engine used
within DRBizNet for the management of potentially long running,
multi-user workflows
CBL Customer base load
CSP Curtailment Service Provider
CSV Comma separated value format
DA Day ahead market
DDL Database Definition Language, used to define relational database
schemas
DLC Direct load control
DMZ De-Militarized Zone, a network partition
DR Demand response
DSR Demand side response
EDC Electric Distribution Company
eMkt Short form of eMarket, the PJM Markets Management System
ESB Enterprise Service Bus, used for the implementation of AC2
eSuite PJM web-based user interface for market participants
Event An invocation of a DR program on a given day for a defined time
period
HE Hour ending, a value typically in the range 1-24
HTTP Hyper-Text Transfer Protocol, and IETF standard
HTTP/S HTTP using secured sockets
IETF Internet Engineering Task Force
ISO Independent System Operator
JDBC Java Database Connectivity
LDAP Lightweight Directory Access Protocol
LMP Locational marginal price, usually identified at a PNode
LSE Load Serving Entity
Location A place that can be metered and registered for participation in a DR
program
LRS Load Response System, which will be re-implemented using DRBizNet
MSET PJM Market Settlement System
MSRS New database for PJM Market Settlement System
LRS – External Web-Services Design
Confidential and Proprietary Page 8
NERC National Energy Regulatory Commission
Orchestration Within DRBizNet TIBCO is used for the orchestration of service,
periodic and integration processes
PJM An ISO
PNode Pricing node
Program Demand response program, can be defined using emergency or
economic rules
RBAC Role-based access control
RDBMS Relational database management system, e.g. Oracle
Registration The process by which a customer location is registered for a specific
DR program
RPM Reliability Pricing Model
RSS Remote Syndication Service
RT Real-time market
SAA Symmetric additive adjustment, a method for calculating CBLs
Self Schedule
Settlement A document that is generated as the result of an event that provides the
information required to initiate payment processing, including the
amount that is owed
SMS Short Messaging System, used for short text messages to cell phones
SMTP Simple Mail Transfer Protocol, an IETF standard used for e-mail
SOA Service-Oriented Architecture
SOAP Simple object access protocol, based upon XML
SP Stored Procedure, where capabilities and syntax are specific to a
database product
SQL Structured Query Language, as defined as an ANSI standard and often
extended by database products
UDS PJM Unit Dispatch System
UML Unified Modeling Language
VOIP Voice over IP, within the context of LRS requirements the intent is to
provide an interface to a telephony infrastructure
W3C Worldwide Web Consortium
WS Web Services
WS-* Used to designate web services standards defined by the W3C
WS-I WS-I Basic Profile 1.0 –
http://www.ws-i.org/Profiles/BasicProfile-1.0-2004-04-16.html
WSA Weather sensitive adjustment, a method for calculating CBLs
WSDL Web Services Definition Language
XML Extensible Markup Language
XSD XML Schema, used to define the structure of XML documents
XSL XML Stylesheet Language, used to transform XML documents
LRS – External Web-Services Design
Confidential and Proprietary Page 9
1.4 References
Artifact Definition
External Interfaces
Security Design
Specification
Detailed security design for external interfaces. This is a companion document to the External Interfaces Conceptual
design.
XSDs Specific message structure and element details.
Additional references to related standards are described in section 1.6.
1.5 Overview
This document focuses on the external interface design and related interface definitions
from all perspectives except for security, which is described in detail in a companion
document. The interfaces are to be provided using web services, where a rationale is
provided in subsequent sections.
1.6 Program-level Standards
In general, the design described by this document will leverage web services and related
security standards as defined by the World-Wide Web Consortium (W3C) and OASIS.
Program-level standards include those related to security, as well as basic web service
standards including:
XML
XML Schema
XPath
XSL
SOAP
Web Services
WSDL
These are described in the companion security design document. W3C standards can be
freely accessed from http://www.w3.org.
Another key program standard is the IEC Common Information Model (CIM), as defined
by IEC 61970-301. This is used to define models used by PJM, which are exchanged
using IEC 61970-501. It will also be leveraged by this design for the definition of
messages used for interfaces. There is also a standard for message structures defined by
IEC 61968-1. There standards can be purchased from the IEC web site at
http://www.iec.ch. Materials related to IEC standards, including the CIM model it self
LRS – External Web-Services Design
Confidential and Proprietary Page 10
can be freely obtained from the UCA International Users Group SharePoint at
http://sharepoint.ucausers.group.org/CIM.
There are several key Internet Engineering Task Force references. These include:
Internet Engineering Task Force RFC 2828: Internet Security Glossary
Internet Engineering Task Force RFC 2119: Key words to indicate RFC
requirement levels
Internet Engineering Task Force RFC 2246: Transport Layer Security (TLS)
Internet Engineering Task Force RFC 3275: XML Digital Signature and
Processing
IETF documents can be freely obtained from http://www.ietf.org.
OASIS standards can be freely obtained from http://www.oasis-open.org.
The definition of timestamps is specified by ISO-8601, with the exception that
timestamps of 24:00:00 are not used for compatibility reasons. This is partly a
consequence of the XML Schema definition for ‘dateTime’, where hour 24 is not
explicitly allowed. There are some implementations of timestamps within software
products that do not correctly handle timestamps of 24:00:00.
ISO standards can be purchased online from a variety of sources including ANSI, at
http://www.ansi.org. Descriptions of ISO-8601 can be freely obtained from other sources
including Wikipedia.
LRS – External Web-Services Design
Confidential and Proprietary Page 11
2 Services Organization The services described by this document are defined using a combination of Web
Services Definition Language (WSDL) and XML Schema. The WSDLs are organized as
follows:
One or more WSDLs defined by PJM, defining operations related to synchronous
request/reply web service messages
In both of the above cases, one or more XML Schemas (XSD) is used to define the
structure of message payloads.
Throughout this document there are diagrams representing XSD structures.
Understanding the diagrams will assist in implementing any services based on these
XSDs. Below is a link which elaborates the details and structures of the XSD diagrams.
http://www.diversitycampus.net/Projects/TDWG-
SDD/Minutes/SchemaDocu/SchemaDesignElements.html
Example WSDL and XSD are provided in the appendices. It is anticipated that these
would be key design artifacts for developers.
2.1 Common Message Structure
Unless otherwise specified, all messages use a common message envelope, where a
predefined structure is used for requests and another structure is used for responses.
This structure is based upon the IEC 61968-1 standard. Messages are constructed
with several sections, including:
Header: required for all messages, using a common structure for all service
interfaces
Request: optional, defining parameters needed to qualify request messages
Reply: Used for response messages to indicate success, failure and error
details
Payload: optional, used to convey message information as a consequence of
the ‘verb’ and ‘noun’ in the message Header. The payload structure provides
options for payload compression.
2.1.1 Message Header Structure
Common to both the request and response messages is a header structure. The header
has several required fields that must be populated, these include:
Verb, to identify a specific action to be taken. There are an enumerated set of
valid verbs, where commonly used values include
LRS – External Web-Services Design
Confidential and Proprietary Page 12
o ‘get’, ‘create’, ‘change’, ‘action’, ‘cancel’, ‘close’ and ‘reply’.
Implementations treats verbs ‘update’ and ‘updated’ as synonyms to ‘change’
and ‘changed’.
Noun: to identify the subject of the action and/or the type of the payload (e.g.
Registration, Notification) if a payload is provided.
Revision: To indicate the revision of the message definition.
Source: identifying the source of the message which should be the ID of the
DR Participant or PJM (typically for reply messages). This should be the
‘short name’ of the submitter.
UserID: Should be supplied as it may be required for some interfaces,
depending upon underlying implementations.
MessageID: If populated on a request, it will be returned on the reply.
Comment: It is never used for any processing-related logic.
The following diagram describes the header structure used for request and response
messages.
Figure 1 - Message Header Structure
LRS – External Web-Services Design
Confidential and Proprietary Page 13
There are several optional fields that may be populated. In the above diagram, the
optional items are represented using dashed borders. If the MessageID is populated
on a request, it will be returned on the reply. The Comment field is never used for any
processing-related logic. The UserID may be used to indicate the person responsible
for initiating a transaction, and will be logged as appropriate, but verification is the
responsibility of the Source system.
In order to identify the DR Participant in a uniform manner, the registered ‘short
name’ of the DR Participant should be supplied as the value of Header/Source. PJM
will verify that this value is consistent with the DR Participant as identified by the
certificate, noting the DUNS number is contained within the certificate.
2.1.2 Request Message Structures
The following diagram describes the structure of a request message that would be
used in conjunction with a WSDL operation.
Figure 2 - Request Message Structure
The RequestMessage can also optionally contain a package with parameters relevant
to the request, called Request. It is likely that different or variant Request packages
may be defined to be used in conjunction with messages for a specific web service
operation. In those cases, the corresponding WSDL and XSD would identify the
optional parameters. The description of the interface (in subsequent sections of this
document) would identify the usage of those parameters. The following is an example
RequestType used in the definition of a Request package that defines some common
parameters used for requests, however it is important to note that these are typically
LRS – External Web-Services Design
Confidential and Proprietary Page 14
application specific. These parameters are most commonly used in conjunction with
‘get’ requests as qualifiers.
Figure 3 - Message Request Parameters
One key use of the RequestType is to avoid the placement of application specific
request parameters in the header or within payload definitions. Also, where a set of
requests that were supported by a specific web service operation had significantly
different requirements for information in the RequestType, it could justify the use of
RequestType variants, where each variant will be used for the definition of messages
for the specific web service operation.
2.1.3 Payload Structures
There are some requests where a Payload must be provided, as would be the case for
a message with a verb of ‘create’ or ‘change’. Payloads are typically XML documents
LRS – External Web-Services Design
Confidential and Proprietary Page 15
that conform to a defined XML schema. There may be cases where a large payload
must be compressed, in the event that it would become very large and otherwise
consume significant network bandwidth. In order to accommodate a variety of
payload format options the following payload structure is used.
Figure 4 - Message Payload Container Structure
In the previous diagram, any type of XML document may be included, using the
XML ‘any’ structure. While this provides options for loose-coupling, specific
complex types defined by XML schemas (XSDs) can be used as well. The WSDL in
the appendix provides an example of this case.
Payloads can also be supplied as XML encoded strings using the ‘Document’ tag,
although this method is less preferred than used of the XML ‘any’.
There are also some cases where a zipped, base64 encoded string is necessary, and
would be passed using the ‘Compressed’ tag. The Gnu Zip compression shall be used
in order to provide compatibility within both Java and Microsoft .Net
implementations. A Java example is provided in Appendix G. Specific examples of
the usage of payload compression would be where:
1. An XML payload, conforming to a recognized XML schema exceeds a
predefined size (e.g. 1MB). This would be very common for large DR
Participant sets of bids, offers, trades or schedules
2. A payload has a non-XML format, such as PDF, Excel spreadsheet, CSV file
or binary image
3. A payload is XML, but has no XML schema and exceeds a predefined size, as
would be the case of a dynamic query that would return an XML result set
When a payload is compressed and base64 encoded, it is stored within the
Payload/Compressed message element as a string.
The format tag can be used to identify specific data formats, such as XML, RDF,
PDF, DOC, CSV, etc. This is especially useful if the payload is compressed. The use
LRS – External Web-Services Design
Confidential and Proprietary Page 16
of this tag is optional, and would typically only be used when the payload is stored
using the Payload/Compressed message element.
The above options provide an alternative to the use of SOAP attachments. SOAP
attachments are more difficult to secure since the SOAP envelope signature signs the
SOAP body but does not sign the attachment. This also requires that the payload is
processed separately from the rest of the SOAP message (e.g. the message is parsed
to extract the payload, and then the payload is parsed and processed). However, we
believe this implementation approach is less complex than using SOAP attachments.
2.1.4 Response Message Structures
The following diagram describes the structure of a response message that would be
used in conjunction with a WSDL operation, as a response to the request message.
Figure 5 - Response Message Structure
LRS – External Web-Services Design
Confidential and Proprietary Page 17
The ReplyCode would be set to ‘ok’ to indicate that the request was successful, otherwise it
would be set to either ‘fatal’ or ’warning’, and one or more Error elements would be provided
to describe the error(s). ‘fatal’ ReplyCode is indicative of an internal error having occurred.
‘warning’ ReplyCode is indicative of an empty result set due to an invalid identifier or a
search returning no data.
The Error message will contain a text string beginning with a 4 digit error code corresponding
to the type of error. At present, these include –
4001 - Unable to process the request {catch-all}
4002 – Authorization error
4003 – Verb-noun combination missing or unknown
4004 – Request-payload missing or unknown
4005 – Parameter missing
4006 – Invalid parameter
4007 – Data validation errors
4008 – Requested ID not found
4009 – Search returns no data
There may also be more specific error information provided within the payload, as in the case
of registration within a Registration container.
If the MessageID was set in the Header for the RequestMessage, the value will be returned in
the Header of the ResponseMessage.
2.2 Common Security Implementation
This section will provide an overview of security from the perspective of
implementation requirements for PJM Customers. PJM Customers MUST take two
basic steps in securing their Web Services Interaction with PJM:
1. Secure the Transport layer
2. Application level Authentication
2.2.1 Secure the Transport layer
The transport layer is secured by deploying Secure Socket Layer (SSL) and Transport
Layer Security (TLS) following these steps:
1. PJM will Implement Server Side Authentication (explained below).
2. PJM will Ensure minimum SSL/TLS security settings
LRS – External Web-Services Design
Confidential and Proprietary Page 18
Note that TLS is an enhanced specification based on SSL. References to SSL refer to
both SSL and TLS.
SSL is a standard mechanism for Web services that is available on virtually all
application servers. This widely used, mature technology, which secures the
communication channel between client and server, will satisfy all of PJM’s use cases
for secure Web Service communications. Since it works at the transport layer, SSL
covers all information passed in the channel as part of a message exchange between a
client and a server, including attachments. Authentication is an important aspect of
establishing an HTTPS connection. Many platforms support the following
authentication mechanisms for Web Services using HTTPS:
The PJM BigIP server (DMZ resident Proxy Server) authenticates itself (via
F5 appliance) to web services clients with SSL and makes its certificate
available (one way web server authentication).
With Web Services, the interaction use case is usually machine to machine; that is, it
is an interaction between two application components with no human involvement.
Machine-to-machine interactions have a different trust model from typical website
interactions. In a machine-to-machine interaction, trust must be established
proactively, since there can be no real-time interaction with a user about whether to
trust a certificate. Ordinarily, when a user interacts with a website via a browser and
the browser does not have the certificate for the site, the user is prompted about
whether to trust the certificate. The user can accept or reject the certificate at that
moment. With Web Services, the individuals involved in the deployment of the Web
Service interaction must distribute the server certificate prior to the interaction
occurrence.
2.2.2 Application Level Authentication
Besides creating a secure communication channel between a client and a Web
Service, PJM Web Service message exchanges require that authentication information
(username and password) be embedded within the SOAP message header.
Application level authentication is done through the following:
Include username and password in the SOAP header.
The Tibco integration layer will perform the initial username/password authentication
against PJM Open_LDAP and it will pass on the authenticated user role information
to the LRS application for authorization validation purposes.
Appendix E provides an annotated example of a SOAP message.
LRS – External Web-Services Design
Confidential and Proprietary Page 19
2.3 Modeling and Conventions
There are several conventions that are used for definitions, data items and information
models. Note that additional values and conventions will be defined as DR
requirements are finalized.
2.3.1 Use of the IEC CIM
Where possible the IEC CIM should be leveraged. The PJM Interconnection project
and related systems use the CIM as a key standard. Examples of leveraging the CIM
for external web services include:
The use of data structures defined by the IEC CIM where appropriate in
payload definitions
CIM naming conventions are used wherever possible, e.g. ClassName,
propertyName
The properties ‘startTime’ and ‘endTime’ are typically used to identify time
intervals, as they are also used within many CIM classes. Instead of using
combinations of start date, start hour and potentially an interval number (e.g.
to represent 15 minute intervals), absolute times should be specified.
The following class diagram describes the structure of CIM Curves,
IrregularIntervalSchedules and RegularIntervalSchedules. These classes are CIM
building blocks, where there are many other classes in the CIM that inherit from these
three basic types of curves and schedules (e.g. PriceCurve).
LRS – External Web-Services Design
Confidential and Proprietary Page 20
Figure 6 – Example class diagram
2.3.2 Representation of Time
The ISO 8601 standard is used to define the representations of time values that are
conveyed through interfaces. This avoids issues related to time zones and daylight
savings time changes.
For timestamps in messages published by PJM would use Eastern prevailing
time, using the following format: 2007-03-27T14:00:00-05:00 (as time
changes from EDT to EST, the -05:00 would change to -06:00)
Timestamps in messages sent to PJM by PJM Customers could use any ISO
8601 compliant timestamp (with the exception of 24:00, as described in
section 1.6)
It is extremely important to note that the use of ISO 8601 timestamps within message
definitions for the external interfaces defined by this document in no way constrains
other representations of time that may include:
User interfaces, where local time or DR hours may be used as desired
Reports, where reports would be generated using an appropriate local time
LRS – External Web-Services Design
Confidential and Proprietary Page 21
Internal integration, where an application may internally require some other
time structure
In some cases it may be desirable to convert between a timestamp and a local time or
a DR hour. This can be readily accomplished using software functions, XSL and/or
XPath expressions. Examples of time conversion using XSL are provided in
Appendix F. Most development environments have a wide variety of APIs that can
also be used for necessary time conversions.
In cases where there are a sequence of startTime and endTime intervals provided (as
in the cases of ResourceStatus or MinimumEnergy structures as examples),
overlapping time intervals are not allowed and will be flagged as an error. Typically
in these cases the endTime for one interval should identically match the startTime for
the next interval.
In cases where a time that is ‘aligned’ with an interval is expected, but not provided
on a request message (e.g. 2008-01-01T01:03:23-06:00), the integration layer may
round the time to the nearest minute. This may result in an error being generated by
the target application if the minute is not a valid interval boundary. In cases where a
time that is aligned with an hour boundary is expected, but not provided on a request
message, the integration layer may round the time to the nearest hour. In this case,
there may be no generation of an error message.
2.3.3 Other Conventions
The following are other conventions that must be followed by this specification:
Within XML definitions, tags should be namespace qualified. For example, a
tag of <tag> should be prefixed by a specific namespace reference, e.g.
<ns:tag>. This will help to eliminate ambiguity. (Note that many examples in
this document are not namespace qualified for brevity and to aid legibility)
Units for power quantities are in kilowatts (KW).
Units for capacity quantities are in kilowatts (KW).
Units for energy quantities are in kilowatt-hours (KWh).
Units for energy prices are in $/KWh.
Trading dates are specified using YYYY-MM-DD, which indicates the
operating day
2.4 Delivery Approach
LRS – External Web-Services Design
Confidential and Proprietary Page 22
In advance of LRS go live and in accordance with agreed schedule and dependencies,
PJM will provide the following:
Interface specifications for web services
Design artifacts, including XML schemas and WSDLs
Source code examples for web service clients
The interface specifications, artifacts and implementation of the sand box
environment will be staged. An iterative implementation approach will be used,
where feedback from each stage will be used to plan subsequent stages.
2.5 Technical Interoperability
There are several strategies that can be employed in order to achieve technical
interoperability with PJM. These include:
Use of open standards
Working group that allows input from PJM Customers on interoperability
issues
The early deployment of a sandbox environment that enables PJM to work
with the PJM Customers to insure interoperability issues are addressed
prior to DR trials
Providing sample Java and .Net web service client code
Deployment of interfaces via the sandbox environment for early testing by
PJM Customers, so that feedback can be provided to PJM
Open standards are a key part of the strategy to achieve technical interoperability.
Standards of particular interest include:
W3C standards
OASIS WS-* standards
IEC Common Information Model and related standards (e.g. IEC 61968-1)
WS-I Basic Profile 1.0
It is very important that the implementation of Web Service interfaces not be
dependent upon any proprietary, third party products. Another key requirement is that
implementation of web service clients must be possible using both Java and .Net
development tools.
More details on technical interoperability will be provided as a consequence of
existing web services provided by PJM, detailed design and experience with the Sand
Box environment.
LRS – External Web-Services Design
Confidential and Proprietary Page 23
2.6 Service Level Agreements
Different categories of Web Services will have different service level agreements
(SLAs). The SLAs for some Web Services are directly impacted by the variability in
the amount of data that can be transferred (e.g. large payloads).
The response time periods specified for each interface covered by an SLA typically
will vary to some degree, based upon factors such as network and system loading.
Consequentially, each SLA will be stated in a manner such that each SLA will be
honored Z% of the time.
2.7 Auditing, Monitoring and Management
PJM will perform auditing, monitoring and management for Web Services described
by this specification using common services. Internal auditing by PJM will be used to
track and insure that SLAs are met by PJM. All Web Service requests will be logged
by PJM in order to permit calculations related to SLAs. The signatures supplied on
SOAP messages will be recorded with transactions as a means of non-repudiation of
each transaction.
It is important to recognize that PJM is not responsible for the monitoring and
management of DR Participant software and network connectivity. Therefore PJM
cannot guarantee that notification interfaces provided by PJM Customers are
accessible as needed for timely delivery of notifications.
2.8 Versioning
It is important to recognize that new versions of interfaces may be provided over
time, largely as a consequence of:
Staging of initial implementation
New requirements
Upgrades to vendor products
Wherever possible, interfaces will be evolved through augmentation, where a newer
version of an interface is compatible with a previous version of an interface.
However, this will not always be possible. New versions of interfaces will be
manifested by:
Changes to WSDLs
Changes to XML Schemas
Changes to software implementations
LRS – External Web-Services Design
Confidential and Proprietary Page 24
2.9 Governance
The web service interfaces will be critical to the operations of both PJM and PJM
Customers. The Web Services will evolve for many reasons, especially as the needs
of the DR evolve. Governance policies and processes will need to be defined for the
Web Service lifecycle that provide strict guidelines related to:
Design
Implementation
Testing
Deployment
Management
2.10 Web Service Configuration Standards
PJM will configure its web servers with specific parameters for use of Web Services
by PJM Customers (e.g. for security). PJM Customers will also need to set up Web
Services to handle notifications from PJM. PJM will define specific configuration
details and parameters to be used by PJM Customers.
LRS – External Web-Services Design
Confidential and Proprietary Page 25
3 Load Response Objects
This section describes the data objects used in web-services payloads by the PJM
Load Response system. Use of the fields is typically dependent on the type of
request. This is summarized on the right (1=provided/mandatory, 0=optional,
0|1..n=set, blank=ignored), and defined further in later sections of this document. All
fields are subject to PJM business rules regarding organization (and user) read/write
privileges for each object.
Note: The object and message specifications described in this section are subject to
change based upon final DRBizNet design.
3.1 Location
A Location object is used to describe a specific EDC account used as a resource in a
registration.
3.1.1 Location Fields
The following is a description of all the fields in a Location object.
Field Description Example get create change
ID Location object identifier 282718 1 1
Summary info 1 1 0
Name Descriptive name of location Walmart #2234 1 1 0
CSP Short name of the CSP PECO 1 1
EDC Short name of the EDC PGE 1 1
EDCAccount Account no. at the EDC 2672827273 1 1
Zone Short name of the zone PGE-WEST 1 1
Status Status of the location Active 1
Site info 1 1 0
Address1 Address line 1 273 Main St. 1 1
Address2 Address line 2 Suite 3400 1 0
City City Springfield 1 1
State Two-letter state code NY 1 1
Zip Code 5 or 9 number zip code 39482 1 1
Business Segment Business segment code School 1 1
Pnode Pnode identifier 27382 1 0
Profile info 1 1 0
Energy Loss Factor Decimal loss factor 1.003 1 1 0
LRS – External Web-Services Design
Confidential and Proprietary Page 26
Capacity Loss
Factor
Decimal loss factor 1.003
1 1 0
Retail Rate Decimal retail rate (c/kwh) 20.5 1 1 0
Total Load
Reduction
Decimal value of total load
reduction (kw)
2000
1
Peak Load
Contribution
Decimal value of peak load
contibution (kw)
2000
1 1
Load Multiplier An integer number of sites
(default is 1)
5
1 0 0
Generation Fuel
Type
Fuel type code OIL
1 0 0
Meter
Qualification Date
Date on which the meter was
qualified by PJM
12/1/2008
1
State Qualification
Date
Date on which state
qualification was received
1/1/2010
1
Reduction info 1..n 1..n 0..n
Reduction type Reduction type code HVAC 1 1 0
Reduction value Decimal number of kw of
reduction for this type
40.5
1 1 0
Meter Info 1 1 0
Meter Owner Meter owner code 1 1 1
Allow EDC to
submit data
Boolean whether EDC can
submit data (default is false)
false
1 0 0
Allow LSE to
submit data
Boolean whether LSE can
submit data (default is false)
false
1 0 0
Contact info 0..n 0..n
Interest Type Contact interest code Emergency 1 1
First Name First Name of contact John 1 1
Last Name Last name of contact Smith 1 1
Email Email of contact [email protected] 1 1
Phone Phone number of contact 910-328-1932 1 0
LRS – External Web-Services Design
Confidential and Proprietary Page 27
3.1.2 Location Diagram
3.1.3 Location XML Example
<Location>
<id>String</id>
<summaryInfo>
<name>String</name>
<CSP>
<name>String</name>
</CSP>
<EDC>
<name>String</name>
<accountNo>String</Account>
</EDC>
<zone>String</zone>
<status>String</status>
</summaryInfo>
<siteInfo>
<address>
<address1>String</address1>
<address2>String</address2>
<city>String</city>
<state>String</state>
<zipCode>String</zipCode>
</address>
<businessSegment>String</businessSegment>
<pNode>String</pNode>
</siteInfo>
<profileInfo>
<energyLossFactor>3.14159E0</energyLossFactor>
<capacityLossFactor>3.14159E0</capacityLossFactor>
<retailRate>3.14159E0</retailRate>
<loadReduction>3.14159E0</loadReduction>
<peakLoadContribution>3.14159E0</peakLoadContribution>
<loadMultiplier>0</loadMultiplier>
<generationFuelType>String</generationFuelType>
<meterQualificationDate>1967-08-13</meterQualificationDate>
<stateQualificationDate>1967-08-13</stateQualificationDate>
</profileInfor>
<reductionInfo>
LRS – External Web-Services Design
Confidential and Proprietary Page 28
<reductionType>HVAC</reductionType>
<reductionValue>3.14159E0</reductionValue>
</reductionInfo>
<meterInfo>
<meterOwner>EDC Meter</meterOwner>
<allowEDCtoSubmitData>false</allowEDCtoSubmitData>
<allowLSEtoSubmitData>false</allowLSEtoSubmitData>
</meterInfo>
<contactInfo>
<interestType>Flat Fixed</interestType>
<firstName>String</firstName>
<lastName>String</lastName>
<email>String</email>
<phone>String</phone>
</contactInfo>
</Location>
3.2 Registration
A Registration object is used to describe a collection of locations enrolled in a
specific DR program for a period of time.
3.2.1 Registration Fields
The following is a description of all the fields in a Registation object.
Field Description Example get create change
ID Registration object identifier 2637 1 1
Summary info 1 1 0
Reference Reference name of the
registration
R2637
1
Name Descriptive name of
registration or customer
Walmart
1 1 0
Type Type of registration Economic 1
Program Specific program name Economic
Energy 1 1
Start date Effective start date 10/24/2008 1 1
End date Termination date 10/24/2009 1 1
CSP Short name of the CSP PECO 1 1
EDC Short name of the EDC PGE 1 1
LSE Short name of the LSE ESI 1 1
Zone Short name of the zone PGE-WEST 1 1
Status Status of the location New 1
Location info 1..n 1..n 0..n
Location ID Unique location id 29281 1 1 1
EDCAccount EDC Account number 267827273 1
Energy Loss Factor Decimal loss factor 1.003 1 0
Capacity Loss
Factor
Decimal loss factor 1.003
1 0
LRS – External Web-Services Design
Confidential and Proprietary Page 29
Retail Rate Decimal retail rate (c/kwh) 20.5 0
Load Reduction Decimal value of location load
reduction (kw)
2000
1
Peak Load
Contribution
Decimal value of peak load
contibution (kw)
2000
1
Meter Qualification
Date
Date on which the meter was
qualified by PJM
12/1/2008
1
State Qualification
Expiry
Date on which state
qualification expires
1/1/2010
1
Energy info 0 0 0
Energy Type Energy Type Economic 1
Load Reduction Decimal value of aggregate
load reduction (kw)
2000
1
Energy Loss Factor Decimal loss factor (weighted
average of locations)
1.003
1
Strike Price Decimal of $/MW 150.25 1 0 0
Shutdown Costs Decimal of $ for shutdown 32000 1 0 0
Contract Type Contract type RT Index 1 1 0
Price Node Short name of the pricing (aka
aggregate) pnode
PGE-WEST
1 1 0
Retail Rate Decimal retail rate (c/kwh) 20.5 1 1 0
Rate Name Name describing the retail rate
of the site
E-1
1 0 0
Description Text description (or comment)
of the rate
‘Note: rate
changes on Apr
1 to 22.0
c/kwh’ 1 0 0
Emergency Emergency participation flag false 1
SelfSchedule Self-schedule participation flag true 1
DayAhead Day-ahead participation flag false 1
RealTime Real-time participation flag true 1
CBL Method CBL code Standard3 1 1
Weather Station Weather station code PHL 1
AS info 0
SynchReserve SR participation flag true 1
ScheduledReserve DASR participation flag false 1
Regulation Regulation participation flag false 1
BatchLoad Batch load flag false 1
Capacity info 0 0 0
Capacity Type Capacity type code DR 1
Lead Time Lead time (Long or Short) Long 1 1 0
Zone Area Zone area codes PGE-WEST 1 1 0
LRS – External Web-Services Design
Confidential and Proprietary Page 30
RPM Resource ID RPM bid award id (string) 3829282 1 1 0
Measurement
Method
Measurement type code FSL
1 1 0
Capacity Loss
Factor
Decimal loss factor (weighted
average of locations)
1.003
1
Peak Load
Contribution
Decimal value of peak load
contibution (kw)
300.5
1
ManagedLoad Decimal of FSL/GLD/DLC
amount
200.3
1 1 0
Multiplier Integer multiple number of
non-interval sites (default 1)
1
1 0 0
Nominal ICAP Decimal value of nominated
load
200.3
1
Other info 1 0 0
AllowEDCModify Allow EDC to modify flag false 1 0 0
AllowLSEModify Allow LSE to modify flag false 1 0 0
Hold Scheduling Hold scheduling flag false 1
Hold Settlements Hold settlements flag false 1
Comments Comments This is long
text 1 0 0
3.2.2 Registration Diagram
3.2.3 Registration XML Example
<Registration>
<id>String</id>
<summaryInfo>
<reference>String</reference>
<name>String</name>
LRS – External Web-Services Design
Confidential and Proprietary Page 31
<type>String</type>
<program>Economic-2008</program>
<startDate>1967-08-13</startDate>
<endDate>1967-08-13</endDate>
<CSP>
<name>String</name>
</CSP>
<EDC>
<name>String</name>
</EDC>
<LSE>
<name>String</name>
</LSE>
<zone>String</zone>
<status>String</status>
</summaryInfo>
<locationInfo>
<locationID>String</locationID>
<accountNo>String</accountNo>
<energyLossFactor>3.14159E0</energyLossFactor>
<capacityLossFactor>3.14159E0</capacityLossFactor>
<retailRate>3.14159E0</retailRate>
<loadReduction>3.14159E0</loadReduction>
<peakLoadContribution>3.14159E0</peakLoadContribution>
<siteMultiplier>1</siteMultiplier>
<generationFuelType>String</generationFuelType>
<meterQualificationDate>1967-08-13</meterQualificationDate>
<stateQualificationDate>1967-08-13</stateQualificationDate>
</locationInfo>
<energyInfo>
<energyType>String</energyType>
<loadReduction>String</loadReduction>
<energyLossFactor>3.14159E0</energyLossFactor>
<strikePrice>3.14159E0</strikePrice>
<shutdownCosts>3.14159E0</shutdownCosts>
<contractType>String</contractType>
<priceNode>String</priceNode>
<retailRate>3.14159E0</retailRate>
<rateName>String</rateName>
<rateDescription>String</rateDescription>
<emergency>true</emergency>
<selfSchedule>true</selfSchedule>
<dayAhead>true</dayAhead>
<realTime>true</realTime>
<CBLMethod>String</CBLMethod>
<weatherStation>String</weatherStation>
</energyInfo>
<ASInfo>
<synchronizedReserve>true</synchronizedReserve>
<scheduledReserve>true</scheduledReserve>
<regulation>true</regulation>
<batchLoad>true</batchLoad>
</ASInfo>
<capacityInfo>
<capacityType>String</capacityType>
<leadTime>true</leadTime>
<zoneArea>String</zoneArea>
<RPMResourceID>String</RPMResourceID>
<measurementMethod>String</measurementMethod>
<capacityLossFactor>3.14159E0</capacityLossFactor>
<peakLoadContribution>3.14159E0</peakLoadContribution>
<managedLoad>3.14159E0</managedLoad>
<multiplier>3.14159E0</multiplier>
<nominalICAP>3.14159E0</nominalICAP>
</capacityInfo>
<otherInfo>
<allowEDCtoModify>true</allowEDCtoModify>
<allowLSEtoModify>true</allowLSEtoModify>
<holdScheduling>false</holdScheduling>
<holdSettlements>false</holdSettlements>
<comment>String</comment>
LRS – External Web-Services Design
Confidential and Proprietary Page 32
</otherInfo>
</Registration>
3.3 Event
An Event object is used to describe a specific DR event – emergency, load
management, day-ahead, real-time, self-schedule, ancillary services, and outages.
3.3.1 Event Fields
The following is a description of all the fields in an Event object.
Field Description Example get
ID Event object identifier 2637 1
Summary info 1
Event Date Operating date of event start 1/24/2009 1
Event Type Type of event Emergency
Energy 1
Start time Operating start time of event 1/24/2009 1:20 1
End time Operating end time of event 1/25/2009 2:40 1
Description Description of event Line outage in
PECO 1
Short lead Short lead flag false 1
Long lead Long lead flag true 1
Status Status of the event Completed 1
Zone info 0..n
Zone Short name of all affected
zones
PGE-WEST
1
Registration info 0..n
Registration ID Unique registration id 2637 1
Reference Reference name of the
registration
R2637
1
Name Descriptive name of
registration or customer
Walmart
1
Type Type of registration Emergency 1
Program Specific program name DR Full 1
CSP Short name of the CSP PECO 1
EDC Short name of the EDC PGE 1
LSE Short name of the LSE ESI 1
Zone Short name of the zone PGE-WEST 1
LRS – External Web-Services Design
Confidential and Proprietary Page 33
3.3.2 Event Diagram
3.3.3 Event XML Example
<Event>
<id>String</id>
<summaryInfo>
<eventDate>1967-08-13</eventDate>
<eventType>String</eventType>
<startTime>2001-12-17T09:30:47.0Z</startTime>
<endTime>2001-12-17T09:30:47.0Z</endTime>
<description>String</description>
<shortLead>true</shortLead>
<longLead>true</longLead>
<status>String</status>
</summaryInfo>
<zoneInfo>
<zone>String</zone>
</zoneInfo>
<registrationInfo>
<registrationId>String</registrationId>
<reference>String</reference>
<name>String</name>
<type>String</type>
<program>String</program>
<CSP>
<name>String</name>
</CSP>
<EDC>
<name>String</name>
</EDC>
<LSE>
<name>String</name>
</LSE>
<zone>String</zone>
</registrationInfo>
</Event>
3.4 Settlement
A Settlement object is used to describe a DR event settlement or compliance
submission for a specific registration.
LRS – External Web-Services Design
Confidential and Proprietary Page 34
3.4.1 Settlement Fields
The following is a description of all the fields in a Settlement object.
Field Description Example get create change
ID Settlement object identifier 2637 1 1 1
Summary info 1
Event Date Operating date of event start 1/24/2009 1
Settlement Type Type of settlement Economic
Energy 1
Compliance Only Compliance only flag false 1
Start time Operating start time of event 1/24/2009 1:20 1
End time Operating end time of event 1/25/2009 2:40 1
CBLMethod CBL Code Standard3 1
Valid As Of Date Date the cbl calculation was
last run
2009-04-28
1
Validation Message Message from the last run Baseline and
reduction
calculated
successfully 1
Validation Status Status of last CBL run Success 1
Bill Date Bill cycle date 2/1/2009 1
Adjustment Adjustment flag false 1 1
Status Status of the settlement Pending 1
Registration info 1
Registration ID Unique registration id 2637 1
Reference Reference name of the
registration
R2637
1
Name Descriptive name of
registration or customer
Walmart
1
Type Type of registration Emergency 1
Program Specific program name DR Full 1
CSP Short name of the CSP PECO 1
EDC Short name of the EDC PGE 1
LSE Short name of the LSE ESI 1
Zone Short name of the zone PGE-WEST 1
Settlement info 1..n 1..n 1..n
Event Hour Hour ending 15 1 1 1
GMT Hour GMT Hour beginning 1/24/2009
14:00 1
Reduction Hour Flag indicating whether to
settle
true
1 0 0
Market Type Market type indicator RT 1
Baseline Decimal baseline value (kw) 340.2 1
LRS – External Web-Services Design
Confidential and Proprietary Page 35
Load Decimal load value (kw) 220.2 1
Reduction Decimal reduction value (kw) 120.2 1
Rate Decimal retail rate (c/kw) 20.2 1 0 0
Loss Factor Decimal loss factor 1.003 1 0 0
Scheduled Decimal scheduled value (kw) 220.2 1
Dispatched Decimal dispatched value (kw) 120.2 1
DA Price Decimal DA LMP $/kwh 87.23 1
RT Price Decimal RT LMP $/kwh 87.23 1
Totals info 0
Total Reduction Decimal total load reduction 2400.2 1
AverageRate Decimal average retail rate 20.4 1
AverageLoss Decimal average loss factor 1.002 1
Other info 1 0
AllowEDCModify Allow EDC to modify flag false 1 0
AllowLSEModify Allow LSE to modify flag false 1 0
Comments Comments long text 1 0
3.4.2 Settlement Diagram
3.4.3 Settlement XML Example
<Settlement>
<id>String</id>
<summaryInfo>
<eventDate>1967-08-13</eventDate>
<settlementType>Economic Energy</settlementType>
<complianceOnly>true</complianceOnly>
<startTime>2001-12-17T09:30:47.0Z</startTime>
<endTime>2001-12-17T09:30:47.0Z</endTime>
<CBLMethod>String</CBLMethod>
<billDate>1967-08-13</billDate>
<adjustment>true</adjustment>
<status>String</status>
LRS – External Web-Services Design
Confidential and Proprietary Page 36
</summaryInfo>
<registrationInfo>
<registrationId>String</registrationId>
<reference>String</reference>
<name>String</name>
<type>String</type>
<program>String</program>
<CSP>
<name>String</name>
</CSP>
<EDC>
<name>String</name>
</EDC>
<LSE>
<name>String</name>
</LSE>
<zone>String</zone>
</registrationInfo>
<settlementInfo>
<eventHour>0</eventHour>
<GMTHour>2001-12-17T09:30:47.0Z</GMTHour>
<reductionHour>true</reductionHour>
<marketType>String</marketType>
<baseline>3.14159E0</baseline>
<load>3.14159E0</load>
<reduction>3.14159E0</reduction>
<rate>3.14159E0</rate>
<lossFactor>3.14159E0</lossFactor>
<scheduled>3.14159E0</scheduled>
<dispatched>3.14159E0</dispatched>
<DAPrice>3.14159E0</DAPrice>
<RTPrice>3.14159E0</RTPrice>
</settlementInfo>
<totalInfo>
<totalReduction>3.14159E0</totalReduction>
<averageRate>3.14159E0</averageRate>
<avergeLoss>3.14159E0</avergeLoss>
</totalInfo>
<otherInfo>
<allowEDCtoModify>true</allowEDCtoModify>
<allowLSEtoModify>true</allowLSEtoModify>
<comment>String</comment>
</otherInfo>
</Settlement>
3.5 Process
A Process object is used to describe a task, set of tasks, and task completions related
to work-flow processes within the system.
3.5.1 Process Fields
The following is a description of all the fields in a Process object.
Field Description Example get change
ID Process identifier 2637 1 1
Summary info 1
Process name Type of process Approve
Registration 1 1
Process owner Organization who initiated the
process
AEP
1
LRS – External Web-Services Design
Confidential and Proprietary Page 37
Start Date Date process began 1/21/2009 1
End Date Date process ended (if ended) 1/22/2009 1
Status Status of process Denied 1
Object id Id of related object 18278 1 1
Object type Object type (Registration,
Settlement)
Registration
1 1
Task info 1..n 1
Task name Name of task EDC Review 1 1
Task org Organization the task is
assigned
PECO
1
Task user User the task is assigned rmick 1
Task priority Priority of task 2 1
Task started Date/time task was created 11/6/2008 1
Task due Date/time task is due 11/8/2008 1
Task completed Date/time task was completed
(null if open)
11/10/2008
1
Task status Status of task Denied 1
Reasons Comma separated list of
reasons
Invalid meter
0
Comments Comment from task user Wrong number 0
Decision 0..n 1
Decision name Name of Decision Deny 1 1
Decision \ Reasons 0..n 0..n
Reason name Name of reason Invalid meter 1 1
Attributes 0..n
Attribute Name of attribute NewEndDate 1
Attribute Type Data type of attribute DATETIME 1
Initial Value String value representing the
attribute
‘12/31/2009’
1
Value String value representing the
attribute
‘12/31/2009’
1
Readonly Flag indicating read-only true 1
LRS – External Web-Services Design
Confidential and Proprietary Page 38
3.5.2 Process Diagram
3.5.3 Process XML Example
<Process>
<id>String</id>
<summaryInfo>
<processName>String</processName>
<processOwner>String</processOwner>
<startDate>1967-08-13</startDate>
<endDate>1967-08-13</endDate>
<status>String</status>
<objectID>String</objectID>
<objectType>String</objectType>
</summaryInfo>
<taskInfo>
<taskName>String</taskName>
<taskOrg>String</taskOrg>
<taskUser>String</taskUser>
<taskPriority>0</taskPriority>
<taskStarted>1967-08-13</taskStarted>
<taskDue>1967-08-13</taskDue>
<taskCompleted>1967-08-13</taskCompleted>
<taskStatus>String</taskStatus>
<reasons>String</reasons>
<comments>String</comments>
</taskInfo>
<decisionInfo>
<decisionName>String</decisionName>
<decisionReasons>
<reasonName>String</reasonName>
</decisionReasons>
</decisionInfo>
<attributeInfo>
<attribute>String</attribute>
<attributeType>String</attributeType>
<initialValue>String</initialValue>
<value>String</value>
<readOnly>true</readOnly>
</attributeInfo>
</Process>
LRS – External Web-Services Design
Confidential and Proprietary Page 39
3.6 Daily Data
A Daily Data object is used to describe an entire operating day of measurement data
for a given location of a specific measurement type. Currently this is used for 24 (or
23 or 25) intervals of measurement data, typically as part of settlements.
3.6.1 Daily Data Fields
The following is a description of all the fields in a Daily Data object.
Field Description Example get create
Summary info 1 1
Location id Unique id of location 12837 1 1
Registration id Unique id of registration 3526 0
EDC EDC short name PECO 1
EDC Account EDC account # PEC28329 1
Measurements 1 1
Datestamp Operating Date 10/7/2008 1 1
Type Enumerated type of submission DailyLoad 1 1
UOM Enumerated type of data KW 1 1
Intervals Number of intervals provided
(typically 24 – 23 or 25 also
allowed)
24
1 1
Values Comma separated string of
#interval values
273.2,284.5,,,
1 1
Latest Latest submission flag true 1
Submitted by User name of submitter mday 1
Submitted date Date-time of submission 10/8/2008 5:30 1
3.6.2 Daily Data Diagram
3.6.3 Daily Data XML Example
<DailyData>
<summaryInfo>
<locationId>String</locationId>
<registrationId>String</registrationId>
<EDC>
LRS – External Web-Services Design
Confidential and Proprietary Page 40
<name>String</name>
<accountNo>String</account>
</EDC>
</summaryInfo>
<measurementInfo>
<dateStamp>1967-08-13</dateStamp>
<type>String</type>
<UOM>String</UOM>
<intervals>0</intervals>
<values>3.14159E0</values>
<latest>true</latest>
<submittedBy>String</submittedBy>
<submittedate>2001-12-17T09:30:47.0Z</submittedate>
</measurementInfo>
</DailyData>
3.7 Interval Data
An Interval Data object is used to describe a random interval of measurement data for
a given location of a specific measurement type. Currently this is used for event
compliance submissions.
3.7.1 Interval Data Fields
The following is a description of all the fields in a Interval Data object.
Field Description Example get create
Summary info 1 1
Location id Unique id of location 12837 1 1
Registration id Unique id of registration 3526 0
EDC EDC short name PECO 1
EDC Account EDC account # PEC28329 1
Measurements 1..n 1..n
Timestamp Operating time 10/7/08 5:23 1 1
Type Enumerated type of submission MinuteLoad 1 1
UOM Enumerated type of data KW 1 1
Value Value for interval 273.4 1 1
Latest Latest submission flag (1=
latest, otherwise 0)
true
1
Submitted by User name of submitter mday 1
Submitted date Date-time of submission 10/8/2008 5:30 1
3.7.2 Interval Data Diagram
LRS – External Web-Services Design
Confidential and Proprietary Page 41
3.7.3 Interval Data XML Example
<IntervalData>
<summaryInfo>
<locationId>String</locationId>
<registrationId>String</registrationId>
<EDC>
<name>String</name>
<accountNo>String</acountNo>
</EDC>
</summaryInfo>
<measurementInfo>
<timestamp>2001-12-17T09:30:47.0Z</timestamp>
<type>String</type>
<UOM>String</UOM>
<value>3.14159E0</value>
<latest>true</latest>
<submittedBy>String</submittedBy>
<submittedDate>2001-12-17T09:30:47.0Z</submittedDate>
</measurementInfo>
</IntervalData>
3.8 Alert Data
3.8.1 Alert Data Fields
The following is a description of all the fields in an Alert Data object.
Field Description Example get
Subject Subject line of Alert 1
Message Message body of the alert 1
Object Type The object type the alert applies
to (Registration. Settlement,
Event)
Registration
1
Object Id The ID of the object the
message pertains to
200
1
Expiration Date The expiration date of the alert 10/7/08 5:23 1
Urgent Flag indicating if the message
is urgent
False
1
LRS – External Web-Services Design
Confidential and Proprietary Page 42
3.8.2 Alert Data Diagram
3.8.3 Interval Data XML Example
<Alert>
<subject>subject</subject>
<message>message</message>
<objectType>objectType</objectType>
<objectId>0</objectId>
<expirationDate>2001-01-01</expirationDate>
<urgent>true</urgent>
</Alert>
LRS – External Web-Services Design
Confidential and Proprietary Page 43
4 Load Response Information The purpose of the LRInformation Service is to support interfaces required for
retrieving Load Response (LR) related information. These are read-only interfaces, as
opposed to transactional interfaces.
Note: The interfaces described in this section are subject to change based upon
final DRBizNet design.
4.1 Interfaces Provided
Specific interfaces using specific combinations of verbs and nouns (i.e. payload
types) are defined to permit a DR participant to programmatically access DR
information. The verb to be used for requests would in all cases be ‘get’. The noun
would identify the type of information being requested. Each request could use a
message ‘Request’ package to specify one or more parameters that would qualify the
request.
The processing sequence is shown in the following sequence diagram.
LRS Users Web
Services ClientBigIP Proxy LRS Application
1: Request (get)
5: Authorize
6: Reply
7: Response (reply, noun, payload)
4: Invoke LRS API
3: Authentication
Integration
Tibco Layer
2:: Request (get)
8: Response (reply, noun, payload)
HTTPS
PJM LRS SYSTEM
HTTP
HTTPS
HTTP
CSP/EDC/LSE WS Client PJM DMZ
Figure 7 - LR Information Request Sequence Diagram
LRS – External Web-Services Design
Confidential and Proprietary Page 44
4.2 Interfaces Required
The messages for LR information requests would use the following message fields:
Message Element Value
Header/Verb Get
Header/Noun Name of payload type
Header/Source DR participant ID
Header/UserID Optional: ID of user
Request/? Optional: Other request parameters may be specified as needed
Payload Message payload data with type defined by Noun
The corresponding response messages would use the following message fields:
Message Element Value
Header/Verb Reply
Header/Noun Defined payload type name
Header/Source PJM
Reply/ReplyCode Reply code, success=OK, error=ERROR or FATAL
Reply/Error May be any number of error messages
Payload Defined payload type
In the cases of payloads that would otherwise exceed 1 megabyte, the payloads would
be zipped, base64 encoded and stored within the ‘Payload/Compressed’ tag.
LRS – External Web-Services Design
Confidential and Proprietary Page 45
4.3 Message Specifications
LRS Information Payload definitions are dataset specific and are described in this section.
4.3.1 Location
Location related information use cases include -
Description Verb Noun Input Output
Get location get location Request/ID=
location id
Payload=location
object
Search locations
by name or edc
account number
get location Request/Match=
string
Payload=set of
location objects
The Get Location interface provides the means for a DR participant to obtain
Location Information. The following parameters are specified in the RequestMessage:
Message Element Value
Header/Verb get
Header/Noun location
Header/Source LR participant ID
Header/UserID Optional: ID of user
Request/ID Optional: Location ID of interest
Request/Match Optional: Location partial name or EDC Account number
The corresponding response messages would use the following message fields:
Message Element Value
Header/Verb reply
Header/Noun location
Header/Source PJM
Reply/ReplyCode Reply code, success=ok, error=fatal or
LRS – External Web-Services Design
Confidential and Proprietary Page 46
warning
Reply/Error Error message, if error encountered
Payload Location(s)
4.3.2 Registration
Registration related information use cases include -
Description Verb Noun Input Output
Get registration get registration Request/ID=
registration id
Payload=
registration object
Search
registrations
active within a
date range
get registration Request/StartTime=
search start date
Request/EndTime=
search end date
Payload= set of
registration objects
The Get Registration interface provides the means for a DR participant to obtain
Registration Information. The following parameters are specified in the
RequestMessage:
Message Element Value
Header/Verb get
Header/Noun registration
Header/Source DR participant ID
Header/UserID Optional: ID of user
Request/ID Optional: Registration ID of interest
Request/StartTime Optional: Start Time of interest
Request/EndTime Optional: End Time of interest
The corresponding response messages would use the following message fields:
Message Element Value
Header/Verb reply
Header/Noun registration
LRS – External Web-Services Design
Confidential and Proprietary Page 47
Header/Source PJM
Reply/ReplyCode Reply code, success=ok, error=fatal or warning
Reply/Error Error message, if error encountered
Payload Registration(s)
4.3.3 Event
Event related information use cases include -
Description Verb Noun Input Output
Get event get event Request/ID=
event id
Payload=
event object
Search events
within a date
range
get event Request/StartTime =
search start date
Request/EndTime=
search end date
Payload= set of
event objects
The Get Event interface provides the means for a DR participant to obtain Event
Information. The following parameters are specified in the RequestMessage:
Message Element Value
Header/Verb get
Header/Noun event
Header/Source DR participant ID
Header/UserID Optional: ID of user
Request/ID Optional: Event ID of interest
Request/StartTime Optional: Start Time of interest
Request/EndTime Optional: End Time of interest
The corresponding response messages would use the following message fields:
Message Element Value
LRS – External Web-Services Design
Confidential and Proprietary Page 48
Header/Verb reply
Header/Noun event
Header/Source PJM
Reply/ReplyCode Reply code, success=ok, error=fatal or warning
Reply/Error Error message, if error encountered
Payload Event(s)
4.3.4 Alert
Alert related information use cases include -
Description Verb Noun Input Output
Get alert get alert Request/StartTime =
search start date
Request/EndTime=
search end date
Payload=
alert object(s)
The Get Alert interface provides the means for a DR participant to obtain Alert
Information. The following parameters are specified in the RequestMessage:
Message Element Value
Header/Verb get
Header/Noun alert
Header/Source DR participant ID
Header/UserID Optional: ID of user
Request/ID n/a
Request/StartTime Required: Start Time of issued date
Request/EndTime Required: End Time of issued date
The corresponding response messages would use the following message fields:
LRS – External Web-Services Design
Confidential and Proprietary Page 49
Message Element Value
Header/Verb reply
Header/Noun alert
Header/Source PJM
Reply/ReplyCode Reply code, success=ok, error=fatal or warning
Reply/Error Error message, if error encountered
Payload Event(s)
4.3.5 Settlement
Settlement related information use cases include -
Description Verb Noun Input Output
Get settlement get settlement Request/ID=
settlement id
Payload=
settlement object
Search
settlements within
a date range
get settlement Request/StartTime=
search start date
Requent/EndTime=
search end date
Payload= set of
settlement objects
The Get Settlement interface provides the means for a DR participant to obtain
Settlement Information. The following parameters are specified in the
RequestMessage:
Message Element Value
Header/Verb get
Header/Noun settlement
Header/Source DR participant ID
Header/UserID Optional: ID of user
Request/ID Optional Settlement ID of Interest
Request/StartTime Optional: Start date of event
Request/EndTime Optional: End date of event
LRS – External Web-Services Design
Confidential and Proprietary Page 50
The corresponding response messages would use the following message fields:
Message Element Value
Header/Verb reply
Header/Noun settlement
Header/Source PJM
Reply/ReplyCode Reply code, success=ok, error=fatal or warning
Reply/Error Error message, if error encountered
Payload Settlement(s)
4.3.1 Process
Process related information use cases include -
Description Verb Noun Input Output
Search pending
processes
assigned to
organization
get process Payload= set of
process objects
Get process status
and history
get process Request/ID=
process id
Payload=
process object
Search pending
processes started
by organization
get process Request/
Organization =
short name of
organization
Payload= set of
process objects
The Get Process interface provides the means for a DR participant to obtain detailed
Process information. The following parameters are specified in the RequestMessage:
Message Element Value
Header/Verb get
Header/Noun process
Header/Source DR participant ID
Header/UserID Optional: ID of user
LRS – External Web-Services Design
Confidential and Proprietary Page 51
Request/ID Optional: Process ID of Interest
Request/Organization Optional: Organization of interest (must match participant ID)
The corresponding response messages would use the following message fields:
Message Element Value
Header/Verb reply
Header/Noun process
Header/Source PJM
Reply/ReplyCode Reply code, success=ok, error=fatal or warning
Reply/Error Error message, if error encountered
Payload Process(s)
4.3.2 Measurement Data
Measurement Data related information use cases include -
Description Verb Noun Input Output
Gets submitted
daily data for a
location and date
range
get dailydata Request/ID=
location id
Request/StartTime=
start date
Request/EndTime=
end date
Payload= set of
daily data
objects
Gets submitted
daily data for a
registration and
date range
get dailydata Request/AlternateID=
registration id
Request/StartTime=
starttime
Request/EndTime=
endtime
Payload= set of
daily data
objects
Gets submitted
interval data for
a location and
date range
get intervaldata Request/ID=
location id
Request/StartTime=
start date
Request/EndTime=
end date
Payload= set of
interval data
objects
LRS – External Web-Services Design
Confidential and Proprietary Page 52
Gets submitted
interval data for
a registration
and date range
get intervaldata Request/AlternateID=
registration id
Request/StartTime=
starttime
Request/EndTime=
endtime
Payload= set of
interval data
objects
4.3.2.1 ‘get’ dailydata or intervaldata
The following parameters are specified in the RequestMessage:
Message Element Value
Header/Verb get
Header/Noun dailydata or intervaldata
Header/Source DR participant ID
Header/UserID Optional: ID of user
Request/ID Optional: Location id
Request/Alternate ID Optional: Registration id
Request/Start time Start date-time of reads
Request/End time End date-time of reads
The corresponding response messages would use the following message fields:
Message Element Value
Header/Verb reply
Header/Noun dailydata or intervaldata
Header/Source PJM
Reply/ReplyCode Reply code, success=ok, error=fatal or warning
Reply/Error Error message, if error encountered
Payload DailyData(s) or IntervalData(s)
LRS – External Web-Services Design
Confidential and Proprietary Page 53
The payload objects will contain all available fields, with the exception that the
Registration Id will only be populated if it was part of the search criteria.
LRS – External Web-Services Design
Confidential and Proprietary Page 54
5 Load Response Transactions
The purpose of the Load Response Transactions (LRTransaction) Service is to support
interfaces required for LR Transactions. This section describes the use of web services by
PJM Customers that involve the creation, submission, change, and cancellation of
Registrations, Location, Settlement, etc.
Note: The interfaces described in this section are subject to change based upon
final DRBizNet design.
5.1 Interfaces Provided
Specific interfaces using specific combinations of verbs and nouns (i.e. payload
types) are defined to permit a PJM LR participant to programmatically interact with
LR Transactions.
The verb to be used for requests would be one of {create, change, action, cancel}.
The noun would identify the type of transaction being requested. Each request could
use a message ‘Request’ package to specify one or more parameters that would
qualify the request.
The processing sequence is shown in the following sequence diagram.
LRS – External Web-Services Design
Confidential and Proprietary Page 55
LRS Users Web
Services ClientBigIP Proxy LRS Application
1: Request (create, change, cancel)
5: Authorize
6: Reply
7: Response (reply, noun, payload)
4: Invoke LRS API
3: Authentication
Integration
Tibco Layer
2:: Request (create, change, cancel)
8: Response (reply, noun, payload)
HTTPS
PJM LRS SYSTEM
HTTP
HTTPS
HTTP
CSP/EDC/LSE WS Client PJM DMZ
Figure 8 - LR Transaction Request Sequence Diagram
5.2 Interfaces Required
The messages for LR information requests would use the following message fields for
creation or update (change) of a record:
Message Element Value
Header/Verb create/change
Header/Noun Name of payload type
Header/Source Org short name
Header/UserID Optional: ID of user
Request/? Optional: Other request parameters may be specified as needed
Payload Message payload data with type defined by Noun
LRS – External Web-Services Design
Confidential and Proprietary Page 56
The corresponding response messages for create or update would use the following
message fields:
Message Element Value
Header/Verb reply
Header/Noun Name of payload type
Header/Source PJM
Reply/ReplyCode Reply code, success=ok, error=fatal or warning
Reply/Error May be any number of error message if the ReplyCode is ERROR
Reply/Timestamp The time the submission was received by PJM
Reply/ID Process id (if PENDING)
Payload Message payload data with type defined by Noun.
In the cases of payloads that would otherwise exceed 1 megabyte, the payloads would
be zipped, base64 encoded and stored within the ‘Payload/Compressed’ tag.
The messages for LR information requests would use the following message fields for
cancellation (delete) of a record:
Message Element Value
Header/Verb cancel
Header/Noun Name of payload type
Header/Source Org short name
Header/UserID Optional: ID of user
Request/ID Required: ID of the record to be deleted
The corresponding response messages for cancel would use the following message
fields:
LRS – External Web-Services Design
Confidential and Proprietary Page 57
Message Element Value
Header/Verb reply
Header/Noun Name of payload type
Header/Source PJM
Reply/ReplyCode Reply code, success=ok, error=fatal or warning
Reply/Error May be any number of error message if the ReplyCode is ERROR
Reply/ID Process id (if PENDING)
Reply/Timestamp The time the submission was received by PJM
5.3 Message Specifications
LRS Transaction verb, noun and payload definitions are dataset specific and are described in
this section.
5.3.1 Location
Location related transactional use cases include –
Description Verb Noun Input Output
Create a new
location
create location Request/Option=
new
Payload=location
object
Reply/ID=
process id
Payload=location
object
Update a
location
change location Request/Option=
detail
Payload=
location object
Reply/ID=
process id
5.3.1.1 ‘create’ Location
The ‘create’ Location interface provides the means for a DR participant to create a
Location. The following parameters are specified in the RequestMessage:
Message Element Value
Header/Verb create
LRS – External Web-Services Design
Confidential and Proprietary Page 58
Header/Noun location
Header/Source Org short name
Header/UserID Optional: ID of user
Request/Option {new, [future]}
Payload Location
The corresponding response messages would use the following message fields:
Message Element Value
Header/Verb reply
Header/Noun location
Header/Source PJM
Reply/ReplyCode Reply code, success=ok, error=fatal or warning
Reply/Error Error message, if error encountered
Reply/ID Process id (if PENDING)
Payload Location
5.3.1.2 ‘change’ Location
The ‘change’ Location interface provides the means for a DR participant to change a
Location. The following parameters are specified in the RequestMessage:
Message Element Value
Header/Verb change
Header/Noun location
Header/Source Org short name
Header/UserID Optional: ID of user
Request/Option {detail, [future]}
Payload Location
LRS – External Web-Services Design
Confidential and Proprietary Page 59
The corresponding response messages would use the following message fields:
Message Element Value
Header/Verb reply
Header/Noun location
Header/Source PJM
Reply/ReplyCode Reply code, success=ok, error=fatal or warning
Reply/Error Error message, if error encountered
Reply/ID Process id (if PENDING)
5.3.2 Registration
Registration related transactional use cases include –
Description Verb Noun Input Output
Create a new
registration
create registration Request/Option=
new
Payload=
registration object
Reply/ID=
process id
Payload= registration
object
Create a new
registration
and submit
for approval
create registration Request/Option=
submit
Payload=
registration object
Reply/ID=
process id
Payload= registration
object
Update
registration
details
change registration Request/Option=
detail
Payload=
registration object
Reply/ID=
process id
Submit a
registration
for approval
action registration Request/Option=
submit
Request/ID=
registration id
Reply/ID=
process id
Withdraw a
pending
registration
action registration Request/Option=
withdraw
Request/ID=
registration id
Reply/ID=
process id
LRS – External Web-Services Design
Confidential and Proprietary Page 60
5.3.2.1 ‘create’ Registration
The ‘create’ Registration interface provides the means for a LR participant to create
Registration Information. The following parameters are specified in the
RequestMessage:
Message Element Value
Header/Verb create
Header/Noun registration
Header/Source Org short name
Header/UserID Optional: ID of user
Request/Option {new, submit, [future]}
Payload Registration
The corresponding response messages would use the following message fields:
Message Element Value
Header/Verb reply
Header/Noun registration
Header/Source PJM
Reply/ReplyCode Reply code, success=ok, error=fatal or warning
Reply/Error Error message, if error encountered
Reply/id Process ID (if PENDING)
Payload Registration
5.3.2.2 ‘change’ Registration
The ‘change’ Registration interface provides the means for a LR participant to change
their Registration Information. The following parameters are specified in the
RequestMessage:
Message Element Value
Header/Verb change
LRS – External Web-Services Design
Confidential and Proprietary Page 61
Header/Noun registration
Header/Source Org short name
Header/UserID Optional: ID of user
Request/Option {details, [future]}
Payload Registration
The corresponding response messages would use the following message fields:
Message Element Value
Header/Verb reply
Header/Noun registration
Header/Source PJM
Reply/ReplyCode Reply code, success=ok, error=fatal or warning
Reply/Error Error message, if error encountered
Reply/ID Process ID (if PENDING)
5.3.2.3 ‘action’ Registration
The ‘action’ Registration interface provides the means for a LR participant to initiate
an action on a Registration. The following parameters are specified in the
RequestMessage:
Message Element Value
Header/Verb action
Header/Noun registration
Header/Source Org short name
Header/UserID Optional: ID of user
Request/Option {submit, withdraw,[ future]}
Request/ID Registration ID
LRS – External Web-Services Design
Confidential and Proprietary Page 62
The corresponding response messages would use the following message fields:
Message Element Value
Header/Verb reply
Header/Noun registration
Header/Source PJM
Reply/ReplyCode Reply code, success=ok, error=fatal or warning
Reply/Error Error message, if error encountered
Reply/ID Process ID (if PENDING)
5.3.3 Event
There is no create/change Event interface at this time. (Self-scheduled events will be
done outside LRS).
5.3.4 Settlement
Settlement related transactional use cases include –
Description Verb Noun Input Output
Update the
settlement
change settlement Payload=
settlement object
Reply/ID=
process id
Validate a
settlement
action settlement Request/Option=
validate
Request/ID=
settlement id
Withdraw a
settlement
action settlement Request/Option=
withdraw
Request/ID=
settlement id
Reply/ID=
process id
Create a
settlement
adjustment
create settlement Request/Option=
adjustment
Payload=
settlement object
Reply/ID=
Payload=settlement
object
LRS – External Web-Services Design
Confidential and Proprietary Page 63
5.3.4.1 ‘change’ Settlement
The change Settlement interface provides the means for a LR participant to change
their Settlement Information. The following parameters are specified in the
RequestMessage:
Message Element Value
Header/Verb change
Header/Noun settlement
Header/Source Org short name
Header/UserID Optional: ID of user
Request/Option {detail, [future]}
Payload Settlement
The corresponding response messages would use the following message fields:
Message Element Value
Header/Verb reply
Header/Noun settlement
Header/Source PJM
Reply/ReplyCode Reply code, success=ok, error=fatal or warning
Reply/Error Error message, if error encountered
Reply/ID Process ID (if PENDING)
5.3.4.2 ‘action’ Settlement
The action Settlement interface provides the means for a LR participant to initiate an
action on a Settlement. The following parameters are specified in the
RequestMessage:
Message Element Value
Header/Verb action
Header/Noun settlement
LRS – External Web-Services Design
Confidential and Proprietary Page 64
Header/Source Org short name
Header/UserID Optional: ID of user
Request/Option {submit, withdraw, validate, [future]}
The corresponding response messages would use the following message fields:
Message Element Value
Header/Verb reply
Header/Noun settlement
Header/Source PJM
Reply/ReplyCode Reply code, success=ok, error=fatal or warning
Reply/Error Error message, if error encountered
Reply/ID Process ID (if PENDING)
5.3.4.3 ‘create’ Settlement
The create Settlement interface provides the means for a LR participant to create an
adjustment on an existing closed Settlement. The following parameters are specified
in the RequestMessage:
Message Element Value
Header/Verb create
Header/Noun settlement
Header/Source Org short name
Header/UserID Optional: ID of user
Request/Option {adjustment, [future]
Payload Settlement
The corresponding response messages would use the following message fields:
Message Element Value
LRS – External Web-Services Design
Confidential and Proprietary Page 65
Header/Verb reply
Header/Noun settlement
Header/Source PJM
Reply/ReplyCode Reply code, success=ok, error=fatal or warning
Reply/Error Error message, if error encountered
Reply/ID Process ID (if PENDING)
5.3.5 Process
Process related transactional use cases include –
Description Verb Noun Input Output
Complete an
assigned
process task
(approve, deny,
etc)
change process Request/Option=
completetask
Payload= process
object
Reply/ID=
process id
5.3.5.1 ‘change’ Process
The change Process interface provides the means for a LR participant to update a
Process state, typically to complete an assigned task. The following parameters are
specified in the RequestMessage:
Message Element Value
Header/Verb change
Header/Noun process
Header/Source Org short name
Header/UserID Optional: ID of user
Request/Option {completetask, [future]}
Payload Process
The corresponding response messages would use the following message fields:
Message Element Value
LRS – External Web-Services Design
Confidential and Proprietary Page 66
Header/Verb reply
Header/Noun process
Header/Source PJM
Reply/ReplyCode Reply code, success=ok, error=fatal or warning
Reply/Error Error message, if error encountered
Reply/ID Process ID
5.3.6 Measurement Data
Measurement Data related transactional use cases include –
Description Verb Noun Input Output
Upload daily
measurement data
create dailydata Payload=Daily
data
Reply/ID=
process id
Upload interval
measurement data
create intervaldata Payload=Interval
data
Reply/ID=
process id
5.3.6.1 ‘create’ Daily Data
The create DailyData interface provides the means for a DR participant to upload
(i.e., ‘submit’) DailyData Information, typically for settlement. The following
parameters are specified in the RequestMessage:
Message Element Value
Header/Verb create
Header/Noun dailydata
Header/Source Org short name
Header/UserID Optional: ID of user
Payload DailyData
The corresponding response messages would use the following message fields:
LRS – External Web-Services Design
Confidential and Proprietary Page 67
Message Element Value
Header/Verb reply
Header/Noun dailydata
Header/Source PJM
Reply/ReplyCode Reply code, success=ok, error=fatal or warning
Reply/Error Error message, if error encountered
Reply/ID Process id (if PENDING)
5.3.6.2 ‘create’ Interval Data
The create IntervalData interface provides the means for a DR participant to create
(i.e., ‘submit’) IntervalData Information, typically for compliance. The following
parameters are specified in the RequestMessage:
Message Element Value
Header/Verb change
Header/Noun intervaldata
Header/Source Org short name
Header/UserID Optional: ID of user
Payload IntervalData
The corresponding response messages would use the following message fields:
Message Element Value
Header/Verb reply
Header/Noun intervaldata
Header/Source PJM
Reply/ReplyCode Reply code, success=ok, error=fatal or warning
Reply/Error Error message, if error encountered
Reply/ID Process id (if PENDING)
Appendix A: WSDL for DR Requests This WSDL uses a set of operations for servicing all DR requests, related to information requests and alert acknowledgements.
<?xml version="1.0" encoding="UTF-8"?>
<!--Created by TIBCO WSDL-->
<wsdl:definitions xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:tns="http://www.uisol.com/wsdl/2009/LRSConcrete"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:ns="http://www.uisol.com/schema/drbiznet/2009/message" name="Untitled"
targetNamespace="http://www.uisol.com/wsdl/2009/LRSConcrete">
<wsdl:types>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.uisol.com/schema/drbiznet/2009/message"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:include schemaLocation="Message.xsd"/>
</xs:schema>
</wsdl:types>
<wsdl:message name="AlertRequest">
<wsdl:part name="Message" element="ns:AlertRequest"/>
</wsdl:message>
<wsdl:message name="InformationRequest">
<wsdl:part name="Message" element="ns:InformationRequest"/>
</wsdl:message>
<wsdl:message name="TransactionRequest">
<wsdl:part name="Message" element="ns:TransactionRequest"/>
</wsdl:message>
<wsdl:message name="ResponseMessage">
<wsdl:part name="Message" element="ns:ResponseMessage"/>
</wsdl:message>
<wsdl:message name="FaultMessage">
<wsdl:part name="part1" element="ns:FaultMessage"/>
</wsdl:message>
<wsdl:portType name="Operations">
<wsdl:operation name="LRSTransactions">
<wsdl:input message="tns:TransactionRequest"/>
<wsdl:output message="tns:ResponseMessage"/>
LRS – External Web-Services Design
Confidential and Proprietary Page 69
<wsdl:fault name="fault1" message="tns:FaultMessage"/>
</wsdl:operation>
<wsdl:operation name="Alerts">
<wsdl:input message="tns:AlertRequest"/>
<wsdl:output message="tns:ResponseMessage"/>
<wsdl:fault name="fault1" message="tns:FaultMessage"/>
</wsdl:operation>
<wsdl:operation name="LRSInformation">
<wsdl:input message="tns:InformationRequest"/>
<wsdl:output message="tns:ResponseMessage"/>
<wsdl:fault name="fault1" message="tns:FaultMessage"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name="HTTPEndPointBinding" type="tns:Operations">
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="LRSTransactions">
<soap:operation soapAction="/BusinessService/DRBizNetEWSService.serviceagent/HTTPEndPoint/LRSTransactions"
style="document"/>
<wsdl:input>
<soap:body parts="Message" use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body parts="Message" use="literal"/>
</wsdl:output>
<wsdl:fault name="fault1">
<soap:fault name="fault1" use="literal"/>
</wsdl:fault>
</wsdl:operation>
<wsdl:operation name="Alerts">
<soap:operation soapAction="/BusinessService/DRBizNetEWSService.serviceagent/OperationsEndpoint1/Alerts" style="document"/>
<wsdl:input>
<soap:body parts="Message" use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body parts="Message" use="literal"/>
</wsdl:output>
<wsdl:fault name="fault1">
LRS – External Web-Services Design
Confidential and Proprietary Page 70
<soap:fault name="fault1" use="literal"/>
</wsdl:fault>
</wsdl:operation>
<wsdl:operation name="LRSInformation">
<soap:operation soapAction="/BusinessService/DRBizNetEWSService.serviceagent/HTTPEndPoint/LRSInformation"
style="document"/>
<wsdl:input>
<soap:body parts="Message" use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body parts="Message" use="literal"/>
</wsdl:output>
<wsdl:fault name="fault1">
<soap:fault name="fault1" use="literal"/>
</wsdl:fault>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="DRBizNetEWSService">
<wsdl:port name="HTTPEndPoint" binding="tns:HTTPEndPointBinding">
<soap:address location="http://UISOL-1:9696/BusinessService/DRBizNetEWSService.serviceagent/HTTPEndPoint"/>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>
LRS – External Web-Services Design
Confidential and Proprietary Page 71
Appendix B: XML Schemas The following XML schema is used to define Message structures for request and response messages for the WSDL defined in
Appendix B. These are provided here for reference purposes, but versions should be downloaded from the PJM web site for
development use.
message.xsd
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns="http://www.uisol.com/schema/drbiznet/2009/message" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.uisol.com/schema/drbiznet/2009/message" elementFormDefault="qualified" attributeFormDefault="unqualified"
version="0.0.1">
<xsd:complexType name="RequestType">
<xsd:sequence>
<xsd:element name="Date" type="xsd:dateTime" minOccurs="0"/>
<xsd:element name="StartTime" type="xsd:dateTime" minOccurs="0"/>
<xsd:element name="EndTime" type="xsd:dateTime" minOccurs="0"/>
<xsd:element name="Zone" type="xsd:string" minOccurs="0"/>
<xsd:element name="Option" type="xsd:string" minOccurs="0"/>
<xsd:element name="Match" type="xsd:string" minOccurs="0"/>
<xsd:element name="Organization" type="xsd:string" minOccurs="0"/>
<xsd:element name="ID" type="xsd:string" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element name="AlternateID" type="xsd:string" minOccurs="0"/>
<xsd:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="ReplyType">
<xsd:sequence>
<xsd:element name="ReplyCode" type="xsd:string"/>
<xsd:element name="Error" type="xsd:string" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element name="Timestamp" type="xsd:dateTime" minOccurs="0"/>
<xsd:element name="ID" type="xsd:string" minOccurs="0" maxOccurs="unbounded"/>
<xsd:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="PayloadType">
LRS – External Web-Services Design
Confidential and Proprietary Page 72
<xsd:sequence>
<xsd:choice>
<xsd:any namespace="##other" processContents="skip" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element name="Document" type="xsd:string" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element name="Compressed" type="xsd:string" minOccurs="0"/>
</xsd:choice>
<xsd:element name="format" type="xsd:string" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="HeaderType">
<xsd:sequence>
<xsd:element name="Verb" default="get">
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="cancel"/>
<xsd:enumeration value="canceled"/>
<xsd:enumeration value="change"/>
<xsd:enumeration value="changed"/>
<xsd:enumeration value="create"/>
<xsd:enumeration value="created"/>
<xsd:enumeration value="close"/>
<xsd:enumeration value="closed"/>
<xsd:enumeration value="delete"/>
<xsd:enumeration value="deleted"/>
<xsd:enumeration value="get"/>
<xsd:enumeration value="reply"/>
<xsd:enumeration value="submit"/>
<xsd:enumeration value="action"/>
<xsd:enumeration value="update"/>
<xsd:enumeration value="updated"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
<xsd:element name="Noun" type="xsd:string"/>
<xsd:element name="Revision" type="xsd:string" default="001"/>
<xsd:element name="Source" type="xsd:string"/>
<xsd:element name="UserID" type="xsd:string" minOccurs="0"/>
LRS – External Web-Services Design
Confidential and Proprietary Page 73
<xsd:element name="MessageID" type="xsd:string" minOccurs="0"/>
<xsd:element name="Comment" type="xsd:string" minOccurs="0"/>
<xsd:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
<xsd:element name="Message">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Header" type="HeaderType"/>
<xsd:choice>
<xsd:element name="Request" type="RequestType" minOccurs="0"/>
<xsd:element name="Reply" type="ReplyType" minOccurs="0"/>
</xsd:choice>
<xsd:element name="Payload" type="PayloadType" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:complexType name="RequestMessageType">
<xsd:sequence>
<xsd:element name="Header" type="HeaderType"/>
<xsd:element name="Request" type="RequestType" minOccurs="0"/>
<xsd:element name="Payload" type="PayloadType" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
<xsd:element name="InformationRequest" type="RequestMessageType"/>
<xsd:element name="TransactionRequest" type="RequestMessageType"/>
<xsd:element name="AlertRequest" type="RequestMessageType"/>
<xsd:element name="ResponseMessage">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Header" type="HeaderType"/>
<xsd:element name="Reply" type="ReplyType" minOccurs="0"/>
<xsd:element name="Payload" type="PayloadType" minOccurs="0"/>
</xsd:sequence>
LRS – External Web-Services Design
Confidential and Proprietary Page 74
</xsd:complexType>
</xsd:element>
<xsd:element name="FaultMessage">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Reply" type="ReplyType" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>
LRSLocation.xsd
<?xml version="1.0" encoding="UTF-8"?>
<!-- edited with XMLSpy v2008 rel. 2 sp2 (http://www.altova.com) by Anu (EDS) -->
<xs:schema xmlns="http://www.pjm.com/schema/drbiznet/2009/model" xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.pjm.com/schema/drbiznet/2009/model" elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:include schemaLocation="LRSCommonTypes.xsd"/>
<xs:element name="Locations">
<xs:complexType>
<xs:sequence>
<xs:element ref="Location" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:complexType name="locationSummaryInfoType">
<xs:sequence>
<xs:element name="name" type="xs:string" minOccurs="0"/>
<xs:element name="CSP" type="organization" minOccurs="0"/>
<xs:element name="EDC" type="organization" minOccurs="0"/>
<xs:element name="zone" type="xs:string" minOccurs="0"/>
<xs:element name="status" type="xs:string" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="locationSiteInfoType">
<xs:sequence>
LRS – External Web-Services Design
Confidential and Proprietary Page 75
<xs:element name="address" type="address" minOccurs="0"/>
<xs:element name="businessSegment" type="xs:string" minOccurs="0"/>
<xs:element name="pNode" type="xs:string" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="locationProfileInfoType">
<xs:sequence>
<xs:element name="energyLossFactor" type="xs:double" minOccurs="0"/>
<xs:element name="capacityLossFactor" type="xs:double" minOccurs="0"/>
<xs:element name="retailRate" type="xs:double" minOccurs="0"/>
<xs:element name="loadReduction" type="xs:double" minOccurs="0"/>
<xs:element name="peakLoadContribution" type="xs:double" minOccurs="0"/>
<xs:element name="loadMultiplier" type="xs:double" minOccurs="0"/>
<xs:element name="generationFuelType" type="xs:string" minOccurs="0"/>
<xs:element name="meterQualificationDate" type="xs:date" minOccurs="0"/>
<xs:element name="stateQualificationDate" type="xs:date" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="locationReductionInfoType">
<xs:sequence>
<xs:element name="reductionType" type="xs:string" minOccurs="0"/>
<xs:element name="reductionValue" type="xs:double" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="locationMeterInfoType">
<xs:sequence>
<xs:element name="meterOwner" type="xs:string" minOccurs="0"/>
<xs:element name="allowEDCtoSubmitData" type="xs:boolean" minOccurs="0"/>
<xs:element name="allowLSEtoSubmitData" type="xs:boolean" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:element name="Location">
<xs:annotation>
<xs:documentation>LRS Location Object</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
LRS – External Web-Services Design
Confidential and Proprietary Page 76
<xs:element name="id" type="objectId" minOccurs="0"/>
<xs:element name="summaryInfo" type="locationSummaryInfoType" minOccurs="0"/>
<xs:element name="siteInfo" type="locationSiteInfoType" minOccurs="0"/>
<xs:element name="profileInfo" type="locationProfileInfoType" minOccurs="0"/>
<xs:element name="reductionInfo" type="locationReductionInfoType" minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="meterInfo" type="locationMeterInfoType" minOccurs="0"/>
<xs:element name="contactInfo" type="contact" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
LRSRegistration.xsd <?xml version="1.0" encoding="UTF-8"?>
<!-- edited with XMLSpy v2008 rel. 2 sp2 (http://www.altova.com) by Anu (EDS) -->
<xs:schema xmlns="http://www.pjm.com/schema/drbiznet/2009/model" xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.pjm.com/schema/drbiznet/2009/model" elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:include schemaLocation="LRSCommonTypes.xsd"/>
<xs:element name="Registrations">
<xs:complexType>
<xs:sequence>
<xs:element ref="Registration" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:complexType name="registrationSummaryType">
<xs:sequence>
<xs:element name="reference" type="xs:string" minOccurs="0"/>
<xs:element name="name" type="xs:string" minOccurs="0"/>
<xs:element name="type" type="xs:string" minOccurs="0"/>
<xs:element name="program" type="xs:string" minOccurs="0"/>
<xs:element name="startDate" type="xs:date" minOccurs="0"/>
<xs:element name="endDate" type="xs:date" minOccurs="0"/>
<xs:element name="CSP" type="organization" minOccurs="0"/>
<xs:element name="EDC" type="organization" minOccurs="0"/>
<xs:element name="LSE" type="organization" minOccurs="0"/>
LRS – External Web-Services Design
Confidential and Proprietary Page 77
<xs:element name="zone" type="xs:string" minOccurs="0"/>
<xs:element name="status" type="xs:string" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="registrationLocationType">
<xs:sequence>
<xs:element name="locationID" type="objectId" minOccurs="0"/>
<xs:element name="accountNo" type="xs:string" minOccurs="0"/>
<xs:element name="energyLossFactor" type="xs:double" minOccurs="0"/>
<xs:element name="capacityLossFactor" type="xs:double" minOccurs="0"/>
<xs:element name="retailRate" type="xs:double" minOccurs="0"/>
<xs:element name="loadReduction" type="xs:double" minOccurs="0"/>
<xs:element name="peakLoadContribution" type="xs:double" minOccurs="0"/>
<xs:element name="siteMultiplier" type="xs:double" default="1" minOccurs="0"/>
<xs:element name="generationFuelType" type="xs:string" minOccurs="0"/>
<xs:element name="meterQualificationDate" type="xs:date" minOccurs="0"/>
<xs:element name="stateQualificationDate" type="xs:date" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="registrationEnergyType">
<xs:sequence>
<xs:element name="energyType" type="xs:string" minOccurs="0"/>
<xs:element name="loadReduction" type="xs:string" minOccurs="0"/>
<xs:element name="energyLossFactor" type="xs:double" minOccurs="0"/>
<xs:element name="strikePrice" type="xs:double" minOccurs="0"/>
<xs:element name="shutdownCosts" type="xs:double" minOccurs="0"/>
<xs:element name="contractType" type="xs:string" minOccurs="0"/>
<xs:element name="priceNode" type="xs:string" minOccurs="0"/>
<xs:element name="retailRate" type="xs:double" minOccurs="0"/>
<xs:element name="rateName" type="xs:string" minOccurs="0"/>
<xs:element name="rateDescription" type="xs:string" minOccurs="0"/>
<xs:element name="emergency" type="xs:boolean" minOccurs="0"/>
<xs:element name="selfSchedule" type="xs:boolean" minOccurs="0"/>
<xs:element name="dayAhead" type="xs:boolean" minOccurs="0"/>
<xs:element name="realTime" type="xs:boolean" minOccurs="0"/>
<xs:element name="CBLMethod" type="xs:string" minOccurs="0"/>
<xs:element name="weatherStation" type="xs:string" minOccurs="0"/>
LRS – External Web-Services Design
Confidential and Proprietary Page 78
</xs:sequence>
</xs:complexType>
<xs:complexType name="registrationASInfoType">
<xs:sequence>
<xs:element name="synchronizedReserve" type="xs:boolean" minOccurs="0"/>
<xs:element name="scheduledReserve" type="xs:boolean" minOccurs="0"/>
<xs:element name="regulation" type="xs:boolean" minOccurs="0"/>
<xs:element name="batchLoad" type="xs:boolean" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="registrationCapacityType">
<xs:sequence>
<xs:element name="capacityType" type="xs:string" minOccurs="0"/>
<xs:element name="longLeadTime" type="xs:boolean" minOccurs="0"/>
<xs:element name="zoneArea" type="xs:string" minOccurs="0"/>
<xs:element name="RPMResourceID" type="objectId" minOccurs="0"/>
<xs:element name="measurementMethod" type="xs:string" minOccurs="0"/>
<xs:element name="capacityLossFactor" type="xs:double" minOccurs="0"/>
<xs:element name="peakLoadContribution" type="xs:double" minOccurs="0"/>
<xs:element name="managedLoad" type="xs:double" minOccurs="0"/>
<xs:element name="multiplier" type="xs:double" minOccurs="0"/>
<xs:element name="nominalICAP" type="xs:double" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="registrationOtherType">
<xs:sequence>
<xs:element name="allowEDCtoModify" type="xs:boolean" minOccurs="0"/>
<xs:element name="allowLSEtoModify" type="xs:boolean" minOccurs="0"/>
<xs:element name="holdScheduling" type="xs:boolean" minOccurs="0"/>
<xs:element name="holdSettlements" type="xs:boolean" minOccurs="0"/>
<xs:element name="comment" type="xs:string" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:element name="Registration">
<xs:annotation>
<xs:documentation>LRS Registration Object</xs:documentation>
</xs:annotation>
LRS – External Web-Services Design
Confidential and Proprietary Page 79
<xs:complexType>
<xs:sequence>
<xs:element name="id" type="objectId" minOccurs="0"/>
<xs:element name="summaryInfo" type="registrationSummaryType" minOccurs="0"/>
<xs:element name="locationInfo" type="registrationLocationType" minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="energyInfo" type="registrationEnergyType" minOccurs="0"/>
<xs:element name="ASInfo" type="registrationASInfoType" minOccurs="0"/>
<xs:element name="capacityInfo" type="registrationCapacityType" minOccurs="0"/>
<xs:element name="otherInfo" type="registrationOtherType" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
LRSEvent.xsd <?xml version="1.0" encoding="UTF-8"?>
<!-- edited with XMLSpy v2008 rel. 2 sp2 (http://www.altova.com) by Anu (EDS) -->
<xs:schema xmlns="http://www.pjm.com/schema/drbiznet/2009/model" xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.pjm.com/schema/drbiznet/2009/model" elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:include schemaLocation="LRSCommonTypes.xsd"/>
<xs:element name="Events">
<xs:complexType>
<xs:sequence>
<xs:element ref="Event" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:complexType name="eventSummaryType">
<xs:sequence>
<xs:element name="eventDate" type="xs:date" minOccurs="0"/>
<xs:element name="eventType" type="xs:string" minOccurs="0"/>
<xs:element name="startTime" type="xs:dateTime" minOccurs="0"/>
<xs:element name="endTime" type="xs:dateTime" minOccurs="0"/>
<xs:element name="description" type="xs:string" minOccurs="0"/>
<xs:element name="shortLead" type="xs:boolean" minOccurs="0"/>
<xs:element name="longLead" type="xs:boolean" minOccurs="0"/>
<xs:element name="status" type="xs:string" minOccurs="0"/>
LRS – External Web-Services Design
Confidential and Proprietary Page 80
</xs:sequence>
</xs:complexType>
<xs:complexType name="zoneInfoType">
<xs:sequence>
<xs:element name="zone" type="xs:string" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="eventRegistrationType">
<xs:sequence>
<xs:element name="registrationId" type="objectId" minOccurs="0"/>
<xs:element name="reference" type="xs:string" minOccurs="0"/>
<xs:element name="name" type="xs:string" minOccurs="0"/>
<xs:element name="type" type="xs:string" minOccurs="0"/>
<xs:element name="program" type="xs:string" minOccurs="0"/>
<xs:element name="CSP" type="organization" minOccurs="0"/>
<xs:element name="EDC" type="organization" minOccurs="0"/>
<xs:element name="LSE" type="organization" minOccurs="0"/>
<xs:element name="zone" type="xs:string" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:element name="Event">
<xs:annotation>
<xs:documentation>LRS Event object</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element name="id" type="objectId" minOccurs="0"/>
<xs:element name="summaryInfo" type="eventSummaryType" minOccurs="0"/>
<xs:element name="zoneInfo" type="zoneInfoType" minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="registrationInfo" type="eventRegistrationType" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
LRSSettlement.xsd
LRS – External Web-Services Design
Confidential and Proprietary Page 81
<?xml version="1.0" encoding="UTF-8"?>
<!-- edited with XMLSpy v2008 rel. 2 sp2 (http://www.altova.com) by Anu (EDS) -->
<xs:schema xmlns="http://www.pjm.com/schema/drbiznet/2009/model" xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.pjm.com/schema/drbiznet/2009/model" elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:include schemaLocation="LRSCommonTypes.xsd"/>
<xs:element name="Settlements">
<xs:complexType>
<xs:sequence>
<xs:element ref="Settlement" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:complexType name="settlementSummaryType">
<xs:sequence>
<xs:element name="referenceId" type="objectId" minOccurs="0"/>
<xs:element name="eventDate" type="xs:date" minOccurs="0"/>
<xs:element name="settlementType" type="xs:string" minOccurs="0"/>
<xs:element name="complianceOnly" type="xs:boolean" minOccurs="0"/>
<xs:element name="startTime" type="xs:dateTime" minOccurs="0"/>
<xs:element name="endTime" type="xs:dateTime" minOccurs="0"/>
<xs:element name="CBLMethod" type="xs:string" minOccurs="0"/>
<xs:element name="billDate" type="xs:date" minOccurs="0"/>
<xs:element name="adjustment" type="xs:boolean" minOccurs="0"/>
<xs:element name="status" type="xs:string" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="settlementRegistrationType">
<xs:sequence>
<xs:element name="registrationId" type="objectId" minOccurs="0"/>
<xs:element name="reference" type="xs:string" minOccurs="0"/>
<xs:element name="name" type="xs:string" minOccurs="0"/>
<xs:element name="type" type="xs:string" minOccurs="0"/>
<xs:element name="program" type="xs:string" minOccurs="0"/>
<xs:element name="CSP" type="organization" minOccurs="0"/>
<xs:element name="EDC" type="organization" minOccurs="0"/>
<xs:element name="LSE" type="organization" minOccurs="0"/>
<xs:element name="zone" type="xs:string" minOccurs="0"/>
LRS – External Web-Services Design
Confidential and Proprietary Page 82
</xs:sequence>
</xs:complexType>
<xs:complexType name="settlementInfoType">
<xs:sequence>
<xs:element name="eventHour" type="xs:integer" minOccurs="0"/>
<xs:element name="GMTHour" type="xs:dateTime" minOccurs="0"/>
<xs:element name="reductionHour" type="xs:boolean" minOccurs="0"/>
<xs:element name="marketType" type="xs:string" minOccurs="0"/>
<xs:element name="baseline" type="xs:double" minOccurs="0"/>
<xs:element name="load" type="xs:double" minOccurs="0"/>
<xs:element name="reduction" type="xs:double" minOccurs="0"/>
<xs:element name="rate" type="xs:double" minOccurs="0"/>
<xs:element name="lossFactor" type="xs:double" minOccurs="0"/>
<xs:element name="scheduled" type="xs:double" minOccurs="0"/>
<xs:element name="dispatched" type="xs:double" minOccurs="0"/>
<xs:element name="DAPrice" type="xs:double" minOccurs="0"/>
<xs:element name="RTPrice" type="xs:double" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="settlementTotalInfoType">
<xs:sequence>
<xs:element name="totalReduction" type="xs:double" minOccurs="0"/>
<xs:element name="averageRate" type="xs:double" minOccurs="0"/>
<xs:element name="averageLoss" type="xs:double" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="settlementOtherInfoType">
<xs:sequence>
<xs:element name="allowEDCtoModify" type="xs:boolean" minOccurs="0"/>
<xs:element name="allowLSEtoModify" type="xs:boolean" minOccurs="0"/>
<xs:element name="comment" type="xs:string" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:element name="Settlement">
<xs:annotation>
<xs:documentation>LRS Settlement Object</xs:documentation>
</xs:annotation>
LRS – External Web-Services Design
Confidential and Proprietary Page 83
<xs:complexType>
<xs:sequence>
<xs:element name="id" type="objectId" minOccurs="0"/>
<xs:element name="summaryInfo" type="settlementSummaryType" minOccurs="0"/>
<xs:element name="registrationInfo" type="settlementRegistrationType" minOccurs="0"/>
<xs:element name="settlementInfo" type="settlementInfoType" minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="totalInfo" type="settlementTotalInfoType" minOccurs="0"/>
<xs:element name="otherInfo" type="settlementOtherInfoType" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
LRSProcess.xsd: <?xml version="1.0" encoding="UTF-8"?>
<!-- edited with XMLSpy v2008 rel. 2 sp2 (http://www.altova.com) by Anu (EDS) -->
<xs:schema xmlns="http://www.pjm.com/schema/drbiznet/2009/model" xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.pjm.com/schema/drbiznet/2009/model" elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:include schemaLocation="LRSCommonTypes.xsd"/>
<xs:element name="Processes">
<xs:complexType>
<xs:sequence>
<xs:element ref="Process" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:complexType name="processSummaryType">
<xs:sequence>
<xs:element name="processName" type="xs:string" minOccurs="0"/>
<xs:element name="processOwner" type="xs:string" minOccurs="0"/>
<xs:element name="startDate" type="xs:date" minOccurs="0"/>
<xs:element name="endDate" type="xs:date" minOccurs="0"/>
<xs:element name="status" type="xs:string" minOccurs="0"/>
<xs:element name="objectID" type="objectId" minOccurs="0"/>
<xs:element name="objectType" type="xs:string" minOccurs="0"/>
</xs:sequence>
LRS – External Web-Services Design
Confidential and Proprietary Page 84
</xs:complexType>
<xs:complexType name="taskInfoType">
<xs:sequence>
<xs:element name="taskName" type="xs:string" minOccurs="0"/>
<xs:element name="taskOrg" type="xs:string" minOccurs="0"/>
<xs:element name="taskUser" type="xs:string" minOccurs="0"/>
<xs:element name="taskPriority" type="xs:string" minOccurs="0"/>
<xs:element name="taskStarted" type="xs:date" minOccurs="0"/>
<xs:element name="taskDue" type="xs:date" minOccurs="0"/>
<xs:element name="taskCompleted" type="xs:date" minOccurs="0"/>
<xs:element name="taskStatus" type="xs:string" minOccurs="0"/>
<xs:element name="reasons" type="xs:string" minOccurs="0"/>
<xs:element name="comments" type="xs:string" minOccurs="0"/>
<xs:element name="decisionInfo" type="decisionInfoType" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="decisionInfoType">
<xs:sequence>
<xs:element name="decisionName" type="xs:string" minOccurs="0"/>
<xs:element name="decisionReasons" type="xs:string" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="attributeInfoType">
<xs:sequence>
<xs:element name="attribute" type="xs:string" minOccurs="0"/>
<xs:element name="attributeType" type="xs:string" minOccurs="0"/>
<xs:element name="initialValue" type="xs:string" minOccurs="0"/>
<xs:element name="value" type="xs:string" minOccurs="0"/>
<xs:element name="readOnly" type="xs:boolean" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:element name="Process">
<xs:annotation>
<xs:documentation>LRS CBL Object</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
LRS – External Web-Services Design
Confidential and Proprietary Page 85
<xs:element name="id" type="objectId" minOccurs="0"/>
<xs:element name="summaryInfo" type="processSummaryType" minOccurs="0"/>
<xs:element name="taskInfo" type="taskInfoType" minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="attributeInfo" type="attributeInfoType" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
LRSDailyData.xsd <?xml version="1.0" encoding="UTF-8"?>
<!-- edited with XMLSpy v2008 rel. 2 sp2 (http://www.altova.com) by Anu (EDS) -->
<xs:schema xmlns="http://www.pjm.com/schema/drbiznet/2009/model" xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.pjm.com/schema/drbiznet/2009/model" elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:include schemaLocation="LRSCommonTypes.xsd"/>
<xs:element name="DailysData">
<xs:complexType>
<xs:sequence>
<xs:element ref="DailyData" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:complexType name="dailySummaryType">
<xs:sequence>
<xs:element name="locationId" type="objectId" minOccurs="0"/>
<xs:element name="registrationId" type="objectId" minOccurs="0"/>
<xs:element name="EDC" type="organization" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="dailyMeasurementInfoType">
<xs:sequence>
<xs:element name="dateStamp" type="xs:date" minOccurs="0"/>
<xs:element name="type" type="xs:string" minOccurs="0"/>
<xs:element name="UOM" type="xs:string" minOccurs="0"/>
<xs:element name="intervals" type="xs:integer" minOccurs="0"/>
<xs:element name="values" type="listOfValues" minOccurs="0"/>
<xs:element name="latest" type="xs:boolean" minOccurs="0"/>
LRS – External Web-Services Design
Confidential and Proprietary Page 86
<xs:element name="submittedBy" type="xs:string" minOccurs="0"/>
<xs:element name="submittedate" type="xs:dateTime" minOccurs="0"/>
<xs:element name="submissionError" type="xs:string" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:element name="DailyData">
<xs:annotation>
<xs:documentation>Daily Data Object</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element name="summaryInfo" type="dailySummaryType" minOccurs="0"/>
<xs:element name="measurementInfo" type="dailyMeasurementInfoType" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
LRSIntervalData.xsd <?xml version="1.0" encoding="UTF-8"?>
<!-- edited with XMLSpy v2008 rel. 2 sp2 (http://www.altova.com) by Anu (EDS) -->
<xs:schema xmlns="http://www.pjm.com/schema/drbiznet/2009/model" xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.pjm.com/schema/drbiznet/2009/model" elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:include schemaLocation="LRSCommonTypes.xsd"/>
<xs:element name="IntervalsData">
<xs:complexType>
<xs:sequence>
<xs:element ref="IntervalData" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:complexType name="intervalDataSummaryType">
<xs:sequence>
<xs:element name="locationId" type="objectId" minOccurs="0"/>
<xs:element name="registrationId" type="objectId" minOccurs="0"/>
<xs:element name="EDC" type="organization" minOccurs="0"/>
</xs:sequence>
LRS – External Web-Services Design
Confidential and Proprietary Page 87
</xs:complexType>
<xs:complexType name="intervalMeasurementInfoType">
<xs:sequence>
<xs:element name="timestamp" type="xs:dateTime" minOccurs="0"/>
<xs:element name="type" type="xs:string" minOccurs="0"/>
<xs:element name="UOM" type="xs:string" minOccurs="0"/>
<xs:element name="value" type="xs:double" minOccurs="0"/>
<xs:element name="latest" type="xs:boolean" minOccurs="0"/>
<xs:element name="submittedBy" type="xs:string" minOccurs="0"/>
<xs:element name="submittedDate" type="xs:dateTime" minOccurs="0"/>
<xs:element name="submissionError" type="xs:string" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:element name="IntervalData">
<xs:annotation>
<xs:documentation>Interval Data Object</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element name="summaryInfo" type="intervalDataSummaryType" minOccurs="0"/>
<xs:element name="measurementInfo" type="intervalMeasurementInfoType" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
LRSAlert.xsd <?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns="http://www.pjm.com/schema/drbiznet/2009/model" xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.pjm.com/schema/drbiznet/2009/model" elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:include schemaLocation="LRSCommonTypes.xsd"/>
<xs:complexType name="AlertMessageType">
<xs:sequence>
<xs:element name="subject" type="xs:string"></xs:element>
<xs:element name="message" type="xs:string"></xs:element>
<xs:element name="objectType" type="xs:string"></xs:element>
LRS – External Web-Services Design
Confidential and Proprietary Page 88
<xs:element name="objectId" type="objectId"></xs:element>
<xs:element name="expirationDate" type="xs:date"></xs:element>
<xs:element name="urgent" type="xs:boolean"></xs:element>
</xs:sequence>
</xs:complexType>
<xs:element name="Alerts">
<xs:complexType>
<xs:sequence>
<xs:element name="Alert" type="AlertMessageType" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
Appendix C: Payload Compression Example The purpose of this section is to provide an example of the code required to compress and encode a payload, where the payload is then
passed as the contents of the Payload/Compressed element. The following is a Java example that leverages commonly used classes for
compression and base64 encoding.
package BusinessService.TS.WebServiceClient.CompressionClient;
import java.util.*;
import java.io.*;
import java.io.File;
import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.io.InputStream;
import java.io.IOException;
import java.util.zip.*;
import org.apache.soap.encoding.soapenc.Base64;
public class CompressionClientCompressandEncode{
protected byte[] input = null;
protected String base64GzipInput = "";
public byte[] getinput() { return input; }
public void setinput(byte[] val) { input = val; }
public String getbase64GzipInput() { return base64GzipInput; }
public void setbase64GzipInput(String val) { base64GzipInput = val; }
LRS – External Web-Services Design
Confidential and Proprietary Page 89
public CompressionClientCompressandEncode() { }
public void invoke() throws Exception {
In : byte[] input
Out : String base64GzipInput
ByteArrayOutputStream bas = new ByteArrayOutputStream();
GZIPOutputStream bis = new GZIPOutputStream(bas);
bis.write(input);
bis.close();
base64GzipInput = Base64.encode(bas.toByteArray());
}
}