Test Case C.1.0: User Tasks with incoming/outgoing Message Flows

[Trickovic]

In the process model there is a user task with one outgoing message flow and one outgoing message flow. I believe this is not conform with the BPMN specification (and in particular, the execution semantics part). The BPMN2 specification says: "User Task: Upon activation, the User Task is distributed to the assigned person or group of people. When the work has been done, the User Task completes." Although the BPMN metamodel allows such a constellation - Message Flows can theoretically be connected to any type of Tasks - still the (execution) semantics of incoming and outgoing Message Flows for User Tasks is not defined. So I would argue that the adopted process model is not a valid BPMN model.

[falko]

Here is the model:

[falko]

The upper Pool of this model is not executable, but the lower Pool is. The upper Pool including the Message Flows are only meant as a documentation to visualize how users interact with the automated process.

When the model is deployed to Camunda BPM, it only deploys the executable Pool and the Message Flows are ignored during execution.

[falko]

Hi Ivana,

I spend some hours to go through the spec and look at every single statement about Message Flows and related concepts:

You are right in that the BPMN meta model, XML schema as well as specification text allow Message Flows to connect to any type of Tasks including User Tasks (see the statements I quoted below). There is no single statement further restricting to what elements a Message Flow can connect.

You also right in that

the (execution) semantics of incoming and outgoing Message Flows for User Tasks is not defined.

In fact there is no single mention of Message Flow at all in chapter 13, which describes the BPMN Execution Semantics. The execution semantics of sending an receiving messages are solely based on Messages or Operations directly referenced by Tasks through attributes like messageRef or operationRef. A Message Flow itself does not have any execution semantics. Thus, it is correct of Camunda BPM to ignore Message Flows during execution and the model is valid BPMN.

Unless you can present any other statements that further restrict the use of Message Flows, I would suggest we close this issue and leave the test case as is.

Greetings from Berlin, Falko

Statements in BPMN 2.0.2 that allow Message Flows to connect to User Tasks

p.41 (PDF 71):

Table 7.4 displays the BPMN modeling objects and shows how these objects can connect to one another through Message Flows. [...] The [arrow] symbol indicates that the object listed in the row can connect to the object listed in the column. Only those objects that can have incoming and/or outgoing Message Flows are shown in the table. Thus, Lane, Gateway , Data Object, Group, and Text Annotation are not listed in the table.

The table shows an abstract task as being able to have incoming and/or outgoing Message Flows.

p.121 (PDF 151):

Figure 9.14 displays the class diagram of a Message Flow and its relationships to other BPMN elements.

The diagram shows that source and target are InteractionNodes, which can be ConversationNodes, Tasks or Events.

p.122 (PDF 152):

Table 9.8 – Message Flow attributes and model associations Only the Pool/Participant, Activity, and Event elements can connect to Message Flows.

p.152 (PDF 182):

An Activity MAY be the target of a Message Flow; it can have zero (0) or more incoming Message Flows. An Activity MAY be a source of a Message Flow; it can have zero (0) or more outgoing Message Flows.

p.149 (PDF 179):

The types of Activities that are a part of a Process are: Task, Sub-Process, and Call Activity

p.155 (PDF 185):

The diagram shows that User Task is a sub-class of Task and can therefore be source or target of a Message Flow.

Furthermore, there are many examples in the spec that show Message Flows connected to Abstract Tasks:

And finally there is even an example explicitly showing a Message Flow connected to a User Task:

[ehelmste]

As discussed on wednesday, we, at W4, do agree that this is a bug.

Spec says (page 123, page 153 of the PDF) that message flows can connect to "interaction nodes" and interaction nodes represents activities, events, pools. So what we see on this model can be correct.

But as the process in second pool is executable, the executable part of the spec also applies. On page 430 of the spec (page 460 of the PDF), in the execution part, user tasks are described as : "User Task: Upon activation, the User Taskis distributed to the assigned person or group of people. When the work has been done, the User Taskcompletes."

On the same page, only Send task and Receive task are described as treating messages.

In addition, in the schema / spec, the only task types that can reference a message are Send task and Receive task (through their messageRef attribute). Same idea with Operation that User Task does not reference (send task and receive task do).

To conclude: when processes are executable, messages must only be produced by throw events with a message trigger or send tasks, and consumed by catch events with a message trigger or receive tasks. Meaning message flows sources can only be message thow events or send tasks, and message flows targets can only be message catch events or receive tasks.

EDIT : sorry, I did not see Falko commented in the meantime.

[mskurz]

@Trickovic wrote:

Upon activation, the User Task is distributed to the assigned person or group of people. When the work has been done, the User Task completes.

Well, BPMN literature suggests that the message flow has impact on the execution:

