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 :

  1. modifier un formulaire Flow dans WordPress ;
  2. enregistrer le formulaire ;
  3. Flow extrait une structure canonique et calcule un hachage de synchronisation ;
  4. la définition backend est créée ou mise à jour si nécessaire ;
  5. 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 :

  1. déployer le backend Flow sur AWS ;
  2. enregistrer l’URL de base de l’API publiée dans Gatey comme API distincte ;
  3. configurer dans Gatey le même mode de protection que celui choisi lors de la publication du backend (IAM ou COGNITO) ;
  4. 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.created
  • submission.updated
  • submission.action-invoked
  • integration.webhook.requested
  • ai.agent.completed
  • ai.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 workflow
  • WorkMail -> 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.