Message Flow

Hi Daniel,

even though a task is allowed (please refer to Table 7.2, item "Fork", the first item on page 34 of the BPMN 2.0.2 specification) to have more than a single outgoing control flow, I personally regard this bad style. I prefer to explicitly specify how the successors get activated. The parallel gate used in your second variant is the one I would personally clearly prefer over your variant 1.

Variant 3 is a completely different story. In your variant 3 message flows instead of control flows are used. Well, a control flows typically is interpreted as a synchronous communication, but a message flow is definitely an asynchronous communication. As a result control flows and message flows imply completely different implementations with completely different warranties. Given a control flow I would presume a once-and-only-once delivery is warrantied. I would not assume once-and-only-once delivery to be guarantied for message flows unless this warranty is explicitly stated. Also I would assume different timing constraints.

Hope this helps.

/pica

Hello,

I agree with Carsten, the second variant is the closest to the truth. Omit the events: Information flow is always implied inside processes along the control flow. Different lanes are also intra-process, since they are part of the same Pool. By the BPMN specification Lanes have no special meaning other than an interpretation you give to them (e.g. systems, roles).

Message flows as in your variant 3 would only be used for inter-process communication, i. e. across different pools, never inside the same pool. Typically you place the message symbol between the Pools in that case, so it's clearly visible you have an interface between the processes there. Then you could consider using Receive Message Events (Start or Intermediate) in the receiving process or alternatively a Receive Message Task.

Regards, M. Zschuckelt

Hi Daniel,

Hello Mr. Zschuckelt,

on "truth":

The by far most important fact I have learned as consultant is, there are at least as many truths as people living on earth. I intentionally wrote "at least". I sometimes have to admit, being human, I myself have more than a single truth at a time depending on the very situation ;-)

This is also the reason I try hard to explicitly name the source of the truth in my statements (i.e. the OMG's BPMN 2.0.2 specification as before).

I also really like the single-source-of-truth approach in projects and always try hard to get it established. In my current project the definite-source-of-truth is a PTC Integrity IMS repository. As you may already recognized, I refuse to regard a file share a single-source-of-truth ;-)

/pica

Hello Mr. Zschuckelt,

I would be happy to get your opinion, or your "truth" on valid assumptions regarding warranties and constraints implied by control flows respective message flows.

/pica

Hello Mr. Pitz, hello Daniel,

as to my claims on Message Flow, see chapter 9.4 of the BPMN 2.0.2 spec. My claims on Lanes, see chapter 10.8.

As to my "truth": See chapter 10.2.1 of the spec. Process models serve very different purposes (private, public, executable) so in that sense depending on the purpose you are more or less free to make the conventions such that you can express what you want to express and your target group will be educated to understand it. The closer you stick to the standard described in the spec the less hassle you have when your purpose expands or shifts (e. g. mapping private models to executable models). Certainly you have to reduce your level of detail significantly when you model a business process compared to an executable process. My suggestions are based on real world conventions for business processes at a European sales and distribution entity of a company with a well-known worldwide brand. They are working with the ARIS platform.

As to my claim, that information flow is always implied along the control flow: Here you caught me. Yes, that is not part of the spec. In fact see chapter 7.2 where it is stated, that BPMN explicitly is not a data flow language. I think it is a safe assumption because even in a paper process before the introduction of computers your process token is a sign-off check list on a paper file that is handed from desk to desk, role to role, collecting the information, approvals, decisions etc. down the line. Any workflow engine will implement some data container to be passed along the process flow - with the process token as an absolute minimum content. So the warranty along the control flow should be, that the following step will receive the token (or any data associated with it). Since data modelling is not part of BPMN scope you cannot guarantee that all or even a certain set of gathered data will be passed on.

Message flows to another Pool are not defined to be asynchronous or synchronous. You could require synchronous communication (e.g. a HTTP communication), but you have to deal with the case, if that fails. My default assumption is asynchronous communication for message flows, but see figure 8.28 which models the response (without defining synchronous warranties, I reckon the example is asynchronous). If it is an external Pool, you cannot even be sure your communication partner still exists or that you get notified, if he doesn't. If it is an internal process you can imagine all types of message delivery (publish and subscribe, message aggregation, etc.), but even then you have to take into account, that the other process might not be listening for your message on an Intermediate Receive Message Event, because it terminated for some other reason. The safest message delivery method would be a Start Message Event, which instantiates a new process instance on message occurrence.

Hello Mr. Zschuckelt

Many thanks,

Merci bien,

Mille gracias,

und eine extra große Tüte Danke,

Carsten

Hi All

want to know the BPMN rules for connection between gateway to event. Do we allow to create the connection?

Hi,

I am not aware of any restrictions there. You could argue, that 2 events directly after a process split via parallel gateway don't make much sense. But after a process join with a parallel gateway (that is allowed also in BPMN), it may make perfect sense (event occurs after synchronisation of the two branches).

Hi Zach

i like to show the flow among main pool and black pool (please refer a diagram as shown below). I used Intermediate event (through) to show this situation, it's current? or any suggestion?

Hi Mazmee,

the Intermediate send message event is placed in your Pool, not in the Black box Pool (wouldn't be black box any more). From the event you model the message flow to the border of the Black box Pool. If you expect a response, you need a (Intermediate) Receive message event somewhere, which receives a message flow from the border of the Black box pool. See figure 9.12 in the Spec for an example of message flow between 2 black box pools. If one of the Participants in the message exchange is white box, the message flow originates/terminates at Message events or Message tasks inside that Pool. Optionally you can use the message symbol (Envelope pictogram) between the Pools, which is of type Cluster/data model and you could use it to assign an IE data model to describe the message content.

Hallo Daniel,

I think all the 3 solutions are incorrect.

The more simple is that you describe simply your functional need; the bpmn model will be simple

Hi Robert,

as any model does not cover all aspects of reality, you are right. But despite not being "the god truth" the second variant in most cases is the most helpful.

/Carsten