Talk:DetectedIssue when using multiple payloads

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)

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.