传入消息的自定义确认

Question

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

我们的编排如下：

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部分是最近添加的内容;在此之前所有订单都已成功导入。

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

Answer 1

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

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

Answer 2

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

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

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

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

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

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