BPMN events work well for cases which require the coordination of many (an unknown number at the time of the design) participants with a similar behaviour. This case is typical for voting, bids and other dynamic situations. The logic “one pool implies one instance because there is one participant” is not sufficient for such cases. Instead it is necessary to use the logic “one pool implies many instances, one per participant” is required (this is rather implicit in BPMN).
For example, figure above shows a voting process with many voters each of whom behaves in accordance with the coordination logic presented in the pool VOTERS. The whole process is coordinated by the pool COOR and comprises three steps: preparation 1, ballot casting 2 and finalisation 3.
In the first step 1 , the repetition of process fragment PF01 in the pool COOR starts many instances of a process in the pool VOTERS.
In the second step 2 , each voter may cast a ballot (activity Vote from the pool VOTERS); this event is consumed by the intermediate message event E01 in the repeating process fragment PF02 in the pool COOR. If a voter hasn’t cast a ballot before the deadline, then process fragment PF01 in the pool VOTERS is terminated by a time-out exception which is consumed by the intermediate message event E02 in the repeating process fragment PF02 in the pool COOR.
In the third step 3, the process publishes the results of the vote.
The explicit separation of the behaviour of the voters from the voting procedure and the imposition that all voters are treated equally (i.e. the pool VOTERS acts as a voter’s proxy) considerably simplifies the validation, control, monitoring and certification of such a process-based solution.
Thanks,
AS
Posts
