アクションの定義
アクションは、Notification Services がサブスクリプション ルールを実行するたびに実行される一連の Transact-SQL ステートメントです。各サブスクリプション ルールには、定義済みのクエリである基本アクションか、または条件アクションを含めることができます。条件アクションを使用すると、通知生成クエリの WHERE 句に相当する条件をサブスクライバが作成できます。ここでは、基本アクションとその作成方法について説明します。
アクション
アクションの Transact-SQL ステートメントは、ルールの作業の一部を実行します。通常、これは、サブスクリプション フィールドとイベント フィールドの結合を基に通知を生成する作業です。次の例は、天気アプリケーションの通知を生成するアクションを示しています。
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 ビューを自動的に作成します。このビューには、ジェネレータによって処理される現在のイベント セットのみが含まれます。
アクションは、このイベント ビューとサブスクリプション テーブルを使用する必要がありません。たとえば、他のデータベースのテーブルにクエリを実行できます。
また、アクションは通知を生成する必要がありません。ただし、少なくとも 1 つのサブスクリプション ルールが、通知を生成するアクションを持つ必要があります。そうでない場合、アプリケーションがサブスクライバに対して通知の生成および送信を実行しなくなります。
Transact-SQL クエリ作成の詳細については、「クエリの基礎」を参照してください。
INSERT ステートメント
メモ : |
---|
INSERT ステートメントは、Notification Services 2.0 で通知の作成に使用された通知関数に代わる機能です。 |
コード例に示すように、INSERT ステートメントの次のフィールドを次の順序で指定する必要があります。
- SubscriberId
- DeviceName
- SubscriberLocale
- 通知スキーマで定義されたすべての非計算フィールド。計算フィールドを使用する場合は、これらのフィールドに値を挿入しないでください。通知データを挿入する際に、これらのフィールドの値が計算されます。
サブスクリプション ルール内でのみ、通知テーブルに追加します。Notification Services は、サブスクリプション ルールを処理する際に、各ルール実行を作成し、これらのルールを起動して、実行後にクリーンアップします。サブスクリプション ルールの実行以外に通知を挿入する場合、ルールの実行の作成およびクリーンアップは発生しません。これによりエラーが発生します。
WHERE 句を使用した追加条件の指定
サブスクリプション スキーマに複数のカスタム フィールドがある場合、WHERE 句を追加して追加条件を指定できます。たとえば、天気アプリケーションでサブスクライバが温度範囲を入力できる場合、上記のコード例に次の句を追加できます。
WHERE e.HighTemp > s.High
OR e.LowTemp < s.Low
この WHERE 句を指定すると、サブスクライバによって入力された範囲をイベントの HighTemp 値が上回った場合、またはサブスクライバによって入力された範囲をイベントの LowTemp 値が下回った場合のみ、アクションが通知を生成するようになります。
メモ : |
---|
アプリケーションを XML ファイルで定義している場合は、"<" などの予約 XML 文字をエンティティ参照に置き換える必要があります。詳細については、「XML の予約文字」を参照してください。 |
その他の句
Transact-SQL の SELECT ステートメントでは、その他多数の句がサポートされます。ただし、大部分の句は Notification Services に関連しません。たとえば、ORDER BY 句を使用すると、SELECT クエリの結果を並べ替えることができますが、この順序が Notification Services による通知の書式設定や配信の方法または時期に影響を与えることはありません。UNION 句を使用すると、2 つのクエリの結果を結合できますが、サブスクリプション ルールではほとんど使用されません。
ストアド プロシージャの使用
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 管理オブジェクト (NMO) を使用してアクションを定義します。
- EventRule の Action 要素 (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 を使用してアクションを定義します。
- ScheduledRule の Action 要素 (ADF)
- Action プロパティ (NMO)
参照
概念
条件アクションの定義
イベント ルールの定義
定期的なルールの定義
その他の技術情報
WHERE (Transact-SQL)
INSERT (Transact-SQL)
SELECT (Transact-SQL)
サブスクリプション クラスの定義