Поделиться через

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

  • Статья

Изменения: 17 июля 2006 г.

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

ms172509.note(ru-ru,SQL.90).gifВажно!
Условные действия должны использоваться, только если необходимо разрешить подписчикам создавать собственные сложные условия для создания уведомлений. В противном случае необходимо использовать предварительно определенные действия, которые позволяют пользователям вводить значения для параметризованного запроса, поскольку это более эффективно. Дополнительные сведения см. в разделе Определение действий.

Условные действия

Условное действие позволяет использовать гибкие правила, создаваемые подписчиками. В то время как предварительно определенное действие позволяет подписчикам только задавать параметры для запросов, определенных разработчиком, условное действие позволяет подписчику создавать для запроса эквивалент предложения WHERE, используя логические операторы (AND, OR и NOT) для комбинирования отдельных условий.

Например, приложение Weather может иметь класс событий, который содержит два поля: City и Forecast. Разработчик может определить базовый запрос для создания уведомлений, например:

INSERT INTO dbo.WeatherNotifications(SubscriberId, DeviceName, 
    SubscriberLocale, City, Forecast) 
SELECT [Subscription.SubscriberId], [Subscription.DeviceName], 
    [Subscription.SubscriberLocale], [Input.City], [Input.Forecast])
FROM dbo.FlightEventRule

Обратите внимание, что этот запрос выбирает данные из представления, название которого соответствует правилу (в данном случае FlightEventRule). Поля в этом представлении имеют имена Subscription.SubscriptionFieldName и Input.EventFieldName, при этом имена полей должны быть заключены в квадратные скобки.

Используя интерфейс управления подписками, подписчик может определить условия, которые являются эквивалентными предложению WHERE. Например, пользователь может задать два условия: City имеет значение «Seattle», а Forecast содержит слово «snow», а затем объединить эти условия при помощи оператора AND. Это эквивалентно следующему предложению WHERE:

WHERE City = 'Seattle' AND Forecast LIKE '%snow%'

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

Вопросы производительности

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

Безопасность

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

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

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

Транзакции

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

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

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

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

Имя входа SQL Server

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

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

Определение имени входа SQL Server

Пользователь базы данных

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

Службы Notification Services предоставляют необходимые разрешения на объекты служб Notification Services, но не предоставляют разрешения на входные таблицы или представления, а также не предоставляют разрешения ни на какие определенные пользователями функции, используемые условными действиями. Эти разрешения необходимо будет предоставить при развертывании приложения. Команды языка Transact-SQL для предоставления этих разрешений имеют следующую форму:

-- grant permissions on the view for an input event class
GRANT SELECT ON ApplicationSchema.EventClassName TO SqlUserAccount
-- grant permissions on an input event chronicle table
GRANT SELECT ON ChronicleSchema.ChronicleName TO SqlUserAccount
-- grant execute permissions on a user-defined function 
-- used in Subscription.Conditions
GRANT EXEC ON UDFSchema.MyUserDefinedFunction TO SqlUserAccount
Определение пользователя базы данных

Имя входного объекта

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

  • Если условное действие представляет собой правило событий, то входным объектом обычно является представление событий, имеющее такое же имя, как и класс событий.
    Внимание!   Не используйте таблицу с именем NSимя_класса_событийEvents в качестве входного объекта. Эта таблица содержит все события, которые не были удалены из системы, и приведет к созданию дублирующихся уведомлений.
  • Если условное действие предназначено для запланированного правила, то входным объектом обычно является хроника событий.
    Внимание!   Не используйте для запланированных правил представление событий с именем имя_класса_событий в качестве входного объекта. Это представление содержит только текущий пакет событий и часто будет пустым или неполным для запланированных правил.
Определение имени входного объекта

Схема входного объекта

Схема входного объекта — это имя схемы базы данных для входного объекта.

  • Если входным объектом является представление событий, то схемой является схема приложения. Схема приложения может быть определена при определении базы данных приложения или она может иметь значение по умолчанию dbo. Дополнительные сведения см. в разделе Определение базы данных приложений.
  • Если входным объектом является хроника событий, то схема определяется в инструкции CREATE TABLE, которая создает хронику событий. Она обычно совпадает со схемой приложения. Дополнительные сведения см. в разделе Определение хроники для класса событий.
Определение схемы входного объекта

Выражение на языке Transact-SQL

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

Этот запрос должен выбирать поля подписки и входного объекта из представления, объединяющего данные подписки и события. Поля подписки в представлении имеют имена в виде [Subscription.имя_поля_подписки]. Поля входного объекта (события) имеют имена в виде [Input.имя_поля_cобытия].

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

Шаблон

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

INSERT INTO schema.NotificationClassName(SubscriberId, 
    DeviceName, SubscriberLocale, NotificationFields) 
SELECT [Subscription.SubscriberId], DeviceName, SubscriberLocale, 
    [Input.EventFieldName], ...
FROM schema.RuleName

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

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

Предложение INSERT

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

  • SubscriberId
  • DeviceName
  • SubscriberLocale

Все невычисляемые поля определены в схеме уведомления. При использовании вычисляемых полей не добавляйте к этим полям значения. Эти значения вычисляются при вставке данных уведомления.

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

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

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

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

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

EXECUTE dbo.WeatherConditionActionSP;
Определение выражения на языке Transact-SQL

Написание интерфейсов управления подписками

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

Например, код, который показывает добавление подписки, основанной на условии, см. в разделе Добавление подписки.

См. также

Справочник

Microsoft.SqlServer.NotificationServices.Rules

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

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

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

INSERT (Transact-SQL)
SELECT (Transact-SQL)
Определение классов подписки
Разработка интерфейсов управления подписками

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

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

Журнал изменений

Версия Журнал

17 июля 2006 г.
Измененное содержимое
  • Добавлен раздел об интерфейсах управления подписками.