Комментарии 9
И где тут про гидралисков?
Почему у всс все варианты - нарисовать в новой схеме какие-то шаги миграции.
Почему бы не написать вообще внешний мигратор, у которого будет таблица : старый шаг, новый шаг, код который нужно выполнить, включая и модификацию переменных процесса. Единственная проблема здесь, если без ручного вмешательства миграция невозможна, нет данных. Ну по крайней мере можно выбрать хоть какой-то шаг с минимумо потерь.
Спасибо за дополнение, это вполне валидный вариант миграции. Некоторые BPM-продукты даже имеют поддержку подобных миграций, например, у Camunda есть Cockpit.
Есть ограничение -- ни Camunda, ни Pega не предоставляют API, чтобы мигрировать шаг с изменением его типа: ручной в автоматический, автоматический в подпроцесс и другие комбинации. Для решения этой проблемы мы применяем варианты с шагами миграции на схеме -- например, паттерн Migration Island.
Спасибо. Я в камунде только мельком читал про миграцию, и о таких ограничениях не знал.
Как вариант, при миграции, если это не ручной шаг, пинать процесс дальше, срывая например время ожидания, или генерируя событие, чтобы перейти в то состояние которое легко мигрировать.
С другой стороны, если полезть напрямую в базу, конечно ограничений нет. :)
Спасибо за статью. Небольшое дополнение.
Предположим также, что ручные шаги выполняются в веб-приложении — и у него вышла новая версия, где на форме задачи появилась кнопка «Отклонить». Что же произойдёт, когда пользователь откроет задачу из старого процесса и нажмёт на эту новую кнопку? Наше решение попробует выполнить альтернативное действие на старом процессе, где его нет, что приведёт к ошибке.
Есть вариант когда доступность кнопок описывается в рабочем процессе. Веб-приложение только рисует кнопки полученные от рабочего процесса.
Тогда описанной выше проблемы не будет: задачи новой версии рабочего процесса будут иметь кнопку, для старых задач кнопки не будет. Конечно это не отменяет необходимости миграции если нужно и старые задачи перевести на новый процесс.
Самореклама:
видео прототипа движка рабочих процессов с генерацией кнопок (4 мин)
https://vimeo.com/632994077
online демо конструктора форм
https://alexeyboiko.github.io/FormDesignerDemo/
презентация
https://1drv.ms/p/s!AtucE3yK2YmNg0OdNt0FmTKnKfZZ?e=zGmp4o
Как я понял, у вас весь процесс завязан на одной форме. И в зависимости от текущего шага вы или показываете поле или нет.
Все движки BPM работают по-другому. В процессе есть точка - ручное вмешательство. Вот для этой точки и рисуется форма. И проблемы с полями нет - так как иначе вы бы вообще не увидели данную форму, ели бы она вам не пришла по процессу. Плюс для каждой точки рисуется своя форма, сложной логики что показывать а что нет здесь нет - показывается вся форма.
Как я понял, у вас весь процесс завязан на одной форме.
Нет, форм можно сделать сколько угодно. Движок выбирает форму (а точнее описание формы) в зависимости от текущего пользователя и статуса объекта (заявки/задачи). Так же выбираются и доступные действия (кнопки): от текущего пользователя и статуса.
Спасибо за предложенный вариант. Конечно, кнопки -- это лишь пример, измениться может и состав отображаемых / вводимых данных на форме.
Поэтому в общем случае этот вариант требует передачи BPM-продуктом, помимо данных формы, её полного метаописания, достаточного для генерации экранной формы универсальным интерпретатором метаязыка. В этом случае в каждую версию процесса заложены метаописания каждого шага, что позволяет корректно отображать формы старых версий процесса.
К сожалению, сам подход с отрисовкой форм по метаописанию, по нашему опыту, годится только для прототипирования и простейших приложений. В решениях, над которыми мы работаем, этот подход не справляется с требованиями к современным UI/UX. Попытки наращивать функциональность метаязыка приводят, в конечном итоге, к изобретению аналогов HTML/CSS/JS. Более перспективной альтернативой мне видится отрисовка на фронте экранной формы с учётом версии процесса, а не только идентификатора шага.
Но, в любом случае, ещё остаётся проблема с шагами других типов -- например, заполнением / разбором интеграционных сообщений в автоматических шагах. Здесь по-прежнему потребуются адаптеры для разных версий.
Попытки наращивать функциональность метаязыка приводят, в конечном итоге, к изобретению аналогов HTML/CSS/JS
Это точно. С конструкторами форм нужно знать меру. Думаю что конструктор должен уметь
задавать проверку полей по regex
скрывать/показывать поля в зависимости от значения других полей
настраивать связанные выпадающие списки
Все остальное в конструктор не пихать. С таким набором функций конструктором еще можно пользоваться.
Однако, ограничение конструкторов не означает что они нигде не применимы. Для многих задач конструкторов хватит. Взять хотя бы SharePoint - там вообще можно только местами поля менять.
В прототипе (давал ссылку выше) для случаев когда конструктора не хватает предлагается реализовать самодельные контролы (индивидуально под заказчика). И вставлять эти самодельные контролы в формы, так же как и предустановленные контролы, через дизайнер.
Концепция “сделай рабочий процесс без программистов” немного страдает, но в целом полезность движка рабочий процессов сохраняется: настройка статусов и переходов, обработчики команд, доступность форм/полей, история рабочего процесса, логирование и проч.
Заднее число против обратной силы, или Миграции в BPM-решениях