Help Desk y tickets

Una alerta por correo avisa a una persona. Un ticket entra en la cola del equipo que resuelve, con número, plazo e historial. El CMS abre ese ticket solo cuando se dispara una alerta, en la herramienta de atención que la empresa ya usa — y también deja que cualquier persona autorizada abra uno a partir de un mensaje con error, ya completado con el contexto de la integración.

El CMS solo abre el ticket. No lo comenta, no lo cierra y no lo vuelve a leer: el ciclo de vida pertenece a la herramienta de atención. El número del ticket queda guardado en el CMS, junto al mensaje que lo abrió.

Cómo encajan las piezas

Son tres registros, hechos en este orden:

1. La herramienta — en Configuración › Parámetros › Help Desk. Activarla crea todo lo que el envío necesita: la Aplicación de la herramienta, la Interfaz, la Entrega, el Transformador y la Credencial.
2. El destino — en Config. de Integración › Configuración ITSM. Es el para quién dentro de la herramienta: el grupo de atención, la categoría, la urgencia. Una misma herramienta suele tener varios destinos, uno por área.
3. La alerta — en Alertas, el campo Abrir ticket en elige los destinos de cada configuración de alerta.

Por debajo, abrir un ticket es entregar un mensaje: el CMS arma el cuerpo, lo coloca en la Entrega de la herramienta y el mensaje sigue el camino de cualquier otro — intentos, log, pantalla de Mensajes. No existe un conector especial por herramienta, y por eso el mensaje del ticket aparece en Mensajes como prueba de que salió.

Herramientas soportadas

Cada herramienta trae, en el popup de activación, los requisitos previos de su lado — el rol itil en ServiceNow, la API habilitada en GLPI, el API token en lugar de la contraseña en Jira. Vale la pena leerlos antes de completar: la mayor parte de las fallas de primera configuración está ahí.

1. Activar la herramienta

Configuración › Parámetros › pestaña Help Desk.

El botón Activar abre el catálogo. Cada herramienta aparece con una descripción de lo que abre, y al elegir una el popup pide:

El bloque Lo que crea la activación muestra, antes de confirmar, la Interfaz y la Entrega que van a existir. La elección entre Canal y Cola merece atención:

• Canal (recomendado): un ticket rechazado por la herramienta no retiene los siguientes. Los tickets no tienen orden entre sí, así que es el comportamiento correcto en la mayoría de los casos.
• Cola: un ticket a la vez, en orden de llegada. Si uno es rechazado, los siguientes esperan hasta que alguien desbloquee la Interfaz — justo en el momento en que la herramienta tiene problemas.

Los nombres creados están en inglés y derivan de la sigla: la Interfaz GLPI_TICKET, la Entrega GLPI_TICKET_OPEN, el Transformador “GLPI GLPI - ticket body” y la Credencial “GLPI — CMS integration”. El inglés es el estándar para todo lo que graba la activación; los textos de las pantallas siguen en el idioma de cada usuario.

La misma herramienta se puede activar más de una vez — un GLPI de producción y uno de homologación, por ejemplo. Cada activación es una Aplicación propia, con su sigla, y por eso con sus propios nombres (GLPIQA_TICKET, GLPIQA_TICKET_OPEN). Si alguno de los nombres ya existe, la activación se rechaza e indica cuál: nunca reutiliza la Interfaz o la Entrega de otra activación.

La Interfaz y la Entrega vienen del pack de la herramienta, y solo la activación instala ese pack. Los packs de apertura de tickets no aparecen en el asistente de packs de las Aplicaciones: instalados en una Aplicación de la planta, se volverían una Entrega de ticket suelta, sin Destino y fuera de este catálogo.

SAP PM

SAP PM es distinto de las demás herramientas: no crea Aplicación. La activación pide la Aplicación SAP donde se abrirán los avisos — el combo solo lista Aplicaciones del tipo SAP RFC/BAPI —, y esa elección se puede cambiar después, en la edición. También se puede activar SAP PM más de una vez, una por Aplicación SAP.

En lugar de “Lo que crea la activación”, la pantalla muestra la Entrega que abre el aviso en esa Aplicación: la Entrega SAP RFC que llama a BAPI_ALM_NOTIF_CREATE, encontrada por la función (la sigla puede ser cualquiera). El pack SAP PM trae esa Entrega lista. Para que el aviso exista de verdad, tres cosas deben estar en ella:

