Здравствуйте!
В данной статье приводятся ответы на вопросы с примерами настроек системы 
КонструкторБизнесПроцессов
Предыдущие части:
- БИП Бизнес-Процессы, FAQ: Ответы на вопросы, Часть 01
- БИП Бизнес-Процессы, FAQ: Ответы на вопросы, Часть 02
- БИП Бизнес-Процессы, FAQ: Ответы на вопросы, Часть 03
- БИП Бизнес-Процессы, FAQ: Ответы на вопросы, Часть 04
Надеемся, данная информация окажется для вас полезной и интересной!🙂
Навигация
- FAQ22 – Программный запуск процесса
- FAQ23 – Запуск по расписанию с условием
- FAQ24 – Произвольные оповещения (API, HTTP-запросы и т. п.)
- FAQ25 – Порядок отправки уведомлений
- FAQ26 – Сломанный процесс
- FAQ27 – Настройка процесса по схеме
- FAQ28 – Ошибка в программном коде
:FAQ22 – Программный запуск процесса
Вопрос: Подсистема позволяет запускать бизнес-процессы вручную и автоматически. А можно ли запускать бизнес-процессы программно? Мы хотим иметь возможность запуска настроенных сценариев из нашего кода.
https://rutube.ru/video/617358a596d586c36216484035f6aa76/
Да, действительно.
Бизнес-процессы могут запускаться вручную и автоматически.
Кроме этого, вы можете запускать их программно, используя встроенную функцию _ЗапуститьНовыйПроцесс.
Описание функции доступно во встроенной справке, а также в материалах, доступных на нашем сайте.
Функция может быть использована в любом месте вашего программного кода, по необходимости.
Для примера можем открыть модуль web-сервиса и встроить вызов функции в одну из процедур, используемых в данном модуле.
Вызовем функцию _ЗапуститьНовыйПроцесс, передав в неё параметры запуска и данные об объектах, с которыми связан процесс.
Процесс может быть связан как с одним объектом, так и с несколькими.
В качестве параметров мы должны передать Ссылку на сценарий, по которому должен быть запущено процесс, Дату запуска, Событие запуска. И Комментарий. Два последних параметра можно оставить пустыми.
Функция возвращает структуру, содержащую ссылку на новый бизнес-процесс и текст ошибки, если запуск не удался.
При необходимости данный текст ошибки можно зафиксировать в журнале регистрации.
Таким образом, используя функцию _ЗапуститьНовыйПроцесс, мы можем в любое время программно запустить бизнес-процесс по любому сценарию, в любом месте вашего программного кода.
:FAQ23 – Запуск по расписанию с условием
Вопрос: Нам нужно, чтобы система по расписанию проверяла задолженность клиентов. И по тем клиентам, у которых есть долг перед нами, для менеджеров, ответственных за работу с данными клиентами, формировались задачи по контролю задолженности. Можно ли настроить такой сценарий?
https://rutube.ru/video/3137dc75fa41768cce246f1eddc92b57/
Да. Можно.
Создадим новый сценарий.
Пусть по данному сценарию для исполнителя будет формироваться одна задача по работе с задолженностью.
Укажем, что данный процесс связан со справочником Партнеры. Этот справочник содержит сведения о наших клиентах.
В качестве исполнителя задачи укажем основного менеджера, указанного в партнере.
Теперь у нас есть сценарий, который при запуске будет связан с клиентом.
По данному сценарию, для основного менеджера клиента формируется задача по работе с задолженностью.
Этот сценарий мы можем запустить вручную.
Теперь настроим автоматический запуск данного сценария.
Процессы по сценарию будет запускаться один раз в день. Точное время запуска указывать не будем.
Теперь нам нужно получить данные о задолженности и по каждому клиенту с долгом запустить отдельный бизнес-процесс.
Для этого, в условии автоматического запуска добавим шаблон кода.
В данном коде мы должны указать запрос к данным о задолженности клиентов.
Для демонстрации примера, данные мы можем получить из одного из регистров основной конфигурации.
В массив _ВыходныеДанные мы поместим всех клиентов, у которых есть задолженность.
По каждому клиенту из массива выходных данных, мы запустим отдельный процесс. За это отвечает переменная _РазделятьПоПроцессам.
Значение переменной _Результат определяет нужно ли вообще запускать процессы или нет. Если массив выходных данных пуст, это означает, что клиентов с задолженностью нет. А значит, процессы запускать не требуется.
Расписание и Условие запуска процессов по сценарию настроены.
Процессы будут запускаться только, если есть клиенты с задолженностью.
Активируем сценарий.
По расписанию, ближайшее время запуска сегодня – это текущий момент, потому что мы не указали точное время запуска.
Система по расписанию проверила наличие клиентов с задолженностью и сформировала по каждому из них отдельный процесс.
В рамках каждого процесса, для основного менеджера поставлена задача для работы с задолженностью по каждому клиенту.
Для менеджера Королева поставлена задача по работе с задолженностью клиента Ассоль, потому что этот менеджер указан в карточке клиента, как основной.
Таким образом, мы настроили сценарий, который по расписанию проверяет расчеты с клиентами и формирует задачи для менеджеров тех клиентов, у которых есть задолженность.
:FAQ24 – Произвольные оповещения (API, HTTP-запросы и т. п.)
Вопрос: Возможно ли создать дополнительный вариант уведомления? Например, который можно отправить API-запросом, или передать в нашу внутреннюю систему обмена сообщениями. Уведомлений в систему взаимодействия, по электронной почте и в Telegram недостаточно для всех наших задач.
https://rutube.ru/video/adf38cf454930aa8073e0ca01b4f72b3/
Да.
Можно настраивать произвольные уведомления, используя алгоритмы.
Возьмем для примера сценарий с 1 задачей.
Настроим для этой задачи отправку произвольного уведомления.
Для этого, в типе оповещения выберем Прочее.
Текст сообщения можно не указывать. В этом случае, текст будет получен из описания задачи.
Теперь настроим алгоритм отправки уведомления. Готового алгоритма в списке у нас нет, поэтому создадим новый.
Для примера, запишем данные текущего оповещения в текстовый файл.
Сейчас мы не ставим целью показать написание какого-то реального запроса в какую-то внешнюю систему, получения от нее ответа и его обработки.
Непосредственно к подсистеме это отношения не имеет.
Здесь мы показываем, что в рамках алгоритма нам доступен весь функционал языка 1С и в рамках алгоритмов мы можем реализовать любую логику, в том числе и для формирования произвольных уведомлений и отправки их куда угодно.
А запись в файл – это самая простая демонстрация работы алгоритма.
Если в результате выполнения кода значение переменной _Результат = Истина, система считает это успешной отправкой.
В случае, если сообщение не отправлено, мы можем присвоить этой переменной значение, отражающее причину ошибки.
Через переменные ПолучательОповещения, ТекстОповещения и ТекстОповещенияHTML доступны значимые данные текущего уведомления.
В данном коде мы допустили ошибку. Не будем её сейчас исправлять, а посмотрим, что произойдет.
Запишем алгоритм без проверки и выберем его в настройках оповещений.
Теперь запустим процесс по нашему сценарию.
На карте процесса видим, что для исполнителя сформировалась задача.
Значит, должно сформироваться наше произвольное уведомление.
Т.к. ранее мы не настроили какой-то специальный текст для уведомления, текстом будет являться описание задачи из настроек сценария.
Сообщение не пришло. Перейдем в список сообщений, чтобы разобраться в причине.
В списке сообщений мы видим, что наше произвольное уведомление не отправилось. И видим причину. Ошибка в коде.
Система будет пытаться повторно отправить это сообщение, но, пока мы не исправим ошибку, смысла в этом нет.
Исправим ошибку и вручную запустим отправку неотправленных уведомлений.
Теперь наше уведомление обработано и "отправлено"
"Отправлено" здесь в кавычках, потому что алгоритм произвольного уведомления всего навсего сформировал текстовый файл, содержащий сведения о нашей задаче.
Здесь мы видим получателя уведомления, текст уведомления и текст уведомления в формате html.
Таким образом, мы настроили систему так, чтобы вместо отправки уведомлений в систему взаимодействия, по электронной почте или в Telegram, она выполнила произвольный алгоритм в рамках настроек оповещений.
Это даёт нам возможность, используя функционал подсистемы, реализовать любые варианты уведомлений, контролируя их отправку.
:FAQ25 – Порядок отправки уведомлений
Вопрос: Мы настроили автоматическое оповещение по бизнес-процессу. Исполнителю задачи должно приходить уведомление на почту. Но этого не происходит. В чем может быть дело?
https://rutube.ru/video/e975ae2ad07db913699aef6ab7ddaaf0/
Давайте посмотрим.
Для примера возьмем сценарий, состоящий из двух задач.
Выполним настройку оповещений.
Для 1-ой задачи при запуске шага исполнитель получит письмо. Укажем тему и текст письма.
По 2-ой задаче, добавим оповещение для наблюдателя. Это тоже будет электронное письмо при запуске задачи.
Оповещения настроены.
Следует обратить внимание, что оповещение можно отключить. Для этого, в списке настроек, следует дважды щелкнуть по первой ячейке. Оповещение станет неактивным и отправляться не будет.
Таким образом можно без удаления настройки из списка временно отключать оповещения.
Сохраним настройки и запустим по сценарию новый процесс.
На карте процесса видим, что запустилось две задачи.
В соответствии с настройками оповещений по каждой задаче должны быть отправлены письма.
Теперь давайте разберемся с тем, как работает автоматическая отправка уведомлений.
Во-первых, все события, связанные с процессом и его шагами фиксируются в отдельном регистре событий.
В нашем случае произошло три события: запуск процесса, запуск первой задачи и запуск второй задачи.
Все события обрабатываются автоматически. Но для этого, в соответствии с инструкцией по подготовке подсистемы к использованию, должно быть запущено регламентное задание. Задание должно выполняться под пользователем, обладающим полными правами на подсистему. В противном случае, события могут или не обрабатываться вообще, или обрабатываться некорректно.
Расписание, то есть периодичность запуска задания должна быть настроена такой, чтобы автоматическая обработка событий и отправка уведомлений происходили с достаточной для комфортной работы, частотой.
Теперь мы убедились, что подсистема подготовлена к работе в соответствии с инструкцией. Ничего не должно препятствовать штатной работе.
Что делает система при обработке событий?
Во-первых, удаляет из списка все незначимые события. То есть события, для которых не настроены уведомления.
В нашем случае, таким являлось событие запуска процесса.
Во-вторых, по всем значимым событиям выполняются проверки.
В-третьих, отправляются оповещения, если ошибок не обнаружено. И записываются ошибки, если они обнаружены.
В нашем случае, одно событие обработалось, а по второму возникла ошибка.
Если событие обработалось, значит должно было быть сформировано сообщение.
Все сообщения хранятся в отдельном списке. Откроем его.
Видим, что было успешно отправлено одно сообщение.
Исполнитель получил письмо.
А что же случилось со второй задачей?
При обработке события возникла ошибка.
Система сообщила нам, что получатель оповещения не указан.
В настройках мы указали, что уведомление должен получить наблюдатель по задаче.
Но наблюдателя мы не указали. Ни в настройках сценария, ни в самой задаче.
Поэтому и возникла ошибка. Система просто не знает кому следует отправить письмо.
Давайте откроем задачу и вручную добавим наблюдателя.
Наблюдатель добавлен. Теперь система знает, кому следует отправить оповещение.
Событие успешно обработано.
Теперь откроем список сообщений и убедимся, что письмо отправлено.
Письмо не отправилось. Откроем карточку сообщения и посмотрим почему.
В тексте ошибки видим, что у получателя не указан адрес электронной почты.
Система знает кому отправить письмо, но не знает на какой адрес.
Откроем карточку пользователя и укажем e-mail.
Теперь систему всё устраивает и она успешно отправила уведомление.
И пользователь получил своё письмо.
Таким образом, система позволяет настраивать и отправлять автоматические уведомления по различным событиям бизнес-процессов.
Для корректной работы обязательно требуется подключать и подготавливать подсистему к работе в точном соответствии с инструкциями, входящими в комплект поставки. В этом случае система будет работать стабильно и предсказуемо.
Кроме этого при настройке оповещений следует стремиться к тому, чтобы у системы были все необходимые данные о получателях, для успешной отправки.
А на случай возможных ошибок и несоответствий, система сохраняет всю историю обработки событий и отправки сообщений, для того чтобы можно было легко отследить причины возможных коллизий.
:FAQ26 – Сломанный процесс
Вопрос: Мы внесли изменения в заблокированный сценарий, по которому был запущен процесс. После этого процесс завис и перестал работать. Что нам делать?
https://rutube.ru/video/38e450fe2282c34b1323f73e8886f2a0/
Давайте посмотрим.
Сначала создадим сценарий, на котором будем пробовать "сломать" рабочий процесс.
Сценарий будет состоять из трех последовательных задач.
Запишем сценарий и запустим по нему новый процесс.
Откроем карту процесса. На ней мы видим, что процесс запустился и была сформирована 1-ая задача.
Для завершения процесса требуется последовательно выполнить все 3 задачи.
Но сейчас мы решили, что 2-ую задачу выполнять не будем, а внесем изменения в схему процесса.
Сценарий заблокирован, потому что по нему есть запущенный процесс.
Система предупреждает о возможных сбоях в работе уже запущенных процессов, но мы это проигнорируем и разблокируем его.
Мы решили, что нам надо поменять порядок 1-ой и 2-ой задач. Сначала должно формироваться Действие №2, а за ним – Действие №1. И уже после этого – Действие №3.
Запишем измененный сценарий и вернемся на карту нашего процесса.
Уже по схеме видим, что процесс выглядит неадекватно. Задача №2 еще не выполнена, а следующая за ней Задача №1, уже завершена.
Теперь давайте выполним Задачу №2.
Задача выполнена, но ничего не происходит.
Процесс стоит на месте и не двигается дальше.
Всё. Мы его сломали.
Что мы можем сделать в этой ситуации?
Во-первых, при разблокировке сценария система нас предупреждала о возможных сбоях в активных процессах при нарушении порядка шагов.
Мы это проигнорировали и получили то что видим перед глазами.
Поэтому, первое, что мы можем сделать – это удалить данный процесс и запустить новый.
Новый процесс будет работать в соответствии со сценарием.
Последовательное выполнение задач приведет к завершению процесса.
Процесс завершен. Но это уже не тот же самый процесс, что был запущен в первый раз.
Давайте вернемся к нашему сломанному процессу и попробуем запустить его по-другому.
У нас есть возможность перезапустить текущий зависший процесс.
При этом, все выполненные шаги удалятся. Процесс начнется с самого начала. И будет работать в соответствии со сценарием.
Последовательное выполнение задач приведет к завершению процесса.
Процесс завершится после выполнения 3-ей задачи. Это тот же самый процесс, что был запущен в первый раз, но запущенный повторно.
Вернемся к первоначальной версии зависшего сценария и попробуем оживить его ещё как-нибудь по-другому.
Ещё один способ, это отмена задач.
При отмене задачи, процесс не перезапускается полностью, а повторно начинается с отмененной задачи. Все шаги, которые были пройдены после отмененной задачи, удаляются.
Это удобно в тех случаях, когда требуется откатиться в процессе на несколько шагов назад, не перезапуская весь процесс.
Но в нашем случае придется отменить обе выполненные задачи, т.к. порядок нарушен с самого начала процесса.
После отмены, система сформировала новую задачу для выполнения.
Теперь процесс пойдет по сценарию.
Процесс завершен. Это тот же самый процесс, что был запущен в первый раз, но отдельные шаги были отменены и запущены повторно.
Вернемся к первоначальной версии зависшего процесса.
Есть еще один способ.
Он используется как принудительный, ручной запуск остановленного процесса.
В контекстном меню истории процесса есть специальная кнопка обработки и запуска текущего шага.
Эта кнопка определяет последний завершенный шаг процесса и повторно обрабатывает его, пытаясь запустить следующие шаги.
Последний шаг определяется, как шаг с максимальный порядковым номером в списке шагов.
Обработка шага завершилась, но ничего не произошло. Процесс остался на месте.
Для поиска причины включим настройку трекера. Вместо описаний шагов на карте будут отображаться их порядковые номера.
Здесь мы сразу и видим, что порядок шагов нарушен: 0-2-1, вместо 0-1-2.
А при ручном запуске система пытается повторно обработать 2-ой шаг, но после него шаг уже выполнен. Поэтому, ничего не происходит.
Мы своими руками сломали процесс, изменив логику сценария. Теперь можем попробовать своими руками его восстановить.
Для этого нужно восстановить порядок шагов.
Укажем новый порядок, в соответствии с действующей схемой сценария.
Начнем по порядку с 1-ой задачи. Она должна стать 2-ой.
Теперь порядок восстановлен. Шаги следует в правильном порядке: 0-1-2.
Теперь можно снова попробовать завести "заглохший" сценарий.
Процесс запустился и мы можем продолжить работать с ним.
Теперь его ход соответствует новым настройкам сценария.
Выполнение 3-ей задачи привело к завершению процесса.
Таким образом, система позволяет изменять настройки действующих процессов "на горячую", без остановки процесса.
В случае незначительных с технической точки зрения изменений, например описания шагов, сроков выполнения, адресации и тому подобное, работа процесса не нарушится.
Если же изменения касаются логики протекания процесса, схемы сценария, то здесь в каждом индивидуальном случае нужно подходить аккуратно. И при возможности не вносить изменения, если имеются активные процессы.
Процессы рекомендуется сначала завершить. Или скопировать сценарий и уже в копии делать все изменения.
Но если других вариантов не остается и изменение сценария привело к нарушению работы действующего процесса, то и здесь система предлагает ряд способов, которые позволят реанимировать замерший процесс.
:FAQ27 – Настройка процесса по схеме
Вопрос: Нам разработали схему, описывающую протекающий у нас процесс. Можно ли настроить данный процесс в 1С с помощью системы КонструкторБизнесПроцессов©?
https://rutube.ru/video/99290078fba8041dd238a54e8b1815ca/
См. КонструкторБизнесПроцессов. Настройка бизнес-процесса по схеме
:FAQ28 – Ошибка в программном коде
Вопрос: Что произойдет, если в программном коде сценария есть ошибка?
https://rutube.ru/video/dc58091d6a8cb8f651854ceba7d605b3/
Если в сценарии есть программный код, содержащий ошибку, код, который приводит к ошибке компиляции и выполнения, то такая ситуация является нештатной.
Программа не может работать корректно, если в ней используется нерабочий программный код.
Поэтому в общем случае, программный код, работающий без ошибок – это основа функционирования системы.
Если ваш код не работает или работает неправильно, процессы в которых он используется, могут работать некорректно.
Давайте для примера возьмем сценарий с шагами-обработками.
В 3 обработках сценария выполняется программный код.
На формах настроек система предупреждает нас о том, что код должен быть рабочим.
Запустим по данному сценарию новый процесс.
Откроем его карту и посмотрим, как протекает процесс.
После 1-го шага сценария выполнились три обработки.
И процесс перешел на следующий шаг, по которому была создана задача.
Каждая из обработок создала текстовый документ, в соответствии с их программным кодом.
После выполнения задачи и проверки условия, процесс завершится.
Данный процесс работает штатно.
Теперь давайте внесем в программный код одной из обработок какую-нибудь ошибку.
Разделим что-нибудь на ноль.
При проверке программного кода система предупреждает, что наш код нерабочий.
Проигнорируем.
Запишем сценарий и запустим по нему новый процесс.
Откроем его карту и посмотрим, что произошло.
Шаг, в котором мы добавили нерабочий программный код, светится красным цветом. Это означает, что система попыталась выполнить код на данном шаге, но не смогла этого сделать.
В комментарии к невыполненному шагу мы можем ознакомиться с текстом ошибки.
Остальные шаги по процессу успешно завершены.
Теперь система отложила повторное выполнение этого шага на 5 минут.
Через 5 минут система снова попытается выполнить программный код.
Она будет делать это до тех пор, пока код не сможет быть успешно выполнен, чтобы процесс смог перейти на следующий шаг.
Давайте откроем сценарий, исправим нашу ошибку и сохраним изменения.
Не будем ждать пока система сама повторно обработает данный шаг, а запустим его принудительно.
Теперь программный код выполнен успешно и процесс вернулся в штатный режим работы.
По индексации шагов видим, что система 3 раза пыталась выполнить данный шаг.
На данном примере мы увидели, что для корректной работы процессов требуется программный код, работающий без ошибок.
Но даже если код написан с ошибками, система попытается сохранить общую работоспособность всего процесса.
Процесс будет оставаться на одном месте, пока ошибка не будет исправлена.
Или пока программный код не перестанет намеренно вызывать состояние ошибки.
Данный случай возможен, если мы намеренно вызываем исключение при выполнении программного кода.
В ряде случаев это может использоваться, чтобы уменьшить общее количество шагов на схеме или когда выполнение программного кода не привело к требуемым результатам. Например, при неудачных попытках подключения к внешним системам.
Сейчас мы искусственно вызвали ошибку при выполнении кода для шага проверки условия.
Теперь система будет снова пытаться выполнить данный шаг до тех пор, пока программный код не будет вызывать исключение.
Или пока код не будет изменен.
Откроем настройки шага-условия и уберем искусственный вызов ошибки.
Теперь системе ничего не мешает выполнять процесс в штатном режиме.
Подведем итог.
Используемый в процессах программный код должен быть рабочим.
В нештатных ситуациях система стремится сохранить общую работоспособность процесса.
Тем не менее, нерабочий программный код может привести к некорректному поведению системы.
Спасибо!
Вступайте в нашу телеграмм-группу Инфостарт
