The MPI/API Replacement Working Group September 25, 2014
Agenda 1. Review response to real-time energy market (RTEM) mockup screens. 2. Overview of DRAFT Webservice design 3. Next steps 2
Mock-up User Interface Feedback Stakeholder Feedback: The presentation only covered self-scheduling offers. At the meeting it was stated that this was due to the RTEM screen being too complex. The RTEM market is the screen we use most often and its complexity is precisely the reason why it is important to see how it will be redesigned. IESO Response: The IESO’s IT staff, who are responsible for the MPI/API system development, are evaluating the timing for building the RTEM mock-up screens for this working group to review. The earliest expected turnaround time for a presentation of the enhanced RTEM design would be October 2014. 3
Mock-up User Interface Feedback (cont’d) Stakeholder Feedback: Based on the mock-up presented, this design does not seem to enhance usability. It looks like it would require more steps than the current version to update offers. As entering offers is a time sensitive process, anything that slows down data entry is problematic. We appreciate the IESO’s efforts to redesign the interface and hope that improvement of usability will be considered a top priority. IESO Response: The current product offering is being reviewed to specifically highlight the enhanced usability from the previous format to ensure that the time and energy being invested in this initiative will provide a more efficient product for the end user. The IESO continues to treat feedback as high priority during the stakeholdering process and anticipate the RTEM mock-up screens will provide system improvements. 4
Mock-up User Interface Next Steps 1. IESO would like to better understand the measures for complexity and usability. 2. IESO would like to extend the review period to gather input and develop design principles. 3. IESO will work with developers based on design principles. 4. Updated mock-ups will be presented in a future workgroup session. 5
Proposed Web Service Design Design Principles 1. Provide same functions currently available in MIM IDK 2. Adhere to industry standards (e.g. W3C) 3. Implement data validation via XML where applicable (e.g. Hour ending must be between 1 and 24) 6
Proposed Web Service Definition • A DRAFT Web Service Definition has been created in the form of a Web Service Definition Language (WSDL) file. • The WSDL will define the type of functions available and the input/output information. 7
Proposed Web Service Definition Operations 1. BidQueryOperation - Retrieve dispatch data (bids/offers) 2. BidUpdateOperation - Submit dispatch data 3. HealthCheckOperation - Retrieve API status and version 4. MarketStatusOperation - Retrieve IESO market status 5. MessageOperations - Retrieves system messages 8
DRAFT Web Service Definition WSDL File date – every message since input date. target – all, MP specific, user specific 9
DRAFT Web Service Definition WSDL File (Dispatch Data) a 10
Next steps 11
Next Steps Date Activities Expected Action Oct 9, 2014 Deadline for written Working Group to input for the web service submit written feedback design on the proposal Oct 23, 2014 IESO respond to written Review IESO response comments from working group TBD Review MP TBD requirements for Role Based Access Control 12
Next Steps (cont’d) Date Activities Expected Action Q1, 2015 Meeting to present Attend Presentation updated user interface proposal based on stakeholder feedback Q1, 2015 Meeting to present final Attend Presentation user interface proposal based on stakeholder feedback 13
Thank You! 14
Recommend
More recommend
