BPMN User Substitution : Deep dive
I have already explained the basics of the user substitution in my previous post, Do your business processes getting hold-up. Please read it first if you haven’t already. Moving on, let’s see how to solve each of complications we found.
Substitute unavailability
If the substitute user also unavailable, there is no point of substitution. There are two options for this.
- The initial user should make sure the substitute is available on his absence.
- Using the transitivity property.
We have the support for both of these scenarios. By default, we always consider the given substitute as the substitute for the tasks. There is an option to enable the transitivity in the configuration. Once this is enabled, we check the availability of the given substitute. If the given substitute is not available, we look for an available substitute using the transitivity property in existing substitution records. We update this transitive substitute at the addition of the substitution record, each update to the substitution record and in pre configured scheduled time intervals.
We may run into an unstable stage if there exist a circular dependency between substitutes. We will simply reject such substitution creation or update requests. If this happens while we calculate transitive subs in the timer job, we do not have the luxury of rejecting it. In such situations, the task will be assigned to the Task owner. If the task owner is not defined, the task will be in the ‘Claimable’ status and original assignee and the substitute will be added as candidate users.
Claimable tasks
There can be a rare situation where a task is in ‘Claimable’ status and all the candidate users are not available. To overcome this, we have added substitute users also as candidate users for the tasks that the user is a candidate.
Substitution scheduler
We have introduced a timer job to activate the scheduled substitution requests, resolve the transitive substitutes and deactivate the expired substitutions. This time interval is configurable. This is the recommended time period for a substitution record to be active/effective. It is advised to put this according to your use case. For an instance for a clerical work place a one day will be suitable, but for a call center environment, it may be ten minutes. If you have a cluster you can either put exact interval in the master node and put a very high number in other nodes.
That’s all about BPS user substitution feature. This is included in our latest release WSO2 BPS 3.6.0.
Thanks.