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

Я думаю, большинству читателей моего блога известно, что такое сделки в Битрикс24, что такое статусы сделок и как можно повесить выполнение определенного бизнес-процесса на переход сделки в определенный статус. Это достаточно тривиальная задача. Мои же клиенты захотели, чтобы каждый продукт в сделке так же обладал своим собственным статусом (состоянием готовности), чтобы набор возможных статусов настраивался отдельно для каждого продукта и чтобы на переход каждого продукта в каждый статус можно было настроить отдельный бизнес-процесс. Все это удалось реализовать за очень короткий срок, не отступая от «золотых правил» разработки под Битрикс.

Стандартными средствами Битрикс24 продукту было добавлено множественное свойство «Возможные статусы»:

После этого я кастомизировала компонент формы редактирования продукта в каталоге, для того, чтобы каждому продукту можно было задавать свой набор статусов и ставить каждому статусу в соответсвие бизнес-процесс из раздела Сервисы — Бизнес-процессы:

Для хранения привязки бизнес-процесса к статусу товара использовано служебное поле Описания значения свойства инфоблока:

Для хранения привязки стейджа к продукту и владельцу (а владельцем может быть не только сделка) был заведен отдельный хайлоадблок:

//первым делом получаем список доступных стейджей для продукта (по ID продукта) и текущий стейдж в хайлоадблоке состояний продуктов, если стейдж уже и так последний — ничего не делаем//если стейдж не последний — находим тот, в который нам нужно перевести продукт//сохранение стейджа продукта — это апдейт или добавление элемента в хайлоадблок состояний
    //интересное начнается при запуске соответсвуюещего БПCModule::IncludeModule(‘bizproc’);//В $UF_STAGE у нас порядковый номер текущего стейджа$BP_ID = $arStagesProperty[‘DESCRIPTION’][$UF_STAGE]; $STAGE_NAME = $arStagesProperty[‘VALUE’][$UF_STAGE];$STAGE_ID=$arStagesProperty[‘PROPERTY_VALUE_ID’][$UF_STAGE]; //В $arIB заранее собрана привязка информационных блоков БП и темплейтов БП (эти ID разные, и разработчики часто их путают)$IB_ID=$arIB[$BP_ID];
//Далее мы собираем виртуальный документ, над которым будет запущен потом экземпляр БП//Через свойства этого виртуального документа можно передать все, что нам понадобится на этапе выполнения БП//эти свойства доступны в свойствах документа при настройке различных активити в дизайнере БП
$documentId = CBPVirtualDocument::CreateDocument(0,array( «IBLOCK_ID» => $IB_ID, «NAME» => «Create Notification», «CREATED_BY» => «user_1», //Запускаем от имени админа «PROPERTY_STAGE_ID»=>$STAGE_ID, «PROPERTY_STAGE_NAME»=>$STAGE_NAME, «PROPERTY_DEAL_ID»=>$UF_OWNER, «PROPERTY_PRODUCT_ID»=>$UF_PRODUCT, «PROPERTY_PRODUCT_NAME»=>$UF_PRODUCT_NAME, «PROPERTY_HEAD_TASK_ID»=>$HEAD_TASK_ID,   )     );
 $arErrorsTmp = array();//Запаскаем нужный БП CBPDocument::StartWorkflow($BP_ID,   array(«bizproc»,»CBPVirtualDocument»,$documentId),  array(), $arErrorsTmp);

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

Тут закономерно возникает вопрос (который я задавала и заказчику на этапе внедрения): а почему бы не реализовать это одним большим и сложным БП, к-й переводит продукт от одного статуса к другому. С таким сложным БП ИТ-специалисту заказчика, к-й будет поддерживать проект было бы тяжело работать. А с выбранной реализацией для того, чтобы изменить поведение системы при переводе конкретного продукта в конкретный статус, ИТ-специалисту заказчика нужно сделать простые и понятные действия на уровне дизайнера бизнес-процессов в очень простых и маленьких БП.

php-вставка для перевода продукта из одного стейджа в другой и запуска соответсвующего БП выглядела примерно так же, как и скрипт перевода продукта из одного стейджа в другой, за исключением того, что переменные приходили не из POST-запроса, а из переменных БП и из свойств виртуального документа:

$product_id='{=Document:PROPERTY_PRODUCT_ID}’;
$owner_id='{=Document:PROPERTY_DEAL_ID}’;
$head_task_id='{=Variable:HEADTASKID_printable}’;

Кстати реализация подобного кейса не возможна в облачной версии Битрикс24. Поэтому своим клиентам я рекомендую покупать именно коробочную версию. Ведь в коробке Битрикс24 можно реализовать любые хотелки, и облачная версия в контексте подобных задач — просто ущербна.