воскресенье, 19 июля 2015 г.

Битрикс24 - опыт расширения функционала за счет бизнес-процессов (коробочная версия)

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

В этом июне мне посчастливилось реализовать на базе Битрикс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 можно реализовать любые хотелки, и облачная версия в контексте подобных задач - просто ущербна.

Комментариев нет: