Issue 9410: Update definition of merging behavior of Exclusive Data-Based Gateway (bpmn-ftf) Source: International Business Machines (Dr. Stephen White, wstephe(at)us.ibm.com) Nature: Uncategorized Issue Severity: Summary: Update the definition of the merging behavior of the Exclusive Data-Based Gateway. Currently, the Gateway just passes all Tokens through. The behavior should be changed to be exclusive in that it will allow the first Token to arrive through the Gateway, but ignore/consume all other Tokens from the same Token family. Resolution: Revised Text: Actions taken: March 2, 2006: received issue Discussion: Discussion: This issue will be resolved during the next BPMN FTF. Disposition: Deferred Defer: The potential complications of resolving this issue, particularly surrounding the formal definition of Token flow, requires that this issue be deferred so that it can be handled in a better way in BPMN 2.0. However, a couple of modifications to the specification are required to correct an error in how the Exclusive Data-Based Gateway was applied in an example. Revised Text: Section 10.2 "Sequence Flow Mechanisms," page 119: a) Second paragraph on the page: replace paragraph with the following paragraph: "Another merging situation is the Workflow Pattern Discriminator. In this situation, the multiple incoming Sequence Flow are parallel instead of alternative (see Figure 10.32). Thus, there will be two Tokens arriving (at different times) at the Complex Gateway preceding activity “D.” To satisfy the Discriminator pattern, the Complex Gateway must accept the first Token and immediately pass it on through to the activity. When the second Token arrives, it will be excluded from the remainder of the flow. This means that the Token will not be passed on to the activity, but will be consumed." (Note: there is a footnote included with the "Workflow Pattern Discriminator." text) b) Figure 10.33 ("Workflow Pattern #8 -- Discriminator"): Replace figure with the following Figure: Disposition: End of Annotations:===== ubject: BPMN Issue X-Mailer: Lotus Notes Release 7.0 HF85 November 04, 2005 From: Stephen A White Date: Thu, 2 Mar 2006 14:46:40 -0800 X-MIMETrack: Serialize by Router on D03NM690/03/M/IBM(Release 6.53HF743 | November 3, 2005) at 03/02/2006 15:46:43, Serialize complete at 03/02/2006 15:46:43 Description: Update the definition of the merging behavior of the Exclusive Data-Based Gateway. Currently, the Gateway just passes all Tokens through. The behavior should be changed to be exclusive in that it will allow the first Token to arrive through the Gateway, but ignore/consume all other Tokens from the same Token family. ________________________________________________ Stephen A. White, Ph.D. BPM Architect Business Innovation and Optimization IBM Software Group 714-505-6767 714-438-5590 wstephe@us.ibm.com Subject: RE: Merge gateway questions Date: Tue, 22 Aug 2006 18:51:47 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Merge gateway questions Thread-Index: AcbGHwMSY/mbz822Rvi6Cn5Fjis9DAAJtFTQ From: "Cummins, Fred A" To: "Stephen A White" , Cc: "BPMNFTF" X-OriginalArrivalTime: 22 Aug 2006 23:51:51.0461 (UTC) FILETIME=[F0619D50:01C6C645] Steve, That's not what exclusive means to me. That sounds like inclusive. Fred -------------------------------------------------------------------------------- From: Stephen A White [mailto:wstephe@us.ibm.com] Sent: Tuesday, August 22, 2006 3:11 PM To: conrad.bock@nist.gov Cc: BPMNFTF Subject: Re: Merge gateway questions > - A kind of merge that immediately passes along any tokens coming into > it (regardless of whether there are still upstream tokens). This is what the Exclusive Gateway does now. It acts as a "pass-through," allowing all Tokens that arrive to immediately continue. There is an open issue (9410) that is a request to change/extend the behavior of the Exclusive Merge so that it actually excludes some Tokens (i.e., let the first one through and exclude any (parallel) laggers. While we haven't actually started discussions on 9410, we have (as Frank Mentioned) discussed this behavior quite a bit. We have recognized a requirement to have exclusive merging, but have not yet figured out how to actually do it. > - Tokens arriving at an exclusive merge after an earlier token has > arrived and passed through. Right now they continue on through. As mentioned above, we have discussed how to get the Gateway to recognize and stop the appropriate Tokens. -Steve "Conrad Bock" 08/14/2006 08:01 AM Please respond to To "BPMNFTF" cc Subject Merge gateway questions Steve, et al, Has there been any discussion on these merge topics, didn't see anything about them spec: - A kind of merge that immediately passes along any tokens coming into it (regardless of whether there are still upstream tokens). - Tokens arriving at an exclusive merge after an earlier token has arrived and passed through. Thanks, Conrad Reply-To: From: "Conrad Bock" To: "'Stephen A White'" , "'Cummins, Fred A'" Cc: "'BPMNFTF'" Subject: RE: Merge gateway questions Date: Mon, 28 Aug 2006 12:39:02 -0400 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcbJWohxW3V45CFNTLCb3nS4/eRTcwBZdYBg X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: conrad.bock@nist.gov X-Spam-Status: No Steve, > Well, the merging behavior of the Exclusive Gateway is > definitely not exclusive. It is not really inclusive when > compared to the merging behavior of the Inclusive Gateway > either. I would call it a passthrough. Sounds like a serious terminology problem here. Did the latest resolutions clear that up? Conrad To: Cc: bpmn-ftf@omg.org Subject: RE: Merge gateway questions X-Mailer: Lotus Notes Release 7.0 HF242 April 21, 2006 From: Stephen A White Date: Mon, 28 Aug 2006 09:46:03 -0700 X-MIMETrack: Serialize by Router on D03NM690/03/M/IBM(Release 7.0.1HF269 | June 22, 2006) at 08/28/2006 10:46:03, Serialize complete at 08/28/2006 10:46:03 Conrad, I don't think that it is a terminology problem as much as the way that the merging behavior of the Exclusive Gateway is defined. Issue 9410 deals with this. We will discuss on Thursday and change the behavior (or change the terminology, perhaps). -Steve "Conrad Bock" 08/28/2006 09:39 AM Please respond to To Stephen A White/Irvine/IBM@IBMUS, "'Cummins, Fred A'" cc "'BPMNFTF'" Subject RE: Merge gateway questions Steve, > Well, the merging behavior of the Exclusive Gateway is > definitely not exclusive. It is not really inclusive when > compared to the merging behavior of the Inclusive Gateway > either. I would call it a passthrough. Sounds like a serious terminology problem here. Did the latest resolutions clear that up? Conrad To: "Cummins, Fred A" Cc: "BPMNFTF" , conrad.bock@nist.gov Subject: RE: Merge gateway questions X-Mailer: Lotus Notes Release 7.0 HF242 April 21, 2006 From: Stephen A White Date: Tue, 29 Aug 2006 14:15:57 -0700 X-MIMETrack: Serialize by Router on D03NM690/03/M/IBM(Release 7.0.1HF269 | June 22, 2006) at 08/29/2006 15:15:58, Serialize complete at 08/29/2006 15:15:58 Fred, I've put such a table on the site (http://www.bpmn.org/FTF/Issues/Gateway%20Table.htm). It can also be accessed through Issue 9410 (http://www.bpmn.org/FTF/Issues/Issue%209410.htm), which addresses the Exclusive merging behavior. All, Please review the table and send in any comments or questions. -Steve "Cummins, Fred A" 08/25/2006 08:11 AM To Stephen A White/Irvine/IBM@IBMUS cc "BPMNFTF" , Subject RE: Merge gateway questions Steve, Seems like we need a table of the different things we want these gateways to do, where we can clarify the differences and the appropriate graphs and names for them. The table that's in the spec doesn't do it. Fred -------------------------------------------------------------------------------- From: Stephen A White [mailto:wstephe@us.ibm.com] Sent: Friday, August 25, 2006 10:11 AM To: Cummins, Fred A Cc: BPMNFTF; conrad.bock@nist.gov Subject: RE: Merge gateway questions Fred, Well, the merging behavior of the Exclusive Gateway is definitely not exclusive. It is not really inclusive when compared to the merging behavior of the Inclusive Gateway either. I would call it a passthrough. -Steve "Cummins, Fred A" 08/22/2006 04:51 PM To Stephen A White/Irvine/IBM@IBMUS, cc "BPMNFTF" Subject RE: Merge gateway questions Steve, That's not what exclusive means to me. That sounds like inclusive. Fred -------------------------------------------------------------------------------- From: Stephen A White [mailto:wstephe@us.ibm.com] Sent: Tuesday, August 22, 2006 3:11 PM To: conrad.bock@nist.gov Cc: BPMNFTF Subject: Re: Merge gateway questions > - A kind of merge that immediately passes along any tokens coming into > it (regardless of whether there are still upstream tokens). This is what the Exclusive Gateway does now. It acts as a "pass-through," allowing all Tokens that arrive to immediately continue. There is an open issue (9410) that is a request to change/extend the behavior of the Exclusive Merge so that it actually excludes some Tokens (i.e., let the first one through and exclude any (parallel) laggers. While we haven't actually started discussions on 9410, we have (as Frank Mentioned) discussed this behavior quite a bit. We have recognized a requirement to have exclusive merging, but have not yet figured out how to actually do it. > - Tokens arriving at an exclusive merge after an earlier token has > arrived and passed through. Right now they continue on through. As mentioned above, we have discussed how to get the Gateway to recognize and stop the appropriate Tokens. -Steve "Conrad Bock" 08/14/2006 08:01 AM Please respond to To "BPMNFTF" cc Subject Merge gateway questions Steve, et al, Has there been any discussion on these merge topics, didn't see anything about them spec: - A kind of merge that immediately passes along any tokens coming into it (regardless of whether there are still upstream tokens). - Tokens arriving at an exclusive merge after an earlier token has arrived and passed through. Thanks, Conrad To: bpmn-ftf@omg.org Subject: Proposed Resolution for Issue 9410 X-Mailer: Lotus Notes Release 7.0 HF242 April 21, 2006 From: Stephen A White Date: Sat, 21 Oct 2006 22:16:43 -0700 X-MIMETrack: Serialize by Router on D03NM690/03/M/IBM(Release 7.0.1HF346 | August 4, 2006) at 10/21/2006 23:16:45, Serialize complete at 10/21/2006 23:16:45 This is intended for Ballot 4 http://www.bpmn.org/FTF/Issues/Issue%209410.htm Note: There wasn't time to finish the resolution for this issue. Thus, we will have to defer it for now and finish it during the next FTF Issue 9410: Update definition of merging behavior of Exclusive Data-Based Gateway Description: Update the definition of the merging behavior of the Exclusive Data-Based Gateway. Currently, the Gateway just passes all Tokens through. The behavior should be changed to be exclusive in that it will allow the first Token to arrive through the Gateway, but ignore/consume all other Tokens from the same Token family. Suggested Resolution: Defer: This issue will be resolved during the next BPMN FTF. Revised Text: None To: bpmn-ftf@omg.org Subject: Proposed Resolution for Issue 9410 X-Mailer: Lotus Notes Release 7.0 HF242 April 21, 2006 From: Stephen A White Date: Thu, 8 Feb 2007 15:26:43 -0800 X-MIMETrack: Serialize by Router on D03NM690/03/M/IBM(Release 7.0.2HF32 | October 17, 2006) at 02/08/2007 16:26:44, Serialize complete at 02/08/2007 16:26:44 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at omg.org This is intended for Ballot 7. http://www.bpmn.org/FTF/Issues/Issue%209410.htm We also voting to defer to the second FTF this in the first FTF. After much debate, we are again going to defer it to V2.0. But we did find an error in the text that we needed to fix. Issue 9410: Update definition of merging behavior of Exclusive Data-Based Gateway Description: Update the definition of the merging behavior of the Exclusive Data-Based Gateway. Currently, the Gateway just passes all Tokens through. The behavior should be changed to be exclusive in that it will allow the first Token to arrive through the Gateway, but ignore/consume all other Tokens from the same Token family. Suggested Resolution: Defer: The potential complications of resolving this issue, particularly surrounding the formal definition of Token flow, requires that this issue be deferred so that it can be handled in a better way in BPMN 2.0. However, a couple of modifications to the specification are required to correct an error in how the Exclusive Data-Based Gateway was applied in an example. Revised Text: Section 10.2 "Sequence Flow Mechanisms," page 119: a) Second paragraph on the page: replace paragraph with the following paragraph: "Another merging situation is the Workflow Pattern Discriminator. In this situation, the multiple incoming Sequence Flow are parallel instead of alternative (see Figure 10.32). Thus, there will be two Tokens arriving (at different times) at the Complex Gateway preceding activity .D.. To satisfy the Discriminator pattern, the Complex Gateway must accept the first Token and immediately pass it on through to the activity. When the second Token arrives, it will be excluded from the remainder of the flow. This means that the Token will not be passed on to the activity, but will be consumed." (Note: there is a footnote included with the "Workflow Pattern Discriminator." text) b) Figure 10.33 ("Workflow Pattern #8 -- Discriminator"): Replace figure with the following Figure: