BPMN 1.2 NO IDEA Avatar
  1. OMG Issue

BPMN12 — Section: 9.4, 9.4.1, 9.4.2

  • Key: BPMN12-34
  • Legacy Issue Number: 11634
  • Status: closed  
  • Source: TIBCO ( Justin Brunt)
  • Summary:

    We have been puzzling over the meaning of the MultiIinstance Paralllel Marker and believe that there’s a conflict in the description. We saw this in the 1.0 specification and then checked to see if the 1.1 specification had changed in any way but found it to be the same. We believe there needs to be clarification around the MultipleInstance loop MI_Ordering attribute with regards to the task marker symbol that should be used. Here’s the basic description (we’re giving table/figure references from v 1.1 draft of BPMN spec).… BPMN spec says that Standard loop will look like Figure 9.15 Image 1 And Multi Instance loop will look like Figure 9.15 Image 2 However in Table 9.20 Multi-Instance Loop Activity Attributes in the MI_Ordering attribute description it clearly states that… If set to Parallel, the Parallel marker SHALL replace the Loop Marker at the bottom center of the activity shape (see Figure 9.9 and Table 9.18). This suggests that a Multi-Instance Loop task that is set to sequential would actually have the Standard Loop Marker. The question is, which statement is correct, the first… “Standard Loop activities will have a marker that is a circle with an arrow and Multi-Instance Loop activities will have a marker that is two parallel vertical lines” Or the second… “A Parallel Multi-Instance activity will have a marker that is two parallel vertical bars. Standard loops and sequential multi-instance activities will have a marker that is a circle with an arrow on it”. These statements made in the BPMN spec seem to be contradictory. Now, to us, whether the task instances are performed in parallel or sequential is the most significant thing to display visually on the diagram. And therefore we actually think that the second statement should be true. However, whether the condition is evaluated once or on each loop iteration could also be significant enough to be visible in the diagram. We actually think that there are 3 significant pieces of information that BPMN is trying to convey with only 2 markers and associated attributes. § Separate Task instances are run in parallel. § Separate Task instances are run sequentially, and if so… o The loop exit condition is a Boolean expression and is re-evaluated on each loop iteration. o The condition is a Numeric expression that is evaluated only once before loop begins and specifies a maximum value for LoopCounter. We think that there are 2 possibilities to overcome this problem and clarify the meaning… 1) Add a new value to the Standard Loop TestTime attribute – OnceBefore – this states that the expression is numeric and specifies the number of loop iterations. Then remove the MI_Ordering attribute i.e. all Multi-Instance loops are parallel. It may be useful to introduce a new marker symbol to distinguish between OneBefore and Before/After (if it is deemed significant enough to been seen at diagram level). 2) Leave all the attributers as they are but introduce a new marker symbol for “The condition is a Numeric expression that is evaluated only once before loop begins and specifies a maximum value for LoopCounter” (i.e. a Multi-Instance Loop with MI_Ordering set to sequential. In either case, if all three pieces of information are deemed significant enough to been seen at diagram level, here are our suggestions… Multi-Instance + Parallel - use parallel bar symbol Standard Loop Before/After (Evaluated On every iteration) … You could, also distinguish between before and after by say, turning the symbol upside down for evaluate-before… Because the circle as a break in it then it suggests (maybe?) that the process engine stops to re-evaluate things each time round the loop. Multi-Instance + Sequential (or new Standard Loop + OnceBefore… Use circle with no break Because the circle has no break in it then it suggests (maybe?) that the process engine already knows how many times to go around.

  • Reported: BPMN 1.1 — Wed, 31 Oct 2007 04:00 GMT
  • Disposition: Resolved — BPMN 1.2
  • Disposition Summary:

    Suggested Resolution:
    Close, No Change: This issue is out of scope for the RTF and will be addressed by the response to
    the BPMN 2.0 RFP.
    Revised Text: None
    Disposition: Closed, deferred

  • Updated: Wed, 11 Mar 2015 01:53 GMT