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

CMJX-MSS-BPM-统一流程管理平台规范第48页/共50页CMJX-MSS-BPM整合项目-统一流程管理平台规范中国移动江西公司MSS域流程整合咨询项目统一流程管理平台规范（初稿）版本：V1.0日期：2010年11月16日COPYRIGHT2010byPrimetonTechnologies,Ltd.ALLRIGHTSRESERVED.文档修订记录序号版本号修订日期修订概述修订人审批人备注10.12010-11-16确定初版本刘为20.22010-11-24修订周海涛30.72010-11-25修订刘为周海涛41.02010-11-26修订刘为周海涛内部资料注意保密

目录1. 引言 31.1. 编写目的 31.2. 适用范围 31.3. 引用文件 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. 集成开发环境 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. 附录 99引言编写目的为了保证江西移动MSS域BPM整合咨询项目顺利实施，编写此文档，梳理工作内容，确认工作范围，指导项目实施进度。其目标体现在四个层面：完成江西移动MSS域的所有业务流程的梳理，对其进行分析和整理。在对业务流程进行分析整理的基础上提出其流程的整合建议，编写流程整合规范。根据规范建议提出流程规划及实施方案建议。根据规范建议对初期的统一流程管理平台的建设提供指导建议。适用范围本规范涵盖了江西移动MSS域流程整合、流程建设的技术及业务规范，包括系统架构、与统一任务中心的整合规范、与统一用户中心的整合规范、与业务系统的整合规范、统一流程平台组件库的构建规范、统一流程平台的界面规范以及流程应用的实施方法论、业务流程梳理分析方法、业务流程设计方法、业务流程设计过程和业务流程持续优化等方面的内容。从技术及业务角度出发，给出了流程应用建设的要求，供中国移动内部和应用厂商共同使用，适用于江西移动MSS域流程应用的相关建设。引用文件术语、定义和缩略语下列术语和定义适用于本规范：术语名词解释BPM业务流程管理业务流程管理。COMPONENT组件流程应用中抽取出的满足特定功能的功能单元，可以是逻辑组件，可以是界面组件技术规范平台架构--ok平台总体架构以流程为中心的统一流程管理平台支撑MSS域业务流程整合的工作，该平台处于整合集成架构中的“流程集成层”，如下图所示：通过该集成架构，可以支持跨应用的以流程为中心的集成，包括：对战略与决策支持管理域、计划与预算管理域、供应链管理域、财务管理域、人力资源管理域和企业综合管理域等六大管理域的流程进行集成，将其中的应用服务和流程服务进行抽取，并注册到企业服务总线中，通过流程进行集成。与“统一认证与授权平台UAAP（或称为4A系统）”进行集成，为流程的任务管理和权限控制提供组织机构和授权信息。使用企业服务总线很容易实现应用与服务间的集成工作。将流程门户中的业务流程建模、流程集中工作台、管理控制台、统计分析监控、优化调整工具、引擎配置管理等模块集成到企业门户中。统一流程管理平台平台功能结构下面对整个集成架构中的BPM平台功能架构进行描述，如下图所示： 业务流程管理系统分为基本功能部分和扩展功能部分。其中：基本功能部分包括基础支撑（业务流程引擎，业务规则引擎以及系统管理与维护），运行时环境（系统/组件的连接、用户/客户端应用的交互以及业务活动监控和业务事件管理），以及设计时环境（业务流程的建模和设计、业务规则管理部分内容以及功能组件的注册、发布与管理）；扩展功能部分则包含一些扩展接口、业务流程引擎扩展能力、业务流程的仿真与优化，以及多租户服务能力。统一流程管理平台的功能模块包括实现BPM全生命周期的支持，包括：建模与设计、部署与执行、监控与分析、优化与调整等环节。平台逻辑结构根据中国移动“移动MSS规划及BPM整合规范”的要求，综合考虑江西移动MSS域流程的固化、优化以及跨部门之间流程集成、服务集成等应用集成的要求，统一流程管理平台建设采用如下“流程应用架构”。该应用架构包括资源层、逻辑层、服务层、流程层、协同层，如下图所示：协同层：为用户提供了一个统一的交互门户和工作平台，通过RIA（RichInternetApplication）的方式提升用户体验，用户通过协同层更容易以其他人进行协作，例如即时通讯、查看工作任务列表、查看发布信息，也能够把已有数据、服务或界面快速组合到新应用中。通过协同层，用户不再与多个孤立的系统进行交互，而是面对一个有机的整体；流程层：维护跨系统之间的业务状态，企业应用的核心是业务流程，流程包括端到端流程和人工参与的流程，流程会产生任务，推送到工作平台，流程把企业中多个应用联接起来；服务层：将应用系统提供的逻辑以标准化的方式暴露出来，使开发者不需要关心逻辑的对外协议、逻辑的实现方式、逻辑的部署位置，并提供事件的方式降低逻辑间的耦合度，为非侵入式的操作提供基础；逻辑层：实现了具体的业务逻辑，包括UI逻辑和后台逻辑。逻辑由多个组件组成，以可插拔的方式部署，提供逻辑的编排能力；资源层：解决如何整合数据的问题，需要通过一个统一的数据编程模式统一对不同数据源的访问。该逻辑架构说明了应用系统的应用架构以及支撑应用架构的统一流程管理平台基础设施。各应用系统大体都包含协同层、流程层、服务层、逻辑层和资源层，为了使各层相关功能能够稳健运行都需要底层各种基础设施的支撑。流程层也不例外，他需要其他基础设施来支撑业务流程的运行。平台物理架构部署模式根据中国移动“移动MSS规划及BPM整合规范”的要求，综合考虑江西移动MSS域流程特点，建议采用如下图所示的“统一流程平台”方案：“统一流程管理平台”方案特点：统一流程管理平台与MSS域业务系统部署在不同的逻辑服务器上的不同Web应用中；统一流程管理平台数据库与MSS域业务数据库系统分离；MSS域业务系统与统一流程管理平台引擎之间通过远程服务方式调用，事务一致性处理方式需要通过业务补偿的方式进行；统一BPM集成流程平台与应用之间可以加入服务总线，实现对多系统的流程整合。（建议本次试点过程中将统一流程平台独立部署，最好不与现有业务应用混杂，即使投资限制无法提供满足高性能的设备也争取利用现有设备将统一流程平台独立部署。否则后续规范的落地和验证只能是一纸空谈，无法得到真正贯彻。）物理架构系统物理部署架构同时还要考虑在大规模应用时，用户并发访问量太大给统一流程管理平台所带来的访问压力和性能问题。所以，统一流程管理平台需要提供相应的接口，方便完成基于集群（Cluster）等模式的部署、负载均衡操作等处理过程，保证业务流程管理系统的性能。下面就是集群方式的部署图：企业内网企业内网（ESB选件）集群部署场景WebServiceWebServiceOA系统wapi_client.jar模块A模块B模块CJava本地调用PLIS系统wapi_client.jar模块A模块B模块CJava本地调用WebServiceBPM统一流程平台集群节点1BPMOA业务流程PLIS业务流程节点2BPMOA业务流程PLIS业务流程业务系统与统一流程管理平台之间采用WebService方式调用，其中ESB为备用方案。统一流程管理平台需要提供服务接口注册能力，容易注册到商用ESB中。按照系统建设原则与策略，建议前期不采用商用ESB产品模式，随着连接到统一流程管理平台业务系统的增长以及业务量的增长，根据需求决定是否部署ESB产品。拓扑结构结合江西移动MSS域系统当前性能要求和未来2年内业务发展的预期，以江西移动目前的在线用户为基础进行硬件环境的配置，提供以下网络拓扑部署结构：整合规范与统一任务中心整合规范--liuwei与统一任务中心关系关系图定位及分工MSS域流程应用负责业务流程实现及发起流程驱动请求（即完成任务请求）。统一流程管理平台负责接收应用系统的完成任务请求，驱动流程，在统一流程管理平台系统中完成原有工作任务，同时新产生工作任务；随后统一流程管理平台会调用统一任务中心的数据接收接口将新产生的任务推送到统一任务中心，同时调用统一任务中心的任务更新接口将原有统一任务中心的任务结束。统一任务中心负责接收统一流程管理平台的推送任务请求和完成任务请求。与统一任务中心交互任务推送统一流程管理平台将新产生的工作任务推送给统一任务中心。因为统一任务中心目前推送的任务只能是针对人的，所以约定在统一流程管理平台中活动的参与者不能选中角色和机构，只能是角色和机构下的人。任务推送接口采用HTTP和WEBSERVICE两种方式，其接口规范参见下表：序号字段名称数据类型及长度必填中文说明样例及说明1IdInteger是Key自动生成的ID2itemId字符串长度：255个字符是在应用系统待办ID第三方系统待办ID2Docid字符串否DocumentidDOMINO文档的ID3Title字符串长度：255个字符是标题经营分析8月份报表4link字符串长度：500个字符是待办访问链接//xxx.do5category字符串长度：100个字符是分类通知公告一般为流程名称6Pubdate字符串是待办数据生成日期2008-09-2210:00:00，格式必须符合yyyy-mm-ddhh:mi:ss7comments字符串是紧急度数字0-9数字越大紧急度越高8appId字符串长度：100个字符是应用IDeg:erp@jx.cmcc(由待办中心建立、分配)9waitStatus字符串长度：255个字符是待办状态经理审核10Uid字符串是用户的uid比如：lisong待办人UID，必须符合统一用户管理系统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字符串否校验具体说明请参见《EMIS3.0统一待办集成规范V3.doc》任务结束统一流程接收管理平台统一任务中心的任务更新请求。任务推送接口采用HTTP和WEBSERVICE两种方式，其接口规范参见上述任务推送参数规范表。具体说明请参见《EMIS3.0统一待办集成规范V3.doc》任务查询在各业务子系统中同样存在任务查询，其任务查询来自于统一流程管理平台的任务查询接口，与统一任务中心不产生交互。它与统一任务中心的任务在数据上是对等的关系，要保持数据一致，但它们是并列的两套任务系统，存在于两套不同的系统中，所以它们实质上是并列的、数据一致的关系。与统一用户中心整合规范--liuwei与统一用户中心关系关系图 整合要点统一用户角色统一流程管理平台会通过同步统一用户中心的数据和在平台中建立角色来搭建整体的流程平台的用户数据，如果使用流程平台的话，不允许在各子系统中维护自己的角色，须使用统一的组织机构接口实现。组织机构接口统一流程管理平台实现了统一的组织机构接口，其组织数据、人员数据来自于同步后的数据和结合平台建设的角色数据。如果以后要更改整个组织机构，只需要改统一流程平台的组织机构接口实现。与统一用户中心交互数据同步统一流程管理平台通过数据同步接口同统一用户中心进行用户数据的交互，数据的同步采取实时同步策略。因为统一用户中心只有组织数据和人员数据，所以同步到统一流程管理平台的数据也只有组织数据和人员数据，而角色数据是在统一流程管理平台上维护的，那么新同步过来的数据也需要管理员后续将角色数据加上。与业务系统整合规范--zhouht需要细化和量化。与业务系统关系 统一流程管理平台与业务系统之间的关系如下图所示：定位及分工业务系统 业务系统需要完成的工作：业务信息展示、业务信息维护、调用平台接口驱动流程、提供业务服务接口等功能。统一流程管理平台统一流程管理平台提供：流程的调度，任务的分配，流程服务接口等。整合要点部署形态业务流程应用与统一流程管理平台分布式部署，两者之间松耦合。统一流程管理平台提供给多个业务系统同时使用，不能因为某个业务系统的故障造成整个MSS域业务流程应用故障。组织人员信息业务流程类应用一个典型特点就是人工交互，在系统建设过程中组织机构信息数据处理是一个重要环节。统一流程管理平台已经提供了与统一用户中心的交互能力，不允许业务系统直接连接到统一用户中心，不推荐业务系统同步方式备份组织人员数据。角色信息组织人员信息统一，角色信息各异是业务流程类应用另一个典型特点。角色和系统的业务关联度较高，各个系统都有各自独立的角色信息。统一流程管理平台提供角色维护能力，角色具有系统属性，系统间角色不冲突。不允许业务系统直接维护角色信息，方便对整个MSS域系统角色的管理，为抽取公共角色（岗位）提供基础。BPM引擎接口统一流程管理平台对BPM引擎提供的接口进行了封装和处理，比如接口调用缓存等优化操作。业务系统通过平台提供的接口驱动BPM引擎，不允许业务系统直接访问BPM引擎接口和服务。组件规范组件抽取是针对开发商同统一流程平台进行对接时，根据自身调用的需要进行的相关功能的封装及实现。为规范开发商的组件的实现，需要开发商遵循统一的组件抽取开发规范，为系统的调用及维护提供制度上的保证。组件抽取规范组件是为实现一定功能，并可以被流程引擎调用的逻辑实现。为能更好的管理、调用这些组件，抽取组件时需要遵循一定的规范，通过标准化的流程，实现组件抽取。明确组件实现功能及流程引擎的边界，减少不必要的流程引擎的负担。详细描述组件实现的功能，调用方式。明确在什么样的情况下使用此组件定义组件的输入、输出，并给出每个参数具体的含义说明给出组件的名称，需要能够做到见名之意对组件出现的异常情况给予说明并对出现异常时采取的动作将需要抽取组件的信息填入到相应的表中，使得流程引擎在配置时能够按照需求进行配置。组件抽取所用到的表信息：组件功能表组件功能描述使用范围调用方式Webservice方式、本地调用方式等组件名称组件参数参数1参数2参数说明说明2异常处理说明组件开发规范流程功能组件开发规范 开发商在进行流程组件的二次开发时，首先是根据组件抽取的结果进行组件的开发。并根据组件信息表完善功能组件的相关信息，并填写组件实现表，提供后续开发人员使用。分析抽取的功能组件功能，明确组件实现目标按照组件实现的功能，定义组件的报名及组件名，组件的报名及组件名需要按照应用开发规范进行命名。分析输入输出参数，并对输入输出参数进行定义，参数的取名按照有明确意义的英文字母来取名。参数的类型建议采用简单类型（string、int等，不建议采用复杂类型）对组件的异常信息进行规划，根据异常处理说明，决定对异常采取封装并抛到调用的上层还是在该组件内处理掉。对于不影响程序运行，并不会产生后续效应的异常，在组件内处理，而当此异常对后续的操作会产生影响，则对此异常进行封装，并将此异常传递到调用层，由调用层进行处理。根据组件功能信息表中的调用方式，将开发的组件发布成java方法还是将其发布成服务。如果是本地java方法，则提供调用的完整类名及方法名、参数等信息，否则，提供调用服务的相关信息。组件功能实现表组件功能实现组件功能描述使用范围调用方式Webservice方式、本地调用方式等调用方式服务调用本地方法调用wsdl地址完整类名url地址方法名组件参数参数1参数2参数N参数说明说明2说明N异常处理说明接口类组件开发规范流程功能组件开发规范已包含接口类组件开发规范，请参考流程功能组件开发规范复合功能组件开发规范复合组件功能是根据项目需要，为实现系统大粒度的功能，由开发商开发的可能包含业务与流程引擎API的结合、流程引擎API的组合实现的业务功能。这些功能的实现有利于开发人员更好使用流程引擎。复合功能的组件梳理与开发规范，请参考流程功能组件开发规范公共流程组件开发规范公共流程组件命名规则公共组件命名时，首先需要遵循见名之意，其次，对组件的包名也需要有一定的规范，方便后续查找、追踪组件提供者，为后续组件的维护及持续优化提供便利。公共流程组件分为两个部分，一个部分是流程定义部分，另外一个是组件部分，对这两种情况分别说明公共流程定义部分公共流程的流程定义名遵循的规则：com.cmccjx.public.workflow.系统名.流程名。业务操作中的命名规范遵循应用开发规范的命名规范公共组件部分开发公共组件时，需要对包名进行限制。包名一般以com.cmccjx.打头，其次是公司英文或拼音，如果过程取公司首字母（如：primeton）；后面接的是public.workflow，接着是系统的名称(如：oa)，最后是系统的模块名称。包名都采用小写字母。具体包名如下显示。com.cmccj.公司名.public.workflow.系统名.模块名。如：com.cmccjx.primeton.public.workflow.workflowinstmgr定义流程组件的名称，名称的命名需要有业务含义，如结束工作项的命名：finishWorkItme。采用骆驼表示法来表示。公共流程组件发布目录所有公共流程都需要发布到“默认的业务目录”中。公共流程组件描述清单流程组件在提交部署时，需要提供如下的详细信息流程定义信息。描述流程所实现的流程详细信息，使用目的。自动活动的配置信息清单人工活动的配置清单连线的配置信息在流程定义中所用到的业务资源信息的配置信息，包括业务资源的目录等信息。组件管理规范--ok参见《管理规范→组件管理规范》章节。组件复用规范组件能够复用的标准是在流程运行过程中，该流程组件被调用次数在一段时间之内大大超过其他组件的调用次数，可以将此组件作为候选可复用的流程组件，经过相关的评审，从候选列表中选出最终作为可复用的组件，并对类似功能的组件进行归并，对其结构进行规划，对其性能进行优化，使得该流程组件最终成为高可用性、高性能的组件。为实现这个目标，需要遵循以下规范筛选规范候选流程组件是通过统计方式分析得出的其被调用次数是在组件调用中占比较高（平均调用次数的3倍以上）。具有通用性的特征能够容易整合其他类似功能规划设计复用组件的功能需要具有通用性确定调用该组件的前置条件及后置条件规划接口参数，且接口参数意义明显接口方式明确，并提供完整的接口说明实现优化。根据java代码优化原则进行代码优化发布规范提供可供使用的组件包提供可复用组件的功能说明提供完善的接口说明，包括组件调用的前置条件及后置条件应用开发规范命名规范--zhouht在现有的业务流程系统中，流程引擎供一个系统单独使用，当多个系统共用同一个BPM引擎时，为了避免混淆，命名变得非常重要。下面列举部分流程相关部件命名实例，供业务系统参考（征求意见稿）。系统编码规范要点各个系统按照业务含义定义2~4个英文字母的系统编码。规范说明接入到统一流程管理平台的各个业务系统，为了便于区分，各个系统按照业务含义定义2~4个英文字母的系统编码。比如：合同管理系统（pm）、办公自动化（oa）等。流程定义编码规范要点流程定义编码命名必须均为小写。通用格式如下xxxxxx(cmccjx).xxx(projectname).xxx(modulename).xxx(flowname)规范说明流程定义编码是流程定义模板唯一编码，在平台中必须保持唯一。流程定义编码命名必须均为小写。名词需要使用英文说明功能，不能推荐采用拼音。具体示例如下：通用格式如下xxxxxx(cmccjx).xxx(projectname).xxx(modulename).xxx(flowname)以cmccjx.ehr.vacation.annualleave为例： 第一段jxcc代表江西移动。 第二段ehr为项目名称“人力资源系统”。 第三段vacation为项目模块“假期管理”。 第四段annualleave为流程定义名词“年假申请流程”。流程实例名称规范要点流程实例名称必须包含业务信息。规范说明在用户待办任务列表中，首先看到的是流程实例和活动实例名称。其中为了让用户在待办任务列表中可以直观的了解任务信息，流程实例名称必须包含业务信息，具体需要包含哪些关键业务信息需要在需求调研时确认。比如年假申请流程，当流程实例化的时候，命名为“财务部张三年假申请流程”或者是“财务部张三2010年年假申请流程”。这样处理人员不用点击进入待办任务信息页面即可了解待办任务的大概信息。如果全部命名为“年假申请流程”，则无法区分流程实例之间的差异。活动定义名称规范要点活动定义名称必须包含业务信息，在一个流程模板中，流程定义名称必须能够区分开来。规范说明假设在如下所示的流程图中，环节2和环节4都是部门领导审批，如果不加区分，在部门领导处理时，在待办任务列表中无法直观的了解流程所处环节。 环节2和环节4分别命名为“部门领导初审”、“部门领导复审”之后，活动定义名词可以直接区分两个环节的差异。业务操作命名规范要点活动定义名称必须包含业务信息，在一个流程模板中，流程定义名称必须能够区分开来。规范说明假设在如下所示的流程图中，环节2和环节4都是部门领导审批，如果不加区分，在部门领导处理时，在待办任务列表中无法直观的了解流程所处环节。规则命名规范要点规则分为参与者规则和分支规则，在统一流程管理平台中规则命名需要加上系统编码前缀。规范说明当规则集中到统一管理平台中之后，需要区分规则的系统属性。便于区分不同业务系统的规则。比如：人力资源系统中请假审批分支规则，当部门经理请假时，公司副总审批；部门员工请假时部门员工审批。该分支规则命名为：“ehr-请假流程-审批人规则”。流程梳理规范--liuwei描述在流程梳理的过程中要执行的规范，填写的表单。组件使用--liuwei描述如何使用组件标签类组件使用流程功能类组件使用 见《接口规范→接口分类描述→统一流程管理平台接口功能分类》章节。流程设计规范--zhouht是否需要子流程规范要点：在业务流程定义中，一组相关的活动组，可以设计成一个子流程；引入子流程的概念用于表示按照递归方式对流程在级别上做更深入的优化，直至到达合适的组成部分。是否使用子流程主要从下面几个指标衡量：企业管理的模式是否需要精细：如财务部门多级审批环节，可以是一个审批环节，也可以是在财务部门经过一组相关活动组成的活动组审批。当然，业务流程管理优化有很多工作要做，但是不是本文重点，这里就不深入讨论。使用子流程是否可以使流程图表达简洁清晰：在某些业务流程中环节较多，如果所有的活动放在同一个层次，会使得流程图拓扑结构复杂而不容易识别。对业务功能相近或者相关的活动组适当的使用子流程，可以使整个业务流程表达清晰简单。这种情况下推荐使用子流程。一组活动被多处重用：在整个业务系统中，如果某些相近或者相关的活动组在多个流程中可以重用，推荐使用子流程。是否有子流程嵌套：在业务系统中如果有子流程递归调用的情况，建议使用子流程。【应用场景——活动组复用举例】：在REF_Ref222986124\r\h图3-2所示中的应用场景中，客服部门会受理不同产品的申办请求，不同的产品在IT支撑部门处理过程都是一样的：首先由“IT支撑部审核”，如果是非标准业务转由“IT支撑部经理审核”，最后由IT支撑人员做相应的操作。其他部门则根据产品的不同走不同的审批流程。使用子流程的设计方案是可以将“IT支撑部处理”相关的3个人工活动设计成所示的子流程，REF_Ref222986124\r\h图3-2的需求就可以设计成REF_Ref222986146\r\h图3-4的方案。这样“IT支撑部处理”子流程就可以在多个流程中使用，将来IT支撑部处理过程发生变化时，仅仅修改子流程即可。子流程调用层级设计规范要点子流程嵌套调用层级建议为3级。规范说明主流程调用子流程，子流程可以调用另一个子流程，如此递归技术上来讲，子流程调用的层级不受限制。在实际项目中，如果子流程层级太深，流程返回时执行速度会有影响；另外，太深的流程调用不利于流程监控图展示。根据实际项目实践，推荐子流程调用层级为3层。界面规范--zhouht接口规范--liuwei接口服务方式流程应用与统一流程管理平台主要采用三种服务方式：UDDI服务方式和普通WebService服务方式、HTTP会话服务方式。UDDI服务：统一描述、发现和集成（UDDI）规范定义发布和发现有关WebService的信息的方法。业务系统调用统一流程管理平台提供的服务都是采用UDDI的服务方式普通WEBSERVICE：非采用UDDI服务方式的调用，通常指采用传统WebService框架（如：Xfire，Axis2）发布和调用的服务。统一流程管理平台调用业务系统的服务方式可采用普通WebService方式或HTTP会话服务方式。引用系统根据具体业务需求灵活选择。HTTP会话服务：HTTPURL地址直接提供的服务，统一流程管理平台调用业务系统的服务和BPM流程引擎调用的服务会采用HTTP会话服务。引用系统根据具体业务需求灵活选择。接口通讯方式接口基本采用了同步请求/应答方式、异步请求/应答方式（暂不考虑会话方式、可靠消息传输方式、文件传输等通讯方式）。服务调度时可选择服务方式是同步请求/应答方式还是异步请求/应答方式。在接口通讯中，基于交易的事务处理方式可采用以下几种通讯方式：同步请求/应答方式：接口调用方向接口提供方发送服务请求，接口调用方阻塞等待接口提供方返回处理结果。异步请求/应答方式：接口调用方向接口提供方发送服务请求，与同步方式不同的是，在此方式下，接口提供方处理请求时，接口调用方继续运行；当接口提供方处理结束时返回处理结果。接口完整性管理根据现有应用系统的特点，接口都是采用基于交易的事务处理机制实现，每个接口在对外提供服务的时候应该保证事务的完整，一个接口里包含的所有业务都在一个事务内。在服务调用出错后事务全部回滚，以便业务能对再次对其进行处理以确保流程的顺利流转。调用方在批量调用接口的时候，须考虑事务的完整性和延续性，确保出错后能多次调用以完成整个事务，来保障整个业务事务的统一。接口安全管理为避免系统间非正常访问，保证接口交互信息的可用性、完整性和保密性。接口访问须对接口本身进行安全访问，须在服务调用的客户端和服务端进行安全配置及安全验证。业务系统提供服务时须在服务内部进行IP地址、密码校验等安全限制，非正常的系统访问予以拒绝，同时每次调用记录服务调用日志。如果业务系统提供的是HTTP服务，则须进行单点认证或进行相关授权。流程管理平台提供的服务在提供之前需进行服务端与客户端密钥的安全配置，非安全访问予以拒绝。接口分类描述业务系统服务接口描述 业务系统与统一流程管理平台相互调用的接口主要包括业务系统服务接口和统一流程管理平台接口两大类。其中业务系统服务接口指的是调用方为统一流程管理平台，服务方为业务系统的接口。主要是指流程活动为服务方式（如：自动活动或webservice活动）时，统一流程管理平台会调用业务系统中的业务逻辑服务。业务系统接口规范业务系统接口适用范围业务系统发布的服务接口主要提供给流程管理平台统一调用，来完成业务的相关实现。通常是在流程中的自动活动和WebService活动中调用。提供的服务需满足接口的高并发性和稳定性要求，在流程设计时可根据具体的业务和接口的执行情况选择在自动活动中调用还是在WebService活动中调用。业务系统接口发布规则业务系统发布的服务接口发布的方式主要为两种方式：一种是WebService接口，一种是HTTP接口。通常WebService服务在应用系统中以WebService工具（如：xfire\axis2）暴露成webservice，接口的输入输出参数应可序列化。HTTP服务直接在应用中跟随应用启动发布，其接口的输入输出参数为文本，并且文本尽量避免适用中文和特殊符号。业务系统接口管理规则业务系统提供的业务接口在发布和管理时应在系统建设时遵循一定的规范，如发布时填写具体的接口说明，功能说明，输入输出参数说明，被哪些流程调用等信息。发布后要能实现可预见、可管理的原则，在对接口进行维护的过程中和执行后要能清晰的查询相关接口的在用信息、调用频次、资源占用等信息，以便于业务系统查知提供了哪些服务接口及监控其接口的运行情况以及对应用系统整体的影响。接口发布时填写模板可参见《业务系统接口管理模板》。业务系统接口异常规则在统一流程管理平台调用业务系统接口的时候，会出现不同的异常情况，包括网络异常、业务异常等，对于调用方的直接影响是导致流程的运转不正常。在流程定义时会设置服务调用时的异常处理策略，在策略为“回滚异常”和“进入异常状态”的情况下，此时流程停在服务调用的活动上面，所以在业务实现上需要对其进行处理。处理的规则为如下建议：对于复杂的业务流程，进行人工干预，实行业务重做。在业务端实现后台处理进程，自动查询处理异常服务，然后自动调用其服务并完成相关活动以驱动流程。统一流程管理平台调用规范接口调用方式自动活动调用自动活动的调用即可调用业务系统的WebService服务又可调用HTTP服务。在自动活动中绑定的业务操作中输入统一的方法名和相关的参数。WebService活动调用WebService活动的调用只能调用业务系统的WebService服务，在流程定义时配置相关的WebService信息，包括WSDL地址，SOAPHEAD信息，SOAPBODY信息，相关参数，调用方式等。接口调用规则接口的调用分为WebService活动调用和自动活动调用，WebService活动只能调用业务系统WebService服务，如果想调用业务系统的HTTP服务，须使用自动活动调用。其调用有同步异步之分，对于不需要立即返回结果的接口调用或者是实时性响应要求高的接口调用采用异步方式，否则为同步方式。接口异常处理统一流程管理平台调用接口出现异常后，须采取相应的处理措施，在流程定义阶段须指明其异常处理的策略，分为如下处理策略：回滚异常 出错后，直接回滚异常，回滚到上个事务分割点。忽略异常 出错后，忽略异常，活动完成，继续执行后继动作。进入异常状态，等待人工干预 出错后，进入异常状态不继续流转。自动执行单步回退，活动终止出错后，直接执行单步回退，回退到上个节点，当前自动活动终止。自动路由到其它活动，活动终止 出错后，直接根据配置跳转到下一个活动，当前自动活动终止。自动执行规则逻辑。出错后，自动执行设定的一个"规则逻辑"，当规则逻辑执行完后，活动结束，继续执行后继活动。统一流程管理平台流程组件接口描述 主要是指统一流程管理平台提供的流程组件服务。调用方为业务系统，服务方为统一流程管理平台。这些服务以远程WebService的方式提供，通过统一流程管理平台提供的客户端在业务系统中远程调用。统一流程管理平台接口规范平台接口适用范围统一流程管理平台发布的服务接口主要提供给各业务子系统统一调用，来完成流程的相关实现。凡是流程的相关组件都使用统一流程管理平台提供的服务。平台接口发布规则统一流程管理平台提供的服务接口发布的方式为UDDI服务，它不是真正意义上的WebService，是一种http服务。对应用系统来说，它是以UDDI的方式，通过统一流程管理平台的客户端以API的方式调用的服务接口。平台接口管理规则统一流程管理平台接口在发布和管理时按照组件化、服务化的规范来提供，由统一流程管理平台结合BPM引擎统一来实现和发布。如果业务系统发现平台有不满足的接口，须按照《组件管理规范》按照组件管理流程提交接口申请，来实现平台接口的管理和维护。考虑兼容性，原则上平台接口是不能修改和删除的，只能新增相关接口。平台接口异常规则统一流程管理平台提供的接口在调用时会抛出异常，并将异常返回给接口的调用方，业务系统根据返回的异常结合业务场景来处理各自的业务。业务调用规范调用方式业务系统调用统一流程平台提供的服务接口均采用UDDI服务调用的方式，统一流程管理平台已经做好了封装，同时提供了客户端代码，其代码编写方式与传统的javaapi调用方式相同。事务完整性规则在实际业务场景中，会存在业务逻辑与流程接口互相调用的情况，包括：业务系统只调用一个流程接口对于此种业务调用，直接使用统一流程管理平台客户端直接调用接口。业务系统只调用多个流程接口对于此种业务调用，只能是一个修改类接口加上其他查询类接口的调用，为保障事务统一，不允许多个修改类接口的同时调用。目前统一流程管理平台已将常用的多个修改类同时调用的接口抽取成大的接口供业务系统调用，同时在业务设计上尽力避免多个修改类接口的同时调用。业务系统先调用业务逻辑再调用一个流程接口此种调用的关键是既调用了业务逻辑，又调用了修改类流程接口，对于此种业务调用，应在业务系统调用中先调用业务逻辑，再调用流程接口，通过捕捉调用流程接口的成功信息或出错信息来提交或回滚业务事务，以达到事务的完整统一。业务系统先调用业务逻辑再调用多个流程接口此种调用的关键是既调用了业务逻辑，又调用了多个修改类流程接口，应结合场景2和场景3来实现此种调用。即首先将多个流程接口抽取为场景2描述的一个修改类流程接口，然后按照场景3描述的，在业务系统调用中先调用业务逻辑，再调用流程接口，通过捕捉调用流程接口的成功信息或出错信息来提交或回滚业务事务，以达到事务的完整统一。如果不能按照场景2将多个修改类流程接口调用抽取成一个流程接口调用，需要在每一次接口调用时采用流程补偿的机制，即在业务端实现反交易调用来确保业务的统一实现。操作流程图如下图所示：业务系统调用业务逻辑与调用流程接口存在混合调用混合调用即调用业务逻辑后再调用流程接口，然后根据结果再次调用业务逻辑，调用后继续调用流程接口的无序、混合型的调用。对于此种业务调用，在业务设计时尽力避免，以减少系统存在此种情况的可能性。此种调用采取的调用策略为：业务上的逻辑调用通过业务系统本身实现事务控制；在流程接口调用时，如果调用异常，同样采取采用流程补偿的机制，即在业务端实现反交易调用来确保业务的统一实现。操作流程图如下图所示：接口异常处理业务系统在调用统一流程管理平台的接口时，由于统一流程平台已将异常直接抛出给调用一方，所以在业务系统中可以直接捕获异常。通常的处理规则须与事务完整性结合在一起，须在结合异常处理的基础上做到事务完整性控制，具体参见《事务完整性规则》章节。统一流程管理平台接口功能分类流程实例类接口【功能定义】流程实例管理、查询接口。【功能描述】提供了诸如根据流程实例更换模板、

