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

Всем привет!

Итак, у вас есть процессное приложение на 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 симпатии

UPDATE:

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

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

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

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

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

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

UPDATE.

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

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

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

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

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

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

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

  1. перенос с исходного описание процесса на migration island, преобразование данных
  2. перенос на целевое описание процесса
1 симпатия