Partager via

Conservation d'un échange EDI reçu traité par lot

  • Article

Notes

Toutes les options d’interface utilisateur mentionnées dans cette rubrique sont disponibles dans la page Paramètres de l’hôte local (section Paramètres du récepteur ) des onglets contrat bidirectionnel de la boîte de dialogue Propriétés de l’accord .

Lorsque le pipeline de réception EDI conserve un échange EDI entrant par lot, l'analyse normale de chaque document informatisé/message en fichiers XML intermédiaires distincts n'a pas lieu. Le pipeline de réception EDI traite l'échange comme un document unique sans fractionner les documents informatisés/messages. Cela se produit lorsque la propriété d’option de traitement par lots entrant est définie sur Conserver l’échange - suspendre l’échange en cas d’erreur ou Conserver l’échange - suspendre les jeux de transactions en cas d’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 lot, 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é réception

Le Désassembleur EDI traite les lots conservés comme suit :

  • Lorsque le Désassembleur EDI traite un lot pour le conserver, il convertit le format de fichier plat en format XML et ajoute X12InterchangeXML ou EdifactInterchangeXML comme nœud racine XML. Cette opération indique au pipeline d'envoi que l'échange par lot doit être conservé et que le schéma Edifact_BatchSchema ou X12_BatchSchema doit servir à valider le nœud racine.

  • Le Désassembleur ajoute l'attribut DelimiterSetSerializedData au nœud racine d'un message XML par lot afin d'indiquer les séparateurs que le pipeline d'envoi devra utiliser pour générer un échange EDI par lot à partir du message XML. Lorsque le message XML est un lot conservé, l'attribut est défini par le pipeline de réception à partir des séparateurs utilisés dans le message entrant. Lorsque le message XML par lot est produit par l'orchestration du traitement par lot, l'attribut est défini d'après la valeur spécifiée dans les propriétés de l'accord.

  • Le désassembleur utilise l’un des espaces de noms suivants lorsqu’il crée un échange préservé encodé en XML : http://schemas.microsoft.com/BizTalk/EDI/EDIFACT/2006/InterchangeXML ou http://schemas.microsoft.com/BizTalk/EDI/X12/2006/InterchangeXML.

  • Le désassembleur promeut la propriété EDI.ReuseEnvelope == True de contexte pour identifier l’échange comme conservé. Ceci vous permet de créer un port d'envoi qui s'abonne à tous les échanges par lot conservés.

    Notes

    Un document HIPAA ne sera pas fractionné en sous-documents si l’option traitement par lots entrant est définie sur Conserver l’échange. Ce sera le cas même si l'annotation subdocument creation break a la valeur « Oui » dans le schéma HIPAA.

    Erreur lors du traitement

    Si vous avez sélectionné l’option Conserver l’échange - suspendre l’échange en cas d’erreur pour l’option Traitement par lots entrant, l’intégralité de l’échange est suspendue en raison d’une erreur. Si BizTalk Server suspend l’intégralité de l’échange conservé, la structure de l’échange et l’ordre des jeux de transactions au sein de l’échange sont conservés. En cas d’erreur, BizTalk Server publierez une entrée d’erreur consolidée dans le journal des événements. Cette entrée inclut toutes les erreurs au niveau de l'échange, du groupe fonctionnel et des documents informatisés.

    Si vous avez sélectionné l’option Conserver l’échange - suspendre les ensembles de transactions en cas d’erreur pour le traitement par lots entrants, le pipeline de réception EDI supprime tout jeu de transactions non valide de l’échange et procède à la création du code XML de l’échange. Le fichier XML d'échange ainsi produit est nécessaire pour réutiliser les enveloppes des segments de contrôle (ISA, GS, GE et IEA pour les échanges X12 ou UNA, UNB, UNG, UNE et UNZ pour les échanges EDIFACT). L’échange sera considéré comme un document traité avec succès ; Toutefois, l’erreur est signalée dans l’observateur d’événements et si un accusé de réception fonctionnel est généré, il signale l’erreur. BizTalk Server créez une entrée distincte dans le journal des événements pour chaque jeu de transactions qui est en erreur. Si BizTalk Server supprime un jeu de transactions erroné de l’échange, la structure et l’ordre de l’échange peuvent ne pas être conservés. BizTalk Server met à jour le nombre de jeux de transactions dans l’échange.

    Voici les cas particuliers de suspension des documents informatisés en cas d'erreur :

  • Si tous les documents informatisés d'un groupe sont non valides, chaque document informatisé est suspendu individuellement mais les segments de contrôle du groupe (sans les documents informatisés puisqu'ils ont été abandonnés) sont inclus dans le fichier XML d'échange généré.

  • Si tous les documents informatisés d'un échange sont non valides, chaque document informatisé est suspendu individuellement mais les segments de contrôle de l'échange (sans les documents informatisés puisqu'ils ont été abandonnés) sont inclus dans le fichier XML d'échange généré.

  • Si les segments de contrôle du groupe sont non valides, tous les documents informatisés du groupe sont suspendus individuellement.

  • Si les segments de contrôle de l'échange sont non valides, tous les documents informatisés de l'échange sont suspendus individuellement et le fichier XML de l'échange n'est pas généré. Une entrée est créée dans l'observateur d'événements pour l'échange rejeté.