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_ = ?")
.setDate(0, duedate)
.setLong(1, Long.valueOf(taskId))
.executeUpdate();
}
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