• IMHO, incoming message flows are a precondition for executing the user task. Leaving out this message flow change the semantics of the diagram.
• Once the user task completes, a corresponding message is sent and makes it possible to trigger the receiving events. Again, leaving out this message flow change the semantics of the diagram.

So there is need for connecting message flows and user tasks. Obviously, this could be circumvented by using message send and receive events (like @ehelmste suggests). But this is not something I regularly see.

[berndruecker]

Hey guys.

I want to add the view of a consultant working for years with BPMN: We use the message flows between non-executable and executable pools coming from or pointing to UserTasks very regularly to connect the executable process and the documentation of what the user does in this step.

We made VERY good experiences with this methodology (business analysts as well as other stakeholders perfectly understand this)! We described it in our Real-Life BPMN book and get a lot of good feedback. And like Falko wrote it is not forbidden by the Specification. So from my point of view this must not be forbidden - that would be a huge step backwords in terms of how to apply BPMN in real-life!

Cheers Bernd

[falko]

Let me add that category C of the MIWG test cases is meant to contain real-life examples and more generally an interoperability test suite should not just contain the smallest common denominator that works in every tool.

If there are tools that have an issue with this test case, I'm happy to provide a variation C.1.1 that contains only the executable process, since our tool Camunda Cycle can do such a Pool Exctraction automatically based on the executable attribute of BPMN. This additional variation might be a good compromise for the upcoming demo, where we indeed are looking for a smallest common denominator that works for as many engines as possible.

However, I strongly believe we should not mix up the different and sometimes conflicting goals of testing and demoing by the MIWG in this discussion.

[Trickovic]

Thanks for the feedback on the issue I raised! I still have to go through all comments, one by one, but here I would like to go back to the BPMN2 specification. The definition of MessageFlow does not restrict the type of Activities that could be the source and the target of a Message Flow. Falko listed relevant sections of the specification. However, if you look at the Activities section (table 10.3) and sub-sections of relevant Activity sub-types (Sent Task – table 10.9, Receive Task – table 10.10, and User Task –table 10.13) you will see that Send Task and Receive Task have attribute “messageRef” and UserTask does not have. This attribute indicates that the Message will be sent or received by the Task correspondingly. I believe that these parts of the specification clarify that the intention was not to model message exchange using User Tasks.

[jakobfreund]

Hi Ivana, thanks for pointing out the messageRef-Attribute. Though there is no messageRef-Attribute for Service Task either, I would basically agree that the authors probably did not see the User Task in the same light like the Send/Receive Tasks in terms of message flows.

However they clearly did not forbid this pattern - this is not disputable.

And I think this happened for a very good reason: After the experiences the community made with BPEL, it became obvious that an execution standard should be less restrictive, if we want to foster the adoption. You cannot know beforehand, what people will actually do with the standard in order to benefit from it, so you need to provide them with a certain "space". I am very convinced that BPMN's success is based on exactly this realization.

The pattern Bernd and Falko mentioned is a very good example for this. There are numerous good reasons for applying that pattern in both exectuable and non-executable pools. If you want to, I can provide a detailed enumeration.

But what I am actually saying is:

a) There are very good reasons for accepting this pattern as something that is basically "allowed".

b) So far I have not learned of any reason against it, besides the speculation that it may or may not was intended by the spec authors.

So if this is the current situation, why not judge "in dubio pro reo" ?

Thanks for considering :-)

Jakob

[ehelmste]

I think we are not talking on the same level. We should first clarify this. Are we talking about:

• modelling of the C.1.0 test case in a modelling tool (like a Composer, Modeler, depeding the denomination of each vendor), like A and B interchange test cases
• execution of the C.1.0 test case using an execution engine
• creating an executable test case that can be used for the upcoming demo
• any combination of the previous elements

From an execution point of view:

@mskurz wrote:

• IMHO, incoming message flows are a precondition for executing the user task. Leaving out this message flow change the semantics of the diagram.
• Once the user task completes, a corresponding message is sent and makes it possible to trigger the receiving events. Again, leaving out this message flow change the semantics of the diagram.

I would agree with that if:

• this was explained somehow in the chapter 13 that talks about execution
• the user task had some attribute referencing somehow a message (like send task that has a messageRef attribute)

@jakobfreund wrote:

Though there is no messageRef-Attribute for Service Task either

That's true, but the messages (in and out) that are treated by a service task are described through the operation referenced by the service task (described at chapter 10.2.3 of the spec).

[falko]

Scope of Discussion

We are discussing if C.1.0 is a valid BPMN 2.0 model. The particular question is:

Can User Tasks have incoming or outgoing Message Flows?

We are not discussing if User Tasks can actually throw or catch Message Triggers during execution.

Once we resolved this issue, we can think about using model C.1.0 or parts of it for demo purposes.

Summary of the Arguments

To ease further discussion of the matter I'll try to summarize all the arguments that have been brought up so far. I'll skip particular quotes and references for brevity, but I can provide them if needed.

1. Pro

1.1. OMG Documents

1. XML schema allows it
2. UML meta model allows it
3. Spec text allows it
4. Message Flows don't have execution semantic (ch.13 doesn't even mention them at all)
5. Spec contains explicit example
6. non-normative FTF document "BPMN 2.0 by Example" contains explicit example
7. BPMN is methodology-agnostic
8. Messages can even represent physical goods
9. User Tasks in BPMN 1.x do have message attributes
10. WS-Human Task suggested as User Task implementation, which uses SOAP messages

1.2. Practice

1. valuable practice described in best-selling book "Real-life BPMN" by Jakob Freund and Bernd Rücker
2. several examples found in best-selling book "BPMN Method & Style" by Bruce Silver
3. used by significant part of the BPMN community
4. any User Task implementation notifies the user about new tasks and users notify engine about completion
5. BPMN's value is not being a great programming language, but a communication tool between Business and IT

1.3. MIWG

1. there are other non-mainstream test cases, e.g. vertical modeling (A.4.1) and Lanes without Pools (A.4.0)
2. category C is meant to contain real-life examples
3. in dubio pro reo

2. Contra

2.1. OMG Documents

1. User Task has no message attributes
2. execution semantic does not mention sending and receiving messages in context of User Task
3. WS-HumanTask suggested to hide task engine protocol from models
4. According to Ivana the above facts reflect the intention of the spec authors for User Tasks not to send or receive Messages

2.2. Practice

1. this is a methodology invented by Camunda

2.3. MIWG

1. tools may have issues with this test case

Conclusion

• User Tasks with Message Flows are neither explicitly forbidden nor explicitly allowed inside the OMG documents.
• We all agree that this modeling style is useful for documentation purposes.
• Proposal for a Compromise: We keep the test case, but don't make strong test assertions about Message Flows connected to User Tasks, i.e. we do not open issues if a tool does not support this.

[tstephen]

Thanks for the summary Falko and everyone who has contributed to get us to this point.

I would like to take a slightly different approach to the problem. Rather than Falko's question about whether User Tasks may have message flows I believe we are actually trying to:

 Identify a candidate process for our next public demo of the work of the BPMN MIWG

A demo, I should add, we have agreed we would like to showcase execution as well as modeling as well as continuing to emphasize the areas different vendors can interoperate on.

In this context I think the above thread amply proves there is room for doubt and dispute on the matter. Furthermore I suggest that is reason enough to say the model would not serve us well in the demo.

So I am happy to agree with the first two bullets of Falko's conclusion but not with the last. I think we should drop the top pool along with all message flows, which will give us ample things to showcase in our demo and avoid all discussion of the demo being focused on dispute of a single semantic.

[falko]

@tstephen I completely agree to these suggestions for the demo. However, we first need to resolve the bug that Ivana opened for test case C.1.0. To speed up the resolution I suggested a quick compromise rather than discussing this forever.

For the demo I suggest that we do it like with all previous demos: Use separate models stored and tested in our MIWG demo repository of even in a dropbox. I just created a folder for the new demo inside the demo repository and added a variation of C.1.0, in which I extracted the engine pool using Camunda Cycle:

[ldugan]

Sorry not to weigh in sooner, but put me in the Falko camp on this one. Most of the salient points have been made, but here is a reprise and some additions:

• messageFlow has no execution semantics and messageRef is optional, with the import that it is a visualization that may/may not have a link to data payload (messageRef pointing to message that has itemDefinition
• Meta model and rules for activity permit it even for User Task, but messageRef is not involved, though it is for serviceTask, sendTask, receiveTask, and messageEvent (all flavors) via the operation element in interface
• if the payload is empty (if you will), understood as no messageRef in the messageFlow, I would contend that that data input requirements for the userTask to be active (as a state) are either satisfied (empty set) or irrelevant (not an actual dataInput moment)
• executability is per the process attribute, and presumably only reacts to the presence of interface to implement operations that match up with messages (leaving any match up with messageFlows to be just nice-to-haves)
• as a modeling approach, I have found that it provides a path for model preservation from the business process perspective to the business system perspective , and - though I know that BPMN is not an architectural modeling language - the use of this approach (using messageFlows this way) - helps in such modeling since the inbound/outbound moments are understood as information flows across the man-machine interface

If this doesn't sell, then you can black box the other pools are just ignore it. You could also drop them, but I don't believe that has any basis in the spec, but may have some in practicality.

[dgagne]

Webmeeting 26 Nov 2014 o The various positions were presented and discussed o It was decided to maintain the “diagram” of test case C.1.0 (with the two pools but without the DataStore) o It was decided that the only executable process of the model would ignore all message flows for execution purposes o It was decided that Automated Test Tools would not report on missing message flows to User Activities