Best Practice for SLA based task flow

[sangv]

I have a relatively simple use case and I am looking for some guidance on the best way to solve it. There are two actors, employees and managers. Managers track how the employees are performing the tasks and perform actions based on how much at risk employees are on missing the SLA for the task.

So for example -
SLA for a task is 1 week. As a manager, I want to perform some action if the employee has not completed the task in 3 days (maybe email the employee and ask him if he needs any help). If its been 4 days and the task is not completed, I want to call the employee and check progress. If its been 5 days, I want to cancel the order or email the customer updating him that it will take longer than planned.

So,
i) Am I better off modelling this as two different processes and having a task listener on the employee's task alert the manager's process. In this case, the manager's process will be purely an SLA based process and all the actual tasks will be on the employee's process. The other option is to model this as one process and have the SLA monitoring task and the employee's user task as parallel tasks (and have a timer event in parallel as well that feed's into a gateway).

ii) Looks like a lot of timers will be involved here. Instead of modelling this sequentially, can I loop back based on a condition and reset the timer (3 days, then add a day and then add a day). Is there a better way to do it other than using timer events.

iii) Does Activiti provide some implicit support for SLA based use cases like this. Any thing I can read up on for example. Do I just use "due date" to set the SLA?

Thanks for your help,
Sang

[c_arunrathnakum]

Need solution please. Coming through same requirement

[frederikherema1]

The best way to solve this is doing this in a single process, as it's all related to a single use case. The best way to do this, IMHO, is to have multiple boundary-timer-events on the UserTask for the employee. These boundary-events should have cancelActivity="false" in the XML, which keeps the "employee" task alive when the timer fires.

When one of the timers fires (eg. first one at 3 days -> timeDuration="P3D"), you have a user-task for the manager called "Call employee X". The outcome of this tasks leads to an end-event. When the "Call employee X" task is completed, only the "forked" part of the process ends (caused by the timer) and the employee-usertask remains active. The other timers can have other timeDurations.

Finally, if there is a hard-deadline, you can have the timer cancel the activity and go to a manager-task "deadline expired". This way, after the 10 days, the employee won't have see the task in his task-list anymore.