Arquitectura de procesamiento de suscripciones

Una vez obtenidos los eventos, Notification Services ya puede procesar las suscripciones y generar notificaciones. La función del generador es evaluar las suscripciones según los eventos.

Para generar notificaciones, el programador de la aplicación crea una o varias reglas para la aplicación. Estas reglas se escriben como consultas Transact-SQL que especifican cómo se relacionan los eventos y las suscripciones, así como cualquier otra condición que deba cumplirse para generar una notificación.

En una aplicación sencilla, cuando el generador activa una regla, la aplicación evalúa todas las suscripciones disponibles y las compara con el lote actual de eventos visible desde una vista de eventos. Cuando un evento coincide con una suscripción, el generador de notificaciones crea una notificación. Esta notificación contiene datos acerca del evento. También hace referencia a datos del suscriptor, del dispositivo del suscriptor y, en ocasiones, a la configuración local del suscriptor, además de otra información necesaria para la distribución.

La notificación no se envía nada más crearla. En su lugar, el generador escribe la notificación en una tabla de notificaciones interna. Cuando un lote de notificaciones está preparado, el distribuidor aplica formato a las notificaciones y las distribuye.

Si una aplicación admite suscripciones programadas, cuando el generador procesa estas suscripciones, sólo ve las que deben evaluarse. Por ejemplo, si el generador se ejecuta cada 15 minutos, a las 8:00 a.m. el generador evalúa todas las suscripciones programadas entre las 7:45 a.m. y las 8:00 a.m.

Si una aplicación utiliza datos históricos, podrá almacenarlos junto con información del evento y de suscripción en una tabla complementaria denominada crónica y utilizar estos datos para generar notificaciones.

El generador se ejecuta según una programación definida por el período de tiempo del cuanto en el archivo de definición de la aplicación. El cuanto determina la frecuencia con la que el generador activa reglas. Un período de cuanto corto provoca que el generador se ejecute con más frecuencia y consuma más recursos del sistema. Un intervalo de cuanto largo provoca un retardo mayor entre la llegada de los eventos y la generación de las notificaciones.

Tipos de regla

Las reglas definidas en la aplicación controlan el funcionamiento del generador. Puede crear los siguientes tipos de reglas:

• Las reglas de crónica de eventos almacenan o actualizan el historial de eventos en tablas de crónica definidas por el programador de la aplicación. Cada vez que se ejecuta el generador, activa este tipo de regla en primer lugar.
• Las reglas de evento generan notificaciones para las suscripciones por eventos. Este tipo de regla se ejecuta después de la regla de crónica de eventos si se encuentra disponible un lote de eventos asociado. Este tipo de regla también puede administrar tablas de crónica.
• Las reglas programadas generan notificaciones de suscripciones programadas. Este tipo de regla se ejecuta después de la regla de crónica de eventos para cualquier suscripción relacionada que deba procesarse. Este tipo de regla también puede administrar tablas de crónica.

Tipos de acción de regla

Las reglas de evento y programadas especifican la acción que debe ejecutarse al desencadenarse la regla. Cada acción es una consulta Transact-SQL que define una unidad de trabajo que debe realizar el generador. Estas consultas pueden generar notificaciones, pero también pueden realizar otras tareas como mantener los datos de la crónica.

Las reglas de evento y programadas utilizan tanto acciones simples basadas en parámetros como acciones de condición más flexibles:

• Las acciones simples son consultas Transact-SQL que definen por completo la consulta de generación de notificación, incluidas las cláusulas WHERE. Las acciones simples obtienen las expresiones de la cláusula WHERE de los datos de suscripción y los datos de evento. Por ejemplo, una aplicación meteorológica puede permitir a los suscriptores que especifiquen una ciudad para generar las notificaciones meteorológicas. En este caso, la consulta de acción simple utilizaría una cláusula WHERE, como WHERE subscription.city = event.city, que combina los datos de evento y de suscripción en los nombres de ciudad.
  Cuando una regla utiliza una acción simple, los suscriptores proporcionan parámetros para la consulta tales como el nombre de la ciudad.
• Las acciones de condición permiten a los suscriptores definir por completo las condiciones para la búsqueda de la consulta. Por ejemplo, podría exponer el esquema de datos de eventos en la interfaz de administración de suscripciones y permitir que los suscriptores crearan sus propias condiciones de búsqueda a partir de estos datos, como WHERE event.State = Washington AND event.LowTemperature < 0. La interfaz de administración de suscripciones simplifica la escritura de las condiciones de búsqueda hasta tal punto que basta con seleccionar columnas y operadores de los cuadros de lista y especificar los valores en los cuadros de texto.

Las acciones simples generan un conjunto limitado de condiciones de búsqueda que debe evaluar el generador, por lo que su rendimiento suele ser mejor que el de las acciones de condición. Las acciones de condición, por su parte, son más eficaces, pero deben evaluar más condiciones de búsqueda para la regla de evento o regla programada.

Vea también

Conceptos

Especificar la duración de cuantos del generador
Definir reglas de suscripción
Arquitectura de recopilación de eventos
Arquitectura de administración de suscripciones
Arquitectura de entrega y formato de notificaciones

Ayuda e información

Obtener ayuda sobre SQL Server 2005