Hi Frank, Please find my comments inline.
The process model you have drawn enables multiple receiving message events in parallel. According to the BPMN 2.0 spec this is not allowed for key-based correlation (i.e. the correlation mechanism similar to BPEL correlation sets); but it is allowed for predicate based correlation (often used in collaborations). I assume that we are not dealing with collaborations here. Thus, only one of the events/tasks will receive the message - you see mainly two ways in which this is handled by an engine, (i) the engine randomly assigns the message, or (ii) a runtime error occurs. Not sure what our implementation does Yeah. When we enable multiple message receiving events in parallel, BPMN engine will throw an error. But when you provide the activity id ( Unique id that we use in the process definition model to identify an event receiver) along with the message, BPMN engine can determine the event receiver to be executed. On the other hand, if we have only single message receiving event, we don't have to provide the activity id. Why are the correlation-keys not sufficient? When a process is instantiated it gets tightly coupled with a process model, i.e. a version of a certain process model; and all correlation-keys associated with that instance are coupled with that version. Exactly, we apply the correlation-keys to identify the process instances. But in addition to that clients can use the *processInstanceVariables* variable to add/update their user-defined/business variables to the process instance during the process instance execution and it's not being used to filter out the process instances. Regards, Firzhan
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