改变一个流程实例的状态、创建并启动工作流实例、删除流程实例、批量删除流程实例、挂起流程实例、终止流程实例、查询满足条件的后继活动、查询流程实例的详细信息等相关功能。流程定义查询类接口【功能定义】业务流程定义查询接口。【功能描述】提供了业务流程管理中需要使用的查询接口，可以查询业务流程实体、活动定义实体、连线实体、流程包列表、流程目录、活动已经定义的参与者等信息。诸如获取某业务流程中某个活动定义的基本信息、获得某业务流程中某活动定义设置在“组织机构与角色”里的参与者、查询某业务流程中的所有活动定义、查询某业务流程中某个活动定义的所有直接后继活动、根据业务流程名称，和活动定义ID查询活动的后继活动连线信息、查询某业务流程中某个活动定义的所有直接前驱活动、查询某业务目录下的所有新版本业务流程等功能。流程发布类接口【功能定义】流程定义部署、发布和取消发布管理接口【功能描述】提供了诸如部署流程定义、根据流程定义ID删除流程定义、删除各版本具有相同名称的流程定义、发布某流程定义模板的指定版本、取消某流程定义的发布等功能。工作任务查询类接口【功能定义】工作项查询接口。【功能描述】提供了诸如结合业务表的工作任务查询，查询指定用户领取和待执行的工作任务、查询指定人员委托出去并且已经完成的工作项信息、查询指定人员完成的工作项、查询指定人员已经完成的工作项信息、查询扩展工作项的业务属性等功能。可以通过调用这个接口的方法来查看用户的工作列表，包含了工作代理代办的查询。活动实例类接口【功能定义】活动实例相关操作接口。【功能描述】提供了对活动实例进行查询，如查询指定流程下的活动实例；也可以对活动实例进行多种操作，比如完成，重启，删除等功能。诸如激活活动、执行活动实例ID对应的回退动作、完成活动实例但不终止正在运行的工作项、完成活动实例、完成活动实例,并设置相关数据、重新启动某个活动实例、查询活动实例的状态、查询后继活动实例、查询某个活动实例的所有前驱实例等功能。活动参与者指派类接口【功能定义】指派活动后继活动参与者接口。【功能描述】提供了诸如指派后继活动的参与者、判断当前工作项操作是否需要为后继活动指派参与者、查询某个活动需要指派参与者的后继活动列表等功能。代理类接口【功能定义】代理管理接口。【功能描述】提供了包括所有代理相关的操作如创建代理关系，修改代理关系修改代理人范围、删除代理关系等功能。诸如增加委托人的候选人范围、清理某个代理关系的代理项信息、创建代理关系、批量删除多个代理关系、修改指定的代理关系、查询所有代理关系等功能。回退类接口【功能定义】工作流活动实例回退管理接口。【功能描述】提供了提供查询当前活动实例之前运行时经过的活动定义，以及回退活动等功能。诸如根据某策略回退到某活动、查询当前实例到目标活动定义之间所有运行时经过的活动定义等功能。自由流类接口【功能定义】流程实例管理、查询接口。提供了诸如【功能描述】流程相关数据管理类接口【功能定义】工作流相关数据管理接口。【功能描述】提供了获得相关数据中指定路径下的值、批量获得相关数据中指定路径下的值、根据流程实例ID，将对象值放到相关数据区、根据流程实例ID，批量设置相关数据中指定路径下的值等功能。具体接口列表参见《附录：流程接口列表》。管理规范平台使用规范--zhouht开发流程申请接入开发包下载流程开发流程部署流程监控流程优化组件管理规范组件管理有专门的组件维护者岗位，负责组件的组件审核、入库、发布、优化改造等工作。该岗位应长期存在，不附属于某个项目。负责整个组件体系的建设，包括组件的梳理，组件的开发提供，组件的维护，组件的撤销等。组件维护者岗位制定和完善组件的使用规范，并定期发布最新的组件版本和更新内容说明。组件只有组件维护者岗位有权限修改，但允许各项目组查看和使用。组件管理生命周期组件的管理过程是知识不断积累，组件不断成长的良性循环过程。一个典型的组件成长过程如下图所示：组件管理的生命周期由组件开发、组件评审、组件发布、组件使用、组件维护几个阶段组成，如下图所示：图STYLEREF1\s22组件管理的生命周期参与者及职责总览图-参与者及职责总览参与者角色组件维护者组件维护者是维护组件的主要责任人，组件的规划、入库、发布、反馈信息收集、改进、升级、推广、停用等任务均由组件维护者牵头负责，同时组件维护者也可以作为组件提供者。通常由对EOS平台比较熟悉的技术人员担任。组件评审者组件评审者是组件质量的主要责任人，组件的评审由组件评审者牵头负责。通常由熟悉EOS和组件管理规范的人员担任。组件提供者组件提供者为组件提供组件，组件的入库任务由组件提供者发起。此外，组件在被使用的过程中，有需要改进、升级的原则上由组件维护者完成，但由于组件提供者对所提供的组件比较熟悉，也可以被组件维护者借调过来进行组件的改进、升级工作。组件使用者组件使用者使用组件提供的组件，完成某种需求。组件使用者还有一个重要的任务就是对其在项目中正式用的组件必需进行反馈，以帮助组件维护者完善组件，使组件中的组件更加健壮，可复用度更高，从而提升整个组件的质量。如果项目中使用了组件中的组件没有进行反馈，则针对该组件有新版本时不对该项目组进行通知。管理规范入库申请参与者组件提供者任务描述1、编写组件，组件提供者积累知识，按照组件的抽取原则编写组件；2、准备入库，按照以下目录进行文档文件存放，并打包为rar压缩文件；（1）文档文件存放目录结构01_入库申请单02_部署文件（包括组件JAR、第三方JAR、数据库脚本、使用手册等文件）03_源代码04_Javadoc文件05_开发文档06_组件使用说明07_应用案例说明（2）压缩文件命名规范：组件名_日期＋_版本；（3）压缩包结构参见附录组件压缩包结构。3、组件提供者提交“提请入库组件压缩包”至“组件\01_入库申请”，并对组件维护者进行邮件通知，其中邮件标题格式为“组件入库申请提醒：压缩文件名”。产出物1、组件入库申请单；2、提请入库组件压缩包。组件评审参与者组件评审者任务描述组件评审者收到“组件提请评审提醒”邮件；对组件进行测试，并检查组件是否符合规范；提交评审意见至“组件库\03_组件评审\02_评审意见”。其中，评审意见文档命名规则为：压缩文件名＋_评审者姓名；若评审通过，组件库维护者从“组件库\03_组件评审