Architektúra · Űrlapok, ellenőrzés és munkafolyamat-futtatás
Eseményvezérelt űrlap- és munkafolyamat-backend WordPresshez AWS-en
Az űrlapok létrehozása és elhelyezése maradjon WordPressben, míg a tartós vázlatok, beküldések, megbeszélések, ellenőrzési állapotok, értesítések és további műveletek egy egyértelmű API- és eseményhatár mögött futnak.
WordPress / statikus frontend
↓
Flow-futtatókörnyezet
frontend API
↓
Beküldési és vázlatállapot
├→ feltöltések
├→ megbeszélés / ellenőrzési állapot
└→ munkafolyamat-események
↓
e-mail / webhookok / műveletek
Végrehajtási határ
Az űrlap akkor válik munkafolyamattá, amikor az állapotának túl kell élnie az oldalkérést
A hosszú űrlapoknak, jóváhagyásoknak és ellenőrzési folyamatoknak tartós állapotra van szükségük. A Flow különválasztja a böngészőbeli élményt a backendbeli állapotmegőrzéstől és a további végrehajtástól, így a nyilvános oldal statikus maradhat, miközben a folyamat önállóan folytatódik.
Űrlap- / ellenőrzési felület WordPressben
↓ böngésző
/frontend/* API
├→ vázlat mentése / betöltése / véglegesítése
├→ rekord beküldése
├→ feltöltési szerződés
└→ megbeszélési / értékelési adatok
↓
tartós állapot + események
/admin/* → védett kezelés
↓
munkafolyamat-indítás → e-mail / webhook / folyamatművelet
Biztonsági határ A nyilvános űrlapútvonalak és a privilegizált adminisztrációs útvonalak kockázati profilja eltérő. Az anonim beküldések kontrolljai, a hitelesített ellenőri hozzáférés és az adminisztratív konfiguráció nem használhat közös, széles jogosultsági felületet.
A Flow stack által létrehozott erőforrások
A Flow backend különválasztja az API-, számítási, állapot-, adat-, esemény-, biztonsági és üzemeltetési feladatokat. Ez az áttekintés megmutatja az egyes architekturális szerepeket ellátó AWS-erőforrásokat.
| Réteg | AWS-erőforrások | Architekturális feladat |
|---|---|---|
| API-réteg | Regionális API Gateway REST API, opcionális egyedi domain és opcionális Route53-rekordok | Külön frontend- és adminútvonalakat biztosít anélkül, hogy az űrlapok futtatását a WordPress-tárhelyhez kötné. |
| Számítási réteg | Forms API Lambda, Workflow Dispatcher Lambda, Email Sender Lambda, Webhook Dispatcher Lambda és telepítési Custom Resource Lambda | Külön működési egységben tartja a szinkron űrlapkezelést, az aszinkron munkafolyamatokat, az e-mail-küldést és a kimenő webhookokat. |
| Állapotréteg | DynamoDB-táblák a beküldésekhez, eseményekhez, sablonokhoz, munkafolyamat- és űrlapdefiníciókhoz, webhook-végpontokhoz és folyamattérképekhez | Célhoz kötött, TTL-lel és megőrzéssel kezelt táblákban tárolja a definíciókat, rekordokat és állapotot, nem a WordPress-adatbázist használja integrációs naplóként. |
| Adatréteg | S3-adatbucket és sablonbucket, opcionálisan meglévő bucketek | A nagy fájlátvitelt és az újrafelhasználható e-mail- vagy sablonerőforrásokat objektumtárba helyezi. |
| Eseményréteg | EventBridge-szabályok és események: beküldés létrehozva/frissítve, állapot/művelet, AI-agent befejeződött/meghiúsult | Az űrlapműveleteket megfigyelhető eseményekké alakítja, amelyek a látogató blokkolása nélkül indíthatnak munkafolyamatokat. |
| Biztonsági réteg | Cognito authorizer az adminútvonalakhoz, opcionális IAM/NONE módok, WAF, reCAPTCHA, IP-engedélyezési/-tiltási listák, SSM/KMS a titkokhoz | Eltérő védelmet alkalmaz a nyilvános beküldésekre és a privilegizált kezelési API-kra. |
| Üzemeltetési réteg | CloudWatch-naplócsoportok, SQS dead-letter queue, konfigurálható naplómegőrzés és opcionális GuardDuty kártevővédelem | Saját naplókat, újrapróbálkozási/hibafelületet és opcionális adatellenőrzést ad a futtatókörnyezethez. |
Frontend API és admin API
A két útvonalcsalád eltérő hívókat szolgál ki, ezért nem örökölhetik ugyanazokat a bizalmi feltételezéseket. A táblázat az űrlapműködés és jogosultságok beállítása előtt láthatóvá teszi a futtatási határt.
| Útvonalcsalád | Példák | Jellemző hívó | Biztonsági megközelítés |
|---|---|---|---|
| Frontendbeküldés | /frontend/forms/{formId}/submit | Nyilvános vagy védett oldalon megjelenített Flow-űrlap | Felhasználói hitelesítés nélkül is futhat, de anonim forgalomnál reCAPTCHA-, WAF- és sebességkorlátozás szükséges. |
| Frontendvázlatok | /frontend/forms/{formId}/drafts, /drafts/load, /drafts/delete, /drafts/{submissionId}/submit | Hosszú űrlapot mentő, folytató vagy véglegesítő látogató | A vázlathoz tartozó hitelesítő adatok és a végleges validáció különválik, így a vázlatmentés nem indítja el a végleges munkafolyamatot. |
| Frontend-feltöltés előkészítése | /frontend/forms/{formId}/upload-url | Nagy melléklet feltöltését előkészítő űrlapkomponens | Előre aláírt S3-feltöltési szerződést ad vissza; az adatnak nem kell áthaladnia a WordPressen. |
| Adminűrlapok és -beküldések | /admin/forms, /admin/forms/{formId}/submissions | WP Admin vagy kezelőfelület | Cognito/IAM és opcionális IP-engedélyezési lista védje. |
| Adminsablonok, -munkafolyamatok és -webhookok | /admin/templates, /admin/workflows, /admin/webhook-endpoints | Az üzleti működést konfiguráló adminisztrátor | Ezek az útvonalak megváltoztatják a futtatási viselkedést, ezért soha nem kezelhetők nyilvános frontend-végpontként. |
Adatmodell: miért hasznos több tábla
A backend külön kezeli a definíciókat, az aktuális rekordokat, az eseménytörténetet és az integrációs konfigurációt, mert életciklusuk eltér. Egyetlen általános űrlapsor nem elegendő a tartós munkafolyamatokhoz.
| Táblacsalád | Mit képvisel | Miért különálló |
|---|---|---|
| Űrlapdefiníciók | A frontenden használt űrlapok szerkezete és verziói | Az űrlap módosulhat, miközben a régi beküldéseknek továbbra is értelmezhetőnek kell maradniuk. |
| Beküldések | Aktuális beküldési állapot, vázlat/végleges állapot és alapvető mezőadatok | Ez az a működési rekord, amelyet az adminnézetek és munkafolyamatlépések lekérdeznek. |
| Beküldési események | Bővülő előzmény: létrehozás, frissítés, állapotváltozás, művelethívás | Az audit- és újrapróbálkozási működés nem írhatja felül az aktuális beküldési rekordot. |
| Sablonok | Újrafelhasználható e-mail- és sablonmetaadatok | Az e-mail-tartalomnak a beküldési rekordoktól függetlenül kezelhetőnek kell lennie. |
| Munkafolyamat-definíciók | Szabályok, műveletek és útválasztási működés | A munkafolyamat-logikának saját életciklusa van, ezért explicit verziózás és kezelés szükséges. |
| Webhook-végpontok | Kimenő integrációs célok és aláírási beállítások | A külső rendszerek működési függőségek, nem egyszerű űrlapmezők. |
| Folyamattérképek | Futásidejű kapcsolat a folyamatok, beküldések és műveletek között | Az összetett munkafolyamatokhoz egyetlen űrlaprekordon túlmutató korrelációs állapot szükséges. |
Biztonsági és visszaélés elleni kontrollok
A nyilvános űrlapútvonalak és a privilegizált kezelési útvonalak nem használhatnak azonos védelmi modellt. A táblázat elhelyezi a botvédelmet, a WAF-ot, az identitást és a titkok tárolását a Flow futtatókörnyezetében.
| Kontroll | Alkalmazási terület | Tervezési indok |
|---|---|---|
| reCAPTCHA | Nyilvános frontend-űrlapvégpontok | Csökkenti a botbeküldéseket, mielőtt azok tárolt rekordot, e-mailt, webhookot vagy modell-/munkafolyamat-költséget eredményeznének. |
| WAF-sebességkorlátozás | Frontend- és adminútvonal-előtagok | Eltérően korlátozza a látogatói és adminisztrációs útvonalakkal való visszaélést. |
| Admin Cognito authorizer | /admin/* útvonalak | Valódi identitási határ mögött tartja az űrlapdefiníciókat, beküldéseket, sablonokat, munkafolyamatokat és webhook-konfigurációt. |
| SSM/KMS-titkok | reCAPTCHA-titkok és webhook-aláírási titkok | A megosztott titkokat távol tartja a WordPress-beállításoktól és a sablonforrásoktól. |
| GuardDuty kártevővédelem | Adatbucket, ha engedélyezett | Opcionális ellenőrzést ad a feltöltött adatokhoz, mielőtt a további feldolgozás megbízik bennük. |
Az architektúrát megváltoztató telepítési paraméterek
Ezek nem pusztán megjelenési beállítások. Megváltoztatják a hitelesítést, a visszaélés elleni védelmet, a tárhely tulajdonlását, a titkokat, a domaineket és az üzemeltetést, ezért architekturális döntésként kell őket felülvizsgálni.
| Paraméterterület | Példák | Architekturális hatás |
|---|---|---|
| Hitelesítési módok | FrontendApiAuthMode, AdminApiAuthMode, AdminCognitoUserPoolId, scope-ok | Meghatározza, hogy a frontend- és adminfelületek nyilvánosak, IAM- vagy Cognito-védettek. |
| Visszaélés elleni védelem | EnableRecaptcha, reCAPTCHA-mód/webhelykulcs/küszöb, EnableWAF, engedélyezett/tiltott IP-listák | Meghatározza, mennyi anonim forgalom érheti el a backendet, és mely útvonalak sebességkorlátozottak vagy engedélyezettek. |
| Tárhely tulajdonlása | TemplatesBucketName, PayloadBucketName, előtagok | Lehetővé teszi újonnan létrehozott bucketek vagy meglévő tárolási konvenciók használatát. |
| Titkok | EnableKmsForSecrets, webhook-aláírási titok, reCAPTCHA-titok | Meghatározza, hogy a titkok dedikált KMS-kulccsal és SSM-paraméterekkel legyenek-e tárolva. |
| Domain/DNS | ApiCustomDomainName, tanúsítvány ARN, Route53-beállítások | Az API-t execute-api URL-ről saját domainre helyezi, amikor a DNS- és tanúsítványútvonal elkészült. |
| Üzemeltetés | Adat- és naplómegőrzés, Lambda-memória/időtúllépés/naplózási szint | A WordPress-oldalak módosítása nélkül szabályozza a költséget, megfigyelhetőséget és futtatási tartalékot. |
Megvalósítási út
A műveletek összekötése előtt modellezze a folyamatot
Ugyanaz a backend egyszerű űrlapokat és összetettebb folyamatokat is támogathat, ha a vázlat, a beküldés, az ellenőrzés és a művelet állapota egyértelmű marad.
- Határozza meg a rekordot és annak életciklusát — Döntse el, mi számít vázlatnak, mi válik beküldött rekorddá, milyen ellenőrzési állapotok léteznek, és mely mezőknek vagy mellékleteknek kell megmaradniuk a munkamenetek között.
- Válassza külön a látogatói és ellenőri műveleteket — A nyilvános vagy hitelesített frontendműveleteket tartsa szűk futtatási felületen, az űrlapok, beküldések és munkafolyamatok adminisztratív kezelését pedig külön védje.
- A tartós állapotváltozás után bocsásson ki eseményt — E-mailt, webhookot vagy más folyamatműveletet csak a megfelelő rekord- vagy állapotváltozás elfogadása után indítson, hogy a további feldolgozás hibája ne törölje az eredeti beküldést.
- Tesztelje az újrapróbálkozásokat és átadásokat — Külön hibafolyamatként ellenőrizze a vázlat folytatását, a végleges beküldést, az ellenőrzési döntéseket, a megbeszélési vagy értékelési módosításokat, a sikertelen értesítéseket és a külső webhookhibákat.
Mikor indokolt az eseményvezérelt Flow-backend különválasztása
Jó választás
Űrlapok, amelyek valójában üzleti folyamatok
- A felhasználóknak munkamenetek között is el kell tudniuk menteni és folytatni egy hosszú űrlapot.
- A beküldések az első űrlaplépés után ellenőrzési, jóváhagyási, megbeszélési, értékelési vagy állapotkezelési munkafolyamatba kerülnek.
- A nyilvános frontend lehet statikus, miközben az állapotnak és a további műveleteknek aktívnak és önállóan üzemeltethetőnek kell maradniuk.
Maradjon egyszerűbb
Hagyományos űrlapmegoldás is elegendő lehet, ha
- az űrlap rövid, és a folyamat egyetlen beküldéssel és egyszerű értesítéssel véget ér.
- a webhely teljesen dinamikus, és egy meglévő űrlapbővítmény már működési nehézség nélkül lefedi a munkafolyamatot.
- nincs szükség tartós vázlatokra, backendbeli ellenőrzési állapotra, eseményelőzményekre vagy külső munkafolyamat-műveletekre.
Problémaútmutatók
Az architektúra által támogatott vásárlói problémák
Hogyan válthatók fel az e-mailes és táblázatos jóváhagyások WordPress-munkafolyamattal?
Kezdje az E-mailes és táblázatos jóváhagyások felváltása WordPress-munkafolyamattal útmutatóval. Ez az üzemeltetési problémát mutatja be; az architektúra azt magyarázza el, hol élnek a rekordok, az ellenőrzési állapot és a munkafolyamat-műveletek.
Hogyan menthetnek el a felhasználók egy hosszú WordPress-űrlapot későbbi folytatáshoz?
Tekintse meg a Hosszú WordPress-űrlap mentése és későbbi folytatása útmutatót. A tartós vázlatállapot helye a böngészős futtatókörnyezet mögött van, nem egyetlen PHP-oldalkérésben.
Hogyan egyesíthetők az űrlapok, megbeszélések és értékelések egy ellenőrzési munkafolyamatban?
Az ellenőrzési esetre tekintse meg a WordPress-ellenőrzési munkafolyamat űrlapokkal, megbeszéléssel és értékelésekkel útmutatót, statikus közzététel után is aktív együttműködéshez pedig a Beszélgetések, válaszok és értékelések statikus WordPress-felületen oldalt.
Működik ez statikusan közzétett WordPress esetén is?
Igen. Az oldal statikus tárhelyről szolgálható ki, miközben a Flow a böngészőből hívja a konfigurált backendet. A WordPress statikussá tétele dinamikus funkciók elvesztése nélkül bemutatja a tágabb statikus oldal és dinamikus futtatókörnyezet modellt.
Induljon ki a munkafolyamat problémájából
A további automatizálás előtt vigye ki a folyamatot a beérkező levelek közül
Először válassza ki a vásárlói problémát – jóváhagyás, mentés és folytatás vagy strukturált ellenőrzés –, majd ezzel az architektúrával határozza meg az állapotmegőrzési, jogosultsági és eseményhatárokat.