Action Envoyer pour formulaire adaptatif

Une action d’envoi est déclenchée lorsqu’un utilisateur clique sur le bouton Envoyer d’un formulaire adaptatif. Le formulaire adaptatif fournit certaines actions Envoyer prêtes à l’emploi. Les actions d’envoi disponibles sont les suivantes :

Vous pouvez également étendre les actions d’envoi par défaut pour créer votre propre action d’envoi.

Vous pouvez configurer une action d’envoi dans la section Envoi des propriétés du conteneur de formulaire adaptatif, dans la barre latérale.

Configuration de l’action d’envoi

Envoyer vers le point d’entrée REST

Utilisez l’action Envoyer vers le point d’entrée REST pour transmettre les données envoyées à l’URL REST. L’URL peut être celle d’un serveur interne (le serveur sur lequel le formulaire est rendu) ou externe.

Pour transmettre des données à un serveur interne, indiquez le chemin de la ressource. Les données sont transmises selon le chemin de la ressource. Par exemple : /content/restEndPoint. Pour de telles requêtes de transmission, les informations d’authentification de la requête d’envoi sont utilisées.

Pour transmettre des données à un serveur externe, indiquez une URL. Le format d’URL est le suivant : https://host:port/path_to_rest_end_point. Assurez-vous de configurer le chemin pour que la requête POST soit traitée anonymement.

Mappage pour la transmission des valeurs de champs sous forme de paramètres de page de remerciement

Dans l’exemple ci-dessus, les informations saisies par l’utilisateur dans textbox sont capturées au moyen du paramètre param1. La syntaxe permettant de publier les données capturées au moyen de param1 est :

String data=request.getParameter("param1");

De même, les paramètres que vous utilisez pour publier des données XML et des pièces jointes sont dataXml et attachments.

Par exemple, vous utilisez ces deux paramètres dans votre script pour analyser les données à un point d’entrée REST. Utilisez la syntaxe suivante pour stocker et analyser les données :

String data=request.getParameter("dataXml");
String att=request.getParameter("attachments");

Dans cet exemple, data contient les données XML et att les données des pièces jointes.

L’option d’envoi Envoyer vers le point d’entrée REST transmet les données renseignées dans le formulaire à une page de confirmation configurée dans le cadre de la requête HTTP GET. Vous pouvez ajouter le nom des champs à la requête. Le format de la requête est le suivant :

{fieldName}={request parameter name}

Comme illustré ci-dessous, param1 et param2 sont transmis en tant que paramètres avec des valeurs copiées à partir des champs textbox et numericbox pour la prochaine action.

Configuration de l’action Envoyer vers le point d’entrée REST

Vous pouvez également Activer la requête POST et fournir une URL pour la publication de la requête. Pour envoyer des données au serveur AEM qui héberge le formulaire, utilisez un chemin d’accès relatif correspondant au chemin racine du serveur AEM. Par exemple, /content/forms/af/SampleForm.html. Pour envoyer des données vers un autre serveur, utilisez un chemin d’accès absolu.

REMARQUE

Pour transmettre les champs en tant que paramètres dans une URL REST, tous les champs doivent avoir des noms d’éléments différents, même s’ils sont placés sur différents panneaux.

Envoyer un e-mail

Vous pouvez utiliser l’action d’envoi Envoyer un e-mail pour envoyer un e-mail à un ou à plusieurs destinataires lors de l’envoi réussi du formulaire. Le message généré peut contenir des données de formulaire dans un format prédéfini. Par exemple, dans le modèle suivant, le nom du client, l’adresse d’expédition, le nom de l’État et le code postal sont récupérés à partir des données de formulaire envoyées.

"

Hi ${customer_Name},

Les paramètres suivants sont définis comme votre adresse de livraison par défaut :
${customer_Name},
${customer_Shipping_Address},
${customer_State},
${customer_ZIPCode}

Regards,
WKND

"
REMARQUE
  • Tous les champs de formulaire doivent avoir des noms d’élément différents, même si les champs sont placés sur différents panneaux d’un formulaire adaptatif.
  • AEM as a Cloud Service exige que le e-mails sortants soient chiffrés. Par défaut, les e-mails sortants sont désactivés. Pour les désactiver, envoyez un ticket d’assistance à Demande d’accès.

