Есть подпроцесс со сложной логикой и несколькими событиями окончания. Например, корреспонденция сортируется и отправляется "в архив", "на подпись", "на доработку". Задача - после окончания подпроцесса распределить токены.
Проблема - распределение происходит не на основе данных, а на основе вынесенного вердикта, то есть, попадания токена в конкретный end event. То есть, обычные шлюзы использовать нельзя, они data-based. Можно использовать Event-based gateway, но... С ним есть всего пара примеров и там используются message intermediate event, что в этой ситуации явно не правильно. Какие события можно использовать в данном случае? None event нельзя, остаётся только conditional event. Можно ли? Надо ли что-нибудь при этом изменить в подпроцессе?
-
Опубликовано 4 года назад #
-
Корреспонденция внутри подпроцесса отправляется по разным ветвям с помощью развилки или/или? Так она работает на основе данных. Поэтому на выходе из подпроцесса смело ставьте развилку, которая работает на основе этих же данных.
На пустое завершающее событие завязать маршрутизацию нельзя, на событие-условие нельзя, на сообщение тоже нельзя.
Можно завязать на событие-ошибку или на событие-эскалацию. Но с помощью не развилки по событиям, а прикрепленного обработчика.
Опубликовано 4 года назад # -
1) На основе данных - неудобно. Представьте себе множественные сложные проверки, разветвленный граф и в итоге - один из трёх возможных выводов. С точки зрения родительского процесса не важно, какие именно данные были проверены и как, важно - какой результат был получен. Можно, конечно, записать вывод в данные специально для дальнейшего gateway. Но это явный костыль.
2) А почему conditional event нельзя в данном случае? По стандарту он в event-based gateway может использоваться.
3) На ошибку и эскалацию не хочется. Лучше уж костыль из п1, он хоть интуитивно-понятный.
P.S. Может быть, я ошибаюсь и и\или шлюзы можно рисовать в схеме без реальной информации для шлюзов в данных? Только на том основании, что ранее на информации из этих данных был сделан вывод, который и проверяется в итоговом шлюзе? То что инструменты моделирования такое не поймут - не важно. Интересует с точки зрения стандарта.
Опубликовано 4 года назад # -
Множественные сложные проверки, разветвленный граф и в итоге один из трех вариантов - это кейс для задачи на вызов бизнес-правила.
Опубликовано 4 года назад # -
Простите, не понял ответа. Вы имеете ввиду какой-то общеизвестный паттерн?
Опубликовано 4 года назад # -
я имею в виду тип задачи: business rule task.
Опубликовано 4 года назад # -
К сожалению, в данном случае не подойдёт. Там всё сложно, я же и упрощенный пример привожу. Интересует именно академическое решение проблемы, как можно поступать в этой ситуации. Причём варианты "по стандарту никак" и "своё расширение стандарта" тоже имеют право быть. А business rule task вместо subprocess, это workaround. Это как вместо теоремы пифагора калькулятор использовать. Удобно, но знаний не прибавляет.
P.S. А почему event gateway с conditional event нельзя использовать? Единственное, что в conditional event меня смущает, это упоминание того, что это должна быть глобальная величина.
Опубликовано 4 года назад # -
мне кажется, вы просто не понимаете что такое business rule, извините.
и что такое conditional event - тоже ))
подсказываю: conditional event - это не проверка условия, а ожидание момента наступления условия. не "вердикт отрицательный?" (это про развилку), а "стоим тут, ждем момента, когда вердикт станет отрицательным".
глобальная величина должна быть, если conditional event стартовый.
Опубликовано 4 года назад #
Ответ
Вы должны авторизоваться, чтобы публиковать сообщения.