Workflowinstanz

Dieses Kapitel beleuchtet den Lebenszyklus einer konkreten Workflowinstanz: Vom Anstoß im ERP-System über das Polling der Engine bis hin zur Fehlerbehandlung und Persistenz.

Start aus microtech

Eine Workflowinstanz wird nicht über einen aktiven Push-Mechanismus (wie Webhooks) gestartet, sondern durch das aktive Polling der Workflow-Engine.

Die Engine durchsucht regelmäßig die Tabelle tblTransactions in den angebundenen microtech-Mandanten. Dabei wird nach Datensätzen gesucht, die einen spezifischen Startmarker tragen. Im Standardfall wird das Feld fldSel30312 auf den Wert Workflow angefordert geprüft.

Sobald ein passender Datensatz gefunden wird, extrahiert die Engine die notwendigen Startparameter:

• Workflow-Name: Aus dem Feld fldSel30313 wird ermittelt, welcher Blueprint (z.B. „Rechnungsfreigabe“) gestartet werden soll.
• Objekt-Referenz: Die Belegnummer (fldBelegNr) dient als eindeutige fachliche Referenz.
• Initialnotiz: Eventuelle Bemerkungen aus fldInExtBeaInfo werden als erster Kontext in den Workflow übernommen.

Polling-Verhalten und Performance

Die Häufigkeit, mit der die Engine nach neuen Workflows sucht, ist konfigurierbar. In der aktuellen Produktionsumgebung ist das Polling-Intervall auf 1 Minute festgelegt.

Das bedeutet, dass das System alle 60 Sekunden prüft, ob in den angebundenen microtech-Mandanten neue Aufgaben zur Bearbeitung bereitstehen.

In jedem Polling-Durchlauf prüft die Engine alle aktiven Kunden und deren Mandanten. Um die Systemlast zu optimieren, werden die Daten seitenweise (Paging) abgerufen, wobei bis zu 100 Treffer pro Abfrage verarbeitet werden können.

Zustände einer Instanz

Während ihres Laufs durchläuft eine Instanz verschiedene technische und fachliche Zustände:

Übersicht der Instanz-Zustände

Zustand	Typ	Beschreibung
OPEN	Aktiv	Der Workflow befindet sich in regulärer Bearbeitung. Ein Benutzer oder eine Gruppe ist zugewiesen.
RETRYING_MICROTECH	Aktiv (Wiederholung)	Externe Synchronisation mit microtech ERP ist temporär blockiert (z. B. Beleg im ERP geöffnet). Das System wiederholt den Schreibversuch mit exponentiellem Backoff.
APPROVED	Endzustand	Alle Freigabeschritte wurden erfolgreich durchlaufen und der Beleg im ERP aktualisiert.
REJECTED	Endzustand	Ein Bearbeiter hat den Vorgang fachlich abgelehnt. Der Beleg wird im ERP dauerhaft gesperrt.
COMPLETED	Endzustand	Workflow erfolgreich beendet (bei Prozessen ohne explizite Freigabe-/Ablehnungslogik).
CANCELLED	Endzustand	Der Vorgang wurde durch einen Tenant-Administrator administrativ beendet. Der Beleg in microtech ERP wird sofort entsperrt und die Steuerungsfelder werden zurückgesetzt.
TRIGGER_NOT_MATCHED	Endzustand	Die Objektdaten erfüllten beim Start die im Blueprint hinterlegte Bedingung (trigger.nextStep.condition) nicht. Die nicht erfüllte Regel wird im Protokoll und im ERP ausgewiesen.

Blueprint-Inspektion zur Laufzeit

Jede Workflow-Instanz ist fest an die Version des Blueprints gebunden, mit der sie gestartet wurde. Um Nachvollziehbarkeit und Fehlersuche zu gewährleisten, stellt ConnectWORKFLOW für jede Instanz eine Blueprint-Vorschau bereit:

