Eventos

La funcionalidad de Eventos en Bruno GMAO permite automatizar acciones sobre activos (Assets) y peticiones (Requests) basándose en condiciones definidas por el usuario. Cada evento puede ejecutar una o varias acciones, como:

• Enviar notificaciones (por email o aviso interno).
• Crear una nueva solicitud (Request) en el sistema.
• Registrar logs de eventos en el historial.

Los eventos se gestionan en la tabla MainPlan_Events y se procesan automáticamente mediante un cron de eventos. Cada evento tiene un tipo definido en EventsTypes, que incluye su categoría (ASSET o REQUEST) y las acciones a ejecutar en formato JSON (ProcessingActions).

Podemos acceder a los tipos de Eventos desde la pagina de configuración. Desde la lista de tipos de evento podemos Habilitar/Deshabilitar la generación de cada tipo de evento o silenciar sus notificaciones.

En la pagina de edición de cada tipo de evento podemos modificar las acciones de procesamiento del tipo de evento:

Flujo de funcionamiento

1. Se registran eventos en la tabla MainPlan_Events con información básica: AssetId o RequestId, fecha de detección y tipo de evento.
2. El cron de eventos lee los eventos pendientes (ProcessingStatus = 'PENDING' y Closed = 0) y los procesa de forma secuencial.
3. Para cada evento, se leen las acciones definidas en el JSON ProcessingActions del tipo de evento.
4. Cada acción se evalúa con su condición (opcional). Solo se ejecuta si la condición devuelve true.
5. Se ejecuta la acción: Notificación, Creación de request o Log.
6. Tras la ejecución, se registra un log en MainPlan_EventLogs y se actualiza el estado del evento a PROCESSED o ERROR según corresponda.

Visualización de Eventos

Si tenemos habilitado el tipo de evento cuando ocurre se visualizará desde la vista del Activo o desde la vista de la Peticiópn en función de la categoría del tipo de evento:

En Activos:

En Peticiones:

En ambos casos se muestra la lista de eventos vinculados al activo o a la petición:

Desde el botón de Log se puede acceder a los datos del log de procesamiento del evento (usuarios avanzados) :

Configuración de los ProcessingActions

Cada tipo de evento puede tener definidas varias acciones en JSON bajo el campo ProcessingActions.

Estructura general

{
  "Actions": [
    {
      "Action": "SEND_NOTIFICATION",
      "Condition": "CriticalityId > 2 AND AssetId IN (SELECT AssetId FROM Assets WHERE AreaId=5)",
      "Notification": {
        "TemplateId": "GMAO_EVENT_ASSET",
        "Channels": ["email", "notice"],
        "Recipients": [
          { "Type": "role", "RoleId": "admins" },
          { "Type": "user", "UserId": 101 },
          { "Type": "email", "Email": "external@example.com" }
        ],
        "Priority": "HIGH"
      }
    },
    {
      "Action": "CREATE_REQUEST",
      
      "Parameters": {
        "RequestType": "PRE",
        "Description": "Evento automático - revisión crítica de activo"
      }
    },
    {
      "Action": "LOG_EVENT",
      "Condition": null,
      "Parameters": {
        "Message": "Evento logueado automáticamente"
      }
    }
  ]
}

Campos de cada acción:

Configuración de Notificación (Notification):

Tipos de Recipients disponibles

Los recipients determinan a qué usuarios o contactos se enviará la notificación. Se pueden combinar varios en la misma acción. El sistema permite tanto destinatarios estándar como específicos de GMAO.

Recipients estándar

• user: un usuario específico del sistema Bruno GMAO, identificado por su UserId.
  Ejemplo:

  { "Type": "user", "UserId": 101 }

• role: todos los usuarios que tengan asignado un rol determinado dentro del sistema.
  Ejemplo:

  { "Type": "role", "RoleId": "Manager" }

• employee: un empleado concreto de la base de datos de empleados, identificado por EmployeeId.
  Ejemplo:

  { "Type": "employee", "EmployeeId": 2001 }

• email: una dirección de correo externa, sin necesidad de que exista como usuario o empleado en el sistema.
  Ejemplo:

  { "Type": "email", "Email": "external@example.com" }

Recipients específicos de GMAO

