Résolution de l'accord et détermination du schéma pour les messages EDI sortants

Pour générer un message EDI vers un partenaire commercial, le pipeline d'envoi EDI doit effectuer les opérations suivantes :

• déterminer l'accord correspondant au message ;

• déterminer le schéma à utiliser pour valider le message.

Résolution d’accord

Le pipeline d'envoi EDI effectue une recherche d'accord par le biais d'une série d'étapes pour déterminer s'il existe une correspondance entre l'échange sortant et les propriétés d'un 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 générer et valider le message sortant.

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

1. Résout l'accord en faisant correspondre la propriété de contexte AgreementPartIDForSend à l'ID de l'accord unidirectionnel. Cette propriété doit être de type entier, elle peut être définie dans un composant personnalisé ; elle n’est pas définie par BizTalk Server.

2. Si l'étape 1 échoue, résout l'accord en mettant en correspondance les trois propriétés de contexte suivantes avec les propriétés d'accord AgreementNameForSend, SenderPartyNameForSend, ReceiverPartyNameForSend. Notez que celles-ci doivent être définies de manière à être correctement associées à un accord. Ces propriétés peuvent être définies dans un composant personnalisé ; elle n’est pas définie par BizTalk Server.

3. Si l’étape 2 échoue, résout le contrat en faisant correspondre le nom de partie dans les propriétés de contexte de message à la propriété DestinationPartyName, qui est définie comme programme de résolution de contrat supplémentaire sous l’onglet Identificateurs des propriétés du contrat.

4. En cas d'échec de l'étape 3, résout l'accord en mettant en correspondance les propriétés suivantes dans le contexte d'un message avec celles des propriétés d'accord DestinationPartySenderIdentifier, DestinationPartySenderQualifier, DestinationPartyReceiverIdentifier et DestinationPartyReceiverQualifier. Notez que les quatre propriétés doivent être définies pour pouvoir être résolues correctement en contrat. Ces propriétés peuvent être définies dans un composant personnalisé ; ils ne sont pas définis par BizTalk Server. Pour plus d’informations, voir plus bas.

   Notes

   Si l’un des ensembles de propriétés de contexte ci-dessus est promu et BizTalk Server ne parvient pas à trouver un accord associé à ces propriétés de contexte, BizTalk Server suspend le message.

   Si l'utilisateur écrit intentionnellement un ensemble de propriétés de contexte à des fins de résolution d'accord et si le résolveur ne parvient pas à identifier OnewayAgreement, le message est suspendu. En cas d'échec de la résolution d'un accord en fonction d'un ensemble de propriétés de contexte, un message d'avertissement est généré dans EventLog.

5. Si l'étape 4 échoue ou qu'aucune des propriétés de contexte ci-dessus n'est promue, le message EDI est mappé à un accord en faisant correspondre le port d'envoi abonné au message au port d'envoi associé à un accord.

   Notes

   Si le même port d'envoi est associé à plusieurs accords, BizTalk Server génère une erreur.

6. Si aucun accord n'est trouvé lors de l'étape 1, 2, 3 ou 4, le pipeline d'envoi utilise les paramètres d'accord de secours pour générer le message sortant.

   Résolution du contrat par les propriétés de contexte de l’expéditeur et du destinataire correspondantes

   Dans l'étape 2 ci-dessus, les quatre propriétés de contexte utilisées dans la correspondance sont les suivantes : EDI.DestinationPartySenderIdentifier, EDI.DestinationPartySenderQualifier, EDI.DestinationPartyReceiverIdentifier et EDI.DestinationPartyReceiverQualifier. L’espace de noms de ces propriétés de contexte est http://schemas.microsoft.com/Edi/PropertySchema. BizTalk Server tente de faire correspondre ces valeurs aux identificateurs et qualificateurs de l’expéditeur et du destinataire associés dans les propriétés d’accord unidirectionnel. Pour X12, ces champs sont ISA05, ISA06, ISA07 et ISA08 dans la page Identificateurs de l’onglet contrat unidirectionnel de la boîte de dialogue Propriétés de l’accord ; pour EDIFACT, ces champs sont UNB2.1, UNB2.2, UNB3.1 et UNB3.2 dans la page Identificateurs de l’onglet contrat unidirectionnel de la boîte de dialogue Propriétés de l’accord .

   Pour activer la résolution d'accord côté envoi à l'aide des quatre qualificateurs et identificateurs de l'expéditeur et du récepteur, vous devez définir les quatre propriétés de contexte afin d'identifier l'accord de manière unique. L'utilisation de cette méthode de recherche d'accord offre une flexibilité accrue dans le cadre du traitement côté envoi. Par exemple, elle peut vous éviter de créer plusieurs ports d'envoi sous certaines circonstances et de faire appel à des filtres de port d'envoi complexes. Elle vous évite également de devoir définir la propriété OneWayAgreementId (le cas échéant).

   Si les quatre propriétés de contexte ont été définies pour un message et qu'aucune correspondance n'est trouvée entre celles-ci et les propriétés de propriété, le message est suspendu. L'accord est résolu à l'aide du port d'envoi associé à l'accord uniquement si aucune des quatre propriétés de contexte n'a été définie.

Détermination du schéma

Le pipeline d'envoi EDI détermine le schéma qui s'applique au message à partir des nom et espace de noms du schéma contenus dans le fichier XML intermédiaire de chaque document informatisé (soit en tant qu'informations de type de document soit dans le nœud racine).

Pour un échange conservé, le pipeline d'envoi utilise les informations de type de document des documents informatisés spécifiques du fichier XML intermédiaire pour l'échange complet. Il utilise les schémas de segment de contrôle pour le traitement des segments d'enveloppe.

Voir aussi

Envoi des messages EDI par BizTalk Server