Validation de type EDI (élément de données)
Le pipeline de réception EDI et le pipeline d'envoi EDI exécutent la validation EDI sur les éléments de données de document informatisé. Cette validation est configurée pour tous les messages en provenance ou à l’adresse d’une partie spécifique, par le biais des propriétés d’accord de cette partie sur la page Validation (sous la section Paramètres de l’ensemble de transactions pour les contrats X12 ou EDIFACT). Si la propriété Edi Type Validation n’est pas sélectionnée dans la page Validation , les validations de données décrites dans cette rubrique ne seront pas effectuées.
La validation de type EDI est activée pour les messages entrants et sortants en sélectionnant la propriété Validation de type EDI dans la page Validation des onglets d’accord bidirectionnel de la boîte de dialogue Propriétés de l’accord . Pour les messages entrants et sortants, cette propriété est sélectionnée par défaut de sorte que la validation EDI soit activée par défaut.
Contrôles de validation
Lorsque le pipeline de réception EDI ou le pipeline d'envoi EDI exécute la validation EDI, il valide les éléments suivants :
Les types de données, comme définis par les propriétés EDI du schéma
Les restrictions de longueur
Les éléments de données vides et les séparateurs de fin
Notes
Cette validation ne vérifie pas les jeux de codes (énumérations), ni les occurrences minimum ou maximum.
Character Sets
Pour effectuer la validation d'éléments de données EDI, les pipelines de réception EDI et d'envoi EDI exigent que le jeu de caractères soit défini comme suit :
Pour EDIFACT, le jeu de caractères est établi dans l’élément de données UNB1 de la page Charset et Séparateurs de l’onglet accord unidirectionnel de la boîte de dialogue Propriétés de l’accord ou de la boîte de dialogue Paramètres de secours EDIFACT (si aucun accord n’a été établi).
Pour KEDIFACT, le caractère est établi dans l’élément de données UNB1 de la page Charset et Séparateurs de l’onglet Accord unidirectionnel de la boîte de dialogue Propriétés de l’accord, comme pour EDIFACT. La valeur de l’élément UNB1.1 doit être définie sur
KECA.Pou X12, le jeu de caractères du message est défini dans les propriétés de pipeline.
Notes
Lorsque le composant d'exécution BizTalk effectue la validation EDI d'un message, il utilise le jeu de caractères X12 sélectionné dans les propriétés de pipeline. Toutefois, la validation des propriétés entrées dans les pages de la boîte de dialogue Propriétés du contrat est effectuée à l’aide du jeu de caractères sélectionné dans la page Charset et Séparateurs de cette boîte de dialogue. Pendant l’exécution, le pipeline ignore la valeur de la page Charset et Séparateurs de la propriété de jeu de caractères X12 de la boîte de dialogue Propriétés du contrat . Si ces deux paramètres ne sont pas les mêmes (c’est-à-dire que la propriété du jeu de caractères X12 de la boîte de dialogue Propriétés du contrat a la valeur Étendue , tandis que la propriété de caractère X12 dans les propriétés du pipeline est définie sur De base), des erreurs de validation de message peuvent se produire.
Validation du type de données
Pour X12, les types de données EDI suivants sont annotés dans le schéma pour validation par les composants Désassembleur/Assembleur des pipelines de réception ou d'envoi : numérique, décimal, identificateur, chaîne, date, heure, binaire et composite.
Pour XEDIFACT, les types de données EDI suivants sont annotés dans le schéma pour validation par les composants Désassembleur/Assembleur des pipelines de réception ou d'envoi : alphabétique, numérique, identificateur, chaîne et composite.
Restrictions de longueur
Pour X12 et EDIFACT, les éléments ou sous-éléments doivent être validés conformément aux exigences de longueur (minimum et maximum). On entend par longueur le nombre de positions de caractère utilisées. Les symboles et les notations décimales ne sont pas pris en compte dans la définition de la longueur.
Notes
Pour les types de données Chaîne X12_AN, les espaces de début sont conservés et les espaces de fin autorisés dans n'importe quel segment pour satisfaire les exigences de longueur minimale.
Pour KECA, la longueur est interprétée comme étant le nombre d'octets. Par exemple, si la longueur est définie sur 3, l'élément ou le sous-élément peut inclure trois caractères d'un octet ou une combinaison d'un caractère de deux octets et d'un caractère d'un octet.
Validation des éléments de données vides et des séparateurs de fin
Pour X12, les éléments de données marqués comme obligatoires ne peuvent pas être vides dans une instance si le segment est présent. Si l'élément de données est de type composite, au moins un élément de données composites doit être évalué.
Pour EDIFACT, les éléments de données (et sous-composants) non évalués et conditionnels peuvent être exclus. Cependant, le séparateur est conservé.
Les séparateurs de fin ne sont pas obligatoires pour X12 ou EDIFACT, mais recommandés.
Lorsque la validation de type EDI est désactivée
Si vous désactivez la validation de type EDI, le pipeline de réception ou d'envoi EDI traite les éléments de données présentant des erreurs vérifiées par la validation de type EDI sans suspendre le message en cours de traitement.
Notes
La validation structurelle EDI est effectuée même si la validation de type EDI est désactivée. Un échange dont les validations structurelles de base échouent est suspendu, même si la validation de type EDI est désactivée.
Voici certaines des erreurs dont le traitement ne suspend pas le message :
Un jeu de transactions inattendu/non défini
Données inattendues/non définies au niveau du segment/de la boucle et de l'élément de données
Caractère facultatif (occurrences minimum et maximum) au niveau du segment/de la boucle et de l'élément de données
Violation des exigences de longueur (min./max.) au niveau de l'élément de données (données dont la longueur dépasse le niveau maximal ou est inférieure au niveau minimal)
Incompatibilité de types de données au niveau de l'élément de données (excepté pour le type de données d'ID qui dispose de son propre contrôle)
Liste d'énumération non valide au niveau de l'élément de données.
Si la validation de type EDI est désactivée côté réception, mais activée côté envoi, le pipeline d'envoi EDI ne peut pas retraiter le XML généré par le pipeline de réception en un fichier EDI valide si le fichier XML contient des erreurs. Le pipeline d'envoi génère donc une erreur.
Si la validation de type EDI est désactivée, le pipeline de réception ou d'envoi EDI gère les erreurs comme suit :
| Données inattendues | Action |
|---|---|
| Document informatisé inattendu/non défini | Le pipeline de réception ou d'envoi EDI accepte un document informatisé même si le schéma correspondant n'a pas été déployé. |
| Segment/enregistrement inattendu | Le pipeline de réception génère une balise avec le préfixe approprié : <UnexpectedSegment_%SegmentID%>. Le pipeline d'envoi utilise le premier des trois caractères du nom de balise XML comme nom de segment. |
| Élément de données simples inattendu | Le pipeline de réception génère une balise XML avec un préfixe, un identificateur de segment et un index représentant la position de l’élément de données dans le segment : <UnexpectedDataElement_%FieldName%. |
| Élément de données composites inattendu | Le pipeline de réception génère des balises XML avec un préfixe, un identificateur de segment et un index représentant la position de l’élément de données dans le segment : <UnexpectedCompositeDataElement_%FieldName%. |
| Données requises manquantes | Le pipeline traite les données comme étant facultatives. |
| Violation de la longueur de l'élément de données | Le pipeline traite la longueur non valide de l'élément de données comme valide (min. = 0 et max. = unbounded). |
| Valeur d'énumération non valide dans l'instance (application au type de données d'ID) | Le pipeline ignore l'erreur et poursuit le traitement. |
| Violation du nombre maximum de répétitions dans l'instance | Le pipeline traite les données répétées comme valides (occurrences min. = 0 et occurrences max. = unbounded). |
Rapport d'erreurs
Lorsque la validation de type EDI est désactivée, BizTalk Server ne signale pas d’erreurs dans le observateur d'événements, mais signale un avertissement. De plus, l'accusé de réception renvoie un message d'acceptation au tiers source, définissant AK501 et AK901 comme « E » dans les accusés de réception X12 997 ou UCI.4, UCM.3 et UCF.4 comme « 7 » dans les accusés de réception EDIFACT CONTRL, supprimant ainsi toute possibilité de rectification dans les futures transmissions. Cependant, les récepteurs du message ont la possibilité de récupérer manuellement le document, évitant ainsi au message d'être rejeté ou suspendu. En outre, la Edi.ErrorsInTransactionSet propriété de contexte est promue si l’une de ces erreurs est rencontrée par le pipeline de réception EDI. Cette propriété est promue comme « True » si des erreurs de validation EDI ou étendue sont détectées. En l'absence d'erreurs, cette propriété est promue comme « False ».
Si le pipeline de réception ou d'envoi rencontre des données inattendues, il signale l'erreur au niveau parent et ignore les erreurs au niveau enfant, comme indiqué ci-dessous :
| Données inattendues | Action |
|---|---|
| Document informatisé inattendu | L'accusé de réception signale cette erreur et ignore les erreurs suivantes au niveau du segment/de la boucle et de l'élément de données. |
| Segment/boucle inattendu(e) | L'accusé de réception signale cette erreur et ignore les erreurs au niveau de l'élément de données. |
| Élément de données inattendu | L'accusé de réception signale cette erreur et ignore les erreurs composites relatives aux propriétés telles que l'ID, la longueur et les occurrences et celles inhérentes aux champs d'élément de données composites (le cas échéant). |