传入消息的自定义确认

时间:2016-07-12 21:15:17

标签: biztalk biztalk-2013

我不确定我是否正确行事。

我们的编排如下:

ReceiveOrder
TryScope (Long Running)
   AcknowledgementScope (Atomic)
     ConstructOrderAckMessage
        TransformOrderToAck (using a map)
     SendOrderAckToMessageQueue
   AtomicWebServiceScope
      ImportOrderToDBExpression
   Construct and send message to another process
CatchException
      ConstructErrorExpression
      HandleExceptionStartOrchestration

当我们用大约6000个订单测试时,我们注意到所有这些订单都产生了确认消息(SendOrderAckToMessageQueue)。确认是一个简单的XML,它基于由船员提供的模式,该模式将订单发送到此业务流程。

然而,并非所有这些都被导入数据库(ImportOrderToDBExpression)(约45)。事实上,没有错误或失败或任何类型的暂停实例。没有进口的订单没有什么不寻常之处。如果它失败了,它就会默默地这样做。

请注意,AcknowledgementScope部分是最近添加的内容;在此之前所有订单都已成功导入。

这是因为我在此业务流程中设置了不正确的范围吗?还有什么问题可以解决?是否有更好的方式以傻瓜式方式发送确认?谢谢你的建议。

2 个答案:

答案 0 :(得分:1)

你没有提到任何Catch Blocks。你的所有范围都有Catch Blocks吗?

如果存在没有Catch Block的Exception或者没有记录Exception的Catch Block,它将显示为静默失败。

答案 1 :(得分:1)

是的,你做错的主要是调用外部DLL将记录插入数据库。

除非编写的DLL具有多线程能力,包括限制并发连接数并具有良好的重试和错误处理能力,否则它可能会遇到错误并无声地失败。

即使您确实在DLL中将错误记录到事件日志中,您也必须为DLL用于写入事件日志的应用程序名称授予权限,否则DLL将在其中失败。 s catch块试图写入事件日志。

您应该做的是使用带有适当适配器的发送端口将记录发送到数据库。

此外,您需要原子范围的情况非常少。使用原子范围,开发人员可以实现任何回滚。此外,您可能不需要长时间运行的范围,除非您希望您的Orchestration花费很长时间,并且在等待响应时应该脱水。

在BizTalk Orchestration收到消息后发送确认没问题,只要你能以某种方式在BizTalk中恢复失败的消息,所以你需要有某种重试机制。