Обеспечение уникальности экземпляра процесса

Camunda 7
1

Коллеги, привет!

Необходимо обеспечить уникальность экземпляра процесса (например, в разрезе ключа процесса и бизнес-ключа). Если существует экземпляр процесса ААА с бизнес ключом 123, то процессный движок не должен позволять стартовать процесс с аналогичным бизнес-ключом. Каким образом можно это реализовать? Может быть есть что-то “из коробки” так сказать? :smiley:

Первое, что пришло на ум:

  • На стартовое событие процесса повесить Execution Listener, проверяющий, есть ли процесс с похожим бизнес-ключом, есть есть, вырабатывать исключение
  • Транзакция откатится обратно, не дав создать процесс

Для большей надежности можно (наверное) также метод проверки, вызываемый в листенере, аннотировать как @Transactional, добавив максимальный уровень изоляции (Serializable).

2

Добрый день,
Если нет централизованного модуля генерации бизнес-ключей, и клиентов несколько, и каждый может генерировать какие угодно ключи, то не лучше ли тогда не принимать бизнес-ключ в запросе, а генерировать его уже внутри процесса и возвращать вместе с синхронным ответом? Пусть клиент использует это значение внутри своей логики. Это точно гарантирует уникальность ключа.
Ваше решение с генерацией исключения конечно будет работать, но поставьте себя на место клиента? Что ему делать если получено исключение про не уникальный ключ? Генерировать новый запрос? Если несколько клиентов вместо, к примеру, генерации ключей через UUID генерируют их через автоинкремент, то между ними будет просто гонка по генерации ключей. Ни к чему хорошему это не приведёт.

3

Добрый день!

Можно генерировать бизнес-ключ с помощью делегатного кода и возвращать его при старте процесса через REST API.

public class BookOutGoodsDelegate implements JavaDelegate {

  public void execute(DelegateExecution execution) throws Exception {
    ...
    String recalculatedKey = (String) execution.getVariable("recalculatedKeyVariable");
    execution.setProcessBusinessKey(recalculatedKey);
    ...
  }

}
4

P.S. По поводу обеспечения уникальности.
Встречал также такой подход, как добавить ограничение уникальности на табличку
ACT_RU_EXECUTION (поля PROC_INST_ID_, BUSINESS_KEY_).

5

Уникальность бизнес-ключа реально нужна только для процессов верхнего уровня. Для подпроцессов это может создать дополнительные трудности, так как будет сложнее найти все связные подпроцессы. А так, если все процессы в одной задаче будут иметь один бизнес-ключ, то это может упростить их поиск и анализ.
Кстати, бизнес-ключ можно задать и в Script Task через такой grovy script:
execution.businessKey = UUID.randomUUID().toString()

1 лайк
6

Неплохая идея, можно повесить его на execution listener. :slight_smile:
Но возникает вопрос, не проще ли тогда уж process instance id использовать? Он также будет возвращаться клиенту при старте процесса.

7

Учитывая то, что в стандарте BPMN2 нет никаких упоминаний про бизнес-ключи, и в других BPM системах они тоже не встречаются, выходит что это некий бонус от Camunda. В принципе, читая их документацию тоже создаётся такое впечатление. Это условный “ключ”, и именно это слово и вводит в заблуждение. Мы как-то уже привыкли к тому, что ключ должен быть уникальным и обязательным. А тут подразумевается уникальность некой бизнес-деятельности. Это уже вопрос к общим положениям к проектировке процессов в каждом конкретном проекте. Но как мне кажется, без него можно обойтись.

1 лайк