Multiple start event with messages

[Bernadette Hill]

Hi

I am reviewing a process and would like to simplify it. It involves 6 different entry points which are all emails being received and only one is required to start the event. The previous author of the process had 5 pools with messages coming from each with a message event to an exclusive gateway (see section of process image below). I think this is overly complicated and would like to use a multiple start event with each of messages and not use the individual pools. Can someone advise of how this could be done? Thanks in advance.

[Neal McWhorter]

Use a receive task as the first activity in the target process and follow it by an event gateway which branchs to all the message event types. Send your input events to the receive task.

--
--
You received this message because you are subscribed to the Google
Groups "BPMN Forum" group.
Public website: http://www.bpmnforum.com
To post to this group, send email to BPMN...@googlegroups.com
To unsubscribe from this group, send email to
BPMNforum+...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/BPMNforum?hl=en_US?hl=en

---
You received this message because you are subscribed to the Google Groups "BPMN Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to BPMNforum+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/BPMNforum/279f7e3d-0203-4c34-bf56-ef830dfd77f8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Michelle McWilliams]

I think it kind of depends upon your need.  If you don't need to explicitly make each message receive start it's own icon, you can make one icon, and attach a note that says what would be a qualifying message.  

Or, as Neal mentioned, you could use an event gateway that dictates that whichever happens next, first, is the path you go down.  
Attached visual.  

--
--
You received this message because you are subscribed to the Google
Groups "BPMN Forum" group.
Public website: http://www.bpmnforum.com
To post to this group, send email to BPMN...@googlegroups.com
To unsubscribe from this group, send email to
BPMNforum+...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/BPMNforum?hl=en_US?hl=en

---
You received this message because you are subscribed to the Google Groups "BPMN Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to BPMNforum+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/BPMNforum/279f7e3d-0203-4c34-bf56-ef830dfd77f8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

--Michelle

[Michelle McWilliams]

p.s.  labelling in the second instance would be a bear.  ha ha :p 

--

--Michelle

[Bernadette Hill]

Thanks for the feedback. After posting the message yesterday, i had another go. What do you think of this? Similar to Michelle's. I think there should be message icons for each as the source of the message is from different locations. I was trying to avoid multiple swim lanes. The text on the messages is where the message came from. The process description will cover a lot more detail.

[Neal McWhorter]

This is technically incorrect as there is no reception of the event in your flow and the exclusive gateway is also superfluous as an event gateway already triggers only one path out. 

Having said that many or even most BPMN diagrams are technically incorrect because they are intended as communication pieces rather than targeted for an execution engine. If this works for you that's fine.  I'd just suggest that you document for your organization that this is a pattern that is not standard to avoid confusion.

Neal

--
--
You received this message because you are subscribed to the Google
Groups "BPMN Forum" group.
Public website: http://www.bpmnforum.com
To post to this group, send email to BPMN...@googlegroups.com
To unsubscribe from this group, send email to
BPMNforum+...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/BPMNforum?hl=en_US?hl=en

---
You received this message because you are subscribed to the Google Groups "BPMN Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to BPMNforum+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/BPMNforum/61261b63-f32e-4df3-8371-0fbfacb43e1c%40googlegroups.com.

[Michelle McWilliams]

I agree about the closing exclusive  gateway.  I think inclusive is better.  

I am not sure what Neal means by receive event.  Receive message is an event, but it does need to show the communication flow from its source.  

What I didnt realize is this is a multiple start process.  Before you had the receive messages after a task.  A multistart can be drawn two diff ways but i will have to show later....

To view this discussion on the web visit https://groups.google.com/d/msgid/BPMNforum/CAJ%3DOUkvXAbT3Sg-rQL_QzBn3n50yss_DtZF5ziK4unp2B4j%3DPg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

--Michelle

[Michelle McWilliams]

Ok, I have drawn out three ways to model a multi start process w messages received. 
One is using a multi start event icon, which essentially means "which one is triggered of the next following events, is the path to go down". 
The second example is an old way that Bruce Silver mentioned used to be how multi start events were drawn, and can still be, but informally and if your diagram doesn't need to be consumed by a process engine software. 
The third example is like your most recent diagram, but with a few corrections of work flows, labels, and inclusive gateway. 

Whether something is technically accurate can too, I believe, depend upon the BPM software that is being used.  Not all software recognizes all symbols, or have limitations in terms of model complexity.  
But to Neal's point, many diagrams are more for communication purposes rather than to be consumed and analyzed by BPM software engines.  In which case, let it be as accurate following BPMN rules as possible, 

but you will have a little more creative leeway with a few things.  

--

--Michelle

[Neal McWhorter]

All,

There are a few points I'd like to make about the examples I've seen to clarify how to use the standard. 

• An incoming inclusive gateway is used to bring together multiple flows and cause the process to wait until all these flows arrive. This is a synchronization point. An incoming inclusive gateway isn't appropriate in these  flows because since only one flow will ever arrive meaning this process would never complete. 
• An exclusive gateway defines that it will be triggered when the first incoming flow arrives. Since the process is event-based as it is defined it can never have more than one active flow. Adding the exclusive gateway therefore is confusing because it seems to contradict this. In practice the exclusive gateway is meaningless in this case. 

I've attached an example below of what I believe is the best way to model this. 

