本系列的 第 1 部分 重点介绍了 SOA 服务层中与 BPM 分离的决策服务，并使用了一种具有有限载荷的粗粒度接口。这样做的目的在于实现可重用性，避免让 BPM 使用者将所有数据都发送给决策服务。BPM 和 BRMS 的信息模型不同；BPM 充当工作流编排层，没有承载与它使用的服务相同的结构和定义。决策服务是一个可重用的服务，不是为单个使用者而设计的。BPM 仍然是一个使用者，因此需要将 IBM Business Process Manager (IBM BPM) 与 IBM ">Operational Decision Manager (IBM ODM) 集成在一起。本文将介绍不同的产品集成功能，并提供有关使用它们的时机的一些条件。架构师需要评估其功能需求和非功能需求，选择最佳的解决方案。
从 2010 年 6 月开始，IBM BPM 和 IBM ODM（以前的 ILOG JRules）提供了开箱即用的集成功能，实现了顺利的集成。但是，在实现这些集成之前，需要考虑一些约束条件。最重要的约束条件与两个产品所需的信息模型密切相关。在 第 1 部分 中可以看到，业务流程管理变量可处理流程活动之间的信息，使用 coach 向人们提供信息或从人们那里获取数据。大部分时间，决策服务需要采用一种不同的数据模型，这种模型使用面向对象的分析方法根据域模型调整而来，添加了实用程序方法和算法操作，获得了一个比 BPM 所用图表更复杂的数据图表。该模型的目的在于更有效地执行规则，改善规则创作体验。IBM BPM 流程应用程序使用 JavaScript 变量在流程活动之间传递数据，BPM Advance Integration Service (AIS) 使用一个服务数据对象来管理数据，ODM 将本机使用 XML，甚至会使用 OPJO 类。还需要使用数据映射和技术映射。
在过去三年中我们看到，从流程中外部化规则处理的需求更高，两个最常见的需求是数据验证和富决策活动。数据验证规则常常埋藏于屏幕逻辑内，但也需要验证在流程中收集的所有数据，然后才能将它们保存到后端系统。富决策活动包括知识和主题专家会制定数据决策所用的每个人类任务。人们常常将流程流路由规则（网关节点）视为要外部化到 BPMS 中的规则，但是，事实上这是一种很少见的使用情形。其中大部分路由规则都很简单，表示有限数量的规则，在本质上是静态的。在 IBM BPM 中使用 JavaScript 实现这种路由逻辑要简单和快捷得多。对于数据验证，需求可分离为以下两类：
在将数据输入
表单中后立即验证它，以在同一个 coach 中获得错误消息。 在所有数据收集活动结束时，用户会在业务数据提交到后端或下游流程时验证数据。系统会将一个错误列表报告给用户，以便能够修复数据。
图 1 显示了一个业务流程定义示例，演示了数据输入活动和后面的正式数据验证步骤，这个步骤建模为嵌套的服务。
图 1. 含有数据验证调用的人类服务
对于 coach 中的数据验证，目前的常见方法是在 coach 中使用 JavaScript 实现结构规则或业务规则，约束数据模型或用户界面。以下示例可通过在 coach 中向小部件控件添加逻辑来实现。
如果损失类型为汽车事故，则需要选择一辆被保险的汽车，而且还必须提供事故位置地址。 如果损失类型为火灾，那么至少需要选择一种被保险的财产。
在 Coach Designer 内，开发人员可以使用其他字段上的条件控制元素可视性。图 2 在索赔类型上将一个条件定义为 accident，以显示一个相应的字段。
图 2. 使用其他字段值控制可视性
查看上述这些规则，显然它们也需要包含在流程中的最终验证步骤中。数据验证规则的外部实现可供应用程序的其他部分或其他使用者重用。因此，这些约束规则可编码到两个地方：用户界面和 BRMS。事实上，在一些解决方案中，BRMS 可支持两种情形，我们将在本系列的第 3 部分中介绍。另外，由于这些是可执行的规则，所以重要的是不仅要考虑规则的条件，还要考虑操作部分和执行上下文。UI 中的操作是在字段级显示一个错误消息，这会导致 validate data 决策服务拒绝索赔，并在一个列表中累积发现的所有问题。
本文中提供的示例利用了 IBM BPM V8.0.1 Advanced 和 IBM ODM V8.0.1，但所提供的大部分方法都可用于两个产品的 7.5 版。
当在 Process Designer 中设计一个业务流程模型定义时，流程开发人员可使用不同的集成功能与出站服务（比如决策服务）交互。当前的功能包括 Web 服务集成、Java 集成、Advanced Integration Services 和 BPM JRules 决策服务。
基本的索赔处理场景
为了演示本文中提供的不同示例，我们将使用一个针对汽车保险的基本的索赔处理应用程序。该过程首先是一组用于输入索赔数据的 coach，然后第一个系统车道活动将验证索赔，向索赔处理人员（流程参与者）报告任何错误，然后进入资格鉴定和判决步骤流程，这些也属于决策服务。顺利的话，随后将进入索赔支付和索赔备案步骤。我们至少需要考虑两个决策服务：一个用于数据验证，另一个用于判决索赔。规则优势使我们能够在验证中识别大约 100 条规则，在宣布步骤中识别至少 500 条规则。业务流程定义和决策服务的开发可以并行执行，而且大部分时间都需要不同的开发人员技能集：业务流程分析师定义 BPMN 流程定义，而规则分析师（常常是精通知识获取技术和知识表达的知识工程师）处理规则发现、分析和实现。另外，在业务端，流程负责人常常与业务规则负责人不同；例如，索赔处理流程负责人不负责判决规则，这由判决部门负责，风险管理规则也是如此。
两个团队的并行开发需要同步化。信息模型定义和决策服务规范代表两个主要元素，限制了产品之间的集成。