深入biztalk中Delivery Notification和ACK、NACK机制

原创 2007年09月28日 14:10:00

考虑这样一种情况:用orchestration处理一个order,在流程中做了处理后通过一个发送端口发送到商业伙伴那里,然后需要明确的知道order确实通过发送端口发送到商业伙伴之后才能继续之后的流程处理,如果发送order没有成功,则在orchestration中做异常处理。

按照biztalk的正常的消息发布订阅机制,上述的情况是物理发送端口订阅orchestration的逻辑发送端口发送的order消息,当orchestrationorder消息发送到Messagebox,消息引擎根据订阅关系,把order消息发送到订阅这个order的物理发送端口,至此,orchestration发送order的过程就算完成,至于物理发送端口是否把消息顺利的发送出去(可能顺利的发送了出去,可能在发送端口内部出错,也可能从端口发送出去后从另一端返回错误信息)orchestration无从知道。

针对这种情况,biztalk提供一种反馈机制,发送端口(单向发送端口或者双向发送端口)可以根据需要返回发送成功的ACK消息(Positive Acknowledgment)和发送失败的NACK消息(Negative Acknowledgment),如果发送端口成功的把消息发送出去了,则可以返回ACK消息,如果发送端口发送消息失败(不管是发送端口内部出错还是发送出去后收到错误信息),则返回NACk消息。Orchestration收到ACK或者NACK消息后,就可以知道消息是否正常的发送出去了,根据得到的反馈消息,进行之后的流程。一般的收到ACK反馈消息,流程正常的继续下去,收到NACK消息,orchestration会生成一个DeliveryFailureException异常,在orchestration中可以设计一个异常捕获,捕获DeliveryFailureException异常后进行异常处理。

 

深入分析反馈机制

要使用发送端口反馈机制,需要做一些设置。

l         逻辑发送端口的Delivery Notification属性设置为 Transmitted

这是告诉biztalk消息引擎,发送出去的消息是需要反馈消息的。

l         Send shap所在scopeSynchronizd属性设置为true

(但是测试表明,这个属性跟ACKNACK的反馈关系不大)

l         Scope形状可以设置Exception Handler捕获DeliveryFailureException异常

如果从物理发送端口返回的NACK消息,那么orchestration将在这个scope的位置产生一个DeliveryFailureException异常,可以被Scope形状的Exception Handler捕获,进而进行进一步的异常处理。

 

下面详细分析一个消息在orchestration被发送出去后,到orchestration收到ACK消息或者NACK消息的整个过程的底层机制。

一、    orchestration中消息从逻辑端口发出

消息在orchestration到达逻辑发送端口时,因为逻辑发送端口的Delivery Notification属性设置为 Transmittedbiztalk将会做两件事:

1、  在消息的上下文属性中增加一个系统属性:AckRequired = true

在将要发送出去的消息的上下文属性中,增加一个系统属性AckRequired = true,这个属性的作用是告诉接收这个消息的物理发送端口,此消息是需要反馈消息的,物理发送端口在收到的消息中发现有这个属性,就会在端口发送消息成功后形成ACK消息,在发送失败后生成NACK消息,并发布消息

如果逻辑发送端口的Delivery Notification属性设置为none,消息中将不会包含AckRequired = true的系统属性,物理发送端口也不会生成ACKNACK消息并发布。

2、  在逻辑发送端口位置新建一个实例订阅,订阅发送端口返回的ACKNACK消息。

首先在逻辑发送端口处初始化一个correlation token(相关标识)赋给出站消息的上下文的系统属性CorrelationToken

之后新建一个实例订阅,订阅者为这个orchestration服务实例的逻辑发送端口。看一下数据库Subscription订阅表中的一个此类实例订阅的一个示例:

uidSubID(此实例订阅的uid -- 2b78f65c-a983-4a49-b626-afc551d54c98

uidClassID(产生订阅的服务类型) -- 226fc6b9-0416-47a4-a8e8-4721f1db1a1b(表示是XLANG/s服务)

uidServiceID(产生此订阅的具体服务)-- 63eb391b-37ee-3243-56b1-e93e8bd7ec05(这个orchestrationguid

uidPortID(表示业务流程中订阅消息的端口shape-- 63eb391b-37ee-3243-5622-7452edd13162(发送消息的逻辑端口,ACKNACK还是由它来接收)

uidInstanceID(产生此订阅的实例的guid-- ba1eff99-c1b2-447b-882d-d391e1b17b6f(此orchestration服务实例的guid

这个实例订阅的条件在messagebox数据库中的EqualsPredicates表中,看一下这个实例订阅的订阅条件示例,条件就一个,消息的系统属性CorrelationToken为相关集的token

uidPropID(属性guid-- 593badb0-43fb-40c2-a211-8e148f102109(查阅bt_DocumentSpec系统属性表,这个guid表示的系统属性为http://schemas.microsoft.com/BizTalk/2003/system-properties#CorrelationToken,即系统属性CorrelationToken

vtValue(属性的值) -- 31e04a93-9e4a-4584-8c7b-71e09c733ed3(就是初始化的那个相关集的token

 

在给出站消息添加了系统属性AckRequiredCorrelationToken后,orchestration把消息发布到messagebox,同时生成一个实例订阅,订阅系统属性CorrelationToken相符的消息。在消息发布出去后,直到直接外层long running scope结束处,等待ACK或者NACK消息的返回。

二、    消息在发送端口

物理发送端口订阅了orchestration逻辑发送端口的消息,在收到消息后,物理发送端口发现有AckRequiredCorrelationToken属性,知道这个消息是需要提供反馈的。

物理端口执行正常的发送工作,将收到的消息经过发送管道,发送适配器发送出去。

如果消息成功的发送了出去,物理发送端口就会生成一个ACK消息,这个ACK消息只有上下文属性,没有消息正文,ACK包含的属性有:

属性名

描述

BTS.AckFailureCategory

Identifies the ErrorCategory, which gives the place and reason for the suspension.

BTS.AckFailureCode

Identifies the ErrorCode, which gives the place and reason for the suspension.

BTS.AckType

Value is ACK for a positive acknowledgment and NACK for a negative acknowledgment.

BTS.AckID

Identifies the MessageID of the original message.

BTS.AckOwnerID

Identifies the instance ID from the original message.

BTS.CorrelationToken

Identifies the correlation token from the original message if one is present.

BTS.AckDescription

Identifies the ErrorDescription, which gives the place and reason for the suspension.

BTS.AckSendPortID

Identifies the SendPortID from the original message.

BTS.AckSendPortName

Identifies the SendPortName from the original message.

BTS.AckOutboundTransportLocation

Identifies the OutboundTransportLocation from the original message.

BTS.AckReceivePortID

Identifies the ReceivePortID from the original message.

BTS.AckReceivePortName

Identifies the ReceivePortName from the original message.

BTS.AckInboundTransportLocation

Identifies the InboundTransportLocation from the original message.

其中的CorrelationToken属性就是发送端口从接收到消息上下文属性中这个属性获取的。发送端口发布这个ACK消息后,orchestration要靠匹配这个属性获得ACK消息。

如果消息发送失败,包括消息在物理发送端口内部出错,消息发送出了物理发送端口后从对方收到了错误信息,发送端口都会生成一个NACK消息。NACK消息跟ACK消息一样拥有上述的上下文属性,另外NACK还有一个SOAP fault的消息正文,一般形式如下:

 

<?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>


物理发送端口在发送消息失败后,把发送端口服务实例挂起,同时发布
NACK消息。

三、    ACKNACK返回orchestration

发送端口发布ACKNACK消息后,根据实例订阅的订阅条件(CorrelationToken),消息引擎把ACKNACK消息路由到发送消息的那个orchestration服务实例。

如果接收到的是ACK消息,orchestration从之前停留等待反馈消息的发送形状那里继续按照正常的流程继续下去。

如果接收到的是NACK消息,orchestration在发送形状所在的scope产生一个DeliveryFailureException异常,异常可以被scopeexception handler捕获,在异常处理中做相应的处理。

 

在异常处理中可以:

// DeliveryFailureException类型转换成 SoapException类型

System.Web.Services.Protocols.SoapException se = (System.Web.Services.Protocols.SoapException)e.InnerException;
   
System.Diagnostics. EventLog.WriteEntry (NACK内容,se.Detail.InnerXml); 

 

下面就是可以在windows日志中看到返回的NACK详细内容的xml

<ns0:NACK Type="NACK" xmlns:ns0="http://schema.microsoft.com/BizTalk/2003/NACKMessage.xsd">

      <NAckID>{BD6682EE-1741-4856-8CC7-B2EE36B7874E}</NAckID>

      <ErrorCode>0xc0c01c10</ErrorCode>

      <ErrorCategory>0</ErrorCategory>

      <ErrorDescription>The FILE send adapter cannot open file C:/Foo/DeliveryNotification/out/{505A3211-9081-4720-827B-A0DE2BD124FD}.xml for writing. </ErrorDescription>

</ns0:NACK>

 


   以上过程就是一个设置了
Delivery Notification属性的发送端口发送消息的整个过程。

 

此外,ACKNACK消息处理除可以被发送消息的orchestration本身接收外,还可以设计一个专门的orchestration,根据NACK消息的系统属性,通过Content-based的路由NACK消息,接收biztalk应用中所有的NACK消息,然后进行相关的处理,比如统一记入错误日志,做错误统计等等。

 参考:
 
 biztalk文档Development > Developing BizTalk Server Applications > Using the BizTalk Messaging Engine > Error Handling > Using Acknowledgments
 Kevin B Smith 《Acknowledgments and Negative Acknowledgments (Part 1)》

 
版权声明:本文为博主原创文章,未经博主允许不得转载。

相关文章推荐

对I2C总线时序的一点理解以及ACK和NACK(NAK)

关键字: i2c ,IIC,bus, ACK,NACK,NAK,SDA,SCL,timing,master,slaver,时序,响应,总线 关于i2c的响应问题:对于每一个接收设备(从设备,...

TDD LTE中的 ACK/NACK Bundling和 Multiplexing

TDD LTE中,上下行之间不一定是对称的。在下行子帧多于上行子帧的配置中,会出现一个上行子帧中同时上报多个下行子帧的HARQ的情况。一个上行子帧中上报HARQ的数目取决于LTE上下行的配置以及下行的...

对I2C总线时序的一点理解以及ACK和NACK(NAK)

关于i2c的响应问题:对于每一个接收设备(从设备,slaver),当它被寻址后,都要求在接收到每一个字节后产生一个响应。因此,the master device 必须产生一个额外的时钟脉冲(第九个脉冲...

BizTalk Server 事务机制

概述BizTalk Server 业务流程引擎可管理复杂流程和/或事务集的状态,对其应用业务逻辑,并调用其支持应用程序。 业务流程可由使用原子事务的若干分立工作组成,这些原子事务在发生错误或长时间运行...

iphone notification机制导读

  • 2010-05-28 10:52
  • 221KB
  • 下载

TCP的ACK原理和延迟确认机制

一、ACK定义TCP协议中,接收方成功接收到数据后,会回复一个ACK数据包,表示已经确认接收到ACK确认号前面的所有数据。ACK字段长度为32位,能表示0~2^32-1之间的值。二、ACK作用发送方在...

RabbitMQ消息应答------ack机制

Message acknowledgment(消息应答) 执行一个任务可能需要花费几秒钟,你可能会担心如果一个消费者在执行任务过程中挂掉了。一旦RabbitMQ将消息分发给了消费者,就会从内存中删除...

storm ack机制流程详解

storm ack机制现在网上一堆资料。根据我的理解,对可靠版的word count进行了流程分析。 spout每发出一条信息,会根据用户指定的message id生成root id(假...

ESFramework 开发手册(09) -- ACK机制与同步调用

正如ESFramework 开发手册(01) -- 发送和处理信息一文中所介绍的,我们在客户端使用ICustomizeOutter接口的Send方法,可以给服务端或其它在线客户端发送自定义信息,那么,...

storm 的ack机制(可靠性)

一  可靠性 简介                     Storm的可靠性是指Storm会告知用户每一个消息单元是否在一个指定的时间(timeout)内被完全处理。 ...
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:深度学习:神经网络中的前向传播和反向传播算法推导
举报原因:
原因补充:

(最多只允许输入30个字)