1. BAPI_ALM_NOTIF_SAVE en “Llamar a continuación, en la misma sesión”. La BAPI de crear solo guarda el aviso en la memoria de la sesión RFC; sin la grabación en la misma sesión, el aviso desaparece cuando se cierra la conexión. Ver llamadas siguientes.
2. Commit activado — el BAPI_TRANSACTION_COMMIT, en la misma sesión.
3. El programador de la Interfaz activado, en Programadores. Desactivado, el aviso entra en la cola y queda detenido, y el “Abrir ticket” muestra “Esperando” para siempre.

La activación y Probar conexión verifican las tres y dicen qué falta — la activación se rechaza mientras falte alguna.

La grilla

En las acciones de la fila están Detalles (Aplicación, Interfaz, Entrega y Credencial creadas), el Modelo de cuerpo — verde cuando la herramienta ya tiene uno registrado — y la edición, donde vive Probar conexión.

Desactivar una herramienta solo impide tickets nuevos. Destinos, Interfaz, Entrega y el historial de tickets quedan intactos, y reactivarla devuelve todo como estaba.

Probar conexión

El botón, en la edición de la herramienta, hace una lectura real en ella — sin abrir ticket — con la Credencial de la Entrega. El resultado tiene tres estados:

• Verde: la herramienta aceptó la credencial y la lectura.
• Rojo: con el motivo. 401 es usuario o contraseña rechazados; 403 es credencial aceptada sin el permiso que la apertura exige, y la pantalla dice cuál (el rol itil en ServiceNow, el acceso a la API en el perfil de GLPI).
• Aviso: la herramienta no tiene, en el CMS, una lectura que confirme la credencial (es el caso de InvGate). La prueba pasa con la nota “no verificada” — es el primer ticket el que lo confirma.

En SAP PM la prueba es otra: verifica la Entrega que abre el aviso, la grabación en la misma sesión, el commit y el programador de la Interfaz — ver SAP PM.

Modelo de cuerpo

Cada herramienta tiene un modelo de cuerpo: el JSON (o XML) del ticket en el formato que esa API espera, con los campos de la alerta en lugar de los valores. Se edita aquí, con el panel de campos junto al editor, y cumple dos papeles:

• Es el punto de partida de todo destino nuevo de esta herramienta — salvo en SAP PM, donde el cuerpo nace de los campos de la Definición de Entrega.
• Es el cuerpo enviado por un destino que no tiene cuerpo propio.

El editor abre con un ejemplo de la herramienta solo como punto de partida — Usar el modelo original de la herramienta lo restaura. El ejemplo nunca se envía por sí solo: sin modelo guardado y sin cuerpo en el destino, el ticket no sale, y el historial registra la falla.

2. Configurar el destino — /ticket-destinations

Config. de Integración › Configuración ITSM.

Un destino responde a dónde, dentro de la herramienta, va el ticket. El caso típico es el mismo GLPI con un destino para Mantenimiento Eléctrico y otro para TI — cambian el grupo, la categoría y la urgencia.

La grilla agrupa los destinos por herramienta: el encabezado de cada grupo muestra el Help Desk, el sello de conexión (que abre los detalles) y cuántas configuraciones tiene. Cada fila es una configuración, en una sola línea:

La flecha al comienzo de la fila abre el detalle: cada Aplicación con su conexión, sus propios motivos, si usa el cuerpo predeterminado o un cuerpo propio y cuándo abrió el último ticket. Ahí se responde “¿por qué motivo el MES abre ticket?” — la columna de la fila junta los motivos de todas las Aplicaciones y no dice cuál es de cuál.

Los filtros de Aplicación, Interfaz, Definición y Motivo valen por Aplicación: “MES + Aplicación Offline” solo muestra el destino si el propio MES abre ticket por Offline. Con alguno activo, las filas ya abren con el detalle, y las Aplicaciones fuera del filtro aparecen atenuadas al final — el destino sigue sirviéndoles, y quien va a modificarlo necesita verlo. La búsqueda por texto también encuentra el motivo por el nombre (“offline”).

