Messages MDN
Le MDN (Message Disposition Notification) est l'accusé de réception envoyé en réponse à un message AS2. Si un MDN est activé, la transmission AS2 n’est pas terminée tant que le MDN n’a pas été reçu et vérifié. BizTalk Server tente toujours de retourner un MDN pour indiquer la status du traitement des messages, même si une erreur s’est produite lors du traitement du message AS2.
Le MDN vérifie les éléments suivants :
Que le message d’origine a été reçu avec succès par la partie réceptrice. L'expéditeur du message d'origine vérifie ceci en comparant l'ID du message initialement envoyé au champ original-message-id inclus par le récepteur dans le MDN.
Que l’intégrité des données échangées a été vérifiée par le partenaire destinataire. L'expéditeur du message d'origine s'en assure en comparant le MIC calculé à partir de la charge du message d'origine envoyé au MIC calculé par le récepteur sur la charge du message reçu et inclus dans le champ Received-content-MIC du MDN (s'il est signé).
Qu’il n’y a pas de répudiation de réception. L'expéditeur s'en assure en comparant le MDN signé à la clé publique du partenaire destinataire et en vérifiant que la valeur de MIC renvoyée dans le MDN est identique au MIC de la charge du message d'origine conservé dans la base de données de non-répudiation.
Notes
Une MDN synchrone sert de réponse HTTP (par exemple : 200 OK).
Notes
Pour plus d’informations sur le traitement côté réception des MDN, consultez Traitement d’un MDN entrant. Pour plus d’informations sur le traitement côté envoi des MDN, consultez Envoi d’un MDN sortant.
Le pipeline de réception AS2Receive génère un MDN à l’aide des propriétés du contrat AS2 d’une partie si la propriété Utiliser les paramètres du contrat pour la validation et MDN au lieu de l’en-tête de message est sélectionnée sous l’onglet Contrat unidirectionnel dans la boîte de dialogue Propriétés du contrat . Dans ce cas, la propriété AS2-From de l'en-tête du message sert à générer le MDN, mais les autres propriétés sont extraites des paramètres de l'accord AS2 du tiers.
Si l'option de remplacement de la propriété AS2 n'est pas sélectionnée, ou que l'accord AS2 du tiers est disponible, le pipeline de réception génère le MDN à l'aide des balises d'en-tête AS2 dans le message entrant.
Un MDN peut être signé, mais il ne peut être ni chiffré ni compressé.
Les propriétés de contexte utilisées pour traiter les messages MDN incluent les propriétés qui peuvent être promues et celles qui ne sont pas exposées publiquement, mais peuvent être vues dans les messages suspendus et suivis. Pour obtenir la liste de ces propriétés de contexte, consultez Propriétés de contexte AS2.
Les propriétés de contexte DispositionMode et DispositionType doivent toutes deux être promues pour qu'un MDN soit généré. Si une erreur se produit dans la charge AS2 ou EDI, la propriété DispositionType indique une erreur. Vous pouvez voir cette propriété dans la boîte de dialogue Détails du message qui s’affiche (via la boîte de dialogue Détails du service) à partir des instances du service suspendu dans la page Hub de groupe de la console d’administration BizTalk Server. Si une erreur se produit dans l’en-tête, BizTalk Server indique l’erreur dans la propriété DispositionType et tente d’envoyer le MDN, mais en fonction de l’erreur, peut ne pas être en mesure de le faire.
Le MDN contient les en-têtes suivants :
En-têtes HTTP/AS2. Pour plus d’informations, consultez Messages AS2.
Couche de transfert. Elle inclut l'en-tête Content-Type, qui inclut le message signé à parties multiples, l'algorithme du MIC, le protocole de formatage de la signature et les sous-en-têtes de limite de parties multiples les plus externes.
Première partie. La première partie d'un message signé à parties multiples est le MDN incorporé. Elle est lisible par l'homme.
Deuxième partie. La deuxième partie d'un message signé à parties multiples contient la signature numérique, une référence au message d'origine, le type de disposition et l'état, ainsi que la valeur du MIC. Elle est lisible par une machine.
Les en-têtes AS2-From et AS2-To et la propriété de contexte MessageID servent à corréler un MDN au message AS2 auquel il répond. L'en-tête Original-Message-ID d'un MDN provient de l'en-tête Message-ID du message AS2 auquel le MDN répond.
Le MIC (Message Integrity Check) permet de vérifier qu'un MDN est corrélé à la charge du message d'origine envoyé. Le Digest du MIC est inclus dans le champ d'extension Received-Content-MIC, dans la deuxième partie du message MDN signé à parties multiples.
Si un MDN est activé et qu'un pipeline d'envoi AS2 traite un message sortant, le pipeline calcule une valeur MICHashValue à partir de la charge du message. Le pipeline d'envoi enregistre la valeur de hachage dans la table EdiInt_Mic de la base de données BizTalkMsgBoxDb. Les messages AS2 sont soumis à un suivi dans cette table et identifiés de façon unique par les valeurs AS2From, AS2To et MessageID, ainsi que par la colonne MICHashValue les accompagnant. Le récepteur du message calcule la valeur de hachage du MIC lorsqu'il traite la charge du message et il inclut cette valeur de hachage dans le MDN renvoyé. L'expéditeur du message d'origine compare la valeur de hachage du MIC figurant dans le MDN qu'il reçoit à la valeur de hachage qu'il a enregistrée. Si ces valeurs correspondent, il supprime le MDN, ainsi que l'entrée dans le tableau EdiInt_Mic, et la transmission est terminée.
Le MIC est codé en Base64. L'algorithme appliqué au MIC peut être SHA1 ou MD5. Il est déterminé à partir de la liste déroulante Algorithme de signature (activé si la propriété Requête MDN signée est activée) dans la page Paramètres MDN de l’expéditeur de l’onglet Contrat unidirectionnel de la boîte de dialogue Propriétés du contrat . Il est également déterminé à partir de l'en-tête AS2 Signed-Receipt-MICalg du message d'origine.
Messages AS2
Traitement d’une notification de réception du message entrante
Envoi d’une notification de réception du message sortante