统一流程支撑平台与服务共享平台项目

1、统一流程支撑和服务共享平台项目研究成果 统一流程支撑和服务共享平台项目研究成果2011年12月1.业务概述31.1.原有业务方案和问题分析31.2.业务实现目标概述41.3.建设范围和方式41.4.业务主要功能51.4.1.业务功能总结51.4.2.本期业务功能实现52.业务优化技术实现方案82.1.验证了统一流程支撑平台的关键技术点82.2.流程和集成平台功能架构102.2.1.流程运行引擎112.2.2.服务总线子系统132.2.3.服务管控子系统142.2.4.应用适配子系统152.2.5.数据层152.3.流程和集成平台运行架构152.3.1.平台运行物理模型162.3.2.平台物理部

2、署架构172.3.3.软件产品配置清单193.业务优化效果203.1.2011年项目完成情况203.2.项目后期展望211. 业务概述1.1. 原有业务方案和问题分析黑龙江移动公司MSS域里众多系统各自采用独立的流程引擎，系统之间很难进行相互融合，但实际业务中又存在大量共享数据、流程的调用和交互触发的需求。示意如下：主要存在问题：1、系统复杂：现有MSS域里存在众多品牌和类型的流程引擎，为流程整合带来巨大困难；各个系统之间存在大量的数据、流程交互需求。2、长流程被阻隔：各个系统流程是分散的、尚未实现自动衔接，跨部门、跨应用的“长流程”极难实现，无法支撑端到端的流程。3、管理要素未对象化：很多关

3、键的管理要素尚以附件的形式存在，在整个流程流转过程中需要重复多次的录入，数据不统一，尚未实现对象化、电子化管理，无法做到全程监控。4、公文代替流程系统：现有管理信息系统都是依托公文系统进行流转，而非标准化的流程管理，很难对整体流程进行统一的控制、管理和监控。为此，需要建设企业信息化统一流程集成平台，提高系统间的交互效率，流程平台的位置如下所示： 1.2. 业务实现目标概述在黑龙江移动企业信息化领域流程与服务集成平台的业务功能目标是：1. 建设企业信息化域内的统一流程集成平台，整合现有MSS域里存在的众多品牌和类型的流程引擎，实现跨系统的流程整合，提高系统间的交互效率；2. 自动衔接各个系统的分

4、散的流程，支持更多跨部门、跨应用的“端到端的长流程”；3. 通过流程整合和梳理的过程，逐步实现管理要素在企业化级别的对象化管理，建立黑龙江移动企业信息化领域的组件资产库；4. 引人更多的流程管理机制，管理人员能够对企业信息化领域的所有流程进行统一的控制、管理和监控，从而优化流程，更好的服务移动内部用户；5. 改变现有管理信息系统依托公文系统进行流程流转的不足，逐步把现有管信系统的适合流程实现的公务系统过渡到统一的流程集成平台上来；6. 通过建设黑龙江移动企业信息化领域内的统一的服务总线平台，实现管理信息系统和其他业务系统的在流程和数据的全面集成，有效地支撑部门之间的协同协作；7. 通过在管理信

5、息域内流程平台的建设，积极探索流程平台的多租户可行性，为未来流程平台扩展到其他领域做好准备；1.3. 建设范围和方式本期项目的主要为黑龙江移动企业信息化领域搭建流程与服务集成平台，同时在平台搭建完成后，通过服务方式实现多个循序渐进的流程项目。项目建设方式采取分阶段建设模式，渐进式实施。1.4. 业务主要功能1.4.1. 业务功能总结n 管理员和用户可以根据实际的业务需求，快速在平台上部署新的业务流程，或者根据需要来调整和改变在平台上的流程，达到动态服务业务需求的目标；n 使用统一的平台对全部的流程整合需求进行业务流程处理，使用统一的服务器来部署业务流程，提供统一的流程管理手段和界面实现对全部流

6、程的统一管控，达到简化管理、统一服务目的。n 通过滚动式的业务流程实现，更多的沉淀出面向管信领域的通用流程或者服务，建立管信领域更多可重用的流程和组件资产库，降低开发和运维的成本；n 实现管理信息系统和其他业务系统的在流程和数据的全面集成，有效地支撑部门之间的协同协作，拓展管理信息系统服务的深度和广度；n 管理信息系统可以通过服务集成平台来集成更多的黑龙江移动的业务系统，实现业务系统数据在管理信息系统的深入展现和挖掘，为决策和管理人员提供更有价值的信息数据；n 改变现有管理信息系统依赖公文进行日常业务处理的问题，改造公文类应用，把公文类应用逐步转型到电子流程类应用，从而实现能够以一套工作流执行

7、引擎支撑多工作流实例（例如公文审批流）的定义、运行和监控管理的目的;n 整合现有管理信息系统的各种类型的流程平台，改变现有系统存在很多不同流程引擎的复杂状况，从而简化管理和应用部署，打破技术壁垒，实现流程平台的统一化建设；1.4.2. 本期业务功能实现黑龙江移动企业信息化领域流程与服务集成平台在2011年底的实现目标包括以下几点：n 实现OA与经分系统（营销管理系统）的跨域流程整合。改变现有经分系统生成的营销策划方案需要领导登录经分系统进行审批的现状，通过把经分系统生成的营销策划方案的审批环节延伸到OA系统中进行审批实现，初步探索如何使用流程平台实现不同业务领域的流程整合。以营销管理系统中的省

8、公司营销审批流程(如下图所示)为例，其流程中的审批环节需要相关部门领导登录到营销管理系统进行审批。类似的流程还有许多，需要相关领导及业务人员分别登录不同系统审批、处理，各个系统界面风格不一致、操作规程各异，无疑增加了使用上的不便，降低了工作效率。 整合后的系统由流程集成平台统一驱动业务流程的流转，营销管理系统只需调用流程集成平台的流程服务，流程平台会将生产审批代办展示在OA系统中，完成了营销管理系统与OA之间端到端的流程整合，从而大大提高了流程的审批效率。同时，系统的整合和改造尽可能多地利用了既有OA资产，体现了SOA强调复用的理念，从长远看将有助于降低IT总体成本。 n SCM（供应链）接口

9、的标准化服务实现改变供应链系统对外服务的接口私有化的问题，改造现有SCM系统对外Webservice接口，将SCM对外接口标准化成全系统内可以重用的服务，并且集成到流程与服务集成平台，探索现有系统如何基于ESB技术实现不同系统的接口标准化，达到全业务系统内的服务共享。n 用户管理系统的通用功能的标准化服务抽离及实现。通过标准化的手段或者平台实现用户管理系统模块的标准化服务的统一的注册、管理、监控和发布，以便于其他系统可以以标准化、规范化的模式使用管理信息系统的功能，从而实现管理信息系统功能模块的复用。在实现管理信息系统功能模块的标准化服务封装的过程中，初步建立系统交互的标准化模式和数据交互规范

10、； 服务的注册及管理实现采用IBM的WSRR来实现，其注册界面如下图所示。2. 业务优化技术实现方案2.1. 验证了统一流程支撑平台的关键技术点1、通过对MSS域业务流程的梳理，发现了业务服务组件、建立了服务规约，确立了长期服务治理的标准 2、利用服务总线平台，实现了多系统业务服务的接入，有效地支撑了部门间、系统间的协作 3、利用业务流程管理平台，实现了跨系统、跨业务部门的端到端的流程管理(流程穿越)，统一了流程引擎4、利用SOA理念，进行业务服务和流程的梳理5、IBM SOMA方法论是实现服务化、流程化改造的可行手段6、流程穿越7、业务流程引擎利用服务总线实现MSS域各系统的服务编排8、利用

11、ESB实现了MSS各系统间的信息传递、服务调用 ESB 提供了: 路由能力 通信协议独立性 格式转换独立性 事件处理 2.2. 流程和集成平台功能架构黑龙江移动流程和服务集成平台的功能构成遵循组件化和松耦合的原则，集成平台内部包含流程运行引擎、服务管控子系统、服务总线子系统、应用适配子系统、数据层，每个子系统又包含若干业务功能和技术功能组件，建议的系统总体逻辑架构如下图所示：以下就每一个子系统的功能做具体说明：2.2.1. 流程运行引擎流程运行引擎是实现流程和服务集成平台的核心平台，这个流程引擎是符合业界BPEL流程规范的标准的BPM平台，所有开发完成的业务流程都会部署在这个流程引擎上运行，并

12、且管理员或者用户可以通过这个流程平台实现流程的建模、模拟和监控，从而实现业务流程的统一运行和管理。流程运行引擎包括几个主要的功能部件：l 流程建模流程建模提供可视化的流程设计和在线流程编辑工具，业务人员与技术人员在同一平台上完成业务流程建模任务；l 流程运行流程运行模块是支持业务流程运行和部署的核心模块，开发完成后的业务流程部署在流程运行模块上，并且可以支持多个流程实例的并发运行；l 流程模拟流程模拟可以在业务流程设计阶段能够模拟流程的运行，并且可以结合在线的流程运行统计数据，对流程运行结果进行分析和统计，以便查看流程的设计是否合理或能否进行优化业务逻辑处理：总线子系统的定位是实现数据的迁移和

