Как обновить БП, если по нему уже идет работа в CRM

Опишу ситуацию:
По старой версии БП были запущены процессы. После этого возникла необходимость изменить БП и были внесены соответствующие изменения. Старые БП нельзя просто так завершить, в виду того, что их выполнение не предполагает быстрого выполнения (например, ожидается ответ от клиента, а это нельзя никак ускорить так, чтобы завершить БП).
Вопрос: как сделать так, чтобы незавершенные БП пошли дальше по новому БП?
Новая версия БП довольно серьезно отличается от старой (новые ветки, задачи, добавлены новые параметры). Есть ли какой-то алгоритм как можно сделать безболезненный переход? Поделитесь опытом как вы решали такие ситуации.

Нравится

7 комментариев

Было такое, решали тем, что "замыкали" выходы со всех задач старого процесса на новый. Возможно вариации, но общая схема такая:
1) В новом процессе:
- добавляем параметр процесса OldActionName, тип строка, в нем будет передано название того элемента старого процесса, из которого попали в новый. Если процесс запускаем сам по себе - значение будет пусто.
- в начале ставим блок-условие, которое анализирует значение параметра OldActionName и переходит на соответствующую задачу.
2) В старом процессе:
- добавляем блок-подпроцесс с новым процессом
- после блоков-задач ставим блок-скрипт, который выставляет значение параметра OldActionName нового процесса, и собственно переходит на новый процесс.

Чтобы не превращать оба процесса в "паутину" связей :), можно сначала запросом к таблице tbl_WorkflowItem определить названия незавершенных элементов процессов, и настроить переходы только для них.

"Валерий Андрусик" написал:Возможно вариации, но общая схема такая

Валерий, спасибо за то, что поделились опытом. Все еще думаю как сделать лучше.

А что если изменять значения параметров в диаграмме и элементах уже запущенного БП, и сделать так, чтобы эти параметры указывали на следующий исполняемый элемент из нового БП, тогда не нужно будет 2 отдельных процесса (старый и новый), то есть внести изменения в таблицы tbl_Workflow и tbl_WorkflowItem?

Дело в том, что сама диаграмма хранится как сервис. В tbl_WorkflowItem мы видим только отработанные и текущие элементы процессов (будущих там нет). Ядро Террасофт создает следующую запись в tbl_WorkflowItem только при отработке текущей задачи, ориентирусь на схему процесса в tbl_Service.
Если я правильно понял, у вас на рабочей базе работает старый процесс, а на базе разработки вы расширили его же. Если при этом у вас в новой версии диаграммы сохранились все элементы старой, с теми же кодами, то думаю можно просто обновить сервис - при отработке элемента ядро найдет в новой диаграмме новые связи. А вот если изменения повлекли в том числе и удаление элементов или их переименование - тогда хуже. Я бы тогда советовал сделать новый процесс (с другим USI), и настроить переход на него. Может еще специалисты Террасофт посоветует что-то.

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

Очень интересненько... возьму на заметку.

Да, правильно

Действительно, Валерий правильно подсказал решение. Оно и довольно простое, но в то же время приводит к результату. Процессы при экспорте-импорте в xml файлах указаны только перечень элементов процесса. Элементы же хранятся в tbl_WorkflowItem и кто у них следующий узнают только после перехода в состояние "Выполнено", тогда в сервисе процесса ищется тот, который должен выполняться следующим. Поэтому предложенная "подмена" - это почти законный способ "перевести" элементы старого процесса на выполнение в рамках нового.

Показать все комментарии