• Abruf: Über das Portal können Benutzer und Administratoren direkt an der Aufgabe oder in der Instanzenliste die Blueprint-Definition öffnen.
• Grafische Visualisierung: Das Portal rendert den Blueprint über die Komponente WorkflowCanvas als interaktiven Graphen aller Schritte, Verzweigungen und Bedingungen.
• YAML-Quelltext: Die bereinigte Blueprint-Definition kann im YAML-Format eingesehen und per Klick in die Zwischenablage kopiert werden.

Wichtige Datenfelder

Jede Instanz führt einen „Rucksack“ an Daten mit sich, der über die gesamte Laufzeit erhalten bleibt:

• currentStep: Zeigt an, in welchem Schritt des Blueprints sich der Workflow gerade befindet.
• claimedBy: Dokumentiert den aktuellen Besitzer einer Aufgabe (siehe Aufgabeaktionen). Um Blockaden zu vermeiden, wird die Übernahme nach 24 Stunden automatisch aufgehoben.
• history: Eine lückenlose, revisionsfähige Spur aller Aktionen, Zeitstempel und beteiligten Personen.
• data: Ein flexibler Datenspeicher für prozessrelevante Zusatzinformationen und Zwischenstände.

Fehlerbehandlung und Retrying

Da die Synchronisation mit microtech eine externe Schnittstelle betrifft, kann es zu technischen Störungen kommen. Typische Ursachen für Synchronisationsfehler sind:

• Unerreichbarkeit: Die microtech-Schnittstelle (GraphQL) ist temporär nicht erreichbar oder das Netzwerk ist gestört.
• Datensatz-Sperren: Die Zieltabelle (z.B. tblTransactions) oder der spezifische Beleg wird gerade in microtech durch einen Benutzer bearbeitet. Ein offener Vorgang im ERP blockiert den Schreibzugriff für die Workflow-Engine.

In solchen Fällen wechselt die Instanz automatisch in den technischen Zustand RETRYING_MICROTECH.

Die Retry-Strategie

Das System nutzt eine exponentielle Wiederholungs-Strategie, um kurzzeitige Störungen selbstständig zu beheben und überbrückt dabei einen Zeitraum von insgesamt ca. 30 Minuten:

• 1. Versuch: Nach 1 Minute
• 2. Versuch: Nach weiteren 2 Minuten
• 3. Versuch: Nach weiteren 4 Minuten
• 4. Versuch: Nach weiteren 8 Minuten
• 5. Versuch: Nach weiteren 16 Minuten

Verhalten bei endgültigem Fehlschlagen

Sollte auch der fünfte Versuch (nach über 30 Minuten) fehlschlagen, wird der automatische Prozess abgebrochen und die Instanz wieder in den Zustand OPEN versetzt. Dabei geschieht Folgendes:

• Fehlermarkierung: Die Instanz erhält eine interne Markierung (sync_error_note).
• Sichtbarkeit: Der Bearbeiter der Aufgabe sieht in der Workflow-Oberfläche einen deutlichen Hinweis auf das Problem (z.B. „Das Ergebnis des Workflows konnte nicht in microtech geschrieben werden...“). Auch in der Prozess-Historie wird der Fehler als System-Eintrag protokolliert.
• Erwartete Reaktion: In diesem Fall muss der Benutzer manuell eingreifen. Da der Datensatz in der Cloud noch im Zustand des letzten Schritts verharrt, ist das erwartete Verhalten, die gewünschte Aktion (z.B. Freigabe/Ablehnung) in der Workflow-Oberfläche erneut anzustoßen, sobald die Ursache im ERP (z.B. den offenen Beleg schließen) behoben wurde.

Persistenz und Nachvollziehbarkeit

Nach jedem abgeschlossenen Schritt wird der aktuelle Stand der Instanz inklusive der gesamten Historie dauerhaft gespeichert (persistiert). Dies stellt sicher, dass auch bei einem Systemneustart oder einem schwerwiegenden Fehler keine Prozessdaten verloren gehen und jeder Schritt jederzeit auditierbar bleibt.