ITSM Helix + iTRACS
Se abre un ticket en Helix. Se ejecuta en el DCiM. Se cierra en los dos. Sin que el operador del data center toque nunca la herramienta de ticketing.
QUÉ ESTAMOS INTEGRANDO
Gestión y sincronización de tickets (Work Orders).
SISTEMAS INTEGRADOS
Helix - iTRACS
RESULTADO PRINCIPAL
El resultado principal es acabar con la doble gestión de tickets. El operador del data center trabaja solo en iTRACS, y los cambios de estado (En curso y Cerrado) se sincronizan automáticamente con Helix.
Contexto de la integración
iTRACS ON PREMISE
Fabricante: Commscope
Versión: Versión 5.4.5 o posterior
Módulos: WSDL
Helix CLOUD
Fabricante: BMC Software
Módulos: Web Services
El reto: ¿por qué era necesaria esta integración?
- Doble gestión permanente entre el ITSM y el DCiM. Sin integración, cada ticket de cambio en el data center se gestiona dos veces: en Helix (donde se abre, se asigna y se hace seguimiento del proceso ITSM) y en el DCiM (donde se planifica la ubicación, se ejecuta la conexión y se comisiona el equipo). El operador de data center tiene que leer el ticket en Helix, trasladar mentalmente la información al DCiM, ejecutar el trabajo, volver a Helix para actualizar el estado, y finalmente cerrarlo en ambos sitios. Este doble trabajo no solo consume tiempo, el ticket en Helix dice "en curso" cuando el DCiM ya lo ha cerrado, o viceversa. Con la integración, el operador trabaja solo en el DCiM y los estados se propagan automáticamente.
- Información del ticket incompleta o inadecuada para la ejecución física. Un ticket de comisionamiento necesita datos muy específicos para ejecutarse en un data center: tipo de equipo, fabricante, modelo, número de fuentes de alimentación con su potencia y voltaje, tarjetas PCI con tipo y número de puertos, línea de negocio. Sin integración, esta información llega al operador en formato libre (un email, un campo de texto genérico) y el operador tiene que perseguir al solicitante para completar lo que falta. La integración estandariza este flujo: el formulario ITSM incluye los campos obligatorios que el DCiM necesita, y toda esa información llega estructurada a la petición del DCiM, lista para planificar.
- Falta de visibilidad del estado real de ejecución en el ITSM. El responsable del servicio IT ve en Helix que hay 20 tickets abiertos de comisionamiento. Pero no sabe cuáles están planificados, cuáles se están ejecutando físicamente y cuáles están bloqueados esperando un rack libre. Esa información vive solo en la cabeza del operador del data center o en el DCiM. La sincronización bidireccional de estados hace que Helix refleje la realidad operativa del data center: si el operador mueve el ticket a "En Curso" en el DCiM, Helix lo muestra al instante. El ITSM deja de ser un sistema de tickets desconectado de la ejecución real.
- Trazabilidad; el proceso ITIL de gestión de cambios se rompe en la puerta del data center. Las organizaciones invierten en implementar procesos ITIL con herramientas como BMC Helix para garantizar trazabilidad, aprobaciones y control de cambios. Pero cuando el ticket llega al data center, el proceso se convierte en manual: el operador ejecuta el trabajo sin que el ITSM refleje qué se hizo, cuándo, quién lo hizo, y qué quedó documentado en el DCiM. La integración extiende el proceso ITIL hasta el último metro: cada cambio de estado en el DCiM se sincroniza automáticamente a Helix, y el cierre del ticket incluye el comentario del operador como confirmación de que el trabajo se completó realmente, es un cierre con evidencia operativa.
- Actualmente, la interfaz de ITSM Helix no dispone de un conector nativo con iTRACS. Esta limitación impide establecer un flujo de comunicación automatizado entre ambos entronos, obligando a realizar de forma manual y duplicada determinadas tareas y a mantener la información sincronizada en ambos entornos. Como consecuencia, se incrementa la carga operativa y el riesgo de inconsistencias o desactualización de la información entre los sistemas.
Los sistemas del ecosistema
SISTEMA | DESCRIPCIÓN | APORTA | RECIBE |
ITSM Helix | Plataforma ITSM utilizada para la gestión y registro de tickets/Work Orders. | Generación de Work Orders/Tickets y suministro de la información asociada a la petición. La creación de una petición en Helix desencadena su traslado a iTRACS para su tratamiento. | Recibe de iTRACS la evolución del ticket, principalmente los cambios de estado, manteniendo sincronizada la situación de la Work Order entre ambos sistemas. |
iTRACS | Plataforma de gestión de infraestructura de centro de datos (DCiM) | Recepción de las Work Orders procedentes de Helix y gestión de las mismas desde esta plataforma. | Recibe las peticiones y la información necesaria para su tratamiento y devuelve a Helix los cambios de estado generados durante la gestión. |
El diagrama de conexión
La arquitectura está compuesta por dos sistemas externos (Helix y iTRACS) y un servidor de integraciones que contiene, por un lado, los Web Services que reciben la información desde Helix y un aplicativo que se encarga de comunicar los cambios de estado que se producen en iTRACS hacia Helix de forma síncrona.
El flujo de datos en acción
A continuación se describe el flujo de trabajo de una petición en iTRACS:
El proceso de integración comienza desde Helix donde se abre una nueva petición para la realización de una tarea en iTRACS.
La petición queda reflejada en iTRACS en la ventana de Manager (Workflow -> Manager).
Los proyectos con las nuevas Request de Helix se generan bajo el Proyecto raíz “Remedy Requests”. Se llaman “Remedy Request Ticket XXXX” donde XXX es el Identificador del Ticket de Helix. Cada proyecto contiene una Request con el mismo nombre.
Con la Request seleccionada podemos consultar en la pestaña de notas la información asociada a la petición.
El usuario deberá confirmar el inicio de las acciones solicitadas en Helix cambiando al estado “En curso”. En iTRACS se corresponde con el estado “Planned”.
Este cambio de estado invoca al agente de integración que comunica a Helix el cambio Una vez comunicado el estado a Helix, el campo Reference reflejará el cambio en iTRACS añadiendo ONGOING STATUS OK tras el identificador del ticket.
En caso de error en la comunicación con Helix, el estado cambiará a “Flagged” y en el campo “Reference” se añadirá el estado de la sincronización con Remedy “Status ONGOING ERROR”.
Para volver a lanzar el proceso de sincronización se debe cambiar manualmente el estado de nuevo a Planned.
iTRACS realiza 3 intentos de comunicación antes de dejar el proceso en estado ONGOING ERROR por lo que es posible que transcurridos unos minutos desde el cambio de estado a Flagged, se cambie automáticamente de nuevo a Planned y a ONGOING OK.
Tras unos minutos, comprobaremos que el estado ha sido actualizado también en Helix mirando el campo Reference, donde deberá indicar “Status CLOSED OK”
En caso de error en la sincronización con Helix, el estado de iTRACS cambiará a Flagged y en el campo Reference indicará “Status CLOSED ERROR”
Como en el caso anterior, iTRACS realizará 3 intentos de sincronización. Si transcurridos esos intentos no consigue realizar una comunicación exitosa con Helix, dejará el estado en estado “Flagged” y en el campo Reference, Status CLOSED ERROR. Para volver a intentar la sincronización será necesario cambiar manualmente el estado de nuevo a “Closed”.
MODELO Y EJECUCIÓN
Orientado a eventos para la sincronización de cambios de estado.
DISPARADOR
Creación de Work Orders y eventos asociados a cambios de estado en iTRACS.
Lo que hizo la diferencia
Decisiones de diseño que no eran las obvias, y por qué las tomamos.
Clave 1: sincronización basada en eventos
Se optó por un modelo de sincronización orientado a eventos para propagar los cambios de estado desde iTRACS hacia Helix. Los camios de estado en las Work Orders de iTRACS generan eventos que desencadenan automáticamente la ejecución del componente de integración y la correspondiente actualización del ticket en Helix.
Este enfoque permite que ambas plataformas estén sincronizadas en tiempo real, minimizar procesos de consulta periódica y mantener una mayor coherencia entre el estado operativo de la Work Order en iTRACS y su representación en el sistema ITSM.
¿Tu ecosistema tecnológico está preparado para conectarse?
Cuéntanos qué sistemas tienes y qué necesitas que se hablen.