DW

Hello Community :)

I have a question:

I would like to design a Message flow from Task A to Task B AND Task C.

A messages {B and C}.

Im confused about the different possibilities to design a message flow.

Which one is correct to "inform" other lanes and start a task.

 

*edit: okay, i made a big fault to confuse pools and lanes.

Best Regards

 

by Carsten Pitz
Posted on Thu, 04/05/2018 - 16:03

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

0
by M. Zschuckelt
Posted on Thu, 04/05/2018 - 18:03

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

0
by Carsten Pitz
Posted on Fri, 04/06/2018 - 07:49

In reply to by 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

0
by Carsten Pitz
Posted on Fri, 04/06/2018 - 07:53

In reply to by M. Zschuckelt

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

0
by M. Zschuckelt
Posted on Fri, 04/06/2018 - 11:10

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.

0
by M. Mazmee Wahab
Posted on Wed, 04/11/2018 - 11:09

Hi All

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

0
by M. Zschuckelt
Posted on Mon, 04/16/2018 - 09:43

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).

0
by M. Mazmee Wahab
Posted on Wed, 04/18/2018 - 02:51

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?

 

 

 

File attachments
0
by M. Zschuckelt
Posted on Fri, 04/20/2018 - 13:53

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.

0
by Robert Page
Posted on Sat, 06/09/2018 - 13:34

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

 

0
by Carsten Pitz
Posted on Sat, 06/09/2018 - 14:49

In reply to by BpmAuSoleil

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

0

Featured achievement

Rookie
Say hello to the ARIS Community! Personalize your community experience by following forums or tags, liking a post or uploading a profile picture.
Recent Unlocks

Leaderboard

|
icon-arrow-down icon-arrow-cerulean-left icon-arrow-cerulean-right icon-arrow-down icon-arrow-left icon-arrow-right icon-arrow icon-back icon-close icon-comments icon-correct-answer icon-tick icon-download icon-facebook icon-flag icon-google-plus icon-hamburger icon-in icon-info icon-instagram icon-login-true icon-login icon-mail-notification icon-mail icon-mortarboard icon-newsletter icon-notification icon-pinterest icon-plus icon-rss icon-search icon-share icon-shield icon-snapchat icon-star icon-tutorials icon-twitter icon-universities icon-videos icon-views icon-whatsapp icon-xing icon-youtube icon-jobs icon-heart icon-heart2 aris-express bpm-glossary help-intro help-design Process_Mining_Icon help-publishing help-administration help-dashboarding help-archive help-risk icon-knowledge icon-question icon-events icon-message icon-more icon-pencil forum-icon icon-lock