13、应用调用，和业务逻辑相关的部分建议独立总线系统之外，建议在服务接入子系统包含和业务逻辑处理相关的模块；l 人工任务流程引擎支持多种人工任务的实现机制，支持多种人工任务的分配模式以应对复杂的由人工参与比较多的业务处理流程；l 表单服务表单是业务流程设计中人工任务环节的重要人机交互形式。流程引擎应该包括表单服务的能力，以便用户获得一致的使用体验，并使系统开发标准化。流程引擎应支持以图形化拖拽方式设计表单，表单执行过程中用户应该可以很方便地获得或修改流程所使用的业务信息。l 页面流业务流程中人工任务环节人机交互的一种方式。在单个用户处理某一人工任务环节时可以由系统以向导式方式，根据业务流程中的信息及

14、用户输入按照预先定义的规则自动地引导该用户一步一步地处理一系列页面(表单)。使用页面流技术，可以提高人机交互的友好程度，改善用户体验。l 流程统计流程统一提供各种手段实现对流程运行的统计，统计维度包括运行时间、总流程数目、成功流程数目、失败流程数目、流程发起人、操作人等，并且支持流程统计的数据能够以图形化的方式展现报表，包括表格、直方图、等方式；l 流程监控提供各种手段实现对运行时流程的监控，包括流程执行周期、活动执行时间、事件间隔等待时间、流程执行剩余完成时间、吞吐量等常见KPI进行监控和分析，并且以图形化的方式展现流程运行的状态；l 流程管理流程管理提供图形化的工作界面实现对流程的统一管理

15、，包括流程平台的管理、流程运行实例的管理、流程运行状态的跟踪等方面；l 规则处理规则处理支持通过多种方式设置流程流转规则，业务人员或者技术人员可以通过WEB界面动态的调整和设置规则条件，这样流程可以规则设置条件决定流程的走向；2.2.2. 服务总线子系统服务总线子系统是实现服务集成平台的核心模块，功能组件包括：l 通信接入实现外部系统到流程平台的统一接入，并且实现系统接入时的协议转换，包括对FTP/HTTP/SOAP/Web Service/JMS等通讯协议的支持，并且支持这些不同协议之间的转换过程；l 文件处理服务总线子系统可以实现各种格式文件的处理，包括文件的上传和下载，以及对文件内容的解

16、析过程。l 服务组合服务总线能将各已有系统提供的服务等组合一个新的服务，使服务对外部系统而言更具有可封装性、服务效率和服务透明性；l 数据路由提供智能路由功能，根据数据内容进行灵活而高性能的决策，从而将数据发送到相关的目的地。l 数据转换数据转换主要实现对数据格式的校验以及实现非标准的Web Service报文格式和XML报文与标准化的Web Service报文格式之间的转换工作；l 数据解析数据解析主要对传入总线平台的数据处理工作，包含数据的分离、合并、映射、计算等处理过程；l 数据分发通过支持“点对点”和“一对多”路由，支持“请求- 响应”模型和“发布- 订阅”多种消息分发模型实现数据从源

17、系统到目的系统的分发过程。l 应用整合服务总线能够实现和在不同技术平台实现的系统实现对接，并且可以把来自不同系统的功能模块包装成流程运行时需要的接口形式；l 公共组件公共组件实现了服务总线其它各功能组件层的公用组件。具体包括：l 日志记录组件完成企业服务总线日志信息的记录。包括系统处理正常时的信息以及系统处理异常错误信息。l 异常处理组件异常处理组件层完成对各种服务处理失败情况的统一处理，如记录日志、流水、返回异常应答等。l 数据库访问组件数据库访问组件实现对数据库数据访问的通用功能封装。如增加记录、删除记录、更新记录、查询记录等。2.2.3. 服务管控子系统服务管控子系统是平台的管理和监控中

18、心，管理员通过此子系统实现对流程和集成平台的管理、监控、维护、服务发布和部署以及服务配置管理等操作，保证平台能正常健康的运行，具体包括以下功能部件：l 元数据管理实现平台中各种服务的元数据管理，包括服务的分类管理、服务的版本及变更管理功能，服务有效性验证、服务依赖性分析等；l 服务发布和查找实现服务的发布和查找功能，流程平台可以通过动态的查找过程获得服务注册库中的服务能力，并且可以把封装好的服务发布到内网供各个系统进行使用；l 服务注册实现各种服务在平台上的注册，注册信息包含各种服务信息，如服务接口、服务运行与参数等；l 权限管理定义人员对平台的管理权限，定义各种平台的使用角色以及各种角色的对

