Validation des données dans Dev Studio

Dans App Studio, vous pouvez configurer les conditions de validation qui effectuent une comparaison vrai/faux de la valeur d’un champ par rapport à une valeur constante ou la valeur d’un autre champ. Des scénarios de validation plus complexes peuvent nécessiter des compétences supplémentaires fournies par les règles validate dans Dev Studio.

Considérez les scénarios suivants, chacun nécessitant un comportement que vous ne pouvez configurer que dans Dev Studio :

• Lorsqu’un client canadien envoie son adresse, l’entrée du code postal doit être conforme au format standard des codes postaux canadiens.
• Lorsqu’un investisseur ouvre un compte-titres, il remplit un questionnaire pour déterminer son niveau d’expérience. Seuls les investisseurs les plus expérimentés peuvent ajouter des opérations sur marge à leur compte.
• Lorsqu’une personne souscrit à une complémentaire santé, le demandeur doit télécharger un formulaire de consentement pour permettre la divulgation d’informations médicales à des tiers.

Règles validate

Les règles validate permettent de s’assurer que les données fournies par vos utilisateurs respectent les conditions requises pour l’avancement du dossier. En attribuant des règles de validation aux flow actions, vous pouvez empêcher les utilisateurs de saisir des informations que votre application ne peut pas traiter, et réduire ainsi le nombre d’erreurs de traitement.

Dans Dev Studio, vous pouvez étendre les règles validate créées automatiquement dans App Studio. Vous pouvez également créer de nouvelles règles validate dans la catégorie Process.

Règles edit validate

Les règles edit validate s’appliquent aux propriétés. Il s’agit d’un code Java qui compare la valeur d’une propriété à un modèle défini. Par exemple, une règle edit validate peut vérifier qu’une valeur de propriété se compose de sept chiffres, avec un espace séparant le troisième chiffre du quatrième. En cas de concordance, la valeur saisie est validée. Dans le cas contraire, le système signale une erreur pour la valeur saisie.

Les règles edit validate sont utilisées lors d’une validation côté client, ce qui signifie que les valeurs fournies par l’utilisateur sont immédiatement validées sans faire référence au serveur. La validation intervient dès que les utilisateurs modifient la valeur saisie. Pour appliquer une règle edit validate à une propriété, mentionnez la règle edit validate figurant dans l’onglet Advanced du formulaire de règle de la propriété, dans le champ Use validate.

La logique métier peut dicter que les entrées des utilisateurs respectent certaines normes. Par exemple, pour recueillir les coordonnées d’un utilisateur, une organisation doit s’assurer que les informations sont valides. Avant qu’une application puisse confirmer qu’un code postal, une adresse e-mail ou un numéro de téléphone sont exacts pour un utilisateur, elle doit confirmer que l’entrée de l’utilisateur est conforme à un format précis qui peut varier selon le lieu.

L’exemple suivant explique comment appliquer une règle edit validate à partir d’une règle validate pour s’assurer qu’un utilisateur saisit un code postal conforme au format en vigueur aux États-Unis, qui exige cinq chiffres.

Vérifiez vos connaissances avec l’interaction suivante.

La logique métier (business logic) peut exiger qu’une application valide les données différemment en fonction de certaines conditions, comme la saisie utilisateur, le statut ou la phase (stage) du dossier (case), ou d’une action utilisateur. Cela peut être réalisé à l’aide d’une règle validate.

Prenons un type de dossier (case type) pour l’ouverture d’un nouveau compte-titres. Une société de services financiers peut offrir la possibilité de négocier des titres sur marge en prêtant des fonds au client pour acheter des actions ou d’autres placements autorisés. Ce prêt, connu sous le nom de prêt sur marge, exige que le client conserve un certain taux entre le solde du prêt et la valeur du compte, p. ex 30 %. L’entreprise veut s’assurer que les clients utilisent les marges intelligemment et limitent la nécessité d’un appel de marge, c’est-à-dire une demande de fonds supplémentaires ou la vente automatique d’un placement pour rétablir le taux entre le solde du prêt et la valeur du compte. Les investisseurs ayant une vaste expérience des placements présentent un faible risque en cas d’appel de marge, tandis que les investisseurs ayant une expérience limitée présentent un risque beaucoup plus élevé. De plus, les comptes qui limitent les contributions sur une base annuelle, comme les plans d’épargne retraite, interdisent complètement les opérations sur marge. Pour satisfaire à cette exigence, vous pouvez conditionner la logique de validation au type de compte et au niveau d’expérience.

Pour qualifier la logique de validation, utilisez l’onglet Input de la règle validate pour identifier le type de qualification à appliquer en sélectionnant l’une des options.

• Input property – Qualifier la validation en fonction des données fournies par l’utilisateur. Dans l’exemple du nouveau compte-titres, les champs de niveau d’expérience et de type de compte sont utilisés pour spécifier la logique de validation.
• Proposed work status – Qualifier la validation en fonction du statut que l’application applique au dossier. Par exemple, une demande de carte de crédit est basée en partie sur le credit score du client. Pour le statut Pending-Qualification, le credit score peut descendre jusqu’à 600, tandis que le passage au statut Approved nécessite un credit score minimum de 725.
• Flow action – Qualifier la validation en fonction de l’action effectuée par un utilisateur. Par exemple, un formulaire contenant des informations sur l’employé exige sa date d’entrée en fonction. Si l’utilisateur souhaite exécuter l’intégration d’un nouvel employé, la date d’entrée en fonction doit être dans le futur. Si l’utilisateur souhaite effectuer l’évaluation annuelle d’un employé, la date d’entrée en fonction doit être passée.
• Stages – Qualifier la validation en fonction de la phase actuelle du dossier. Par exemple, pour demander un prêt immobilier ou hypothécaire, le client doit indiquer ses revenus annuels. À la phase Submission, l’application exige que l’utilisateur fournisse des revenus estimés. À la phase Approval, l’estimation doit être remplacée par une valeur concrète confirmée.

L’exemple suivant illustre la validation qualifiée par la saisie. La valeur sélectionnée dans la liste Experience level détermine la condition de validation qui s’applique lorsque vous envoyez le formulaire. Si l’utilisateur sélectionne Experienced ou Professional, les opérations sur marge sont autorisées et la case à cocher permettant d’activer les opérations sur marge n’est pas validée. Si l’utilisateur sélectionne Limited, une erreur s’affichera s’il coche la case d’activation des opérations sur marge.

Au centre de l’image suivante, faites glisser la ligne verticale pour afficher la configuration d’une validation qualifiée par la saisie, et le résultat obtenu.

App Studio prend en charge les comparaisons vrai/faux entre deux valeurs de propriété ou une valeur de propriété et une constante. Dans les dossiers pour lesquels vous ne pouvez pas configurer ce type de comparaison, vous pouvez accéder à une bibliothèque de fonctions de validation sur le formulaire de règle validate dans Dev Studio. Par exemple, vous pouvez utiliser une fonction pour vérifier si une date tombe dans les quatre ou huit dernières semaines, ou pour vérifier si un utilisateur a téléchargé et joint un type spécifique de pièce au dossier. Chaque fonction présente un ensemble personnalisé de champs pour configurer le comportement de validation.

L’exemple suivant explique comment utiliser une fonction pour configurer la validation. La règle validate utilise la fonction A [attachment category] is [attached/not attached] to the current case pour s’assurer que l’utilisateur joint un document qui constitue un justificatif d’identité dans le cadre du processus d’intégration d’un nouvel employé.

Au centre de l’image suivante, faites glisser la ligne verticale pour afficher la configuration de la validation de la pièce jointe, et le résultat obtenu.