Send message from task inside sub-process

[Rowan]

If in BPMN2 I've got a task inside a sub-process that sends a message
to something in a different pool, how do I show this? The method of
showing it needs to work (a) on the sub-process diagram, (b) on the
main process diagram when the sub-process is expanded, and (c) on the
main diagram when the sub-process is collapsed.

The BPMN2 standard says that message flows from sub-processes are
allowed, and I can create them with the tool I'm using (Visual
Paradigm) but I can't see how to create the message flow in the sub-
process diagram from the task that sends the message to the "edge" of
the sub-process.

Thanks - Rowan

[Neal McWhorter]

Rowan,

Good question. This is something I've heard asked many times. The key to understanding this situation is to keep in mind that a message event (I'm assuming that's what you mean when you say a message) can only be thrown in one pool and caught in another pool. Because of this it isn't possible to do directly what you're talking about. If a message was shown being thrown from a subprocess and then going from that process to the boundary of the containing process (or really any other process in the same pool) then that process would have to contain a catching message event. But that's impossible because a message event can't be caught in the same pool where it is thrown. 

If this seems unnatural you have to understand that showing the message going from the subprocess to any other process basically has no semantic significance. So from an operational standpoint showing it the way you suggest wouldn't generate any executable behavior. From a diagrammatic standpoint though it would be really nice to have the ability to "see" message events that are thrown from a subprocess somehow shown on a diagram. Strictly speaking there isn't anything to prevent a tool from implementing a notation for showing this but BPMN doesn't define any way to do this. If your tool allows it you can just draw the flow from the message event to the boundary of the parent process and back out from that until it leads to an outgoing message event. That approach isn't conformant but it is visually intuitive.

Neal McWhorter

Principal | Enterprise Agility

Business Vision Delivered

www.enterprise-agility.com

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

[Rowan]

Neal,

Thanks for your helpful reply. I'm going to display my ignorance here!
I'm not using a message "event" to create the message (as far as I
know). I'm using what my tool calls a Send Task. Nor am I (as far as I
know) "throwing" or "catching" messages (although I suppose that's
what it may be called technically). Here is the sort of diagram I'm
creating: http://www.sylvester-bradley.org/rowan/images/MessagesExample.png
Sales Enquiry is a message from a "black box" pool to a message start
event in a different pool.
Credit Check Request is a message from a Send Task in one pool to a
Message Start Event in another pool.
Credit Check Response is a message from a Send Task in one pool to a
Mesage Intermediate Event in another pool.

I'm using these constructs because to me, from the palette of objects
available, they seemed to represent most closely what people actually
do. I.e. sending a message is something that someone actually has to
do (a task) not something that just happens (an event). Receiving a
message _is_ something that just happens (an event), and it can either
come "out of the blue" (a start event), or it can be something you
were waiting for before you could continue with your work (an
intermediate event). This thinking leads me not to use message end
events. But this is just what I've worked out for myself, not what's
necessarily best practice.

The question about messages from within sub-processes arises if I want
to put the details of the credit check process into a sub-process,
like this:
http://www.sylvester-bradley.org/rowan/images/MessagesSubprocessExample.png
I can, as shown here, draw a message flow from the sub-process to the
Message Intermediate Event in a different pool, but what do I show on
the sub-process diagram? There is nowhwere for the message flow to go
to.

Is this the right way of showing these messages? If the way I'm using
the BPMN symbols is wrong, or if there is a better way, it would be
great to know that!

I should say that at the moment I'm not executing these processes -
I'm purely using the diagrams as a means of recording the manual
processes and agreeing with all stakeholders what they are. However,
the next stage is to move on to improving the processes and automating
them where possible, so I would like as far as possible to produce
executable processes, or processes which can be easily converted to
executable.

Many thanks - Rowan

> >http://groups.google.com/group/BPMNforum?hl=en_US?hl=en- Hide quoted text -
>
> - Show quoted text -

[Thomas Röhrig]

Rowan,

i don't see any problems in what you do. You may put your credit check
into a sub process. From execution point of view, the result of the
subprocess is available in the main process and this could be send to
the sales pool with an event, task, whatever you want.
That's the way we do it in IYOPRO.

Best, Thomas

[Neal McWhorter]

Rowan,

Thanks for clarifying things. Let me start by addressing the difference between a "Send Task" and a "Throwing Message Event". 