19、各种服务和流程的使用权限和使用策略；l 服务监控服务监控主要完成监控在总线平台上的各种服务，包括接口运行状态的监控、SLA定义和监控、总线平台的运行情况监控等；l 配置管理配置管理主要实现实现流程和集成平台的运行参数调整以保证系统能够正常运转，并且最大可能的发挥性能；l 服务部署管理员通过服务部署的过程实现开发完成的流程和应用模块发布到和流程运行引擎和服务总线上的过程；2.2.4. 应用适配子系统流程和集成平台通过应用适配子系统实现和现有应用的整合，包含技术适配器、ERP适配器、自开发适配器等不同的适配器，同时管理人员和开发人员通过适配配置实现对适配器的管理过程；2.2.5. 数据层数据层实现

20、流程和集成平台的不同类型的数据存储和管理，存储的主要数据可分成几类：日志数据、应用数据、系统配置数据和其他数据等；2.3. 流程和集成平台运行架构建议使用以下运行架构支撑以上所述的功能架构。在运行架构中，根据功能特点把流程和集成平台的各子系统分布在不同的运行域中，每个运行域可以由一个或者几个物理节点实现，也可以把若干个运行域合并在一个物理节点上实现。2.3.1. 平台运行物理模型根据流程和集成平台的逻辑运行架构的定义，结合本项目的性能、容量、安全、可用性、可扩展性等非功能要求，建议使用以下的物理运行模型来部署逻辑运行架构中定义的各个运行域的功能：上述的系统总体物理运行模型可以帮助清楚的划分系统

21、功能分布以及对应的物理节点部署，方便管理和进行物理配置。每个节点群的说明如下：1 核心应用节点组核心应用服务区主要包含了流程和集成平台核心运行域的功能，建议使用2个物理节点（节点1和节点2）, 节点1和节点2分别由2台P560Q的其中的一个物理分区构成（每个分区分出2个CPU, 8G内存），这2个节点组成集群， 在这个集群中部署流程流程运行域和服务总线域内的功能模块。 平台管理和数据节点组平台管理和数据节点群使用2个物理节点（节点3和节点4），其中节点3负责流程和集成平台平台各种数据的存储和管理；节点4负责平台管理域的功能，这两

22、个物理节点通过HA机制互为备份，当某台机器出现问题，通过接管方式实现系统的可用性要求。节点3和节点4分别由2台P560Q的其中的一个物理分区构成（每个分区分出2个CPU, 8G内存）2.3.2. 平台物理部署架构遵循系统总体运行模型的定义可以导出平台的物理部署架构，流程和集成平台平台物理部署架构包括了对应的软件、硬件和网络配置建议和软件产品在给定硬件的部署方案，下面给出具体的部署架构图。. 核心应用节点组配置参照下面核心应用节点组软硬件配置图，具体的软件和硬件部署为：u 硬件配置2台P 560Q进行分区，每个机器分成2个物理分区，每个物理分区配置为2CPU, 8G内存，对应图中的

23、节点1和节点2。u 软件配置² 机器1的分区1（节点1）和机器2的分区1（节点2）同时安装IBM WebSphere Process Server 7.0和WebSphere ESB 7.0。² 使用IBM WebSphere Process Server 7.0和WebSphere ESB 7.0内嵌的集群机制组成集群，节点1和节点2同时运行流程引擎和服务集成平台。. 平台管理和数据节点组配置u 软件配置1. 节点3和节点4同时安装IBM DB2企业版本9.5 （含在WebSphere Process Server 7.0产品包中），节点3和4通过HA机制互

24、为备份，运行时节点3为运行数据库的主节点，出现问题时由节点4接管。2. 节点3和节点4同时安装WebSphere Service Repository&Registry 7.0作为服务注册、管理、监控的平台，节点3和4通过HA机制互为备份，运行时节点4为运行数据库的主节点，出现问题时由节点3接管。u 硬件配置2台P 560Q进行分区，每个机器分成2个物理分区，每个物理分区配置为2CPU, 8G内存，对应图中的节点3和节点4。考虑的数据库的数据存放在共享的外置存储上，因此需要配置双端口的光纤通道卡支持外置光纤存储的连接。2.3.3. 软件产品配置清单总结上面配置结果，建议本期黑龙江移动流程和服务集成平台的软件配置图如下：根据以上的软件产品配置建议和软件在硬件平台上的部署架构，具体的产品配置清单如下，序号软件功能厂家软件名称数量描述1ESB平台软件IBMWebSphere ESB 7.04CPU服务总线软件基础平台。2服务注册和管理软件IBMWebSphere Service Repository and Registry 7.01 CPU提供服务的注册和管理。3应用适配器软件IBM