Напоминание о просроченной задаче без повторного создания задачи

Пример предоставила t.me/sakhnovadinara

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



Один из минусов - задача ставится повторно. Это сбивало реальные сроки исполнения задачи. А в случае с согласованием была ошибка, когда задача ставилась тем, кто уже согласовал.

Получилось решить проблему так:



В блоке Данные о процессе получаем ID текущего процесса и время его создания. т.е. дату постановки задачи.

Код:

const instance = await Application.processes._searchInstances().where(f => f.__id.eq(f.__id)).first()
Context.data.id_process = instance!.data.__id
Context.data.begin_date = instance!.data.__createdAt

Далее шлюз и/или. В условиях перехода используем любое условие, которое выполняется всегда. Например, инициатор = инициатор. Таким образом, запускаются обе ветки одновременно.

В верхней ветке просто согласование. Согласовано/Не согласовано.

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



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

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

Например, 1 день. Дату начала, напоминаю, мы передали из родительского процесса.


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

Код:

const instance = await Application.processes._searchInstances().where(f => f.__id.eq(Context.data.id_process!)).first()
Context.data.buffer = instance!.data.__state
if (instance){
if ((instance.data.__state == ProcessInstanceState.exec)||(instance.data.__state == ProcessInstanceState.wait)){
Context.data.delay = true
}
else
{
Context.data.delay = false
}
}

Это сценарий проверки статуса процесса. Context.data.delay - контекстная переменная в подпроцессе, типа Да/Нет. Тут со статусами прикол. Судя по описанию, exec это значит процесс выполняется. Но на практике оказалось, что он уходит в wait.

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

Добрый день, очень заинтересовал ваш пример, но осталось пара вопросов. Вот здесь: "В первом блоке Присваивание, указываем счетчик, который будет считать, на сколько дней просрочена задача. " Про какой счетчик идет речь? Где мы его создали? И что за сценарий "Увеличить счетчик"? Какой там код?

Счетчик представляет собой контекстную переменную типа Число (целое). В сценарии увеличть счетчик мы увеличиваем эту переменную на единицу.

Понятно. Еще вопрос. Зачем вот здесь переменная buffer , ее нужно создавать в контексте?
Context.data.buffer = instance!.data.__state

Что-то оповещение в цикл уходит....

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

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