Receive Task vs. Message Intermediate Catch Event

[aapthorp]

I've been looking for some guidelines on when to use a Receive Task vs. Message Intermediate Catch Event, but haven't found anything. Does anyone know of any good explanations? The BPMN 2.0 spec highlights similarities but not differences.

When looking at these constructs from the point of view of Activiti (and to some extent BPMN) I see some inconsistencies, the reasons for which are not immediately apparent:

1) Why signal (runtime.signal) a receive task the receipt of a message and receive the message (runtime.messageEventReceived) on an intermediate event?

2) When correlating (via an execution query) a receive task I have to use the activity id, but when finding the message subscriber I have use the message name. i.e. in on case use an id and the other the name.

Clearly this still works, but certainly the second point tripped me up - as I looked for the id instead of the name, having done the opposite for the receive task.

[frederikherema1]

1) I don't really get you're first question. Can you clarify that one for me,please?

2) A receive-task is an activity that is part of the process. If you want to locate that specific recieve-task, you should use it's ID to look it up. A message is another concept. Although the message-catching-event is an activity of itself, it's the message-definition you're interested in, not the actual activity.

[aapthorp]

1) I don't really get you're first question. Can you clarify that one for me,please?

I was trying to figure out the rationale for 'signaling' a Receive Task with a message vs a semantic that is closer to receiving a message.

2) A receive-task is an activity that is part of the process. If you want to locate that specific recieve-task, you should use it's ID to look it up. A message is another concept. Although the message-catching-event is an activity of itself, it's the message-definition you're interested in, not the actual activity.

Understood. The question is why in one case use an id and in the other use a name, it seems inconsistent?

Both points may be 'nit picky' but coming back to my original question I was experimenting with messaging a Receive Task vs. a Message Intermediate Catch Event and spotted the apparent inconsistencies. At the end of the day aren't both wait states, that wait on receipt of a message? Indeed it's interesting that the BPMN 2.0 spec indicates that a Receive Task can be used instead of an event with an Event Gateway.

[jbarrez]

Both points may be 'nit picky' but coming back to my original question I was experimenting with messaging a Receive Task vs. a Message Intermediate Catch Event and spotted the apparent inconsistencies. At the end of the day aren't both wait states, that wait on receipt of a message? Indeed it's interesting that the BPMN 2.0 spec indicates that a Receive Task can be used instead of an event with an Event Gateway.

The way I always interpreted it is as follows:
- A receive task is indeed similar to a message wait
- Activiti allows to signal such receive tasks from something external to the engine. This is a remnant from the jbpm heritage. It has nothing to do with a BPMN signal.
- Message exchange in BPMN is really for inter-process communication and not to communicate with external resources.

So at the end of the day I think it is just a matter of taste. In my opinion, I feel a receive task is a bit more easier to understand when I look at diagrams, but that's just probably me.