Добрый день!

 

Есть родительский процесс в рамках которого "Менеджер" добавляет в обьект "Заявка" новую стадию заявки (связанный обьект "Стадия"), согласно которой Заявка попадает в очередь обработки Оператором. Дальше по итогам взятия Оператором из очереди данной заявки и ее проработки - в заявку добавляется новая стадия - и вот в этот момент необходимо отправить емейл уведомление "Менеджеру" о том, что заявка проработана.

Первую часть с менеджером реализовал в виде родительского процесса который переходит в подпроцесс:

Подпроцесс в свою очередь по сигналу добавления новой стадии "запускает" отправку емейл уведомления менеджеру:

Но наткнулся на 2 проблемы:

1. При использовании стартового сигнала в подпроцессе - сам подпроцесс не считывает параметр "Менеджер" из родительского процесса, как и любые другие параметры (пробовал менять стартовый параметр "Сигнал" на "Простое" - параметры передаются успешно). 

2. Как избежать запуска "Подпроцесса" для других заявок у которых новая стадия добавляется не с родительского процесса, а другими механизмами? (во избежание загрузки системы лишними процессами)

Нравится

5 комментариев
Лучший ответ

Александр, Вы смешиваете два механизма: безусловный запуск подпроцесса из основного процесса и запуск процесса по сигналу на каком-то событии объекта.

 

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

 

По общему механизму со стадиями, который Вы создаёте, не вполне понял. Если после добавления стадии нужно проверить, создана ли она по процессу, можно создать в объекте стадии новое поле и ставить там пометку. Если Вы имеете в виду две разных стадии, по процессу создалась вторая, а уведомление отправить автору первой, то в процессе на событии создания второй стадии можно по связям с заявкой вычислить первую, её автора-менеджера и отправить уведомление ему. Если по типу стадии нельзя однозначно сказать, какая идёт за какой, можно добавить в объект справочное поле со ссылкой на предыдущую.

Добрый вечер.

 

Если рассматривать Вашу реализацию задачи, то, во-первых, подпроцесс из родительского процесса можно не вызывать, он вызовется автоматически при наступлении события, указанного в сигнале. Во-вторых, параметр "Менеджер" можно вычитывать из записи в таблице 'Стадии' (это будет тот, кто создал эту стадию) и потом ему отправлять уведомление. Избежать запуска подпроцесса при добавлении новой стадии другими способами можно, если добавить в таблицу стадий некоторое поле-признак, которое будет указывать на добавление стадии по процессу, и перед отправкой письма проверять установлено ли значение для данного параметра. А в родительском процессе устанавливать значение этого параметра при создании стадии.

 

Правильнее, конечно, добавить вызов подпроцесса (но не по сигналу) из родительского процесса и в него передать и Id созданной стадии, и менеджера, которому нужно отправить письмо, но вызывать подпроцесс только тогда, когда новая стадия уже создана.

 

А в данном примере можно и не использовать подпроцесс, а добавить отправку e-mail менеджеру прямо в родительском процессе, но опять таки только тогда, когда новая стадия уже создана, то есть у Вас должен быть переход на отправку письма по условию.

Алла Савельева пишет:

Правильнее, конечно, добавить вызов подпроцесса (но не по сигналу) из родительского процесса и в него передать и Id созданной стадии, и менеджера, которому нужно отправить письмо, но вызывать подпроцесс только тогда, когда новая стадия уже создана.

А какой элемент в таком случае подойдет для запуска? 

 

 

Алла Савельева пишет:

А в данном примере можно и не использовать подпроцесс, а добавить отправку e-mail менеджеру прямо в родительском процессе, но опять таки только тогда, когда новая стадия уже создана, то есть у Вас должен быть переход на отправку письма по условию.

Тут же опять вопрос: а как понять что новая (последующая, другая) стадия уже создалась, если текущий экземпляр процесса работает в рамках созданной им одной записи, а все последующие стадии создаются вне процесса и прямо в процессе не участвуют?

Алла Савельева пишет: Во-вторых, параметр "Менеджер" можно вычитывать из записи в таблице 'Стадии' (это будет тот, кто создал эту стадию) и потом ему отправлять уведомление.

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

 

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

Признак "добавление стадии по процессу" можно добавить в запись созданную по процессу, но нам все равно нужно сначала как то дождаться создания последующей стадии и только потом отправить "Менеджеру" уведомление.

 

