Как я неоднократно писал в этом блоге, зачастую то, что называет бизнес-процессом бизнес, в терминах BPMN моделируются не одним, а несколькими пулами. См. например процессный паттерн “внутренний заказ” или “обработка входящих”. И там, и там процесс-”клиент” оставляет задание в базе данных и переходит в ожидание сообщения от процесса-”сервера”, что задание выполнено.
Схема рабочая, но у нее есть недостаток: сервер здесь должен знать клиента, что называется, “в лицо” - в схему процесса-сервера зашивается отправка сообщения в процесс-клиент. Если сервер обслуживает всего одного клиента, то это нормально, но если это не так?
Рассмотрим следующий пример: процесс продажи выставляет счет клиенту и ждет, что процесс обработки выписки банка, запускаемый периодически (например, ежедневно), успешно идентифицировав очередной платеж, сообщит, что счет оплачен -
Теперь усложним задачу: пусть у нас не один, а несколько процессов продажи: продажа товаров, продажа услуг, продажа VIP-клиентам, продажа через партнеров и т.д., причем зафиксировать число таких шаблонов не представляется возможным. Куда в этом случае должен отправлять сообщение процесс обработки платежей?
Решение: вместо сообщения воспользоваться условным событием -
- Процесс-клиент (Продажа) записывает задачу в базу данных и переходит к ожиданию изменения статуса задачи (статус счета = оплачено).
- Процесс-сервер (Входящие платежи) меняет статус оплаты.
- Процесс-клиент просыпается и идет дальше.
В этой схеме ни клиент, ни сервер не знают схем друг друга, взаимодействую только через общие данные (счет в рассматриваемом примере). Это означает, что разработчик волен менять схему одного процесса, и это никак не отразится на другом. Или добавить новый шаблон процесса-клиента. Или процесса-сервера.
Отдельный вопрос - поддерживает ли событие-условие ваша конкретная BPMS?
Хорошая новость для пользователей Bizagi: в палитре Bizagi BPM Suite событие-условие появилось и схема типа приведенной выше работает - проверено.