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

После обработки сигнала, в бизнес-процессах стоит блок чтение данных из таблицы, в которую добавилась запись. И периодически возникают ситуации, когда чтение данных работает в одном процессе, а в других - чтение данных возвращает, что нет такой записи.

Хотя id добавляемой записи передается во все бизнес-процессы по сигналу.

Я пробовала убрать блок чтение записи, и после срабатывания сигнала, у меня вызывался скрипт, где я делала селект по id добавляемой записи, и селект возвращается пустой.

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

Нравится

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

Ну, здесь очевидным кажется свести все процессы в один, а дальше запускать существующие процессы как подпроцессы.

Сидоров Александр Валерьевич, спасибо за ответ. Дело в том, что эти бизнес-процессы очень объемные и не совпадают по смыслу. Хотелось бы их разграничить

Татьяна,

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

Александр,

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

Татьяна,

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

Александр,

Спасибо большое за ответ, будем думать

Татьяна, возможно даже лучше будет обратится не к CSM, а сразу в техническую поддержку Terrasoft.

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

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

 

Возникла необычная проблема, необычность заключается в том, что у нас не работают на одной из платформ таймеры. Во время тестирования бизнес-процесса, который запускается с периодичностью в пару дней на тестовой платформе, все прекрасно работало.

 

Однако когда мы перешли на рабочую платформу, таймеры резко перестали срабатывать, точнее в журнале событие есть, схема точно рабочая, но никаких действий вовсе нет.

 

Может где-то есть настройки работы таймера, чтобы проверить, все ли корректно работает и сравнить с тестовой платформой? Заранее благодарю!

Нравится

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

Я бы посмотрел в сторону Quartz, возможно с ним какие-то проблемы https://academy.terrasoft.ru/docs/developer/elements_and_components/qua…

 

Для начала увеличить значение в веб конфигах на более высокое (по умолчанию там 5), затем перезапустить iis.

<add key="quartz.threadPool.threadCount" value="5" />

Добрый день, коллеги.

Есть вероятность что таймеры попадают на то время когда пул приложения спит, тут может помочь настройка согласно публикации https://community.terrasoft.ru/articles/bespereboynaya-rabota-zadaniy-q…

 

Но в целом что стоит сравнить так это внешний Web.config с обеих сред. Возможно достаточно будет их заполнить одинаково, или если у вас на прод среде в разы больше задач для Quartz может понадобится настройка согласно статье https://academy.terrasoft.ru/docs/7-17/developer/elements_and_component…

 

Если это не поможет, было бы неплохо уточнить формулировку "журнале событие есть, схема точно рабочая, но никаких действий вовсе нет" не совсем понятно что именно тут происходит, а что нет.

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

Добрый день!

 

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

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

Изображение удалено.

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

Изображение удалено.

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

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

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

Нравится

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

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

 

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

 

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

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

 

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

 

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

 

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

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

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

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

 

 

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

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

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

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

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

 

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

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

 

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

 

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

 

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

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

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

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

 

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

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

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

Дать возможность в сигнале об изменении записи понять, какие именно поля изменились и, в идеале, передавать старые значения полей.

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

Здравствуйте, Алексей!

 

Передали данное пожелание команде разработки.

 

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

 

Ещё ранее была похожая идея о генерации сообщений и сигналов.

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

Есть БП, реагирующий на изменение записи, на несколько полей.

Можно ли внутри БП понять, какое именно поле или поля изменились, т.к. скорее всего будут меняться не все поля???

Нравится

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

Можно много отдельных сигналов, каждый настроен под своё поле одного и того же объекта. Но нужно корректно обработать, если при одном сохранении поменяли несколько таких полей, чтобы отработала вся нужная логика, но без лишних повторов.

Инструментами БП, если не ошибаюсь, такое нельзя определить.

как альтернатива можно несколько сигналов стартовых добавить, каждый будет отлавливать свое событие.

Вадим Косарев,

а отловится, если изменилось несколько полей, а не одно?

Нужно делать процесс в объекте на сигнал Saving, где можно сравнивать старые и новые значения. И уже оттуда запускать какую-то логику

Такое можно определить во встроенном БП на событии Saving, там можно прочитать старое (GetTypedOldColumnValue) и новое (GetTypedColumnValue) значение полей до момента записи в базу. А затем полученные значения учитывать на Saved уже после сохранения. Подробнее см. в теме.

Всем спасибо за ответы! Уточню, мне не нужны старые значения, мне просто нужно понять какие поля изменились. Или это же только Saving?

 

Можно много отдельных сигналов, каждый настроен под своё поле одного и того же объекта. Но нужно корректно обработать, если при одном сохранении поменяли несколько таких полей, чтобы отработала вся нужная логика, но без лишних повторов.

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

Алексей-Карягин,

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

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

В бизнес-процессах среди "начальных событий" наиболее часто используемым является "сигнал от объекта", из трех вариантов действий на которые должна осуществляться реакция: с вариантами "Создания" и "Удаления" - функционал фильтрации события на старте а также набор "входных" параметров (основываясь на практике использования) - достаточен, в силу специфики юзкейсов. А вот с действием "Изменение записи", по моему мнению, функционала немного не хватает для построения более линейной и "красивой логики", а так же покрытия большого количества типовых юзкейсов, в нем сильно не хватает функционала связанного с "ИЗМЕНЯЕМЫМ значением" 1) Было бы очень круто, среди условий старта по сигналу иметь не только блок проверки "После изменения запись должна соответствовать условиям" Но и блок проверки "Перед изменением запись должна соответствовать следующим условиям" Что позволило бы развивать юзкейсы связанные с изменением конкретных значений на конкретные значения (довольно часто вписывающиеся в требования бизнес-логики). А так же позволило бы избежать проблем связанных с реализацией кейса "при первичном заполнении ранее не заполненного поля", которые сплошь и рядом встречаются в бизнес-требованиях, и решать задачу приходится через введение дополнительных полей-флагов (булево) которое отражают факт выполнения логики обработки первичного заполнения. Устанавливая его в этом же вызове БП, чтобы в дальнейшем при изменении этого поля логика первичной инициализации уже не отрабатывала. (что есть суть - overhead в чистом виде и по БД и по архитектуре, Бритва Окама - негодует) 2) Так же было бы неплохо иметь ИЗМЕНЕННОЕ и ИЗМЕНЯЕМОЕ значение в виде стартовых параметров в сигнале БП, это позволило бы избежать как минимум одного побочного "Чтения данных" или "Если старое значение X а новое значение Y то... иначе...", а в некоторых случаях позволило бы развивать юзкейсы "Если новое значение конкретный X то..." прямо со старта процесса, что выглядит более линейным и логичным с точки зрения схематики. Я уже вижу сотню применений такой возможности на своих задачах. Хотелось бы услышать мнение сообщества по поводу моего предложения, Вам тоже не хватает подобной функциональности ?

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

что-то с названием темы...
нет возможности отредактировать самостоятельно,
возможно у кого-то есть права модератора, корректное наименование:
"Бизнес-процесс, сигнал от объекта, изменение; добавление информации о предыдущем значении, и доп.условие старта"

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

При удалении записи тоже было бы классно иметь возможность узнать значения её полей.

Владимир, в таком случае проще добавить в раздел логическое поле «Удалён» и вместо удаления ставить эту галку. Можно ещё фильтровать по её отсутствию или права всем удалять, кроме админа.

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

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

Подскажите, как отловить сигнал завершения БП со страницы раздела. БП запускается с этой же страницы. А после получения сигнала о завершении, выполнить произвольную функцию.

БП со страницы раздела вызываю следующим кодом:

                                       var processArgs = {
                                                sysProcessName: 'CollectionOfStatistics',
                                                parameters: {
                                                        CreatedById: CreatedById,
                                                        CalcForPeriod: forPeriod
                                                }
                                        };
                                        ProcessModuleUtilities.executeProcess(processArgs);

Нравится

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

Здравствуйте, Олег!

Вы можете вызвать следующий web сервис:
http[s]://<адрес_приложения_bpm'online>/0/ServiceModel/ProcessEngineService.svc/CollectionOfStatistics/Execute?ResultParameterName=RESULTPARAMETERNAME&CreatedById=CreatedById&CalcForPeriod=forPeriod

В результате на клиент придет значение результирующего параметра RESULTPARAMETERNAME после получения которого, Вы можете выполнить произвольную функцию.

Более подробно о сервисе ProcessEngineService.svc Вы можете почитать по ссылке

RESULTPARAMETERNAME - параметр процесса с типом "Строка". В Вашем кейсе достаточно будет ограничить длину строки 50 символами.

Здравствуйте, Алексей. Спасибо за ответ. Возможно я что-то делаю не правильно. Воспользывался вашим советом. Вызываю БП со страницы раздела следующим методом:

var CreatedById = this.Terrasoft.SysValue.CURRENT_USER_CONTACT.value;
 
var Params = "ResultParameterName=ResultProcess&CreatedById=" + CreatedById + "&CalcForPeriod=false";
 
 
Terrasoft.AjaxProvider.request({
		url: "../ServiceModel/ProcessEngineService.svc/CollectionOfStatistics/Execute?" + Params,
		method: "POST",
		scope: this,
		jsonData: {},
		callback: function(request, success, response) {
			if (success) {
 
//Сюда приходит строка с возвращаемым параметром из БП
//Вида : 
//response.responseText =
//"<string xmlns="http://schemas.microsoft.com/2003/10/Serialization/">"ProcessEnd"</string>"
//Как ее правильно обработать? string.replace мне кажется не совсем верным решением
 
                      }
		}
	});

Как правильно обработать строку вида:

response.responseText = ""ProcessEnd""?

И второй вопрос: в БП есть преднастроенная страница. Соответственно, если она вызывается, то страница раздела ничего не ждет. Параметр response.responseText приходит со значением null и метод в котором вызывается БП завешается. Что не так?

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

Если в процессе есть преднастроенная страница, то должна открыться и пока этот элемент не будет выполнен, результирующий параметр будет null.

Обработка полностью зависит от Вашей задачи. Так как всегда будет приходить один и тот же параметр, то string.replace, как по мне, очень даже корректное решение.

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

Добрый день!
В обращении в ITIL есть такие поля "просрочен по реакции" и "просрочен по разрешению",
эти поля заполняются автоматически, если плановое время реакции/разрешения прошло.
Почему стартовый сигнал в бизнес-процессе ( при изменении обращения, "просрочен по реакции"=true, должно быть изменено поле "просрочен по реакции") не срабатывает?
Не реагирует именно на изменение поля "просрочен по реакции"(по разрешению)
Если добавить еще какое-то поле в "должно быть изменено поле", то бизнес-процесс стартует

Нравится

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

Добрый день Дарья!!!

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

В обращении в ITIL есть такие поля "просрочен по реакции" и "просрочен по разрешению",
эти поля заполняются автоматически, если плановое время реакции/разрешения прошло.

Я хотела бы сделать бизнес-процесс, в котором в качестве стартового сигнала служило бы изменение поля "просрочен по реакции".
Сигнал выглядит следующим образом: сигнал при изменении обращения, условие - "просрочен по реакции"=Да, список должно быть измененных полей - "Просрочен по реакции".

Сигнал не срабатывает на изменение поля "Просрочен по реакции".
Именно на это поле. Если я любое другое поле добавлю, то сигнал начнет срабатывать.
Особенность поля "просрочен по реакции" в том, что его изменение происходит автоматически, т.е. как только дата реакции становится просроченной.

Дарья, насколько я понимаю, изменения происходят на уровне бд, пользователь не изменяет данный параметр, соответственно сигнал не может среагировать.

ясно, спасибо

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

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

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

Собственно сам вопрос - возможно ли запускать один процесс несколькими сигналами? Не совсем удобно плодить кучу бизнес-процессов для решения одной задачи.

Нравится

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

Здравствуйте, Константин!

Создание двух начальных событий для одного процесса не предусмотрено базовой логикой приложения BPMonline 7.X. Для одного начального события возможен только один процесс, который в свою очередь может ветвится в зависимости от условий.

Показать все комментарии
Публикация

В продолжение темы http://www.community.terrasoft.ua/blogs/2131

Как вывести звуковое сопровождение для определенного события, например, появление напоминаний?

var FileName = "c:\\file.mp3"
function Music(FileName) {
     var Shell = System.CreateObject("WScript.Shell");
     Shell.Run("mplayer2 \/play \/close " + FileName, 0, false);
}

Результат: стандартный плеер Windows запускается в фоне и воспроизводит звуковой файл. Закрывается после воспроизведения файла.

Нравится

Поделиться

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

Для WAV-файлов есть способ без запуска плеера.

Саша, это потрясающе! :)

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