La création d'un jeu de règles de validation nécessite d'effectuer les étapes suivantes :
Si le jeu de règles spécifié dans la section "Validations supplémentaires" n'existe pas, l'infrastructure d'informations collectées dynamiques génère un jeu de règles "starter". Le jeu de règles starter généré possède une classe nommée "ValidationResult" avec la classe de règles de base et un attribut "evidence" mentionné dans la section Contrat des jeux de règles de validation. Il est associé à la catégorie Informations collectées dynamiques de validation.
Parfois, un jeu de règles existant est spécifié en tant que jeu de règles à utiliser pour validation. Généralement, cela se produit lorsqu'une nouvelle version de type d'informations collectées dynamiques précédente possède déjà un jeu de règles pour validation. Si un jeu de règles existant est utilisé, il doit se conformer au contrat des jeux de règles de validation. Si un jeu de règles de validation existant est modifié, les modifications sont visibles pour toutes les versions de type d'informations collectées dynamiques qui ont utilisé ce jeu de règles.
Comme décrit dans la section sur la classe de règles DefaultEvidenceValidationResult, cette classe de règles possède des attributs correspondant à différents jeux de validations. Tous ces attributs ont une valeur null. Aucune validation n'est donc définie dans les jeux validations. Pour un type d'informations collectées dynamiques particulier, tout ou partie des jeux de validations peut être requis. Par exemple, une version de type d'informations collectées dynamiques peut nécessiter uniquement "detailsValidations" et "standardValidations". Les attributs correspondant aux jeux de validations doivent être définis. Généralement, une liste CER fixe est utilisée pour construire la liste des validations dans un jeu.
En général, une validation fait référence aux données de l'enregistrement d'informations collectées du dossier ou des enregistrements d'informations collectées associées. Voilà pourquoi le contrat des jeux de règles de validation doit posséder un attribut nommé "evidence". Cet attribut contient les données de l'instance d'informations collectées de dossier correspondante lorsque le jeu de règles est appelé.
Une validation peut être définie à l'aide de l'expression CER create. Lorsqu'elle est appelée pour la classe de règles Validation, l'expression create nécessite de spécifier une dérivation pour les attributs isFailure et failureMessage.
La dérivation de l'attribut isFailure doit générer une valeur booléenne. Par exemple, prenons deux attributs "startDate" et "endDate" présents dans un type d'informations collectées dynamiques. La validation nécessite que l'attribut "startDate" soit différent de l'attribut "endDate". La dérivation de l'attribut isFailure de cette validation peut utiliser une expression CER compare qui compare les attributs "startDate" et "endDate". L'expression compare obtient la valeur de ces deux attributs à l'aide d'une expression de référence sur l'attribut "evidence" de la classe de règles de validation.
La dérivation de l'attribut failureMessage doit générer une valeur de type curam.creole.value.Message . Pour ce faire, la dérivation peut utiliser un message XML ou une expression Resource Message. Encore une fois, si le message doit être paramétré avec les données de l'enregistrement Informations collectées de dossier, l'attribue requis est accessible via l'attribut "evidence" de la classe de règles de validation à l'aide de l'expression reference.
Si vous le souhaitez, une valeur peut être spécifiée pour l'élément "informationalType" de la validation. Si aucune valeur n'est spécifiée, le type d'information sera considéré comme une erreur. Toutefois, les opérations statiques ( error() , warning() et fatalError() ) dans curam.dynamicevidence.validation.impl.InformationalType peuvent être utilisés pour indiquer un type d'informations différent.
Généralement, le type d'information dépend du mode Validation. Le mode Validation d'une session Validation particulière est accessible via l'attribut "validationMode" de la classe de règles Résultat de validation. Le mode Validation peut ensuite être comparé avec un ou plusieurs modes de validation à l'aide des opérations statiques ( applyChanges() , approve() , insert() , modify() , validateChanges() ) définies dans curam.dynamicevidence.validation.impl.ValidationMode pour détermine le type d'information à utiliser. Par exemple, le mode Validation d'une session Validation peut être comparé aux éléments "Appliquer les modifications" et "Valider les modifications" et le type d'information peut être spécifié comme erreur pour le premier et comme avertissement pour le second.