问题标签 [workflow-foundation]

我们需要构建几个需要相当高级的工作流功能的应用程序。计划是将数据存储在 SQL Server 中，使用 Windows Workflow Foundation 作为工作流引擎，并使用 Flex 或 Silverlight 等 RIA 技术构建前端。

我们已经设置了 Sharepoint 2007，并且我们中的一些人（包括我）有一些创建自定义 Sharepoint 工作流的经验，这些工作流可以处理 Sharepoint 列表中的数据。

我的问题是，将 Sharepoint 用于工作流程是否有意义，而实际数据存储在 Sharepoint 之外的单独数据库中？我们需要 Sharepoint 的任务、身份验证和电子邮件功能，但是我们的数据模型有点复杂，所以我们宁愿不将数据存储在 Sharepoint 中。我们宁愿不要从头开始使用 Workflow Foundation，因为 Sharepoint 已经为我们提供了我们需要的 90% 的功能。

有什么想法/建议吗？

我需要建议（书籍/链接）来提高我在以下方面的技能 -

1. Web 服务（基于 SOAP 和 REST）
2. Windows Communication Foundation（开箱即用且基于 REST）
3. Windows 工作流基础

我认为自己在 Web 服务方面处于中等水平，在 WCF 和 WF 方面几乎处于中等水平。我想知道一些适合中高级读者的书籍/链接。任何其他平台无关的资源也会很棒。

我正在使用 WorkFlowServiceHost（在 .net 3.5 中）来托管状态机工作流。我使用 WCF 接收活动来处理对工作流的调用。我正在使用 WCF 授权策略根据消息标头中的信息将声明附加到传入请求。因此，在链条的更下方，我可以使用 ServiceSecurityContext 或仅使用 Thread.CurrentPrincipal 来获取有关请求（角色、用户等）的授权信息。

我知道这对我们不起作用，因为工作流正在分派不同的线程来处理运行时引擎在有工作要做时引发的事件（即接收活动）。关于请求的上下文信息（OperationContext）在工作流中不再可用（除了在运行时线程上随机执行工作时）。

我想做的是在创建工作线程之前获取有关请求（OperationContext）的信息，获取工作线程并将上下文信息附加到它，以便它在工作流实例中可用。

我想在运行时必须有一些事件我可以处理来做到这一点，但我没有想出任何东西。而且我真的不想使用手动工作流调度程序。任何帮助表示赞赏。

谢谢！

我在使用 WWF 和外部引发的事件时遇到了 NullReference 问题。WWF 状态机与在状态机中引发事件的服务实例一起工作，以提供数据——当然——改变状态。虽然使用事件“正常”操作可以正常工作，但我遇到了一个奇怪的问题。

为了处理超时场景，我让状态初始化器使用外部超时机制在提到的服务中注册回调。在给定时间之后，回调函数运行并应在状态机中引发超时事件。事件定义如下：

如前所述，如果没有从超时机制中调用，则可以正常工作。ExternalDataEventArgs 是使用有效的 Guid 创建的。引发 Excetion 访问事件中的委托：

任何人的想法？谢谢。

作为我的个人改进计划 (PIP™) 的一部分，我正在尝试学习 Windows Workflow Foundation 的基础知识。

我决定写一个相当简单的博客引擎。我知道那里有很多东西，但这只是一个游乐场项目，我可以用来学习一些很酷的东西。我想要实现的主要功能之一是使用 WF 对博客条目进行审核。该项目的其余部分将是一个 ASP.NET MVC 应用程序，可能会洒上一点 WCF。

根据我对 WF 的了解，我应该使用如下所示的顺序工作流程：

1. 作者添加/编辑博客条目。
2. 条目被发送给版主批准。
3. 版主批准发布 - 或 - 返回第 1 项。供作者更正，以及版主注释。
4. 结束

每个步骤还应通过电子邮件向操作的接收者发送电子邮件。

由于人为交互因素，我猜测 WF 运行时需要在某个地方自行序列化，这样它就不会丢失状态（因为每个活动都可能被 AppPool 重置、服务器崩溃等中断）。

有谁知道实施类似工作流程的任何好例子或地方？

谢谢大家。

我听说Windows Workflow 团队正在为下一个版本重新实现许多现有框架。我的公司有几个项目可能非常适合 Workflow，而且我现在熟悉框架的基础知识，但我担心如果我们现在尝试在 WF 中实现这些，我们最终会当事情本应在不久的将来好转时感到后悔。

我们应该等待工作流的下一个主要版本，还是应该现在开始探索它以更好地做好准备？

为 Workflow Foundation (3.0/3.5) 编写长期运行的自定义活动的最佳实践表明，完全在活动的 Execute 方法中执行长期运行的任务并不是一个好主意。分配给工作流的单个线程将被阻止，从而阻止处理工作流的其他计划请求。

所以对于长时间运行的任务，应该创建一个队列。实际工作将由本地服务（在线程池线程上运行）完成。该服务通过先前的工作流队列将工作结果传递给等待活动。

所以我的问题是，究竟是什么将任务量化为长时间运行？是处理时间的问题吗？什么时候应该创建一个队列，什么时候只使用本地服务就足够了？

感谢您的任何澄清。

我正在使用 Windows 工作流构建一个状态机，并且我正在尝试从我的解决方案中的另一个程序集中新建一个对象。当我构建解决方案时，我从 StateActivityValidator 获得一个 TypeLoadException（它在成功构建后运行以查看所有必需的属性都已设置等）。

我试图创建实例的类型非常简单，它有一个默认的公共构造函数，并且两个程序集都已签名。任何想法可能是什么问题？

我有一个响应列表项更改的状态机工作流程。工作流还会更新列表项；当工作流进行更改时，有什么方法可以避免触发 OnWorkflowItem 更改事件？

我需要在后台运行并进入我的数据库并根据某些逻辑扫描和更新某些行的东西。我需要它像每小时一样运行，我的环境是 Windows Server 2003、SqlServer 2005。

WWF 对这个目的有好处吗？或者我应该创建一个 Windows 服务？而且，WWF 和 Windows 服务之间有什么区别，或者仅仅是做到这一点的最佳方式是什么？

谢谢，雷。