Wer aus der PowerCenter-Welt kommt, kennt das Gantt-Chart im Workflow Monitor: Man sieht auf einen Blick, welche Session wann gelaufen ist, wie lange sie gebraucht hat und wo es gehakt hat. In der IDMC habe ich so eine Ansicht immer vermisst. Dort sehe ich die Läufe als zeitsortierte Liste, ohne Zeitachse, ohne Verschachtelung und ohne Vergleich mit früheren Läufen. Über die Schnittstelle JobLogEntries liefert die IDMC laut Doku außerdem nur die letzten 33 Tage.
Deshalb habe ich mir einen eigenen Laufzeit-Monitor gebaut. In diesem Artikel zeige ich euch, was er kann und woher er seine Daten bekommt.
Das Gantt-Chart
Der Monitor ist eine Webanwendung. Auf der Startseite steht das Gantt-Chart: waagerecht die Zeit, je Lauf ein Balken. Die Zeilen bilden einen aufklappbaren Baum aus Org, Projekt, Ordner und Asset, wobei jedes Asset eine Zeile bekommt und nicht jeder einzelne Lauf. So sieht das aus:
Die Daten im Bild sind erfunden. Ich habe den Monitor für den Screenshot gegen einen lokalen Nachbau der IDMC-Schnittstellen laufen lassen, den ich auch für die Tests nutze.
Der Status steckt in der Farbe des Balkens und zusätzlich in einem Zeichen, etwa ✕ für fehlgeschlagen oder ▲ für eine Warnung. So bleibt er auch ohne Farbsehen erkennbar. Oben fasst ein Satz die Lage zusammen, zum Beispiel „Ein Lauf ist fehlgeschlagen, sonst läuft alles.“, daneben stehen die Zähler je Status. Ein zugeklappter Knoten zeigt ein Band in der Farbe seines schlechtesten Laufs, damit ein Fehler nicht im Baum verschwindet.
Beim Öffnen zeigt der Monitor immer die letzten 24 Stunden mit einer Linie für „jetzt“. Den Zeitraum kann man frei wählen, höchstens 31 Tage am Stück. Gezoomt wird in zehn Stufen vom ganzen Zeitraum bis zu einer Minute. Dazu gibt es Filter nach Status, Asset-Typ und Name sowie die Schnellauswahl „Nur Fehler“. Über einen Rechtsklick auf einen Balken springt man zum vorherigen oder nächsten Lauf desselben Assets. Zeitraum, Zoom, Filter und aufgeklappte Knoten stehen in der Adresse der Seite, eine Ansicht lässt sich also als Link weitergeben.
Details und Logs
Ein Klick auf einen Balken öffnet die Details des Laufs: Kopfdaten, Zeilenzahlen und gegebenenfalls die Fehlermeldung. Praktisch finde ich den Vergleich mit den Vorläufen. Der Monitor zeigt den Median und das 10. bis 90. Perzentil der Dauer der letzten 30 erfolgreichen Läufe desselben Assets. Gibt es weniger als fünf, steht dort „zu wenige Vorläufe“ statt einer Zahl. Ein Satz in Klartext fasst das Ergebnis zusammen, etwa „Um 06:13 abgebrochen, nach 13 min statt üblich 48–55 min.“
Das Log eines Mapping Tasks oder Taskflows holt der Monitor bei Bedarf direkt aus der IDMC und speichert es nicht. Im Log kann man mit * und ? suchen und sich nur die Trefferzeilen anzeigen lassen.
Taskflows und ihre Schritte
Im Workflow Monitor standen die Sessions unter ihrem Workflow. Genauso stehen im Monitor die Läufe, die ein Taskflow gestartet hat, unter diesem Taskflow, auch über mehrere Ebenen. Die Verbindung zwischen Taskflow und Kindlauf liefert die IDMC im Feld parentEntityId.
Die Pfeile zwischen den Balken kommen aus der Definition des Taskflows, denn nur sie kennt die Reihenfolge der Schritte. Dafür sucht der Monitor einmal am Tag die Taskflows heraus, zu denen er Läufe gespeichert hat, exportiert neue oder geänderte Definitionen und speichert die veröffentlichten Fassungen, höchstens 50 Taskflows je Exportauftrag. Fehlerpfade werden gestrichelt gezeichnet. Bricht ein Taskflow ab, weil ein Schritt gar nicht erst starten konnte, erscheint dieser Startfehler als eigene Zeile mit ✕.
Woher die Daten kommen
Eine Push-Schnittstelle für Jobläufe bietet die IDMC nicht, der Monitor fragt also regelmäßig nach. Er nutzt dafür vier Schnittstellen:
| Schnittstelle | Wofür im Monitor |
|---|---|
JobLogEntries |
Historie: beendete Läufe mit Eltern-Kind-Beziehung, Projekt, Agent und Zeilenzahlen in einer Abfrage |
activityMonitor |
laufende Mapping Tasks samt Zeilenzähler |
activityLog |
gerade beendete Mapping Tasks und Details |
tf/status |
laufende und beendete Taskflows mit ihren Schritten |
JobLogEntries würde fast allein reichen, wird in meinen Messungen aber nur stündlich aufbereitet, mit 10 bis 72 Minuten Verzögerung. Für die lebende Kante des Gantt-Charts braucht es deshalb die drei anderen Quellen. Welche Fallen dabei auf euch warten, von Zeitstempeln in Eastern Time mit Z-Suffix bis zu Kennungen, die mal als String und mal als Zahl kommen, habe ich im Artikel IDMC-Jobläufe per REST-API überwachen beschrieben.
Ein Hintergrundprozess fragt die Quellen in festen Takten ab und schreibt alles in eine eigene Datenbank:
Laufende Jobs fragt der Monitor alle 5 Sekunden ab, ohne laufende Jobs alle 10 Sekunden, die Historie alle 15 Minuten. Beim ersten Einschalten lädt er die gesamten 33 Tage, die JobLogEntries hergibt. Danach behält er die Läufe selbst, in der Voreinstellung 400 Tage. Meldet sich ein Lauf nicht mehr, gilt er nach 75 Minuten als „noch nicht bestätigt“ und nach drei Stunden als „Verbleib unbekannt“, schraffiert statt farbig.
Wichtig war mir, dass der Monitor nur liest. Die einzige Ausnahme sind die Exportaufträge für die Taskflow-Definitionen. Dafür muss der Benutzer, mit dem sich der Monitor an der Org anmeldet, Assets exportieren dürfen.
Secure Agents im Blick
Neben dem Gantt-Chart gibt es einen zweiten Bereich, den standardmäßig nur Administratoren sehen. Er zeigt je Org die Secure Agents und ihre Dienste und vergleicht jede Minute den Ist- mit dem Sollzustand. Auslastungswerte zeigt er nicht, weil die API keine liefert.
Ein Dienst gilt als gestört, wenn Ist und Soll voneinander abweichen und das über mehrere Abfragen so bleibt. Scheitert dagegen nur der Abruf selbst, steht dort „unbekannt“ und nicht „gestört“. Gemailt wird nur, wenn sich ein Zustand ändert, und es folgt eine Entwarnung. Fällt ein ganzer Agent aus, kommt eine Mail statt einer je Dienst. Fehlgeschlagene Läufe meldet der Monitor ebenfalls per Mail, eine je Lauf auf oberster Ebene. Die Empfänger legt man je Org und Anlass fest.
Betrieb und Technik
Der Monitor ist in Python geschrieben, mit FastAPI, Jinja2 und HTMX. Das Gantt-Chart ist handgeschriebenes SVG mit wenig eigenem JavaScript, ohne Diagrammbibliothek. Als Datenbank dient SQLite oder PostgreSQL. Webanwendung und Hintergrundprozess laufen getrennt und verständigen sich nur über die Datenbank.
Für den Betrieb gibt es drei Wege: als Container (mit PostgreSQL per Compose), als Linux-Dienst über systemd oder als Offline-Paket für Server ohne Internetzugang. Anmelden kann man sich lokal, per LDAP bzw. Active Directory oder per OIDC. Über die Rollen Administrator, Bearbeiter und Betrachter und die Freigabe einzelner Orgs je Benutzer oder Gruppe sieht jeder nur die Orgs, die ihn betreffen. Die Oberfläche gibt es auf Deutsch und Englisch.
Entstanden mit Spec-driven Development
Bevor ich mit dem Monitor selbst angefangen habe, stand eine Vorstudie mit kleinen Messskripten gegen eine produktive Org: Welche Schnittstelle liefert was, wie schnell und in welcher Zeitzone? Erst mit diesen Messungen ist die Spezifikation entstanden. Daraus wurden 13 Meilensteine mit 89 Arbeitspaketen. Umgesetzt habe ich sie mit Claude Code nach dem Ablauf, den ich im Artikel Spec-driven Development mit Claude Code beschrieben habe. Zwischen der Vorstudie am 7. September und dem Stand vom 15. Oktober 2026 liegen 305 Commits.
Wie ihr seht, bekommt man mit den REST-Schnittstellen der IDMC ein Gantt-Chart wie im Workflow Monitor, man muss es sich nur selbst bauen. Den Monitor stelle ich Kunden auf Anfrage zur Verfügung. Falls ihr ihn einsetzen möchtet oder Fragen dazu habt, schreibt mir gerne.
Autor
