本文将以需求中部分业务流程为例，介绍如何开发基于WPS的业务流程，包括图1所示的系统架构中WPS平台之上的业务流程，业务状态机，业务规则等组件。

引言

现代企业中存在多个业务IT系统，一个复杂的业务过程可能会在多个系统上进行操作，这就是跨系统的业务流程。在传统的各个系统独立分散的架构下，系统之间的访问会由各个系统自己发起，业务流程的逻辑分散在各个业务系统之中，造成了业务流程的割裂和数据资源的冗余，同时异构系统之间的交互存在着访问方式和数据类型转换的困难。

流程整合的平台可以解决上面这些问题，它将异构的业务系统接入到这个平台之上，将系统提供的服务封装成标准的服务，具备标准的接口方式和数据类型，并将与各个系统进行交互的业务流程放在这个平台之上，可以快速的开发，变更，部署和管理业务流程。当用户需要增加一个新的业务的时候，可以复用现有的流程编排出新的业务流程。

WebSphere Process Server（WPS） V6是一个基于SOA架构的业务流程集成平台，在将现有的IT系统集成到平台的基础上，将各个系统的业务流程也集成到这个平台之上，以多个可重用的流程组合编排成端到端的完整的业务流程。

WSCTI项目集成了多个电信业务系统，实现了一系列端到端的业务流程，本系列的第一，二部分对项目的背景，需求，架构以及数据模型等方面进行了介绍，参见参考资料。本文将以需求中部分业务流程为例，介绍如何开发基于WPS的业务流程，包括图1所示的系统架构中WPS平台之上的业务流程，业务状态机，业务规则等组件。

图1 WSCTI系统架构

业务流程分析

WSCTI实现的业务场景集中在电信业务中最常见的订单处理方面，下面我们就以订单处理这个业务流程为例。

下面是订单处理的用例：

参与者：CRM，服务开通系统，计费系统，资源管理系统，操作员

前提条件：操作员通过Web客户端提交客户订单，订单中包含一个或者多个业务开通请求，多个业务开通之间可能存在依赖关系，比如ADSL开通要求电话先安装完成。订单所需资源已预占。

基本成功流程：

1. CRM存储订单。

2. 确认是否订单中所有工单都已完成，如果是，跳到第6步；否则，继续。

3. 在订单中的未开始工单中找出未被依赖的工单，比如在ADSL和电话中首先安装电话，交由业务开通系统实施此工单。一个工单可能会花费较长的时间去完成，比如几天或者几个星期。

4. 业务开通系统首先实施和配置业务，然后进行端到端的测试，然后激活此服务。 开通实施过程的状态变化会更新到CRM，方便客户查询。

5. 业务开通完成后，跳到第2步重新确认是否所有工单都已完成。只有在所有的工单都完成以后，整个订单才算完成。

6. 所有工单都已完成后，在资料管理系统中实占所有已预占的资源，在计费系统中增加计费项目。订单已完成，在CRM中更新订单状态。

7. 告知操作员客户订单已完成，服务已开通，由操作员向客户通知。

可以看到，在这个业务流程中包含了多个业务系统之间的交互，在将它们集成到WPS平台之上后，将通过WPS与这些系统进行交互，调用它们提供的服务。图2显示了在WPS平台之上如何组织订单处理的流程。

图2 订单处理流程图

在下面的小节中我们将展示WPS如何实现流程的编排，也就是图2中WebSphere Process Server泳道部分。由于篇幅的限制，我们将只对重点的方面做介绍。

业务流程开发

对外接口

订单处理作为一个服务，它有向外发布的基于WSDL标准的接口OrderHandling，接口中的操作包括订单提交，取消订单，修改订单和查询订单，如图3所示：

图3 订单处理接口

实现订单处理接口的服务组件将实现接口中的所有操作，也就是实现了这些功能。这个服务组件以此接口导出后，其它的SCA模块以及非SCA的程序都可以调用这些服务，比如调用submitOrder操作，就可以提交订单，然后由WPS驱动业务流程运行，对提交的订单进行处理。除了提交订单以外，还支持对提交的订单进行查询，修改以及撤消等功能。

在WID中，可以通过菜单File -> New -> Interface开始创建接口，指定接口所在的模块和名字等属性，然后就可以为接口新增操作，为操作指定输入，输出等数据类型。

导入服务

让我们看看我们已经拥有了哪些外部提供的服务，我们要使用这些服务完成订单处理的功能。这些服务在WID中由其它的模块提供，它们都以SCA Export的方式导出，在订单处理的模块中是将它们以SCA Import的方式导入，这样就可以使用这些服务。WSCTI项目中的其它服务模块与订单处理模块之间的关系如图4。

