Используем БП, в которых стартовым событием является добавление нового участника email-рассылки, sms-рассылки, мероприятия и кампании. При этом запускаются только те процессы, где стартовым событием служит создание участника мероприятия, остальные процессы не срабатывают. Причём на тестовой 14-дневной версии "Маркетинга" свежего выпуска такой проблемы при предварительной проработке не наблюдалось. У нас сборка 7.16.2. В чём может быть проблема?

Нравится

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

Примечание: когда добавление осуществляется через справочник, процесс срабатывает. А когда через добавление на деталь - нет.

Добрый вечер Нина, для решения данной проблемы можно ознакомится с документацией которая соответствует версии вашего приложения:

https://academy.terrasoft.ru/documents/technic-bpms/7-16/sobytiya-v-hod…

 

Так же можно узнать больше используя приложение с МаркетПлейса - https://marketplace.creatio.com/template/business-processes-start-events

 

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

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

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

Нравится

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

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

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

Татьяна,

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

Александр,

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

Татьяна,

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

Александр,

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

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

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

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

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

Нравится

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

Алексей, добрый день.

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

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

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

Коллеги, приветствую.

Есть некоторый простой бизнес- процесс, инициируемый событием- сигналом "Добавление записи в таблицу".

Например:

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

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

Был бы весьма признателен за информацию.

Спасибо.

--
С уважением, Алексей Быков.

Нравится

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

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

У стартового сигнала есть параметр "Идентификатор записи" (RecordId). Создайте параметр процесса NewID с типом "Уникальный идентификатор". Используйте элемент "Формула" для передачи параметра StartSignal.RecordId в созданный Вами параметр NewID.
Используйте в задании-сценарии следующий код, чтобы получить значение, которое хранится в параметре NewID:

Id = Get<Guid>("NewID")

В итоге в параметре элемента "Задание-сценарий" будет установлено Id стартового сигнала.

Здравствуйте, Алексей! Спасибо большое за ответ, сейчас попробую сделать это.

Алексей, спасибо еще раз, все верно.

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