Un error de notificación Automic CALL.ALARM que nadie conseguía reproducir, pruebas a simple vista en una captura de pantalla y un único detalle pasado por alto que dio un giro completo a toda la investigación. Este es un caso real de asistencia técnica Automic Automation V24 del equipo de asistencia de Tricise, y constituye un ejemplo casi perfecto de por qué la experiencia de primera mano sigue superando a todas las herramientas de resolución de problemas de las que disponemos.
Si desea consultar un caso práctico relacionado sobre cómo las dependencias ambientales pueden provocar el fallo AWI, consulte nuestro artículo complementario sobre los errores de inicio de sesión AWI Automic y la configuración de Tomcat. Este caso práctico aborda el tema desde una perspectiva diferente: cuando el error es real, el cliente tiene razón y el ingeniero, sencillamente, no puede reproducirlo.
La situación: un objeto de notificación que no se comportaba
El cliente abrió un caso poco después de actualizar su sistema a la versión Automic Automation V24.4.4. Un objeto de notificación concreto — CALL.ALARM — había dejado de funcionar como lo hacía habitualmente.
En versiones anteriores, la interfaz AWI mostraba la notificación con dos botones de cierre: «Aceptar» y «Rechazar». Tras la actualización, esos botones desaparecieron. El usuario podía ver el mensaje, hacer clic en «Aceptar» y el cuadro de diálogo se cerraba. Un segundo después, se volvía a abrir. Luego se cerraba. Y luego se volvía a abrir. No había forma de evitar la notificación desde dentro de la interfaz AWI; la única solución era cerrar manualmente el objeto de notificación desde la supervisión de procesos.
Para un equipo de operaciones que depende de las notificaciones de CALL.ALARM para validar alertas críticas, este no es un problema estético. Bloquea toda una clase de flujo de trabajo.
Diagnóstico: cuando la reproducción falla
Lo primero que se hace en cualquier caso de asistencia técnica es reproducir el problema. El ingeniero de Tricise configuró un objeto de notificación sencillo del tipo CALL.ALARM, creó una tarea para activarlo y la ejecutó en la misma versión Automic Automation V24.4.4 que tenía el cliente.
El error no apareció. Los botones se mostraron correctamente. Tanto aceptar como rechazar funcionaron. Misma versión de producto, mismo tipo de objeto, mismo comportamiento esperado.
El siguiente paso fue sospechar de la configuración específica del cliente. Variables, dependencias, configuraciones del cliente... algo debía ser diferente. El cliente fue excepcionalmente cooperativo, empaquetó un escenario reproducible de su entorno y envió los objetos para que el ingeniero pudiera cargarlos en un sistema de prueba limpio.
Todavía nada. Los objetos corrieron. Los botones aparecieron. El error se negó a aparecer.
En este momento, el caso se encuentra en una situación delicada que cualquiera que haya trabajado en asistencia técnica conoce bien: hay pruebas evidentes de un defecto real —capturas de pantalla, datos de seguimiento de los procesos del cliente, un comportamiento repetible por su parte— y, sin embargo, desde el equipo de asistencia técnica somos totalmente incapaces de reproducirlo. Los registros y los rastros de ejecución no suelen ser de ayuda en los problemas de visualización. Y no había nada en la configuración del cliente que fuera lo suficientemente inusual como para explicar esta discrepancia.
El detalle en la captura de pantalla
El avance en este error de notificación de Automic CALL.ALARM se produjo al examinar con más detenimiento la captura de pantalla del cliente, no fijándome en los botones que faltaban, sino en el borde de AWI que los rodeaba.
El cliente estaba ejecutando el AWI en alemán. Cada intento de reproducción del lado de Tricise se había realizado en el AWI en inglés. Esa era la única variable que no se había controlado.
El ingeniero cambió el AWI de prueba al idioma alemán, activó el mismo objeto simple de notificación CALL.ALARM y los botones desaparecieron. El diálogo comenzó a repetirse. Comportamiento idéntico al del entorno del cliente. Pruebas posteriores confirmaron que el mismo defecto appeared en el AWI francés también.
El error se localizó en paquetes de idioma específicos de AWI, una clase de problema que casi nunca aparece en la descripción de los síntomas, porque los clientes no consideran “uso la interfaz en alemán” como parte del contexto técnico. Lo mencionan con la misma frecuencia que mencionan el color de su monitor.
La corrección y la solución alternativa
Una vez que se dispuso de una reproducción, el caso se elevó al Broadcom como un error confirmado. El proveedor lo aceptó y se comprometió a corregirlo en el Service Pack 24.4.5, que restablece la visualización correcta del botón de notificación en las interfaces de usuario (AWI) en alemán y francés.
Para el cliente, la solución alternativa inmediata fue simple: cambiar la sesión de AWI a inglés hasta que se instale el service pack parcheado. No es elegante, pero desbloquea al equipo en minutos, y una solución limpia ya está en el plan.
La documentación oficial de la notificación (CALL) de Broadcom describe detalladamente el comportamiento previsto de los botones en las plantillas de ALARMA, lo que constituye una base útil para cualquiera que desee validar la solución alternativa.
Lo que realmente nos enseña este error de notificación Automic CALL.ALARM
Tres cosas, todas las cuales generalizan mucho más allá de este caso específico:
- Un fallo en la reproducción es un dato. Cuando un cliente puede reproducir un problema y el servicio de asistencia no, la respuesta se encuentra en la diferencia entre ambos entornos. No se trata de que “el cliente esté haciendo algo mal” —casi nunca es así—. La clave está en encontrar la variable que nadie está modificando de forma consciente.
- Las capturas de pantalla aportan un contexto que la descripción del caso no ofrece. Las etiquetas de la interfaz de usuario en alemán aparecían en la captura de pantalla desde el primer momento. La solución se hizo evidente en cuanto alguien observó la imagen como tal, y no como una prueba para una hipótesis que ya tenía en mente.
- La comunicación interna multiplica el valor de cada caso resuelto. A los pocos días de resolver este caso de CALL.ALARM, varios clientes más notificaron el mismo problema. Como el equipo había analizado el caso en sus reuniones internas habituales, esos tickets de seguimiento se cerraron en cuestión de minutos, en lugar de días, y los clientes recibieron de inmediato la solución provisional y la información sobre el plan de corrección.
Preguntas frecuentes sobre este error de notificación Automic CALL.ALARM
Tras publicar el caso internamente, el equipo de soporte de Tricise siguió recibiendo las mismas preguntas de seguimiento de los clientes que encontraban síntomas similares. Las respuestas a continuación cubren lo que surge con más frecuencia, incluidas las situaciones en las que la simple solución de “cambiar a inglés” no es una opción.
¿Qué versiones del Automic Automation se ven afectadas?
El defecto se notificó por primera vez en la versión Automic Automation V24.4.4 y fue confirmado por Broadcom como un error en la misma versión. Las versiones anteriores del paquete de servicio de la línea V24.4.x no mostraron el problema en nuestras pruebas de reproducción en AWI alemán y francés. La corrección se incluye en el paquete de servicio V24.4.5. Los clientes que aún utilizan la versión V24.4.3 o anteriores no están expuestos; los clientes que utilizan la versión V24.4.4 están expuestos hasta que instalen la versión V24.4.5. La línea V24.5.x no formaba parte de este caso y debe probarse por separado si se actualiza de la versión V24.4 a la V24.5 en un solo paso.
¿Qué idiomas AWI activan los botones que faltan?
El alemán y el francés fueron los dos idiomas que confirmamos en el caso de soporte. El inglés no lo desencadena. No probamos todos los idiomas compatibles de AWI, pero el patrón — un defecto de representación específico de la localización — es coherente con la forma en que AWI crea paquetes de idioma para la línea V24.4. Si ejecuta AWI en italiano, español o cualquier otra configuración regional que no sea inglesa, considérelo un riesgo conocido en V24.4.4 y verifique el comportamiento de la notificación CALL.ALARM en un cliente no productivo antes de confiar en él en flujos de trabajo de producción.
¿Qué pasa si no podemos actualizar a la V24.4.5 de inmediato?
La solución provisional es que los usuarios de AWI cambien su sesión personal de AWI a inglés. La configuración es por usuario, por lo que un solo ingeniero de operaciones puede cambiar a inglés sin afectar a sus colegas. El resto de la plataforma —Automation Engine, agentes, motor de flujo de trabajo— no se ve afectado y continúa ejecutándose en su configuración existente. Si el cambio de sesión no es aceptable, la segunda solución provisional es terminar los objetos de notificación CALL.ALARM activos desde el Monitor de Procesos en lugar de desde el diálogo, lo cual es operativo engorroso pero funcionalmente completo.
¿El defecto afecta a otros tipos de objetos de notificación de LLAMADA?
En nuestro trabajo de reproducción no vimos el mismo problema de renderizado de botones en CALL.MAIL ni en las plantillas de notificación de ejemplo. El defecto es específico de la interacción de solicitud y respuesta de CALL.ALARM, que renderiza un diálogo con botones explícitos de aceptar/rechazar además del botón Aceptar. CALL.MAIL no presenta ese patrón de interacción, por lo que no hay botones que desaparezcan en primer lugar. Aún recomendamos probar cada flujo de trabajo basado en notificaciones en el mismo idioma AWI que utilizan sus usuarios de producción, especialmente después de cualquier actualización de V24.4.x.
¿Cómo podemos evitar que este tipo de error llegue a producción nuevamente?
La solución estructural consiste en incluir una interfaz de usuario (AWI) en un idioma distinto del inglés en las pruebas de validación previas a la producción cada vez que se actualice a la versión Automic Automation. La mayoría de los equipos empresariales solo prueban la AWI en inglés porque es la que utilizan sus ingenieros a diario, lo que significa que los errores de localización llegan a producción antes de que nadie se dé cuenta. Añadir un único cliente de prueba con el AWI configurado en el idioma que utilizan sus operadores le lleva a un ingeniero una hora y permite detectar toda una clase de defectos, de los que este caso es solo un ejemplo.
¿Cuál es la forma más rápida de enviar un caso complicado de Automic al servicio de asistencia de Tricise?
En los casos en los que es importante poder reproducir el problema —y en la mayoría lo es—, el paquete que más nos ayuda contiene cuatro elementos: la versión Automic Automation (incluido el nivel del Service Pack), capturas de pantalla del comportamiento defectuoso con la interfaz de AWI visible (indicadores de idioma, menú de usuario, tema), un objeto de notificación o flujo de trabajo exportado que muestre el problema, y una descripción de un párrafo sobre lo que el cliente esperaba y lo que ocurrió realmente. La captura de pantalla con el chrome de AWI es el detalle que ha marcado la diferencia en este caso, y casi nunca aparece en los tickets de soporte a menos que se le pida específicamente al cliente.
¿Y qué hay de los equipos híbridos con operadores tanto de inglés como de alemán?
Este es el escenario más doloroso en términos operativos, y varios clientes lo informaron después de que publicamos el resumen del caso interno. Hasta que se instale la V24.4.5, la recomendación práctica es estandarizar el idioma de AWI al inglés para los miembros del equipo que procesan activamente las notificaciones CALL.ALARM, y permitir que otros miembros del equipo utilicen su idioma preferido para trabajos de solo lectura o que no sean de notificación. El idioma de AWI es una configuración por usuario, por lo que la división es factible sin cambios en la infraestructura. Una vez que se envíe la V24.4.5, la división ya no será necesaria y los equipos podrán volver a sus idiomas preferidos.
Por qué los clientes eligen Tricise para la asistencia técnica de Automic
Este es el tipo de caso que no se resuelve mediante una búsqueda en la base de conocimientos. Necesita un ingeniero de soporte con la paciencia suficiente para preguntar “¿qué tiene de diferente su configuración que yo no veo?”, la disciplina suficiente para seguir leyendo la evidencia después de que la primera reproducción falle y la conexión suficiente con un equipo que convierta una resolución en una solución para todos los afectados.
Como especialistas en Automic Automation en Tricise, gestionamos más de 1.600 casos como este cada año. Cada caso se incorpora a nuestros intercambios internos y a nuestra base de datos Smart Automation, de modo que el próximo cliente que se enfrente a un problema similar reciba una respuesta más rápida.
Para los equipos que tengan previsto actualizar a la versión V24 o que ya estén utilizando la versión V24.4.x, nuestro catálogo de formación Tricise University aborda las cuestiones prácticas del soporte técnico tras la actualización, incluyendo cómo preparar rápidamente un informe reproducible cuando los síntomas son inusuales.
El resultado final
Un error de notificación «Automic CALL.ALARM» que resiste los intentos de reproducción tanto por parte del cliente como del servicio técnico no es imposible de resolver; simplemente exige que el ingeniero siga analizando las pruebas una vez agotadas las vías más obvias. En este caso, la respuesta estaba en una captura de pantalla desde el principio. La lección es más antigua que cualquier versión de Automic: la variable que nadie tiene en cuenta suele ser la que realmente importa.
¿Tienes un caso de asistencia técnica con el Automic que se te resiste?
Si te encuentras con un comportamiento de Automic Automation que “no debería darse” y tu equipo interno se ha quedado atascado, es probable que el equipo de asistencia de Tricise ya haya visto algo similar. Analizaremos el caso juntos, identificaremos la variable que falta y te daremos una solución viable.
Reservar una consulta gratuita de 30 minutos con el soporte de Tricise
