Fehler und Fehleranalyse in IBM Planning Analytics sind meistens Teamwork – oder gab es doch wieder nur den Screenshot der Fehlermeldung mit dem Betreff „bitte asap fixen“? In den letzten Jahren musste ich mehr als einmal meine eigenen Fehler und die „Unschärfen“ anderer Kolleg:innen suchen, finden und korrigieren. Du auch? Mein Prozess zur TM1 Fehleranalyse sieht wie folgt aus:
- Fehlerbeschreibung: Beginnen wir damit, den Fehler so genau wie möglich zu beschreiben. Welche Symptome treten auf? Wann und unter welchen Bedingungen tritt der Fehler auf? Tipp: statt E-Mail PingPong ist das die kurze Teams Session meist einfacher – aber geht leider nicht immer. Also nachfragen – keine Annahmen treffen!
- TM1error Log: Ich möchte nicht sagen, dass ich Fehlerbeschreibung validiere, aber TM1 Fehler können manchmal gemein sein… Was steht in den TM1 Logs? Macht das Sinn, ist das der Fehler, wann tritt der Fehler auf, welche Laufzeit, läuft etwas parallel = Muster und Auffälligkeiten suchen
- Isolierung des Fehlers: Ich versuche den Bereich, in dem der Fehler auftritt, einzugrenzen. Fehler in der Schnittstelle, beim Import oder Export? Dann versuche ich das genaue auftreten des Fehlers zu identifizieren. Ich untersuche die beteiligten Systeme, schaue ins Flatfile, prüfe die Datenbank Tabelle, etc. – jeder TM1 Fehler hat einen Ursprung.
- Überprüfung der Konfiguration: Sind PersistentFeeder aktiviert oder funktioniert die neue C Rule nicht, weil AllowSeparateNandCRules = „F“? Stelle sicher, dass die Konfigurationseinstellungen der beteiligten Systeme, Pfade, etc. (und alles was du ansonsten noch unterstellst tatsächlich) korrekt sind.
- Daten überprüfen: Untersuche, d.h. logge die Daten während der Prozess/Rule Ausführung. Einfaches System: was geht rein, wann wird welche Variable verändert, stimmt das und was kommt am Ende raus. Stelle sicher, dass die Datenintegrität erhalten bleibt und keine unerwarteten Transformationen oder Verluste auftreten.
- Testen von Randfällen: Führen Sie Tests mit verschiedenen Eingabedaten und Randfällen durch, um das Verhalten der Schnittstelle oder der ETL-Strecke unter verschiedenen Bedingungen zu überprüfen. Dies kann helfen, seltene oder unerwartete Fehlerzustände zu identifizieren.
- Zusammenarbeit mit anderen Teams: Das Backup Skript auf dem neuen RHEL Server wird nicht ausgeführt, aber die Rechte vom TM1 Service User sollten passen? Klar schmunzelt der Linux Admin, wenn nur root User ins Backup Verzeichnis schreiben dürfen. Ihm ist aber bewusst, dass er (wahrscheinlich) keine C von N Rule unterscheiden kann. Gleiches gilt, wenn das SingleSignOn Verfahren eingerichtet wird und der Cognos Analytics Content Store keine Fehler loggt. „Hey DBA, kannst mal schauen, ob ich eine Session auf der Oracle DB bekomme?!“
- Root Cause Analysis (RCA): RCA, Fehlerbaum oder Fehler-Ursache-Analyse. Führe bei Bedarf eine strukturierte TM1 Fehleranalyse durch, notiere dir die Punkte. Nur so lassen sich zugrunde liegenden Ursachen des Fehlers identifizieren und geeignete Maßnahmen zur Behebung zu entwickeln.
Eigentlich warst du du auf der Suche nach einem spezifischem TM1 Fehler? Google bringt dich nicht weiter? Vielleicht kann ich bei deinem Fehler weiter helfen! 1 Stunde kostenlos & unverbindlich Adhoc TM1 Fehleranalyse – überzeuge dich selbst von der Qualität meiner Arbeit.
