3

我们希望用 WF4 工作流替换我们的大部分业务逻辑。
它们都是非常典型的工作流程：用户操作创建实例、数据库工作、下一个用户确认等。

我们对工作流主机的要求是：

  1. 从存储在数据库中的 XAML 定义创建工作流 (DynamicActivity)
  2. 支持不同版本的工作流
  3. 支持基于长时间的事件（我们目前知道 5 天后通知并在 30 天后回滚工作流）
  4. 支持许多工作流的许多实例（我们已经确定了 10 个工作流，其中大约有 4000 个正在进行中，其中只有少数在任何时候都在处理）
  5. 服务重启后保留所有状态（包括基于时间的事件）
  6. 对调用用户进行身份验证（WindowsAuthentication，如果可能）

作为迁移工作的一部分，我使用“WCF 工作流服务应用程序”项目构建了一些 POC，但据我所知，这些并不是立即可行的。

我知道 #2 是通过 WCF 路由完成的，我的理解是 WSH 将为我们处理 #3（这是真的，给定 #5 吗？），但我看不出 #1 在默认情况下如何工作项目结构。
我已经使用 WorkflowApplication 实例解决了 #1，但这依赖于使用书签来恢复每个输入事件，而且我不相信 WorkflowApplication 会在不卸载空闲工作流的情况下扩展以满足我们的需求，这会破坏延迟活动。

所以，如果你一直坚持我这么远：

  • 有没有办法使用 WSH 来实现所有这些，无论是在默认项目中还是通过我们自己实现其中一些？
  • 考虑到较长的持续时间以及卸载和重新加载工作流的潜在需求，我们是否最好编写自己的“DurableDelay”活动来记录真正的唤醒时间并卸载要由主机进程恢复的工作流？
  • 如果 WSH 不打算这样做，是否有现有的替代方案？

我不反对编写我们自己的主机服务来处理工作流生命周期，我们甚至制定了提议的设计，但如果事实证明有现成的解决方案，我不想开始这条路线.

干杯

4

2 回答 2

1

您可以通过使用 a从数据库而不是文件系统加载工作流来实现#1 。有关这方面的更多信息，VirtualPathProvider请参阅如何使用数据库存储库构建工作流服务。

.NET 4.0 不支持工作流版本控制 ( #2 )，但在 .NET 4.5 中，您可以更好地支持实际版本控制。请参阅Windows Workflow Foundation 4.5 中的新增功能。但是，如果您不需要在工作流启动后更改工作流，而只需要新实例从新版本开始，而已经执行的实例可以使用以前的工作流定义完成，那么您可以在数据库级别实现版本控制并只处理每个工作流定义版本具有不同的工作流服务。

然后，您可以将 IIS ( AppFabric ) 中托管的工作流服务与 SQL Server 实例存储一起使用，几乎免费获得#3、#4和#5 。

最后对于#6，假设您坚持使用 .NET 4.0，您可以查看WF Security Pack CTP 1。

于 2013-02-01T12:18:19.767 回答
0

我正在开发相同类型的工作流程。

我也首先介绍了工作流服务，但由于我们的工作流完全集成在业务层中，我不想使用 WCF 来访问工作流。
所以我现在使用 WorkflowApplication 作为主机，所以我可以实例化和操作主机。
最大的问题是恢复使用延迟活动的工作流程（您需要在数据库中检查自己）

于 2013-02-05T15:42:29.850 回答