Форумы Интермех - Помещение событий в IDBTimedEvents 1327 page 0

Форумы Интермех / API и разработка модулей расширения / Помещение событий в IDBTimedEvents

Автор

Сообщение

Дата: 4 Апр 2013 15:58:07 ° Поправил: Дмитрий

В данном посте освещены некоторые моменты использования серверной службы IDBTimedEvents, которая пока не документирована в IPS.

Интерфейс серверной службы описан IDBTimedEvents в пространстве имен Intermech.Interfaces.Server. Служба позволяет создавать в системе события, которые будут срабатывать разово или по расписанию и вызывать в ответ указанный в событии обработчик (например, сборщик мусора в базе данных или индексатор файловых атрибутов).
Для создания события используется метод AddEvent, в который нужно передать структуру TimedEventProperties и (при необходимости) менеджер для работы с базой данных. Необходимость в менеджере может возникнуть в случае, если добавление события происходит в транзакции, при откате которой событие должно быть удалено из очереди событий.

В структуре TimedEventProperties должны быть обязательно заполнены следующие поля:

StartDate - дата и время срабатывания события (только для разовых событий);

ServiceGuid - глобальный ид. обработчика события (см. ниже);

EventKind - указывает периодичность события;

Name - Наименование события, если его нужно отображать и настраивать в списке событий (обязательно для периодических событий);

Schedule - строка с настройками расписания события (только для периодических событий). Эта строка формируется планировщиком задач, но её задать и самостоятельно следующим образом:

TimedEventKinds.Hourly - Для ежечасного события в строке количество часов, через которое нужно сработать событию;

TimedEventKinds.Daily - Для ежедневного события в строке находится инфа во сколько нужно сработать событию (в форме HH:mm) - часы и минуты;

TimedEventKinds.Weekly - Для еженедельного срабатывания в строке хранится время срабатывания, а затем через запятую - дни недели по енумератору DayOfWeek, приведённому к числу (например, 12:00,2,5);

TimedEventKinds.Monthly - Для ежемесячного события хранится время срабатывания (часы:минуты)и через запятую - числа месяца, в которые должно сработать событие (HH:mm, DD, DD, DD..);

TimedEventKinds.Yearly - Для ежегодного события хранится день срабатывания в формате хранится в формате HH, mm, DD, MM (часы, минуты, день, месяц)HH, mm, DD, MM (часы, минуты, день, месяц);

Дополнительно в TimedEventProperties можно заполнить следующие поля:

DeadlockDate - Дата, по истечении которой незатребованное событие будет удалено из списка событий (в UTC);

RetryCount - Сколько раз повторить попытку вызова обработчика события в случа неудачи;

ServerName - Имя сервера, на котором должно выполняться событие;

ImmediateRun - Стартовать ли событие при запуске сервера приложений если запланированный старт был пропущен (для периодических событий);

ObjectID - Ссылка на объект, к которому имеет отношение данное событие;

UserID - Пользователь, к которому относится данное событие (если это имеет значение);

StringInfo - Дополнительная строковая информация о событии;

IntInfo - Дополнительная числовая информация о событии;

Перед регистрацией события в системе нужно зарегистрировать его обработчик, который будет вызван в момент срабатывания. Для этого предназначен метод IDBTimedEvents.RegisterService, которому на вход нужно подать объект, поддерживающий интерфейс IDBTimedService или унаследованный от него интерфейс IDBManualScheduledService, который рекомендуется поддерживать обработчикам событий, которые должны выполняться в отдельном потоке, не задерживая общую очередь обработки событий. Также регистрируемый объект должен поддерживать интерфейс IDBGuid, который должен возвращать глобальный идентификатор данного обработчика событий, по которому будут приходить обратные вызовы обработчика при срабатывании события.

Также в пространстве имён Intermech.Kernel описан абстрактный класс DBCustomManualScheduledService, от которого можно наследовать свои обработчики периодических событий. В конструктор данного класса рекомендуется отправлять клон системной или иной сессии, чтобы данный объект работал с собственными сессионными объектами, транзакциям и пр., если планируется его асинхронное исполнение в отдельном потоке.