Архитектура обработки подписок

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

Чтобы создавать уведомления, разработчик приложения создает одно или несколько правил для приложения. Эти правила записаны в виде запросов на языке Transact-SQL, задающих отношения событий и подписок, а также любые другие условия, которые должны быть выполнены для создания уведомления.

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

Уведомление не отправляется сразу после создания. Вместо этого генератор записывает уведомление во внутреннюю таблицу уведомлений. Когда готов пакет уведомлений, уведомления форматируются и распространяются распространителем.

Если приложение поддерживает расписание подписок, то когда генератор обрабатывает расписания подписок, он видит только те подписки, для которых пришло время оценки. Например, если генератор запускается каждые 15 минут, то в 8:00 генератор оценивает все подписки, расписание для которых было установлено с 7:45 до 8:00.

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

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

Типы правил

Работа генератора определяется правилами, определенными для приложения. Можно создавать правила следующих типов.

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

Типы действий правил

Правила событий и правила по расписанию задают действие, которое необходимо выполнить при срабатывании правила. Каждое действие представляет собой запрос на языке Transact-SQL, определяющий блок работ для выполнения генератором. Эти запросы могут создавать уведомления, но также могут выполнять другую работу, например поддержку данных хроники.

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

• Простые действия представляют собой запросы на языке Transact-SQL, полностью определяющие запрос создания уведомления, включая предложения WHERE. Простые действия получают выражения предложений WHERE из данных подписок и событий. Например, приложение Weather может позволять подписчикам задавать город для получения уведомлений о погоде. После этого запрос простого действия использует предложение WHERE, например WHERE subscription.city = event.city, соединяя данные о событиях и подписках по именам городов.
  Когда правило использует простое действие, подписчики предоставляют параметры для запроса, например название города.
• Условные действия позволяют подписчикам полностью определять свои условия поиска для запросов. Например, можно сделать схему данных о событиях доступной в интерфейсе управления подписками и разрешить подписчикам создавать собственные условия поиска в этих данных, такие как WHERE event.State = Washington AND event.LowTemperature < 0. Интерфейс управления подписками может сделать написание этих условий поиска таким же простым, как выбор столбцов и операторов из списков и ввод значений в текстовые поля.

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

См. также

Основные понятия

Указание длительности такта генератора
Определение правил подписок
Архитектура коллекции событий
Архитектура управления подписками
Форматирование уведомлений и архитектура доставки

Справка и поддержка

Получение помощи по SQL Server 2005