External Interfaces & Integration July 24 2007 Stephen Kerr

1. External Interfaces & IntegrationJuly 24 2007Stephen Kerr 1

2. Agenda • Updates to External Interface Specification • New Services • Sandbox & EDS deployment • Notifications & Listeners & Security • Web Service testing • Integration Design Process • Artifacts • Process • Exceptions 2

3. Updates to External Interface Specification • Certain elements of the External Interface Specification were approved on May 21st on condition that regular updates were provided to the specification • Revision 1.02 was posted on July 20th for review • Review feedback required by August 3rd • Updated document will be republished by August 9th • TPTF vote on August 14th • The changes in version 1.02 are • Removed deleteOutputSchedules from ThreePartOffer • Added statement related to ordering guarantees in section 2.6. • Added note regarding the handling of timestamps that are not interval ‘aligned’ in section 2.3.2 • Corrected figure 10 to reflect use of ‘INC’ or ‘DEC’ type in mRID for IncDecOffers • Corrected Figure 9 to not have expiration column • Modified Figure 10 to add column to map protocol terms to XML tags • Modified sections 3.3.1, 3.3.3, 3.3.4, 3.3.5 and 3.3.11 to not use expirationTime as a key value • Corrected references to ‘IrregularIntervalSchedule’ to be ‘TmSchedule’ • Revised section 5.1 and Figure 109 to reflect revised notification scheme • Revised ASOffer structure, uses a variation of PriceCurve that provides price points for each specific AS type. This affects sections 3.3.4, 2.3.1, 2.3.3 and 2.3.4 3

4. New services being built • The services we are building for Aug 30th release as loopback services are listed • There will be no back-end functionality associated with these services in the Sandbox • The back-end systems have not implemented these services yet and are subject to change • The Market Information types will be simulated but we have not yet decided what the response will be • Simple document or XML response • The services will be deployed to the EDS environment on the transition plan schedule • New Market Transaction Services • Self Arranged Ancillary Services • Ancillary Services Offer • Ancillary Services Trade • DAM Energy Bid • DAM Energy Only Offer • Congestion Revenue Rights Offer • PTP Obligation Bid • Self Schedule • New Market Information Services • Proxy Curves • Startup and Shutdown Instructions • Total Regulation • Load Ratio Share • Unit Availability • Forecasted Load • Real-Time System Load • Market LMPs and SPPs • Mitigated Curves • New Notifications • Outage Notifications • Notices and Alerts • CRR Awards • New Outage Scheduling Services • Outage Creation 4

5. Sandbox & EDS deployment • Following services are available • Three Part Offer • Incremental/Decremental Offers • Current Operating Plan • Output Schedule • Bid Set Acceptance • Bid Set Errors • Get mRID • System Status • Defects are being posted here: • http://nodal.ercot.com/readiness/sandbox/documents/docs/Sandbox_Defects.xls • Problem with optional fields being made mandatory • Notifications system is functional but network configuration has to be reworked to get notifications through the DMZ • Back-end integration with MMS enters test in early August for early EDS3 • Three Part Offer • Incremental/ Decremental Offers • Current Operating Plan • Output Schedule • Pending sent through the general Notification service NOT • Bid Set Acceptance • Bid Set Errors 5

6. Notifications & Listeners ERCOT DMZ Internet MP System HTTPS HTTPS - Request Target Application Request Broker Proxy Server MP Application Requests HTTPS HTTPS - Reply Event HTTPS - Notify Event Source Notification Service MP Service Notifications HTTPS - Acknowledge Network design is in progress around the outbound and inbound traffic through DMZ Back-end systems will be available to stimulate notifications toward end 07/early 08. Until then notifications will be simulated 6

7. Solution Use Case The following sequence of steps would be used to send a notification message to an MP system: • ERCOT Notification Service establishes an HTTPS connection to target MP system at port 443 of URL pre-specified by MP • Notify message is signed by ERCOT using the ERCOT server certificate (the same one used for external web services) • MP web service is invoked by ERCOT Notification Service, sending the Notify message • MP system validates the signature, using the ERCOT public key • Notify message is consumed by the MP system • MP system replies with a simple, unsigned Acknowledge message using the same HTTPS connection • ERCOT Notification Service receives Acknowledge message and marks the transmission as complete • Process is repeated for next notification or if a retry is needed according to established rules 7

