使用 Windows Workflow Foundation 规则引擎提高 SharePoint 2010 工作流的灵活性
使用 Windows Workflow Foundation 规则引擎提高 SharePoint 2010 工作流的灵活性
SharePoint 2010
摘要：了解 Windows Workflow Foundation 规则引擎的功能和优点，这些功能和优点可以帮助您自动执行 Microsoft SharePoint 2010 应用程序中的工作流的业务逻辑和流程。了解如何以及何时对简单或更复杂的 SharePoint 工作流方案使用规则引擎。
上次修改时间：
适用范围：
Business Connectivity Services | Open XML | SharePoint Designer 2010 | SharePoint Foundation 2010 | SharePoint Online | SharePoint Server 2010 | Visual Studio
工作流是强制执行业务流程的应用程序，其中包含一系列活动和连接这些活动的控制结构。应用程序需要通过某种方法从一种活动切换到另一种活动，直到流程完成。但是由于这些流程的组成部分经常会发生变化，而工作流的核心逻辑保持不变，因此情况会变得很复杂。例如，需要不同审批级别的阈值和呈报任务的时间范围就属于可能会随着业务需求的变化而变化的条件。但是，支持这些条件的逻辑通常保持不变，即仍需要执行审批并且仍需要呈报并完成任务。在这种情况下，业务规则引擎可以提供一个既支持"不断变化的组成部分"又支持核心业务逻辑的框架。在尝试了解规则引擎及其工作原理之前，必须了解此工具解决的问题，这一点很重要。
从本节的标题可以看出，目标是拆分工作流项目，以便将业务逻辑与控制工作流处理的逻辑分离。换句话说，创建和更新任务、处理列表项目和文档以及执行其他任务的代码不应该与描述业务信息的代码或标记混在一起。确定特定项目需要哪些用户的审批以及用户所拥有的文档审阅时间等信息应该与基础业务逻辑分离。示例 1 包含两个方案，这两个应用场景用于说明从维护的角度看，分离和控制业务逻辑与处理逻辑为什么很重要。
假设您正在编写用于传送文档以供审批的工作流。业务要求中指出，如果任何特定审阅者在 5 天内未执行分配的审阅任务，则应将文档视为未经批准，并且应该按照文档已被主动拒绝的情况相应地继续执行流程的剩余部分。在业务要求与往常相同的情况下，很可能在部署此自定义工作流后不久，有人发现五天的时间对于审阅期来说不够长，并且发现审阅者未执行操作已经导致"间接否决"发生，从而意识到审批者应该至少有两周时间来审阅和签署他们的任务。可能会碰巧发生这种情况：周五下午较晚的时候意识到了这一点，并且必须在周一早晨之前实施更改。而且，必须对当前正在运行的所有工作流实例实施这一更改。
您更喜欢哪种方案？
方案 1：从版本控制系统签出源代码，检查所有代码以查找对五天审阅期进行硬编码的位置（可能存在多个位置），然后进行更改，对流程执行一系列测试、重新打包和重新部署，并寄希望于即将开始的新工作流或正在进行的任何实例都不会出错。
方案 2：通过自定义客户端应用程序更改单个 XML 文件，并将它保存回服务器。
答案是显而易见的。
您可以通过多种方式处理这类情况，例如使用 Web 服务、数据库条目或简单的平面文件。但是，您必须意识到这只是一个简单的示例，对简单的阈值使用规则引擎会使复杂程度增加，这是完全不必要的。但是，设想一下更复杂的情况，如示例 2 中所述的情况。
假设您具有相同的文档审批流程，该流程同样存在"间接否决"（由于审阅者未及时响应）的可能性，但现在工作流程包含如下一些其他要求：
如果错过审阅时间范围的人员是主管或更高层的员工，则不会自动拒绝文档，而是将任务分配给他们的行政助理，行政助理现在具有新的阈值时间段来审批文档。
审批时间范围根据基本值进行调整，并且根据文档的优先级增加或减少。
如果文档创作者是副总裁或副总裁的行政助理，则删除间接否决选项，在这种情况下，一系列呈报时间范围将生效。
如果文档被标识为具有特定敏感度级别，则不论任何其他因素如何设置，都绝对不会在行政助理的任务中显示任何揭示文档内容的信息。只是告诉他们必须提醒上级主管人员审阅文档。
在这个更复杂的方案中，一些其他因素发挥了作用 — 多个长度可变且具有唯一阈值的审阅期、优先于其他规则的规则、导致重新计算其他规则的规则、导致其他规则发生变化的规则，以及其他因素。
使用对第一个示例有效的任何选项来实现第二个示例的难度大大增加。自定义数据库和 Web 服务可能仍然起作用，但会更加难以实现。同时，您必须管理的选项数也大大增加，这就使事情变得更加复杂。此外，如果您需要与第二个示例大致相同、仅在一两个方面不同的新工作流，则必须重现大量相同的逻辑并维护两个副本，或者必须生成一个可以处理这两个工作流（甚至第三个、第四个、第五个等）的通用应用程序。
示例 2 中所描述的情况说明了为什么需要"规则引擎"。
最简单地说，规则是生成 Boolean 值的逻辑片段，可用于将工作流程分流到多个可能路径中的任何一个。在这一层面上，规则实际上没有什么特别之处。此类规则通常称为条件，它们类似于示例 1 中所讨论的简单阈值。
规则可在多个活动中用作条件，例如：
IfElseBranch
有条件的 ActivityGroup
Replicator
在上述每种情况下，条件只是一种 Boolean 计算。包含条件的特定活动会根据条件计算的结果产生不同的行为。在最简单的 IfElseBranch 情况下，如果条件为 true，则分支执行其子活动；如果条件为 false，则分支不执行任何操作。其他活动以相似的方式发挥作用。
您可以通过以下两种方式之一实现条件：作为代码条件或作为声明性条件。很明显，使用代码条件需要在自定义程序集中编写得出条件的 Boolean 值需要执行的代码。声明性条件使用内置在 Microsoft Visual Studio 的工作流扩展中的条件编辑器（如图 1 所示）。示例 3 中显示了示例声明性条件。虽然仍在条件编辑器中编写代码，但是此代码通常只实现简单的比较，因此不像编写自定义代码那样复杂。
图 1. 条件编辑器
以下是简单条件的示例：
this.po_amount & 1000 and reviewer.role & userrole.director
privacy_level == "restricted"
document_owner.division = Divisions.Finance
date_now & required_approval_date
通过在代码中实现条件，您可以十分灵活地执行您必须执行的操作。可以在 Microsoft .NET Framework 中执行的任何操作均可以在代码条件中完成，以得出所需的 Boolean 结果。您可以与数据库、Web 服务、自定义对象、复杂计算等进行交互。对于声明性条件，可用选项仅在一定程度上受可行性限制。您仍需要编写代码，并且代码可以执行完整的代码条件可以执行的大多数操作。但是，如果不只是执行简单的比较，一开始就使用代码条件可能是更好的选择。
根据到目前为止我所介绍的内容，您可能对规则的实用性产生了质疑。它们似乎只会增加复杂性，而没有提供多大价值。但是，它们确实很有用处。若要了解原因，您必须了解两个概念：Policy 活动和 RuleSet。
Policy 活动是 Windows Workflow Foundation 中附带的一个内置工具，因此可用于 SharePoint 工作流。策略是协同工作以定义业务要求的相关规则的集合。Policy 活动的作用是：它将定义和执行方法封装为一组规则 — 称为 RuleSet。（有关更多详细信息，请参阅下一节 。）
我在前面讨论的条件充当一种 Boolean 标志，以确定工作流程如何继续或是否继续。它们是 if-then-else 语句的 if 部分。对于前面的示例，这已经足够；活动会处理其余工作。对于其他方案，您需要完成更多操作，而 Policy 活动会完成这些操作。通过 Policy 活动，您可以在末尾追加 then-else 部分以完善功能。当您需要执行更多操作时，则可以这样做。Policy 活动的作用是管理 RuleSet 中规则的创建和执行。
Policy 活动本身很简单。它只包含一个您应该注意的重要属性：RuleSetReference。（其他属性是 Name、Description 和 Enabled，所有这些都相对比较容易理解。）顾名思义，RuleSetReference 属性包含对此 Policy 活动在运行时所执行的 RuleSet 的引用。它还提供对用于管理该 RuleSet 的用户界面的访问，可以通过用户界面充分发挥规则引擎的强大功能。
RuleSet 是具有一组执行语义的规则集合。它包括以下几项：
一个或多个条件
条件的计算结果为 true 时要执行的零个或多个操作
条件的计算结果为 false 时要执行的零个或多个操作
用于控制规则执行情况的元数据，例如：
重新计算条件
以下各节更详细地阐释各个规则及其语义，最后介绍由 Microsoft 提供的规则集编辑器应用程序。
当条件的计算结果为 true 或 false 时规则可以执行的操作。它们是规则的 then 和 else 部分，并且可以包含逻辑所需的任何内容（调用 Web 服务、使用自定义对象、设置字段值等）。操作可以是您可以在 .NET Framework 中对其编写代码的任何对象，但是您应考虑如下几个重要问题：
此操作在工作流中引用的对象。
自定义对象的字段或方法必须是静态的，因为无法实例化实例。
不能直接实例化对象。但是，可以编写具有静态方法的自定义对象，该自定义对象实例化和处理其他对象。
除了上述这些注意事项之外，您可以在操作中执行任何所需的任务。查看规则集编辑器时，您将会看到操作界面的外观。
本示例显示一些示例 Actions，它们位于 RuleSet 的 then 和 else 部分。
this.SomeVariable = SomeValue
myObject.myStaticMethod()
myObject.SomeStaticField=this.workflowProperties.List.Title
名称是为每个规则指定的标识。
优先级使您能够控制 Policy 运行时执行规则的顺序。规则根据优先级顺序按降序执行，因此优先级为 5 的规则先于优先级为 4 的规则进行计算，优先级为 2 的规则先于优先级为 1 的规则进行计算，依此类推。默认状态下，所有规则都从优先级 0 开始。若要强制某条规则最后执行而不更改每个其他规则的优先级，则可以指定负优先级。
活动标志是一个 Boolean 值，它指示特定规则是否处于活动状态。这使您可以将规则保留在 RuleSet 中，但禁止它们执行。
重新计算条件是一个值，从表面上看没有什么特殊之处，但却具有深远的影响。只有两个选项：Always 和 Never。默认值为 Always。要完全了解此设置的结果，必须了解链接，链接将在下文中介绍。现在，请注意以下几点：
Always意味着当规则引擎确定必须重新计算 RuleSet 中的某个特定规则时，它将重新计算。
Never 意味着即使规则引擎确定应该重新计算 RuleSet 中的某个特定规则，它也不会重新计算。一定要注意，仅当规则执行非空的 then 或 else 操作时，才认为已计算规则。此外，此设置仅用于控制重新计算，它对初始计算没有任何影响。若要禁止执行初始计算，必须使用前面讨论的 Active 标志。
在下文的一节中讨论"链接"时，您将看到操作中的重新评估条件。但首先，您必须了解如何标识规则之间的依赖关系，因为触发重新计算的正是这些依赖关系。
当一个规则所做的更改影响另一个规则的计算结果时，即表示这两个规则之间存在依赖关系。示例 5 中显示了最简单的依赖关系。
以下示例显示简单的规则依赖关系。
规则 1：if x=5 then y=7
规则 2：if y=3 then z=4
规则 2 依赖于规则 1，因为如果规则 1 执行其 then 操作，则会更新变量 y，而规则 2 的条件中使用了该变量。
稍后您将看到，依赖关系可能会变得更加复杂。有三种标识依赖关系的方法：Implicit、Attribute-Based 和 Explicit。
虽然没有对示例 5 进行此类标注，但它确实使用了隐式模型来标识依赖关系。规则引擎遍历 RuleSet 并查找以下类型的方案：一个规则直接影响另一规则的条件计算结果。这是默认行为。
仅当规则调用自定义方法时，基于特性的依赖关系才有用。使用自定义对象通常会使相互依赖关系变得混乱，规则引擎可能无法标识依赖关系。为了解决此问题，开发人员可以使用三个特性来修饰他们的方法，以提供规则引擎所需的信息，这些特性如下所示：
RuleRead("PropertyName") 使用此特性修饰的方法将读取指定的属性值。
RuleWrite("PropertyName") 使用此特性修饰的方法将更新指定的属性值。
RuleInvoke("MethodName") 使用此特性修饰的方法将调用另一方法，另一方法必须使用 RuleRead 特性或 RuleWrite 特性修饰。
示例 6 演示上述每个特性。
读取属性值的方法使用 RuleRead 特性修饰，如以下代码示例所示。
[RuleRead("ApproverRole")]
public UserRole GetApproverRole(string UserName)
// Do some processing here to determine the role of the user, based
// upon the ApproverRole property.
更新属性的方法使用 RuleWrite 特性修饰，如以下代码示例所示。
[RuleWrite("ApprovalThreshold")]
public void SetApprovalThreshold(int BaseDays, UserRole Role)
// Do some processing here to calculate the number of days users
// have to complete tasks based on their role in the organization
// and update the ApprovalThreshold property.
不直接与属性交互的方法仍可以使用 RuleInvoke 特性修饰，以指示它调用与属性交互的另一方法。
[RuleInvoke("SetApprovalThreshold")]
[RuleInvoke("GetApproverRole")]
Public void CalculateAndAssignThresholdBasedOnRole(string UserName)
UserRole Role = GetApproverRole(UserName);
// Calculate BaseDays here.
SetApprovalThreshold(BaseDays, Role);
请注意，上面的代码示例中使用了多个特性。另请注意，RuleInvoke 特性的目标方法使用 RuleRead 特性或 RuleWrite 特性修饰。关于标识依赖关系，最后请注意如下几点：可以使用星号 (*) 指定从对象中读取或写入对象的所有字段。例如，[RuleRead("ApproverRole/*")] 表示读取拥有 ApproverRole 字段的对象上的所有字段。相同的方法可用于 RuleWrite 属性。 如果不指定特性，则认为对方法的调用将读取目标对象的所有属性和字段，但不写入任何属性和字段。传递给方法的任何参数都被认为是读取，仅 out 或 ref 参数被认为是写入。
在您不具有所调用方法的源代码时，或者您无法更改所调用方法的源代码以使用适当的特性修饰目标方法时，Explicit 特性非常有用。这种依赖关系标识通过在规则集编辑器中使用 Update 语句直接添加到您的规则中，如示例 7 所示。在某些情况下，它还可用于必须显式标识依赖关系的任何方法调用。
本示例演示如何使用 Update() 语句来显式标识依赖关系。
If x & 7 then SomeExternalMethodThatUpdatesY()
"链接"使您能够将工作流链接在一起，也就是从另一个工作流的活动中调用一个全新的工作流。链接基于已识别的规则依赖关系；更具体地讲，链接基于一个规则的操作与其他规则的条件之间的依赖关系。链接是使问题开始变复杂的根本原因。这个概念本身相当简单：规则之间可能存在关系，在这些关系中，一个规则的 then 或 else 语句执行的某些操作（如设置变量）可能会导致重新计算另一依赖规则的条件。遗憾的是，情况通常不会这么简单。这些依赖关系使用前面介绍的方法进行标识，其中包括隐式、显式或基于特性的依赖关系。
链接使您能够基于以下几项控制重新计算规则的方式：
其他规则所做的更改
规则引擎标识的依赖关系（根据特定指令）
为整个 RuleSet 设置的重新计算条件
下面是三个链接设置选项：
Full 双向追踪所有依赖关系，并根据需要重新计算规则。
Explicit Update Only 仅使用特定 Update 语句标识的依赖关系有效。
Sequential 链接处于关闭状态。规则仅根据优先级按降序执行一次，不重新计算规则。
Full 是这些选项中最复杂的一个。Full 可能会导致一个相互关联的、非常复杂的规则网。在复杂的完全链接环境中，出现循环引用的可能性非常高。示例 8 提供了一个简单的通用方法，帮助您理解此概念。示例 8 之后是一个实际示例，说明链接的强大功能和潜在的复杂程度。
下面是简单链接的示例。
规则 1（优先级：3，重新计算=总是）：If x=2 then x=5
规则 2（优先级：2，重新计算=总是）：If y=3 then z=7 and x=2 else z=4
规则 3（优先级：1，重新计算=总是）：If z=4 then y=3
此 RuleSet 中存在两个依赖关系。每个依赖关系都很明显，如下所示：
规则 3 依赖于规则 2，因为规则 3 中的条件基于 z 的值，该值在规则 2 的 else 操作中设置。
规则 2 依赖于规则 3，因为规则 2 的条件基于 y 的值，该值在规则 3 的 then 操作中设置。
假定 RuleSet 的链接设置为 Full，并且开始时使用以下初始值：
现在，逐个执行规则，将出现以下情况：
规则 1 首先执行，因为它具有最高优先级。由于其条件的计算结果为 false (x != 2)，因此其 then 操作永远不会执行，因此不会发生任何更改。
接下来执行规则 2（优先级 2）。同样，由于其条件的计算结果为 false，因此其 then 操作不会执行。但是，其 else 操作会执行，因此 z 的值更改为 4。
规则 3 最后执行。其条件的计算结果为 true (z = 4)，因此其 then 操作将执行，并将 y 更改为 3。
如果链接设置为 Full 之外的其他任何值，则执行过程将在此处停止。但是，因为链接设置为 Full 并且重新计算设置为 Always，所以将重新计算规则 2。
这次，规则 2 的条件的计算结果为 true，因此 z 设置为 7 并且 x 设置为 2。
这会对规则 1 和规则 3 触发更多的重新计算。首先重新计算规则 1，因为它具有更高优先级。
规则 1 的条件的计算结果为 true，因此 x 更改为值 5。
规则 3 现在重新计算。其条件的计算结果为 false，因此不会执行任何操作，并且 RuleSet 结束。
最后您将得出以下值：
尽管前面的示例相当简单，但它确实能够说明问题。遗憾的是，在实际业务规则中您绝不会处理简单的整数值。您需要处理人员、时间范围和职责。办公室政治可能会发挥作用，这总是会使事情更加复杂。此外，因为人员的流动性，您通常必须处理角色而不是个人。
示例 9 在一定程度上说明了这种复杂性。该示例对变量的使用做出了一些假设以便简化示例，所以不要考虑其中一些的支持细节，只需关注业务逻辑。此外，该示例使用伪代码编写，以便目标明确、重点突出地说明问题。在该示例中，使用了一个 RuleSet 来确定在工作流的一个阶段一个审阅者拥有的批准或拒绝文档的天数。
下面是实际链接的示例。
规则 1（优先级：4，重新计算=从不）：If 1=1 then BaseReviewCycleDays=5
规则 2（优先级：3，重新计算=总是）：If DocumentPriority=High then ReviewCycleDays=BaseReviewCycleDays - 2 else ReviewCycleDays=BaseReviewCycleDays
规则 3（优先级：2，重新计算=从不）：If Reviewer & RegularReviewer then ReviewCycleDays += 3
规则 4（优先级：1，重新计算=总是）：If DocumentAuthor & Director then DocumentPriority=High
规则 5（优先级：-1，重新计算=从不）：If Approver.IsExecutive and ReviewCycleDays & 5 then ReviewCycleDays = 5 and Halt
本节并不逐步演练该示例，但如果您有兴趣，则可以完成该示例。简单地说，如果文档标记为常规优先级且由副总裁创作，并且审阅者不是主管人员，那么结果是审阅者有三天的时间来审阅文档。如果将审阅者更改为主管人员并将作者更改为非主管人员，则会将审阅周期延长至八天。
关于此示例的一项说明：请注意，在规则 5 的末尾使用了 Halt 一词。这是一条指令，告诉规则引擎停止处理 RuleSet 并立即返回工作流，所有值均保持当前状态。它不是一个错误条件，而是缩短规则处理周期的一种方式（如果必须这样做）。在此示例中，它确保在计算规则 5 后不重新计算任何条件。
尽管此示例比第一个链接示例更符合实际情况，并且在某些方面更复杂，但它仍非常易于理解。手动为它编写代码相对简单。但是，请记住这只是单个工作流中一个步骤的一部分。该部分仅确定一个审阅者有多长时间来对文档执行操作。如果将此活动扩展到五、六个审阅者，并添加一组完全不同的假设和条件，您就可以了解工作流活动和要求可能有多复杂。
现在，假设您需要更改一些逻辑。理想的状况是业务逻辑已与工作流逻辑的其余部分分离，并且可以在单独的应用程序（通过仅向您显示维护业务规则需要了解的信息来简化任务的一种应用程序）中维护。这就是规则引擎的优点。
在结束链接的讨论之前，最后提醒您：一定要避免循环引用。出现这种情况的可能性很高。事实上，几乎可以肯定地说，在某种情况下您将导致规则之间出现循环引用，从而锁定您的流程。在部署到生产环境之前，请通过对 RuleSets 的各个元素应用各种值或值组合来测试您的解决方案。
现在，您已经对规则有了全面的了解，通过学习 Microsoft 提供的用于编辑 RuleSet 的应用程序（图 2 所示的规则集编辑器）可以将这些知识融会贯通。
图 2. 用于生成和维护规则和元数据的规则集编辑器应用程序
规则集编辑器应用程序提供一个允许您生成规则和维护 RuleSet 元数据的界面。关于此应用程序，要了解的一个重要事项是：通过
类，它可在自定义 Windows 应用程序中使用。因为规则集编辑器是作为一个标准 Windows 对话框实现的，所以就像使用"保存"和"打开"对话框一样，您可以轻松地在自定义应用程序中重新装载它。
遗憾的是，规则集编辑器仅适用于 Windows 应用程序；不能用于 Web 应用程序。
这会带来严重问题。毕竟，SharePoint 是一个 Web 应用程序，并且您正尝试从该 Web 应用程序中使用规则引擎。遗憾的是，这意味着从这一点来讲您无法彻底实现您的目标。不过，您可以通过在现有工作的基础上做一些额外的工作来努力实现您的目标。下面是您已经完成的工作：
将业务逻辑与工作流处理逻辑分离
了解如何使用规则引擎作为一种工具来管理您的业务逻辑
您可能无法做到的是，像前面示例 1 的方案 2 中提到的那样简单地完成维护任务：维护规则不像编辑 XML 文件并将文件保存回服务器那样简单。
但是，通过一些额外的工作，您可以简化维护任务。尽管有关如何构建完整解决方案的详细讨论不在本文的范围之内，但是本文的最后一节将重点介绍成功构建解决方案所需的步骤。
必须理解如何存储 RuleSets 以便它们可供 Policy 活动使用。如果将规则添加到 RuleSet 时注意一下 Visual Studio 中的"解决方案资源管理器"窗口，您可能会发现添加了 .rules 文件。该文件维护有关规则的信息，它是示例 1 的方案 2 中提到的 XML 文件。规则更改时，必须更改该文件。.rules 文件是 RuleSet 的序列化表示形式。此处没有提供 .rules 文件的示例，因为根本没有"短".rules 文件这回事。即使最简单的规则 if 1==1 then this.someVariable = 5，也包含大约 50 行 XML。
幸运的是，通过前面讨论的规则集编辑器应用程序，可以轻松创建和编辑 .rules 文件。如上所述，规则集编辑器是作为标准对话框实现的。单击"确定"时，您创建的 RuleSet 将会在 RuleSetDialog 类的 RuleSet 属性中提供。将此内容转换为文件的过程只是简单的序列化操作。唯一的技巧是使用
类而不是标准 XML 序列化类。
默认情况下，在编译工作流时，.rules 文件存储为资源，如图 3 所示。Policy 活动执行时，它在其父程序集中查找作为资源存在的 RuleSet。这显然对您尝试在此实现的目标没有什么帮助，因为更改 .rules 文件需要重新编译和重新部署程序集。为了使事情变得简单，您需要一个在其他位置查找 .rules 文件的自定义 Policy 活动。
图 3. .rules 文件作为资源嵌入在工作流程序集中
解决方案的最后一部分是一个自定义工作流活动，它在其所在程序集以外的位置查找其 RuleSet 定义。此位置可以是 Microsoft SQL Server 数据库、服务器文件系统中的文件，或 SharePoint 文档库 — 允许自定义工作流活动检索序列化的规则文件并使用它重新生成和执行 RuleSet 的任何位置。示例 10 大致显示了此类活动的 Execute 方法的行为。在此示例中，它从特定 URL（如 SharePoint 文档库的 URL）检索 .rules 文件。
下面的示例显示外部管理的规则应用程序的开头部分。
WorkflowMarkupSerializer serializer = new WorkflowMarkupSerializer();
XmlReader reader = XmlReader.Create(UrlOfRuleFile);
// Deserialize the .rules file into a RuleSet object.
RuleSet ruleSet = (RuleSet)serializer.Deserialize(reader);
reader.Close();
// Next, use a custom method that returns the root of the workflow as
// an activity.
Activity target = GetRootOfWorkflowAsActivity();
RuleValidation validation = new
RuleValidation(target.GetType(), null);
RuleExecution execution = new RuleExecution(validation,target, ctx);
ruleSet.Execute(execution);
在 SharePoint 文档库内存储 .rules 文件的一个好处是您可以利用完整的版本控制、通知、回收站、审批以及 SharePoint 包含的其他高级功能。您甚至可以运行一个工作流以处理对另一工作流的 .rules 文件所做的更改。
在规则引擎可以发挥作用的任何情况下，都可以使用代码。但是，即使对于中等复杂程度的方案，这也是不可行的，特别是对于高度不稳定的方案。对于这些情况，规则引擎使您可以管理不断变化的复杂规则，而无需编写和重新编写代码。对于简单的方案，不适合使用规则引擎。对于简单的 Boolean 计算，代码或声明性条件已经足够。对于更复杂的方案，编写等效的代码是一项巨大的任务。
本文介绍可供 SharePoint 2010 中的工作流使用的 Windows Workflow Foundation 规则引擎的功能和优点。Windows Workflow Foundation 规则引擎并非适用于每个 SharePoint 工作流。它最适用于完善而复杂的方案。管理和计算相互关联的复杂业务逻辑是规则引擎最突出的功能。如果您发现自己遇到的正是此类方案，则可以采用 Windows Workflow Foundation 规则引擎以获得帮助。
有关详细信息，请参阅以下资源：
Windows Workflow Foundation 规则引擎简介
您对此内容的反馈非常重要。请告诉我们您的想法。
更多反馈？
1500 个剩余字符
我们非常感谢您的反馈。
开发人员中心