битрикс24 активити php код
Создаём Activity для Бизнес-процессов
Доброго времени суток!
Нигде не встречал, чтобы клиенты создавали свои Activity (Действия) для бизнес-процессов. Думаю, что это связано с отсутствием соответствующей документации.
В данной статье постараюсь пошагово описать процесс создания своего Activity на примере действия, которое будет писать в лог БП или текстовый файл, произвольные значения из шаблона бизнес-процесса.
[spoiler]
1. Создаём структуру файлов будущего Activity.
Хочу сразу отметить, что название папки с Activity должно совпадать с именем файла, в котором находится класс с Activity, в данном случае файл называется write2logactivity.php
В визуальном редакторе получаем своё действие:
Далее программируем форму настроек действия. Код формы находится в файле properties_dialog.php:
В результате на экране получим:
В зависимости от положения галочки «Писать файл», вывод мы получим или в логе БП:
либо в файле:
3. Сохранение настроек, сделанных в диалоге настройки действия:
4. Выполняем проверку полученных значений, если требуется выводим ошибку:
Вот в общем и всё, труднее было начать, чем сделать.
Битрикс. Бизнес-процессы. PHP-код.
Недавно ко мне обратился насяльника с просьбой помочь в написании бизнес-процесса (далее в статье БП) для автоматической отсылки писем клиентам, у которых подходит срок оплаты хостинга.
Для полноценной работы с дизайнером шаблонов БП потребуется администраторский доступ к корп-порталу.
Находим шаблоны, прикреплённые к списку клиентов хостинга.
Создаём новый Последовательный БП. Битрикс предлагает нам вполне наглядный дизайнер шаблонов БП, к особенностям которого всё-таки придётся привыкнуть (впрочем, как и ко всему, что обладает объёмным синтаксическим и семантическим функционалом).
В диалоге Параметры шаблона находим третью вкладку Переменные и создаём строковую переменную с идентификатором payed_to и с таким же именем. Чуть позже увидим зачем нам эта переменная.
Заодно отключим автоматический запуск при создании и изменении. Эти галочки можно потом проставить, а для дебага они будут мешаться.
1. Общая логика
Для начала составим у себя в голове логику действий.
2. Используемые блоки
Опишем используемые блоки и их функциональность, которую далее используем в решении задачи.
2.1 Изменение переменных
Блок позволяет присваивать переменным шаблона БП какие-то значения. Например, взятые из текущего элемента, к которому прикреплён БП.
2.2 PHP-код
Блок позволяет выполнять PHP-код (всегда ваш, капитан очевидность).
Здесь можно общаться с переменными шаблона и свойствами элемента списка с помощью двух способов.
1. Непосредственное обращение к переменной. Синтаксис обращения можете получить с помощью кнопочки с тремя точечками. Например, получим значение свойства элемента PAYED.
Задание значения переменной осуществляется при помощи функции SetVariable.
3. Составляем демо-шаблон
На основе того, что я знаю, составляю шаблон. Не очень понятно как получить свойство элемента внутри условия Цикла, поэтому я сначала присваиваю значение переменной payed_to, а потом получаю его в условии Цикла. Собственно говоря, для этого я и заводила эту переменную. Ну и для сопутствующего дебага, конечно.
Как перетаскивать блоки в дизайнере, я надеюсь, вы и сами разберётесь =)
3.1 Изменение переменных
3.2 PHP-код
3.3 Цикл
3.4 PHP-код. Вывод в лог.
А дальше и так понятно =)
4. Тестирование и лог
Создаём тестового клиента в списке. Запускаем для него из диалога действий требуемый БП ручками.
Как написать кастомную активити для бизнес-процесса для облачного Битрикс24
На зимней партнерской конференции 1C-Битрикс 2016г Олег Строкатый и Алексей Кирсанов показывали мастер-класс, в ходе которого разработали кастомную активити для бизнес-процесса под облачный Битрикс24. Информация по данной теме есть так же в курсе «Разработчик Bitrix Framework» (ссылки — в конце поста).
Изучив указанные материалы и опробовав их на своих проектах, мы составили для себя простую и подробную памятку действий по разработке активити для облачного Битрикс24, включающую в себя так же некоторые мелочи, которые в вышеуказанных источниках были недосказаны, видимо, в расчете на то, что у разработчика, изучающего их, уже есть определенный базис знаний. Этой памяткой я и хочу поделиться в данном посте.
Кастомная активити для облачного Битрикс24 реализуется как приложение так называемого «второго типа». То есть php-файл с обработчиком активити и с ее установщиком должен лежать где-то на внешнем web-сервере, а Битрикс24 будет обращаться к нему по определенному адресу, например,
Именно этот адрес и используется для добавления приложения в портал, и для публикации приложения в маркетплейс Битрикс24.
Для корректной работы такого приложения домен должен обладать SSL сертификатом (минимум Domain Validation (DV) Certificate). Вести разработку и тестирования приложения можно и без SSL сертификата, но он понадобится для реальной работы приложения, поэтому о нем стоит позаботиться заранее.
1.2 Структура приложения
В самом файле-приложении, прежде всего, необходимо сформировать скелет — структуру страницы приложения.
Данный скелет сразу можно подключить в тестовом портале как будет описано ниже и начать наращивать и отлаживать. Когда мы будем менять что-то в коде приложения на нашем сервере — переподключать приложение на стороне Битрикс24 не нужно — достаточно просто перезагрузить страницу приложения.
2 Какие данные мы получаем и как их проверить
Можно (и нужно) использовать и более сложные проверки с использованием регулярных выражений, но данный пост не о них.
3 Использование REST-api Битрикс24 на php
Далее нам понадобится php-функция, которая посредством curl будет посылать запросы к Битрикс24:
Если нам нужно будет вызвать rest-апи Битрикс24 из php-кода — мы далее можем использовать данную функцию:
4 Метод отладки приложения
Сразу встает вопрос: а как отлаживать наше приложение? Оно же выполняется у нас на сервере — значит мы можем смело все логировать в какой-то файл. Можно, например, использовать функции php fopen, fwrite, fclose. Ну а у нас на сервере тоже стоит Битрикс, поэтому нам нравится использовать функцию AddMessage2Log из битрикс-фреймворка (предварительно подключив заголовок).
5 Использование REST-api Битрикс24 на javascript
Мы можем вызывать rest-апи битрикс24 и через javascript. Следующим образом:
6 Создание и удаление простого активити
В частности нам нужны 2 javaскрипт обработчика для установки и удаления нашей активити (в данном примере мы создаем для облачного Битрикс24 активити, которая запрашивает идентификатор пользователя и возвращает бизнес-процессу его данные: телефон, skype и должность):
7 Логирование запросов и ответов на javascript
Если мы планируем размещать наше приложение в Маркетплейс Битрикс24, мы обязаны логировать все запросы и все ответы от Битрикс24 — не только те, которые посылаем из php-кода, но и те, которые мы посылаем из javascript
Если у нас на сервере тоже стоит Битрикс, можно использовать функции js библиотеки битрикс-фреймворка.
Скрипт-логгер, который мы дергаем по аяксу из нашего javascript может выглядеть так:
8 Не забыть вернуть ответ бизнес-процессу
Если объявляя активити, мы задали параметр ‘USE_SUBSCRIPTION’:’Y’ мы обязаны вернуть бизнес-процессу ответ, соответсвующий описанному для активити массиву выходных параметров RETURN_PROPERTIES. Для этого используем rest-api bizproc.event.send
9 Добавление приложения в портал
Чтобы добавить приложение в портал Битрикс24, его не обязательно публиковать в Маркетплейсе — можно добавить его только в свой портал — для использования только в этом портале. Для этого в левом меню облачного Битрикс24 выбираем пункт «Добавить приложение», далее выбираем «Для личного использования».
В открывшейся форме указываем название приложение, название пункта меню, указываем, права на доступ к каким подсистемам необходимы приложению. Если наше приложение добавляет активити в бизнес-процесс, то необходимо отмечать галку Бизнес-процессы. Указываем ссылку на файл приложения, лежащий на нашем сервере.
Добавленное приложение появляется в списке локальных приложений и в меню приложений.
На странице приложения в портале Битрикс24 у нас 2 кнопки, обработчики которых описаны в посте ранее. Одна кнопка устанавливает нашу кастомную активити, вторая — удаляет.
После установки активити появлется в редакторе бизнес-процесса.
Кастомную активити можно включить в бизнес-процесс, задать ей те входные параметры, которые мы определили, как входные, и она будет работать.
10 Что будет, если удалить кастомную активити, которая включена в бизнес-процесс?
В этом случае бизнес-процесс перестанет отрабатывать корректно, а в редакторе бизнес-процесса данная активити будет подсвечена красным цветом.
Создаем свое «Действие» в коробочном Битрикс24
Всем привет!
Будем учиться кастомизировать Битрикс24 
Модуль бизнес-процессов позволяет администраторам корпоративных порталов автоматизировать деятельность организации без привлечения программиста. Для этого модуль БП предоставляет визуальный конструктор шаблонов БП, в котором разрабатывается алгоритм или конечный автомат. Алгоритм состоит из действий (например, утверждение документа, запрос доп. информации, постановка задачи, изменение полей документа и т. п.), с помощью которых строится взаимодействие с сотрудниками и автоматизируются некоторые операции над документами.
Иногда случается так, что штатных возможностей модуля БП недостаточно для реализации того или иного БП. Разработчиками модуля предусмотрены различные механизмы расширения возможностей БП. Один из них — возможность разрабатывать собственные действия для конструктора шаблонов БП. Эта возможность доступна как для облачных, так и для коробочных версий КП, но принципы разработки для облака и коробки сильно отличаются.
В данной статье мы рассмотрим разработку собственного действия для коробочной версии КП на примере одной из задач кредитной организации. Некоторая информация о разработке своих действий имеется в курсе по бизнес-процессам: https://dev.1c-bitrix.ru/learning/course/index.php?COURSE_ID=57&CHAPTER_ID=04567
Постановка задачи
Общая задача: автоматизировать процесс обработки заявки для кредитной организации.
В процессе обработки заявки на кредит сотрудники совершают звонки заемщикам, поручителям, родным, знакомым, работодателю и т. п. Общий бизнес-процесс ставит задания сотрудникам типа «позвонить заемщику». Однако для совершения звонка через стандартную телефонию, сотрудник должен перейти на детальную страницу документа БП (в нашем случае — сделки CRM), затем позвонить клиенту, задать вопросы и заполнить анкету (которая еще должна быть перед глазами) ответами на эти вопросы.
Частная задача: уменьшить затраты времени сотрудников на обзвон и анкетирование клиентов и поручителей.
Для решения этой задачи разрабатываем действие БП «Звонок клиенту с анкетой». Данное действие должно позволять поставить задание сотруднику на звонок кому-либо с заполнением анкеты (похож на запрос доп. информации). Сотрудник должен видеть кнопку звонка, по нажатии на которую начинается вызов абонента через телефонию Б24, а также выводятся поля анкеты для заполнения.
Разработка действия БП «Звонок клиенту с анкетой»
1. Подготовка объекта
Нестандартные действия БП должны располагаться в каталоге /local/activities.
Для начала выберем название для нашего действия: IvSipCallActivity.
На возврате значений остановимся подробнее. Существует два способа описать возвращаемые значения: с помощью ключей RETURN и ADDITIONAL_RESULT.
Используйте RETURN, если вам заранее известен состав возвращаемых значений. Например, если вы разрабатываете действие «Сумма чисел», то вы заранее знаете, что выход у действия будет один — значение суммы.
RETURN должен содержать массив, описывающий каждое возвращаемое значение следующим образом:
Если вы не знаете заранее, какие возвращаемые значения будут у действия, используйте ADDITIONAL_RESULT. Например, в нашем действии звонка с анкетой возвращаемыми значениями будут значения полей анкеты. Проблема в том, что заранее не известно, какие поля будут в анкете — это зависит от настроек действия.
ADDITIONAL_RESULT должен содержать последовательный массив названий свойств действия, из которых будут взяты возвращаемые значения. А значения этих свойств будут заданы уже в конструкторе и/или во время выполнения БП. В нашем примере возвращаемые значения будут взяты из свойства QuestionnaireResults (результаты заполнения анкеты).
Использовать одновременно RETURN и ADDITIONAL_RESULT нельзя: будут использованы значения только из RETURN.
Поскольку мы разрабатываем «обычное действие» (которое не будет содержать дочерних действий), наш класс должен быть унаследован от CBPActivity. Если же вам понадобится разработать действие, которое должно содержать дочерние действия (как, например, альтернативы и циклы), наследуйте класс своего действия от CBPCompositeActivity.
Создадим класс и определим в нем самые необходимые методы. Реализацию рассмотрим далее.
Создайте файлы локализации и откройте конструктор шаблонов БП. На данном этапе должно быть возможно добавить наше действие в шаблон из панели справа.
Чтобы у действия появилась форма настроек, необходимо создать два метода: GetPropertiesDialog и GetPropertiesDialogValues. Первый отвечает за формирование HTML формы настроек, второй — за обработку отправки формы пользователем.
Начнем с GetPropertiesDialog. Этот метод похож на код компонента: сначала формируется массив значений для полей формы, а затем вызывается шаблон самой формы. HTML формы можно сформировать прямо в этом методе, однако, “каша” из HTML и PHP снизит сопровождаемость вашего кода, поэтому такой подход применять не рекомендуется.
Логика подготовки данных следующая:
если форма была отправлена ранее, использовать имеющиеся данные, в противном случае:
инициализировать массив данных формы по-умолчанию,
загрузить свойства действия и дополнить этот массив значениями, которые могли быть сохранены ранее.
Метод имеет много формальных аргументов, поэтому здесь они не приводятся. В исходном коде класса действия вы можете найти их все, а также там есть документирующие комментарии с описанием каждого аргумента.
В нашем случае данные для формы и свойства действия для хранения настроек совпадают, поэтому код инициализации можно скопировать из конструктора.
Важно! Списки пользователей (поле «Ответственный») должны храниться в специальной форме в виде массива. В конструкторе это же самое поле представлено строкой. Поэтому мы используем метод CBPHelper::UsersArrayToString на значении свойства Responsible, перед тем, как передать его в форму. При сохранении настроек требуется конвертация в обратную сторону, пример будет далее.
Код формы настроек — преимущественно HTML. Конструктор шаблонов БП ожидает, что метод GetPropertiesDialog вернет фрагмент HTML-таблицы, поэтому каждое поле необходимо описывать тегом tr.
Шаблон формы настройки будем хранить отдельно от логики действия. Для этого создадим файл properties_dialog.php в каталоге действия. Чтобы выполнить этот шаблон воспользуемся методом ExecuteResourceFile исполняющей среды, который запускает PHP-файл в режиме буферизации и возвращает весь вывод скрипта в виде строки. В третьем аргументе укажем, какие переменные будут доступны в области видимости скрипта: ключ — название переменной в скрипте.
Код формы довольно объемный, просмотрите его самостоятельно и прочтите комментарии. Здесь лишь опишем общие соображения о создании шаблонов форм настройки.
Для вывода элементов управления используйте метод CBPDocument::ShowParameterField, который поддерживает следующие типы полей: многострочный текст, пользователь, да/нет, дата и время, текстовое поле ввода. К каждому полю этот метод добавляет кнопку «. », которая позволяет подставлять значения вида <=. >из переменных, констант и пр. Если же вам необходимо создать свой элемент управления, то кнопку «. » можно добавить с помощью метода CBPHelper::renderControlSelectorButton.
HTML в файле properties_dialog.php должен быть следующего вида:
Редактор полей анкеты реализуем на стороне клиента с помощью JS.
На текущий момент вы можете добавить действие в шаблон и вызвать его настройки.
Теперь добавим метод GetPropertiesDialogValues в класс действия. Как и в первом случае, список аргументов и документирующие комментарии вы можете найти в исходном коде действия.
Задача этого метода — проверить введенные данные на корректность и сохранить их в свойствах действия, либо сообщить об ошибках.
Код ошибки вы можете придумать самостоятельно.
В случае успешного прохождения валидации, мы формируем новый массив значений свойств. Как и в прошлый раз, воспользуемся методом CBPWorkflowTemplateLoader::FindActivityByName, чтобы найти наше действие в дереве шаблона. Однако в этот раз, дерево передано нам по ссылке, чем мы и воспользуемся для сохранения настроек.
Обратите внимание, что список ответственных за задание передается нам из конструктора в виде строки. Перед сохранением мы преобразуем его в массив с помощью метода CBPHelper::UsersStringToArray.
Если ошибок нет, метод должен вернуть true, в этом случае конструктор закроет окно настройки действия.
На этом поведение действия для конструктора можно считать законченным.
Реализация логики шага: задание на звонок
Теперь приступим к реализации логики действия, которая будет выполняться во время работы бизнес-процесса.
Если действие включает постановку задания пользователям, то общий принцип решения этой задачи следующий:
при запуске действия исполняющей средой происходит создание задания (задание — отдельная сущность) и регистрация действия как обработчика события задания;
действие сообщает исполняющей среде, что шаг еще не завершил выполнение, но на текущий момент делать больше нечего (будем ожидать действий пользователя), БП приостанавливает свое выполнение;
обработка отправленной формы задания: валидация данных и отправка события о попытке завершения задания;
обработка события нашим действием: если все необходимые условия выполнены, завершение задания и самого действия (исполняющая среда поймет, что действие завершилось и запустит следующее).
Таким образом, наше действие — само себе обработчик события.
Создание задания БП и подписка на события
Для начала реализуем метод Subscribe. Его задача — создать задание для пользователей и зарегистрировать обработчик события.
Прежде всего запишем в журнал выполнения БП, что его исполнение дошло до задания на звонок. В общем случае, чтобы добавить запись в этот журнал, необходимо использовать службу журналирования бизнес-процессов (Tracking Service), однако для этой задачи есть метод-обертка WriteToTrackingService.
При записи в журнал можно использовать некоторые выражения как при создании шаблона БП.
Создание задания выполняется с помощью службы заданий бизнес-процессов. Заданию потребуются некоторые данные из документа БП, которые, аналогично, можно получить с помощью службы документов. Получить экземпляры служб можно следующим образом:
Параметры задания ($arParameters) вы выбираете самостоятельно. Передайте все, что нужно для отображения формы задания. Если какие-либо данные в форме должны меняться в зависимости от значений свойств действия, передавать их в качестве параметров задания не имеет смысла. Для примера, в качестве параметров не передаются поля анкеты и значения, введенные пользователем — к ним доступ будет осуществлен иначе.
Наконец, нужно сообщить исполняющей среде о регистрации обработчика события.
Первый аргумент — название события. Его можно выбрать произвольно, однако общепринятая практика — использовать название действия в качестве названия события. Второй аргумент — сам обработчик события. Это объект, реализующий интерфейс IBPActivityExternalEventListener, он передается в метод Subscribe.
Полную реализацию метода со всеми проверками на исключительные ситуации вы можете посмотреть в исходном коде действия.
Задача метода Unsubscribe — удалить зарегистрированный обработчик событий и удалить или закрыть задание БП в зависимости от ситуации. В классе действия заведем поля taskId и taskStatus, которые будут содержать ID созданного задания и его конечный статус на случай непредвиденного вызова Unsubscribe (об этом далее).
Наконец, реализуем метод Execute.
Реализуем метод Cancel. Поскольку в методе Unsubscribe уже реализована логика удаления или завершения поставленного ранее задания, вызовем его. Также вернем исполняющей среде состояние действия — “завершено”.
Некоторые несущественные проверки опущены в приведенном выше коде. Полные реализации методов вы можете увидеть в исходном коде действия.
Вывод формы задания исполнителю
Теперь реализуем форму задания — то, что увидит пользователь, которому оно будет поставлено.
Для формирования HTML виджета телефонии в классе действия созданы два метода: getSipPhoneHtml и getContactHtml, возвращающие код виджета для произвольного номера телефона и контакта CRM соответственно.
Рассмотрим метод getSipPhoneHtml. Он использует класс CCrmViewHelper модуля CRM для генерации виджета телефонии.
Метод CCrmViewHelper::PrepareFormMultiField генерирует HTML для множественных полей сущностей CRM (E-mail, телефон, мессенджер. ).
Третий аргумент — префикс атрибута id для создаваемого HTML. Аргумент необязательный, значение по умолчанию — пустая строка. Четвертый аргумент — описания полей (PHONE, EMAIL. ), необязательный, если передать null, метод сам возьмет описания всех доступных полей.
Виджет телефонии выглядит как ссылка на номер телефона. Однако при ее нажатии запускается звонок.
Этого достаточно, если необходимо вывести виджет для произвольного номера телефона. Однако, если в настройках действия указан контакт CRM, мы выведем дополнительную информацию и ссылку на страницу контакта, чтобы сотруднику было удобнее.
Для этого реализуем метод getContactHtml. В нем, помимо телефона, мы выведем фотографию, полное имя и должность. Рассмотрите код этого метода самостоятельно, он достаточно прост. Для генерации виджета телефонии используем ранее созданный метод getSipPhoneHtml. В результате получим следующее:
Окно звонка, которое открывается при нажатии по номеру телефона, можно сворачивать. Поэтому сотрудник, которому поставлено задание, сможет во время разговора заполнять анкету.
Как и в случае с формой настройки действия, HTML-код всей формы вынесем в отдельный файл tasktemplate.php (который нужно создать в каталоге действия). Этот файл, аналогично, представляет собой фрагмент таблицы и должен состоять из полей, описываемых с помощью тега tr.
В приведенном коде опущены несущественные детали. Посмотрите полные реализации методов и шаблонов в исходном коде действия. О ValueStorage — далее.
Обработка формы и событий задания
Осталось лишь реализовать поведение нашего действия при нажатии кнопки «Готово» в форме задания.
Когда пользователь на нее нажимает, запускается метод PostTaskForm. Реализация данного метода похожа на GetPropertiesDialogValues: нужно проверить корректность данных и собрать массив ошибок, затем вернуть true или false в зависимости от успеха. Однако, в случае, если данные успешно прошли проверку, нужно еще отправить событие о попытке завершения задания.
Последнее сделаем следующим образом:
Наконец, осталось реализовать последний метод — OnExternalEvent, который занимается обработкой событий.
В этом методе мы проверим, все ли требования выполнены для завершения задания и, если да, то завершим его и само действие.
Здесь сделаем небольшое отступление. Вы могли заметить в исходном коде действия понятие ValueStorage. Рассмотрим его немного подробнее.
В процессе использования этого действия «в бою» оказалось удобным вызывать его в цикле с разными контактами. Например, сотрудник не смог выяснить всю необходимую информацию по контакту, тогда БП предлагает позвонить другому контакту. Когда, позднее, сотрудник вернется к первому, все введенные значения в поля анкеты, соответствующие данному контакту, должны быть восстановлены. Поэтому значения хранятся отдельно от анкеты и сразу для всех контактов, с которыми было запущено данное действие. ValueStorage — свойство действия, массив, ключами которого являются ID контакта, либо номера телефонов, значения — массивы значений для полей анкеты. Метод getValueStorageName возвращает ключ массива ValueStorage, соответствующий выбранному контакту.
В методе OnExternalEvent мы сохраняем введенные значения в ValueStorage и проверяем, все ли обязательные поля заполнены.
$arEventParameters — аргумент метода OnExternalEvent. Код сохранения значений полей анкеты изучите самостоятельно.
Теперь при запуске БП можно видеть как создается задание и выполнить его.
Тестовый пример
Проверим работу нашего действия на примере небольшого БП в ленте.
Дозвонились или нет — поле анкеты (результат). БП будет ставить задание на звонок с интервалом в 1 час до тех пор, пока ответственный не укажет в анкете, что звонок был успешным.
Действие имеет следующие настройки.
Анкета, в данном случае, соответствует полям документа.
Запустим БП. У нашего действия выполнится метод Execute, затем Subscribe, будет создано задание БП.
Созданное задание мы увидим в ленте.
При нажатии кнопки «Приступить» выполнится метод ShowTaskForm, который выводит анкету.
Нажатие на номер телефона запускает звонок через телефонию Битрикс24.
После того как связь с абонентом будет успешно установлена, в правом верхнем углу появится кнопка «Свернуть». Окно звонка будет минимизировано и появится возможность заполнять анкету прямо во время разговора. В левом нижнем углу экрана вы увидите следующее:
Стрелка справа позволяет развернуть окно звонка, как было изначально.
Сразу после завершения звонка в ленте контакта будет создано сообщение, как при обычном звонке из карточки контакта:
Вернемся к форме задания. Если ввести что-либо, кроме результата, и нажать «Готово», то выполнится метод PostTaskForm, затем OnExternalEvent. Как мы помним, если хотя бы одно обязательное поле не заполнено, задание не завершится. В нашем случае обязательно только одно поле — результат, которое мы специально не заполнили. В результате задание останется в ленте и к нему можно будет снова «Приступить». При этом введенные значения будут сохранены.
Теперь выберем результат «Не дозвонились». Задание стало завершенным, но это временно. Мы видим, что сам БП «Выполняется».
Как только закончится пауза, оно будет поставлено вновь, при этом введенные ранее значения будут восстановлены. При этом поля документа не меняются.
Теперь введем корректные значения и выберем результат «Дозвонились». БП завершился.
Введенная информация сохранилась в поля документа (см. последний шаг БП).
В журнале БП можем видеть результат вызовов WriteToTrackingService.
Для тестирования, мы, конечно, заменили 1 час на одну минуту
Заключение
Модуль БП — мощный инструмент для автоматизации бизнес-процессов как с точки зрения пользователя, так и программиста. Возможность разрабатывать собственные действия позволяет реализовать бизнес-процессы, потенциально, любой сложности.
В данном уроке мы рассмотрели лишь создание «обычного» действия. Также существуют составные, с помощью которых можно реализовать самые разные способы управления «потоками» исполнения БП.
Также возможно подключение собственных сущностей в качестве документов БП, но это уже отдельная тема.
Пишите в комментариях ваш опыт разработки своих действий.
Какие еще статьи по кастомизации коробки Б24 вы бы хотели видеть?