Hi Jean,
You can instantiate X number of IPC processes by adding X number of Destination Users to the Activity containing the IPC event.
Having said this however, the problem I can see - whether you use IPC events or normal client events - would be that you need to know before hand how many contributors need to participate (slots) before the Activity is expired and moved to the next step (or back to the Originator for re-evaluation for that matter).
I would suggest getting some consultation help from you local Services office - these guys have done pretty amazing stuff with K2 and there MUST be some easy solution to your requirement.
Regards,
Ockert
Hi, Ockert,
Thank you for the reply.
Unfortunately, at first time the originator does not know how many contributors need to participate before he sends to next activity (Contribute). So the system should allow him to add more contributors later (not at one time to define all the destination users), and not affect the users (contributors) which he already assigned. Then at a particular time, the originator thinks that the assignment of contributors is done, so the workflow should evaluate whether all the contributors finish his/her job, if all assigned contributors (slots) are done. Then the parent process can move to the next activity.
Can K2 handle this kind of case?
Thanks
Best Regards
Jean
Hi Jean,
There will MOST DEFINITELY be some way to achieve this but it may require some custom coding and design. This is exactly the reason I've recommeded some consultation.
Regards,
Ockert
We did exactly this behavior for one of our customer...
I can explain quickly how we did:
We used IPC event as said Ockert
1) We added as many destination users as we know at process start PLUS one destination user who is in fact the user account that runs the K2Server service (I call it a phantom subprocess). This extra IPC won't be used but allows us to continue review activity even if predefined destination users have finished their tasks.
2) In the subprocess:
A start activity incrementes a counter for number of running subprocesses instance
An end activity decrementes this same counter
Using this counter, we are able to know how many subprocesses are running. If the counter equals 1, we still have only the "phantom" subprocess and we can finished it to goes on.
3) Through a web interface, a user is able to add new destination users by searching them through Active Directory. When adding a user, we launch a new instance of the sub process and increment the counter of running sub process.
Well that's all... It requires some code but can be achieved. The only required thing is ti have all approval business logic in a subprocess.
Hope this helps!
PS: I can explain more but it will be easier in my natural language : french
Depending on the underlying business requirement, it strikes me that this need would be a good fit for the delegation feature