Александр, Вы смешиваете два механизма: безусловный запуск подпроцесса из основного процесса и запуск процесса по сигналу на каком-то событии объекта.

 

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

 

По общему механизму со стадиями, который Вы создаёте, не вполне понял. Если после добавления стадии нужно проверить, создана ли она по процессу, можно создать в объекте стадии новое поле и ставить там пометку. Если Вы имеете в виду две разных стадии, по процессу создалась вторая, а уведомление отправить автору первой, то в процессе на событии создания второй стадии можно по связям с заявкой вычислить первую, её автора-менеджера и отправить уведомление ему. Если по типу стадии нельзя однозначно сказать, какая идёт за какой, можно добавить в объект справочное поле со ссылкой на предыдущую.

Зверев Александр,

Александр, спасибо за советы, сделал подобным образом, только на стадию добавил не пометку, а статус. И дальше уже в рамках одного процесса по элементу "Обработать сигнал" отслеживаю изменение статуса в ранее созданной по процессу стадии, а после этого отправляю email создателю стадии.

А за то, что "Стартовый сигнал" не будет в под.процессе не будет принимать параметр из родительского процесса уже начал догадываться, но явно в академии ничего не нашел.

 

Алла Савельева,

Вам тоже спасибо за совет, направление по признаку учел.

Показать все комментарии

Коллеги, привет! 

Помогите, пожалуйста, понять. 

Установил темплейт - https://marketplace.terrasoft.ru/template/podprocess-polucheniya-emailov-polzovateley-iz-roli

Перекомпилировал базу, в списке процессов при выборе в подпроцессе не появился. 

Что делаю неверно, куда посмотреть? 

Нравится

2 комментария

Сделайте так чтобы ваш пакет зависел от пакета, где находится этот процесс. После этого процесс появится в списке.

Миннекаев Айдар, не помогает, есть ли ещё варианты? 

Показать все комментарии

Доброго времени суток!

Необходимо запустить N подпроцессов из основного процесса и каким-то образом ожидать выполнения всех подпроцессов.

Буду благодарен любым идеям.

UPD-1. Изначально не известно сколько будет подпроцессов, поэтому такого рода схема не подойдет

Нравится

12 комментариев

Здравствуйте!

что то вроде такого -http://prntscr.com/ocm1ol

Вот наглядный пример, создал 3 БП, в них добавил разные таймеры и посмотрим как идет обработка в главном БП
http://prntscr.com/ocmaqq - Главный
http://prntscr.com/ocmaxg - 1 мин задержки
http://prntscr.com/ocmb6t - 2 мин задержки
http://prntscr.com/ocmbg8 - 3 мин задержки

Запускаем основной и смотрим диаграму:
http://prntscr.com/ocmc05
http://prntscr.com/ocmc9u
http://prntscr.com/ocmck4 - завершился (диаграма выполнения основного без изменения - http://prntscr.com/ocmcso)
http://prntscr.com/ocmda0

Нигрескул Алексей,

Обновил описание вопроса

Если процессы создаёте кодом, то можно их количество записать в определённое поле, а в конце дочернего процесса отнимать от значения единицу. На изменение поля на ноль в основном процессе повесить сигнал.

Зверев Александр,

А где создавать это поле? И как сделать обработчик сигнала?

В каком-то объекте, подходящем по логике, с которым по смыслу связаны эти процессы. Обработчик — сигнал на изменение поля в объекте.

Зверев Александр,

То есть нужно в дочернем процессе сначала считать эту колонку селектом затем сделать update? НО если эти дочерние процессы завершаться секунда в секунду, то подсчет не будет верным. Как быть тогда?

Уменьшать и считывать старое значение можно в том же запросе.

Зверев Александр,

Гарантируется ли при использовании этого запроса правильный подсчет одновременно завершающихся подпроцессов?

Этот способ не является стандартным. Как такое делать штатно, описал выше для фиксированного числа процессов Алексей. Тут же все гарантии будет давать разработчик, то есть Вы. По идее, если всё в одном SQL-запросе, то мешать не будет.

Зверев Александр,

Зверев Александр пишет:Уменьшать и считывать старое значение можно в том же запросе.

Через такой запрос не генерится сигнал 

Действительно, в таком случае используйте не Update, а ESQ. Синхронизацию в этом случае нужно предусмотреть самостоятельно. Либо же менять при помощи Update, а в следующем шаге менять другое поле по ESQ или посылать сигнал иным образом.

