Usually I have a definite opinion about what a BPMN construct means, and whether some diagram fragment is valid or not. Here I used to have an opinion, but now I’m not sure. I’m hoping a reader will set me straight. The issue is an intermediate event (e.g., message or timer) “floating” in a process or expanded subprocess alongside the regular flow, the one bounded by start and end events. The floating event has a sequence flow out, leading eventually to end event, but no sequence flow in. It’s just floating there.
I always thought this was illegal, but I’ve seen it in Appian diagrams and more recently in Active Endpoints. Michael Rowley from Active Endpoints, who knows a bit about it, says it’s legal in BPMN 1.1, and now I’m not sure. Here is what the spec says about intermediate events “in Normal flow”, i.e. not attached to activity boundary… (and the language is repeated verbatim in the IBM draft of BPMN 2.0):
Intermediate Events of the following types MUST be a target of a Sequence Flow: None, and Compensation. They MUST have one (and only one) incoming Flow…. Intermediate Events of the following types MAY be a target of a Sequence Flow: Message, Timer, Conditional, Link, and Signal. They MAY have one (and only one) incoming Flow.
Note – These types of Intermediate Events will always be ready to accept the Event Triggers (once) while the Process in which they are contained is active. They are NOT optional and are expected to be triggered during the performance of the Process.
That would seem to say “floaters” are allowed, at least for message, timer, conditional, and signal (link is special, not really an event). On the other hand, the semantics are not described. Michael says the BPEL mapping (non-normative) section suggests that if the trigger of the floater occurs, a new token is created, i.e. a parallel thread of this process (or subprocess) is instantiated, and in fact it can occur any number of times until the process or subprocess ends. Thus it acts like a non-aborting attached event, or at least the portion that runs within the context of the subprocess.
Hmmm. In that case, why does BPMN 2.0 add that bit about inline event subprocesses? And what does the mysterious Note (above) mean when it says that triggering of these intermediate events is “NOT optional and… expected… during performance of the Process”? If triggering the floater is not optional, it would not have to be floating; you could just draw a parallel sequence flow to it from the start event.
The language is baffling for sure, and no less so because it’s repeated in BPMN 2.0. Any ideas out there?
Tags: BPMN
8 Responses to “Are Floating Intermediate Events Valid?”
BPMN Training
NEW! Virtual classroom Jan 25-28. Find out more!
Learn BPMN the right way. Not just compliance with the spec, but maximum effectiveness as a common visual language. Methodology, patterns, best practices, organizing complex models.... Hands-on with a tool. Loads of exercises, both in class and post-class (with individualized help, certification of proficiency). 60-day license to Process Modeler for Visio included.
Available online and in 2-day public classes. Don't be left behind.
2010 public classes Online Jan 25-28, Chicago April 21-22, San Francisco June 30-July 1, DC September 15-16, New York November 3-4. Have 10 or more students? Private 2-day classes delivered at your site, with same tool and post-class certification. Contact me for pricing and details.
BPMN Method and Style
Both specs also contain a para which I read as conflicting with the one that quote
From Business Process Modeling Notation, v1.1 P37
° If the Start Event is used, then there MUST NOT be other flow elements that do not have incoming Sequence Flow—all other Flow Objects MUST be a target of at least one Sequence Flow.
° Exceptions to this are activities that are defined as being Compensation activities (have the Compensation Marker). Compensation activities MUST NOT have any incoming Sequence Flow, even if there is a Start Event in the Process level. See Section 10.3, “Compensation Association,” on page 129 for more information on Compensation activities.
° An exception to this is the Intermediate Event, which MAY be without an incoming Sequence Flow (when attached to an activity boundary).
This I read as requiring incoming sequence flow except when attached to boundary.
I suggest that a clean up is required in BPMN 2.0 spec at least.
I can’t think of any practical difference that you could infer from a floater distinct from an intermediate event with an inbound sequence flow. However, it may convey a difference to business people … in the case of a floater, the intermediate event could not be seen as being ‘prepared’ by the predecessor in the sequence flow.
I note that Intalio does not allow floating intermediate events … they are treated as start events and only one start event is allowed in a process.
Bruce – My understanding is that (at the moment in BPMN 1.1), all Intermediate Events are either a) attached to an Activity as an Interrupt Mechanism, or b) placed in between Sequence Flow (with only one incoming and one outgoing Sequence Flow).
Appian, while providing a fiarly accurate representation of BPMN, is bending the rules to suit some of the funcitonality native to their engine. I dont know the Active EndPoints use of the Intermediate Event.
Either way, Intermediate Event cannot be floating. Otherwise it is a Start Event – that is what the SE is for, starting a Thread of Activity. There is no reason why a Process cannot have multiple Start Events. The Flow Objects need not all be connected to one all seeing, all dancing process flow.
I will check with Steve next week at Think Tank (I am Pretty sure he will be there).
While the language of BPMN 2.0 may clear up the spec a little, I would not expect it to suddenly break the rules of the spec to support a couple of vendors who have mis-interpretted the original.
From the “BPMN Modeling & Reference Guide” (by myself and Stephen White, the main author of the spec
“Intermediate Events are placed within the Process flow to repre-sent things that happen during the normal operations of the Proc-ess and usually occur in between Activities. They may also inter-rupt the normal processing of an Activity. …Intermediate Events are either placed within the normal flow of a Process (i.e. between Activities), or they are attached to the boun-dary of an Activity to trigger an interruption of that Activity.”
The book is available from Future Strategies (www.futstrat.com)
Wow, two votes off the bat for “invalid” on the floaters. Thanks David and Derek. David, I have always interpreted the para you quote as reference to what used to be called “start activities”, i.e. activities with no sequence flows in. BPMN 1.1 extended that to all flow objects, but I try not to use that option. Derek, I’m not sure I agree that a process can have multiple start events that signify parallel threads instantiated at different points in time, e.g. by different events, if that’s what you mean. That is essentially the floater semantic with a different notation. Again, this is what BPMN 2.0 is calling inline event subprocesses; a special notation would not be needed if a second start event did the same thing. Maybe you are saying it was there all along but BPMN 2.0 is trying to make it clearer? In any case the language I quote in my post about intermediate events MAY have incoming sequence flow (not MUST) is repeated verbatim in the IBM-SAP-Oracle submission, so that part at least is no clearer.
Note added per “the man,” Steve White himself. Floaters are technically allowed (for some reason), but the meaning is the same as a sequence flow from the start event to the floating intermediate event. In other words, it is not an optional occurrence; the process will wait for this event and it can only be triggered once. So it’s fair to say that the way floaters are used in the wild – i.e., optional occurrence, can be instantiated multiple times – is invalid.
[...] had good luck with my previous BPMN “request for information” posting, so here is another one. Is it valid to end a [...]
[...] usage and tips 30 October 2008 — Panos Are Floating Intermediate Events Valid? The issue is an intermediate event (e.g., message or timer) “floating” in a process or [...]
Hi Bruce,
I recently started studying the BPMN 1.1 spec and I think this could be explained with the “Event Context” as described in 10.2.2 Exception flow. This is the only place where they mention it but I think it should be used to describe the difference between a start and an intermediate event.
They descibe that in order for an intermediate event to start an exception flow its event context has to be active (running) at the start of the trigger. I think this can be seen as: there is a token somewhere in it’s context (activity). This could also be used when an intermediate event is placed in a sequence flow. A token arrives and only then will the trigger be applicable. A floating intermediate event will never recieve a token, so can never respond to its trigger, because when the trigger arrives, its event context is not active. The difference between start and intermediate event would then be that a start event always has an active event context.
This of course is not written in the spec, but my view of how this should be seen. What do you think?
I found the part of the spec where floaters are forbidden:
p37 states:
If the Start Event is used, then there MUST NOT be other flow elements that do not have incoming Sequence Flow—all other Flow Objects MUST be a target of at least one Sequence Flow.
° An exception to this is the Intermediate Event, which MAY be without an incoming Sequence Flow
(when attached to an activity boundary).
So when there is a start event, intermediate events MUST have incoming flow, except when connected to a boundary of an activity.
When there is no start event, intermediate events can be floaters that start the same time as all other activities or gateways without incoming sequence flow.