Automationen (Webhooks & API-Connectors)

Der durchgängige Automations- und Integrationsprozess in der betrieblichen Praxis

Moderne ERP-Systeme operieren nicht als isolierte Datensilos, sondern als hochgradig vernetzte Orchestrierungsplattformen. Das Modul automations in Centurio ERP schlägt die Brücke zwischen externen Drittsystemen, KI-Agenten und den internen Fachmodulen.

1. Universal Integration Platform (UIP) & Connector SDK

Unternehmen nutzen spezialisierte Softwarelösungen (z.B. Branchen-Webshops, CAD-Systeme, Speditionsportale, Zeiterfassungsterminals, Zahlungsdienstleister). Das Modul löst dieses Problem über die Universal Integration Platform (UIP):

• Connector SDK: Anstatt für jedes Fremdsystem proprietären Code in Kernmodule zu schreiben, implementieren Konnektoren die standardisierten SDK-Methoden: connect(), discover(), query(), sync(), export().
• Kanonisches Datenmodell (CDM - Canonical Data Model): Heterogene Drittsystem-Payloads (z.B. JSON eines Shopify-Webhooks, XML einer EDIFACT-Nachricht oder CSV eines Spediteurs) werden über Mapping-Profile in das einheitliche kanonische Datenmodell von Centurio ERP transformiert.
• Entkopplung: Änderungen an externen APIs berühren niemals die ERP-Kernlogik; lediglich das Adapter-Profil wird angepasst.

2. Sichere Webhook-Ingestion & Replay-Schutz (HMAC & Fingerprint)

Trifft ein externes Webhook-Ereignis ein (z.B. Online-Shop meldet bezahlte Bestellung oder Zahlungsdienstleister meldet Stripe-Transaktion):

• Kryptographische HMAC-Signatur: Das System verifiziert über den Header X-Hub-Signature-256 oder X-Signature mit dem im Mandanten hinterlegten Pre-Shared-Secret die Echtheit und Unverfälschtheit der Nachricht via HMAC-SHA256 (cap:automations.webhook.validate_hmac). Manipulierte Anfragen werden sofort mit HTTP 401/403 verworfen.
• Idempotenz-Fingerprint: Aus dem Payload-Inhalt und dem Event-Zeitstempel errechnet das System einen eindeutigen SHA-256 Fingerprint.
• Replay-Schutz: Wird dieselbe Nachricht durch Netzwerk-Timeouts oder Angreifer mehrfach gesendet, erkennt die Idempotenz-Prüfung das Duplikat und liefert die frühere Quittung zurück, ohne die Transaktion doppelt auszuführen.

3. No-Code Canvas Engine & DAG-Workflow-Kompilierung

Für individuelle Kundenabläufe bietet Centurio ERP den visuellen Canvas Workflow Editor im Workflow- & No-Code-Studio (/semantic/designer):

• Directed Acyclic Graph (DAG): Workflows werden als gerichtete azyklische Graphen modelliert. Der Canvas kennt diese Knotentypen (Palette):
  • Start/Ende: Jeder Ablauf hat genau einen Start (manueller Einstieg mit Datensatzkontext) und jeder Zweig endet in einem Ende-Knoten.
  • Bedingung (condition): Verzweigung nach Workflow-Regel; Ausgänge Ja/Nein, beide müssen verbunden sein.
  • Parallel aufteilen/zusammenführen (parallel_split/parallel_join): Startet bis zu 8 Zweige gleichzeitig bzw. wartet, bis alle Zweige angekommen sind.
  • Freigabe (approval): Human-in-the-Loop-Gate; pausiert bis zur Entscheidung einer Organisationsrolle (Genehmigt/Abgelehnt).
  • Formular (form_task): Interaktive Datenerhebung; Ausgänge Abgesendet/Abgebrochen, Antworten stehen Folgeschritten als Formularantworten zur Verfügung.
  • Fachaktion (operation): Aufruf genau einer geprüften, canvas-tauglichen System-Capability (z. B. Aufgabe anlegen, Belegstatus setzen); Eingabebindungen werden am Knoten geprüft.
  • Für jedes Element (for_each): Wiederholt die gebundene Fachaktion sequenziell für bis zu 32 Datensätze einer verknüpften Liste; Fehler halten zur Prüfung an.
  • KI-Vorschlag (agent): Ein Agent erarbeitet an dieser Stelle einen Entwurf — niemals direkte Ausführung.
  • Teilprozess (subprocess): Visueller Verweis auf einen anderen Ablauf; echte Unterausführung folgt mit geprüftem Adapter.
  • Wartezeit (timer), Signal senden/warten (emit_signal/wait_event), API-Connector (connector_call): Warten, Ereigniskopplung und geprüfte externe Schnittstellenaufrufe.
