Wie unsere Plattform gebaut ist

Dazwischen liegt unser Service-Proxy. Er legt eine vereinheitlichte REST-Schnittstelle darüber, die die Begriffe abbildet, mit denen tatsächlich gearbeitet wird: Vorgang, Aufgabe, Zuständigkeit, Zustand.

Die Adressen sind so geschnitten, dass sie sich weiterverwenden lassen. Ein Link auf einen einzelnen Vorgang funktioniert in einer E-Mail, in einem Ticket, in einem Portal oder in einem fremden System – ohne dass jemand vorher eine Sitzung aufbauen muss.

Zwei Folgen daraus. Die Schnittstelle bleibt stabil, auch wenn sich darunter etwas ändert; Versionswechsel der Engine wandern also nicht in Ihren Code. Und der Proxy trägt Funktionen, die die Engine selbst nicht mitbringt – er ist nicht nur eine Hülle, sondern die Stelle, an der ergänzt wird.

Prozesse laufen lang. Ein Vorgang ist Tage unterwegs, oft Wochen, manchmal Monate. In dieser Zeit ändern sich Adressen, Preise, Zuständigkeiten, Lieferzeiten, Stammdaten – nur eben nicht in dem, was der Prozess bei seinem Start einmal übernommen hat. Was er hält, ist eine Momentaufnahme, und sie altert ab dem ersten Tag.

Verlässlich ist ein Prozess deshalb ausschließlich für seinen eigenen Verlauf: welcher Zustand, welche Entscheidung, wann, durch wen. Alles andere holt er sich in dem Moment, in dem es gebraucht wird – aus Ihrem ERP, Ihrer Dokumentenablage, Ihrer Fachdatenbank.

Wann immer man erwägt, einen Datensatz in die Verwaltung eines Prozesses zu geben, obwohl es ihn in einem anderen System bereits gibt, sollte man deshalb genau hinsehen. Im Zweifel ist das angebundene System dasjenige mit der Wahrheit. So entsteht keine zweite Wahrheit, die irgendwann von Ihrer abweicht, und keine Synchronisation, die jemand überwachen müsste.

Das Muster stammt aus der serviceorientierten Architektur und ist bewusst alt. Die Prüffrage dazu, die man nicht wörtlich nehmen muss, aber ernst: Über die Adapter muss sich ein Vorgang bedienen lassen, auch wenn das Prozessmodell nicht mehr da wäre. Wir orchestrieren Dienste – wir sind keine zweite Fachanwendung.

Wer wissen will, was in einem Angebot steht, fragt das ERP. Wer wissen will, wie lange es in der Freigabe lag, fragt uns. Und wer beides zusammen mit den Daten aus drei weiteren Anwendungen direkt am Arbeitsschritt sehen will, erweitert die Oberfläche um die entsprechenden Widgets – ohne dass dafür Daten dupliziert werden müssten.

Deshalb spiegeln wir diese Prozessdaten zusätzlich in eine strukturierte Ablage. Damit werden Suchen über alle Parameter möglich, Auswertungen über den Bestand und die Übergabe an andere Systeme.

Auf den Ablauf hat das keinen Einfluss. Die Spiegelung ist eine Lesesicht, nichts weiter. Die Engine bleibt unverändert, sie steuert weiterhin allein den Prozess, und im Zweifel gilt immer der Stand in der Engine. Wir werden dadurch aber schneller und fachlich flexibler, ohne dass irgendwo eine zweite Quelle der Wahrheit entsteht.

Und weil wir die Engine dafür nicht angefasst haben, gibt es keinen eigenen Zweig, den wir pflegen müssten. Ein Versionswechsel bleibt ein Versionswechsel und wird kein Projekt.

Jeder Aufruf an ein Fremdsystem wird protokolliert: Zeitpunkt, Dauer, Umfang der Antwort, Ergebnis. Damit wird Fehlersuche im Nachhinein möglich – auch für den Fehler von vor zwei Wochen, der in den Systemprotokollen längst überschrieben ist. Und Auffälligkeiten werden erkennbar, bevor etwas ausfällt: eine Schnittstelle, die langsamer antwortet als im Vormonat, ein Mengengerüst, das sich verschoben hat.

