Ein Automic-CALL.ALARM-Benachrichtigungs-Bug, den niemand reproduzieren konnte, Hinweise, die offen sichtbar in einem Screenshot lagen, und ein einziges übersehenes Detail, das die gesamte Untersuchung kippte. Das ist ein realer Support-Fall zu Automic Automation V24 aus dem Tricise-Support-Team — und ein nahezu perfektes Beispiel dafür, warum praktische Erfahrung jedes Troubleshooting-Tool schlägt, das wir besitzen.
Eine verwandte Fallstudie dazu, wie Umgebungsabhängigkeiten das AWI lahmlegen können, findet sich in unserem Begleitartikel zu Automic-AWI-Logon-Fehlern und der Tomcat-Konfiguration. Diese Fallstudie betrachtet einen anderen Blickwinkel: Wenn der Bug real ist, der Kunde recht hat und der Engineer ihn schlicht nicht reproduzieren kann.
Die Ausgangslage: ein Benachrichtigungsobjekt, das nicht wollte
Der Kunde meldete den Fall kurz nach dem Upgrade seines Systems auf Automic Automation V24.4.4. Ein bestimmtes Notification-Objekt — CALL.ALARM — verhielt sich nicht mehr so, wie es immer funktioniert hatte.
In früheren Versionen zeigte das AWI die Benachrichtigung mit zwei klaren Buttons an: annehmen und ablehnen. Nach dem Upgrade waren diese Buttons verschwunden. Der Nutzer konnte die Meldung sehen, auf OK klicken, und der Dialog schloss sich. Eine Sekunde später öffnete er sich erneut. Dann schloss er sich. Dann öffnete er sich wieder. Die Benachrichtigung war aus dem AWI heraus nicht zu entkommen — der einzige Workaround bestand darin, das Notification-Objekt manuell über Process Monitoring zu beenden.
Für ein Operations-Team, das sich auf CALL.ALARM-Benachrichtigungen verlässt, um kritische Alarme zu bestätigen, ist das kein kosmetisches Problem. Es blockiert eine ganze Workflow-Klasse.
Diagnostik: Wenn die Reproduktion fehlschlägt
Der erste Reflex in jedem Support-Fall ist die Reproduktion. Der Tricise-Engineer richtete ein einfaches Notification-Objekt vom Typ CALL.ALARM ein, baute eine Task zum Auslösen und ließ sie auf derselben Automic-Automation-Version V24.4.4 laufen, auf der auch der Kunde war.
Der Bug trat nicht auf. Die Buttons wurden korrekt angezeigt. Annehmen und Ablehnen funktionierten beide. Gleiche Produktversion, gleicher Objekttyp, gleiches erwartetes Verhalten.
Der nächste Schritt war, eine kundenindividuelle Konfiguration zu vermuten. Variablen, Abhängigkeiten, Client-Einstellungen — irgendetwas musste anders sein. Der Kunde zeigte sich außergewöhnlich kooperativ, schnürte ein reproduzierbares Szenario aus seiner Umgebung und schickte die Objekte herüber, damit der Engineer sie in ein sauberes Testsystem laden konnte.
Immer noch nichts. Die Objekte liefen. Die Knöpfe erschienen. Der Fehler weigerte sich aufzutauchen.
An diesem Punkt steht der Fall an einem unangenehmen Punkt, den jeder kennt, der schon einmal im Produktsupport gearbeitet hat: Es gibt offensichtliche Hinweise auf einen echten Defekt — Screenshots, Process-Monitoring-Daten des Kunden, reproduzierbares Verhalten auf seiner Seite — und gleichzeitig die völlige Unfähigkeit, das Ganze auf der Support-Seite nachzustellen. Logs und Traces helfen bei einem Anzeigeproblem selten weiter. Und am Setup des Kunden war nichts ungewöhnlich genug, um die Diskrepanz zu erklären.
Das Detail im Screenshot
Der Durchbruch bei diesem Automic-CALL.ALARM-Benachrichtigungs-Bug kam durch einen genaueren Blick auf den Screenshot des Kunden — nicht auf die fehlenden Buttons, sondern auf das AWI-Chrome drumherum.
Der Kunde nutzte die AWI auf Deutsch. Jeder Reproduktionsversuch auf der Tricise-Seite wurde mit der englischen AWI durchgeführt. Das war die einzige Variable, die nicht kontrolliert worden war.
Der Engineer stellte das Test-AWI auf die deutsche Spracheinstellung um, löste dasselbe einfache CALL.ALARM-Notification-Objekt aus, und die Buttons verschwanden. Der Dialog begann zu loopen. Identisches Verhalten wie in der Kundenumgebung. Spätere Tests bestätigten, dass derselbe Defekt auch im französischen AWI auftrat.
Der Bug war auf bestimmte AWI-Sprachpakete beschränkt — eine Fehlerklasse, die in der Symptombeschreibung fast nie auftaucht, weil Kunden „Ich nutze die deutsche Oberfläche" nicht als Teil des technischen Kontexts betrachten. Sie erwähnen es ungefähr so oft, wie sie die Farbe ihres Monitors erwähnen.
Die Lösung und der Workaround
Mit der erfolgreichen Reproduktion in der Hand wurde der Fall als bestätigter Bug an Broadcom eskaliert. Der Hersteller nahm ihn an und sagte einen Fix im Service Pack 24.4.5 zu, das die korrekte Darstellung der Notification-Buttons im deutschen und französischen AWI wiederherstellt.
Für den Kunden war der unmittelbare Workaround einfach: die AWI-Session auf Englisch umstellen, bis das gepatchte Service Pack installiert ist. Nicht elegant, aber das Team ist innerhalb von Minuten wieder einsatzfähig, und ein sauberer Fix steht bereits auf der Roadmap.
Die offizielle Notification-(CALL)-Dokumentation von Broadcom beschreibt das beabsichtigte Button-Verhalten von ALARM-Templates im Detail — ein nützlicher Hintergrund für alle, die den Workaround validieren wollen.
Was dieser Automic-CALL.ALARM-Benachrichtigungs-Bug tatsächlich lehrt
Drei Dinge, die sich alle weit über diesen konkreten Fall hinaus verallgemeinern lassen:
- Eine fehlgeschlagene Reproduktion ist selbst eine Information. Wenn ein Kunde etwas reproduzieren kann und der Support nicht, dann liegt die Antwort im Unterschied zwischen den beiden Umgebungen. Nicht „der Kunde muss etwas falsch machen" — fast nie. Die Disziplin besteht darin, die Variable zu finden, die niemand bewusst variiert.
- Screenshots transportieren Kontext, den die Fallbeschreibung nicht enthält. Die deutschen UI-Beschriftungen waren von Anfang an im Screenshot zu sehen. Der Fix wurde in dem Moment sichtbar, in dem jemand das Bild als Bild betrachtete und nicht als Beleg für eine bereits feststehende Hypothese.
- Interne Kommunikation vervielfacht den Wert jedes gelösten Falls. Innerhalb weniger Tage nach der Lösung dieses CALL.ALARM-Falls meldeten mehrere weitere Kunden dasselbe Symptom. Weil das Team den Fall in den regelmäßigen internen Meetings besprochen hatte, wurden diese Folge-Tickets in Minuten statt Tagen geschlossen — und die Kunden erhielten sofort den Workaround sowie die Information zum Fix-Plan.
Häufig gestellte Fragen zu diesem Automic-CALL.ALARM-Benachrichtigungs-Bug
Nach der internen Veröffentlichung des Falls erhielt das Tricise-Support-Team immer wieder dieselben Folgefragen von Kunden, die auf ähnliche Symptome stießen. Die folgenden Antworten decken die häufigsten Punkte ab — einschließlich der Situationen, in denen der einfache „Auf Englisch umstellen"-Workaround keine Option ist.
Welche Automic Automation-Versionen sind betroffen?
Der Defekt wurde erstmals auf Automic Automation V24.4.4 gemeldet und von Broadcom als Bug in derselben Version bestätigt. Frühere Service-Pack-Releases der V24.4.x-Linie zeigten das Problem in unseren Reproduktionstests im deutschen und französischen AWI nicht. Der Fix wird mit Service Pack V24.4.5 ausgeliefert. Kunden, die noch auf V24.4.3 oder früher sind, sind nicht betroffen; Kunden auf V24.4.4 sind so lange betroffen, bis sie V24.4.5 installiert haben. Die V24.5.x-Linie war nicht Teil dieses Falls und sollte separat getestet werden, wenn ein Upgrade von V24.4 auf V24.5 in einem Schritt erfolgt.
Welche AWI-Sprachen lösen die fehlenden Schaltflächen aus?
Deutsch und Französisch sind die beiden Sprachen, die wir im Support-Fall bestätigt haben. Englisch löst das Problem nicht aus. Wir haben nicht jede unterstützte AWI-Sprache getestet, aber das Muster — ein lokalisierungsspezifischer Rendering-Defekt — passt zu der Art, wie das AWI die Sprachpakete für die V24.4-Linie baut. Wer das AWI auf Italienisch, Spanisch oder in einer anderen nicht-englischen Locale betreibt, sollte dies auf V24.4.4 als bekanntes Risiko behandeln und das Verhalten von CALL.ALARM-Notifications auf einem Nicht-Produktions-Client verifizieren, bevor er sich in produktiven Workflows darauf verlässt.
Was, wenn wir nicht sofort auf V24.4.5 upgraden können?
Der Interims-Workaround besteht darin, dass AWI-Nutzer ihre persönliche AWI-Session auf Englisch umstellen. Die Einstellung ist nutzerbezogen, sodass ein einzelner Operations-Engineer auf Englisch umschalten kann, ohne Kollegen zu beeinträchtigen. Der Rest der Plattform — Automation Engine, Agents, Workflow-Engine — ist nicht betroffen und läuft in der bestehenden Konfiguration weiter. Sollte ein Sprachwechsel der Session nicht akzeptabel sein, ist der zweite Workaround, aktive CALL.ALARM-Notification-Objekte über Process Monitoring statt aus dem Dialog heraus zu beenden — operativ umständlich, funktional aber vollständig.
Beeinträchtigt der Fehler andere CALL-Benachrichtigungsobjekttypen?
In unseren Reproduktionstests haben wir denselben Button-Rendering-Fehler bei CALL.MAIL und den SAMPLE-Notification-Templates nicht beobachtet. Der Defekt ist spezifisch für die Request-and-Response-Interaktion von CALL.ALARM, die einen Dialog mit expliziten Annehmen-/Ablehnen-Buttons zusätzlich zum OK-Button rendert. CALL.MAIL bietet dieses Interaktionsmuster nicht, also gibt es dort schlicht keine Buttons, die verschwinden könnten. Wir empfehlen dennoch, jeden Notification-basierten Workflow in der AWI-Sprache zu testen, die die produktiven Nutzer tatsächlich verwenden — insbesondere nach jedem V24.4.x-Upgrade.
Wie können wir verhindern, dass diese Art von Fehler erneut in die Produktion gelangt?
Der strukturelle Fix besteht darin, bei jedem Automic-Automation-Upgrade auch ein nicht-englisches AWI in die Validierungsläufe der Vorproduktion einzubeziehen. Die meisten Enterprise-Teams testen nur das englische AWI, weil ihre Engineers im Tagesgeschäft damit arbeiten — was bedeutet, dass Lokalisierungsdefekte die Produktion erreichen, bevor jemand sie bemerkt. Einen einzelnen Test-Client einzurichten, dessen AWI auf die Sprache der Operatoren eingestellt ist, kostet einen Engineer eine Stunde und fängt eine ganze Defektklasse ab, von der dieser Fall nur ein Beispiel ist.
Wie kann man einen kniffligen Automic-Fall am schnellsten an den Tricise-Support weiterleiten?
Für Fälle, in denen die Reproduktion entscheidend ist — und das gilt für die meisten — enthält das hilfreichste Paket vier Dinge: die Automic-Automation-Version (inklusive Service-Pack-Stand), Screenshots des fehlerhaften Verhaltens mit sichtbarem AWI-Chrome (Sprachindikatoren, Nutzermenü, Theme), ein exportiertes Notification- oder Workflow-Objekt, das das Problem demonstriert, sowie eine kurze, einabsatzlange Beschreibung dessen, was der Kunde erwartet hat — und was tatsächlich passiert ist. Der Screenshot mit dem AWI-Chrome ist genau das Detail, an dem dieser Fall hing, und es taucht in Support-Tickets fast nie auf, sofern der Kunde nicht gezielt danach gefragt wird.
Was ist mit hybriden Teams mit englischen und deutschen Bedienern?
Das ist das betrieblich schmerzhafteste Szenario, und mehrere Kunden meldeten es, nachdem wir das interne Case-Write-up veröffentlicht hatten. Bis V24.4.5 installiert ist, lautet die praktische Empfehlung: die AWI-Sprache für die Teammitglieder, die aktiv CALL.ALARM-Notifications bearbeiten, auf Englisch zu standardisieren — und den übrigen Teammitgliedern für reine Lese- oder Nicht-Notification-Arbeiten die bevorzugte Sprache zu lassen. Die AWI-Sprache ist eine nutzerbezogene Einstellung, sodass diese Aufteilung ohne infrastrukturelle Änderungen umsetzbar ist. Sobald V24.4.5 ausgeliefert wird, ist die Aufteilung nicht mehr nötig und die Teams können zu ihren bevorzugten Sprachen zurückkehren.
Warum Kunden sich für Tricise als Support für Automic entscheiden
Das ist die Art von Fall, der sich nicht über eine Suche in der Wissensdatenbank lösen lässt. Er braucht einen Support-Engineer, der geduldig genug ist, zu fragen „Was ist an deinem Setup anders, das ich übersehe?", diszipliniert genug, die Hinweise weiter zu lesen, nachdem die erste Reproduktion gescheitert ist — und gut genug an ein Team angebunden, das aus einer Lösung einen Fix für alle Betroffenen macht.
Als Automic-Automation-Spezialisten bei Tricise bearbeiten wir jedes Jahr mehr als 1.600 Fälle wie diesen. Jeder Fall fließt zurück in unseren internen Austausch und in unser Smart-Automation-Portfolio, damit der nächste Kunde, der auf ein ähnliches Problem stößt, eine schnellere Antwort bekommt.
Für Teams, die ein V24-Upgrade planen oder bereits auf V24.4.x betreiben, deckt unser Schulungskatalog der Tricise University die betrieblichen Realitäten des Post-Upgrade-Supports ab — einschließlich der Frage, wie sich ein reproduzierbarer Fall schnell aufbereiten lässt, wenn die Symptome ungewöhnlich sind.
Das Endergebnis
Ein Automic-CALL.ALARM-Benachrichtigungs-Bug, der sowohl Reproduktionsversuche auf Kundenseite als auch auf Support-Seite übersteht, ist nicht unlösbar — er verlangt nur, dass der Engineer die Hinweise weiter studiert, nachdem die offensichtlichen Pfade ausgeschöpft sind. In diesem Fall lag die Antwort die ganze Zeit in einem Screenshot. Die Lektion ist älter als jede Automic-Version: Die Variable, die niemand variiert, ist meistens die, auf die es ankommt.
Haben Sie einen hartnäckigen Supportfall in Automic?
Wenn dir Automic-Automation-Verhalten begegnet, das „eigentlich nicht passieren dürfte", und dein Inhouse-Team an eine Wand stößt, hat das Tricise-Support-Team mit hoher Wahrscheinlichkeit schon etwas Ähnliches gesehen. Wir schauen uns den Fall gemeinsam an, identifizieren die fehlende Variable und bringen dich zu einer tragfähigen Antwort.
Vereinbare eine kostenlose 30-minütige Beratung mit dem Tricise Support
