Sistema de Alertas

Este es el módulo más importante en la arquitectura del modelo propuesto (ver figura 3.5.1), representa la “capa intermedia” entre las fuentes de datos y los usuarios. Es el encargado de gestionar todo el proceso de alertas, desde su origen hasta su entrega al usuario final. Dado que es un módulo muy grande, se dividió en sub-módulos, los cuales son descritos a continuación.

Figura 3.5.1.4 Ejemplo de uso de los

3.5.2.1 Gestor de alertas

Este módulo es utilizado principalmente por el administrador del sistema para registrar y relacionar todos los elementos involucrados con el proceso de alertas. Tales elementos van desde el alimentador que provee el servicio de alerta hasta el dispositivo final en donde se visualizará la alerta.

Los suscriptores también hacen uso de este módulo para personalizar sus preferencias de notificación.

A continuación se describen cada uno de los componentes del gestor de alertas: • Administrador de Alimentadores y Servicios de Alerta.

A través de este componente el administrador del sistema da de alta servicios de alerta.

Este módulo lee los conectores genéricos provenientes de un alimentador y almacena su información en el repositorio genérico de alertas.

La idea de contar con un repositorio genérico de alertas surge debido a que los datos de una alerta en un dominio dado no son los mismos en otro dominio, por ejemplo, en el sector energético, los datos de una alerta del área de Generación no son los mismos que los de una alerta del área de Administración y Finanzas.

Por lo anterior, se diseñó un modelo de base de datos flexible para alojar cualquier tipo de alerta, esto se logró haciendo uso de parámetros de alerta (ver la figura 3.5.2.1.1).

Las entidades PARAMETROS_X_SERVICIO y VALORES_X_PARAMETROS son utilizadas para guardar la información que aparece entre las etiquetas <parametros> </ parametros> del documento XMLAlertDesc.

Este diseño, es también aprovechado por el administrador de suscripciones (explicado más adelante) para lograr que los suscriptores almacenen sus preferencias de notificación mediante el ajuste de parámetros de la alerta

En el anexo C puede ver el modelo ER completo del repositorio genérico de alertas, así como el detalle del diccionario de datos.

• Administrador de compuertas de comunicación.

A través de este módulo el administrador del sistema registra la información de las compuertas de comunicación a las que tiene acceso.

Para el sistema de alertas una compuerta de comunicación es una aplicación externa que puede ser accedida a través de una URL. Su finalidad principal es la de enviar alertas en una tecnología de mensajería especifica. Por ejemplo se puede tener una compuerta para enviar alertas como SMS, otra para enviarlas como correo electrónico, otra para MMS, etc.

La información que necesita conocer el sistema de alertas acerca de la compuerta es: con qué URL accederá a la compuerta y el número de mensajes máximos que puede tener en cola.

• Administrador de Dispositivos y Tecnologías de Mensajería soportadas. En este módulo se registran los tipos de dispositivos y Tecnologías de Mensajería (TM) que soporta el sistema de alertas. Los tipos de dispositivos son clasificados por modelo y marca.

Al momento de registrar una TM, opcionalmente se puede anexar una hoja de transformación o Extensible Style Sheet (XSLT,) la cual indica al sistema de alertas cómo transformará el contenido de las alertas para que éste sea compatible con la TM que se está registrando. Por ejemplo si la tecnología de mensajería que se está registrando es “Mensajes de Voz” se puede asociar un documento XSLT que transforme el contenido de la alerta (XMLAlertData) en XMLVoice, el resultado de esa transformación es lo que se enviará la dispositivo del usuario final (ver figura 3.5.2.1.2).

Figura 3.5.2.1.1 Diagrama Entidad Relación asociado al “Administrador de alimentadores y servicios de alertas”.

Figura 3.5.2.1.2 El uso de XSLT para transformar el contenido de las alertas en diversos formatos. Tabla 3.5.2.1.1. Formatos válidos en diversas tecnologías de mensajería

La ventaja de usar una hoja de transformación, brinda la flexibilidad necesaria para convertir el modelo propuesto en una solución extensible con nuevas TM. Por ejemplo, en caso que surja una nueva TM (o una mejora a una TM existente), el administrador sólo deberá registrar o actualizar (según sea el caso) la hoja de transformación asociada a la TM y con ello el sistema de alertas automáticamente se encargará de aplicarla al contenido de las alertas para que de ahí en adelante se envíen según el formato requerido por la nueva tecnología.

Otra de las ventajas de usar XSLT es que las reglas sobre cómo “formatear” el contenido de la alerta no quedan “fijas en el código” o hardcoded, si no que son una serie de instrucciones externas que puede ser actualizadas, reemplazadas o removidas sin afectar el funcionamiento del sistema de alertas. La tabla 3.5.2.1.1 muestra algunos ejemplos de formatos válidos que se pueden asociar a una TM.

Tecnología de Mensajería (TM) Formato compatible

MMS SMIL

Correo electrónico HTML o Texto sin formato

Jabber XMPP

El uso de XSLT fue propuesto para cumplir con los requerimientos RCA-03 y RCM-03. Este módulo también permite asociar una o varias compuertas de comunicación a una TM. Lo anterior es de gran utilidad para distribuir cargas a la hora de despachar mensajes, por ejemplo, si la tecnología de mensajería “SMS” tiene dos compuertas asociadas, la mitad de las alertas pueden ser enviadas por la compuerta uno y el resto por la compuerta dos, o en su defecto, usar sólo la compuerta uno y en caso de que ésta falle (o esté ocupada) usar la compuerta dos.

Para poder almacenar toda la información de este módulo se creó un diseño de base de datos flexible (ver la figura 3.5.2.1.3), el cual tiene como principal objetivo hacer que al gestor de alertas una herramienta extensible ya que permite al administrador anexar tantas TM, compuertas de comunicación y tipos de dispositivos como él lo deseé.

La información almacenada en las entidades asociadas a este módulo, es utilizada más adelante por el módulo despachador, el cual se detalla en la sección 3.5.2.3.

• Administrador de Suscripciones

Este módulo permite al suscriptor modificar sus preferencias de notificación con base a 3 criterios:

1. Periodicidad. Aquí el suscriptor puede indicar un periodo de tiempo mayor