Basically the only real difference between the two is that by being an "Activity" the "Send Task" element can have things like boundary events and performers. Other than that they are functionally equivalent. I like the idea that if someone is performing the work that you would use a "Send Task" instead of a "Throwing Message Event" but from an execution standpoint there is no difference. The same is true for the "Receive Task" vis-a-vis the "Catching Message Event". 

Now that I see your diagram I better understand what you're trying to accomplish. You appear to have 2 pools that have a protocol between them where a message is sent from the top pool to the bottom pool and then a response is sent from the bottom pool to the top pool. Internally the response message is coming from the "Send Result" activity but you don't want to show it this way. 

BPMN 2.0 has a variety of ways of handling this based upon how complex you need to get. The simplest approach is to create what BPMN calls a "public process" to contain your "Credit check subprocess". That basically means that the only thing any other process can see is the set of messages sent by that process and the ordering of those messages. Your "Credit check subprocess" would then become a private process which must conform to the interface definition of the "public process" that contains it. Unfortunately the standard doesn't define any visual way of representing this so it's all pretty much behind the scenes settings. It's OK to not show the message flowing from the "Send result" activity because that is really just visual candy to BPMN that has no real semantics. The real definition of the connection between a message sent and a message received is all done behind the scenes in the various attributes of the activities. 

This is just the beginning of what BPMN 2 has to offer for these kinds of situations. You can also get much more abstract by creating collaborations and conversations which are abstract protocols where either side could be any process that conforms to the overall protocol. This stuff starts to get a bit complicated so you may want to checkout the standard itself to really fully understand this or pickup one of the many books out there that digest the standard a bit more. I'm also happy to continue to try to answer any questions that you have.

Best of luck!

Neal McWhorter

Principal | Enterprise Agility

Business Vision Delivered

www.enterprise-agility.com

[Rowan]

I've now got to the relevant part of Bruce Silver's Method & Style
book (which we must remember was written 2 years ago before BPMN2 was
finalised). He says a couple of interesting things about this:

1. A Send Task and a Message Intermediate Event are semantically
identical, _including_ that a Send Task _cannot_ have a performer, and
that it is completed instantly as soon as the flow reaches it. He
recognises that this does not represent what happens in real life,
where a person actually has to compose the message and send it, so he
recommends using a User Task for humans sending messages. This seems a
shame, since I think the use of the envelope symbol on the rounded-
rectangle is useful to identify tasks that send messages, but I
suppose if the underlying model is not going to be correct we should
not use it. Is this still correct, and current thinking?

2. That the correct way of showing messages sent from tasks inside a
sub-process is to include on the sub-process diagram the pool to which
you are sending or from which you are receiving the message, which
should be named identically to the same pool on the main diagram. It
had not occurred to me that this was possible, but my tool (Visual
Paradigm) seems to allow it, and it seems to neatly overcome the
problem I've been having with this, so that's what I will do...

Thanks - Rowan

On Apr 5, 8:40 pm, Neal McWhorter <neal.mcwhor...@gmail.com> wrote:
> Rowan,
>

> >http://www.sylvester-bradley.org/rowan/images/MessagesSubprocessExamp...

> > > >http://groups.google.com/group/BPMNforum?hl=en_US?hl=en-Hide quoted

[Neal McWhorter]

Rowan,

1) I double-checked and I see no restriction in BPMN 2.0 that a Send Task cannot have a performer. I didn't try to trace back and see if this was a restriction in earlier versions. I've never been much of a fan of using tasks for messages so I've not kept close tabs on this part of the standard. In fact I tried multiple times to have them removed but to no avail. 

Your comments about using Message Events for human tasks gets to the heart of a lot of the difficulty people have applying the standard. Message Events are there explicitly to support messaging middleware (think IBM Websphere MQ because that's one of the key technologies the standards writers were accomodating). Message Events require things like correlation id's and instance identifier's to be semantically complete exactly for this reason. If you want to make a process executable then this is really the only permissible way to use them. In that case a Manual Task is what you want for your "message" task. A human task is really another automation piece that is designed for automatic assignment of role-driven resources so it really isn't correct to use this either if you are defining an automated process. 

But if you are modeling processes for analytic reasons it is common to ignore these automation-based details. In fact BPMN 2.0 allows a process to be marked as non-executable essentially just to provide a way for tools to NOT enforce these kinds of executable details.

2) You're definitely right that this is permissible and in situations where showing the pool on the subprocess diagram is OK this is a very good approach.

Neal McWhorter

Principal | Enterprise Agility

Business Vision Delivered

www.enterprise-agility.com