События таймера (Timer Events)
|
Этот раздел перенесён из документации Camunda 7 и в дальнейшем будет доработан с учётом особенностей OpenBPM Engine |
События таймера — это события, которые срабатывают по заданному таймеру. Они могут использоваться как стартовые события, промежуточные события или граничные события. Граничные события могут быть прерывающими или непрерывающими.
Конфигурация
Таймеры срабатывают только в том случае, если включён Job Executor.
Определение таймера
Таймеры настраиваются с использованием формата времени ISO 8601. Определение таймера должно содержать ровно один из следующих элементов.
Time Date
Данный формат задаёт фиксированную дату и время (в соответствии со стандартом ISO 8601), в которые таймер будет сработан.
Пример:
<timerEventDefinition>
<timeDate>2011-03-11T12:13:14Z</timeDate>
</timerEventDefinition>Time Duration
Чтобы задать, через какое время должен сработать таймер, можно указать элемент timeDuration как вложенный элемент timerEventDefinition.
Длительность может быть задана в одном из двух форматов длительности ISO 8601
http://en.wikipedia.org/wiki/ISO_8601#Durations:
-
PnYnMnDTnHnMnS
-
PnW
Пример (интервал продолжительностью 10 дней):
<timerEventDefinition>
<timeDuration>P10D</timeDuration>
</timerEventDefinition>Time Cycle
Определяет повторяющиеся интервалы. Это полезно, например, для периодического запуска процессов или отправки нескольких напоминаний по просроченным пользовательским задачам.
Элемент timeCycle может быть задан в двух форматах. Первый вариант — формат повторяющейся длительности, описанный в разделе
#_time_duration,
в соответствии со стандартом ISO 8601 Repeating Intervals
http://en.wikipedia.org/wiki/ISO_8601#Repeating_intervals.
Пример (3 повторения, каждое длительностью 10 часов):
<timerEventDefinition>
<timeCycle>R3/PT10H</timeCycle>
</timerEventDefinition>Дополнительно можно задавать цикл таймера с использованием cron-выражений. В примере ниже таймер срабатывает каждые 5 минут, начиная с начала часа:
0 0/5 * * * ?
Подробности об использовании cron-выражений см. в CronTrigger Tutorial.
Примечание: первый символ обозначает секунды, а не минуты, как в классическом Unix cron.
Повторяющаяся длительность лучше подходит для относительных таймеров, которые вычисляются относительно некоторой точки во времени (например, момента начала пользовательской задачи), тогда как cron-выражения удобны для абсолютных таймеров — что особенно полезно для стартовых таймерных событий.
Изменение цикла таймера
Цикл повторения таймера может управляться через REST API или путём вызова ManagementService.
Устанавливая дату выполнения таймера (due date), можно изменить момент его исполнения.
managementService.setJobDuedate(String jobId, Date newDuedate)Изменения одного экземпляра таймера не влияют автоматически на последующие экземпляры. Например, если повторяющийся таймер срабатывает каждые 30 минут и дата выполнения одного срабатывания была изменена (например, на +15 минут), то этот таймер будет выполнен через 45 минут после предыдущего. Однако следующий таймер снова будет следовать старому расписанию и выполнится через 15 минут после изменённого таймера.
Если требуется пересчитать даты выполнения всех последующих таймеров с учётом внесённых изменений, можно передать флаг cascade (при использовании REST API) либо воспользоваться следующим Java API:
managementService.setJobDuedate(String jobId, Date newDuedate, boolean cascade)Выражения
В определениях таймерных событий можно использовать выражения. Это позволяет динамически изменять конфигурацию таймера на основе переменных процесса.
Переменные процесса должны содержать строку в формате ISO 8601 (или cron для типа timeCycle) в зависимости от типа таймера.
<boundaryEvent id="escalationTimer" cancelActivity="true" attachedToRef="firstLineSupport">
<timerEventDefinition>
<timeDuration>${duration}</timeDuration>
</timerEventDefinition>
</boundaryEvent>Повторная переоценка цикла таймера
Цикл повторения таймера может быть обновлён, если изменяется выражение, определяющее его значение. Это достигается путём повторной оценки выражения при следующем срабатывании таймера. Новый цикл вступает в силу, начиная со следующего запланированного таймера.
Рассмотрим сценарий с таймером, определённым следующим образом, где myBean.getCycle()="R3/PT2H":
<startEvent id="theStart">
<timerEventDefinition>
<timeCycle>#{myBean.getCycle()}</timeCycle>
</timerEventDefinition>
</startEvent>Предположим, что таймер должен сработать в 13:00, 15:00 и 17:00.
В 16:00, после двух срабатываний таймера, значение бина изменяется на myBean.getCycle()="R2/PT30M".
В результате таймер всё ещё будет сработан в 17:00 (в соответствии с первоначально рассчитанным циклом).
После этого он сработает в 17:30 и 18:00 — уже на основе нового цикла.
Данная возможность по умолчанию отключена. Чтобы её включить, необходимо установить свойство
reevaluateTimeCycleWhenDue в значение true в конфигурации процессного движка.
|
Для немедленного принудительного перерасчёта цикла таймера выполните следующие шаги:
После выполнения этой задачи последующие задания будут создаваться с обновлённым циклом таймера. |
Обработка часовых поясов
Конфигурация 2022-03-11T12:13:14 не содержит информации о часовом поясе.
Во время выполнения такая дата интерпретируется в локальном часовом поясе JVM, в которой выполняется процесс.
Это может приводить к проблемам, например, при запуске нескольких узлов OpenBPM Engine в разных часовых поясах или если невозможно гарантировать часовой пояс платформы.
Кроме того, возможны сложности, связанные с переходом на летнее/зимнее время (DST).
Если есть сомнения, рекомендуется явно указывать время в UTC (например, 2022-03-11T12:13:14Z) либо с относительным смещением от UTC (например, 2022-03-11T12:13:14
Лицензия и атрибуция
Эта документация была создана на базе материала "Camunda 7 Docs" от Camunda, находится под лицензией Creative Commons Attribution-ShareAlike 3.0 Unported License .
Оригинал документации: https://docs.camunda.org