Доброго времени суток, коллеги!
Совершаю первые попытки использования бизнес-процессов, поэтому прошу сильно не пинать.
Задача. При изменении состояния инцидента на определённое значение и неизменении этого состояния в течение n-ного количества времени, необходимо сформировать напоминалку ответственному и создателю.
Моё видение решения.
Через "Автоматический запуск процесса" настраиваю запуск моего процесса по изменению данных в источнике данных Инцидент если новое значение состояния соответствует такому-то фильтру. Как гасить уже висящий процесс при смене состояния на другое пока не придумал, возможно через другой бизнес-процесс, в котором скриптом прописать окончание предыдущего.
Создаём бизнес-процесс, содержащий всего два действия:
1. Задержка на n-ное количество времени
2. чтение/запись данных, "запись значений параметров в базу данных", "создать новую запись" с источником данных "напоминание". В п.5 заполняю поля будущего напоминания: "Описание = текст напоминания", "Тип объекта = Инцидент", "Время = как указать текущее + 1-2 минуты?" И вопрос с п.4: указать взаимосвязь ключевого поля с параметром диаграммы. Видимо, здесь нужно указать, к какому инциденту будет прицеплено новое уведомление. Откуда заполучить номер? И ID ответсвенного и создателя инцидента как поймать?
Нравится
1. Через "Автоматический запуск процесса" настраиваем запуск БП через каждые M-минут (зависит от n и здравого смысла)
2. В БП:
- берем все инциденты, подходящие по признакам ("неизменении этого состояния в течение n-ного", для учета последнего изменения надо либо сделать поле, куда писать текущее время при изменении, либо включить историю)
- проверяем для выбранных инцидентов - нет ли уже напоминалок/вместо проверки можно просто удалять созданные ранее (по какому-то признаку + ИД инцидента)
- добавляем и/или обновляем напоминалки для выбранных инцидентов
Так у вас будут всегда (с промежутком в M-минут) актуальные напоминалки
Как вариант, можно сделать это в виде задания Агента-SQL.
Но на сам деле надо сделать по-другому)) При изменении состояния инцидента на нужное - ставить напоминалку через n-времени. При изменении состояния с нужного - стирать ее. И Все)
"Андросов Дмитрий" написал:Как вариант, можно сделать это в виде задания Агента-SQL
Если все ж надумаете делать именно регулярно выполняемые задания - всячески плюсую этот вариант!
Ставить напоминалку - это работа ручками, а именно её и хочется исключить, т.к. в этом случае в процесс вклинивается человеческий фактор. Сейчас у народа есть фильтр по заданному состоянию инцидента, и на него им лень перейти и проверить не появилось ли там что-нибудь.
В целом, мысль понял и принял. На самом деле, наверно в джобик SQL это засунуть проще будет.
1. Выбираю все инциденты в нужном статусе из tbl_Incident
2. Из tbl_IncidentLog вытягиваю max(CreatedOn) для данного инцидента. Если эта дата отличается от текущей более чем на N, проверяю наличие/отсутствие в tbl_Reminding строчки для этого инцидента. Если нет, инсертю её.
Теоретически, должно получиться. Пошел кодить.
"Булат Андрей Борисович" написал:Ставить напоминалку - это работа ручками, а именно её и хочется исключить
Имелся ввиду скрипт на сохранение объекта Инцидент. Кодом написать генерацию напоминания, работать будет автоматом
"Александр Кудряшов" написал:
Булат Андрей Борисович пишет:
Ставить напоминалку - это работа ручками, а именно её и хочется исключить
Имелся ввиду скрипт на сохранение объекта Инцидент. Кодом написать генерацию напоминания, работать будет автоматом
Тоже вариант.
Остаётся вопрос: как убивать неиспользованные напоминания, если инцидент из неправильного состояния переведён раньше наступления часа Х. Там-же в скрипте отслеживать? Всё-таки, вариант с периодическим заданием/джобиком эту логику отработает правильнее.
"Булат Андрей Борисович" написал:как убивать неиспользованные напоминания...Там-же в скрипте отслеживать? Всё-таки, вариант с периодическим заданием/джобиком эту логику отработает правильнее.
реализовать скриптом проще.
после сохранения инцидента (DatasetAfterPost):
- если состояние изменилось с другого на неправильное - поставить напоминалку на текущее время + n
[когда наступит время Х - напоминалка отрабоается (удалится или переставится) вручную тем, на кого она ставится, если час Х не наступит то:]
- если состояние поменялось с неправильного на другой - удалить напоминалку, если она есть
состояние для дальнейшего сравнения в качестве "того, которое было до редактирования" лучше сохранять в переменную на AfterOpen
Реализовал таки через джобик SQL, ибо TSQL мне больше знаком :-) Вроде работает. Но... Напоминалку пользователь увидит только если запустит программу. У нас не все постоянно сидят в системе: не требуется это.
Отсюда вылезло продолжение задачи. Формировать не напоминалку а письмо. Тоже средствами MSSQL это возможно, или возвращаемся к первому сообщению - формирование бизнес-процесса?
"Булат Андрей Борисович" написал:Тоже средствами MSSQL это возможно, или возвращаемся к первому сообщению - формирование бизнес-процесса?
оба варианта рабочие, но БП лучше т.к. логика не выносится за рамки системы
ой нет, это же 3х)))
по-моему, лучше сделать джоб на отправку е-мейла)
"Андросов Дмитрий" написал:ой нет, это же 3х)))
по-моему, лучше сделать джоб на отправку е-мейла)
Тогда подскажите, с какой стороны подлезть? В какие таблицы и что засунуть? И самое главное, с чьей стороны будет уходить письмо?
сформулируйте еще раз задачу с учетом того, что это е-мейл, а не напоминание
При нахождении инцидентов, находящихся в состоянии YY более заданного времени (селека соответствующая уже готова), необходимо отправить письмо ответственному и автору инцидента. Адрес берём из соответствующих контактов. Тема письма - простой текст. В тело письма неплохо было бы затолкать номер инцидента, наименование контрагента и "признаки" инцидента.
письмо отправлять средствами сервера SQL (sp_send_dbmail) или через ОС сервера (плохо представляю как)
я бы отправлял одно письмо на одного адресата (с информацией на все инциденты, касающиеся адресата)
в Террасофт письма, естественно, не сохранятся (да и не надо)
Дмитрий, спасибо! Счастье наступило!
Слепил через sp_send_dbmail. В кучу собирать не стал: один инцидент - одно письмо, чтобы не перелопачивать логику предыдущего джоба.