Модификация экземпляра процесса

Модификация экземпляра процесса очень полезна в тестах JUnit. Не нужно проходить весь процесс до проверяемого места: можно сразу перейти к нужной активити или шлюзу.

Для этого экземпляр процесса запускается с модификацией, и токен ставится сразу в нужное место.

Например, чтобы пропустить подпроцесс Evaluate Loan Application и проверить шлюз Application ok? со своей переменной процесса, запустите экземпляр процесса так:

После этого в тесте JUnit можно проверить, что экземпляр процесса ожидает в активити Accept Loan Application.

Fluent builder модификации экземпляра процесса принимает следующие инструкции:

С каждой инструкцией, создающей экземпляры (startBeforeActivity, startAfterActivity или startTransition), можно передать переменные процесса. Для этого в API есть методы:

Переменные устанавливаются после создания областей видимости, нужных для запуска (см. Вложенный запуск), и до начала выполнения указанного элемента. Поэтому для инструкций startBefore и startAfter в истории процессного движка эти переменные не выглядят так, будто их установили во время выполнения указанной активити. Локальные переменные устанавливаются на том выполнении, которое выполняет инструкцию, то есть входит в активити и т. п.

Подробнее о переменных и областях видимости см. в разделе Переменные.

API модификации экземпляра процесса построен на экземплярах активности (activity instances). Дерево экземпляров активности для экземпляра процесса возвращает следующий метод:

ActivityInstance это рекурсивная структура данных, и экземпляр активности, который возвращает этот метод, представляет сам экземпляр процесса. Идентификаторы объектов ActivityInstance используются для отмены конкретных экземпляров (см. Отмена экземпляра активности) и для выбора предка при запуске (см. Выбор предка при запуске).

Для спуска по дереву экземпляров активности в интерфейсе ActivityInstance есть методы getChildActivityInstances и getChildTransitionInstances. Пусть, например, активны активити Assess Credit Worthiness и Register Application. Тогда дерево экземпляров активности выглядит так:

В коде экземпляры активности Assess и Register можно получить так:

Можно также сразу получить все экземпляры активности для заданной активити:

В отличие от экземпляров активности, экземпляры перехода представляют не активные активити, а активити, в которые выполнение вот-вот войдет или из которых вот-вот выйдет. Так бывает, когда задания асинхронных продолжений уже существуют, но еще не выполнены. Дочерние экземпляры перехода у экземпляра активности возвращает метод getChildTransitionInstances. API для экземпляров перехода похож на API для экземпляров активности.

Возьмем экземпляр процесса из примера выше, в котором активна активити Decline Loan Application. Отправим инструкцию запуска перед активити Assess Credit Worthiness. При ее применении процессный движок создает экземпляры всех родительских областей видимости, которые еще не активны. В данном случае перед запуском активити движок создает экземпляр подпроцесса Evaluate Loan Application. Дерево экземпляров активности было таким:

а стало таким:

Кроме создания родительских областей видимости, движок регистрирует подписки на события и задания в этих областях. Рассмотрим, например, такой процесс:

При запуске активити Assess Credit Worthiness регистрируется и подписка на граничное событие сообщения Cancelation Notice Received, так что подпроцесс можно отменить этим событием.

По умолчанию запуск активити создает экземпляры всех родительских областей видимости, у которых еще нет экземпляров. Если дерево экземпляров активности такое:

то запуск Assess Credit Worthiness дает следующее дерево:

Экземпляр области видимости подпроцесса тоже создан. Теперь допустим, что экземпляр подпроцесса уже существует, как в этом дереве:

Повторный запуск Assess Credit Worthiness выполнится в контексте существующего экземпляра подпроцесса, и дерево станет таким:

Если нужно другое поведение и подпроцесс должен получить второй экземпляр, передайте идентификатор экземпляра активности предка в метод startBeforeActivity(String activityId, String ancestorActivityInstanceId). Аналогичные методы есть для запуска после активити и для запуска перехода. Параметр ancestorActivityInstanceId принимает идентификатор экземпляра активности, который сейчас активен и относится к активити-предку запускаемой активити. Активити считается допустимым предком, если она содержит запускаемую активити напрямую или через другие вложенные активити.

Если идентификатор экземпляра активности предка задан, создаются экземпляры всех областей видимости между предком и запускаемой активити, даже если экземпляры у них уже есть. В примере следующий код запускает активити Assess Credit Worthiness, указывая предком экземпляр процесса (он же корневой экземпляр активности):

Итоговое дерево экземпляров активности:

Подпроцесс запущен второй раз.

Отмена экземпляра активности распространяется на родительские экземпляры активности, в которых не остается других экземпляров активности. Так экземпляр процесса не остается в бессмысленном состоянии выполнения. Например, если в подпроцессе активна одна активити и ее экземпляр отменяется, подпроцесс тоже отменяется. Рассмотрим такое дерево экземпляров активности:

После отмены экземпляра активности Assess Credit Worthiness дерево становится таким:

Если после выполнения всех инструкций не осталось ни одного активного экземпляра активности, отменяется весь экземпляр процесса. В примере выше так случилось бы, если бы отменили оба экземпляра активности: Assess Credit Worthiness и Decline Loan Application.

Экземпляр процесса отменяется только после выполнения всех инструкций. Если между двумя инструкциями в экземпляре процесса нет активных экземпляров активности, экземпляр процесса не отменяется сразу. Допустим, активна активити Decline Loan Application. Дерево экземпляров активности:

Следующая модификация выполнится успешно, хотя сразу после инструкции отмены в экземпляре процесса нет активных экземпляров активности:

Инструкции модификации всегда выполняются в том порядке, в котором их передали. Поэтому одни и те же инструкции в разном порядке могут дать разный результат. Рассмотрим такое дерево экземпляров активности:

