Responses should be responses

[radboudp]

In USEF / UFTP / Shapeshifter a choice was made to respond to messages using a separate XML message asynchronously to the request XML message with the sole reason to indicate if the message was correct or not. The response is very basic. It holds:

• Reference to the request MessageID (unfortunately in a specific field per response type)
• Result field: Either Accepted or Rejected
• RejectionReason: In case result is Rejection then a simple message explaining what was wrong.

However, a number of response message also contain business information:

• AGRPortfolioQueryResponseType : dsoView, timeZone, period
• DPrognosisResponseType : flexOrderStatus
• DSOPortfolioQueryResponseType : congestionPoint, timeZone, period

These responses are not the technical validation responses as they are intended. It also holds (in some cases) loads of data that needs to be retrieved. This should be handled differently, if it is desired to uphold this way of handling request and their technical validation. Of course, it is also an option to change this.

Option 1: Uphold the current way of handling technical confirmation of correctness / errors: These three message and responses need to be split into a true response type and some kind of "result" message that later follows:

• AGRPortfolioQueryType -> AGRPortfolioQueryResponseType (accepted/rejected) -> In case of "accepted" a new message type AGRPortfolioQueryResultType is send with the business data fields: dsoView, timeZone, period
• DPrognosisType -> DPrognosisResponseType (accepted/rejected) -> In case of "accepted" a new message type DPrognosisResultType is send with the business data fields: flexOrderStatus
• DSOPortfolioQueryType -> DSOPortfolioQueryResponseType (accepted/rejected) -> In case of "accepted" a new message type DSOPortfolioQueryResultType is send with the business data fields: congestionPoint, timeZone, period

Option 2: Dismiss the asynchronous technical confirmation of the request message and handle technical confirmation including validations synchronously: So, why do we send a complete separate HTTP message to indicate that the request had some errors. Systems should not have any problems keeping up in processing message and therefor there is no reason to process the validations inside the HTTP message processing. It is also ok when this takes a few milliseconds. Secondly, there also is a mechanism described in the protocol to return 429 response code when the load is to high. In addition, the "Accepted" response message functionally feels like a business "Accepted", while it is just a technical "Accepted". It means: "There are no errors in your message, I will process the content". And it does not mean "I agree with the content and I will do so." This is especially problematic for the FlexOrderType and FlexOrderResponseType. What is the exact meaning of "FlexOrderResponseType Accepted"?? Does this mean: Message receive, will think about it? Or "message content acknowledged order has been placed". I feel it is the latter, which is in that regard in contradiction with the "Accepted is just a technical Accepted" criterium. When an order is confirmed with a technical acknowledgement, then this would be much clearer if this was the HTTP OK, and nothing more. It would also be much clearer in regards to the three Response message types in which now business data is placed.

[tomwetjens]

Discussed: we don't see enough value in this for now.