次の方法で共有

条件アクションの定義

  • [アーティクル]

更新 : 2006 年 7 月 17 日

アクションは、Notification Services がサブスクリプション ルールを実行するたびに実行される一連の Transact-SQL ステートメントです。各サブスクリプション ルールには、定義済みのクエリである基本アクションか、または条件アクションを含めることができます。条件アクションを使用すると、通知生成クエリの WHERE 句に相当する条件をサブスクライバが作成できます。ここでは、条件アクションとその作成方法について説明します。

ms172509.note(ja-jp,SQL.90).gif重要 :
通知を生成するための独自の複雑な条件をサブスクライバが作成できるようにする必要がある場合にのみ、条件アクションを使用します。それ以外の場合は、ユーザーがパラメータ化クエリに値を入力できるようになっている、定義済みのアクションを使用します。この方がより効率的です。詳細については、「アクションの定義」を参照してください。

条件アクション

条件アクションでは、サブスクライバによって作成された柔軟なルールを使用できます。定義済みのアクションは、開発者が定義したクエリのパラメータ値をサブスクライバだけが指定できるようにします。一方、条件アクションは、ブール演算子 (AND、OR および NOT) を使用して個別の条件を組み合わせることにより、クエリの WHERE 句に相当する条件をサブスクライバが作成できるようにします。

たとえば、天気予報アプリケーションに City と Forecast という 2 つのフィールドを含むイベント クラスがあるとします。開発者は、次のように、通知を作成するための基本的なクエリを定義することができます。

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" を含む、という 2 つの条件を指定し、AND 演算子でこれらの条件を結合することができます。これは、次の WHERE 句に相当します。

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

Notification Services がサブスクリプション ルールを実行するときは、すべての類似の条件がまとめて処理されます。これによりパフォーマンスが向上します。Notification Services は、一致する入力とサブスクリプションの組を使用してルールのビューを作成します。

パフォーマンスに関する注意点

Notification Services がすべての類似の条件をまとめて処理する場合でも、条件アクションを使用するときはオーバーヘッドが発生します。Notification Services は、すべての条件のセットを取得し、それらの条件を、効率的に評価できるように整理し、評価したうえで、すべてのサブスクリプションに対する結果の通知を作成する必要があります。このオーバーヘッドのため、通常、定義済みのアクションの評価よりも、条件アクションを使用するルールの評価のほうが時間がかかります。

セキュリティ

すべての条件アクションは、条件アクションに対して指定したデータベース ユーザーのコンテキストで実行されます。ユーザー権限を低くしておけば、サブスクリプション管理インターフェイスが何者かに侵害され、他のテーブルへのアクセスまたは他のアクションの実行を試みる条件が挿入された場合でも、セキュリティに対する脅威が最小限に抑えられます。

データベース ユーザーに対しては、イベント ソースからデータを選択すること、および、条件によって使用されるユーザー定義関数を実行することだけを許可するように権限を制限しておく必要があります。

Notification Services がアプリケーション データベース内でアプリケーション オブジェクトを作成するときに、このユーザーに関連付けられている SQL Server ログイン アカウントが存在している必要があります。

トランザクション

条件アクションのステートメントはすべて、同じトランザクションの一部となるため、それらはすべてが正常に完了するか、すべてがロールバックされるかのどちらかになります。トランザクションが失敗すると、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
データベース ユーザーを定義するには

入力名

条件アクションを使用する際は、どのビューまたはテーブルにイベント データを格納するかを指定する必要があります。

  • 条件アクションがイベント ルールに含まれている場合は、通常、入力はイベント クラスと同じ名前を持つイベント ビューになります。
    注意   入力にはイベント テーブル NSEventClassNameEvents は使用しないでください。このテーブルには、システムから削除されていないすべてのイベントが格納されているため、通知が重複する原因になります。
  • 条件アクションが定期的なルールに対するものである場合は、通常、入力はイベント記録になります。
    注意   定期的なルールに対しては、入力にイベント ビュー EventClassName を使用しないでください。このビューには現在のイベント バッチしか含まれていないため、入力が空または不完全になることがよくあります。
入力名を定義するには

入力スキーマ

入力スキーマは、入力のデータベース スキーマ名です。

  • 入力がイベント ビューである場合は、スキーマはアプリケーション スキーマになります。アプリケーション スキーマは、アプリケーション データベースを定義するときに定義できます。または、dbo の既定値にすることもできます。詳細については、「アプリケーション データベースの定義」を参照してください。
  • 入力がイベント記録である場合、スキーマは、イベント記録を作成する CREATE TABLE ステートメントの中で定義されます。通常、これはアプリケーション スキーマと同じものになります。詳細については、「イベント クラスの記録の定義」を参照してください。
入力スキーマを定義するには

Transact-SQL 式

各記録アクションは、通知を生成するために使用する主要なクエリを指定します。サブスクリプション フィールドと入力フィールドを選択し、それらを通知テーブルに追加するクエリは、このクエリによって指定されます。

このクエリでは、サブスクリプション データとイベント データを結合するビューからサブスクリプション フィールドと入力フィールドを選択する必要があります。ビュー内のサブスクリプション フィールドには、[Subscription.SubscriptionFieldName] という形式で名前が付いています。入力 (イベント) フィールドには、[Input.EventFieldName] という形式で名前が付いています。

サブスクライバは、サブスクリプション管理インターフェイスを介して、クエリの 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」などのリテラル値を指定できます。

このクエリには他のステートメントを含めることができますが、通知を生成する必要はありません。このクエリは、記録の保持など、任意の必要な作業を実行できます。ただし、少なくとも 1 つのサブスクリプション ルールが通知を生成する必要があります。そうでない場合、アプリケーションはサブスクライバに対して通知の生成および配信を実行しなくなります。

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 の参考資料の入手

変更履歴

リリース 履歴

2006 年 7 月 17 日
変更内容 :
  • サブスクリプション管理インターフェイスに関するセクションを追加しました。