ConnectCLOUDDocs

Appearance

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.

Ein Workflow beginnt immer im Zustand OPEN. Er verbleibt in diesem Zustand, solange Aufgaben zu erledigen sind. Erst wenn ein definierter Endpunkt im Blueprint erreicht wird, wechselt die Instanz in einen finalen Status wie APPROVED, REJECTED oder COMPLETED.

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.