Architektur der Abonnementverarbeitung

Sobald Ereignisse gesammelt werden, kann Notification Services Abonnements verarbeiten und Benachrichtigungen generieren. Das Bewerten von Abonnements anhand von Ereignissen ist Aufgabe des Generators.

Zum Generieren von Benachrichtigungen erstellt der Anwendungsentwickler für die Anwendung eine oder mehrere Regeln. Diese Regeln werden als Transact-SQL-Abfragen geschrieben, die angeben, wie Ereignisse und Abonnements verbunden sind und welche anderen Bedingungen erfüllt werden müssen, um eine Benachrichtigung zu generieren.

Wenn der Generator in einer einfachen Anwendung eine Regel auslöst, bewertet die Anwendung alle verfügbaren Anwendungen anhand des aktuellen Batches in einer Ereignissicht sichtbarer Ereignisse. Wenn ein einzelnes Ereignis mit einem einzelnen Abonnement übereinstimmt, erstellt der Benachrichtigungsgenerator eine Benachrichtung. Die Benachrichtigung enthält Daten zum Ereignis sowie Verweise auf Daten über den Abonnenten, das Gerät des Abonnenten, manchmal das Abonnentengebietsschema und andere für die Verteilung erforderliche Informationen.

Die Benachrichtigung wird nicht unmittelbar nach ihrer Erstellung gesendet. Stattdessen schreibt der Generator die Benachrichtigung in eine interne Benachrichtigungstabelle. Wenn ein Benachrichtigungsbatch fertig gestellt wurde, werden die Benachrichtigungen formatiert und vom Verteiler verteilt.

Wenn eine Anwendung geplante Abonnements unterstützt und der Generator die geplanten Abonnements verarbeitet, werden nur Abonnements berücksichtigt, deren Auswertung fällig ist. Wird der Generator z. B. alle 15 Minuten ausgeführt, bewertet der Generator um 8:00 Uhr alle Abonnements, die zwischen 7:45 und 8:00 Uhr geplant wurden.

Verwendet eine Anwendung Vergangenheitsdaten, kann die Anwendung diese Daten zusammen mit Ereignis- und Abonnementinformationen in einer zusätzlichen Tabelle, dem so genannten Verlauf, speichern und diese Daten dann verwenden, um Benachrichtigungen zu erstellen.

Der Generator wird nach einem Zeitplan ausgeführt, der durch die Quantumdauer in der Anwendungsdefinition definiert wird. Das Quantum bestimmt, wie häufig der Generator aktiviert wird und Regeln auslöst. Eine kurze Quantumdauer sorgt dafür, dass der Generator häufiger ausgeführt wird und mehr Systemressourcen verbraucht. Ein langes Quantumintervall sorgt für eine längere Verzögerung zwischen dem Eintreffen von Ereignissen und der Generierung von Benachrichtigungen.

Regeltypen

Die Arbeit des Generators wird von den für die Anwendung definierten Regeln bestimmt. Sie können die folgenden Regeltypen erstellen:

• Ereignisverlaufsregeln speichern oder aktualisieren den Verlauf von Ereignissen in Verlaufstabellen, die vom Anwendungsentwickler definiert werden. Jedes Mal, wenn der Generator ausgeführt wird, löst er zunächst diesen Regeltyp aus.
• Ereignisregeln generieren Benachrichtigungen für ereignisgesteuerte Abonnements. Dieser Regeltyp wird nach der Ereignisverlaufsregel ausgelöst, wenn ein zugeordneter Ereignisbatch verfügbar ist. Diese Art von Regel kann auch Verlaufstabellen verwalten.
• Geplante Regeln generieren Benachrichtigungen für geplante Abonnements. Dieser Regeltyp wird nach der Ereignisverlaufsregel für alle entsprechenden Abonnements ausgeführt, die verarbeitet werden müssen. Diese Art von Regel kann auch Verlaufstabellen verwalten.

Regelaktionstypen

Ereignisregeln und geplante Regeln geben die Aktion an, die ausgeführt werden soll, wenn die Regel ausgelöst wird. Jede Aktion ist eine Transact-SQL-Abfrage, die eine vom Generator auszuführende Arbeitseinheit definiert. Diese Abfragen können Benachrichtigungen generieren, können aber auch andere Aufgaben wie das Verwalten von Verlaufsdaten ausführen.

Ereignisregeln und geplante Regeln können einfache parameterbasierte Aktionen oder flexiblere Bedingungsaktionen verwenden:

• Einfache Aktionen sind Transact-SQL-Abfragen, die die Benachrichtigungsgenerierungsabfrage vollständig definieren, einschließlich aller WHERE-Klauseln. Einfache Aktionen rufen die WHERE-Klauselausdrücke aus Abonnement- und Ereignisdaten ab. Eine Wetteranwendung beispielsweise kann Abonnenten ermöglichen, eine Stadt für Wetterbenachrichtigungen anzugeben. Die einfache Aktionsabfrage verwendet dann eine WHERE-Klausel, wie WHERE subscription.city = event.city, die Ereignis- und Abonnementdaten für Städtenamen verknüpft.
  Wenn eine Regel eine einfache Aktion verwendet, stellen Abonnenten Parameter für die Abfrage bereit, beispielsweise den Städtenamen.
• Bedingungsaktionen ermöglichen Abonnenten, ihre Abfragesuchbedingungen vollständig zu definieren. Sie können beispielsweise das Ereignisdatenschema auf der Schnittstelle der Abonnementverwaltung verfügbar machen und es den Abonnenten ermöglichen, eigene Suchbedingungen für diese Daten zu erstellen, wie z. B. WHERE event.State = Washington AND event.LowTemperature < 0. Die Schnittstelle der Abonnementverwaltung kann das Schreiben dieser Suchbedingungen vereinfachen, sodass lediglich Spalten und Operatoren aus Listenfeldern ausgewählt und dann Werte in Textfelder eingegeben werden müssen.

Einfache Aktionen erzeugen einen begrenzten Satz von durch den Generator zu bewertenden Suchbedingungen und können daher normalerweise besser ausgeführt werden als Bedingungsaktionen. Bedingungsaktionen sind leistungsstärker, es müssen jedoch mehr Suchbedingungen für die Ereignisregel oder geplante Regel bewertet werden.

Siehe auch

Konzepte

Angeben der Generatorquantumdauer
Definieren von Abonnementregeln
Architektur der Ereignisauflistung
Architektur der Abonnementverwaltung
Formatieren von Benachrichtigungen und Architektur der Übermittlung

Hilfe und Informationen

Informationsquellen für SQL Server 2005