Vous pouvez également inclure des pièces jointes et un document d’enregistrement (DE) à l’e-mail. Pour activer l’option Joindre le document d’enregistrement, configurez le formulaire adaptatif pour générer un document d’enregistrement (DE). Vous pouvez activer cette option pour générer un document d’enregistrement à partir des propriétés de formulaire adaptatif.

Envoyer à l’aide du modèle de données de formulaire

L’action d’envoi Envoyer à l’aide du modèle de données de formulaire écrit les données de formulaire adaptatif envoyés pour l’objet de modèle de données spécifié dans un modèle de données de formulaire dans sa source de données. Lors de la configuration de l’action d’envoi, vous pouvez sélectionner un objet de modèle de données dont vous souhaitez écrire les données envoyées dans sa source de données.

En outre, vous pouvez envoyer une pièce jointe de formulaire à l’aide d’un modèle de données de formulaire et d’un document d’enregistrement vers la source de données. Pour plus d’informations sur le modèle de données de formulaire, voir AEM Forms Intégration de données.

Appeler un processus AEM

L’action d’envoi Appeler un processus AEM associe un formulaire adaptatif à un processus AEM. Lorsqu’un formulaire est envoyé, le processus associé commence automatiquement sur l’instance de création. L’action Envoyer place les éléments suivants à l’emplacement de charge utile du flux de travail :

  • Fichier de données : Il contient les données envoyées au formulaire adaptatif. Vous pouvez utiliser l’option Chemin d’accès au fichier de données pour spécifier le nom du fichier et le chemin d’accès du fichier par rapport à la charge utile. Par exemple, le chemin d’accès /addresschange/data.xml crée un dossier nommé addresschange et le place par rapport à la charge utile. Vous pouvez également spécifier uniquement data.xml pour envoyer uniquement les données envoyées sans créer de hiérarchie de dossiers.

  • Pièces jointes : vous pouvez utiliser l’option Chemin d’accès aux pièces jointes pour spécifier le nom de dossier dans lequel stocker les pièces jointes téléchargées dans le formulaire adaptatif. Le dossier est toujours relatif à la charge.

  • Document d’enregistrement : il contient le document d’enregistrement généré pour le formulaire adaptatif. Vous pouvez utiliser l’option Chemin du document d’enregistrement pour spécifier le nom du fichier de document d’enregistrement et le chemin d’accès du fichier par rapport à la charge utile. Par exemple, le chemin d’accès /addresschange/DoR.pdf crée un dossier nommé addresschange relatif à la charge utile et place DoR.pdf relatif à la charge utile. Vous pouvez également spécifier uniquement DoR.pdf pour n’enregistrer que le document d’enregistrement sans créer de hiérarchie de dossiers.

Avant d’utiliser l’action Envoyer Appeler un processus AEM, configurez les éléments suivants pour la configuration du service de paramètres AEM DS :

  • URL du serveur de traitement : le serveur de traitement est le serveur sur lequel le processus Forms ou AEM est déclenché. Il peut s’agir de l’URL de l’instance de création AEM ou d’un autre serveur.

  • Nom d’utilisateur du serveur de traitement : nom d’utilisateur de l’utilisateur du processus

  • Mot de passe du serveur de traitement : mot de passe de l’utilisateur du processus

Pour définir les valeurs d’une configuration, générez des configurations OSGi à l’aide du SDK AEM et déployez la configuration sur votre instance de Cloud Service.

Utilisation de l’envoi synchrone ou asynchrone

Une action d’envoi peut utiliser un envoi synchrone ou asynchrone.

Envoi synchrone : traditionnellement, les formulaires web sont configurés à des fins d’envoi synchrone. Dans un envoi synchrone, lorsque les utilisateurs envoient un formulaire, ils sont redirigés vers une page d’accusé de réception, une page de remerciement ou, en cas d’échec de l’envoi, une page d’erreur. Vous pouvez sélectionner l’option Utiliser l’envoi asynchrone pour rediriger les utilisateurs vers une page web ou afficher un message lors de l’envoi.

Configuration de l’action d’envoi

Envoi asynchrone: les expériences web modernes telles que les application d’une seule page gagnent en popularité. Dans une application de ce type, la page web reste statique tandis que l’interaction entre le client et le serveur se déroule en arrière-plan. Vous pouvez désormais fournir cette expérience avec des formulaires adaptatifs en configurant l’envoi asynchrone.

