UC4 selber bietet viele Hilfsmittel, um über Fehler informiert zu werden: CALL Operatoren, Verhalten bei Returncodes in Plänen, Einstellungen in vielen UC4 Objekten selber. Dennoch bleiben viele Fehlersituationen übrig, über die UC4 nicht informiert bzw. informieren kann: bspw. Abbrüche mit FAULT_OTHER oder blockierte Abläufe. Im folgenden stelle ich einige Lösungen vor, die ich in den unterschiedlichen Installationen eingerichtet und eingesetzt habe.

Abbrüche mit FAULT_OTHER

Mit Abbrüchen im Zustand FAULT_OTHER tut sich UC4 ein wenig schwer, den Fehler zu signalieisern. Tritt ein solcher Fehler in einem Plan auf, so läßt er sich u.U. nach abfangen. Tritt er aber bei einem in einem Scheduler gestarteten Objekt auf, so ist das nicht mehr möglich. Grund hierfür ist, daß FAULT_OTHER Fehler vor oder während der Generierungsphase auftreten, und zu diesem Zeitpunkt die bewährten Mittel für das Alerting noch nicht aktiv sind.

Eine Kombination aus Java, UC4 Script und Job ist in der Lage, solche Abbrüche zuverlässig zu finden.

Die Java-Klasse sucht für einen vorgegebenen Zeitraum nach allen Objekten, welche im Status FAULT_OTHER abgebrochen sind. FAULT_OTHER entspricht dem UC4 Systemcode 1820. Diese Objekte werden in eine VARA gestellt, zusätzlich mit den Informationen der Runnumer (sofern vorhanden), des Parents mit seiner Runnummer sowie der Aktivierungszeit der gefundenen Objekte.

Das UC4 Script faßt die gefundenen Abbrüche so zusammen, daß gleiche Adressaten (oder gleiche Anwendungen) nur eine email über die Abbrüche erhalten. Wie dieses Zusammenfassen aufgesetzt wird, hängt maßgeblich von der einzelnen Installation ab. Bspw. werden in einer Installation die Batch nach Applikationen aufgeteilt, und Addressaten für Abbrüche etc. können nach diesen Applikationen konfiguriert werden. Damit bestimmt das Script, an welche Applikationen FAULT_OTHER Abbrüche gemeldet werden sollen.

Abschließend wird an jeden der gefundenen Adressaten eine email verschickt, in der alle Objekte aufgelistet sind, die im angegebenen Zeitraum mit FAULT_OTHER abgebrochen sind. Hierzu bietet sich ein UNIX Job an, da unter UNIX alle erforderlichen Hilfsmittel standardmäßig vorhanden sind.

Die wichtigsten Informationen des Ablaufes - also der Zeitraum, der durchsucht werden soll, eventuell zu überschreibende Empfänger für einzelen Applikationen, oder Applikationen, für welche keine Fehler gemeldet werden sollen - lassen sich zentral in einer UC4 VARA konfigurieren.

Blockierte Abläufe

Wer kennt das nicht aus seiner Installation: da bricht ein Ablauf ab, und bleibt im Aktivitätenfenster stehen - für Tage oder gar Wochen. Was für sich gesehen erst einmal nur ärgerlich ist, kann in der Summe richtig Mühen bereiten: denn UC4 benötigt vergleichsweise viele Ressourcen, um das Aktivitätenfenster zu verwalten.

Um hier Abhilfe zu schaffen bieten sich unterschiedliche Ansätze an:

• man kann das Aktivitätenfenster periodisch automatisiert bereinigen. Dies ist sicher nicht die schlechteste Lösung. Sie hat allerdings den Nachteil, daß der Nachläßigkeit, sich um abgebrochene Abläufe zu kümmern, Vorschub geleistet wird.
• man kann für jeden blockierten Ablauf die Kollegen informieren, die diesen Ablauf betreuen. Diese Lösung hat den Vorteil, die Kollegen zu informieren, und - vielleicht - dahingehend zu erziehen, daß sie blockierte Abläufe zügig bereinigen.

Sinnvoll ist vielleicht auch eine Kombination aus beiden Ansätzen:

• Abläufe, die abgebrochen und nicht mehr akltiv sind, werden automatisiert deaktiviert und verschwinden damit aus dem Aktivitätenfenster.
• Abläufe, die abgebrochen sind, aber noch aktiv sind (Status BLOCKED), werden an die zuständigen Kollegen gemeldet mit der Bitte, sich um die Abbrüche zu kümmern.

Beide Lösungen lassen sich wieder mit einer Java Klasse sowie UC4 Scripten und Jobs umsetzen.

Automatisches Deaktivieren

Das automatische Deaktivieren wird von einer Java Klasse ausgeführt, welche das Aktivitätenfenster ausliest und alle Tasks löscht, welche länger als eine bestimmte Zeit aktiv sind, und welche nicht aktiv laufen. Es werden also nur solche Tasks deaktiviert, welche wirklich beendet sind. Der Zeitraum, für welchen Task im Aktivitätenfenster stehengelassen werden, ist konfigurierbar. Für die Testumkgebungen haben sich drei Tage als sinnvolle Größe erwiesen (dann lassen sich Montags noch Abbrüche vom vorherigen Freitag analysieren und ggf. nachstarten), für die Produktion 40 Tage (damit steht etwas mehr als einen Ultimo noch zur Verfügung).

Die Klasse wird täglich aufgerufen.

Benachrichtigen bei blockierten Abläufen

Die Benachrichtigung bei blockierten Abläufen arbeitet ähnlich wie das Deaktivieren:

• zuerst werden alle aktiven Jobpläne im Aktivitätenfenster gesucht. Das erfolgt mit einer Java Klasse.
• in einem zweiten Schritt werden jedoch alle Pläne ausgesucht, welche sich im Status 1560 befinden. Status 1560 bedeutet, daß der zugehörige Workflow blockiert ist.
• in einem dritten Schritt werden alle gefundenen blockierten Jobpläne in einer email zusammengefaßt und and die zuständigen Kollegen verschickt. Dabei werden die blockierten Jobpläne wieder nach Applikationen zusammengefaßt.

Der Zeitraum, ab dem blockierte Jobpläne gemeldet werden sollen, ist ebenfalls konfigurierbar. Als Schwellwerte für die Zeit, ab der blockierte Abläufe gemeldet werden, eignen sich in Test- wie Produktionsumgebungen fünf bis sieben Tage - in dieser Zeit sollten ersthafte Batche korrigiert werden. Blockaden, welche nach diesem Zeitraum immer noch vorhanden sind, sollten auf ihre Notwendigkeit hin untersucht werden.