La création de normes ne met en jeu dans les cas nominaux que des
actions de modélisation et de manipulation de l’atelier de
travail sur les normes (OGN).
Il reste nécessaire, dans un
certain nombre de cas de figure, de spécialiser certains aspects du
comportement par défaut du validateur comme par exemple de sérialiser
les bilans de validation sous une forme fixée par le projet client du
validateur. Ces cas de figure sont couverts par l’introduction
de code Java spécifique. Ce code est encadré par une API bien définie
et documentée ici.
La production des bilans de validation est faite au moyen de du schéma présenté dans la figure suivante:
Tous les éléments d’une norme sont décrits dans une instance de INormeDescriptor qui permet de fournir, entre autre éléments, une instance de IReportFactory. Cette instance fournit, entre autre élément, l’instance de IReportSerializer qui doit être utilisée pour produire des bilans de validation au format attendu.
L’interface IReportSerializer fournit deux méthodes :
la seconde est appellée par le validateur pour fournir à l’instance de IReportSerializer les données du bilan à sérializer. La première est également appellée par le validateur pour déclencher la sérialization des bilans de validation. La définition du canal de sortie est laissée à l’appréciation de l’appelant qui fournit une instance de OutputStream. On peut ainsi ne pas faire d’hypothèse sur la cible de la sérialisation.
Le validateur fournit par défaut une implémentation de chacune de ces interfaces qui fournit le service minimum. Pour les remplacer et spécialiser le comportement par défaut, il faut procéder aux étapes de développement suivantes:
Les données collectées pour la production des bilans de validation sont modélisées l’aide d’un méta-modèle Ecore. Ce méta-modèle est présenté figure suivante:
Les bilans sont ainsi fait des éléments suivants:
MessageReport
: le point d’entrée du
modèle. C’est une sous classe de Report
. Nous
avons ainsi les attributs et références suivantes:
anomalies
: la liste des anomalies qui sont
signalées pour le niveau Messagecontext
: la liste des rubriques qui sont dans
le contexte de la rubrique en anomaliereportId
: l’identifiant du bilan (soit
le numéro de déclaration soit l’identifiant utilisé pour la
validation si c’est un MessageReport
valid
: un boolean qui décrit l'état OK/KO du
rapport ou de la déclaration (selon qu’il s’agit
d’un Report
ou d’un MessageReport
)Report
: classe utilisée pour représenter le
résultat de la validation d’une déclarationCategory
: représente une rubrique dans le
message d’origine. On dispose des attributs suivant:
categoryId
: l’identifiant de la
rubrique tel que définit dans le modèle de normecategoryLabel
: le label de la rubrique tel
que définit dans le modèle de normevalue
: la valeur de la rubrique dans le
message.Anomaly
: représente une anomalie dans le bilan
de validation. On dispose des attributs suivants:
code
: le code du message d’erreur (par
exemple, «CST-01», "S20.G00.05.003/CCH-11"message
: le message d’erreur tel que
renseigné dans le modèle de normeblocking
: true
si
l’anomalie est bloquantecategoryId
: l’identifiant de la
rubrique déclenchantecategoryLabel
: le label de la rubrique
déclenchantecategoryValue
: la valeur de la rubrique
déclenchante dans le message validélineNumber
: le numéro de ligne portant la
rubrique dans le message validénumber
: le nombre d’anomalies
constatées mutualisées dans cette anomalie rapportée.Le développeur d’une norme dispose de deux moyens pour spécialiser la production des bilans de validation:
IReportSerializer
(comme nous l’avons évoqué plus haut)
Les extenders peuvent être enregistrés auprès d’une instance de IReportLogger par un appel à la méthode registerExtender()
Les extenders sont des listeners qui sont informés des évènements de lecture du fichier d’entrée. Ainsi, ils peuvent construire des contextes, des représentations alternatives du fichier d’entrée qui seront ensuite utilisées pour produire le bilan de validation.