8. Solution Approach MPs can use any server certificate of their choosing for HTTPS connections to their web server ERCOT will not use a client certificate when establishing an HTTPS connection to a MP notification listener service There is no need to manage additional client certificates over those needed for the external web services, greatly simplifying ERCOT implementation and administration MPs must be able to read ERCOT’s signature to verify that ERCOT sent the Notification MPs can not use Certificate Revocation Lists (CRLs), as ERCOT would not have a client certificate for each MP system Implementation is easier for MPs, as they don’t need to sign the Acknowledge messages (there is only non-sensitive data on the Acknowledge) 8 8

9. Steps to test Notifications & Listeners MP’s must get a new Nodal Test Certificate from ERCOT. The detailed instructions for this request will be communicated through the EDS meetings MP’s must get ERCOT’s public certificate from their Client Services representative in order to read ERCOT signatures MP’s must get the WSDL & XSD from ERCOT, published on http://nodal.ercot.com/readiness/sandbox/websvc/index.html MP’s are responsible for constructing the Notification listener service, using whatever technologies suits MP’s must notify ERCOT of the listener addresses (primary & secondary) and email details (via eds3@ercot.com) MP’s must set up their infrastructure to accept an https connection from ERCOT MP’s can schedule time with ERCOT to test out the service – we will provide 1:1 time with developers (viaeds3@ercot.com) ERCOT verifies the service by sending a test Notification to the MP’s service 9 9

10. Testing for EWS Loopback release • Testing was done a three levels • Development • Developers executed 19 formal unit tests, along with a large number of informal tests • Issue defects were fixed • iFAT • iFAT test team executed 133 formal test scripts • Common services (audit and error handling) 5 tests • External clients 11 tests • Functional 30 tests • Notifications 10 tests • Security 5 tests • XML validation 72 tests • Identified 36 issues or defects • All issues were resolved • Smoke test of Sandbox • iFAT test team executed 14 formal test scripts • Found that notifications fail because of the setup of the sandbox environment 10

11. Sample test case 11

12. Interface Design Process • Identify Integrations • System of Systems Architecture (SoSA) describes the enterprise level integration points needed for the overall Nodal solution. • Integration Design Authority (Technical & Business Architects), project teams and integration vendors work together to produce artifacts • Project Teams are accountable for determining what information they need • Project teams (CRR, MMS, CMM etc) create CSDs & Use Cases that indicate dependencies on information from other systems • Project teams determine what information is necessary and whether they can be supplied • Integration picks up from that point • Interface Specifications & Design • Integration artifacts are produced that contain: • Data Element Name, Element Attributes, Volumetrics, Data Frequency etc. • Business Triggering Events that drive the movement of information • The integration teams use these artifacts to analyze the interface and develop Use Cases • Identify gaps, integration characteristics, mismatches and transformations of data that is necessary between systems • Integrations specifications and Use Cases are the input to design and implementation of the integration between systems. • Exceptions are handled through IDA and Design ClearingHouse • Cases where projects have made conflicting assumptions • Cases where integration discovers missing or incorrect information elements that do not match 12

13. The integration factory constructs interfaces Inputs SoSA – use cases & domain Project CSDs & UCs Interface docs from source and target systems Integration design patterns Existing designs Source & target designs (CSD & Detailed Design) Numerous build inputs incl. Test Cases, Environment config, makefiles, … EDS Schedule EDS Definitions Project Schedules Interface Priorities Interface Build Plan Interface Specification Interface Design Interface Build FAT & ITEST Interface team assigned Interface design agreed Interface conforms with spec Interface specs agreed Seek project commitments Ramp up design and build teams Produce iteration plan for the interface Outline the information flows in the interface Information flows in the interface are enumerated Interface team resolves discrepancies in interface definition between source, target & system Define behavior and information contained in the interface Integration pattern selected Impacts on source and target assessed and incorporated Collaborate with Source & target systems teams Spec stubs and data Interface tests defined Updated design documentation Updated test and dev environments Updated source and libraries Stubs built Activities 13

14. Artifacts from the integration Sample artifacts that are in progress Designs are based on our pattern library: 14

15. Artifacts from the integration Designs are based on our pattern library: 15