Есть какое-то количество задач, имеющих timer boundary events, содержащих описание таймера (Date) в виде выражения ${ dueDate }. Соответственно, как токен процесса достигает задачи, создается запись для JobExecutor’а, имеющая due date = значению переменной dueDate на момент создания задачи.
При получении сообщения из внешнего процесса происходит обновление значения переменной dueDate, но due date таймера не обновляется.
Разумеется, можно делать
managementService.setJobDuedate(String jobId, Date newDuedate)
но это решение не выглядит удачным. Хотелось бы чего-то более абстрактного, без необходимости отлавливать конкретный джоб.
Я так не делал, но думаю, что можно это решать на уровне JobDefinition. Для джобов с типом timer в поле JobDefinition.jobConfiguration пишется какое выражение или DURATION у таких джобов. По JobDefinitionId можно всем джобам обновить dueDate.
Не знаю насколько такое подходит, но в теории должно работать
ManagementService managementService = delegateExecution
.getProcessEngineServices().getManagementService();
List<Job> timers = managementService
.createJobQuery()
.processInstanceId(delegateExecution.getProcessInstanceId())
.timers().list();
if (!timers.isEmpty()) {
log.debug("Found active jobs. Due date will be recalculated");
for (Job timer : timers)
{
managementService.recalculateJobDuedate(timer.getId(), true);
log.debug(String.format("Job id: %s. Definition id: %s. New DueDate is: %s%n",
timer.getId(),
timer.getJobDefinitionId(),
timer.getDuedate()));
}
} else {
log.debug("No active jobs for due date update");
}
Просто беру и пересчитываю значение всех таймеров для экземпляра процесса (благо они все завязаны на переменные).
Не понятно, как получить job id, например по его id в описании процесса. Как я понял, для boundary timer events он появляется в момент, когда токен достигает соответствующей активности/задачи.