Revalidation côté serveur dans un formulaire adaptatif

En règle générale, dans n’importe quel système de capture de données en ligne, les développeurs placent des validations JavaScript côté client pour appliquer des règles métier. Mais dans les navigateurs modernes, les utilisateurs finaux peuvent contourner ces validations et effectuer les envois manuellement à l’aide de différentes méthodes, comme la console Web Browser DevTools. Ces méthodes sont également valables pour les formulaires adaptatifs. Un développeur de formulaires peut créer différentes logiques de validation, mais techniquement, les utilisateurs finaux peuvent ignorer ces logiques de validation et envoyer des données incorrectes au serveur. Les données incorrectes violeraient les règles de fonctionnement mises en place par un auteur de formulaires.

La fonction de revalidation côté serveur permet également d’exécuter les validations fournies par un auteur de formulaires adaptatifs lors de la conception d’un formulaire adaptatif sur le serveur. Elle empêche toute erreur lors des envois de données et toute violation des règles de fonctionnement représentées en termes de validations de formulaire.

Quels éléments valider sur le serveur ?

Les champs de validation en standard d’un formulaire adaptatif réexécutés sur le serveur sont les suivants :

  • Requis
  • Clause de validation d’image
  • Expression de validation

Activation de la validation côté serveur

Utilisez Revalider sur le serveur sous le conteneur de formulaires adaptatifs dans la zone latérale pour activer ou désactiver la validation côté serveur pour le formulaire actif.

Activation de la validation côté serveur

Activation de la validation côté serveur

Si l’utilisateur final contourne ces validations et envoie les formulaires, le serveur effectue de nouveau la validation. Si la validation échoue du côté du serveur, la transaction d’envoi est alors désactivée. L’utilisateur final voit de nouveau s’afficher le formulaire d’origine. Pour l’utilisateur, les données capturées et les données envoyées s’affichent en tant qu’erreurs.

REMARQUE

La validation côté serveur permet de valider le modèle de formulaire. Il est recommandé de créer une bibliothèque client séparée pour les validations et de ne pas la mélanger à d’autres éléments. Par exemple, ne placez pas le style HTML et la manipulation DOM HTML dans la même bibliothèque client.

Prise en charge des fonctions personnalisées dans les expressions de validation

Parfois, en cas de règles de validation complexes, le script de validation exact réside dans des fonctions personnalisées que l’auteur doit appeler à partir de l’expression du champ de validation. Pour rendre cette bibliothèque de fonctions personnalisées visible et disponible lors des validations côté serveur, l’auteur de formulaires peut configurer le nom de la bibliothèque cliente AEM sous l’onglet Réglages de base des propriétés de conteneur de formulaires adaptatifs comme illustré ci-dessous.

Prise en charge des fonctions personnalisées dans les expressions de validation

Prise en charge des fonctions personnalisées dans les expressions de validation

L’auteur peut configurer la bibliothèque personnalisée JavaScript pour chaque formulaire adaptatif. Dans la bibliothèque, conservez uniquement les fonctions réutilisables ayant une dépendance sur les bibliothèques tierces jquery et underscore.js.

Gestion d’erreurs sur l’action d’envoi

Dans le cadre de la sécurité AEM et des conseils de renforcement, configurez les pages d’erreur personnalisées telles que 400.jsp, 404.jsp et 500.jsp. Ces gestionnaires sont appelés lorsque les erreurs 400, 404 ou 500 s’affichent au moment d’envoyer un formulaire. Les gestionnaires sont également appelés lorsque ces codes d’erreur sont déclenchés sur le nœud de publication. Vous pouvez également créer des pages JSP pour d’autres codes d’erreur HTTP.

Lorsque vous préremplissez un modèle de données de formulaire ou un formulaire adaptatif basé sur un schéma avec des données XML ou JSON conformes à un schéma, ce qui signifie que les données ne contiennent pas de balises <afData>, <afBoundData> et </afUnboundData>, les données des champs non liés du formulaire adaptatif sont perdues. Le schéma peut être un schéma XML, un schéma JSON ou un modèle de données de formulaire. Les champs non liés sont des champs de formulaire adaptatif sans la propriété bindref.

Sur cette page