• asset_contacts: todos los contactos definidos en el activo (Asset) del evento.
• asset_responsible: el usuario o grupo configurado como responsable principal del activo.
• request_contacts: todos los contactos vinculados a la solicitud (Request).
• request_planning_resources: los recursos asignados en la planificación de la solicitud.
• request_labor_resources: los recursos de mano de obra que ya han imputado horas en la solicitud.
• request_assets_contacts: contactos de los activos vinculados a la solicitud.

Ejemplo 1: Notificación a roles, usuarios y correos externos

{
  "Recipients": [
    { "Type": "role", "RoleId": "Manager" },
    { "Type": "user", "UserId": 101 },
    { "Type": "email", "Email": "supervisor@empresa.com" }
  ]
}

Ejemplo 2: Notificación a empleados y recursos de la request

{
  "Recipients": [
    { "Type": "employee", "EmployeeId": 2001 },
    { "Type": "employee", "EmployeeId": 2002 },
    { "Type": "request_planning_resources" },
    { "Type": "request_labor_resources" }
  ]
}

Ejemplo 3: Notificación a contactos de activos

{
  "Recipients": [
    { "Type": "asset_responsible" },
    { "Type": "asset_contacts" },
    { "Type": "request_assets_contacts" }
  ]
}

Condiciones (Condition)

• Categoría ASSET: condiciones sobre Assets.

  CriticalityId > 2 AND AreaId = 5

• Categoría REQUEST: condiciones sobre Requests.

  StatusId = 'ON' AND Priority = 'HIGH'

• Subconsultas soportadas:

  AssetId IN (SELECT AssetId FROM Assets WHERE AreaId=5)

Si la condición devuelve 0 filas, la acción se omite y se registra como Skipped.

Ejemplo completo de JSON

{
  "Actions": [
    {
      "Action": "SEND_NOTIFICATION",
      "Condition": "CriticalityId > 2",
      "Notification": {
        "TemplateId": "GMAO_EVENT_ASSET",
        "Channels": ["email", "notice"],
        "Recipients": [
          { "Type": "role", "RoleId": "Manager" },
          { "Type": "employee", "EmployeeId": 2001 },
          { "Type": "email", "Email": "ops@example.com" },
          { "Type": "request_assets_contacts" }
        ],
        "Priority": "HIGH"
      }
    },
    {
      "Action": "CREATE_REQUEST",
      "Condition": "StatusId='ON' AND Priority='HIGH'",
      "Parameters": {
        "RequestType": "CO",
        "Description": "Evento crítico detectado automáticamente"
      }
    },
    {
      "Action": "LOG_EVENT",
     
    }
  ]
}

Visualizar notificaciones

Si el procesamiento de nuestros eventos tienen notificaciones nos aparecerán en la campanita de la pantalla principal (en caso del canal "notice" o directamente en el mail del recipient correspondiente:

Notice

Si clicamos sobre la notice nos lleva al Activo o a la Petición en función de cada tipo de evento.

Mail

Consideraciones importantes

• La condición se evalúa sobre la tabla correspondiente según la categoría (ASSET → Assets, REQUEST → Requests).
• Las subconsultas deben ser autocontenidas y devolver valores válidos.
• SEND_NOTIFICATION requiere al menos un canal y un destinatario.
• CREATE_REQUEST permite definir parámetros arbitrarios que luego se pasan al proceso de creación.
• Todos los eventos procesados generan un registro en MainPlan_EventLogs con estado ejecutado, omitido o error.
• Las notificaciones pueden enviarse por correo y aviso interno simultáneamente.
• Los proveedores solo recibirán notificaciones si tienen EnabledNotifications = 1.
• Los contactos solo recibirán notificaciones si tienen EnabledNotifications = 1.

Beneficios de la funcionalidad de eventos

• Automatización de procesos repetitivos.
• Mejora en la comunicación interna y externa.
• Disminución de tiempos de reacción.
• Configuración flexible y extensible.

Resumen del flujo de configuración de nuevos eventos

1. Crear un tipo de evento en EventsTypes.
2. Asignar categoría: ASSET o REQUEST.
3. Definir el JSON de ProcessingActions con las acciones deseadas.
4. Registrar eventos en MainPlan_Events (manual o desde otros procesos).
5. Nuevo trigger para generar el nuevo evento.
6. El cron de eventos procesa automáticamente cada evento, evaluando condiciones y ejecutando las acciones configuradas.