油田系统整合方案.docx
《油田系统整合方案.docx》由会员分享，可在线阅读，更多相关《油田系统整合方案.docx（12页珍藏版）》请在冰豆网上搜索。
油田系统整合方案
油田信息化整合方案
1.引言
1.1.编写目
本方案为油田信息化整合整体规划及一期改造总体设计。
1.2.阅读对象
本实施方案主要面向油田各级领导及相关技术人员。
1.3.术语定义
无
2.系统概述
1.
2.
2.1.实现目标
随着信息化时代发展，数字化手段提高及融入到日常生产及管理，近年来油田及各下属部门内已建成多个独立信息系统，信息化管理方式已经深入到生产及管理各个层次。
但是伴随着越来越多各自独立子系统建成并投入使用，大量重复功能及兼容性问题已经造成严重资源浪费、管理繁复及低效、信息传递不畅及冲突。
因此对现有各子系统改造及整合就成为未来信息化建设重中之重。
在此背景下，油田信息化整合就是要将油田现有、在建及未来将建各类业务、财务等信息系统整合到统一平台上。
由信息化管理部门统一维护、管理、以及提供更快速及便捷服务。
2.2.整合规划
油田信息化整合建设主要分为三个阶段，各阶段主要完成内容如下：
第一阶段：
子系统级整合
建设信息化平台统一框架，在不改变各子系统内部结构及功能构架前提下，完成各子系统权限管理、系统间流程管理、系统功能模块管理及界面风格统一管理整合。
第二阶段：
模块级整合
详细调研各子系统功能及业务流程，站在集团业务层面，制定统一业务标准，实现各子系统内部功能模块化，模块间接口标准化，最终实现业务功能模块级在统一平台上整合。
第三阶段：
面向中石油集团级云服务推广
通过油田信息化整合完成，实现油田信息系统模块化、标准化。
在此基础上，在中国石油内进行业务推广。
将信息平台及成熟云解决方案结合，最终实现信息系统在全国乃至全球无缝接入及服务。
2.3.设计原则
（1）经济实用性
根据现有技术条件及业务需求，充分考虑系统可实现性及环境复杂性进行设计解决，实现系统管理高效性。
（2）可靠性
平台是一个长期运行并整合多子系统复杂系统，设计时充分考虑后备以及灾难恢复机制，使系统在部分故障时仍然能够提供对用户服务，并且能够很快排除故障恢复正常运行。
（3）安全性
安全性对于系统而言是极为重要。
建立系统网络安全机制，设置权限控制，通过网络自检、实时监控和自动故障报警检测以及一定程度自恢复，确保网络和数据安全，成为必须具有特性。
（4）开放性
整个内部网络传输采用标准TCP/IP协议；其他系统也采用相应工业标准，充分保证系统开放性。
并在设计时保留必要接口，实现及其他系统对接。
（5）可扩展性
系统设计除了可以适应目前需要以外，充分考虑用户日后业务发展需要。
按最经济原则，规划成一个扩展性很强且在扩容升级时浪费最少系统。
支持软件支持二次开发，计算机网络系统适应将来广域扩展。
（6）先进性
在兼顾系统成熟性前提下，采用业界先进技术，以目前较为先进方法实现需要功能，既反应当今科技先进水平，又具有发展潜力，使计算机系统发挥最大效率。
（7）实时访问性
系统不仅可通过传统PC端Web、客户端等方式访问，还将支持各类智能手机、平板电脑等移动设备方式访问。
3.整合平台设计（一期）
3.1.系统结构
3.2.权限管理
3.2.1.功能说明
权限管理是为系统中每一个使用者维护各自权限，使其只能根据自己职位和职责在系统中进行相应工作。
根据权限管理思想，将系统中操作各类模块权限按部门和工作性质进行分类，归类结果作为该部门分管角色。
每个角色可以操作其工作范围内模块；而每个用户又可以对应一种或多种角色。
按照这种方式，对应于不同工作范围不同角色用户，所能操作控制业务模块也就不同。
3.2.2.整合设计
对于各个子系统权限管理功能整合，需要根据子系统实际情况进行。
主要需要分析原有子系统权限管理现有方式，按照方式不同可采用两种不同策略。
●松耦合
现有子系统其权限管理和模块功能间采用松耦合方式，即子系统内部权限管理模块及业务功能模块间紧靠消息方式传递数据。
权限管理模块对实际业务模块及模块内数据没有实际控制能力。
业务模块访问控制、数据控制紧靠权限管理模块提供数据支持。
这种权限管理方式常用于Web方式子系统。
对于采用本类权限管理子系统，最佳整合方式为用整合后新权限管理模块替换原系统权限管理模块。
新权限管理模块按照原子系统权限管理及业务模块间数据访问接口提供访问，以达到权限管理无缝对接。
●紧耦合
现有子系统其权限管理和模块功能间采用紧耦合方式，即子系统内部依靠权限管理模块直接控制业务模块及其相关业务数据访问。
这种形式权限管理方式，权限管理功能渗入每个业务模块内部，常用于客户端形式和早期采用Javaapplet方式子系统。
对于采用本类权限管理子系统，由于原有权限管理渗入系统内每个环节，不易于替换。
因此最佳整合方式为在不改变旧系统程序基础上，采用数据库访问中间件形式。
即按照整合后权限管理建立后台数据结构基础上，按照旧权限管理数据库访问规则，编写数据库访问中间件。
该中间件可将新权限管理数据库结构及数据按照旧系统访问规则整理；旧系统权限管理模块访问采用整合权限管理模块定制数据结构数据库时，依然可以获得原格式数据，以达到新旧权限管理兼容。
3.2.3.模块内部设计
（此设计为初步设计，需根据各子系统实际情况增加管理功能）
3.2.3.1.模型设计
权限往往是一个极其复杂问题，但也可简单表述为这样逻辑表达式：
判断“Who对What（Which）进行How操作”逻辑表达式是否为真。
权限系统核心由以下三部分构成：
创造权限、分配权限、使用权限。
系统各部分主要参及者对照如下：
创造权限——Creator创造
分配权限——Administrator分配
使用权限——User
Creator创造Privilege
Creator在设计和实现系统时会划分，一个子系统或称为模块，应该有哪些权限。
这里完成是Privilege及Resource对象声明，并没有真正将Privilege及具体Resource实例联系在一起，形成Operator。
Administrator指定Privilege及ResourceInstance关联
通过指定权限及资源关系，权限真正及资源实例联系到了一起，产生了Operator（PrivilegeInstance）。
Administrator利用Operator这个基本元素，来合理创造权限模型。
如，创建角色，给用户分配角色等等。
这些操作都是由Administrator来完成。
User使用Administrator分配给权限去使用各个子系统
用户通过Administrator设定User和角色Role对应关系，访问到其可控制资源。
权限管理模型入图3-2所示：
图3-2权限管理模型
3.2.3.2.数据库设计
图3-3为整合平台框架中权限管理数据库设计：
图3-3权限管理数据库关系图
角色表：
维护各个部门下所有角色及说明信息。
权限清单表：
角色表子表，记录每一种角色所可以操作业务模块。
对于某个角色所能操作每个模块都对应表中一条记录。
操作人员表：
记录系统中每一位操作员信息。
用户角色表：
记录用户和角色对应关系，一个用户可以对应多种角色，也就是表中多条记录。
3.2.3.3.实现原理
权限分配首先通过在“角色表”中建立确定部门下新角色，然后选择该角色可以控制业务模块，将其存放在“权限清单表”中，最后为每个用户选择其所属角色存入“用户角色表”。
完成这些工作，系统就可以根据用户所具有不同权限控制其对系统操作了。
操作人员登录后，系统根据其所属部门和用户名从“用户角色表”中获得该用户对应角色；再根据角色从“权限清单表”中获得该用户可以控制模块编号。
对于一个用户对应不同角色，而不同角色对同一模块操作权限又不同时，该用户对这个模块权限取权限级别高。
当取得对应于当前用户可操作业务模块后，系统将这些模块列表以目录树方式显示，供用户选择操作；而对于其他业务模块，用户无权限操作，系统不显示，不提供入口。
3.3.模块管理
3.3.1.整合设计
模块管理可以为系统内各个子系统功能模块提供统一入口，即在整合平台主界面下，采用模块列表等形式，直接、快捷访问各子系统内部功能模块。
本部分整合主要针对原采用Web方式访问子系统，通过模块地址配置，以达到统一界面、统一登录、统一入口形式。
3.3.2.模块内部设计
3.3.2.1.模型设计
模块系统主要完成功能如图3-4所示：
图3-4模块系统功能
模块管理作为整合平台框架重要组成部分，其主要包含两部分功能：
为系统框架挂接业务模块提供接口
系统中为了便于业务模块开发和修改，框架内采用强内聚，模块间采用松散耦合组合模式。
模块之间相互独立，各个业务模块通过模块管理功能，挂接在系统上，通过系统调用。
为权限系统提供过滤条件
针对不同角色所属部门及权限不同，在模块系统中维护对其操作数据滤条件，使用户仅能访问其授权资源。
3.3.2.2.数据库设计
模块管理数据库设计如图3-5所示：
图3-5模块管理数据库设计
模块信息：
包括模块编号、模块名称、模块类别、提示信息、模块图标字段。
记录业务模块各种基础信息。
模块关系：
包括上级模块编号、是否终结点字段。
记录模块之间相互关系，以维护模块关系树。
管理过滤条件：
包括集中管理、集中管理条件、人员分管、人员分管条件、部门管理、部门分管条件字段。
根据管理模式进行分类，维护进入模块初始过滤条件。
查询条件：
包括查询ID、查询标志、查询SQL、打印标志字段。
在模块中提供查询、打印功能条件设置。
模块调用：
Url字段。
提供系统框架对模块调用地址。
3.3.2.3.实现原理
系统中业务模块是通过在模块清单中添加模块信息将其挂接在系统框架上，在系统运行中通过树形菜单调用。
树形菜单是通过“模块清单表”中模块关系相关字段进行维护和控制，自根节点逐级自动生成。
当在菜单中调用某一模块时，系统通过该记录“Url”字段获取模块地址信息，将主界面转向其链接地址显示该模块界面。
当进入该模块时，系统跟据企业管理模式和过滤条件，自动对模块中可操作信息进行过滤。
过滤条件记录在该模块记录管理过滤条件字段中。
3.4.数据交换
3.4.1.功能说明
在业务模块内部，各类单据通过其特定工作流程来进行处理，这是一种工作流管理方式。
为了实现这种工作流管理控制，在系统中设计流程管理模块。
各类单据按照预先定义维护、提交、审批等流程在系统中处理，系统记录每一步处理结果，并将该单据自动提交下一业务流程节点。
3.4.2.整合设计
针对流程功能整合，一期主要完成子系统间流程整合，二期完成子系统内部流程整合。
针对各子系统内部单据多样、复杂特点，以及现有子系统单据流转数据格式不通性及阻塞性，整合系统流程管理需要具有单据通用性、可配置型等特点。
整合后流程管理并不针对特定单据特定形式数据，而是将进入流程单据绑定单号实例化，通过原系统单据访问实现以单号控制业务流转。
3.4.3.模块内部设计
3.4.3.1.模块设计
流程关系系统模型如图3-6所示：
图3-6流程管理模型
3.4.3.2.数据库设计
流程管理数据库设计如图3-7所示：
图3-7流程管理数据库设计
模块信息表：
记录流程对一类业务单据相应处理，包括通过、驳回等。
流程模板表：
记录及一类业务单据对应流程处理模板信息。
模板节点表：
记录确定流程模板上所需经历流程节点信息。
流程实例定义：
根据流程模板生成某类单据实例信息，对应于系统中一张确定单据。
实例节点定义：
记录实例单据所经历每一个流程节点信息，即流程处理每一步骤。
3.4.3.3.实现原理
在系统初始化过程中，在“模块信息表”中为每一类单据定义其相应处理须执行SQL语句，即在审批通过或否决时需要更新单据状态字段SQL语句。
系统管理员或实施人员根据单据类别和业务流程，在系统中维护相应流程模板，模板主信息记录在“流程模板表”中，模板对应节点信息记录在“模板节点表”中，每个模板节点包括可操作该节点人员角色和权限。
在业务处理过程中，当某一单据进入流程后，系统根据该单据类型对应模板自动生成流程实例。
流程实例主信息存储在“流程实例定义表”中；初始化实例流程每个节点将信息存储在“实例节点定义表”中。
单据在流程中进行每一步操作修改实例流程进度信息和对应实例节点信息。
当流程中每个节点全部通过单据，则模板执行单据通过SQL；一旦流程中某一节点否决单据，终止流程执行单据否决SQL。
3.5.界面管理
3.5.1.功能说明
针对整合后平台，所有业务界面需要统一风格。
因此要求各子系统界面风格具有可配置性。
3.5.2.整合设计
针对现有系统界面改造，需要由原系统开发公司将界面风格模板化，便于界面风格统一管理及更新。
对于平台整合后新系统，由于采用Web模式，因此可以模块通用设计模板来开发，以实现程序设计快捷性及统一性。
3.5.3.模块设计
在整合平台中，为了后续开发简单化和快速化，引入使用了通用模板概念。
通用模板设计采用了设计模式思想，对业务规则进行抽象化实现。
使用通用模板好处是使用户界面风格统一、缩小开发周期、增加系统灵活性和使系统便于维护。
在系统中间层上，模板提供通用业务规则实现，及实现特殊规则接口；在及用户接口Web层上，系统中提供两条不同思路通用模板实现：
动态界面生成模板和静态界面生成模板。
两种模板各有优缺点。
静态界面生成需要开发人员根据需求，在程序模板中静态设置界面各种属性。
这样做降低了程序修改灵活性，当界面随用户需求发生变化时，界面需要重新修改，优点是在程序运行时，界面可以直接调用，提高了系统性能。
但对于界面风格改变，由于采用模板元素控制机制，也可达到统一管理效果。
动态界面生成是在程序框架中提供一通用界面，开发人员或者系统管理员根据用户需要通过界面生成模块，在数据库中维护界面需显示信息，当程序运行打开界面时，系统框架从数据库中读取相应信息，并根据该信息动态生成用户界面。
这样做当用户打开界面时需要从数据库中读取界面信息以生成界面，必然会增加系统负担和用户等待时间，使系统性能受到影响。
优点是可以多个模块共用一通用界面，并在系统使用过程中随时根据用户需要设计相应界面，增加了系统灵活性和适应性。
升级会员 