Notificaciones de plataforma y workfows

El siguiente paso en la configuración del modelo operativo de gobierno en Anjana Data consiste en definir las notificaciones que permiten informar a los usuarios sobre eventos, flujos de validación (workflows) o incidencias en la plataforma.

Las notificaciones son un mecanismo clave para garantizar la trazabilidad y la comunicación dentro del gobierno de datos, ya que avisan a los usuarios o a roles completos de acciones como la expiración de un objeto, la creación de un workflow, el fallo en una adherencia, la modificación de políticas o la caducidad de una licencia.

En Anjana Data, las notificaciones se configuran en la tabla Notifications del panel de configuración y estarán disponibles posteriormente en el portal de datos para los usuarios afectados.

Tabla Notifications del Panel de Configuración (Visión administrador)

Las notificaciones se configuran en la tabla Notifications del panel de configuración. La definición de los notificaciones es un paso indispensable para poder configurar los workflows en el BPM y para que los usuarios clave reciban notificaciones de su interés.

Estructura de la tabla Notifications

Cada notificación registrada en la tabla se caracteriza por los siguientes campos:

• id: identificador único de la notificación (PK).

• moduleType: módulo al que aplica la notificación. Actualmente es un campo informativo (legacy) heredado de versiones antiguas. Valores posibles:

  • "BG" → Business Glossary

  • "DC" → Data Catalog

  • "ALL" → aplica a toda la plataforma (opción recomendada).

• notificationCode: código alfanumérico que identifica la notificación y permite invocarla desde las funcionalidades de la plataforma.

• notificationReceiverType: define el tipo de destinatario. Valores posibles:

  • "USER" → la notificación se envía a un usuario específico.

  • "ROLE" → la notificación se envía a todos los usuarios que tengan asignado el rol indicado.

• traslationKey: clave de traducción que enlaza con el texto del mensaje en la tabla Translations. El texto puede contener variables que serán sustituidas en el momento de emisión de la notificación.

• notificationType: tipo de notificación. Valores posibles:

  • "ALERT" → alerta

  • "NOTICE" → aviso

  • "ADMIN_ALERT" → alerta dirigida a administradores

• receiverRole: rol destinatario de la notificación (si el notification_receiver_type es ROLE). Debe coincidir con el name de la tabla Roles.

• severity: nivel de criticidad de la notificación.

• subject: clave de traducción que enlaza con el texto del mensaje en la tabla Translations que contiene el asunto de la notificación.

Códigos de notificación (notificationCode)

Para el correcto funcionamiento de la aplicación, la tabla Notifications debe contener registros que correspondan con una serie de notificationCode predefinidos.

 Variables para las Key de Translations como parte del cuerpo de la notificación

Adicionalmente, los cuerpos de los mensajes de notificación definidos mediante las claves de traducción (campo Key de la tabla de Translations ) pueden contener variables dinámicas delimitadas por ##. Estas variables serán sustituidas automáticamente por los valores correspondientes en el momento de generar y enviar la notificación.

Por ejemplo:

“Ocurrió un error en el borrado del workflow con id #OBJECT_ID#”.

En caso de que una variable se incluya en un mensaje en el que no tenga valor aplicable, será sustituida por N/A.

A continuación se detallan las distintas variables que soporta Anjana Data para su uso en las notificaciones:

 Notificaciones nativas

Anjana Data incorpora de forma nativa una gran cantidad de notificaciones basadas en ROLE para cubrir los principales eventos de gobierno de datos (creación, borrado, expiración, workflows, errores, etc.).

Es responsabilidad del administrador funcional configurar correctamente el campo receiver_role en cada notificación, de modo que los mensajes lleguen a los stakeholders adecuados según el modelo operativo de gobierno definido por la organización.

Una asignación incorrecta o incompleta puede provocar que los usuarios no reciban alertas críticas o, por el contrario, que se sobrecarguen con notificaciones que no les corresponden.

Alta de una nueva Notificación en la tabla Notifications

El alta de una nueva notificación (por ejemplo, una alerta para validar un paso de workflow) implica:

1. Añadir un registro en la tabla Notifications con los datos básicos de la notificación.

2. Configurar las claves de traducción asociadas a la notificación (translationKey y subject) en la tabla Translations, para todos los idiomas que utilice la organización en Anjana Data (tabla Languages).

Para añadir el registro en la tabla Notifications y dar de alta una nueva notificación:

1. Pulsar el botón New en la esquina superior derecha. Esto abrirá un asistente (wizard) con los campos definidos en el apartado Estructura de la tabla Notifications.

2. Completar los campos de la notificación conforme a la estructura descrita en el apartado anterior.

3. Pulsar en Save para guardar el rol o en Cancel para descartar.

Configuración de traducciones para notificaciones

Una vez creada la notificación en la tabla Notifications, es necesario añadir en la tabla Translations los registros correspondientes al cuerpo del mensaje (translationKey) y al asunto (subject) en los distintos idiomas configurados en la aplicación.

El procedimiento es el siguiente:

