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. But many people (including me) consider a process model that specifies concurrent consumption of the same message a severe modeling error...
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. Correlation-keys don't come out of the blue: the firsts correlation keys used to instantiate the process instance are "arbitrary" but after that correlation keys "must fit" - admittedly, the BPMN spec is not precise on it, but BPEL (that is the template for that) is more precise. Maybe I am missing the point what we want to achieve, i.e. that we need all the information Firzhan sketches... Best regards, Frank 2015-12-16 5:40 GMT+01:00 Chathura Ekanayake <chath...@wso2.com>: > > > > >> >> >> We need to have the process definition id, in case there are multiple >> versions of the same process definition exists with in the engine. Because >> of this we are having it as an optional parameter. >> > > I agree with that. But can we make message name optional? We use process > definition id, activiti id, correlation variables, etc to locate the > execution. Once an execution is located, I think we need to provide the > message name when triggering the message event. > > >> >> >> >> On Mon, Dec 14, 2015 at 2:25 PM, Chathura Ekanayake <chath...@wso2.com> >> wrote: >> >>> Hi Firzhan, >>> >>> >>> *processDefinitionKey/processDefinitionId/messageName* (compulsory) >>>> >>>> Either one relevant property out of three should be specified in the >>>> request. >>>> >>> >>> Shouldn't we provide messageName or signalName irrespective of the >>> availability of process definition key or id. Once we queried an execution, >>> I think we need either a message name or a signal name to trigger the >>> receive event. Please check with API. >>> >>> >>> >>>> >>>> *activityId *(optional) >>>> >>>> This property is required when there are more than one receivers >>>> waiting for the same message/signal in different execution flows. >>>> >>>> >>>> >>>> >>>> In the above process flow, all three or two of the execution flows >>>> might be waiting for the same message. >>>> >>>> *action *(compulsory) >>>> >>>> actions can be either messageEventRecieved/signalEventRecieved/signal. >>>> >>>> *signalName* (optional) >>>> >>>> If we have any signal related actions, then *signalName* has to be >>>> specified. >>>> >>>> >>>> *variables* (optional) >>>> >>>> This holds the task specific local variables that can be used to query >>>> and filter the relevant process instances. >>>> >>>> *processInstanceVariables* (optional) >>>> >>>> All the instance variables except correlation variables can be >>>> mentioned here. >>>> >>>> >>>> *correlationVariables* (compulsory) >>>> >>>> All the correlation variables should be mentioned here. By default it >>>> performs the equal operation of that variables. >>>> >>>> *variables* and *processInstanceVariables *can be used to speed up the >>>> querying process and the correlation variables should be unique across the >>>> process instances. >>>> >>> >>> Correlation variables are the ones used to query the relevant execution. >>> Process instance variables are used to pass in new data values with the >>> message. What is the purpose of the first "variables" parameter? >>> >>> Regards, >>> Chathura >>> >>> >>> >>> >> > > _______________________________________________ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > >
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
