2

我在 IIS 中托管工作流服务 (xamlx)。它有一些接收活动，例如 MethodA 和 MethodB。我编写了一个 MVC 应用程序作为客户端来调用这些方法。在 PageA 中，用户提交表单会调用 MethodA，工作流会转到等待 MethodB 的 Receive Activity。然后在Page B，用户提交表单会调用MethodB。但是，如果用户在 PageA 中提交，然后返回到 PageA 并再次提交相同的工作流实例，它将等待一分钟并给出超时异常：

00:01:00 后等待回复时请求通道超时。增加传递给 Request 调用的超时值或增加 Binding 上的 SendTimeout 值。分配给此操作的时间可能是较长超时的一部分。

这个错误似乎来自 WCF，而我想它会给出以下错误：

InstancePersistenceCommand 的执行被中断，因为实例键“guid”未与实例关联。这可能是因为实例或密钥已被清理，或者因为密钥无效。如果生成密钥的消息在错误的时间发送或包含不正确的相关数据，则密钥可能无效。

我有几个问题：

  1. 有没有我们可以设置的配置，以便可以捕获另一个异常，而不是等待一段时间直到可以捕获超时异常？我知道我们可以在绑定标签中设置一个较小的超时值，但这不应该是一个解决方案。

  2. 当工作流实例未处于正确状态时，是否有任何方法可以避免显示 PageA？（即使这样做了，我们还需要解决问题1，因为用户可以打开PageA并在提交前空闲一段时间）

谢谢。

4

2 回答 2

3

回复：超时异常。

这是 WF4 中的一个已知错误。这是 WF/WCF 基础结构将尝试传递消息这一事实的结果。这意味着它将在消息上挂起一段时间，然后查看工作流是否进入可以处理消息的状态。基础架构并不真正了解您的工作流程的结构。因此，即使您完全意识到工作流处于一种状态，即在给定当前状态的情况下，基础设施将等待它永远无法处理消息。

回复：避免显示 PageA。

这实际上取决于 UI 层并且超出了工作流的范围。正如您指出的那样，并非完全可以避免。但是，我在持久存储中使用书签信息取得了很好的成功。每个接收活动都会创建一个具有已知名称的书签，我基本上检查了那里的书签。基于此信息，我将启用/禁用部分 UI。它并不能真正解决用户打开页面并将其保留 15 分钟的问题，因此在调用服务方法时仍然需要一个错误处理程序。对此进行改进的一种方法是，暂时假设一个基于 HTML 的 UI，使用 WebSockets 或SignalR为了更实用，将工作流状态更改从服务器推送到客户端。仍然不会消除错误处理的需要，但应该使 UI 处于错误状态的窗口更小。

于 2013-02-07T04:46:04.440 回答
0

由于我遇到了类似的问题，我想提供一些关于Maurice's answer的超时部分的背景知识。

该信息来自 Jim Carley 在此 Microsoft 论坛主题上的一篇帖子。不幸的是，不支持直接链接到帖子——搜索“协议书签”。我将在这里总结重要的部分。

背景

  • 并非所有书签都是一样的。接收活动创建的那些（“协议书签”）与“非协议”书签的处理方式不同。
  • Pick 活动在内部创建一个非协议书签以在触发器完成时恢复。

  • 当接收到操作的消息并且没有该操作的协议书签时，工作流基础结构会检查是否有工作流实例的任何未完成的非协议书签。

    • 如果有，则基础结构会挂起消息，并且可能会发生超时。
    • 否则消息会立即被拒绝。

底线

以下活动都创建内部书签，因此在与接收活动和乱序消息混合时可能导致超时问题：

  • 挑选
  • 状态
  • CompensableActivity（以及相关的 CompensationExtension）
  • 确认
  • 延迟

对于 Pick，一个潜在的解决方法是使用 Parallel 并将 CompletionCondition 设置为true。

于 2015-04-20T14:59:51.747 回答