#activiti #bpmn #business-process-management #camunda
#activiti #bpmn #управление бизнес-процессами #камунда
Вопрос:
Я очень новичок в мире BPMN 2.0 (Camunda). Мне нужно смоделировать довольно сложный рабочий процесс, описанный ниже. Любая помощь высоко ценится!
У одного процесса есть «цикл событий», который фиксирует событие задачи из внешней системы, затем он асинхронно отправляет задачу на выполнение во внешнюю систему и ожидает ее статус завершения через механизм обратного вызова POST rest. Может поступать любое количество таких событий tasks, пока не будет получено определенное сообщение, которое отмечает конец списка задач. На этом этапе основной процесс должен проверить, завершены ли все асинхронно отправленные задачи, или дождаться завершения еще запущенных задач. Если какая-либо из задач не удалась, весь процесс должен быть помечен как сбой.
Ответ №1:
Этот сценарий очень похож на тот, который мы реализовали у нашего клиента.
Однако вам нужно будет подумать о проблеме по-другому. Ни Camunda, ни его предшественник engine (Activiti) не имеют возможности обрабатывать то, что я люблю называть «долговременными» сообщениями. «Долговременное» сообщение — это сообщение, которое будет сохраняться в движке до тех пор, пока движок не придет и не найдет его. Как правило, если вы используете платформу сообщений pub / sob, такую как JMS, это не проблема. Но если вы общаетесь через http через tcp, то это может быть проблематично, поскольку СООБЩЕНИЯ могут быть ПРОПУЩЕНЫ / ПОТЕРЯНЫ.
Итак, я предполагаю (на основе вашего описания), что вы планируете использовать http через tcp.
Итак, чтобы убедиться, что вы не потеряете сообщения, вам нужно отказаться от парадигмы «цикла». С помощью цикла вы не можете гарантировать, что экземпляр процесса будет ожидать получения задачи при поступлении сообщения.
Таким образом, вместо использования цикла вам следует рассмотреть один процесс «экземпляра», который запускается событием запуска сообщения, событие запуска сообщения будет включать ключ бизнес-данных, который действует как корреляция между связанными экземплярами.
Основной поток приведен ниже:
Обратите внимание, что поток очень прост, получите сообщение, выполните асинхронный вызов и дождитесь сообщения об успешном завершении, затем завершите.
Существует шлюз принятия решений, который определяет, является ли входящее сообщение завершением задачи списка. Если это обнаружено, мы переходим, запрашиваем активные экземпляры с тем же ключом корреляции и ждем, пока экземпляры ti либо завершатся, либо завершатся. Если завершено, экземпляр процесса окончательной задачи завершается и обновляет соответствующий журнал аудита.
Если по завершении экземпляров КАКОЙ-ЛИБО сбой, то экземпляр «final task» обрабатывает условие ошибки.
Комментарии:
1. Не беспокойтесь, Пелых, если бы вы могли установить ответ как принятый и проголосовать, я был бы очень признателен.
2. Есть ли в нем условие гонки? Я не думаю, что есть. Но у меня возник спор с одним из моих коллег, и я не хочу пропустить ничего очевидного. И что именно делает задача «Sleep» ниже? Каков способ обработки повторных попыток в Camunda в целом? Если, скажем, «Асинхронный вызов внешней системы» завершается с ошибкой, и у меня есть бесконечность повторных попыток (возможно ли это?) будет ли следующая последовательность «Механизм запросов для активных экземпляров с этим ключом корреляции» никогда не будет успешной? Что делать, если количество повторных попыток равно 5? Сбой не активен правильно?
Ответ №2:
Для достижения этой цели вы можете использовать задачу получения activiti.
http://www.activiti.org/userguide/#bpmnReceiveTask
У меня была похожая ситуация, когда в моем рабочем процессе нам приходилось ждать ввода от внешнего приложения. Вы можете использовать wait task, а затем, когда вы получите эти данные, вы должны явно сигнализировать об этой задаче, чтобы выполнение переходило к следующему этапу.