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:
- Flow-Formular in WordPress bearbeiten,
- Formular speichern,
- Flow extrahiert eine kanonische Struktur und berechnet einen Synchronisierungshash,
- die Backend-Definition wird bei Bedarf erstellt oder aktualisiert,
- 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:
- Flow-Backend in AWS bereitstellen,
- die veröffentlichte API-Basis-URL in Gatey als separate API registrieren,
- in Gatey denselben Schutzmodus konfigurieren, der bei der Backend-Veröffentlichung gewählt wurde (
IAModerCOGNITO), - 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.createdsubmission.updatedsubmission.action-invokedintegration.webhook.requestedai.agent.completedai.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 workflowWorkMail -> 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.
