Спасибо за предложенный вариант. Конечно, кнопки -- это лишь пример, измениться может и состав отображаемых / вводимых данных на форме.
Поэтому в общем случае этот вариант требует передачи BPM-продуктом, помимо данных формы, её полного метаописания, достаточного для генерации экранной формы универсальным интерпретатором метаязыка. В этом случае в каждую версию процесса заложены метаописания каждого шага, что позволяет корректно отображать формы старых версий процесса.
К сожалению, сам подход с отрисовкой форм по метаописанию, по нашему опыту, годится только для прототипирования и простейших приложений. В решениях, над которыми мы работаем, этот подход не справляется с требованиями к современным UI/UX. Попытки наращивать функциональность метаязыка приводят, в конечном итоге, к изобретению аналогов HTML/CSS/JS. Более перспективной альтернативой мне видится отрисовка на фронте экранной формы с учётом версии процесса, а не только идентификатора шага.
Но, в любом случае, ещё остаётся проблема с шагами других типов -- например, заполнением / разбором интеграционных сообщений в автоматических шагах. Здесь по-прежнему потребуются адаптеры для разных версий.
Спасибо за дополнение, это вполне валидный вариант миграции. Некоторые BPM-продукты даже имеют поддержку подобных миграций, например, у Camunda есть Cockpit.
Есть ограничение -- ни Camunda, ни Pega не предоставляют API, чтобы мигрировать шаг с изменением его типа: ручной в автоматический, автоматический в подпроцесс и другие комбинации. Для решения этой проблемы мы применяем варианты с шагами миграции на схеме -- например, паттерн Migration Island.
Спасибо за предложенный вариант. Конечно, кнопки -- это лишь пример, измениться может и состав отображаемых / вводимых данных на форме.
Поэтому в общем случае этот вариант требует передачи BPM-продуктом, помимо данных формы, её полного метаописания, достаточного для генерации экранной формы универсальным интерпретатором метаязыка. В этом случае в каждую версию процесса заложены метаописания каждого шага, что позволяет корректно отображать формы старых версий процесса.
К сожалению, сам подход с отрисовкой форм по метаописанию, по нашему опыту, годится только для прототипирования и простейших приложений. В решениях, над которыми мы работаем, этот подход не справляется с требованиями к современным UI/UX. Попытки наращивать функциональность метаязыка приводят, в конечном итоге, к изобретению аналогов HTML/CSS/JS. Более перспективной альтернативой мне видится отрисовка на фронте экранной формы с учётом версии процесса, а не только идентификатора шага.
Но, в любом случае, ещё остаётся проблема с шагами других типов -- например, заполнением / разбором интеграционных сообщений в автоматических шагах. Здесь по-прежнему потребуются адаптеры для разных версий.
Спасибо за дополнение, это вполне валидный вариант миграции. Некоторые BPM-продукты даже имеют поддержку подобных миграций, например, у Camunda есть Cockpit.
Есть ограничение -- ни Camunda, ни Pega не предоставляют API, чтобы мигрировать шаг с изменением его типа: ручной в автоматический, автоматический в подпроцесс и другие комбинации. Для решения этой проблемы мы применяем варианты с шагами миграции на схеме -- например, паттерн Migration Island.