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.
This page documents a Resolved, but not fully actioned MnM Hot Topic, i.e. a methodology issue requiring a resolution from Modeling and Methodology.
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."
Issue
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, 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.
Discussion
(Gaby Jewell, Feb 2005) This is an issue today. In the UK, we're receiving a list of appointment slots available for referrals. As we process the list, we may have issues with none, one, many or all of the slots. We process he slots that are valid and return an error for each slot that had an issue. We send one acknowledgement message with a list of errors--could be a long list of errors! No matter what we do, it's wrong (other than "AA" for no slots with issues and "AE" for all slots with issues).
(Rene) That's even less granular than my intention. How doesn one express "I reject slot #3 for reason Y", and "I reject slot #17 for reason Z", and "I accept slot #25, but with the following warning W associated to its acceptance" ? But for sure, just stating that half of them are "acceptable" whereas the other half is not is already problematic.
(Lloyd) I'm not terribly comfortable with an interaction that isn't being treated as a single unit of work. I.e. Either accept the entire interaction or accept none of it, but don't accept bits and pieces. If you need to, reject the whole thing, and then indicate which pieces you actually had problems with. I had proposed turning DetectedIssue into a physical class complete with a 'location' pointer so you could refer to which specific element in the request you weren't happy with. E.g. address repetition 5 or component 3 or whatever. However, it got voted down because of need for greater discussion within INM.
- This would mean INM would have to make a motion like "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." Rene spronk 18:52, 5 Aug 2006 (CDT)
(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)
WGM September 2006
Discussion joint Mnm/INM:
Does CACT represent a single unit of work (rejected or accepted as a whole). There are use-cases, do all 5 or none, others I want you to do 1,2,3,4,5 (seperately). Distinction is what you group in a singe request. Grahame: need to separate biz issues in payload from biz issue communicated in MCCI wrappers. Woody: need to determine what the unit of work was when tne order was sent. Sender makes distinction.
Strawvote: rule that says CACT represents a unit of work (atomic transaction). Accept or reject that unit of work as a whole. Substitution rules may apply (strawvote, 15-3-4)
Root level CACT atomic, more outermost ones not atomic? Charlie: incomplete set of use-cases, many ways of doing this, batch-wrapper related.
Note: INM to approve motion, revisit atomicity of transactions if&when OO has a use-case/question related to it.
