Un bug lié à la notification Automic CALL.ALARM que personne ne parvenait à reproduire, des preuves évidentes visibles sur une capture d'écran, et un seul détail négligé qui a complètement bouleversé l'enquête. Il s'agit d'un cas d'assistance Automic Automation V24 réel traité par l'équipe d'assistance de Tricise — et c'est un exemple presque parfait qui illustre pourquoi l'expérience de terrain reste supérieure à tous les outils de dépannage dont nous disposons.
Pour une étude de cas connexe sur la manière dont les dépendances environnementales peuvent perturber l'AWI, consultez notre article complémentaire consacré aux échecs de connexion à l'AWI Automic et à la configuration de Tomcat. Cette étude de cas aborde le sujet sous un angle différent : lorsque le bug est bien réel, que le client a raison et que l'ingénieur ne parvient tout simplement pas à le reproduire.
La situation : un objet de notification qui n'en faisait qu'à sa tête
Le client a ouvert un dossier peu après avoir mis à jour son système vers la version Automic Automation V24.4.4. Un objet de notification spécifique — CALL.ALARM — avait cessé de fonctionner comme auparavant.
Dans les versions précédentes, l'AWI affichait la notification avec deux boutons clairs : « Accepter » et « Refuser ». Après la mise à jour, ces boutons avaient disparu. L'utilisateur pouvait voir le message, cliquer sur « OK », et la boîte de dialogue se fermait. Une seconde plus tard, elle se rouvrait. Puis se refermait. Puis se rouvrait à nouveau. Il était impossible d'échapper à cette notification depuis l'AWI — la seule solution consistait à fermer manuellement l'objet Notification depuis la surveillance des processus.
Pour une équipe d'exploitation qui s'appuie sur les notifications CALL.ALARM pour valider des alertes critiques, ce n'est pas un problème cosmétique. Cela bloque une classe entière de flux de travail.
Diagnostics : lorsque la reproduction échoue
Dans tout cas de support technique, la première chose à faire est de reproduire le problème. L'ingénieur de Tricise a configuré un simple objet Notification de type CALL.ALARM, a créé une tâche pour le déclencher, puis l'a exécutée sur la même version Automic Automation V24.4.4 que celle utilisée par le client.
Le bug n'est pas apparu. Les boutons se sont affichés correctement. Accepter et rejeter ont tous deux fonctionné. Même version de produit, même type d'objet, même comportement attendu.
La prochaine étape consista à suspecter la configuration spécifique au client. Des variables, des dépendances, des paramètres client — quelque chose devait être différent. Le client fut exceptionnellement coopératif, regroupa un scénario reproductible de son environnement et envoya les objets afin que l'ingénieur puisse les charger dans un système de test propre.
Toujours rien. Les objets ont couru. Les boutons sont apparus. Le bug a refusé de se montrer.
À ce stade, le dossier se trouve dans une situation délicate que tous ceux qui ont déjà travaillé dans le support produit connaissent bien : il existe des preuves évidentes d’un véritable dysfonctionnement — captures d’écran, données de surveillance des processus du client, comportement reproductible de son côté —, mais le support est totalement incapable de le reproduire. Les journaux et les traces ne sont généralement d’aucune aide lorsqu’il s’agit d’un problème d’affichage. Et rien dans la configuration du client n’était suffisamment inhabituel pour expliquer cet écart.
Le détail dans la capture d'écran
La solution à ce bug de notification « Automic CALL.ALARM » est venue d'un examen plus attentif de la capture d'écran fournie par le client — non pas en se concentrant sur les boutons manquants, mais sur la bordure chromée AWI qui les entourait.
Le client utilisait l'AWI en allemand. Toutes les tentatives de reproduction du côté de Tricise avaient été effectuées sur l'AWI en anglais. C'était la seule variable qui n'avait pas été contrôlée.
L'ingénieur a basculé l'AWI de test en langue allemande, a déclenché le même objet de notification simple CALL.ALARM, et les boutons ont disparu. Le dialogue a commencé à boucler. Comportement identique à l'environnement du client. Des tests ultérieurs ont confirmé que le même défaut apparaissait également sur l'AWI français.
Le bug était localisé dans des packs de langues AWI spécifiques — un type de problème qui n'apparaît presque jamais dans la description des symptômes, car les clients ne pensent pas à “j'utilise l'interface allemande” comme faisant partie du contexte technique. Ils le mentionnent à peu près aussi souvent qu'ils mentionnent la couleur de leur moniteur.
La correction et la solution de contournement
Une fois la reproduction obtenue, le cas a été reclassé en Broadcom en tant que bug confirmé. Le fournisseur l'a accepté et s'est engagé à le corriger dans le Service Pack 24.4.5, qui rétablit l'affichage correct du bouton de notification dans les interfaces utilisateur en allemand et en français.
Pour le client, la solution de contournement immédiate était simple : passer la session AWI en anglais jusqu'à ce que le pack de correctifs soit installé. Pas élégant, mais cela permet à l'équipe de débloquer la situation en quelques minutes, et une solution propre est déjà prévue.
La documentation officielle de la notification (CALL) relative à la version Broadcom décrit en détail le comportement prévu des boutons dans les modèles ALARM — une information utile pour toute personne chargée de valider la solution de contournement.
Ce que nous apprend réellement ce bug lié à la notification Automic CALL.ALARM
Trois choses, qui généralisent toutes bien au-delà de ce cas spécifique :
- Un problème de reproduction, c'est une donnée. Lorsqu'un client parvient à reproduire un problème et que le service d'assistance n'y arrive pas, la réponse se trouve dans la différence entre les deux environnements. Il ne s'agit pas de dire “ le client doit faire quelque chose de travers ” — ce n'est presque jamais le cas. Il s'agit de trouver la variable que personne ne modifie consciemment.
- Les captures d'écran apportent un contexte que la description du cas ne fournit pas. Les libellés de l'interface utilisateur en allemand figuraient sur la capture d'écran dès le premier jour. La solution est apparue dès que quelqu'un a regardé l'image pour ce qu'elle était, et non comme une preuve venant étayer une hypothèse déjà formulée.
- La communication interne multiplie la valeur de chaque cas résolu. Quelques jours seulement après la résolution de ce ticket CALL.ALARM, plusieurs autres clients ont signalé le même problème. Comme l'équipe avait discuté du cas lors de ses réunions internes régulières, ces tickets de suivi ont été clôturés en quelques minutes plutôt qu'en plusieurs jours — et les clients ont immédiatement reçu les informations relatives à la solution de contournement et au plan de correction.
Foire aux questions concernant ce bug de notification Automic CALL.ALARM
Après avoir publié le cas en interne, l'équipe du support Tricise a continué de recevoir les mêmes questions de suivi de la part de clients rencontrant des symptômes similaires. Les réponses ci-dessous couvrent les questions les plus fréquentes, y compris les situations où la simple solution de contournement “changer pour l'anglais” n'est pas une option.
Quelles versions du Automic Automation sont concernées ?
Le défaut a été signalé pour la première fois dans la version Automic Automation V24.4.4 et confirmé par Broadcom comme étant un bug dans cette même version. Les versions antérieures du Service Pack de la gamme V24.4.x n’ont pas présenté ce problème lors de nos tests de reproduction sur les environnements AWI allemands et français. Le correctif est disponible dans le Service Pack V24.4.5. Les clients qui utilisent encore la version V24.4.3 ou une version antérieure ne sont pas concernés ; les clients utilisant la version V24.4.4 sont exposés jusqu'à ce qu'ils installent la version V24.4.5. La gamme V24.5.x n'était pas concernée par ce cas et doit être testée séparément si vous effectuez une mise à niveau de la version V24.4 vers la version V24.5 en une seule étape.
Quelles langues AWI déclenchent les boutons manquants ?
L'allemand et le français étaient les deux langues que nous avons confirmées dans le dossier de support. L'anglais ne déclenche pas le problème. Nous n'avons pas testé toutes les langues AWI prises en charge, mais le schéma — un défaut de rendu spécifique à la localisation — correspond à la façon dont l'AWI crée des packs de langues pour la ligne V24.4. Si vous exécuté l'AWI en italien, espagnol ou dans toute autre locale non anglaise, considérez cela comme un risque connu sur V24.4.4 et vérifiez le comportement de la notification CALL.ALARM sur un client non productif avant de vous y fier dans les flux de production.
Que se passe-t-il si nous ne pouvons pas passer à la V24.4.5 immédiatement ?
La solution de contournement provisoire consiste à demander aux utilisateurs d'AWI de basculer leur session AWI personnelle en anglais. Le réglage est par utilisateur, donc un seul ingénieur des opérations peut passer à l'anglais sans affecter ses collègues. Le reste de la plateforme — Automation Engine, agents, moteur de flux de travail — n'est pas affecté et continue de fonctionner dans sa configuration existante. Si le changement de session n'est pas acceptable, la deuxième solution de contournement consiste à terminer les objets d'alerte CAL.ALARM actifs depuis la surveillance des processus plutôt que depuis la boîte de dialogue, ce qui est opérationnellement fastidieux mais fonctionnellement complet.
Le défaut affecte-t-il d'autres types d'objets de notification d'appel ?
Dans notre travail de reproduction, nous n'avons pas constaté le même problème de rendu de bouton sur CALL.MAIL ou sur les modèles de notification SAMPLE. Le défaut est spécifique à l'interaction demande-réponse de CALL.ALARM, qui rend une boîte de dialogue avec des boutons accepter/rejeter explicites en plus du bouton OK. CALL.MAIL ne présente pas ce schéma d'interaction, il n'y a donc pas de boutons qui disparaissent en premier lieu. Nous recommandons tout de même de tester chaque flux de travail basé sur les notifications dans la même langue AWI que celle utilisée par vos utilisateurs de production, en particulier après toute mise à niveau V24.4.x.
Comment pouvons-nous empêcher que ce type de bug n'atteigne à nouveau la production ?
La solution structurelle consiste à inclure une interface utilisateur (AWI) dans une autre langue que l'anglais dans vos cycles de validation pré-production chaque fois que vous effectuez une mise à niveau de Automic Automation. La plupart des équipes d'entreprise ne testent que l'interface utilisateur en anglais, car c'est celle que leurs ingénieurs utilisent au quotidien, ce qui signifie que des défauts de localisation parviennent en production avant que quiconque ne s'en aperçoive. L'ajout d'un seul client de test avec l'AWI configuré dans la langue utilisée par vos opérateurs ne prend qu'une heure à un ingénieur et permet de détecter toute une catégorie de défauts, dont ce cas n'est qu'un exemple parmi d'autres.
Quel est le moyen le plus rapide de signaler un cas complexe concernant le modèle Automic au service d'assistance de Tricise ?
Dans les cas où la reproduction du problème est essentielle — et c'est souvent le cas —, le dossier qui nous aide le plus contient quatre éléments : la version Automic Automation (y compris le niveau du Service Pack), des captures d'écran illustrant le comportement défectueux avec l'interface AWI visible (indicateurs de langue, menu utilisateur, thème), un objet de notification ou de workflow exporté qui reproduit le problème, ainsi qu'une description en un paragraphe de ce à quoi s'attendait le client par rapport à ce qui s'est réellement produit. La capture d'écran avec l'interface AWI est l'élément qui a fait pencher la balance dans ce cas, et elle n'apparaît presque jamais dans les tickets d'assistance, sauf si le client est spécifiquement invité à la fournir.
Qu'en est-il des équipes hybrides avec des opérateurs anglophones et germanophones ?
C'est le scénario le plus pénible opérationnellement, et plusieurs clients l'ont signalé après la publication de l'étude de cas interne. Jusqu'à l'installation de la version V24.4.5, la recommandation pratique est de standardiser la langue de l'AWI à l'anglais pour les membres de l'équipe qui traitent activement les notifications CALL.ALARM, et de laisser les autres membres de l'équipe utiliser leur langue préférée pour le travail en lecture seule ou le travail ne concernant pas les notifications. La langue de l'AWI est un paramètre par utilisateur, le partage est donc réalisable sans modifications d'infrastructure. Une fois que la version V24.4.5 sera livrée, le partage ne sera plus nécessaire et les équipes pourront revenir à leurs langues préférées.
Pourquoi les clients choisissent Tricise pour l'assistance relative au modèle Automic
C'est le genre de cas qui ne se résout pas par une recherche dans une base de connaissances. Il faut un ingénieur de support suffisamment patient pour demander “qu'est-ce qui est différent dans votre configuration que je ne vois pas”, suffisamment discipliné pour continuer à lire les preuves après que la première reproduction échoue, et suffisamment connecté à une équipe qui transforme une résolution en une correction pour tous ceux qui sont concernés.
En tant que spécialistes Automic Automation chez Tricise, nous traitons plus de 1 600 cas comme celui-ci chaque année. Chaque cas alimente nos échanges internes et notre base de données Smart Automation, afin que le prochain client confronté à un problème similaire obtienne une réponse plus rapide.
Pour les équipes qui prévoient de passer à la version V24 ou qui utilisent déjà la version V24.4.x, notre catalogue de formations Tricise University aborde les réalités opérationnelles du support après la mise à niveau, notamment comment constituer rapidement un dossier reproductible lorsque les symptômes sont inhabituels.
Le résultat net
Un bug de notification CALL.ALARM dans Automic qui résiste aux tentatives de reproduction tant du côté du client que du support technique n’est pas impossible à résoudre — il suffit simplement que l’ingénieur continue d’examiner les indices une fois que toutes les pistes évidentes ont été épuisées. Dans ce cas précis, la réponse se trouvait depuis le début dans une capture d’écran. La leçon à en tirer est plus ancienne que n’importe quelle version de Automic : la variable que personne ne modifie est généralement celle qui compte.
Vous rencontrez des difficultés avec un dossier d'assistance concernant la carte Automic ?
Si vous rencontrez un comportement inattendu avec Automic Automation et que votre équipe interne se trouve dans une impasse, l'équipe d'assistance Tricise a probablement déjà rencontré un cas similaire. Nous examinerons ensemble le problème, identifierons la variable manquante et vous proposerons une solution viable.
Réserver une consultation gratuite de 30 minutes avec Tricise Support