Допустим, нужно отменить экземпляр Assess Credit Worthiness и запустить активити Register Application. Эти две инструкции можно упорядочить двумя способами: сначала отмена или сначала запуск. В первом случае код такой:

Из-за распространения отмены экземпляр подпроцесса отменяется при выполнении инструкции отмены, а при выполнении инструкции запуска создается заново. После модификации получается другой экземпляр подпроцесса Evaluate Loan Application. Все сущности, связанные с прежним экземпляром, например переменные и подписки на события, удалены.

Теперь рассмотрим случай, когда сначала выполняется запуск:

Из-за выбора предка по умолчанию при запуске и того, что отмена в этом случае не распространяется на экземпляр подпроцесса, после модификации экземпляр подпроцесса остается прежним. Связанные с ним сущности, например переменные и подписки на события, сохраняются.

Модификация экземпляра процесса учитывает прерывающую или отменяющую семантику запускаемых активити. В частности, запуск прерывающего граничного события или прерывающего событийного подпроцесса отменяет (прерывает) активити, к которой привязано событие или в которой определен подпроцесс. Рассмотрим такой процесс:

Допустим, сейчас активна активити Assess Credit Worthiness. Событийный подпроцесс можно запустить следующим кодом:

Стартовое событие подпроцесса Cancel Evaluation прерывающее, поэтому выполняющийся экземпляр Assess Credit Worthiness будет отменен. То же произойдет, если запустить стартовое событие событийного подпроцесса:

Но если напрямую запустить активити внутри событийного подпроцесса, прерывание не выполняется. Рассмотрим такой код:

Итоговое дерево экземпляров активности:

Модификация работает и для активити с множественным экземпляром (multi-instance). Ниже различаются тело множественного экземпляра (multi-instance body) и внутренняя активити (inner activity). Внутренняя активити это сама активити с идентификатором из модели процесса. Тело множественного экземпляра представляет собой область видимости вокруг этой активити, которая не отображается в модели процесса отдельным элементом. Для активити с идентификатором anActivityId тело множественного экземпляра по соглашению получает идентификатор anActivityId#multiInstanceBody.

Благодаря этому разделению можно запустить как тело множественного экземпляра целиком, так и отдельный экземпляр внутренней активити у выполняющейся параллельной активити с множественным экземпляром. Рассмотрим такую модель процесса:

Допустим, активити с множественным экземпляром активна и у нее три экземпляра:

Следующая модификация запускает четвертый экземпляр активити Contact Customer в том же теле множественного экземпляра:

Итоговое дерево экземпляров активности:

Процессный движок корректно обновляет переменные множественного экземпляра nrOfInstances, nrOfActiveInstances и loopCounter. Если активити с множественным экземпляром настроена по коллекции, при выполнении инструкции коллекция не учитывается и переменная элемента коллекции для дополнительного экземпляра не заполняется. Чтобы ее заполнить, передайте переменную элемента коллекции вместе с инструкцией запуска через метод #setVariableLocal.

Теперь рассмотрим такой запрос:

Он запускает тело множественного экземпляра целиком второй раз, и дерево экземпляров активности становится таким:

Модификацию одного экземпляра процесса можно выполнить асинхронно. Инструкции модификации те же, что и при синхронной модификации, а вызов fluent builder выглядит так:

Этот вызов создает пакетную операцию (batch) модификации, которая выполняется асинхронно. При асинхронной модификации одного экземпляра процесса передавать переменные нельзя.

Если условию удовлетворяют несколько экземпляров процесса, их можно модифицировать за один раз с помощью RuntimeService.createModification(…​). Этот метод позволяет задать инструкции модификации и идентификаторы экземпляров процесса, которые нужно модифицировать. Экземпляры процесса должны относиться к заданному определению процесса.

Fluent builder модификации принимает следующие инструкции:

Экземпляры процесса для модификации выбираются по набору идентификаторов или по запросу экземпляров процесса. Можно указать и то и другое: список идентификаторов и запрос. Тогда модифицируется объединение полученных множеств.

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

Пример синхронного выполнения:

Пример асинхронного выполнения:

В транзакции, которая выполняет модификацию, можно не вызывать слушатели выполнения и задач, а также маппинг входных/выходных параметров. Это полезно, если модификация выполняется в системе, у которой нет доступа к развертываниям затронутых процессных приложений и их классам. Для одного экземпляра процесса используйте метод execute(boolean skipCustomListeners, boolean skipIoMappings) (или executeAsync с теми же параметрами), для нескольких экземпляров процесса методы skipCustomListeners() и skipIoMappings() builder’а модификации.

Метод setAnnotation передает произвольный текст аннотации для аудита.

Аннотация отображается в журнале пользовательских операций для выполненной модификации.

Модификация экземпляра процесса это мощный инструмент: она позволяет запускать и отменять активити как угодно. Поэтому легко получить состояние, недостижимое при обычном выполнении процесса. Рассмотрим такую модель процесса:

Допустим, активна активити Decline Loan Application. С помощью модификации можно запустить активити Assess Credit Worthiness. Когда она завершится, выполнение застрянет на объединяющем параллельном шлюзе: на второй входящий поток управления токен не придет никогда, и шлюз не сработает. Это одна из самых очевидных ситуаций, в которых экземпляр процесса не может продолжить выполнение. В зависимости от модели процесса таких ситуаций может быть много.

Процессный движок не распознает модификации, которые приводят к таким ситуациям. Пользователь API сам отвечает за то, чтобы модификация не оставила экземпляр процесса в нежелательном состоянии. Впрочем, исправлять такие ситуации можно той же модификацией экземпляра процесса.