基于工作流引擎的业务开发模式

    大型电信级应用往往需要支撑大用户量的高并发处理请求，而且随着分布式架构概念的普及，越来越多的应用要求松耦合、灵活的部署架构。流程应用作为一种特定应用类型，涉及到了与业务功能部署模式，是部署在同一个Web应用内部，还是部署在两个逻辑分离的Web应用中。
    总的来说有2种部署模式：

•     流程引擎嵌入部署
•     流程引擎独立部署

    嵌入式部署模式一般适用于独立的业务系统，IT系统建设中不需要有大量的流程应用，仅仅在局部采用流程的场景，而独立式部署模式适用于在IT系统规划中，流程作为一个独立的概念提出，并且作为基础平台引入的场景中，例如统一流程平台建设。

下面有个采取了流程引擎独立部署的应用，具体部署物理实例图如下：



   业务系统和流程引擎分别部署为独立的群组，采用集群模式部署为独立的集群，业务系统和流程引擎可以分别横向扩充，满足未来集团业务增长需求
    业务系统通过流程引擎提供的WAPI Client调用流程引擎提供的流程服务，实现业务和流程之间的交互，逻辑部署图如下所示



    业务系统和流程引擎分离部署后，业务模块所处的位置，有2种业务部署模式，不同的模式在程序员编码的习惯，数据一致性的处理上，负载均衡的考虑有所差异。



业务前置模式
业务系统负责业务操作，业务端代码实现部署在业务端，流程负责流程状态流转，不参与业务数据操作，
业务系统响应用户请求，调用流程引擎，执行启动业务流程操作，同时流程引擎通过触发事件，调用Portal应用提供的服务，把生产的待办任务发送到Portal中，完成之后，控制权返回给业务系统，业务系统完成接下来的业务数据持久化操作并返回用户结果页面。

业务前置模式主要的优点：

• 基本不改变用户的编程习惯，用户在架构设计上不需要做太多调整，容易适应和理解
• 业务系统负责事务发起和提交，对于业务端的事务控制比较容易
• 业务和流程的远程调用交互会比较少，在事务一致性上减少一些风险

业务前置模式主要的缺点：

• 流程引擎提供的事务扩展机制会比较少的使用，在一些特定的事件上不容易扩展
• 业务系统和流程交互的时候，之间的数据交互只能通过流程相关数据完成，一些流程的实例数据可能需要通过接口

业务后置模式
     主要由流程引擎控制整个完整的业务操作序列，业务端代码实现部署在业务端，但是由流程引擎触发业务端完成业务数据持久化操作，由流程引擎最终完成事务提交，业务系统响应用户请求，调用流程引擎，执行启动业务流程操作，同时流程引擎通过触发事件，回调业务系统提供的业务数据持久化服务，完成业务系统数据更新操作，并且调用Portal应用提供的服务，把生产的待办任务发送到Portal中，完成之后，提交事务，完成整个业务操作，然后返回业务系统，由业务系统返回用户结果页面

业务前置模式主要的优点：

• 充分利用流程引擎提供的事务扩展机制，容易在在一些特定的事件上扩展。
• 业务系统和流程交互的时候，之间的数据交互可以通过流程相关数据完成，也可以通过事件扩展时候的调用参数进行流程数据传递。

业务前置模式主要的缺点：

• 业务系统在架构设计上，复杂度会更高一些，开发人员在开发模式上需要更多掌握
• 业务端需要做服务封装，提供流程引擎调用，在事务一致性考虑上，需要考虑实现幂等操作

     两种融合模式，在事务一致性上都需要有足够的考量，原则上尽量减少事务分段，比如可以通过合并业务操作，减少远程调用的次数，对于服务调用尽量在一次服务交互中完成，这在设计上需要有所考虑

    就当前系统而言，主体采取业务前置的方式，即大部分业务逻辑放在web端，并调用流程引擎的api，采取这种模式基于如下2个考虑：

• 和大部分程序的编程习惯相吻合，能采取spring等框架进行beans之间的关系管理以及声明式定义事务；
• 另外是web服务器个数大于流程引擎服务器个数，能均衡业务处理压力。小部分的业务采取后置方式，比如需要触发的一些同步处理等。

业务系统和BPS交互
下图是业务系统和BPS流程引擎交互的一个总体概览图



    业务系统通过流程引擎提供的客户端，访问流程引擎提供的服务，完成流程的触发调用操作，业务系统和流程直接的数据交互通过流程引擎的相关数据区完成，流程引擎在驱动流程流转过程中，通过触发事件机制，完成和业务系统之间的交互（比如发送Portal待办）。
    业务系统开发完成的活动环节表单和流程的交互，可以通过在流程设计时完成，对于人工参与的活动环节，流程提供了设置属性，可以指定具体的业务表单；用户通过任务待办列表触发相应的活动表单，执行相应的业务数据提交操作
    业务系统和流程引擎之间需要建立数据关联，一般建议在业务系统的业务表中，添加流程数据（可以是流程ID，活动环节ID等），保证业务数据和流程数据的交互



事务一致性
业务系统和流程引擎直接采用分布式部署模式，为了保证业务的一致性，在融合过程中，有两种开发模式可供采用：
业务事务控制
流程事务控制
下图是一张典型的业务和流程的调用关系图，从图中可以看到，在整个图中，业务和流程引擎的交互有两个地方涉及到事务完整性问题：




在上面两个环节，流程引擎的事务处理策略是一致的

不错，此文对于业务系统加入工作流引擎的整合很有帮助！楼主可以接着搞点实例来讲解下，如同一个业务（假期申请）用两种方式实现的代码不同点。。。

一般的oa都是这样
lz画的够细致的

我们原来的系统也用工作流，但是现在前台是用flex技术，和工作流整合，还是有不少麻烦，而且也不能很好的利用表单和工作流的整合。最后工作流方案被否掉。有用过flex整合工作流的，欢迎message我。

图文并茂，挺不错

看了最后一个图，BPS流程服务器的作用是什么？
是为了流程控制吗？

bps 是流程引擎，只起到任务项的状态改变，并以此推进流程的执行
业务部分依然有业务系统去完成

最主要的一点：怎样把硬编码转换为转编码？至于怎样流转那是规则与业务的问题。

有3个问题想问 ：
系统是用什么方式来描述任务项状态改变的？是用状态图或者状态机吗？
引擎控制任务项状态改变或者迁移的那部分逻辑是硬编码的吗？如果不是硬编码的，那么系统支持用户为相关的任务项定制自己所需要的状态图吗？因为实际中不同的任务项采取不同的驱动方式是完全可能的。比如，并行工程中经常提到的预提交。
如果系统允许客户定制任务的状态图，那么当同一过程中存在多个相异的任务项状态图时，系统的流程事务控制是如何实现的呢？

任务的转变是通过状态机来的
相对于人工活动，有3层对象需要联动：流程实例 －》 人工活动实例 －》 任务项
对于自动活动，有2层 ： 流程实例 －》 自动活动实例


附图，是3层对象的状态机变迁图