WF4 的 WorkflowServiceHost 的替代方案

本文关键字：方案 WorkflowServiceHost WF4 | 更新日期: 2023-09-27 17:56:53

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

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

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

作为迁移工作的一部分，我使用"WCF 工作流服务应用程序"项目构建了一些 POC，但从我所看到的情况来看，这些项目无法立即实现。

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

所以，如果你一直坚持到现在：

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

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

干杯

WF4 的 WorkflowServiceHost 的替代方案

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

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

然后，您可以将 IIS 中托管的工作流服务 （AppFabric） 与 SQL Server 实例存储结合使用，几乎免费获取 #3、#4 和 #5。

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

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

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

相关文章：