задержка активности в области действия обработки событий - точка доступа рабочего процесса Windows

Question

Я пытаюсь создать следующий сценарий:

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

Итак, я подумал об использовании EventHandlingScope для этого:

• Я ожидаю смены задачи в основной ветке активности Eventhandlingscope,
• прослушивание переназначения изменения задачи в ветви, управляемой событиями - и, если активируется задача переназначения, переназначить первую задачу указанному пользователю
• в другой ветви, управляемой событиями, используйте операцию задержки и периодически проверяйте, приближается ли назначенная пользователем задача к дате исполнения, и отправляйте напоминание по электронной почте

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

Если я добавлю задержку в одну из веток Обработчиков событий, она сработает один раз, но не больше. Принимая во внимание, что если я добавлю туда действие onTaskChange, оно срабатывает каждый раз, когда кто-то меняет эту задачу.

Итак, это ожидаемое поведение? Почему DelayActivity не зацикливается? Как я мог сделать это по-другому? Моя мысль с CAG, но это выглядит немного сложнее ...

Обновление: проблема с CAG заключается в том, что все это блокируется, пока не сработает задержка, даже если сработало событие onChange. Это имеет смысл, но делает его немного сложнее в использовании.

Обновление 2: я переписал текст, чтобы сделать его понятнее

Answer 1

Решение

Фундаментальное мероприятие, которое решает эту проблему: WhileActivity, содержащее ListenActivity.

Акту прослушивания дается 3 EventDrivenActivity веток. Первая - это ваша ветвь «Задача пользователя выполнена», вторая - ветка «Менеджер изменил назначенного пользователя», а третья содержит DelayActivity, за которой следует логика вашей электронной почты.

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

Вам необходимо убедиться, что последовательность «Задача пользователя завершена» задает некоторое значение, которое может быть проверено циклом while, так что цикл while завершается, когда пользователь завершает задачу.

Когда ветвь, отличная от ветки «User Task Completed», отвечает за завершение рабочего процесса ListenActivity, возвратится к ListenActivity и повторно выполнит все 3 события, управляемые событиями, включая ту, которая содержит DelayActivity .

Обратите внимание, что это немного отличается от подхода EventHandlingScope, потому что "прослушивание пользовательской задачи завершено" будет отменено и повторно выполнено, тогда как с EventHandlingScope это не произойдет. IMO - это лучшая договоренность, поскольку это означает, что пользователь, который был выбран для выполнения задачи в начале действия Listen, в конце гарантированно не изменится (потому что, если он будет изменен, вся операция будет отброшена, а новая запущена ).

Почему задержка срабатывает только один раз в EventHandlingScope

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

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

В случае DelayActivity существует некоторое внутреннее «событие, вызванное таймером», которое прослушивается. Когда Задержка впервые введена, тайм-аут настроен так, что таймер сработает в соответствующее время, затем он прослушивает это событие. Однако после срабатывания прицела возвращается к прослушиванию «события, инициированного таймером», однако не происходит повторного запуска исходного кода, который устанавливает тайм-аут, и, следовательно, никаких других «событий, запускаемых таймером», не ожидается.

Answer 2

Я знаю, что вы не хотите этого слышать, но вам лучше создать рабочий процесс вместо обработчика, так как рабочие процессы разработаны так, чтобы намного лучше обрабатывать измерение времени, так как они "долго работают". Обработчики событий более ограничены для моментального запуска события, после чего они завершают действие. Не только это, но, судя по тому, что вы пишете, если требования настолько просты, вы можете создать рабочий процесс SharePoint Designer, чтобы вам даже не пришлось открывать Visual Studio.

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

Наконец, если вы работаете в режиме отладки и жестко запрограммировали свой идентификатор задачи, вы можете запустить только одну задачу за сеанс отладки, иначе ваш обработчик событий остановится, когда в SharePoint будет добавлен другой элемент с таким же идентификатором. Это может объяснить, почему ваша задержка активности заблокирована.