Sharepoint工作流程与Windows工作流程

Question

我们正在实施sharepoint应用程序，我们想知道SharePoint工作流程与Windows工作流程的优缺点。

Answer 1

SharePoint中的工作流是使用Windows Workflow Foundation实现的，因此它们并没有那么不同，但是仍然有一些关于该实现的注意事项。

SharePoint是一个Windows Workflow主机，因此如果您同意SharePoint团队的决策，则不必实现自己的主机，这很好：

• 工作流实例保留在内容数据库中
• 与用户的通信是通过SharePoint任务
• 每个工作流程实例都绑定到列表/库项目
• 未实施跟踪

如果这些选择符合您的喜好，那么请务必使用SharePoint工作流程。

如果没有，那就实施自己的主机并做出自己的决定。

Answer 2

他们是一回事。当前的Windows工作流引擎是为SharePoint创建的。

现在需要注意的是，随着.Net 4.0的发布，工作流程引擎将进行大修。我不知道具体细节，但我被告知差异很大。我不认为这将在Sharepoint 2010中使用，但我没有任何相关信息。

以下是描述4.0升级的link。

Answer 3

您尚未指定是在SharePoint中构建自定义编码的应用程序，还是通过浏览器配置现成的解决方案。无论哪种方式，这里有一些SharePoint工作流的选项。

1. 使用SharePoint中内置的本机工作流，并可从任何列表轻松访问。它们非常基本（通常只有一步或两步的简单批准），但它们可以让您快速启动并运行，并且可以通过浏览器完成。
2. 使用SharePoint Designer构建稍微复杂的工作流程。这将使您可以访问条件逻辑（即基于列表值路由工作流）和无限步骤，以及允许您在流程中引入更多逻辑的许多其他功能。缺点是你必须使用SharePoint Designer，坦率地说，这可能是一个真正的痛苦。
3. 在WF中自定义您的工作流程代码。 Windows Workflow是前两个选项的基础，这两个选项基本上是基础框架之上的抽象。这种方法的主要区别在于您不仅限于浏览器或SPD表面的功能。缺点是这将成为一个更复杂的过程（尽管工作流程可能会更加复杂），您必须经历针对SharePoint，打包部署，发布等的编码工作。

我发现在开发的简易性方面达到了最佳平衡，功能是按照我提供的顺序尝试按上面的列表工作，如果你肯定无法用当前的功能实现这个要求，那么只能进入下一个选项。点。

Answer 4

它基本上是相同的技术。如果您知道一个，您可以轻松使用/切换到另一个。

将SharePoint dll添加到解决方案后，您将获得可在工作流中使用的某些特定SharePoint“活动”。 （创建任务，......）

您的SharePoint Server将充当您的工作流程的主机。

在SharePoint中部署工作流的最佳方法是使用SharePoint功能。这告诉SharePoint要使用的dll（程序集）和要显示的（输入）页面。

作为输入页面，您可以使用简单的.net aspx页面或infopath表单。两者都需要一些试验和错误才能掌握它。

Answer 5

SharePoint只使用Windows工作流基础（WF）作为其工作流引擎。 WF本身只是一个通用的工作流引擎。

为了使用WF，您必须实现主机进程以执行工作流，并对其进行配置以便将实例持久化到数据库等（现在大多数人将WCF服务用作工作流主机，请参阅here或here）。

SharePoint附带已配置的所有内容并实现自己的工作流主机，因此您可以开始使用工作流程。除此之外，它还提供自定义活动和SharePoint特有的其他好东西。

Answer 6

如其他答案中所述，它们是相同的，因为它们使用Windows WOrkflow Foundation。话虽如此，当涉及到通过SharePOint Designer创建的工作流程时，要记住一件重要的事情：它们不是“便携式”开箱即用的，这意味着您可以创建一个绑定列表a，然后将列表保存为一个模板，然后基于该模板创建另一个列表，工作流将无法工作（您已重新绑定它，因为它仍然引用原始列表的ID（guid）。