To view this discussion on the web visit https://groups.google.com/d/msgid/BPMNforum/CA%2BDqCEhqkVaLX59%3DqK1gnmmxTW5-4tC2-38%3DUsA5nYMFvvEaBQ%40mail.gmail.com.

[Neal McWhorter]

Attaching diagram as a PDF since it doesn't appear to have embedded correctly.

[Michelle McWilliams]

- am having difficulty finding details on the double circle in Bruce’s book so interested Neal’s use there.   

🙂

On Fri, Jul 12, 2019 at 6:23 PM Michelle McWilliams <mae...@gmail.com> wrote:

p.s. also the labeling of the pools, BPMN method and style asks that the outside of the pool (the left edge) be labeled as the process name, and the lane itself be labeled as the role/department, and asks that the message flows also be labeled with the "what" that is being sent.  

On Fri, Jul 12, 2019 at 6:19 PM Michelle McWilliams <mae...@gmail.com> wrote:

I see what Neal is saying about using an exclusive (X) gateway.  *Referencing "BPMN Method & Style by Bruce Silver".... In chapter 9 of this book, Bruce does agree that the inclusive (O) gateway should only be used in the event of conditional/conditional parallel paths.  
So, what's great, is that he disagrees with both Neal and I on what should be done then when it's an event gateway - which is a gateway OR a start that indicates an exclusive path follows.  He says to use none, unless there is another path split right after.  I've made a fourth example of what I drew, based upon the book, and am attaching the .pdf.  BTW I corrected my labeling of the receive message events (from passive to active voice).  

I don't agree with what else I see on Neil's map though; this is what I see or how I read it: 
- unnecessary extra swimlanes.  unless each of those pools/lanes is going to map out the tasks of those roles/processes, those can just be collapsed pools that send the message to the process to trigger it to start. 
- receiving messages seems to happen twice in the diagram - before and after the event gateway.  
- the throwing pools aren't using throwing message icons.  which makes me wonder how Neal is using those icons (the empty double circle).  in my training w Bruce, those were meant to indicate an intermediate thing happened in the business that the process is waiting on, not otherwise provided for in the BPMN iconography.... such as "training occurs" - and is used relatively rarely.  

To view this discussion on the web visit https://groups.google.com/d/msgid/BPMNforum/CAJ%3DOUksq%3Dd%2BaK7-DNg3Jg%3DGFrkeAHWmeF3DV8%3DEqhOOd9qDZww%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

--Michelle

--

--Michelle

--

--Michelle

[Michelle McWilliams]

I see what Neal is saying about using an exclusive (X) gateway.  *Referencing "BPMN Method & Style by Bruce Silver".... In chapter 9 of this book, Bruce does agree that the inclusive (O) gateway should only be used in the event of conditional/conditional parallel paths.  
So, what's great, is that he disagrees with both Neal and I on what should be done then when it's an event gateway - which is a gateway OR a start that indicates an exclusive path follows.  He says to use none, unless there is another path split right after.  I've made a fourth example of what I drew, based upon the book, and am attaching the .pdf.  BTW I corrected my labeling of the receive message events (from passive to active voice).  

I don't agree with what else I see on Neil's map though; this is what I see or how I read it: 
- unnecessary extra swimlanes.  unless each of those pools/lanes is going to map out the tasks of those roles/processes, those can just be collapsed pools that send the message to the process to trigger it to start. 
- receiving messages seems to happen twice in the diagram - before and after the event gateway.  
- the throwing pools aren't using throwing message icons.  which makes me wonder how Neal is using those icons (the empty double circle).  in my training w Bruce, those were meant to indicate an intermediate thing happened in the business that the process is waiting on, not otherwise provided for in the BPMN iconography.... such as "training occurs" - and is used relatively rarely.  

To view this discussion on the web visit https://groups.google.com/d/msgid/BPMNforum/CAJ%3DOUksq%3Dd%2BaK7-DNg3Jg%3DGFrkeAHWmeF3DV8%3DEqhOOd9qDZww%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

--Michelle

[Neal McWhorter]

Bruce and I have similar but slightly different approaches. He is less of a literalist in terms of the standard than I am. I tend to stick to things like the standard's definition that message flow can only occur between Pools. However both of us argued during the BPMN standard development process that machine execution was not the primary usage pattern for the standard and history has borne that out.

Still, the basics are agreed upon by most everyone so the usage in your first 3 diagrams of an inclusive incoming gateway is incorrect as I previously stated. I The standard drives this means that all incoming flows must reach the gateway before the flow continues which as I understand the process is not the desired behavior. The 4th diagram looks fine to me other than the lack of use of Pools.

While Bruce's book is a great introduction I urge you to read the standard itself... which is quite approachable to those not immersed in OMG standards... To gain a fuller understanding of the trade-offs that Bruce suggests.

To view this discussion on the web visit https://groups.google.com/d/msgid/BPMNforum/CA%2BDqCEhaX5Lj9k%2BZChQPaic%3D2h%2BmWAZnsXgf3e8A-vGm1kg6PQ%40mail.gmail.com.

[Michelle McWilliams]

All of my diagrams have message flows coming from collapsed pools.  

To view this discussion on the web visit https://groups.google.com/d/msgid/BPMNforum/CAEey8e8dup3TuY6rbSrxtLtmOA0h%2BP2hYZ6jBAbbndR8O7GT1w%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

--Michelle