Das Verhalten im Fehlerfall wird je Schritt festgelegt, nicht pauschal für die ganze Anwendung. Anzahl der Wiederholversuche, Wartezeit dazwischen und die Reaktion gegenüber dem Ticketsystem sind Parameter.

Der Grund dafür ist praktisch. Ein Aufruf, der im Hintergrund ein paar Daten nachlädt, darf es mehrfach versuchen und dabei eine Warnung erzeugen, damit ein Administrator gelegentlich daraufsieht. Derselbe Aufruf, der eine Maske für einen wartenden Sachbearbeiter füllen soll, hat diese Geduld nicht – dort ist der erste Fehlversuch bereits ein Störfall und wird als solcher gemeldet.

Alle Schritte sind zusätzlich über Merkmale zu System, Prozess und Fall gekennzeichnet. Das klingt nach Buchhaltung und zahlt sich später aus: In der Auswertung sieht man dadurch Zusammenhänge, die sonst niemandem auffallen würden – etwa dass die Störungen eines Prozesses sämtlich an einem einzigen Drittsystem hängen.

Zur Kompensation sagen wir nichts Allgemeines

Was passiert, wenn ein Schritt gelungen ist und ein späterer scheitert? Das ist die schwierigste Frage der Prozessautomatisierung, und sie war es immer. Wo die Fachlichkeit sie beantwortet, ist sie leicht: Flug gebucht, Sitzplatz nicht verfügbar, also stornieren und neu beginnen. In einer Kette interner Schritte ist es meist nicht so einfach, weil viele Schnittstellen von sich aus keine Rücknahme anbieten. Dann wird die Kompensation selbst zu einem fachlichen Ablauf, den man modellieren muss.

Die nötigen Festlegungen kommen erfahrungsgemäß nie von allein aus dem Fachbereich – nicht aus Nachlässigkeit, sondern weil im Alltag niemand darüber nachdenkt, was im Falle einer Automatisierung passieren soll, wenn ein Vorgang mittendrin abbricht.

Deshalb gehört diese Frage in die Analyse und nicht in ein Datenblatt. Wir versprechen hier nichts. Wir stellen sie aber, bevor gebaut wird.

Unter der Anwendung läuft IBM Business Automation Manager Open Editions. Die Bausteine darunter – Drools für Regeln, jBPM und Kogito für Prozesse – sind quelloffen und stehen inzwischen als Apache KIE unter dem Dach der Apache Software Foundation. Verfügbar wären sie also auch ohne Hersteller.

Wir setzen trotzdem auf den kommerziell gepflegten Stand, und zwar aus zwei Gründen. Erstens gibt es dort einen versionierten Auslieferungsstand mit Veröffentlichungsplan und Sicherheitsaktualisierungen. Zweitens gibt es einen Weg für die Fälle, die man vorher nicht kennt: Sitzt ein Problem tief in der Engine, können wir es als Partner eskalieren. Ohne diese Möglichkeit könnten wir unsere Zusagen nicht machen.

Und der Punkt, auf den es ankommt: Weil der Proxy die Engine vollständig kapselt, ist sie austauschbar. Was darunterliegt, muss nur dieselbe Schnittstelle bedienen – die kommerzielle Fassung oder die freie Apache-KIE-Installation. Ihre Prozessmodelle, Ihre Oberflächen, Ihre Adapter und Ihre Daten bleiben davon unberührt.

Was Sie dabei verlieren würden, sagen wir dazu: Sie stellen sich die Umgebung selbst zusammen, es gibt keinen Veröffentlichungsplan, keine Sicherheitsaktualisierungen aus einer Hand und niemanden, der im Ernstfall geradesteht. Wir empfehlen es nicht. Aber es ist Ihre Entscheidung und nicht unsere.