暂停的编排服务实例在恢复后重新抛出相同的意外异常

Question

当我尝试恢复暂停的（可恢复的）编排实例时，我遇到了错误。

场景：请求通过 DB2 静态请求 - 响应端口，由于访问权限被拒绝而失败。我可以看到管理控制台中暂停了两个实例，一个与端口有关，另一个与编排有关。修复凭据后，暂停的端口实例恢复，但编排继续失败。

Uncaught exception (see the 'inner exception' below) has suspended an instance of service 'Orchestration name'.
The service instance will remain suspended until administratively resumed or terminated. 
If resumed the instance will continue from its last persisted state and may re-throw the same unexpected exception.
InstanceId: ca927086-465d-40e8-93fe-c3a0e4c161f7
Shape name: 
ShapeId: 
Exception thrown from: segment -1, progress -1
Inner exception: An error occurred while processing the message, refer to the details section for more information 
Message ID: {96B72521-9833-48EF-BB2F-4A2E2265D697}
Instance ID: {F6FBC912-C9DC-489C-87F3-103FA1273FDC}
Error Description: The user does not have the authority to access the host resource. Check your authentication credentials or contact your system administrator. SQLSTATE: HY000, SQLCODE: -1000


Exception type: XlangSoapException
Source: Microsoft.XLANGs.BizTalk.Engine
Target Site: Void VerifyTransport(Microsoft.XLANGs.Core.Envelope, Int32, Microsoft.XLANGs.Core.Context)
The following is a stack trace that identifies the location where the exception occured
at Microsoft.BizTalk.XLANGs.BTXEngine.BTXPortBase.VerifyTransport(Envelope env, Int32 operationId, Context ctx)
at Microsoft.XLANGs.Core.Subscription.Receive(Segment s, Context ctx, Envelope& env, Boolean topOnly)
at Microsoft.XLANGs.Core.PortBase.GetMessageIdForSubscription(Subscription subscription, Segment currentSegment, Context cxt, Envelope& env, CachedObject location)
at Microsoft.XLANGs.Core.PortBase.GetMessageId(Subscription subscription, Segment currentSegment, Context cxt, Envelope& env, CachedObject location)
at (StopConditions stopOn)
at Microsoft.XLANGs.Core.SegmentScheduler.RunASegment(Segment s, StopConditions stopCond, Exception& exp)

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

任何想法如何解决这个问题？

使用示例创建上述场景：

1. 转到 BizTalk 样本/编排/consumeWebservice 文件夹，安装 ConsumeWebService 应用程序和 将 POWebservice 发布到 IIS。
2. 更改 IIS 目录安全性 POWebservice 的权限，删除 匿名或任何其他访问。
3. 现在删除您将看到的消息 由于 HTTP 暂停消息 状态 401：拒绝访问，然后给 访问 POWebservice 或者 匿名或 Windows。
4. 然后继续 暂停的实例，一个会 消失但是 另一个（编排）一个不会的。

Answer 1

如果我错了，请纠正我，但这不只是正常的 biztalk 行为吗？我不是 100% 确定，所以如果有错误请告诉我：

出站消息传递实例已暂停，因为端口用于连接到数据库的凭据错误。

这导致进行这些调用的编排也暂停。

由于问题已修复，暂停的消息实例已恢复并得到正确处理。所以打电话给数据库。

但是，编排实例可能无法恢复，因为在恢复时它发现自己处于最近的持久性点，并且从发送端口返回的原始错误仍然可供编排使用，导致它重新暂停。

在错误消息中，它实际上表示“如果恢复，实例将从其上次持久状态继续，并可能重新引发相同的意外异常。”

如果您想处理这类事情，您可以对数据库进行原子调用。这样，编排将不会在进行数据库调用时自行保留。如果编排随后暂停，它将在进行数据库调用之前的某个时间点恢复，并将正常进行数据库调用，这一次应该会成功，因为您已经修复了原始问题。

唯一的问题是，如果您的 DB 调用不能多次使用相同的数据执行而不发生坏事（不是幂等的）。

我不是 100% 以上的解释。如果我的理解不正确，请指出。

Answer 2

编排将继续因异常而失败，因为当它被挂起时，最后一个持久点是收到异常。这意味着编排将重新启动（恢复时）并重新引发异常。

这里的文章讨论了将编排状态持久化到数据库的一些要点：http://blogs.msdn.com/b/sanket/archive/2006/11/12/understanding-persistence-points-in-biztalk-orchestration.aspx

您可以在编排设计中在某种程度上操纵这一点，正如 Richard Seroter 讨论的 here，但通常您最好使用 failed message routing，使您能够处理失败的消息，并终止失败的编排实例。

Answer 3

Microsoft Biztalk 未处理此场景 = Middleware FAIL。

您必须在编排设计阶段预先解决这个问题... http://seroter.wordpress.com/2007/01/02/orchestration-handling-of-suspended-messages/