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?
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.
My interpretation after I read the post and the comments is that the floating intermediate events receives a token when the context is activated and the context cannot be exited before the token has reached an end event or been join in a gateway.
What I propose is semantics that is exact the same as adding a parallel gateway on the start events sequence flow splitting a token to the floating intermediate event. This was suggested in the original post.
I have seen this in slides where a floating/catching intermediate message event has been used to synchronize with another pool. In this case it was clear that the event was not optional because it was (parallel) joined with the “happy flow” starting from the start event of the context.
To me it make sense because you cannot come late to the intermediate event such that you miss the event trigger (this has been debated as well) and you do not have to think about when to do a parallel split. I see this as a preferred patten, as you (i) don’t have to stop and wait for the event trigger rather join it when the data is needed and (ii) you don’t have to write lines from the parallel split. There is a danger with this because you must be sure that the flow eventually will pass the join gate (and the event will trigger) or you cannot end the context less then with a terminate. This is of course mitigated if the floating intermediate event is placed in a sub-process where it is only activated if the sub-process is engaged by a token.
This semantics is also logic if you think of the fact that it cannot start a process,
it could be used as the first flow object (start event) of a sub-process but only if there are no start events and no other flow objects without incoming flows. In this case it gets its token from the call of the sub-process (not an event sub-process) equivalent to a none start event with a sequence flow to the intermediate event.
I am going to implement work-flows based on BPMN 2.0 and want to know if I should place a token at a floating intermediate event when the context is reached? As I wrote above this is my opinion right now. I don’t see how correlated messages can be caught by an event handler otherwise. It would be nice if adding/removing the event handler would be synchronized with a token entering/leaving in all cases also including the floating intermediate event.
If the sub-process is needed over and over again the event sub-process can be used. The non-interrupting variant creates a parallel token each time it is triggering. The interrupting will exit the context when it is done.
I didn’t expect a comment on this post NOW, as it predates BPMN 2.0. In any case, a “floating” intermediate event in BPMN 2.0 is what is called an implied start node. Implied start nodes are not allowed if there are any real start (or end) events in the process level… which is almost all the time. So my position now is just don’t use them. This is the point jvoesten makes above.