Показать все комментарии

БП продажи
Задача: Создать N-счетов, для каждого созданного счета создать задачу, переводить продажу в состояние "Завершена" только после завершения всех задач, если хотя бы одна задача с отрицательным результатом - отменять продажу.

Решил обернуть это все в подпроцесс, которому на вход передаю количество счетов(вводится пользователем), а результат будет храниться в параметре подпроцесса. В элементе "script" создаю нужное кол-во сущностей. Вопрос - как теперь заставить БП ожидать все созданные задачи?

Нравится

4 комментария

Вам нужен элемент "Слияние" (треугольник) в редакторе БП.

Я бы точно мог его использовать, если бы количество задач было заранее известной константой. я бы нарисовал, допустим, 10 задач и направил бы это в слияние - отлично. Но я не знаю сколько будет задач, так как это указывает пользователь для каждого договора в процессе выполнения БП

Добрый день!

Занимался когда-то похожей задачей.
нашел сервисы процесса (во вложении).
Суть в том, чтобы проверять количество завершенных и не завершенных подпроцессов.
services.rar
сервисы для версии 3.3.1.148 (MSSQL)

Спасибо за ответы, уже натолкнули коллеги на решение - В элементе "Скрипт" создать в цикле все задачи и перейти в следующий элемент "Скрипт", где запросом проверять статус задач и по результатам выставлять текущему WorkflowItem(наш элемент "Скрипт") параметр IsCompleted в true или false. Запускать этот элемент каждый раз когда изменяем задачу данного БП.

Показать все комментарии

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

Тестовый пример диаграмм процесса и подпроцесса дан в приложенных файлах. Идея не моя она была дана в топике http://community.terrasoft.ua/forum/topic/3566#comment-17027. В том же топике она и была разобрана, но так как обсуждение длинное и по большей части связанное с моей неопытностью в разаработке, то здесь приведу краткий алгоритм реализации и грабли на которые наступал я.
 Для передачи результатов завершения подпроцесса была выбрана модель которую предложила Екатерина Мельникова: для передачи информации о результате завершения подпроцесса необходимо создать связанные параметры.
1.Для этого в палитре свойств диаграммы подпроцесса TestSub открываем свойство «Объект» и параметр ResultIDSubProcess с типом «Строка».(Рекомендую кроме «Имени» и типа ничего не трогать)
2. В палитре свойств диаграммы основного процесса Test открываем свойство «Объект» и параметр ResultFromProcess с типом «Строка».
3.Нажимаем кнопку связи объектов и выбрав в нижнем левом окне подпроцесс — задаем свойства его параметра ResultIDSubProcess — назаначив ему тип Исходящий(т.е. Передающий свое значение) и связав с параметром диаграммы ResultFromProcess.
 Для присваивания значения параметру подпроцесса, мы используем способ предложенный В.Андрусиком: создание в конце каждой ветки объекта типа «Скрипт», где мы присваиваем значение парметру подпроцесса ResultIDSubProcess(далее значение в процесс предается по связям назначенным нами в интерфейсе «Связи объектов»). Я использовал просто строковые значения «Yes» и «No». 
Функции обработки вызываются на событии «OnExecute» объекта типа «Скрипт» в подпроцессе. Для присваивания значений в скрипте подпроцесса я использовал два варианта(это совершенно необязательно, просто эксперементировал). При использовании функций WFGetParamValue(Diagram,NameParam) -получить значение параметра по имени или WFSetParamValue(Diagram,NameParam,Type) — присвоить значение параметра по имени, обязательно добавлять в раздел «Использовать скрипты» в скрипте диаграммы скрипт «scr_WorkflowUtils».
 В основном процессе для анализа значений параметра процесса ResultFromProcess добавляем объект «Выбор» и пишем скрипт для извлечения значения параметра и его анализа.
P.S. В скриптах процесса и подпроцесса есть еще скрипты, в которых тоже передаются значения параметров, для заполнения значений Контрагента и Контакта в карточке Задачи, по технологии предложенной в топике: http://community.terrasoft.ua/forum/topic/927. 

Нравится

Поделиться

1 комментарий

Прикрепил файлы ;-). Версия TS CRM - 3.3.0.49 под MS SQL 2005.

Показать все комментарии