图4 WSCTI服务模块

图中PeonyBilling模块提供了计费处理的服务，它封装了计费系统提供的功能；PeonyResource模块提供了资源管理的服务，封装了资源管理系统提供的功能；PeonyService模块提供了工单处理等服务，封装了服务开通系统提供的功能；PeonyCRM模块提供了客户信息管理服务，封装了CRM系统提供的功能。PeonyOrder模块提供订单处理等服务，通过SCA Import导入其它模块提供的服务。

上面这些服务模块封装了在WPS接入的业务系统提供的功能，通过WPS的系统集成功能引入到WPS的平台之上，成为可复用的服务。WPS提供了多种方式将企业中现有的IT应用系统集成到WPS中，包括适配器，Web服务等，本系列的后续文章中将对WSCTI项目中系统集成的案例给出详细的介绍。

服务的设计与组装

现在我们要开始实现订单处理的业务流程，首先对要此业务流程进行简单的分析：

• 从图2可以看到，从订单提交到WPS到完成订单，WPS将与多个业务系统进行交互，也就是会调用到图4中所有导入的服务；
• 此业务流程是个长流程，因为订单中包含多个工单，工单的实施会是一个很长的时间，服务模块需要等待工单实施模块的回调通知工单实施的状态变化。
• 在对订单处理中存在明显的状态转换过程，在订单提交以后，只有所有的工单都成功施工完成后，订单的处理才能开始进行完成订单的工作。
• 需要检查业务实施在先后顺序上的依赖关系，这是业务逻辑的范畴，而且可能经常发生变化。

根据以上分析，我们做出以下设计：

1. 使用业务流程（Business Process）实现多个子业务流程，并对各个外部服务进行调用。子流程包括保存订单，提交工单，更新订单状态，完成订单等流程。每个子流程都是短流程，方便子流程的复用。业务流程将实现一个内部接口SalesOrder，它包含的操作就是每个子流程要实现的功能，如图5。

图5 SalesOrder接口

2. 使用业务状态机（Business State Machine, BSM）实现对订单状态的控制，它不会直接调用外部提供的服务，而是由它调用业务流程组件，驱动子流程实现具体的业务功能。业务状态机组件适合于实现有多个业务状态，状态之间在事件触发下进行转换的业务流程，通常都是长流程。此业务状态机将实现对外的接口OrderHandling，如图3。

3. 对长时间的外部服务采用异步的调用方式，调用服务的方式是单向的（One-Way），当服务完成以后，会回调业务状态机提供的某个服务接口，受到此服务调用的事件驱动，业务状态机将会驱动业务流程的继续。这我们的项目中，这个回调来自于工单实施模块，它在工单的施工状态发生变化的时候，比如实施完成，测试完成等等，将会调用此接口。上面提到的业务状态机将会实现此接口WorkOrderResponse，如图6，这样工单状态变化的事件将会驱动业务状态机中状态的转换。

图6 WorkOrderResponse接口

4. 使用业务规则（Business Rule）组件实现业务依赖关系，将业务逻辑从业务流程中剥离出来，方便定制和修改。业务规则的接口WorkOrderDependency如图7，它根据输入的两种服务类型确定服务之间是否存在依赖关系。

图7 WorkOrderDependency接口

按照以上的设计，我们可以把各个模块组装起来，连接起服务与服务之间的关系，也就是确定了服务的实现之间的调用关系，如图8。

图8 订单处理模块的装配图

图中OrderHandlingBSM是实现业务状态机的组件，SalesOrderBPEL是实现子业务流程的组件，WorkOrderDependencyRuleGroup是实现业务规则的组件，后面我们将简单介绍它们的实现。另外，OrderHandlingExport是OrderHandling服务的导出，WorkOrderResponseExport是WorkOrderResponse服务的导出，用于工单状态更新的回调；其余的导入模块BillingImport, CRMImport, ResourceImport, WorkOrderImport和CustomerNotificationImport为上一节中提到的导入的外部服务。

下面将介绍其中主要模块的实现，更多的关于WPS组件的开发可以参见参考资料。

业务状态机的实现

上面已经提到，图8中的业务状态机OrderHandlingBSM是整个业务流程中的一个主要模块，它维护着订单处理的状态。OrderHandlingBSM实现了OrderHandling接口和WorkOrderResponse接口描述的服务，图9显示了它的实现。

图9 OrderHandlingBSM实现

从图中我们可以看到：

1. 当submitOrder操作被调用的时候，WPS将会创建一个新的OrderHandlingBSM实例，然后进入SaveOrder状态。

2. SaveOrder是个短暂状态，它保存订单以后，马上进入到InProgress状态。

3. 当进入InProgress状态时，会调用SalesOrder接口的ScanAndFireWorkOrders操作遍历所有工单并请求对不被依赖的工单进行施工。

4. InProgress是个稳定状态，可能引起它发生状态迁移的操作有queryOrder, cancelOrder, changeOrder, updateStatus等操作。比如queryOrder，是为了查询处理中的订单的信息，对它就直接返回状态机中保存的订单，因为它包含了最新的信息，然后又返回InProgress状态。

5. 当WorkOrderResponse服务的updateStatus被调用的时候，InProgress状态迁移到CheckStatus状态，同时更新工单状态到相关系统，比如CRM。

6. CheckStatus状态也是个短暂状态，它检查是否所有工单都已经完成，如果是的话，调用SalesOrder服务的completeOrder操作，然后迁移到Completed状态，这个状态机实例随之结束；如果还有工单为完成的话，重新回到InProgress稳定状态，等待新的事件触发。

7. 修改订单操作changeOrder也可能引起订单中工单情况的变化，所以也会使InProgress状态迁移到CheckOrderStatus状态。

8. 取消订单操作cancelOrder会使InProgress状态发生迁移，调用SalesOrder服务的cancelOrder操作后，进入cancelled状态，状态机实例也随之结束。

以上描述中调用SalesOrder服务，实际上就会调用图8中SalesOrderBPEL组件对此服务的实现。

业务流程的实现

业务流程SalesOrderBPEL实现了图5所示的接口，调用其它模块提供的服务，完成多个业务子流程。SalesOrderBPEL的部分实现如图10。

图10 SalesOrderBPEL部分实现

以完成订单操作complete为例，其业务流程的实现主要包括下面几个步骤：

1. 以循环的方式对每个工单进行判断，如果它预占了资源，那么就请求实占资源；

2. 以循环的方式对每个开通的服务增加计费项，并将开通服务的状态更新到CRM系统；

3. 更新订单的状态到CRM系统；

4. 发出人工任务，要求营业员通知客户订单已完成。

SalesOrderBPEL中的业务流程都是短流程，一个流程就是一个完整的事务，其中事务性的活动就是以上1－4步的动作。如果发生错误，整个流程所有已成功完成的事务活动都会调用补偿服务（Compensation Service），目的是将事务活动已完成的动作回滚。关于更多WPS中业务流程对于事务的支持，参见参考资料.

业务规则的实现

我们将业务开通的依赖关系用业务规则组件实现，可以将业务逻辑从业务流程中抽象出来，方便设计，修改和管理。对于业务开通的依赖关系，实现的接口如图7所示，具体的实现WorkOrderDependencyRuleGroup如下图11所示。

图11 WorkOrderDependencyRuleGroup的实现

WorkOrderDependencyRuleGroup是一个业务规则组，可以包含多个业务规则集合，并为它们设定有效日期，选择条件等属性，这里只包含了一个业务规则集合WorkOrderDependencyRuleSet，它的部分实现如图12所示。

图12 WorkOrderDependencyRuleSet的部分实现

我们可以使用可视化的方式定制业务规则，并支持内嵌Java代码实现业务逻辑。这里我们采用静态的方式，根据输入的业务类型确定两种业务之间是否存在依赖关系。

结束语

本文展现了WSCTI项目中实现的一个典型的业务流程，介绍了针对实际的业务流程使用WID进行设计和开发。

参考资料

1. 基于WPS的电信业务集成场景，第一部分：场景与系统架构是本系列的第一篇文章，介绍了WSCTI项目的背景，需求和系统架构。
2. 基于WPS的电信业务集成场景，第二部分：数据建模及其实现是本系列的第二篇文章，介绍了WSCTI项目的数据模型。
3. 基于WPS的电信业务集成场景，第四部分：集成WPS与数据库应用是本系列的第四篇文章，介绍了集成WPS与数据库应用。
4. WebSphere业务流程管理信息中心包含了WebSphere Process Server和WebSphere Integration Developer等产品的文档。
5. 深入了解WPS中的业务状态机详细介绍了如何开发业务状态机。
6. 深入了解WPS中的Business Rules详细介绍了如何开发业务规则。
7. Compensation in WebSphere Process Server business processes详细介绍了WPS对业务流程的事务性以及补偿的支持。