Решение "Workflow Мониторинг"
Общее описание
Решение контролирует состояние службы Workflow и при сбое отправляется сообщение администратору по почте или пытается автоматически восстановить её работоспособность (автоматически перезагружает службу).
Решение состоит из трёх модулей:
- Модуль мониторинга
- Модуль уведомления
- Модуль исправления
Модуль мониторинга
Очередь Workflow хранится в БД в таблице SBWorkflowProcessing. Таблица SBWorkflowProcessing предназначена для хранения информации о задачах, принятых к обработке и об обрабатываемых в текущий момент службой IS-Builder Workflow Processing. Информация о задаче в таблицу заносится при старте задачи, при выполнении задания по задаче и при завершении работы задачи, от которой зависит выполнение других задач. Удаляется при завершении очередного этапа обработки маршрута и при прекращении или удалении задачи.
Мы можем использовать данную таблицу, чтобы контролировать активность службы Workflow. Служба Workflow считается не активной, если дата и время следующей обработки маршрута задачи (NextDateProcessing) пустое (NULL) или меньше текущего времени.
Модуль мониторинга представляет собой SQL-Job, который создается при установке решения. Настройки расписания заполняются при запуске сценария.
Схема работы данного модуля приложена в конце материала.
Модуль уведомления
Модуль уведомления является стандартным компонентом SQL – это Database Mail. Компонент Database Mail — это решение уровня предприятия для отправки сообщений электронной почты от компонента SQL Server Database Engine. Используя компонент Database Mail, приложения базы данных могут отправлять почтовые сообщения пользователям.
Компонента Database Mail устанавливается при установке решения. Настройки компоненты Database Mail заполняются при запуске сценария решения.
Модуль исправления
Модуль исправления представляет собой SQL-Job, который перезагружает службу Workflow при необходимости. Данный SQL-job запускается модулем мониторинга.
Данный модуль можно отключить или включить в настройках сценария решения.
Установка решения
Требование к установке
- Microsoft SQL Server 2005 или выше;
- редакция Microsoft SQL Server как минимум Standard
- если служба workflow установлена на отдельном сервере, необходимо запустить службу «SQL Agent» под учетной записью, которая является администратором на сервере WorkFlow;
- Запустить сценарий под SA.
Импортирование разработки в систему DIRECTUM
При импортировании разработки, появляется следующие компоненты:
- Константы
- WorkFlow_Monitoring_AutoRestart
- WorkFlow_Monitoring_EmailAddress
- WorkFlow_Monitoring_ErrorThreshold
- WorkFlow_Monitoring_Login
- WorkFlow_Monitoring_Password
- WorkFlow_Monitoring_Period
- WorkFlow_Monitoring_Recipients
- WorkFlow_Monitoring_RestartAttempts
- WorkFlow_Monitoring_SMTPServerName
- WorkFlow_Monitoring_SMTPServerPort
- WorkFlow_Monitoring_SMTPServerSSLEnable
- WorkFlow_Monitoring_WarningThreshold
- WorkTimeResponsibleUser
- Сценарии
- Установки мониторинга службы Workflow
Запуск сценария
В данном окне заполняются данные подключения к почтовому серверу.
В данном окне заполняются настройки системы мониторинга.
После выполнения сценария появляются 2 SQL-Job:
- WorkFlow.Мониторинг
- WorkFlow.Мониторинг.Перезагрузка служба WorkFlow
Решение находится во вложении.
Огромное спасибо Владимиру за сценарий и тестирование.
Мохаммед, а есть какая-то статистика по эффективности этого решения в части исправления сбоев?
Интересно - насколько часто сбой службы Workflow успешно решается просто ее перезапуском без вмешательства администратора?
Т.е. получается ваше решение заметит сбой воркфлоу уже после самого пользователя?
Я так понял что оно мониторит появление задач которые не встали в очередь на обработку. Т.е. их создали, попытались стартовать, увидели ошибку "Невозможно подключиться к воркфлоу"?
Статистики нет. Иногда перезагрузка помогает, ну скажем на 70%. Думаю надо ждать отзыв клиентов. Если отзыв будет интересно, будем развиваться
Я так понял что оно мониторит появление задач которые не встали в очередь на обработку. Т.е. их создали, попытались стартовать, увидели ошибку "Невозможно подключиться к воркфлоу"?
замечание (пожелание).
Надо чтобы решение контролировало состояние служба Workflow (Работает/остановлена). Если Workflow в состоянии «Остановлена», отправиться уведомление администратору DIRECTUM.
Мохаммед и Владимир, спасибо за это решение. Workflow действительно часто отваливается, так что решение очень актуально для многих наших заказчиков. Буду распространять ссылку на материал. Начиная с какой версии DIRECTUM оно должно работать?
С любой версией DIRECTUM должно работать.
У наших контрагентов воркфлоу не отваливается. На моей памяти было всего два случая за последние три года когда задачки вставали. Она чаще не запускается с системой, чем зависает. На такой случай у нас есть батник в планировщике который поднимает службу.
Кто из Вас протестировал решение?
В ряде случаев (из личного опыта) рестарт службы произвести не просто: попытка автоматического завершения процессов службы будет безуспешной, если они зависили при обработке чего-либо. В таких случаях корректно остановить службу можно только принудительно завершив процессы службы в диспетчере задач.
Отсюда вопрос: как отреагирует данное решение на состояние службы WF "остановка" и предпримет ли она что-либо для восстановления работы службы? Если ранее это не было предусмотрено, то считайте пожеланием к развитию.
Интересное решение, у меня такой вопрос: Есть блоки типа "Мониторинг" отслеживающие выполнение заданий по подзадаче. Блоки настроены таким образом, что они выполняются сразу когда выполняется задание по подзадаче, т.е. задание при выполнении "дергает" блок мониторинга. Иногда, случается, что что из-за нагрузки или сбоя в работе wf, блок не "дергается" и продолжает ожидать выполнения подзадачи, хотя она уже выполнена.
Есть ли возможность прикрутить к данному решению механизм "дерганья" таких блоков типа "Мониторинг"?
П.С. Простой перезапуск службы wf обычно не помогает...
Я помониторил таблицу SBWorkflowProcessing на предмет наличия записей с пустым NextDateProcessing (is null) и действительно удалось выявить несколько "повисших" задач. Но также я заметил что такие записи (с пустым NextDateProcessing) в таблице появляются постоянно. Понаблюдав я пришел к выводу, что запись с пустым NextDateProcessing говорит о том что текущее задание по задаче выполнилось, а следующее еще не создалось. Так что если условием перезапуска службы является только пустота в поле NextDateProcessing, то, боюсь, служба будет делать рестарт постоянно.
Не надо бояться :)
Пустое поле NextDateProcessing означает, что задача была создана недавно и еще ни разу не обрабатывалась службой Workflow (соответственно, служба и не присвоила еще время следующего исполнения). Если таких задач много - то нужно просто увеличить порог количества необработанных задач для перезапуска сервиса.
Кстати, для повышения производительности Workflow можно увеличить количество процессов в файле настройки Workflow. В этом случае очередь будет обрабатываться бОльшим количеством потоков.
Хотелось бы попробовать данное решение у нашего клиента, из-за большой нагрузки служба переодически падает раз в неделю и о ее падении админы обычно узнают непосредственно от пользователей, часа через 2-3 после падения службы.
О статистике использования сообщу тогда отдельно.
Еще было замечено, что служба Workflow регулярно умирает, если у неё в конфиге есть записи на уже несуществующие системы. Проверьте у себя на всякий случай, хотя мне кажется конфиг смотрят первым делом при возникновении таких проблем :)
Неужели у всех работает?
Авторизуйтесь, чтобы написать комментарий