Aegis-Praxistest, Teil 3 – Definition von Triggern, Events und Prozessen

Der Prozess wird komplettiert

Für die weitere Verarbeitung wird eine eindeutige Bestell-ID generiert. Für unseren Test wählten wir den Klassiker: den UNIX-Zeitstempel (siehe: Galerie Abbildung 5). Der Name des Empfängers, der Zeitstempel und der Text aus der E-Mail werden nun in die zuvor vorbereitete Datenbank per SQL-Kommando übergeben (siehe: Galerie Abbildung 6).

Die bisherigen Arbeitsschritte des Prozesses werden dann mit dem „Connection Tool“ miteinander verbunden. Die Reihenfolge der Verbindungen gibt die Abarbeitungsreihenfolge der Schritte an. Mit einem Klick auf „Validate Workflow“ werden die logischen Verbindungen der Arbeitsschritte geprüft. Findet sich ein „Loch im Prozess“, so wird eine Warnung ausgegeben (siehe: Bild 7).

Die weiteren Arbeitsschritte wurden in derselben Vorgehensweise eingefügt: Die Prüfung der aktuell in der Datenbank noch offenen Bestellung, als simpler Select auf die Datenbank (siehe: Galerie Abbildung 8) oder die Antwort-Mail an den Absender mit der Angabe der Dauer (siehe: Galerie Abbildung 9). Der Ausdruck der Bestellung in die virtuelle Pizza-Küche wurde über das LPR-Kommando realisiert (siehe: Galerie Abbildung 10) – sofern dieses Kommando nicht innerhalb der Standardwartezeit eine positive Rückmeldung gibt, verzweigt sich der Prozess und eine Benutzerinteraktion über das Webinterface wird eingefordert (siehe: Galerie Abbildung 11).

Wie bereits erwähnt, ließe sich hier eine schier endlose Kette an alternativen Lösungswegen zur Abarbeitung dieses Schritts hinterlegen.

So entsteht innerhalb kürzester Zeit, und wir schreiben hier von wenigen Stunden oder Minuten und nicht Tagen, ein Prozess über verschiedenste Techniken, ohne dass sich der Prozess-Designer über die individuellen Strukturen Gedanken machen muss (siehe: Bild 12). Ist der Prozess voll einsatzfähig, so wird er für den Produktivbetrieb freigegeben und funktioniert von nun an automatisch.

Überwachung von Netzwerken

Ob ein Prozess einmalig, n-mal oder gar unendlich oft gestartet werden kann, ob er parallel betrieben wird und wenn ja, in wie vielen Instanzen des Prozesses, so genannte „Work Items“, obliegt dem Prozess-Designer. Wird Aegis beispielsweise zur Überwachung von Server- und Netzwerksystemen eingesetzt, so wird der Prozess-Designer hocherfreut darüber sein, dass Ereignisse zeitlich voneinander getrennt oder kombiniert werden können. Tritt beispielsweise ein physikalischer Fehler auf einer Festplatte auf, so ist es in den meisten Fällen unnötig, den Administrator Sekunden später über logische Festplattenfehler zu informieren.

Aegis einzig und allein für die Überwachung von Systemen einzusetzen würde die Fähigkeiten des Systems in keinster Weise ausnutzen. Hier geht es darum, Aktionen im Einklang mit einem Ereignis automatisiert durchzuführen, ohne dass ein Mitarbeiter zu reagieren hätte. Dazu gehört etwa, auf die eben erwähnten physikalischen Festplattenfehler eines Terminalservers durch das Starten eines virtuellen Terminalservers zu reagieren und diesen in einen NLB-Verbund zu überführen. Ist die neue Maschine verfügbar, werden die Anwender auf dem defekten Server über einen anstehenden „Disconnect“ informiert, der nach einer frei definierbaren Zeit automatisch greift…

weiter mit: Workflows in XML wandeln

(ID:2041739)