Subscription Processing Architecture
After events are collected, Notification Services can process subscriptions, generating notifications. Evaluating subscriptions against events is the job of the generator.
To generate notifications, the application developer creates one or more rules for the application. These rules are written as Transact-SQL queries that specify how events and subscriptions relate, as well as any other conditions that must be met to generate a notification.
In a simple application, when the generator fires a rule, the application evaluates all available subscriptions against the current batch of events visible in an event view. When a single event matches a single subscription, the notification generator creates a notification. This notification contains data about the event; it also references data about the subscriber, the subscriber device, sometimes the subscriber locale, and other information required for distribution.
.gif "Basic subscription processing architecture")
The notification is not sent as soon as it is created. Instead, the generator writes the notification to an internal notification table. When a batch of notifications is ready, the notifications are formatted and distributed by the distributor.
If an application supports scheduled subscriptions, when the generator processes the scheduled subscriptions, it sees only subscriptions that are due for evaluation. For example, if the generator runs every 15 minutes, at 8:00 A.M. the generator evaluates all subscriptions that were scheduled between 7:45 A.M. and 8:00 A.M.
If an application uses historical data, the application can store this data along with event and subscription information in a supplemental table, called a chronicle, and can then use this data to produce notifications.
.gif "Subscription processing with chronicles")
The generator runs according to a schedule defined by the quantum duration in the application definition. The quantum determines how often the generator wakes up and fires rules. A short quantum period causes the generator to run more frequently and consume more system resources. A long quantum interval causes a longer delay between the arrival of events and the generation of notifications.
Rule Types
The work of the generator is determined by the rules defined for the application. You can create the following types of rules:
- Event chronicle rules store or update the history of events in chronicle tables defined by the application developer. Each time the generator runs, it fires this type of rule first.
- Event rules generate notifications for event-driven subscriptions. This type of rule runs after the event chronicle rule if an associated batch of events is available. This type of rule can also manage chronicle tables.
- Scheduled rules generate notifications for scheduled subscriptions. This type of rule runs after the event chronicle rule for any related subscriptions that are due to be processed. This type of rule can also manage chronicle tables.
Rule Action Types
Event rules and scheduled rules specify the action to perform when the rule is fired. Each action is a Transact-SQL query that defines a unit of work for the generator to perform. These queries can generate notifications, but can also do other work such as maintaining chronicle data.
Event and scheduled rules can use simple, parameter-based actions or more flexible condition actions:
- Simple actions are Transact-SQL queries that fully define the notification generation query, including all WHERE clauses. Simple actions obtain the WHERE clause expressions from subscription and event data. For example, a weather application might allow subscribers to specify a city for weather notifications. The simple action query would then use a WHERE clause such as
WHERE subscription.city = event.city, joining event and subscription data on city names.
When a rule uses a simple action, subscribers provide parameters for the query, such as the city name. - Condition actions allow subscribers to fully define their query search conditions. For example, you could expose the event data schema in your subscription management interface, and allow subscribers to create their own search conditions over this data, such as
WHERE event.State = Washington AND event.LowTemperature < 0. Your subscription management interface can make writing these search conditions as simple as selecting columns and operators from list boxes and then entering values in text boxes.
Simple actions produce a limited set of search conditions for the generator to evaluate, and therefore typically perform better than condition actions. Condition actions are more powerful, but have the overhead of evaluating more search conditions for the event or scheduled rule.
See Also
Concepts
Specifying the Generator Quantum Duration
Defining Subscription Rules
Event Collection Architecture
Subscription Management Architecture
Notification Formatting and Delivery Architecture