• Kompilierung in Ausführungspläne: Die Canvas-Engine übersetzt den visuellen Graphen in einen streng deterministischen Ausführungsplan (WorkflowRun), der schrittweise und transaktionssicher abgearbeitet wird.

4. Human-in-the-Loop Genehmigungsschranken (Approval Gates)

Kritische oder finanzrelevante Schritte dürfen in vielen Unternehmen nicht vollautonom durchlaufen:

• In den DAG können Human-in-the-Loop Gates eingefügt werden.
• Erreicht die Ausführung einen solchen Knoten, pausiert der Workflow im Zustand waiting_approval.
• Das System erzeugt eine blockierende Prüfaufgabe für den zuständigen Sachbearbeiter oder Manager (z.B. Rabatt von 25% freigeben).
• Erst nach digitaler Freigabe setzt die Engine den Graph an genau dieser Stelle fort.

5. Kaskadierung & Resilienz (Dead-Letter-Queue & Exponential Backoff)

Nicht jeder externe Server ist immer erreichbar; Netzwerke können schwanken:

• Transaktionale Outbox: Interne Ereignisse werden nicht synchron im HTTP-Request ausgeführt, sondern in die PostgreSQL-Outbox geschrieben und von Hintergrund-Workern zuverlässig verarbeitet (At-Least-Once Delivery).
• Exponential Backoff: Schlägt ein externer API-Aufruf fehl (z.B. Speditions-API antwortet mit 503), wiederholt das System den Versuch in steigenden Zeitabständen (1s, 2s, 4s, 8s, 16s...).
• Dead-Letter-Queue (DLQ): Schlägt auch der finale Wiederholungsversuch fehl, wird der Event-Datensatz in die Dead-Letter-Queue verschoben. Der Workflow bricht nicht unkontrolliert ab; Administratoren erhalten einen Alarm und können den Fehler beheben und den Schritt manuell erneut anstoßen.

6. Revisionssicheres Ausführungsjournal (Execution Audit Trail)

Jede Workflow-Ausführung, jede Webhook-Ingestion und jeder Konnektoren-Sync wird im revisionssicheren Ausführungsjournal (ExecutionJournalEntry) mit Zeitstempel, Eingabeparametern, Zwischenergebnissen, Benutzer- bzw. System-ID und Erfolgsstatus protokolliert. Dies garantiert lückenlose Nachprüfbarkeit bei IT-Audits und GoBD-Prüfungen.

KI-Consultant Blueprint: Customizing & No-Code Architektur

Anleitung für Solution Architects zur Erstellung kundenspezifischer No-Code Automationen.

1. Kundenanforderungsanalyse

• Welche Fremdsysteme sollen angebunden werden (z.B. WooCommerce-Shop, Datev-Connect, IoT-Sensoren)?
• Welche manuellen Routineaufgaben der Mitarbeiter sollen automatisiert werden (z.B. E-Mail-Auftragsbestätigung, Bestandsabgleich)?
• Wo müssen Schwellenwerte für menschliche Freigaben eingebaut werden?

2. No-Code Zusatzfelder (Custom Fields)

Im No-Code Studio (/semantic/customizing):

• Auf WebhookEndpoint:
  • allowed_source_ip_range (Text): Zusätzlicher IP-Whitelist-Filter für Hochsicherheitsumgebungen.
  • sla_response_time_seconds (Ganzzahl): Schwellenwert für Alarmierung bei langsamen Schnittstellen.
• Auf WorkflowRun:
  • business_transaction_id (Text): Verknüpfung zur externen Transaktionsnummer (z.B. Stripe-Charge-ID).

3. No-Code Workflow Canvas DAGs

Blueprint A: E-Commerce Webhook zu Auftragsanlage mit Schwellenwert-Gate

• Trigger-Node: Webhook-Eingang shop.order_placed.
• Transform-Node: Mapping auf kanonisches Verkaufsauftragsmodell (CDM_SalesOrder).
• Condition-Node: cdm_order.total_amount > 5000.00 OR cdm_order.is_foreign_country == true.
  • Zweig True (Risiko): Human-in-the-Loop Gate ➔ Benachrichtigung an Vertriebsleiter; erst nach Klick auf Freigeben weiter.
  • Zweig False (Standard): Direkter Durchlauf.
• Action-Node: Rufe cap:sales.sales_order.create auf und setze StockReservation.

Blueprint B: Dead-Letter-Queue Auto-Recovery mit Slack/Teams Alert

• Trigger-Node: Event WORKFLOW_STEP_FAILED.
• Condition-Node: retry_count < 3.
  • Zweig True: Plane Wiederholungsversuch mit exponentiellem Backoff ($2^{\text{retry}} \times 5$ Sekunden).
  • Zweig False: Verschiebe in DeadLetterQueueItem und sende dringenden Notfall-Alert per Webhook an den Admin-Kanal.