Uploaded image for project: 'OASIS Energy Interoperation TC'
  1. OASIS Energy Interoperation TC
  2. ENERGYINTEROP-493

EiTender issues including spelling

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: wd33
    • Fix Version/s: wd34
    • Component/s: None
    • Labels:
      None
    • Resolution:
      Hide

      Changes as described.

      Add EiDistributeTender and EiDistributeEvent (parallel to EiDistributeQuote) [done wd29 in model] Include EiTargetType (with emix:interfaceType, geospatial, and group names).

      936 EiSend - should be EiRequestTender. Diagram has problems. Add EiDistributeTender. Withdraw should instead be Cancel/Canceled.

      Part of diagram duplicated, title "opt Check for Open Tenders" is confusing - change to "opt Check for Tenders"

      Indicate the the emixBase:uid is for that tender.

      Indicate that the CreatedTender sends back what was received; change to send IDs rather than artifacts.

      EC: if a UID for a tender could receive – suggest change to returning uidType for the response?

      Consider the multiple response pattern from EiEvent and EiQuote. Quote and Tender should look the same.

      Document in the specification that If you don't want a response, use DistributeTender

      Consider Market Rules market rulesa pplying to the values returned to restrict what's returned. Could use the "boolean" approach in EiEvent:TestEvent.

      Document in the specification that EiRequestTender can be from either Party. The return values are those for which I am also a party. Request Tender is not historical, it is only the outstanding tenders and might be implementation limited. Exception: when tenderIDs are passed, if the tender is available it will be returned even if expired or withdrawn.

      Consider POST 1.0 including a query string [0..1]" - but default to return all active (not withdrawn, have not expired) for the relevant party pair .

      Cancel - a list of UIDs (here TenderIDType) and delete the association with emixBase. This leaves only tenderID as the key. Same pattern for Canceled, 0..* tenderIDs.

      Note in the spec that Cancel and Canceled apply to the entire tender. Note in the spec that if the tender to be canceled was created with DistributeTender or CreateTender I already have the ID and the geolocation in my hand, so I don't need to have the full tender.

      partyRole - roles like ISO, LSE, MA, ... that list of things. ... at a high level in the architecture. Annotate the EiEnroll section with that fact.

      Show
      Changes as described. Add EiDistributeTender and EiDistributeEvent (parallel to EiDistributeQuote) [done wd29 in model] Include EiTargetType (with emix:interfaceType, geospatial, and group names). 936 EiSend - should be EiRequestTender. Diagram has problems. Add EiDistributeTender. Withdraw should instead be Cancel/Canceled. Part of diagram duplicated, title "opt Check for Open Tenders" is confusing - change to "opt Check for Tenders" Indicate the the emixBase:uid is for that tender. Indicate that the CreatedTender sends back what was received; change to send IDs rather than artifacts. EC: if a UID for a tender could receive – suggest change to returning uidType for the response? Consider the multiple response pattern from EiEvent and EiQuote. Quote and Tender should look the same. Document in the specification that If you don't want a response, use DistributeTender Consider Market Rules market rulesa pplying to the values returned to restrict what's returned. Could use the "boolean" approach in EiEvent:TestEvent. Document in the specification that EiRequestTender can be from either Party. The return values are those for which I am also a party. Request Tender is not historical, it is only the outstanding tenders and might be implementation limited. Exception: when tenderIDs are passed, if the tender is available it will be returned even if expired or withdrawn. Consider POST 1.0 including a query string [0..1] " - but default to return all active (not withdrawn, have not expired) for the relevant party pair . Cancel - a list of UIDs (here TenderIDType) and delete the association with emixBase. This leaves only tenderID as the key. Same pattern for Canceled, 0..* tenderIDs. Note in the spec that Cancel and Canceled apply to the entire tender. Note in the spec that if the tender to be canceled was created with DistributeTender or CreateTender I already have the ID and the geolocation in my hand, so I don't need to have the full tender. partyRole - roles like ISO, LSE, MA, ... that list of things. ... at a high level in the architecture. Annotate the EiEnroll section with that fact.

      Description

      Cancellation or cancel? 931

      936 EiSend - should be EiRequestTender. Diagram has problems. Add EiDistributeTender. Withdraw should be Cancel/Canceled.

      Part of diagram duplicated

      Distribute Tender - to geo area

      UID for that tender?

      Send back what I received.

      EC: if a UID for a tender could receive – suggest change to returning UuidTypes for the response?

      Retuirn all tenders that I've created - response for "not all" but success?

      Should I have partial success if only a; few can be done. Creation of a tender may or may not require a response, but just an ack that I received the payloads.

      T: two cases - comm are good enough, don't care if you accepted one - each of the five rejected should have an error message? Or "I got your message and may or may not do anything with it"

      Independent - respond with a list of UIDs of created - but sometimes you don't want (all of N California). If don't want a response, use DistributeTender (TB)

      EC: On create - ack of recei9pt of the message - list of IDs of created things. Make it optional - market rules? T: should define all three patterns. one is (a) Tell me about rans you've created; (b) these are the ones I've successfully created in my memory (c) I don't know what's going on - tello me everything about what you accept/reject (create)

      B: Apply same "boolean" as EiEvent TestEvent to this.

      EiRequestTender should be from either pParty - either. party. NOTE only those to which I was a Party.

      Is it only tenders made? Only ones that are ative? limit set of tenders that come back? T: Date? Value? Date range?

      ADD string - "query: string [0..1]" - but default to return all active (not withdrawn, have not expired) for the relevant party pair .

      Cancel - a list of UIDs (here TenderIDType) - as shown.

      Cancel and Canceled - - the entire tender. If it was created with DistributeTender or CreateTender I already have the ID and the geolocation in my hand, so I don't need to have the full tender.

      Same pattern for Canceled, 0..* tenderIDs.

      partyRole - roles like ISO, LSE, MA, ... that list of things. ... at a high level in the architecture.

      Event - does the UID change? UID and revision have to send back more than the UID.

        Attachments

        There are no Sub-Tasks for this issue.

          Activity

            People

            • Assignee:
              ecazalet Edward Cazalet (Inactive)
              Reporter:
              william.cox William Cox (Inactive)
            • Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: