Synchronisation du backend Flow et automatisation AWS des workflows
Flow peut fonctionner sans backend dédié, mais Pro est conçu pour fonctionner particulièrement bien avec le WP Suite Flow Backend déployé séparément dans votre propre compte AWS.
Modèle de soumission
Chaque formulaire peut publier directement du navigateur vers une URL de point de terminaison configurée.
Ce point de terminaison peut être :
- votre propre point de terminaison personnalisé,
- un point de terminaison côté WordPress que vous implémentez vous-même,
- le point de terminaison de soumission du backend Flow.
Cela signifie que Flow ne stocke pas intrinsèquement les soumissions dans WordPress.
Lorsqu’un backend Flow est disponible, le même runtime frontend peut passer d’un simple POST navigateur à un chemin de soumission conscient du backend. La décision de capacité repose sur le transport configuré et sur la cible backend résolue.
Synchronisation backend
Lorsque la synchronisation backend est activée, Flow peut synchroniser un formulaire défini dans Gutenberg vers une définition canonique de formulaire backend. Le flux de synchronisation est le suivant :
- modifier un formulaire Flow dans WordPress ;
- enregistrer le formulaire ;
- Flow extrait une structure canonique et calcule un hachage de synchronisation ;
- la définition backend est créée ou mise à jour si nécessaire ;
- WordPress stocke les métadonnées de synchronisation backend telles que l’ID du formulaire backend, le hachage de synchronisation, le statut, les horodatages et la dernière erreur.
Cette définition backend est ce qui permet aux outils d’administration, aux workflows et au traitement des soumissions de fonctionner sur un schéma stable plutôt que sur le contenu brut du post Gutenberg.
Configuration Pro typique
Une configuration de production courante est la suivante :
- déployer le backend Flow sur AWS ;
- enregistrer l’URL de base de l’API publiée dans Gatey comme API distincte ;
- configurer dans Gatey le même mode de protection que celui choisi lors de la publication du backend (
IAMouCOGNITO) ; - sélectionner cette API dans SmartCloud → Flow Settings → API Settings.
Cela donne à Flow un moyen simple et sécurisé d’atteindre le backend pour les soumissions, les modèles, les workflows et les opérations d’administration.
Brouillons, fichiers et charges utiles plus volumineuses
Avec le backend Flow, les formulaires peuvent prendre en charge :
- les flux de sauvegarde et de chargement de brouillon,
- la suppression de brouillon,
- des ID et statuts de soumission émis par le backend,
- des flux d’upload pré-signés pour les charges utiles volumineuses ou les soumissions riches en fichiers.
Modèle d’événements de workflow
Une fois qu’une soumission est acceptée dans le système de workflow backend, les workflows Flow peuvent réagir à des événements de cycle de vie et d’intégration tels que :
submission.createdsubmission.updatedsubmission.action-invokedintegration.webhook.requestedai.agent.completedai.agent.failed
Cela signifie que la synchronisation backend ne concerne pas seulement le stockage de schéma. C’est aussi le pont entre un formulaire rédigé dans Gutenberg et un pipeline d’événements backend.
Relation avec l’ingestion d’e-mails du backend AI Kit
Les workflows du backend Flow peuvent aussi traiter des événements normalisés provenant de chaînes d’ingestion d’e-mails du backend AI Kit. Dans les déploiements actuels, cela peut ressembler à :
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
La valeur partagée ici est le contrat d’événements. Les soumissions du navigateur et les événements d’ingestion d’e-mails peuvent tous deux être normalisés dans le même modèle de workflow, ce qui permet à la même couche de modèles, aux mêmes définitions d’étapes IA et à la même logique de routage de fonctionner sur plusieurs canaux.
