Перейти к содержимому
BXWiki

Перенос бизнес-процесса между стендами - шаблон, привязка, права

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

Что нужно знать заранее

Шаблон процесса хранится в базе, а не в файлах проекта. Значит, обычная выкладка кода его не переносит, и переносить приходится отдельным шагом вместе с миграциями структуры.

Шаблон привязан к типу документа и к конкретному хранилищу. Для универсального списка и для инфоблока привязка включает числовой идентификатор, а он на стендах разный.

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

Шаги

  1. Посмотреть, к какому типу документа привязан шаблон на стенде разработки.
  2. Выгрузить шаблон файлом и положить его в репозиторий рядом с миграциями.
  3. Проверить на боевом сайте идентификатор хранилища, к которому идёт привязка.
  4. Загрузить шаблон и убедиться, что он виден в нужном списке процессов.
  5. Вернуть права на запуск и проверить процесс на одном тестовом документе.

Решение

Смотрим привязку шаблонов на стенде:

\Bitrix\Main\Loader::includeModule('bizproc');
$docType = ['lists', 'BizprocDocument', 'iblock_' . $iblockId];   // тип документа
$rs = \CBPWorkflowTemplateLoader::GetList([], ['DOCUMENT_TYPE' => $docType],
    false, false, ['ID', 'NAME', 'MODIFIED', 'AUTO_EXECUTE']);
while ($row = $rs->Fetch()) { printf("%d %s %s\n", $row['ID'], $row['NAME'], $row['MODIFIED']); }

Третий элемент типа документа - это идентификатор хранилища. Именно он делает перенос нетривиальным: на боевом сайте у того же списка будет другой номер.

Находим идентификатор хранилища по коду:

$iblock = \Bitrix\Iblock\IblockTable::getRow(['filter' => ['=CODE' => 'vendor_registry'],
    'select' => ['ID', 'IBLOCK_TYPE_ID']]);
printf("на этом стенде: %d\n", $iblock['ID']);   // код одинаков, номер разный

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

Храним выгруженный шаблон в репозитории:

Окно терминала
ls -la migrations/bizproc/               # файлы шаблонов рядом с миграциями
git add migrations/bizproc/soglasovanie.bpt
git commit -m "процесс согласования: версия от 20.08"
# сравнить две версии файла не выйдет: фиксируйте изменения в описании коммита

Файл шаблона нечитаем глазами и не сравнивается построчно. Поэтому в описание коммита пишут словами, что изменилось в маршруте: это единственная понятная история правок процесса.

Проверяем запущенные экземпляры перед правкой:

SELECT COUNT(*) FROM b_bp_workflow_instance;
SELECT DOCUMENT_ID, STARTED FROM b_bp_workflow_state ORDER BY STARTED DESC LIMIT 10;
-- незавершённые процессы означают, что правку шаблона стоит отложить

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

Проверяем перенос на одном документе:

$errors = [];
\CBPDocument::StartWorkflow($templateId, $docType,
    ['lists', 'BizprocDocument', 'iblock_' . $iblockId . '_' . $elementId],
    ['ApprovedBy' => 1], $errors);
print_r($errors);   // пустой массив означает, что запуск прошёл

Типичные проблемы

Перенесённый шаблон не виден в списке процессов.

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

Часть документов идёт по старому маршруту после правки.

Запущенные экземпляры работают по копии шаблона на момент своего старта. Новый маршрут получают только процессы, запущенные после правки шаблона.

Процесс перенесён, но сотрудники не могут его запустить.

Права на запуск задаются отдельно от шаблона и в перенос не попали. Права проверяют и выдают на боевом сайте после загрузки шаблона.

Код внутри процесса падает на боевом сайте.

В коде действия записаны числовые идентификаторы инфоблоков или пользователей со стенда. Внутри процесса опираются на коды и на настройки, а не на номера записей.

Никто не помнит, что менялось в маршруте.

Файл шаблона хранится в репозитории, но построчно не сравнивается. Изменения маршрута описывают словами в коммите и в описании самого шаблона.

Частые вопросы

Почему шаблон нельзя просто выложить с кодом?

Он хранится в базе, а не в файлах проекта, и выкладка кода его не переносит. Перенос делают отдельным шагом вместе с миграциями структуры.

Что означает третий элемент типа документа?

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

Можно ли править шаблон на боевом сайте?

Мелкие правки - да, но запущенные процессы продолжат идти по прежней копии. Изменение маршрута сначала прогоняют на стенде: откатывать процесс дороже, чем код.

Что делать с процессами на старом маршруте?

Либо дать им дойти до конца, либо завершить принудительно и запустить заново. Второе выбирают, когда старый маршрут ведёт не туда, куда нужно бизнесу.

Как хранить историю версий шаблона?

Файлами в репозитории плюс описание изменений словами в коммите. Сравнить два файла шаблона построчно не получится, формат этого не позволяет.

Смежное

Первоисточник