Flow-Backend-Synchronisierung und AWS-Workflow-Automatisierung

Flow kann ohne eigenes Backend arbeiten. Pro ist jedoch besonders auf das separat in Ihrem AWS-Konto bereitgestellte WP Suite Flow Backend abgestimmt.

Übermittlungsmodell

Jedes Formular kann Daten direkt aus dem Browser an eine konfigurierte Endpunkt-URL senden.

Dieser Endpunkt kann sein:

  • ein eigener benutzerdefinierter Endpunkt,
  • ein selbst implementierter WordPress-Endpunkt,
  • der Übermittlungsendpunkt des Flow-Backends.

Flow speichert Übermittlungen daher nicht automatisch in WordPress.

Wenn ein Flow-Backend verfügbar ist, kann dieselbe Frontend-Laufzeit von einem einfachen Browser-POST auf einen backendgestützten Übermittlungspfad wechseln. Die Funktionsentscheidung richtet sich nach dem konfigurierten Transport und dem aufgelösten Backend-Ziel.

Backend-Synchronisierung

Bei aktivierter Backend-Synchronisierung kann Flow ein in Gutenberg definiertes Formular in eine kanonische Backend-Formulardefinition überführen. Der Ablauf lautet:

  1. Flow-Formular in WordPress bearbeiten,
  2. Formular speichern,
  3. Flow extrahiert eine kanonische Struktur und berechnet einen Synchronisierungshash,
  4. die Backend-Definition wird bei Bedarf erstellt oder aktualisiert,
  5. WordPress speichert Metadaten zur Backend-Synchronisierung, etwa Backend-Formular-ID, Synchronisierungshash, Status, Zeitstempel und letzten Fehler.

Mit dieser Backend-Definition können Admin-Werkzeuge, Workflows und die Verarbeitung von Übermittlungen gegen ein stabiles Schema statt gegen den rohen Gutenberg-Beitragsinhalt arbeiten.

Typische Pro-Einrichtung

Eine übliche Produktionseinrichtung sieht so aus:

  1. Flow-Backend in AWS bereitstellen,
  2. die veröffentlichte API-Basis-URL in Gatey als separate API registrieren,
  3. in Gatey denselben Schutzmodus konfigurieren, der bei der Backend-Veröffentlichung gewählt wurde (IAM oder COGNITO),
  4. diese API unter SmartCloud → Flow Settings → API Settings auswählen.

Damit erreicht Flow das Backend für Übermittlungen, Vorlagen, Workflows und Admin-Vorgänge auf einfache und sichere Weise.

Entwürfe, Dateien und größere Nutzlasten

Mit dem Flow-Backend können Formulare Folgendes unterstützen:

  • Abläufe zum Speichern und Laden von Entwürfen,
  • das Löschen von Entwürfen,
  • vom Backend vergebene Übermittlungs-IDs und Statuswerte,
  • vorsignierte Upload-Abläufe für große Nutzlasten oder dateireiche Übermittlungen.

Workflow-Ereignismodell

Sobald eine Übermittlung in das Backend-Workflow-System aufgenommen wurde, können Flow-Workflows auf Lebenszyklus- und Integrationsereignisse reagieren, zum Beispiel:

  • submission.created
  • submission.updated
  • submission.action-invoked
  • integration.webhook.requested
  • ai.agent.completed
  • ai.agent.failed

Die Backend-Synchronisierung dient damit nicht nur der Schemaspeicherung. Sie bildet die Brücke zwischen einem in Gutenberg erstellten Formular und einer Backend-Ereignispipeline.

Beziehung zum E-Mail-Eingang des AI-Kit-Backends

Flow-Backend-Workflows können außerdem normalisierte Ereignisse aus E-Mail-Eingangsketten des AI-Kit-Backends verarbeiten. In aktuellen Bereitstellungen kann das so aussehen:

  • WorkMail -> ai-email-intake-proxy -> ai-email-intake-dispatcher -> Flow workflow
  • WorkMail -> ai-email-intake-proxy -> ai-email-intake-dispatcher -> Flow workflow -> ai.agent -> downstream Flow workflow

Die gemeinsame Grundlage ist der Ereignisvertrag. Browserübermittlungen und E-Mail-Eingangsereignisse lassen sich in dasselbe Workflow-Modell normalisieren. Dadurch können dieselbe Vorlagenebene, dieselben KI-Schrittdefinitionen und dieselbe Routinglogik kanalübergreifend arbeiten.