En la columna de acciones quedan Tickets abiertos, editar y eliminar.

El formulario

Herramienta, Nombre y Entrega son obligatorios, y el error aparece en el propio campo. Guardar no cierra el formulario: la pantalla confirma que guardó y pregunta si desea seguir editando o cerrar.

El cuerpo. Un destino nuevo abre con el modelo de la pestaña Help Desk. Al editar un destino, el editor muestra el cuerpo que se guardó — el modelo solo vuelve con el botón Usar el modelo de la pestaña Help Desk, que pide confirmación cuando ya hay texto en el editor. Nada se graba hasta Guardar.

En SAP PM la base es otra. El aviso no pasa por Transformador: la Entrega recibe el JSON con sus propios campos de entrada (descricao, equipamento, localInstalacao, prioridade…). Por eso el cuerpo abre con los campos de la Definición de Entrega elegida y acompaña el cambio de Definición — una Aplicación SAP tiene varias Entregas, cada una con sus campos. Complete los valores con los campos de la alerta; el botón Usar los campos de la Definición de Entrega los trae de vuelta. Un modelo registrado en la pestaña Help Desk sigue disponible con su propio botón.

Cuerpo por Aplicación

El mismo destino suele servir a varias Aplicaciones, y el cuerpo no siempre es igual — el equipo de SAP PM, el CI de ServiceNow. Encima del editor están las pestañas Predeterminado y una por Aplicación: el cuerpo de una Aplicación vale para las alertas de ella, y las demás usan el Predeterminado. En el combo de nueva pestaña, las Aplicaciones que ya usan el destino vienen primero.

En la pestaña de una Aplicación, el panel lateral muestra también las Variables de esa Aplicación, además de los campos de la alerta. Borrar la pestaña devuelve la Aplicación al Predeterminado.

Hacer clic en un campo del panel lateral escribe el {{campo}} donde está el cursor. El panel tiene la misma altura que el editor y se desplaza por dentro cuando hay muchas variables.

Tres reglas valen para el cuerpo:

• Escriba los campos dentro de las comillas: "name": "{{alertaMensagem}}". El valor entra escapado para el formato de la Entrega (JSON o XML) — una comilla o un salto de línea en el mensaje de la alerta no rompe el ticket.
• El JSON se verifica al guardar, con los campos reemplazados por un valor neutro. Una coma de más aparece ahora, y no en el primer ticket.
• Las Variables valen en los valores: {{SNOW_GRUPO}} de una Variable Global, o de una Variable de Aplicación con el mismo nombre, resuelta contra la Aplicación que disparó la alerta. Así es como el mismo destino lleva el CI correcto para cada Aplicación.

Un cuerpo mínimo para GLPI:

{
  "input": {
    "name": "{{alertaMensagem}}",
    "content": "{{alertaDetalhe}}\n\nAplicación: {{aplicacao}} | Tipo: {{alertaTipo}}\nError: {{alertaErro}}",
    "urgency": 4,
    "type": 1
  }
}

Los campos del cuerpo

El Transformador opcional

Sin Transformador, el cuerpo sale tal cual — es el camino normal. El Transformador sirve cuando el ticket necesita reglas: urgencia según el tipo de alerta, grupo según el texto del error. Recibe el cuerpo con los campos ya resueltos y devuelve el cuerpo final.

El combo lista los Transformadores Globales y los que tienen alcance en esta Entrega. El de la propia Entrega (instalado por el pack de la herramienta) viene primero, y espera otro formato: los campos del contrato (titulo, descricao, urgencia…), no el JSON de la herramienta. Al elegirlo, la pantalla dice qué campos espera y ofrece Usar el formato de entrada de este Transformador, que reescribe el cuerpo en ese formato — con confirmación, como el botón del modelo. Los Transformadores de otras herramientas de tickets no aparecen.

Tickets abiertos

El ícono de historial abre los últimos 50 tickets del destino, en una grilla paginada, con búsqueda por número de ticket. Cada fila trae fecha, número, origen (la alerta, o “Apertura manual por” quien lo abrió) y la situación:

El ícono de mensaje abre el resumen del mensaje, el mismo popup de Mensajes, con el cuerpo enviado y la respuesta de la herramienta.

