Envoi d'un échange de lot préservé
Quand le pipeline d'envoi EDI traite un échange de lot préservé sortant, il traite l'échange traité par lot comme un tout. Il réutilise normalement les segments (de contrôle) existants de l'enveloppe pour créer l'échange EDI, plutôt que d'appliquer une enveloppe basée sur l'accord. Cela se produit lorsque la propriété d’option Traitement par lots entrant est définie sur Préserver l’échange - suspendre l’échange en cas d’erreur ou Conserver l’échange - suspendre les jeux de transactions sur erreur.
Validation de schéma
BizTalk Server valide l’enveloppe d’un lot conservé à l’aide des schémas de lot et des schémas de service. Le schéma de lot est utilisé pour valider le nœud racine du message préservé : les schémas de service sont utilisés pour valider les en-tête et les codes de fin d'échange, de groupe, et de document informatisé. Pour plus d’informations sur les schémas de traitement par lots, consultez Schémas de lot EDI. Pour plus d’informations sur les schémas de service, consultez Schémas de service et de contrôle EDI.
BizTalk Server valide les documents dans un échange par lots à l’aide des schémas de document de votre projet.
Traitement côté envoi
Lorsque l'assembleur EDI traite un échange préservé, il utilise normalement les mêmes en-têtes d'échange, de groupe, et de document informatisé qui existaient dans l'échange traité par lot lorsque celui-ci a été reçu.
Pour les échanges X12, les paramètres de propriété des différentes pages de l’onglet Accord unidirectionnel de la boîte de dialogue Propriétés de l’accord (qui déterminent comment BizTalk Server créera les en-têtes ISA, GS et ST d’un échange sortant) ne s’appliquent normalement pas.
Pour des échanges EDIFACT, les paramètres UNA des propriétés de l'accord sont normalement utilisés. Le segment UNA est facultatif dans un message encodé en EDIFACT, mais il est nécessaire pour sérialiser un échange de lot préservé. S'il n'y a pas de valeur pour le segment UNA dans l'instance XML, les valeurs des propriétés par défaut pour le composant de pipeline d'envoi sont utilisées. Si les propriétés du composant de pipeline d'envoi ne sont pas évaluées, alors le message XML intermédiaire de lot préservé est interrompu.
Si vous promouvez la
EDI.PopulateInterchangeValuespropriété de contexte sur « True » sur l’échange en cours de conservation (dans un composant personnalisé), ediAssembler dans le port d’envoi remplit tous les en-têtes d’échange, de groupe et de jeu de transactions aux valeurs définies dans les propriétés de l’accord.Si vous faites passer la
EDIOverride.OverrideEdiHeaderpropriété de contexte à « True » sur l’échange avant son traitement par le pipeline d’envoi, vous pouvez remplacer les valeurs d’enveloppe du document sortant en définissant les valeurs de propriété de contexte appropriéesEDIOverride. Pour plus d’informations, consultez Substitution d’en-têtes EDI.Pour qu'un échange préservé ne présente pas d'erreurs, l'assembleur préserve la séquence des documents informatisés dans un groupe de l'échange et la séquence des groupes dans l'échange.
Notes
Vous pouvez envoyez un lot préservé avec un pipeline d'envoi XML. Cette manière de faire nécessite cependant que vous changiez l'espace de noms pour le schéma de lot. Pour plus d’informations, consultez Envoi d’un lot conservé avec un pipeline d’envoi XML.
Erreur lors du traitement
Grâce à une balise réservée dans le XML, le pipeline d'envoi EDI identifie un échange EDI en tant que lot préservé. Cette balise, <X12InterchangeXml> ou <EdifactInterchangeXml>, est appliquée au code XML par le pipeline de réception EDI.
Voici les cas particuliers de suspension des documents informatisés en cas d'erreur :
Si tous les documents informatisés d'un groupe ne sont pas valides, alors le pipeline d'envoi EDI inclut des segments de contrôle de groupe dans l'EDI généré, mais le groupe ne contient aucun document informatisé (car ils ont été supprimés). Les totaux de pied de page de groupe sont remis à zéro. Les segments de contrôle d'échange demeurent inchangés.
Si tous les documents informatisés d'un échange ne sont pas valides, alors les segments de contrôle d'échange sont toujours inclus dans l'échange EDI généré, mais l'échange ne contient aucun document informatisé (car ils ont été supprimés). Cela constitue un échange vide.
Si les segments de contrôle de groupe ou les segments de contrôle d'échange ne sont pas valides, un échange encodé en EDI n'est pas généré. Un journal est créé dans l'observateur d'événements, et indique si l'échange a été rejeté.