使用致谢

2025-06-05

BizTalk 消息引擎生成正确认（ACK）和负确认（NACK），以响应通过端口处理消息时遇到的情况。 BizTalk Server 发布肯定确认以指示消息的成功传输，以及发布否定确认以指示消息的传输失败和挂起。

为何使用确认？

积极和负面的确认提供强烈的反馈，可用于确定消息是否已到达其目标，或者在此过程中遇到一个或多个问题。例如，确认在以下情况下很有用：

你想要监视新贸易合作伙伴的接收端口，以便进行架构验证和其他错误。
如果成功发送给合作伙伴进行审批，则希望将已发送的贷款请求的状态标记为“正在处理”;如果传输失败（例如，如果合作伙伴的服务器已关闭），则将其标记为“正在失败”。
处理包含多个采购订单的信息交换，并想要跟踪成功传输或传输失败的订单数量。

可以使用使用筛选器的确认和基于内容的路由来完成上述每个方案。

路由确认

发布 ACK 或 NACK 时，导致 ACK/NACK 的消息中的所有消息上下文属性都会被降低状态。提升的任何属性都不会纳入确认。若要路由确认消息，请使用BTS命名空间中的以下属性来创建筛选条件：

属性名称	数据类型	DESCRIPTION
BTS。AckFailureCategory	xs：int	标识 ErrorCategory，该类别说明暂停的位置和原因。
BTS.AckFailureCode	xs：string	识别 ErrorCode，指明挂起的位置和原因。
BTS.AckType	xs：string	对于正确认，值为 ACK，对于负确认，则为 NACK。
BTS.AckID	xs：string	标识原始消息的 MessageID 。
BTS.AckOwnerID	xs：string	标识原始消息中的实例 ID。
BTS.CorrelationToken	xs：string	标识原始消息中的关联令牌（如果存在）。
BTS.AckDescription	xs：string	识别ErrorDescription，描述挂起的位置和原因。
BTS。AckSendPortID	xs：string	标识原始消息中的 SendPortID 。
BTS.AckSendPortName	xs：string	标识原始消息中的 SendPortName 。
BTS.AckOutboundTransportLocation	xs：string	从原始消息中标识 OutboundTransportLocation 。
BTS.AckReceivePortID	xs：string	标识原始消息中的 ReceivePortID 。
BTS.AckReceivePortName	xs：string	标识原始消息中的 ReceivePortName 。
BTS.AckInboundTransportLocation	xs：string	从原始消息中识别 InboundTransportLocation。

注释

包含错误信息的属性在 ACK 中不存在，因为它们表示正传递。

否定确认消息正文

有关正确认或负面确认的很多重要信息都包含在上下文属性中。除了上下文属性，NACK 还包含包含 SOAP 错误的消息正文部分。 SOAP 错误的格式如下所示：

<?xml version="1.0" encoding="utf-8"?>  
<SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/" SOAP:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">  
  <SOAP:Body>  
    <SOAP:Fault>  
      <faultcode>Microsoft BizTalk Server Negative Acknowledgment </faultcode>  
      <faultstring>An error occurred while processing the message, refer to the details section for more information </faultstring>  
      <faultactor>C:\Projects\Sample\Locations\Response\FM_%MessageID%.xml</faultactor>  
      <detail>  
        <ns0:NACK Type="NACK" xmlns:ns0="http://schema.microsoft.com/BizTalk/2003/NACKMessage.xsd">  
          <NAckID>{FFB1A60B-E593-4620-8897-4E9C7030A937}</NAckID>  
          <ErrorCode>0xc0c01658</ErrorCode>  
          <ErrorCategory>0</ErrorCategory>  
          <ErrorDescription>There was a failure executing the send pipeline: "Microsoft.BizTalk.DefaultPipelines.XMLTransmit, Microsoft.BizTalk.DefaultPipelines, Version=3.0.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" Source: "XML assembler" Send Port: "Failed Message" URI: "C:\Projects\Sample\Locations\Response\FM_%MessageID%.xml" Reason: This Assembler cannot retrieve a document specification using this type: "http://Sample#Unknown".  </ErrorDescription>  
        </ns0:NACK>  
      </detail>  
    </SOAP:Fault>  
  </SOAP:Body>  
</SOAP:Envelope>

适配器引发的异常消息位于 ErrorDescription 元素的 SOAP 详细信息部分。

从业务流程访问消息正文

如果您有一个需要传递通知的编排端口，当传输失败时会引发 DeliveryFailureException，该异常是从包含在 NACK 消息正文中的 SOAP 错误反序列化而来的。若要在编排过程中访问异常消息字符串，请将 DeliveryFailureException 转换为 SoapException，然后访问 InnerXml，如以下代码所示：

// Cast the DeliveryFailureException to a SoapException…  
System.Web.Services.Protocols.SoapException se = (System.Web.Services.Protocols.SoapException)e.InnerException;  
System.Diagnostics.Trace.WriteLine(se.Detail.InnerXml);  
//e is an Microsoft.XLANGs.BaseTypes.DeliveryFailureException  
//object type created in an Exception handler

前面的代码示例返回类似于下面的 XML 片段：

<?xml version="1.0" encoding="utf-8"?>  
<ns0:NACK Type="NACK" xmlns:ns0="http://schema.microsoft.com/BizTalk/2003/NACKMessage.xsd">  
  <NAckID>{FFB1A60B-E593-4620-8897-4E9C7030A937}</NAckID>  
  <ErrorCode>0xc0c01658</ErrorCode>  
  <ErrorCategory>0</ErrorCategory>  
  <ErrorDescription>There was a failure executing the send pipeline: "Microsoft.BizTalk.DefaultPipelines.XMLTransmit, Microsoft.BizTalk.DefaultPipelines, Version=3.0.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" Source: "XML assembler" Send Port: "Failed Message" URI: "C:\Projects\Sample\Locations\Response\FM_%MessageID%.xml" Reason: This Assembler cannot retrieve a document specification using this type: "http://Sample#Unknown".</ErrorDescription>  
</ns0:NACK>

何时发布确认？

在发生故障时，如果至少有一个匹配的订阅，正（ACK）和负（NACK）确认都将被发布到 MessageBox 数据库。例如，如果 BizTalk Server 找不到从接收端口读取的消息的匹配架构，并且没有 NACK 订阅，它将挂起消息（在未启用失败消息路由功能的情况下），并且不发布 NACK。

另请参阅

错误处理
 使用失败的消息路由

通过