Martin, try adding a decision node to your process definition. If the process instance is high priority, go to a task with the timer. Otherwise, go to a task without the timer. It might look odd, but then the use case is odd.
OK, I know this would work, but it will bring some mess into the diagram. The use case is slightly odd, I know. But originally the users just wanted escalation and after some time they just defined few cases when they don't need it, so I just wanted to do it some easy way. I'll probably stick to letting the timer there and just pushing it to 2100
We have something similar. With a twist. Once the task is created and the timer is set, it must be possible to adjust the date for the timer to fire. E.g. we have a timer that creates a task for a supervisor to investigate once the original task has been in progress for a week. But if the original assignee gets sick and can't work, we need to adjust that timer.
I had no alternative but to set the duedate of the timer directly in the jbpm4_job table. It works well, but it would have been a lot neater if the API provided some way of manipulating jobs.
I'm struggling with this issue too. For now I just left the activity and returned back, so new timer is created with new date. But this is not very flexible, since it may fire notifications etc. I'll probably try to separate the timer from the process.
How have you modified the table? Using Hibernate session from jbpm or using some more ugly hack?
We're using Spring, have a DAO that extends HibernateDaoSupport. Then we have this method
public int updateJobDuedate(String taskId, Date duedate)
return getSession().createSQLQuery(" UPDATE jbpm4_job SET duedate_= ? " +
" FROM jbpm4_job job, jbpm4_task task " +
" WHERE job.execution_= task.execution_ " +
" AND task.dbid_ = ?")
So basically you give the ID of the task for which you want the timer to be adjusted, as well as the new duedate for that timer.
We are starting to build a small library of such utility methods which are easier and faster to use than the jBPM API, especially when queries are involved. This is the only "write" method we have though, the rest are all read methods. Another practical one we have is, given the ID of a task, return the business key associated with the processInstance to which that task belongs.
It would (maybe) have been an option to cast jbpm objects to get more control, for example if you have a Task, cast it to TaskImpl, but that requires too much extra unit testing (we use jMock). And it defeats the purpose of using interfaces in the first place
rather than manipulate directly with the table I decided to move timers to separate process. In my case there was high probability that in future timer would cover more tasks and I also need options to reschedule them, this was cleaner way from my point of view than using group timers or something similar.