Миграция процессов

Camunda 7
1

Всем привет!

Итак, у вас есть процессное приложение на Camunda BPM. Бизнес-процессы (как и в целом мир) подвержены трансформации.

В среднем, даже в ходе PoC/пилотного проекта автоматизируемый процесс улучшается порядка 5-6 раз. Если процесс меняется в результате изменений требований законодательства, тарифов или ВНД, предыдущие экземпляры процесса в большинстве случаев исполняются на старой версии, пока процесс не завершится (или например, не истекут условия договора).

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

На этом месте счастливые обладатели Camunda Enterprise могут проходить мимо и радоваться - весь нужный функционал есть у них в Cockpit. Остальным эта заметка, надеюсь, будет полезна.

На помощь приходит Camunda REST API и Postman.

Первым делом необходимо сгенерировать план миграции, указав исходный и целевой process definition id (не путать с process definition key). Id описания процесса (который процесс приобретает после деплоя в базу) - содержит в себе версию процесса. Пример запроса:

https://docs.camunda.org/manual/latest/reference/rest/migration/generate-migration/

Полученный в ответе на предыдущий запрос план миграции необходимо провалидировать, направив его в теле следующего запроса:

https://docs.camunda.org/manual/7.14/reference/rest/migration/validate-migration-plan/

Если все ОК, то валидация возвращает пустой массив instructionReports.

Завершающий шаг - упаковка плана миграции в запрос, содержащий в себе выбранные экземпляры процесса, подлежащие миграции. Отобрать их можно через либо через processInstanceQuery, либо указать список явно в processInstanceIds.

https://docs.camunda.org/manual/7.14/reference/rest/migration/execute-migration/

Если все ОК, система вернет код 204, иначе - описание ошибки.

Бонус:

Bash-скрипт для миграции экземпляров процессов на последнюю версию через REST API. Подходит, например, для встраивания в CI/CD pipeline (если при поставке необходимо смигрировать процессы на новую версию). Настройки описаны в README.MD.

UPDATE:

Если артефакт процесса (шлюз, задача, etc) поменяли id, или процесс значительно поменял структуру, необходимо:

  1. Отдельно сгенерировать план миграции
  2. Дополнить его, сопоставив старые/новые id или прописав, куда мигрировать конкретный wait state (например, в новой версии процесса отсутствует user task), пример:

{ "sourceActivityIds":["loanReviewTask"], "targetActivityIds":["loanApproveMessage"], "updateEventTrigger":false }

  1. Выполнить миграцию.

Вышеуказанный скрипт можно разделить на 2 части:

  • Подготовка плана (с дальнейшим дополнением его “ручными” инструкциями)
  • Валидация и исполнение

P.S. А как вы мигрируете ваши процессы?

2 лайка
2

UPDATE:

Если артефакт процесса (шлюз, задача, etc) поменяли id, или процесс значительно поменял структуру, необходимо:

  1. Отдельно сгенерировать план миграции
  2. Дополнить его, сопоставив старые/новые id или прописав, куда мигрировать конкретный wait state (например, в новой версии процесса отсутствует user task), пример:

{ "sourceActivityIds":["loanReviewTask"], "targetActivityIds":["loanApproveMessage"], "updateEventTrigger":false }

  1. Выполнить миграцию.

Вышеуказанный скрипт можно разделить на 2 части:

  • Подготовка плана (с дальнейшим дополнением его “ручными” инструкциями)
  • Валидация и исполнение
1 лайк
3

UPDATE.

Полезная информация относительно миграции по итогам общения с коллегами из Camunda.

  1. В Camunda 7.16 обещают улучшения, позволяющие сделать процесс миграции более удобным.

  2. Есть известная боль миграции, связанная с тем, что Camunda не дает выполнить перенос экземпляра процесса в том случае, если поменялся тип текущей задачи (Service, Script, etc) или его реализация (Class, Delegate Expression, etc).

Я подобную проблему решал так:

  • модификация экземпляра процесса (откат на предыдущий wait state)
  • миграция
  • обратная модификация экземпляра процесса (если требуется)

Коллеги из Camunda предложили альтернативу в виде промежуточного описания процесса, т.н. Migration Island (см изображение ниже):

migration_island
migration_island1071×2466 246 KB

Таким образом, миграция делится на 2 части:

  1. перенос с исходного описание процесса на migration island, преобразование данных
  2. перенос на целевое описание процесса
1 лайк
4

По работе столкнулся с необходимость миграции 5000+ экземпляров процесса
Как оказалось для этой задачи лучше подходит асинхронная миграция

Миграция может выполняться синхронно (с блокировкой) или асинхронно (неблокируя) с использованием batch (Batch | docs.camunda.org).

Ниже приведены некоторые причины предпочесть тот или иной вариант:

Используйте синхронную миграцию, если:

-количество экземпляров процесса невелико
-миграция должна быть атомарной, т. е. она должна выполняться немедленно и завершаться ошибкой, если хотя бы один экземпляр процесса не может быть перенесен.

Используйте асинхронную миграцию, если:

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

Результат вызова executeAsync
{
“id”: “aBatchId”,
“type”: “aBatchType”,
“totalJobs”: 10,
“batchJobsPerSeed”: 100,
“invocationsPerBatchJob”: 1,
“seedJobDefinitionId”: “aSeedJobDefinitionId”,
“monitorJobDefinitionId”: “aMonitorJobDefinitionId”,
“batchJobDefinitionId”: “aBatchJobDefinitionId”,
“tenantId”: “aTenantId”
}

1 лайк