Architektur · Formulare, Prüfung und Workflow-Laufzeit
Ereignisgesteuertes Formular- und Workflow-Backend für WordPress auf AWS
Formulare werden weiterhin in WordPress erstellt und platziert. Dauerhafte Entwürfe, Einreichungen, Diskussionen, Prüfstatus, Benachrichtigungen und nachgelagerte Aktionen laufen hinter einer klar definierten API- und Ereignisgrenze.
WordPress / statisches Frontend
↓
Flow-Laufzeit
Frontend-API
↓
Einreichungs- und Entwurfsstatus
├→ Uploads
├→ Diskussion / Prüfstatus
└→ Workflow-Ereignisse
↓
E-Mail / Webhooks / Aktionen
Ausführungsgrenze
Ein Formular wird zum Workflow, wenn sein Status die Seitenanfrage überdauern muss
Lange Formulare, Freigaben und Prüfprozesse benötigen einen dauerhaften Status. Flow trennt die Browser-Erfahrung von Backend-Persistenz und nachgelagerter Ausführung. So kann die öffentliche Seite statisch bleiben, während der Prozess unabhängig weiterläuft.
Formular- / Prüfoberfläche in WordPress
↓ Browser
/frontend/* API
├→ Entwurf speichern / laden / abschließen
├→ Datensatz einreichen
├→ Upload-Vertrag
└→ Diskussions- / Bewertungseingaben
↓
dauerhafter Status + Ereignisse
/admin/* → geschützte Verwaltung
↓
Workflow-Dispatch → E-Mail / Webhook / Prozessaktion
Sicherheitsgrenze Öffentliche Formularrouten und privilegierte Admin-Routen haben unterschiedliche Risikoprofile. Kontrollen für anonyme Einreichungen, authentifizierter Prüfzugriff und administrative Konfiguration dürfen keine gemeinsame, weit gefasste Autorisierungsfläche verwenden.
Was der Flow-Stack erstellt
Das Flow-Backend trennt API, Rechenleistung, Status, Nutzdaten, Ereignisse, Sicherheit und Betrieb. Diese Übersicht zeigt, welche AWS-Ressourcen die einzelnen Architekturaufgaben erfüllen.
| Ebene | AWS-Ressourcen | Architekturaufgabe |
|---|---|---|
| API-Ebene | Regionale API Gateway REST API, optionale benutzerdefinierte Domain, optionale Route53-Einträge | Getrennte Frontend- und Admin-Routen bereitstellen, ohne die Formularausführung an das WordPress-Hosting zu binden. |
| Compute-Ebene | Forms API Lambda, Workflow Dispatcher Lambda, Email Sender Lambda, Webhook Dispatcher Lambda, Custom Resource Lambda zur Bereitstellung | Synchrone Formularverarbeitung, asynchrone Workflows, E-Mail-Versand und ausgehende Webhooks als getrennte Betriebseinheiten halten. |
| Status-Ebene | DynamoDB-Tabellen für Einreichungen, Einreichungsereignisse, Vorlagen, Workflow-Definitionen, Formulardefinitionen, Webhook-Endpunkte und Prozesszuordnungen | Formulardefinitionen, Datensätze und Workflow-Status in zweckgebundenen Tabellen mit TTL/Aufbewahrung speichern, statt die WordPress-Datenbank als Integrationsprotokoll zu verwenden. |
| Nutzdaten-Ebene | S3-Bucket für Nutzdaten und Vorlagen, optional vorhandene Buckets | Große Dateiübertragungen und wiederverwendbare E-Mail- oder Vorlagenressourcen in Objektspeicher verlagern. |
| Ereignis-Ebene | EventBridge-Regeln und Ereignisse wie Einreichung erstellt/aktualisiert, Status/Aktion sowie AI-Agent abgeschlossen/fehlgeschlagen | Formulararbeit in beobachtbare Ereignisse umwandeln, die Workflows auslösen können, ohne den Besucher zu blockieren. |
| Sicherheits-Ebene | Cognito-Autorisierer für Admin-Routen, optionale IAM/NONE-Modi, WAF, reCAPTCHA, IP-Zulassungs-/Sperrlisten, SSM/KMS für Geheimnisse | Öffentliche Formulareinreichungen und privilegierte Verwaltungs-APIs unterschiedlich schützen. |
| Betriebs-Ebene | CloudWatch-Loggruppen, SQS-Warteschlange für unzustellbare Nachrichten, konfigurierbare Protokollaufbewahrung, optionaler GuardDuty-Malware-Schutz | Der Laufzeit eigene Protokolle, eine Wiederholungs-/Fehlerfläche und optionale Prüfung von Nutzdaten geben. |
Frontend-API gegenüber Admin-API
Die beiden Routenfamilien bedienen unterschiedliche Aufrufer und dürfen nicht dieselben Vertrauensannahmen übernehmen. Die Tabelle macht die Laufzeittrennung sichtbar, bevor Formularverhalten oder Berechtigungen konfiguriert werden.
| Routenfamilie | Beispiele | Typischer Aufrufer | Sicherheitsprofil |
|---|---|---|---|
| Frontend-Einreichung | /frontend/forms/{formId}/submit | Gerendertes Flow-Formular auf einer öffentlichen oder geschützten Seite | Kann ohne Benutzerauthentifizierung laufen, sollte bei anonymem Verkehr jedoch reCAPTCHA, WAF und Ratenbegrenzung verwenden. |
| Frontend-Entwürfe | /frontend/forms/{formId}/drafts, /drafts/load, /drafts/delete, /drafts/{submissionId}/submit | Besucher speichert, setzt fort oder schließt ein langes Formular ab | Entwurfszugangsdaten und endgültige Validierung sind getrennt, damit das Speichern eines Entwurfs keine finalen Workflows auslöst. |
| Frontend-Upload-Vorbereitung | /frontend/forms/{formId}/upload-url | Formularkomponente bereitet einen großen Anhang vor | Liefert einen vorsignierten S3-Upload-Vertrag; die Nutzdaten müssen WordPress nicht durchlaufen. |
| Admin-Formulare/-Einreichungen | /admin/forms, /admin/forms/{formId}/submissions | WP Admin oder Verwaltungsoberfläche | Sollte mit Cognito/IAM und optionaler IP-Zulassungsliste geschützt sein. |
| Admin-Vorlagen/-Workflows/-Webhooks | /admin/templates, /admin/workflows, /admin/webhook-endpoints | Administratoren konfigurieren Geschäftsverhalten | Diese Routen ändern das Laufzeitverhalten und dürfen nie wie öffentliche Frontend-Endpunkte behandelt werden. |
Datenmodell: Warum mehrere Tabellen sinnvoll sind
Das Backend trennt Definitionen, aktuelle Datensätze, Ereignisverlauf und Integrationskonfiguration, weil sie unterschiedliche Lebenszyklen haben. Eine einzelne generische Formularzeile reicht für dauerhafte Workflows nicht aus.
| Tabellenfamilie | Bedeutung | Grund für die Trennung |
|---|---|---|
| Formulardefinitionen | Struktur und Versionierung der im Frontend verwendeten Formulare | Ein Formular kann sich ändern, während alte Einreichungen weiterhin verständlich bleiben müssen. |
| Einreichungen | Aktueller Einreichungsstatus, Entwurfs-/Endstatus und zentrale Felddaten | Dies ist der operative Datensatz, den Admin-Ansichten und Workflow-Schritte abfragen. |
| Einreichungsereignisse | Append-orientierter Verlauf: erstellt, aktualisiert, Status geändert, Aktion aufgerufen | Audit- und Wiederholungsverhalten dürfen den aktuellen Einreichungsdatensatz nicht überschreiben. |
| Vorlagen | Wiederverwendbare E-Mail-/Vorlagenmetadaten | E-Mail-Inhalte müssen unabhängig von Einreichungsdatensätzen verwaltet werden. |
| Workflow-Definitionen | Regeln, Aktionen und Routingverhalten | Workflow-Logik hat einen eigenen Lebenszyklus und muss explizit versioniert und verwaltet werden. |
| Webhook-Endpunkte | Ausgehende Integrationsziele und Signiereinstellungen | Externe Systeme sind betriebliche Abhängigkeiten und nicht nur Formularfelder. |
| Prozesszuordnungen | Laufzeitzuordnung zwischen Prozessen, Einreichungen und Aktionen | Komplexe Workflows benötigen Korrelationsstatus über einen einzelnen Formulardatensatz hinaus. |
Sicherheits- und Missbrauchskontrollen
Öffentliche Formularrouten und privilegierte Verwaltungsrouten dürfen kein gemeinsames Schutzmodell verwenden. Diese Tabelle zeigt, wo Bot-Schutz, WAF, Identität und Geheimnisspeicherung in die Flow-Laufzeit gehören.
| Kontrolle | Einsatzort | Entwurfsgrund |
|---|---|---|
| reCAPTCHA | Öffentliche Frontend-Formularendpunkte | Bot-Einreichungen reduzieren, bevor daraus gespeicherte Datensätze, E-Mails, Webhooks oder Modell-/Workflow-Kosten entstehen. |
| WAF-Ratenbegrenzung | Frontend- und Admin-Pfadpräfixe | Missbrauch für besucher- und adminseitige Routen unterschiedlich drosseln. |
| Admin-Cognito-Autorisierer | /admin/*-Routen | Formulardefinitionen, Einreichungen, Vorlagen, Workflows und Webhook-Konfiguration hinter einer echten Identitätsgrenze halten. |
| SSM/KMS-Geheimnisse | reCAPTCHA-Geheimnisse und Webhook-Signiergeheimnisse | Gemeinsame Geheimnisse aus WordPress-Einstellungen und Vorlagenquellen fernhalten. |
| GuardDuty-Malware-Schutz | Nutzdaten-Bucket, wenn aktiviert | Optional hochgeladene Nutzdaten prüfen, bevor die nachgelagerte Verarbeitung darauf vertraut. |
Bereitstellungsparameter, die die Architektur verändern
Diese Parameter sind keine kosmetischen Formulareinstellungen. Sie verändern Authentifizierung, Missbrauchsschutz, Speichereigentum, Geheimnisse, Domains und Betrieb und müssen als Architekturentscheidungen geprüft werden.
| Parameterbereich | Beispiele | Architekturwirkung |
|---|---|---|
| Authentifizierungsmodi | FrontendApiAuthMode, AdminApiAuthMode, AdminCognitoUserPoolId, Scopes | Steuert, ob Frontend- und Admin-Flächen öffentlich, IAM- oder Cognito-geschützt sind. |
| Missbrauchsschutz | EnableRecaptcha, reCAPTCHA-Modus/Site-Key/Schwellenwert, EnableWAF, erlaubte/gesperrte IP-Listen | Bestimmt, wie viel anonymer Verkehr das Backend erreicht und welche Pfade begrenzt oder zugelassen werden. |
| Speichereigentum | TemplatesBucketName, PayloadBucketName, Präfixe | Ermöglicht die Verwendung neu erstellter Buckets oder vorhandener Speicherkonventionen. |
| Geheimnisse | EnableKmsForSecrets, Webhook-Signiergeheimnis, reCAPTCHA-Geheimnis | Steuert, ob Geheimnisse mit einem dedizierten KMS-Schlüssel und SSM-Parametern gespeichert werden. |
| Domain/DNS | ApiCustomDomainName, Zertifikat-ARN, Route53-Einstellungen | Verschiebt die API von einer execute-api-URL zu einer eigenen Domain, wenn DNS und Zertifikat bereit sind. |
| Betrieb | Daten- und Protokollaufbewahrung, Lambda-Speicher/Timeout/Protokollstufe | Steuert Kosten, Beobachtbarkeit und Laufzeitreserven, ohne WordPress-Seiten zu ändern. |
Implementierungspfad
Modellieren Sie den Prozess, bevor Sie die Aktionen verbinden
Dasselbe Backend kann einfache Formulare und stärker strukturierte Prozesse unterstützen, wenn Entwurfs-, Einreichungs-, Prüf- und Aktionsstatus eindeutig bleiben.
- Definieren Sie den Datensatz und seinen Lebenszyklus — Legen Sie fest, was ein Entwurf ist, was zu einem eingereichten Datensatz wird, welche Prüfstatus existieren und welche Felder oder Anhänge sitzungsübergreifend erhalten bleiben müssen.
- Trennen Sie Besucher- und Prüferoperationen — Halten Sie öffentliche oder authentifizierte Frontend-Aktionen auf einer schmalen Laufzeitfläche und schützen Sie die administrative Verwaltung von Formularen, Einreichungen und Workflows separat.
- Erzeugen Sie Ereignisse nach dauerhaften Statusänderungen — Lösen Sie E-Mails, Webhooks oder andere Prozessaktionen erst aus, nachdem die relevante Datensatz- oder Statusänderung akzeptiert wurde, damit nachgelagerte Fehler die ursprüngliche Einreichung nicht löschen.
- Testen Sie Wiederholungen und Übergaben — Prüfen Sie das Fortsetzen von Entwürfen, die endgültige Einreichung, Prüfentscheidungen, Diskussions- oder Bewertungsänderungen, fehlgeschlagene Benachrichtigungen und externe Webhook-Fehler als getrennte Fehlerpfade.
Wann sich die Trennung durch ein ereignisgesteuertes Flow-Backend lohnt
Gute Eignung
Formulare, die tatsächlich Geschäftsprozesse sind
- Benutzer müssen ein langes Formular sitzungsübergreifend speichern und fortsetzen können.
- Einreichungen durchlaufen nach dem ersten Formularschritt Prüf-, Freigabe-, Diskussions-, Bewertungs- oder Statusworkflows.
- Das öffentliche Frontend kann statisch sein, während Status und nachgelagerte Aktionen aktiv und unabhängig betreibbar bleiben müssen.
Einfacher halten
Ein konventioneller Formularweg kann ausreichen, wenn
- das Formular kurz ist und der Prozess mit einer Einreichung und einer einfachen Benachrichtigung endet.
- die Website vollständig dynamisch ist und ein vorhandenes Formular-Plugin den Workflow bereits ohne operative Reibung abdeckt.
- keine dauerhaften Entwürfe, kein Backend-Prüfstatus, kein Ereignisverlauf und keine externen Workflow-Aktionen erforderlich sind.
Problemleitfäden
Käuferprobleme, die diese Architektur unterstützt
Wie ersetze ich Freigaben per E-Mail und Tabellenkalkulation durch einen WordPress-Workflow?
Beginnen Sie mit E-Mail- und Tabellenfreigaben durch einen WordPress-Workflow ersetzen. Dort steht das operative Problem im Mittelpunkt; diese Architektur zeigt, wo Datensätze, Prüfstatus und Workflow-Aktionen ausgeführt werden.
Wie können Benutzer ein langes WordPress-Formular speichern und später fortsetzen?
Siehe Benutzer ein langes WordPress-Formular speichern und später fortsetzen lassen. Dauerhafter Entwurfsstatus gehört hinter die Browser-Laufzeit und nicht in eine einzelne PHP-Seitenanfrage.
Wie kombiniere ich Formulare, Diskussionen und Bewertungen in einem Prüfworkflow?
Siehe WordPress-Prüfworkflow mit Formularen, Diskussionen und Bewertungen erstellen für den Prüfanwendungsfall und Diskussionen, Antworten und Bewertungen zu einem statischen WordPress-Frontend hinzufügen, wenn die Zusammenarbeit nach der statischen Veröffentlichung aktiv bleiben muss.
Funktioniert dies auch mit statisch veröffentlichtem WordPress?
Ja. Die Seite kann aus statischem Hosting bereitgestellt werden, während Flow das konfigurierte Backend aus dem Browser aufruft. WordPress statisch machen, ohne dynamische Funktionen zu verlieren erläutert das umfassendere Modell aus statischer Bereitstellung und Laufzeit.
Beginnen Sie mit dem Workflow-Problem
Verlagern Sie den Prozess aus Posteingängen, bevor Sie weitere Automatisierung hinzufügen
Wählen Sie zuerst das Käuferproblem – Freigabe, Speichern und Fortsetzen oder strukturierte Prüfung – und definieren Sie mit dieser Architektur anschließend Persistenz-, Autorisierungs- und Ereignisgrenzen.