DetectedIssue when using multiple payloads
This page documents an INM Workitem, i.e. an issue within scope of the INM Committee that either is still being discussed, or the resolution of which has not yet been included in an INM ballot.
See the discussion page for discussions.
If one sends 1 interaction containing mutiple requests, and some of those are rejected, and others accepted, how does the reciever communicate the reasons for rejecting some of them ? There's a detectedIssue for the ControlAct in the controlAct wrapper, but that's for the entire order, not for parts of it. Do we need detectedIssue classes related to fulfillment objects in the application response ?
- Currently we have deferred the entire issue to a future cycle by constraining an order interaction to 1 request object.
- INM to vote upon the motion "In message-based interactions with 1 single Control Act in EVN mood: The subject of a Trigger Event (represented by the Control Act in EVN mood) can only be rejected in its entirety. If any part of the subject can't be accepted by a receiver, it should be rejected and the reason should be conveyed in the DetectedIssue class of the rejection."
20070110: WGM. Above motion was moved. Discussed: can't we reject part of a message? v2 doesn't allow partial rejections. Difficulty in currently messaging partial acceptance/rejection in a message. Pharmacy has resolved this at the payload level, don't want to do this at the wrapper level. The vote (Rene/Michael, 10-1-0).
Nested controlActs
(Rene) now what if we have a message construct with nested EVN ControlActs? (as in an event replay message, or in some future batch structure). Does one have to reject the outermost controlActs if any of the level-2 controlActs is rejected? I guess not, but it makes the situation a bit more complicated than the draft motion above. Rene spronk 18:52, 5 Aug 2006 (CDT)
- Root level CACT atomic, more outermost ones not atomic? Charlie: incomplete set of use-cases, many ways of doing this, batch-wrapper related.
