I have a hard requirement to pick a list of people and distribute tasks for each of one of them.
However, in the 8.2 SP1 version I am using, the Business Rules do not accept a list of ID as input to a decision table to distribute tasks (for each element of the list) neither the tasks have a Multiple Instance capability builtin.
As of 8.2 SP1 the BPM component still does not provide for Multiple Instantiated Tasks, Subprocesses and Call activities.
Is this something SAG has planned for a next release?
Has anyone thought of a good workaround which doesn’t compromise the integrity of the BPM approach? (It can be done with services and triggers but that would completely brake the BPM as a business solution).
I presently simulate this with a subprocess which expands my task data list into individual documents (each task receives its own specific data) which are then spanned through an inclusive-OR gateway where each possible object is tested for existence before continuing.
For this to work I have a fixed number of objects and branches - which is a dirty trick, hidden from the Business User as much as possible - but at least Business Rules can now be applied. (see attached picture).
You can create a group and assign this group the task based on the business data. Basically, You use the “Distribution Management” in task Assignment. If you select a Round-Robin option, the task engine will automatically distribute the tasks to the group members equally.
Or use the Collaboration task type. U create at least two tasks. Set the first as parent and receive the task. Set the second as a collaboration task.
The list is dynamic in the sense it is created in the previous task, not fixed in code, task configuration or on the diagram.
The idea is to keep the distribution as closely related to the BPM as possible to keep the whole process visible, so the Collaboration Distribution, although with interesting features, is removed from this scenario.
As for the Distribution Management, the trouble with multiple assignment is that only the first user to accept the task gets to work on it - documentation says multiple acceptance is possible but I have not found any way to do it.
Again, multiple distribution is not very helpful for process visibility, so it was also discarded (it is used as a way to distribute one task between several members of a role, group ou list, but one a first-come/first-served policy).
I have changed my implementation, taking advantage of the PRE_CALL Flow service to extract a specific item from the original list using a MAP operation. This will not be the final format as I am still not happy with the performance and need indirection.
