Бернд Рюкер рассказывает о о преимуществах использования паттерна external task по сравнению с JavaDelegate и уверяет, что это совсем не больно. А если вы хотите использовать standalone-движок, то в общем-то у вас нет выбора, только external task.

Вам нужно интегрировать несколько компонентов без помощи менеджеров транзакций с поддержкой ACID (атомарность, согласованность, изоляция и долговечность)? Тогда этот пост для вас.

Я сначала кратко объясню, что такое менеджеры транзакций и почему вы можете не иметь их под рукой в современных архитектурах. Затем я опишу решение, как работать без менеджеров транзакций в целом, а также рассмотрю проект, который я знаю лучше всего, как конкретный пример: движок процессов Camunda.

Введенный в 2015 году, паттерн внешней задачи (external task pattern) становится всё более популярным. Вместо того чтобы движок процессов активно вызывал какой-либо код (push), паттерн внешней задачи добавляет работу в некую очередь и позволяет воркерам (workers) извлекать их по мере необходимости. Этот метод также известен как публикация/подписка (publish/subscribe). Движок процессов публикует задачи, а воркеры подписываются на их выполнение.

В течение длительного времени мы выступали за архитектуру, в которой BPM-движок Camunda встроен в ваше Java-приложение, предпочтительно через Camunda Spring Boot Starter. Однако со временем мы постепенно отошли от этой рекомендации в сторону удалённого движка. В Zeebe мы и вовсе не поддерживаем использование встроенного движка.

В этом посте я хочу объяснить причины этого перехода и почему мы рекомендуем использовать удалённый движок. Однако сначала давайте разберёмся, почему встроенный движок изначально представлял собой привлекательный выбор, и отметим, что изменилось с течением времени. Если вам не интересна эволюция данного вопроса, вы можете пропустить историческую справку и перейти к сравнению архитектур движков.

Хотите узнать, что такое агент ИИ и как можно использовать ИИ для улучшения бизнес-процессов?

-- Читайте перевод статьи из блога Camunda