Uploaded image for project: 'OASIS Energy Interoperation TC'
  1. OASIS Energy Interoperation TC
  2. ENERGYINTEROP-536 Response and EiResponse issues
  3. ENERGYINTEROP-534

It is not clear in the spec whether the response operation for both EIEvent and and EIQuote services are mandatory or not.

    XMLWordPrintable

    Details

    • Type: Sub-task
    • Status: Closed
    • Priority: Major
    • Resolution: No Action
    • Affects Version/s: wd27
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Environment:

      Ed Koch

    • Proposal:
      Hide

      Make sure that in the text of the document that the response operations for both the EIEvent and and the EIQuote services are not mandatory and that in some case they will not be required.

      Show
      Make sure that in the text of the document that the response operations for both the EIEvent and and the EIQuote services are not mandatory and that in some case they will not be required.
    • Resolution:
      Hide

      Using Event as an example, if an Event is created using CreateEvent I believe that a CreatedEvent should always follow. We have allowed for asynchronous communication to be initiated in the PULL pattern wherein a list of events is queried for and then a CreatedEvent is issued in response; but this implies that the CreateEvent already existed.

      A rule of thumb:

      Create is always followed by Created
      Request is always followed by Reply

      Cancel and Delete do not necessarily require Canceled and Deleted operations. Normally in implementation an identifier is passed to reflect the object to be canceled of deleted and an optimistic operation is assumed, that is, if you have received an HTTP 200 Status OK you know the other system received the request and if you don't later hear back via an error return that something failed, that the operation completed successfully. The only time a Canceled or Deleted operation would normally be done is if something other than "yep canceled/deleted" is needed to be passed to the calling system.

      Distribute never gets a return.

      See section 6.5 in WD32

      Show
      Using Event as an example, if an Event is created using CreateEvent I believe that a CreatedEvent should always follow. We have allowed for asynchronous communication to be initiated in the PULL pattern wherein a list of events is queried for and then a CreatedEvent is issued in response; but this implies that the CreateEvent already existed. A rule of thumb: Create is always followed by Created Request is always followed by Reply Cancel and Delete do not necessarily require Canceled and Deleted operations. Normally in implementation an identifier is passed to reflect the object to be canceled of deleted and an optimistic operation is assumed, that is, if you have received an HTTP 200 Status OK you know the other system received the request and if you don't later hear back via an error return that something failed, that the operation completed successfully. The only time a Canceled or Deleted operation would normally be done is if something other than "yep canceled/deleted" is needed to be passed to the calling system. Distribute never gets a return. See section 6.5 in WD32

      Description

      There is a requirement that the EIEvent and EIQuote services need to support interaction patterns that allow the messages to be PUSH'ed and/or PULL'ed from the VTN without requiring a response by the VEN, (e.g. broadcast prices or event information). The diagrams seem to imply that a response is always required and it should be made clear in the text that responses are not mandatory in order to support the broadcast use cases.

      See also ENERGYINTEROP-544 and ENERGYINTEROP-533

        Attachments

          Activity

            People

            • Assignee:
              ed.koch Ed Koch (Inactive)
              Reporter:
              ed.koch Ed Koch (Inactive)
            • Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: