江西移动MSS域BPM整合咨询_统一流程管理平台建设规范_v0.docx

《江西移动MSS域BPM整合咨询_统一流程管理平台建设规范_v0.docx》由会员分享，可在线阅读，更多相关《江西移动MSS域BPM整合咨询_统一流程管理平台建设规范_v0.docx（50页珍藏版）》请在三一办公上搜索。

1、中国移动江西公司MSS域流程整合咨询项目统一流程管理平台规范（初稿）版本：V 1.0日期：2010年11月16日COPYRIGHT 2010 by Primeton Technologies, Ltd.ALL RIGHTS RESERVED.CMJX-MSS-BPM-统一流程管理平台规范第48页/共50页文档修订记录序号版本号修订日期修订概述修订人审批人备注10.12010-11-16确定初版本刘为20.22010-11-24修订周海涛30.72010-11-25修订刘为周海涛41.02010-11-26修订刘为周海涛内部资料注意保密目录1.引言31.1.编写目的31.2.适用范围31.3.引

2、用文件31.4.术语、定义和缩略语32.平台建设方案42.1.平台建设背景42.1.1.MSS域BPM应用背景42.1.2.MSS域BPM应用现状42.2.平台建设目标52.3.平台建设内容62.3.1.平台建设定位62.3.2.平台建设总体思路82.3.3.平台组成及内容103.标准与规范153.1.平台建设规范153.1.1.平台整合规范153.1.2.组件标准规范223.2.应用建设规范323.2.1.项目实施方法论323.2.2.项目实施规范523.2.3.实施使用指导*904.平台和工具*914.1.平台914.1.1.平台建设技术架构914.1.2.基本组成974.1.3.集成开发

3、环境974.1.4.业务流程定制974.1.5.规则引擎974.1.6.集成运行环境984.2.工具984.2.1.管理监控台984.2.2.平台分析工具984.2.3.平台手册985.资产与知识*995.1.组件库995.2.知识库995.2.1.平台规范995.2.2.软件产品知识995.2.3.解决方案995.2.4.示例代码996.附录991. 引言1.1. 编写目的为了保证江西移动MSS域BPM整合咨询项目顺利实施，编写此文档，梳理工作内容，确认工作范围，指导项目实施进度。其目标体现在四个层面：1、 完成江西移动MSS域的所有业务流程的梳理，对其进行分析和整理。2、 在对业务流程进行

4、分析整理的基础上提出其流程的整合建议，编写流程整合规范。3、 根据规范建议提出流程规划及实施方案建议。4、 根据规范建议对初期的统一流程管理平台的建设提供指导建议。1.2. 适用范围本规范涵盖了江西移动MSS域流程整合、流程建设的技术及业务规范，包括系统架构、与统一任务中心的整合规范、与统一用户中心的整合规范、与业务系统的整合规范、统一流程平台组件库的构建规范、统一流程平台的界面规范以及流程应用的实施方法论、业务流程梳理分析方法、业务流程设计方法、业务流程设计过程和业务流程持续优化等方面的内容。从技术及业务角度出发，给出了流程应用建设的要求，供中国移动内部和应用厂商共同使用，适用于江西移动MS

5、S域流程应用的相关建设。1.3. 引用文件1.4. 术语、定义和缩略语下列术语和定义适用于本规范：术语名词解释BPM业务流程管理业务流程管理。COMPONENT组件流程应用中抽取出的满足特定功能的功能单元，可以是逻辑组件，可以是界面组件2. 技术规范2.1. 平台架构 -ok2.1.1. 平台总体架构以流程为中心的统一流程管理平台支撑MSS域业务流程整合的工作，该平台处于整合集成架构中的“流程集成层”，如下图所示：通过该集成架构，可以支持跨应用的以流程为中心的集成，包括： 对战略与决策支持管理域、计划与预算管理域、供应链管理域、财务管理域、人力资源管理域和企业综合管理域等六大管理域的流程进行集

6、成，将其中的应用服务和流程服务进行抽取，并注册到企业服务总线中，通过流程进行集成。 与“统一认证与授权平台UAAP（或称为4A系统）”进行集成，为流程的任务管理和权限控制提供组织机构和授权信息。 使用企业服务总线很容易实现应用与服务间的集成工作。将流程门户中的业务流程建模、流程集中工作台、管理控制台、统计分析监控、优化调整工具、引擎配置管理等模块集成到企业门户中。统一流程管理平台2.1.2. 平台功能结构下面对整个集成架构中的BPM平台功能架构进行描述，如下图所示：业务流程管理系统分为基本功能部分和扩展功能部分。其中：基本功能部分包括基础支撑（业务流程引擎，业务规则引擎以及系统管理与维护），运

7、行时环境（系统/组件的连接、用户/客户端应用的交互以及业务活动监控和业务事件管理），以及设计时环境（业务流程的建模和设计、业务规则管理部分内容以及功能组件的注册、发布与管理）；扩展功能部分则包含一些扩展接口、业务流程引擎扩展能力、业务流程的仿真与优化，以及多租户服务能力。统一流程管理平台的功能模块包括实现BPM全生命周期的支持，包括：建模与设计、部署与执行、监控与分析、优化与调整等环节。2.1.3. 平台逻辑结构根据中国移动“移动MSS规划及BPM整合规范”的要求，综合考虑江西移动MSS域流程的固化、优化以及跨部门之间流程集成、服务集成等应用集成的要求，统一流程管理平台建设采用如下“流程应用架

8、构”。该应用架构包括资源层、逻辑层、服务层、流程层、协同层，如下图所示： 协同层：为用户提供了一个统一的交互门户和工作平台，通过RIA（Rich Internet Application）的方式提升用户体验，用户通过协同层更容易以其他人进行协作，例如即时通讯、查看工作任务列表、查看发布信息，也能够把已有数据、服务或界面快速组合到新应用中。通过协同层，用户不再与多个孤立的系统进行交互，而是面对一个有机的整体； 流程层：维护跨系统之间的业务状态，企业应用的核心是业务流程，流程包括端到端流程和人工参与的流程，流程会产生任务，推送到工作平台，流程把企业中多个应用联接起来； 服务层：将应用系统提供的逻辑

9、以标准化的方式暴露出来，使开发者不需要关心逻辑的对外协议、逻辑的实现方式、逻辑的部署位置，并提供事件的方式降低逻辑间的耦合度，为非侵入式的操作提供基础； 逻辑层：实现了具体的业务逻辑，包括UI逻辑和后台逻辑。逻辑由多个组件组成，以可插拔的方式部署，提供逻辑的编排能力； 资源层：解决如何整合数据的问题，需要通过一个统一的数据编程模式统一对不同数据源的访问。该逻辑架构说明了应用系统的应用架构以及支撑应用架构的统一流程管理平台基础设施。各应用系统大体都包含协同层、流程层、服务层、逻辑层和资源层，为了使各层相关功能能够稳健运行都需要底层各种基础设施的支撑。流程层也不例外，他需要其他基础设施来支撑业务流

10、程的运行。2.1.4. 平台物理架构2.1.4.1. 部署模式根据中国移动“移动MSS规划及BPM整合规范”的要求，综合考虑江西移动MSS域流程特点，建议采用如下图所示的“统一流程平台”方案：“统一流程管理平台”方案特点： 统一流程管理平台与MSS域业务系统部署在不同的逻辑服务器上的不同Web应用中； 统一流程管理平台数据库与MSS域业务数据库系统分离； MSS域业务系统与统一流程管理平台引擎之间通过远程服务方式调用，事务一致性处理方式需要通过业务补偿的方式进行； 统一BPM集成流程平台与应用之间可以加入服务总线，实现对多系统的流程整合。（建议本次试点过程中将统一流程平台独立部署，最好不与现有

11、业务应用混杂，即使投资限制无法提供满足高性能的设备也争取利用现有设备将统一流程平台独立部署。否则后续规范的落地和验证只能是一纸空谈，无法得到真正贯彻。）2.1.4.2. 物理架构系统物理部署架构同时还要考虑在大规模应用时，用户并发访问量太大给统一流程管理平台所带来的访问压力和性能问题。所以，统一流程管理平台需要提供相应的接口，方便完成基于集群（Cluster）等模式的部署、负载均衡操作等处理过程，保证业务流程管理系统的性能。下面就是集群方式的部署图：企业内网（ESB选件）集群部署场景WebServiceWebServiceOA系统wapi_client.jar模块A模块B模块CJava本地调用

12、PLIS系统wapi_client.jar模块A模块B模块CJava本地调用WebServiceBPM统一流程平台集群节点1BPMOA业务流程PLIS业务流程节点2BPMOA业务流程PLIS业务流程业务系统与统一流程管理平台之间采用WebService方式调用，其中ESB为备用方案。统一流程管理平台需要提供服务接口注册能力，容易注册到商用ESB中。按照系统建设原则与策略，建议前期不采用商用ESB产品模式，随着连接到统一流程管理平台业务系统的增长以及业务量的增长，根据需求决定是否部署ESB产品。2.1.4.3. 拓扑结构结合江西移动MSS域系统当前性能要求和未来2年内业务发展的预期，以江西移动目

13、前的在线用户为基础进行硬件环境的配置，提供以下网络拓扑部署结构：2.2. 整合规范2.2.1. 与统一任务中心整合规范 -liuwei2.2.1.1. 与统一任务中心关系2.2.1.1.1. 关系图2.2.1.1.2. 定位及分工l MSS域流程应用负责业务流程实现及发起流程驱动请求（即完成任务请求）。l 统一流程管理平台负责接收应用系统的完成任务请求，驱动流程，在统一流程管理平台系统中完成原有工作任务，同时新产生工作任务；随后统一流程管理平台会调用统一任务中心的数据接收接口将新产生的任务推送到统一任务中心，同时调用统一任务中心的任务更新接口将原有统一任务中心的任务结束。l 统一任务中心负责接

14、收统一流程管理平台的推送任务请求和完成任务请求。2.2.1.2. 与统一任务中心交互2.2.1.2.1. 任务推送统一流程管理平台将新产生的工作任务推送给统一任务中心。因为统一任务中心目前推送的任务只能是针对人的，所以约定在统一流程管理平台中活动的参与者不能选中角色和机构，只能是角色和机构下的人。任务推送接口采用HTTP和WEBSERVICE两种方式，其接口规范参见下表：序号字段名称数据类型及长度必填中文说明样例及说明1IdInteger是Key自动生成的ID2itemId字符串长度：255个字符是在应用系统待办ID第三方系统待办ID2Docid字符串否Document idDOMINO文档的

15、ID3Title字符串长度：255个字符是标题经营分析8月份报表4link字符串长度：500个字符是待办访问链接/5category字符串长度：100个字符是分类通知公告一般为流程名称6Pubdate字符串是待办数据生成日期2008-09-22 10:00:00，格式必须符合yyyy-mm-ddhh:mi:ss7comments字符串是紧急度数字0-9数字越大紧急度越高8appId字符串长度：100个字符是应用IDeg:erpjx.cmcc(由待办中心建立、分配)9waitStatus字符串长度：255个字符是待办状态经理审核10Uid字符串是用户的uid比如：lisong待办人UID，必须符

16、合统一用户管理系统uid标准的uid名称。11Issms字符串长度：1是是否发送短信值只有0,1两种。0:不发短信1:发送短信默认填012ispress字符串长度：1是是否催办值只有0,1两种。0:不催办1:催办默认填013Status字符串是状态值有0-9，现默认值为00：表示待阅1：表示已阅2：表示待办3：表示已办14Resverse1字符串长度：255否预留字段115Resverse2字符串长度：255否预留字段216Resverse3字符串长度：255否预留字段317Resverse4字符串长度：255否预留字段418Resverse5字符串长度：255否预留字段519Checkkey

17、字符串否校验具体说明请参见EMIS3.0统一待办集成规范V3.doc2.2.1.2.2. 任务结束统一流程接收管理平台统一任务中心的任务更新请求。任务推送接口采用HTTP和WEBSERVICE两种方式，其接口规范参见上述任务推送参数规范表。具体说明请参见EMIS3.0统一待办集成规范V3.doc2.2.1.2.3. 任务查询在各业务子系统中同样存在任务查询，其任务查询来自于统一流程管理平台的任务查询接口，与统一任务中心不产生交互。它与统一任务中心的任务在数据上是对等的关系，要保持数据一致，但它们是并列的两套任务系统，存在于两套不同的系统中，所以它们实质上是并列的、数据一致的关系。2.2.2.

18、与统一用户中心整合规范 -liuwei2.2.2.1. 与统一用户中心关系2.2.2.1.1. 关系图2.2.2.1.2. 整合要点2.2.2.1.2.1. 统一用户角色统一流程管理平台会通过同步统一用户中心的数据和在平台中建立角色来搭建整体的流程平台的用户数据，如果使用流程平台的话，不允许在各子系统中维护自己的角色，须使用统一的组织机构接口实现。2.2.2.1.2.2. 组织机构接口统一流程管理平台实现了统一的组织机构接口，其组织数据、人员数据来自于同步后的数据和结合平台建设的角色数据。如果以后要更改整个组织机构，只需要改统一流程平台的组织机构接口实现。2.2.2.2. 与统一用户中心交互l

19、 数据同步统一流程管理平台通过数据同步接口同统一用户中心进行用户数据的交互，数据的同步采取实时同步策略。因为统一用户中心只有组织数据和人员数据，所以同步到统一流程管理平台的数据也只有组织数据和人员数据，而角色数据是在统一流程管理平台上维护的，那么新同步过来的数据也需要管理员后续将角色数据加上。2.2.3. 与业务系统整合规范 -zhouht需要细化和量化。2.2.3.1. 与业务系统关系统一流程管理平台与业务系统之间的关系如下图所示：2.2.3.2. 定位及分工 业务系统业务系统需要完成的工作：业务信息展示、业务信息维护、调用平台接口驱动流程、提供业务服务接口等功能。 统一流程管理平台统一流程

20、管理平台提供：流程的调度，任务的分配，流程服务接口等。2.2.3.3. 整合要点 部署形态业务流程应用与统一流程管理平台分布式部署，两者之间松耦合。统一流程管理平台提供给多个业务系统同时使用，不能因为某个业务系统的故障造成整个MSS域业务流程应用故障。 组织人员信息业务流程类应用一个典型特点就是人工交互，在系统建设过程中组织机构信息数据处理是一个重要环节。统一流程管理平台已经提供了与统一用户中心的交互能力，不允许业务系统直接连接到统一用户中心，不推荐业务系统同步方式备份组织人员数据。 角色信息组织人员信息统一，角色信息各异是业务流程类应用另一个典型特点。角色和系统的业务关联度较高，各个系统都有

21、各自独立的角色信息。统一流程管理平台提供角色维护能力，角色具有系统属性，系统间角色不冲突。不允许业务系统直接维护角色信息，方便对整个MSS域系统角色的管理，为抽取公共角色（岗位）提供基础。 BPM引擎接口统一流程管理平台对BPM引擎提供的接口进行了封装和处理，比如接口调用缓存等优化操作。业务系统通过平台提供的接口驱动BPM引擎，不允许业务系统直接访问BPM引擎接口和服务。2.3. 组件规范组件抽取是针对开发商同统一流程平台进行对接时，根据自身调用的需要进行的相关功能的封装及实现。为规范开发商的组件的实现，需要开发商遵循统一的组件抽取开发规范，为系统的调用及维护提供制度上的保证。2.3.1. 组

22、件抽取规范 组件是为实现一定功能，并可以被流程引擎调用的逻辑实现。为能更好的管理、调用这些组件，抽取组件时需要遵循一定的规范，通过标准化的流程，实现组件抽取。1、 明确组件实现功能及流程引擎的边界，减少不必要的流程引擎的负担。2、 详细描述组件实现的功能，调用方式。3、 明确在什么样的情况下使用此组件4、 定义组件的输入、输出，并给出每个参数具体的含义说明5、 给出组件的名称，需要能够做到见名之意6、 对组件出现的异常情况给予说明并对出现异常时采取的动作7、 将需要抽取组件的信息填入到相应的表中，使得流程引擎在配置时能够按照需求进行配置。组件抽取所用到的表信息：组件功能表组件功能描述使用范围调

23、用方式Webservice方式、本地调用方式等组件名称组件参数参数1参数2参数说明说明2异常处理说明2.3.2. 组件开发规范2.3.2.1. 流程功能组件开发规范开发商在进行流程组件的二次开发时，首先是根据组件抽取的结果进行组件的开发。并根据组件信息表完善功能组件的相关信息，并填写组件实现表，提供后续开发人员使用。1、 分析抽取的功能组件功能，明确组件实现目标2、 按照组件实现的功能，定义组件的报名及组件名，组件的报名及组件名需要按照应用开发规范进行命名。3、 分析输入输出参数，并对输入输出参数进行定义，参数的取名按照有明确意义的英文字母来取名。参数的类型建议采用简单类型（string、in

24、t等，不建议采用复杂类型）4、 对组件的异常信息进行规划，根据异常处理说明，决定对异常采取封装并抛到调用的上层还是在该组件内处理掉。对于不影响程序运行，并不会产生后续效应的异常，在组件内处理，而当此异常对后续的操作会产生影响，则对此异常进行封装，并将此异常传递到调用层，由调用层进行处理。5、 根据组件功能信息表中的调用方式，将开发的组件发布成java方法还是将其发布成服务。如果是本地java方法，则提供调用的完整类名及方法名、参数等信息，否则，提供调用服务的相关信息。组件功能实现表组件功能实现组件功能描述使用范围调用方式Webservice方式、本地调用方式等调用方式服务调用本地方法调用wsd

25、l地址完整类名url地址方法名组件参数参数1参数2参数N参数说明说明2说明N异常处理说明2.3.2.2. 接口类组件开发规范流程功能组件开发规范已包含接口类组件开发规范，请参考流程功能组件开发规范2.3.2.3. 复合功能组件开发规范复合组件功能是根据项目需要，为实现系统大粒度的功能，由开发商开发的可能包含业务与流程引擎API的结合、流程引擎API的组合实现的业务功能。这些功能的实现有利于开发人员更好使用流程引擎。复合功能的组件梳理与开发规范，请参考流程功能组件开发规范2.3.2.4. 公共流程组件开发规范2.3.2.4.1. 公共流程组件命名规则公共组件命名时，首先需要遵循见名之意，其次，对

26、组件的包名也需要有一定的规范，方便后续查找、追踪组件提供者，为后续组件的维护及持续优化提供便利。公共流程组件分为两个部分，一个部分是流程定义部分，另外一个是组件部分，对这两种情况分别说明公共流程定义部分1、 公共流程的流程定义名遵循的规则：com.cmccjx.public.workflow.系统名.流程名。2、 业务操作中的命名规范遵循应用开发规范的命名规范公共组件部分1、 开发公共组件时，需要对包名进行限制。包名一般以com.cmccjx.打头，其次是公司英文或拼音，如果过程取公司首字母（如：primeton）；后面接的是public.workflow，接着是系统的名称(如：oa)，最后是

27、系统的模块名称。包名都采用小写字母。具体包名如下显示。com.cmccj.公司名.public.workflow.系统名.模块名。如：com.cmccjx.primeton.public.workflow.workflowinstmgr2、 定义流程组件的名称，名称的命名需要有业务含义，如结束工作项的命名：finishWorkItme。采用骆驼表示法来表示。2.3.2.4.2. 公共流程组件发布目录所有公共流程都需要发布到“默认的业务目录”中。2.3.2.4.3. 公共流程组件描述清单流程组件在提交部署时，需要提供如下的详细信息1、 流程定义信息。描述流程所实现的流程详细信息，使用目的。2、

28、自动活动的配置信息清单3、 人工活动的配置清单4、 连线的配置信息5、 在流程定义中所用到的业务资源信息的配置信息，包括业务资源的目录等信息。2.3.3. 组件管理规范 -ok参见管理规范 组件管理规范章节。2.3.4. 组件复用规范组件能够复用的标准是在流程运行过程中，该流程组件被调用次数在一段时间之内大大超过其他组件的调用次数，可以将此组件作为候选可复用的流程组件，经过相关的评审，从候选列表中选出最终作为可复用的组件，并对类似功能的组件进行归并，对其结构进行规划，对其性能进行优化，使得该流程组件最终成为高可用性、高性能的组件。为实现这个目标，需要遵循以下规范1、 筛选规范a) 候选流程组件

29、是通过统计方式分析得出的其被调用次数是在组件调用中占比较高（平均调用次数的3倍以上）。b) 具有通用性的特征c) 能够容易整合其他类似功能2、 规划设计a) 复用组件的功能需要具有通用性b) 确定调用该组件的前置条件及后置条件c) 规划接口参数，且接口参数意义明显d) 接口方式明确，并提供完整的接口说明3、 实现优化。根据java代码优化原则进行代码优化4、 发布规范a) 提供可供使用的组件包b) 提供可复用组件的功能说明c) 提供完善的接口说明，包括组件调用的前置条件及后置条件2.4. 应用开发规范2.4.1. 命名规范 -zhouht在现有的业务流程系统中，流程引擎供一个系统单独使用，当多

30、个系统共用同一个BPM引擎时，为了避免混淆，命名变得非常重要。下面列举部分流程相关部件命名实例，供业务系统参考（征求意见稿）。2.4.1.1. 系统编码 规范要点各个系统按照业务含义定义24个英文字母的系统编码。 规范说明接入到统一流程管理平台的各个业务系统，为了便于区分，各个系统按照业务含义定义24个英文字母的系统编码。比如：合同管理系统（pm）、办公自动化（oa）等。2.4.1.2. 流程定义编码 规范要点流程定义编码命名必须均为小写。通用格式如下xxxxxx(cmccjx).xxx(project name).xxx(module name).xxx(flow name) 规范说明流程定

31、义编码是流程定义模板唯一编码，在平台中必须保持唯一。流程定义编码命名必须均为小写。名词需要使用英文说明功能，不能推荐采用拼音。具体示例如下：通用格式如下xxxxxx(cmccjx).xxx(project name).xxx(module name).xxx(flow name)以cmccjx.ehr.vacation.annualleave为例：第一段jxcc代表江西移动。第二段 ehr为项目名称“人力资源系统”。第三段 vacation为项目模块“假期管理”。第四段 annualleave为流程定义名词“年假申请流程”。2.4.1.3. 流程实例名称 规范要点流程实例名称必须包含业务信息。

32、 规范说明在用户待办任务列表中，首先看到的是流程实例和活动实例名称。其中为了让用户在待办任务列表中可以直观的了解任务信息，流程实例名称必须包含业务信息，具体需要包含哪些关键业务信息需要在需求调研时确认。比如年假申请流程，当流程实例化的时候，命名为“财务部张三年假申请流程”或者是“财务部张三2010年年假申请流程”。这样处理人员不用点击进入待办任务信息页面即可了解待办任务的大概信息。如果全部命名为“年假申请流程”，则无法区分流程实例之间的差异。2.4.1.4. 活动定义名称 规范要点活动定义名称必须包含业务信息，在一个流程模板中，流程定义名称必须能够区分开来。 规范说明假设在如下所示的流程图中，

33、环节2和环节4都是部门领导审批，如果不加区分，在部门领导处理时，在待办任务列表中无法直观的了解流程所处环节。环节2和环节4分别命名为“部门领导初审”、“部门领导复审”之后，活动定义名词可以直接区分两个环节的差异。2.4.1.5. 业务操作命名 规范要点活动定义名称必须包含业务信息，在一个流程模板中，流程定义名称必须能够区分开来。 规范说明假设在如下所示的流程图中，环节2和环节4都是部门领导审批，如果不加区分，在部门领导处理时，在待办任务列表中无法直观的了解流程所处环节。2.4.1.6. 规则命名 规范要点规则分为参与者规则和分支规则，在统一流程管理平台中规则命名需要加上系统编码前缀。 规范说明

34、当规则集中到统一管理平台中之后，需要区分规则的系统属性。便于区分不同业务系统的规则。比如：人力资源系统中请假审批分支规则，当部门经理请假时，公司副总审批；部门员工请假时部门员工审批。该分支规则命名为：“ehr-请假流程-审批人规则”。2.4.2. 流程梳理规范 -liuwei描述在流程梳理的过程中要执行的规范，填写的表单。2.4.3. 组件使用 -liuwei描述如何使用组件2.4.3.1. 标签类组件使用2.4.3.2. 流程功能类组件使用见接口规范接口分类描述统一流程管理平台接口功能分类章节。2.4.4. 流程设计规范 -zhouht2.4.4.1. 是否需要子流程规范要点：在业务流程定义

35、中，一组相关的活动组，可以设计成一个子流程；引入子流程的概念用于表示按照递归方式对流程在级别上做更深入的优化，直至到达合适的组成部分。是否使用子流程主要从下面几个指标衡量：u 企业管理的模式是否需要精细：如财务部门多级审批环节，可以是一个审批环节，也可以是在财务部门经过一组相关活动组成的活动组审批。当然，业务流程管理优化有很多工作要做，但是不是本文重点，这里就不深入讨论。u 使用子流程是否可以使流程图表达简洁清晰：在某些业务流程中环节较多，如果所有的活动放在同一个层次，会使得流程图拓扑结构复杂而不容易识别。对业务功能相近或者相关的活动组适当的使用子流程，可以使整个业务流程表达清晰简单。这种情况

36、下推荐使用子流程。u 一组活动被多处重用：在整个业务系统中，如果某些相近或者相关的活动组在多个流程中可以重用，推荐使用子流程。u 是否有子流程嵌套：在业务系统中如果有子流程递归调用的情况，建议使用子流程。【应用场景活动组复用举例】：在Error! Reference source not found.所示中的应用场景中，客服部门会受理不同产品的申办请求，不同的产品在IT支撑部门处理过程都是一样的：首先由“IT支撑部审核”，如果是非标准业务转由“IT支撑部经理审核”，最后由IT支撑人员做相应的操作。其他部门则根据产品的不同走不同的审批流程。使用子流程的设计方案是可以将“IT支撑部处理”相关的3个

37、人工活动设计成所示的子流程，Error! Reference source not found.的需求就可以设计成Error! Reference source not found.的方案。这样“IT支撑部处理”子流程就可以在多个流程中使用，将来IT支撑部处理过程发生变化时，仅仅修改子流程即可。2.4.4.2. 子流程调用层级设计 规范要点子流程嵌套调用层级建议为3级。 规范说明主流程调用子流程，子流程可以调用另一个子流程，如此递归技术上来讲，子流程调用的层级不受限制。在实际项目中，如果子流程层级太深，流程返回时执行速度会有影响；另外，太深的流程调用不利于流程监控图展示。根据实际项目实践，推荐

38、子流程调用层级为3层。2.5. 界面规范 -zhouht2.6. 接口规范 -liuwei2.6.1. 接口服务方式流程应用与统一流程管理平台主要采用三种服务方式： UDDI服务方式和普通WebService服务方式、HTTP会话服务方式。l UDDI服务：统一描述、发现和集成（UDDI）规范定义发布和发现有关WebService的信息的方法。业务系统调用统一流程管理平台提供的服务都是采用UDDI的服务方式l 普通WEBSERVICE：非采用UDDI服务方式的调用，通常指采用传统WebService框架（如：Xfire，Axis2）发布和调用的服务。统一流程管理平台调用业务系统的服务方式可采用

39、普通WebService方式或HTTP会话服务方式。引用系统根据具体业务需求灵活选择。l HTTP会话服务：HTTP URL地址直接提供的服务，统一流程管理平台调用业务系统的服务和BPM流程引擎调用的服务会采用HTTP会话服务。引用系统根据具体业务需求灵活选择。2.6.2. 接口通讯方式接口基本采用了同步请求/应答方式、异步请求/应答方式（暂不考虑会话方式、可靠消息传输方式、文件传输等通讯方式）。服务调度时可选择服务方式是同步请求/应答方式还是异步请求/应答方式。在接口通讯中，基于交易的事务处理方式可采用以下几种通讯方式：同步请求/应答方式：接口调用方向接口提供方发送服务请求，接口调用方阻塞等

40、待接口提供方返回处理结果。异步请求/应答方式：接口调用方向接口提供方发送服务请求，与同步方式不同的是，在此方式下，接口提供方处理请求时，接口调用方继续运行；当接口提供方处理结束时返回处理结果。2.6.3. 接口完整性管理根据现有应用系统的特点，接口都是采用基于交易的事务处理机制实现，每个接口在对外提供服务的时候应该保证事务的完整，一个接口里包含的所有业务都在一个事务内。在服务调用出错后事务全部回滚，以便业务能对再次对其进行处理以确保流程的顺利流转。调用方在批量调用接口的时候，须考虑事务的完整性和延续性，确保出错后能多次调用以完成整个事务，来保障整个业务事务的统一。2.6.4. 接口安全管理为避

41、免系统间非正常访问，保证接口交互信息的可用性、完整性和保密性。接口访问须对接口本身进行安全访问，须在服务调用的客户端和服务端进行安全配置及安全验证。业务系统提供服务时须在服务内部进行IP地址、密码校验等安全限制，非正常的系统访问予以拒绝，同时每次调用记录服务调用日志。如果业务系统提供的是HTTP服务，则须进行单点认证或进行相关授权。流程管理平台提供的服务在提供之前需进行服务端与客户端密钥的安全配置，非安全访问予以拒绝。2.6.5. 接口分类描述2.6.5.1. 业务系统服务接口2.6.5.1.1. 描述业务系统与统一流程管理平台相互调用的接口主要包括业务系统服务接口和统一流程管理平台接口两大类

42、。其中业务系统服务接口指的是调用方为统一流程管理平台，服务方为业务系统的接口。主要是指流程活动为服务方式（如：自动活动或webservice活动）时，统一流程管理平台会调用业务系统中的业务逻辑服务。2.6.5.1.2. 业务系统接口规范2.6.5.1.2.1. 业务系统接口适用范围业务系统发布的服务接口主要提供给流程管理平台统一调用，来完成业务的相关实现。通常是在流程中的自动活动和WebService活动中调用。提供的服务需满足接口的高并发性和稳定性要求，在流程设计时可根据具体的业务和接口的执行情况选择在自动活动中调用还是在WebService活动中调用。2.6.5.1.2.2. 业务系统接口

43、发布规则业务系统发布的服务接口发布的方式主要为两种方式：一种是WebService接口，一种是HTTP接口。通常WebService服务在应用系统中以WebService工具（如：xfireaxis2）暴露成web service，接口的输入输出参数应可序列化。HTTP服务直接在应用中跟随应用启动发布，其接口的输入输出参数为文本，并且文本尽量避免适用中文和特殊符号。2.6.5.1.2.3. 业务系统接口管理规则业务系统提供的业务接口在发布和管理时应在系统建设时遵循一定的规范，如发布时填写具体的接口说明，功能说明，输入输出参数说明，被哪些流程调用等信息。发布后要能实现可预见、可管理的原则，在对接

44、口进行维护的过程中和执行后要能清晰的查询相关接口的在用信息、调用频次、资源占用等信息，以便于业务系统查知提供了哪些服务接口及监控其接口的运行情况以及对应用系统整体的影响。接口发布时填写模板可参见业务系统接口管理模板。2.6.5.1.2.4. 业务系统接口异常规则在统一流程管理平台调用业务系统接口的时候，会出现不同的异常情况，包括网络异常、业务异常等，对于调用方的直接影响是导致流程的运转不正常。在流程定义时会设置服务调用时的异常处理策略，在策略为“回滚异常”和“进入异常状态”的情况下，此时流程停在服务调用的活动上面，所以在业务实现上需要对其进行处理。处理的规则为如下建议：1、 对于复杂的业务流程，进行人工干预，实行业务重做。2、 在业务端实现后台处理进程，自动查询处理异常服务，然后自动调用其服务并完成相关活动以驱动流程。2.6.5.1.3. 统一流程管理平台调用规范2.6.5.1.3.1. 接口调用方式l 自动活动调用自动活动的调用即可调用业务系统的WebService