1. Cuerpo de la notificación (translationKey)

   • Por cada notificación y para cada idioma registrado en la tabla Languages, se debe crear un registro en la tabla Translations.

   • En el campo key se utilizará la translationKey definida en la notificación.

   • En el campo value se incluirá el texto del cuerpo del mensaje en el idioma correspondiente (campo language).

   • El cuerpo del mensaje puede incluir variables dinámicas delimitadas por ## (ejemplo: #OBJECT_ID#).

1. Asunto de la notificación (subject)

   • Por cada notificación y para cada idioma registrado en la tabla Languages, se debe crear un registro adicional en la tabla Translations.

   • En el campo key se utilizará la clave del subject definida en la notificación.

   • En el campo value se incluirá el texto del asunto en el idioma correspondiente (campo language).

Modificación de una Notificación

La modificación del asunto o del cuerpo de una notificación no supone impacto en la configuración, siempre que no se alteren las claves de traducción, es decir, el translationKey o el subject. En este caso, únicamente se debe modificar el contenido del campo value en los registros correspondientes de la tabla Translations.

Por el contrario, si es necesario modificar las claves de traducción (translationKey o subject), se deberán aplicar cambios tanto en la tabla Notifications como en la tabla Translations.

Configuración de las Notificaciones mediante acceso directo a la base de datos (Visión desarrollador)

La tabla de base de datos (BD) que contiene la parametría de los permisos tiene esta estructura:

A continuación se muestra una query de ejemplo para configurar los permisos asociados al rol de DPO:

INSERT INTO hermes.notification
(id_notification, module_type, notification_code, notification_receiver_type, translation_key, notification_type, receiver_role, severity, subject)
VALUES
(1,  'BG', NULL, 'ROLE', 'NOTIFICATION.1.BG.ROLE', 'ALERT', NULL, 'HIGH', 'NOTIFICATION.SUBJECT.ACTION.MUST.BE.VALIDATED'),
(3,  'BG', NULL, 'ROLE', 'NOTIFICATION.3.BG.ROLE', 'NOTICE', NULL, 'LOW',  'NOTIFICATION.SUBJECT.ACTION.PERFORMED'),
(5,  'BG', NULL, 'USER', 'NOTIFICATION.5.BG.USER', 'NOTICE', NULL, 'LOW',  'NOTIFICATION.SUBJECT.ACTION.PERFORMED'),
(6,  'BG', NULL, 'ROLE', 'NOTIFICATION.1.BG.ROLE', 'ALERT', NULL, 'HIGH',  'NOTIFICATION.SUBJECT.ACTION.MUST.BE.VALIDATED'),
(7,  'DC', NULL, 'ROLE', 'NOTIFICATION.7.DC.USER', 'ALERT', NULL, 'HIGH',  'NOTIFICATION.SUBJECT.ACTION.MUST.BE.VALIDATED'),
(8,  'DC', NULL, 'USER', 'NOTIFICATION.8.DC.USER', 'NOTICE', NULL, 'LOW',  'NOTIFICATION.SUBJECT.ACTION.PERFORMED'),
(9,  'DC', NULL, 'USER', 'NOTIFICATION.ACTION.REJECTED.WITH.REASON', 'NOTICE', NULL, 'LOW', 'NOTIFICATION.SUBJECT.ACTION.REJECTED.WITH.REASON'),
(10, 'DC', NULL, 'ROLE', 'NOTIFICATION.10.DC.ROLE', 'NOTICE', NULL, 'LOW',  'NOTIFICATION.SUBJECT.ACTION.APPROVED'),
(11, 'DC', NULL, 'ROLE', 'NOTIFICATION.11.DC.ROLE', 'NOTICE', NULL, 'LOW',  'NOTIFICATION.SUBJECT.ACTION.REJECTED'),
(12, 'BG', 'NEW_DSA', 'ROLE', 'NOTIFICATION.NEW_DSA', 'NOTICE', 'data_architect', 'LOW', 'NOTIFICATION.SUBJECT.NEW.DSA'),
(13, 'BG', 'EXPIRATION', 'USER', 'NOTIFICATION.EXPIRATION', 'NOTICE', NULL, 'LOW', 'NOTIFICATION.SUBJECT.EXPIRATION'),
(14, 'DC', 'ERROR_AUTOMATIC_METADATA', 'ROLE', 'NOTIFICATION.AUTOMATIC_METADATA', 'NOTICE', 'DataSteward', 'LOW', 'NOTIFICATION.SUBJECT.METADATA'),
(15, 'DC', 'DATASET_FAIL', 'ROLE', 'NOTIFICATION.DATASET_FAIL', 'ADMIN_ALERT', 'DataOwner', 'HIGH', 'NOTIFICATION.SUBJECT.CREATION.FAIL.DATASET'),
(16, 'DC', 'DSA_FAIL', 'ROLE', 'NOTIFICATION.DSA_FAIL', 'ADMIN_ALERT', 'DataOwner', 'HIGH', 'NOTIFICATION.SUBJECT.CREATION.FAIL.DSA');