Определение действий

Действие является группой инструкций языка Transact-SQL, которую службы Notification Services запускают каждый раз при запуске правила подписки. Каждое правило подписки может содержать одно действие: или основное действие, которое является предопределенным запросом, или условное действие, что позволяет подписчикам определить эквивалент предложения WHERE для запроса создания уведомления. В этом разделе описываются основные действия и правила их написания.

Действия

Инструкции языка Transact-SQL в действии выполняют определенную работу для правила. Такая работа обычно заключается в создании уведомлений на основании соединения полей подписок и полей событий. В следующем примере представлено действие, создающее уведомления для приложения Weather:

INSERT INTO WeatherNotifications (SubscriberId, DeviceName, 
    SubscriberLocale, City, Forecast)
SELECT s.SubscriberId, s.DeviceName, 
   s.SubscriberLocale, e.City, e.Forecast
FROM WeatherEvents e 
JOIN WeatherSubscriptions s
ON s.City = e.City;

В данном примере выбираются подписчик, устройство, языковой стандарт, город и текст прогноза из соединения представления событий WeatherEvents и таблицы подписок WeatherSubscriptions, а затем добавляют результаты в таблицу уведомлений WeatherNotifications. Службы Notification Services автоматически создают представление WeatherEvents для класса событий WeatherEvents; в этом представлении содержится только текущий набор событий, который должен быть обработан генератором.

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

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

Дополнительные сведения о создании запросов на языке Transact-SQL см. в разделе Основные принципы запросов.

Инструкция INSERT

Примечание.
Инструкция INSERT заменяет функцию уведомления, используемую для создания уведомлений в службах Notification Services 2.0.

Как было показано на приведенном примере кода, в инструкции INSERT необходимо указать следующие поля в следующем порядке:

• SubscriberId
• DeviceName
• SubscriberLocale
• Все невычисляемые поля, определенные в схеме уведомления. При использовании вычисляемых полей не вставляйте значения в такие поля. Значения для таких полей вычисляются при вставке данных уведомления.

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

Использование предложения WHERE для дополнительных условий

Если в схеме подписки более одного пользовательского поля, то можно добавить предложение WHERE для обеспечения дополнительных условий. Например, если приложение Weather разрешает подписчикам вводить диапазон температур, то к предыдущему примеру кода можно добавить следующее предложение:

WHERE  e.HighTemp > s.High 
    OR e.LowTemp < s.Low

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

Примечание.
Если приложение определяется в XML-файле, то необходимо заменить зарезервированные символы XML, например «<», ссылками на сущности. Дополнительные сведения см. в разделе XML Reserved Characters.

Другие предложения

Язык Transact-SQL поддерживает множество других предложений для инструкции SELECT. Однако большая часть таких предложений не подходит для использования в службах Notification Services. Например, предложение ORDER BY располагает результаты запроса SELECT в определенном порядке, но такой порядок не влияет на то, как и когда службы Notification Services будут создавать и доставлять уведомления. Предложение UNION может использоваться для объединения результатов двух запросов, но такая возможность редко используется для правил подписки.

Использование хранимых процедур

Вместо внедрения в действие инструкций языка Transact-SQL действие может вызывать хранимую процедуру. Необходимо создать хранимую процедуру в базе данных приложений. Можно определить хранимую процедуру в сценарии развертывания. Создавать хранимые процедуры можно только после того, как службы Notification Services создадут экземпляр или добавят приложение, но до включения экземпляра или приложения.

Для применения хранимой процедуры необходимо выполнить хранимую процедуру из действия. В следующем примере представлено действие, выполняющее хранимую процедуру:

EXECUTE dbo.WeatherActionSP;

Транзакции

Все инструкции в действии входят в состав одной транзакции, поэтому они либо все успешно выполняются, либо все откатываются. При ошибке транзакции службы Notification Services запишут ошибку в журнал приложений Windows.

Действия для правил событий

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

Внимание!

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

Шаблон

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

INSERT INTO schema.notificationClassName (SubscriberId, DeviceName, 
    SubscriberLocale, NotificationFields)
SELECT s.SubscriberId, DeviceName, SubscriberLocale, Fields
FROM schema.subscriptionClassName s 
JOIN schema.eventClassName e
ON s.columnName = e.columnName
[WHERE...][;]

Можно либо взять значения DeviceName и SubscriberLocale из источника данных, таких как представление подписки, либо указать символьные значения, такие как «File» и «en-US».

Обратите внимание, что значения SubscriberId и DeviceName должны совпадать с записью в таблице SubscriberDevices.

Обслуживание хроники событий

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

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

Следующее правило сначала удаляет все данные хроники событий. Затем правило берет текущий пакет событий из представления WeatherEvents и добавляет эти события в хронику событий.

DELETE FROM dbo.WeatherEventsChron;
INSERT INTO dbo.WeatherEventsChron(City, Date, Low, High, Forecast)
SELECT e.City, e.Date, e.Low, e.High, e.Forecast
FROM dbo.WeatherEvents e;

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

Определение действия для правила событий

При определении приложения посредством XML задайте действия в файле определения приложения (ADF). При определении приложения программным путем используйте управляющие объекты служб Notification Services для задания действий.

• Action Element for EventRule (ADF)
• свойство Action (NMO)

Действия для запланированных правил

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

Шаблон

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

INSERT INTO schema.notificationClassName (SubscriberId, DeviceName, 
    SubscriberLocale, NotificationFields)
SELECT s.SubscriberId, DeviceName, SubscriberLocale, Fields
FROM schema.subscriptionClassName s 
JOIN schema.eventChronicleName ec
ON s.columnName = ec.columnName
[WHERE...][;]

В инструкции SELECT можно либо взять значения DeviceName и SubscriberLocale из источника данных, таких, как представление подписки, либо указать символьные значения, такие, как «File» и «en-US».

Обслуживание хроники подписок

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

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

Определение действия для запланированного правила

При определении приложения посредством XML задайте действия в файле определения приложения (ADF). При определении приложения программным путем используйте объекты NMO для определения действий.

• Action Element for ScheduledRule (ADF)
• свойство Action (NMO)

См. также

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

Определение условных действий
Определение правил событий
Определение запланированных правил

Другие ресурсы

Предложение WHERE (Transact-SQL)
INSERT (Transact-SQL)
SELECT (Transact-SQL)
Определение классов подписки

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

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