3. Vincular el destino a la alerta

En la configuración de alerta, en Alertas, el campo Abrir ticket en lista los destinos, cada uno con el ícono, la sigla y la descripción de la herramienta — para que quede claro en qué sistema se abrirá el ticket. Una alerta puede abrir tickets en más de un destino a la vez (un ticket en TI y un aviso en SAP PM, por ejemplo).

Para Aplicación Offline aparece también Solo abrir ticket después de (minutos), con 5 por defecto: el correo sale de inmediato, y el ticket solo si la Aplicación sigue caída después de ese tiempo. Una oscilación de red de segundos no se convierte en ticket en la cola de soporte. Cero lo abre junto con la alerta.

Las reglas del disparo

• Un ticket a la vez. Abierto un ticket para un par (configuración de alerta, destino), el mismo problema no abre otro. El bloqueo se libera cuando llega la alerta de recuperación — Aplicación Online o Interfaz Desbloqueada —, y un problema nuevo después de eso abre un ticket nuevo.
• Condición Cumplida es por ocurrencia. La alerta de condición ya se dispara una sola vez por cruce — y, separada por clave, una vez por equipo. Por eso no usa el bloqueo de arriba: con él, el aviso del horno 2 esperaría a que se normalizara el del horno 1.
• La recuperación no abre ticket. La alerta de vuelta solo libera el bloqueo; quien cierra el ticket es el equipo, en la herramienta.
• La herramienta no se pide auxilio a sí misma. Si la alerta es sobre la propia herramienta (ServiceNow se cayó), abrir un ticket en ella no tendría sentido: el disparo se registra como Ignorado, y el aviso sale por correo aunque la configuración no tenga el correo marcado.
• Un destino no retiene a los demás. Si un destino falla, los demás de la misma alerta abren normalmente.

Abrir un ticket en el momento

No todo problema empieza en una alerta. Quien ve algo mal puede abrir el ticket directamente.

A partir de un mensaje con error

En un mensaje con Error de Entrega, Error de Negocio o Error de Recolección, el botón Abrir ticket aparece junto a PDF, Enviar por correo y Reenviar — en el popup del mensaje en Mensajes y en la pantalla de detalle. Solo aparece para quien tiene la Herramienta Abrir Ticket en el perfil y cuando existe al menos un destino activo. Un mensaje que es él mismo un ticket no ofrece el botón.

Ahí es donde la apertura manual tiene sentido: un formulario en blanco cualquiera lo completa directo en la herramienta de atención; lo que el CMS agrega es el contexto de la integración. Por eso el popup ya viene completado — y todo sigue siendo editable:

Los campos del destino tienen en cuenta el cuerpo por Aplicación: cambiar la Aplicación cambia los campos. El operador solo completa lo que el destino dejó abierto — un valor fijado en el cuerpo no se sobrescribe, y el popup no crea claves nuevas. Es la forma de abrir un aviso de PM con el equipo que solo conoce quien está en el área.

Solo aparecen en el popup los destinos con Disponible en la apertura manual activado.

Abrir ticket muestra una confirmación con el resumen antes de enviar. Después del envío, el popup sigue la respuesta de la herramienta y muestra el número del ticket en cuanto llega — o el motivo, si la herramienta lo rechaza. Desde ahí se puede abrir otro o, con acceso a Configuración ITSM, ver los tickets abiertos.

La apertura manual queda fuera del bloqueo de un ticket a la vez: quien hace clic quiere un ticket ahora, y el automático todavía puede abrir el suyo después.

Dónde aparece la herramienta en el resto del sistema

La herramienta activada es una Aplicación de la categoría Mesa de ayuda. Aparece donde ayuda a seguir el envío, y queda fuera de donde solo estorbaría:

Permisos

Son tres Herramientas, separadas a propósito — quien abre tickets no necesita poder crear destinos, y quien crea destinos no necesita poder activar herramientas:

La lista de destinos del popup Abrir ticket no depende de que el usuario tenga la Interfaz de la herramienta en el perfil — un operador no la necesita. Lo que se protege ahí es la Aplicación citada en el ticket: solo aparecen las Aplicaciones que el usuario puede ver.

Problemas comunes