MDN 消息
消息处置通知 (MDN) 用于确认已发送 AS2 消息。 如果启用了 MDN,则 AS2 传输直到接收并验证 MDN 后才完成。 即使在处理 AS2 消息过程中出错,BizTalk Server 也将始终尝试返回一个 MDN 以指示消息处理的状态。
MDN 用于确认以下过程:
接收方已成功接收原始消息。 原始消息的发送方通过比较已发送原始消息的 MessageID 与接收方包括在 MDN 中的 original-message-id 字段来验证这一点。
接收伙伴验证交换的数据的完整性。 原始消息的发送方通过将从原始发送的消息有效负载计算的 MIC 与接收方根据接收的消息有效负载计算并包含在 MDN (的 Received-content-MIC 字段中(如果签名) )的 MIC 进行比较来验证这一点。
收据是不可否认的。 为此,发送方使用接收伙伴的公钥验证已签名的 MDN,并验证 MDN 中返回的 MIC 值是否与不可否认数据库中存储的原始消息有效负载的 MIC 相同。
备注
同步 MDN 可用作 HTTP 响应,例如:200 OK。
如果在“协议属性”对话框的单向协议选项卡上选择了使用 协议设置进行验证和 MDN 而不是消息标头 属性,则 AS2Receive 接收管道将使用参与方的 AS2 协议属性生成 MDN 。 在这种情况下,消息标头中的 AS2-From 属性将用于生成 MDN,但其他属性将从参与方的 AS2 协议设置中获取。
如果未选择替代 AS2 属性的选项,或者参与方的 AS2 协议可用,则接收管道将使用传入消息中的 AS2 标头标记生成 MDN。
MDN 可进行签名,但不能加密或压缩。
处理 MDN 消息时使用的上下文属性包括可以升级的属性以及未公开但可以在已挂起和跟踪的消息中查看的属性。 有关这些上下文属性的列表,请参阅 AS2 上下文属性。
若要生成 MDN,必须同时升级 DispositionMode 和 DispositionType 上下文属性。 如果在 AS2 或 EDI 负载中出现错误,则 DispositionType 属性将指示出该错误。 可以在“消息详细信息”对话框中看到此属性,该对话框通过“服务详细信息”对话框 (显示,) BizTalk Server管理控制台的“组中心”页中的“挂起的服务实例”。 如果标头中出现错误,BizTalk Server 将在 DispositionType 属性中指示该错误,并根据该错误尝试发送 MDN(对某些错误,可能无法执行此操作)。
MDN 包含下列标头:
HTTP/AS2 标头。 有关详细信息,请参阅 AS2 消息。
传输层。 这包括内容类型标头,其中包括签名的多部分消息、MIC 的算法、签名格式化协议以及最外面的多部分边界子标头。
第一部分。 多部分签名消息的第一部分是嵌入式 MDN。 它是人工可读取的。
第二部分。 多部分签名消息的第二部分包含数字签名、原始消息的引用、处置类型和状态、MIC 值。 它是机器可读取的。
AS2-From 标头、AS2-To 标头和 MessageID 上下文属性用于将 MDN 与其要做出响应的 AS2 消息相关联。 MDN 中的 Original-Message-ID 标头来自 MDN 所响应的 AS2 消息的 Message-ID 标头。
MIC) (消息完整性检查用于验证 MDN 是否与原始发送的消息有效负载相关联。 MIC 摘要包括在多部分签名 MDN 消息的第二部分中的 Received-Content-MIC 扩展字段中。
如果已启用 MDN,则当 AS2 发送管道处理出站消息时,它将通过相应的消息负载计算 MICHashValue。 该发送管道在 BizTalkMsgBoxDb 数据库的 EdiInt_Mic 表中保存哈希值。 系统在此表中跟踪 AS2 消息,并使用 AS2From、AS2To 和 MessageID 值和伴随的 MICHashValue 列唯一标识这些消息。 消息的接收方在处理消息负载时计算 MIC 哈希值,并在它返回的 MDN 中包括该哈希值。 原始消息的发送方将把它接收的 MDN 中的 MIC 哈希值与它所保存的哈希值相比较。 如果这两个值相匹配,则处置 MDN、删除 EdiInt_Mic 表中的条目,传输将完成。
MIC 是 base64 编码的。 对 MIC 可使用 SHA1 或 MD5 算法。 如果在“协议属性”对话框的单向协议选项卡的“发件人 MDN 设置”页中选中) “请求签名的 MDN”属性,则从“签名算法”下拉列表 (确定。 也可通过原始消息的 Signed-Receipt-MICalg AS2 标头来确定。