问题标签 [workflow-foundation]

标题不是很准确。我目前正在开发一个允许多人输入数据的网站。我需要/想要使用 WFF，因为人们会按一定的顺序输入数据。这是一个客户投诉表。销售人员将填写初始表格并提交投诉。投诉将被审查并驳回或转至调查部分。最后，投诉将被处理并关闭。

我的困境是我也在实施 Sharepoint。这两个项目大约在同一时间到期。最终，Sharepoint 将成为我们唯一的网站，投诉项目也转移到了 Sharepoint。

我宁愿等到 Sharepoint 到位后再进行客户投诉项目。我们将不得不从一开始就重新安排 Sharepoint 项目以包含工作流，而不是稍后再实施。

有任何想法、建议、意见吗？

如果我有，WorkflowInstance我可以连续执行两次吗？

当我这样做时，我得到一个异常告诉我我没有配置持久性服务。但是我的问题是：在我执行WorkflowInstance一次之后，可以再次运行一个实例，还是它变得不可用？每次我想执行时都必须创建另一个实例吗？

我创建了一个小型 VS 解决方案，其中包括带有 WCF ReceiveActivity 项目的 WF（使用 basicHttpBinding）和一些普通的 C# 服务。当使用 WCFTestClient 从 VS 2008 进行测试时，它们都可以正常工作。

我将它们部署到单个 Windows 服务中。除 WF 服务外，其他所有服务都可以正常工作。我花了 6 个小时浏览，但没有找到有效的解决方案。请帮忙。

我有两个编译良好的工作流基础（.NET 3.5 SP 1）应用程序。它有两个声明性规则条件。两者都很简单，例子：
- !this.Shutdown - this.Runtime == null

该项目可以正确构建，没有错误或警告，但是当我运行应用程序时，它会失败并出现以下异常：error 1342: Activity 'whileNotShutdown' validation failed: Can not find the condition "Shutdown not requested".

在另一个应用程序中，我在策略中使用了一个更复杂的规则集，它会生成以下异常：error 1398: Activity 'Defaults' validation failed: Can not find the rule set "Rule Set1". Check if rule set is defined in the rules file.

我尝试删除 .rules 文件并通过重新创建这两个规则来重新创建它，但这并没有帮助。

问题是：导致此错误的原因是什么？

我尝试过的一些事情：

• 将工作流规则放在更大的工作流中对问题没有影响。
• 这个问题现在影响了解决方案中的所有工作流程（甚至那些曾经工作的工作流程）。
• 使用代码规则条件没有相同的问题 - 问题与规则文件有关。
• 重建工作流程没有帮助

我正在使用 WF，并且需要支持事务和持久性。我不想使用 TransactionScopeActvity ，而是使用我自己的事务范围对象，并且最后仍然有一个持久点，它将成为活动本身的事务的一部分（类似于 TransactionScopeActvity 在这方面的工作方式）。我可以通过使用“PersistOnClose”属性在事务结束时实现持久化点，但是持久化调用属于哪个事务呢？它会打开一个新事务，还是寻找环境事务？当持久性点被激活时，如何确保环境事务存在？

与滚动您自己的工作流框架相比，使用 Windows Workflow Foundation (WF) 有什么好处？

据我所知，WF 只提供了一个非常简单的运行时引擎、一堆类和一个用于定义工作流的架构（基于 XAML）。所有困难的事情，例如持久性、为运行时提供主机进程以及实现分布式工作流（跨进程）都由您决定。

此外，使用 WF 有一个学习曲线……如果我们创建自己的工作流框架，我们将简单地利用所有开发人员已经拥有的技能（C#、XML、SQL 等）。

我从一位 MS 布道者那里看到了这个博客，它试图解释为什么我们应该使用 WF：

为什么是工作流？...

IMO 在说服方面做得不好，因为它只是说它有助于“开发人员的生产力”，同时承认开发人员可以自己动手。

这里的任何聪明人能想出一个更好的理由吗？

下面给出的答案摘要：

我认为最有说服力的原因是，使用标准化的工作流平台（例如 WF（而不是滚动您自己的））将使您能够利用 MS 和第三方提供的 Visual Designer 等当前和未来的工具。

此外，由于它是基于 .NET 技术的 MS 堆栈的一部分，因此它可能会与未来的 MS 技术（例如 Azure）有更好的集成/迁移路径。

最后，拥有 WF 经验的开发人员数量将会增加（因为这将使他们的职业生涯受益），将其转变为 SQL 或 HTML 等基本商品技能，这意味着将更容易找到可以开始使用它的人最小的加速时间。

我正在阅读.NET 3.5 中的 Pro WF Windows Workflow一书，第 5 页显示他们在 Visual Studio 2008 中打开了一个新项目，选择了“Visual C#/Workflow”并显示了 8 个模板：

• 空工作流项目
• 顺序工作流库
• SharePoint 2007 状态机...
• 状态机工作流库
• 顺序工作流控制台应用程序
• SharePoint 2007 顺序工作流
• 状态机工作流控制台应用程序
• 工作流活动库

然而，在我的（德语）Visual Studio 2008 中，即使在安装 SP1 之后，在工作流下我也只有：

• Sequenzieller SharePoint 2007-工作流
• SharePoint 2007 - 状态计算机工作流

在 WCF 下我发现：

• 顺序工作流服务库
• 状态机工作流服务库

但是如何获得书中提到的 Visual Studio 2008 工作流模板呢？

我有一个带有属性的工作流，声明如下：

Person 是一个具有它自己的属性（如 Person.Name）的类，并且使用 WF 我可以很好地绑定到 userAccount 属性，但我似乎无法绑定到 userAccount.Name。

是否有可能做到这一点？如果是这样，我需要改变什么？

嗨，我想知道你们中有多少人在生产环境中使用过 Workflow，这是个好主意吗？我的意思是我们可以使用 DB 和调度程序服务创建相同的东西

我刚开始与 WF 合作，我发现真正烦人的是你必须说出很多东西。IMO，程序员每天处理的最困难的事情之一就是为事物构造好名字，而 WF 似乎将这一点发挥到了极致。

以 WF IfElse 活动为例。如果我用原始 C# 编码（不使用 WF），它看起来像这样：

现在上面的 C# 代码简单明了。相反，如果我要定义一个使用 IfElse 活动执行相同操作的 Windows 工作流，首先我必须命名每个 if 块：例如

• ifXEquals0
• ifXLessThan10
• ifXLessThan100

最重要的是，我必须在每个 if 语句中命名每个条件：例如

• x等于0
• x小于10
• x小于100

这不仅乏味，而且难以维护（例如，如果条件改变）并且容易出错（当条件改变时您忘记更改名称）。

问题（据我所知）是 WF 将每个编程构造分解为需要名称的工作流属性。

现在，由于我仍在学习 WF，而且我不想听起来像是什么都知道……我想问你们。难道我做错了什么？在创建 WF 工作流程时，有没有办法避免这种名称问题？这是 Windows WF 特有的问题，还是其他工作流引擎也有同样的问题？