Когда скорость может быть проблемой🚀

Логически эта схема абсолютно правильная. Мы отправляем запрос к внешнему сервису, он выполняет свою работу и возвращает ответ — тогда процесс продолжается.

Но есть нюансы:👀 синхронная задача в вызываемом процессе может выполниться очень быстро, за миллисекунды⚡️. И тогда родительский процесс просто не успеет поймать ответное событие.🤷

Ведь что там происходит под капотом:

Перед Receive task у нас граница транзакции. Значит, процесс записывает свое состояние в базу. Потом создает подписку на получение сообщения. И тоже сохраняет ее в БД.

Все это занимает какое-то время — а внешний процесс уже успел начаться и кончиться, его сообщение улетело в никуда!😢

Чтобы не ломать себе голову — успеет или не успеет процесс стать в состояние ожидания для приема сообщения, просто используйте external task.

Здесь фишка будет не в том, что это какой-то внешний код на чем угодно — Java, Python, C++, JavaScript и так далее, а в самом механизме исполнения таких задач.

Вот как это делается:

Сервер видит, что есть внешняя задача с каким-то топиком. Дальше он публикует ее в очередь и ждет, пока внешний воркер ее исполнит.

Точь-в-точь как с user task'ами — задача висит, пока исполнитель не придет и не выполнит ее. Соответственно, процессу не надо ловить никакие сообщения, надо только ждать — модель получается проще.

Это можно использовать на любой BPM-платформе, которая поддерживает паттерн external task — Camunda, Flowable, Jmix BPM, OpenBPM и другие.

BPM Developers — про бизнес-процессы: новости, гайды, полезная информация и юмор.