Этот сценарий очень похож на тот, который мы реализовали у нашего клиента.
Однако вам нужно будет подумать о проблеме по-другому. Ни Camunda, ни ее предшественник (Activiti) не могут обрабатывать то, что мне нравится, называть «прочными» сообщениями. «Долговечное» сообщение - это то, которое будет сохраняться в двигателе до тех пор, пока двигатель не появится и не ищет его. Как правило, если вы используете платформу сообщений pub/sob, такую как JMS, это не проблема. Но если вы общаетесь через http через tcp, это может быть проблематичным, так как СООБЩЕНИЯ могут быть MISSED/LOST.
Итак, я предполагаю (на основе вашего описания), что вы планируете использовать http через tcp.
Итак, чтобы вы не потеряли сообщения, вам нужно отказаться от парадигмы «петли». С циклом вы не можете гарантировать, что экземпляр процесса будет ждать при получении задачи, когда приходит сообщение.
Таким образом, вместо использования цикла вы должны рассмотреть один «экземпляр», который запускается событие начала сообщения, событие начала сообщения будет включать в себя ключ бизнес-данных, который действует как корреляция между связанными экземплярами.
Основной поток ниже:
![enter image description here](https://i.stack.imgur.com/GgOF0.png)
Обратите внимание, что поток очень просто, получить сообщение, сделать вызов асинхронной и ждать сообщения об успешном завершении, то конец.
Существует шлюз решения, определяющий, является ли входящее сообщение завершением задачи списка. Если это обнаружено, мы разветвляемся, запрашиваем активные экземпляры с одним и тем же ключом корреляции и ожидаем, что экземпляры ti либо не сработают, либо завершатся. Если завершено, окончательный экземпляр процесса задачи завершает и обновляет соответствующий контрольный журнал.
Если по завершении экземпляров ANY сбой, то экземпляр «final task» обрабатывает условие ошибки.
Спасибо, Грег! Это очень хорошая отправная точка для меня. –
Не беспокойтесь Пелых, если бы вы могли установить анср, как принято, и повышать, я бы очень признателен. –