Partager via

Résolution de l'accord, détection du schéma et autorisation des messages EDI reçus

  • Article

Lorsque BizTalk Server reçoit un message EDI, le pipeline de réception EDI effectue des processus de recherche d’accord de partenaire commercial, de découverte de schéma et d’autorisation pour déterminer comment traiter le message.

Résolution d’accord

Le pipeline de réception EDI effectue une résolution d'accord de partenariat commercial par le biais d'une série d'étapes pour déterminer s'il existe une correspondance entre les champs d'en-tête dans le message et les propriétés dans la définition de l'accord. Une fois que BizTalk Server a déterminé l’accord, il détermine le schéma de document qui s’applique à l’échange (voir ci-dessous). Il utilise les propriétés associées à l'accord correspondant et le schéma pertinent pour valider et traiter le message reçu.

Pour résoudre le contrat, BizTalk Server procédez comme suit :

  1. Résoudre l'accord en mettant en correspondance les qualificateurs et identificateurs du récepteur et de l'expéditeur présents dans l'en-tête de l'échange avec ceux présents dans les propriétés d'un accord.

  2. Si l'étape 1 échoue, résoudre l'accord en mettant en correspondance uniquement les qualificateur et identificateur de l'expéditeur présents dans l'en-tête de l'échange avec ceux présents dans les propriétés d'un accord. En outre, comme la première étape n’a pas réussi, il est prudent de supposer que BizTalk Server recevra le message. Par conséquent, BizTalk Server tente de faire correspondre le qualificateur et l’identificateur du récepteur avec les éléments suivants :

    • les valeurs « BT » et « HostX12Recvr » (pour les messages X12) et

    • les valeurs « BT » et « HostEdifactRecvr » (pour les messages EDIFACT)

    Important

    • BizTalk Server 2013 R2, 2013 et 2010 : Les champs ISA5, ISA6, ISA7, ISA8, UNB2.1, UNB2.2, UNB3.1 et UNB3.2 sont obligatoires dans les paramètres du contrat.
      • BizTalk Server 2009 et 2006 R2 : les champs ISA7, ISA8, UNB3.1 et UNB3.2 ne sont pas obligatoires dans les paramètres de partie. Si les champs sont vides, le moteur EDI fournit une résolution basée sur les valeurs de ISA5, ISA6, UNB2.1 et UNB2.2.
      • Pour prendre en charge les résolutions allant de BizTalk Server 2009 et BizTalk Server 2006 R2 aux versions les plus récentes de BizTalk Server, des ID (HostX12Recvr et HostEdifactRecvr) et qualificateurs (BT) codés en dur sont introduits.
      • Vos messages EDIFACT doivent suivre les instructions de la syntaxe et des règles de message de LA CEE .

  3. Si l'étape 2 échoue, utiliser les propriétés de l'accord de secours.

    Dans la première étape, pour X12, BizTalk Server utilisez les valeurs suivantes pour faire la correspondance :

  • ISA05 (qualificateur de l'expéditeur)

  • ISA06 (identificateur de l'expéditeur)

  • ISA07 (qualificateur du récepteur)

  • ISA08 (identificateur du récepteur)

    Pour EDIFACT, BizTalk Server utiliserez les valeurs suivantes pour faire la correspondance :

  • UNB2.1 (identificateur de l'expéditeur)

  • UNB2.2 (qualificateur de l'expéditeur)

  • UNB3.1 (identificateur du récepteur)

  • UNB3.2 (qualificateur du récepteur)

    Les propriétés d’accord utilisées pour la correspondance sont définies dans la page Identificateurs des onglets d’accord spécifiques à la direction de la boîte de dialogue Propriétés de l’accord .

    Ces quatre propriétés côté envoi et côté réception identifient de manière unique l'accord de partenariat commercial. L'utilisation des quatre propriétés vous offre plus de souplesse dans le traitement côté réception. Par exemple, cette méthode de résolution d'accord peut vous permettre d'envoyer des accusés de réception à plusieurs tiers sans créer plusieurs ports d'envoi.

    Si BizTalk Server ne parviens pas à résoudre le contrat à l’aide des quatre qualificateurs et identificateurs de l’expéditeur et du destinataire, il tente de résoudre le contrat en utilisant uniquement le qualificateur et l’identificateur de l’expéditeur. Pour X12, ces champs sont ISA05 et ISA06 ; pour EDIFACT, il s'agit de UNB2.1 et UNB2.2. Comme pour une correspondance des propriétés de l’expéditeur et du destinataire, BizTalk Server fait correspondre les valeurs de l’en-tête d’échange aux propriétés d’accord définies dans la page Identificateurs des onglets d’accord spécifiques à la direction de la boîte de dialogue Propriétés de l’accord. Si seuls le qualificateur et l’identificateur de l’expéditeur sont utilisés pour résoudre l’accord, le qualificateur et l’identificateur du destinataire doivent être non définis dans l’onglet Accord bidirectionnel de la boîte de dialogue Propriétés de l’accord .

    Si aucun accord n’est trouvé, BizTalk Server utilise le contrat de partenaire commercial de secours, sauf si le paramètre de port nécessite une authentification. Si le paramètre de port nécessite une authentification (si l’option Supprimer les messages en cas d’échec de l’authentification ou Conserver les messages en cas d’échec de l’authentification est sélectionnée dans la page Général des propriétés du port de réception), un accord est requis pour tout échange reçu par le port de réception. Alors, si l'accord n'est pas résolu par la mise en correspondance de l'en-tête de l'échange avec les propriétés de l'accord, l'utilisation des propriétés de l'accord de secours pour déterminer l'accord n'est pas autorisée. L'échange est traité comme si l'authentification avait échoué si aucun accord n'est trouvé, et est interrompu.

Notes

Un message du pipeline EDI est transmis à l'étape réussie de la résolution d'accord jusqu'à ce qu'il soit résolu et que l'accord soit activé dans l'étape. Par exemple, si le message est résolu dans la première étape de la résolution d'accord mais que l'accord est désactivé, le message est transmis à l'étape réussie à des fins de résolution.

Détection de schéma

Une fois que BizTalk Server a déterminé l’accord qui est résolu en message, il doit déterminer le schéma qu’il doit utiliser pour valider et traiter le message. Pour ce faire, il utilise les propriétés identifiées dans la page Paramètres de l’hôte local de l’onglet accord unidirectionnel (côté envoi) de la boîte de dialogue Propriétés de l’accord.

Pour déterminer le schéma, BizTalk Server devez d’abord déterminer l’espace de noms de schéma. Le désassembleur EDI utilise soit un espace de noms par défaut pour les schémas standard fournis avec BizTalk Server, soit il détermine l’espace de noms à utiliser pour un schéma personnalisé.

La page Paramètres de l’hôte local de l’onglet Accord unidirectionnel de la boîte de dialogue Propriétés de l’accord vous permet de configurer une grille de valeurs pour déterminer un espace de noms personnalisé. Si aucune correspondance n’est trouvée dans cette grille, le désassembleur EDI utilise l’espace de noms par défaut dans le champ Espace de noms cible marqué pour la ligne par défaut.

Détection de schéma X12

Pour les messages encodés en X12, BizTalk Server détermine un espace de noms personnalisé à l’aide de l’identificateur d’expéditeur de l’application (GS02) et de l’ID du jeu de transactions (ST01) à partir de l’en-tête de l’échange entrant. Il tente de trouver une correspondance entre ces valeurs et les valeurs des propriétés GS02 et ST01 dans la grille Personnaliser l’espace de noms cible de la page Paramètres de l’hôte local (sous Paramètres de l’ensemble de transactions) de l’onglet Contrat bidirectionnel de la boîte de dialogue Propriétés du contrat . S’il trouve une correspondance, il utilise l’espace de noms cible identifié dans la même ligne de la grille pour déterminer le schéma à valider et traiter le message. Si l'espace de noms cible n'est pas déterminé, l'espace de noms cible par défaut est utilisé. Si aucun espace de noms n’est identifié dans le champ Espace de noms Cible marqué pour la ligne par défaut, BizTalk Server utilisera l’espace de noms cible identifié dans les propriétés du contrat de secours pour les messages encodés X12, qui est http://schemas.microsoft.com/BizTalk/Edi/X12/2006par défaut .

Pour les échanges X12, une fois l’espace de noms cible découvert, BizTalk Server détermine le schéma à l’aide des informations suivantes :

  • L'espace de noms cible venant d'être détecté.

  • La version d'origine/version finale dans les cinq premiers caractères de ST03 (si GS07 == X - Accredited Standards Committee X12). Si ST03 n'est pas présent/valide ou ne donne pas la résolution de schéma, la version est déterminée par les cinq premiers caractères de GS08 ou de ISA12 (si GS07 != X).

  • Le DocType dans ST01.

    Le Désassembleur EDI concatène le type de codage, la version d'origine/version finale et le DocType pour déterminer le nom de schéma, par exemple, « X12_00401_864 ». Il concatène ensuite l’espace de noms cible avec le nom de schéma, par exemple . http://schemas.microsoft.com/BizTalk/Edi/X12/2006/X12#X12_00401_864

    Pour un échange HIPAA 837 entrant, BizTalk Server prend en charge trois schémas HIPAA 837 :

Schéma 837 Valeur GS08 dans la version 4010 Valeur GS08/ST03 dans la version 5010
Claim-Dental_837D 004010X097A1 005010X224A1
Claim-Institutional_837I 004010X096A1 005010X223A1
Claim-Professional_837P 004010X098A1 005010X222

Notes

Dans les versions HIPAA, pour le document informatisé 278 (Health Care Services Review), les paires de requête et réponse partagent la même valeur pour GS08 et ST01. En fonction des valeurs de déclenchement dans le champ BHT02, vous pouvez différencier une requête et une réponse 278 dans la version 5010 :

  1. L'une des valeurs 01, 13 et 36 dans BHT02 indique un Health Care Services Review Request.
    2. 11 dans BHT02 indique la réponse à l’examen des services de soins de santé

Détection de schéma EDIFACT

Pour les messages encodés en EDIFACT, BizTalk Server détermine un espace de noms personnalisé à l’aide du type de message (UNH2.1), du numéro de version du message (UNH2.2), du numéro de publication du message (UNH2.3), du code attribué (UNH2.5), de l’ID de groupe fonctionnel (UNG2.1) et du qualificateur de code d’envoi d’application (UNG2.2) à partir de l’en-tête de l’échange entrant. Il tente ensuite de trouver une correspondance entre ces valeurs et les valeurs des propriétés UNH2.1, UNH2.2, UNH2.3, UNH2.5, UNG2.1 et UNG2.2 dans la grille Personnaliser l’espace de noms cible (sous Paramètres de l’ensemble de transactions) de l’onglet accord bidirectionnel de la boîte de dialogue Propriétés de l’accord . S'il trouve une correspondance, il utilise l'espace de noms cible identifié dans la même ligne de la grille pour déterminer le schéma à utiliser pour valider et traiter le message. Si l'espace de noms cible n'est pas déterminé, l'espace de noms cible par défaut est utilisé. Si aucun espace de noms n’est identifié dans le champ Espace de noms Cible marqué pour la ligne par défaut, BizTalk Server utilisera l’espace de noms cible identifié dans les propriétés de l’accord de secours pour les messages encodés ediFACT, qui est http://schemas.microsoft.com/BizTalk/Edi/EDIFACT/2006par défaut .

Pour les échanges EDIFACT, une fois l’espace de noms cible découvert, BizTalk Server détermine le schéma à l’aide des informations suivantes :

  • Espace de noms cible que vous venez de découvrir.

  • Le numéro de version du message dans UNH2.2.

  • Le numéro de version finale du message dans UNH2.3.

  • Le type de message dans UNH2.1.

  • Le code assigné dans UNH2.5.

    Le Désassembleur EDI concatène le type de codage, la version, la version finale et le type de message pour déterminer le nom de schéma, par exemple, « EFACT_D94A_CONTEN ». Il concatène ensuite l’espace de noms cible avec le nom de schéma, par exemple . http://schemas.microsoft.com/BizTalk/Edi/Edifact/2006/EFACT#EFACT_D94A_CONTEN

    Si UNH2.5 est présent dans le message, le Désassembleur EDI tente d'abord de trouver un schéma correspondant à l'aide de la valeur de UNH2.5 dans le nom de schéma, par exemple « EFACT_D94A_CONTEN_TEST ». Si aucun schéma correspondant n'est trouvé, le Désassembleur EDI bascule pour trouver le schéma sans la valeur UNH2.5.

Autorisation

BizTalk Server vérifie les valeurs des champs d’autorisation et de sécurité définis pour l’accord avec les champs du message. En cas d’incompatibilité, BizTalk Server suspend l’échange. Pour les messages EDIFACT, ces champs sont Mot de passe du destinataire (UNB6.1 et UNB6.2). Pour les messages X12, ces champs sont Qualificateur et informations d'autorisation (ISA1-2) et Qualificateur et informations de sécurité (ISA3-4).

Voir aussi

Réception des messages EDI par BizTalk Server