油田系統(tǒng)整合方案

1、油田信息化整合方案1. 引言1.1. 編寫目的本方案為油田信息化整合的整體規(guī)劃及一期改造的總體設計。1.2. 閱讀對象本實施方案主要面向油田各級領導及相關技術人員。1.3. 術語定義無2. 系統(tǒng)概述1.2.2.1. 實現(xiàn)目標隨著信息化時代的發(fā)展，數(shù)字化手段的提高及融入到日常生產與管理，近年來油田及各下屬部門內已建成多個獨立的信息系統(tǒng)，信息化的管理方式已經深入到生產與管理的各個層次。但是伴隨著越來越多各自獨立的子系統(tǒng)建成并投入使用，大量的重復功能及兼容性問題已經造成嚴重的資源浪費、管理繁復與低效、信息傳遞的不暢與沖突。因此對現(xiàn)有各子系統(tǒng)的改造與整合就成為未來信息化建設的重中之重。在此背景下，油田

2、信息化整合就是要將油田現(xiàn)有、在建及未來將建的各類業(yè)務、財務等信息系統(tǒng)整合到統(tǒng)一的平臺上。由信息化管理部門統(tǒng)一維護、管理、以及提供更快速與便捷的服務。2.2. 整合規(guī)劃油田信息化整合建設主要分為三個階段，各階段主要完成內容如下：第一階段：子系統(tǒng)級整合建設信息化平臺統(tǒng)一框架，在不改變各子系統(tǒng)內部結構及功能構架的前提下，完成各子系統(tǒng)權限管理、系統(tǒng)間流程管理、系統(tǒng)功能模塊管理及界面風格統(tǒng)一管理的整合。第二階段：模塊級整合詳細調研各子系統(tǒng)功能及業(yè)務流程，站在集團業(yè)務層面，制定統(tǒng)一的業(yè)務標準，實現(xiàn)各子系統(tǒng)內部功能模塊化，模塊間接口標準化，最終實現(xiàn)業(yè)務功能模塊級在統(tǒng)一平臺上的整合。第三階段：面向中石油集團級

3、云服務推廣通過油田信息化整合完成，實現(xiàn)油田信息系統(tǒng)的模塊化、標準化。在此基礎上，在中國石油內進行業(yè)務推廣。將信息平臺與成熟云解決方案結合，最終實現(xiàn)信息系統(tǒng)在全國乃至全球的無縫接入與服務。2.3. 設計原則（1） 經濟實用性根據(jù)現(xiàn)有的技術條件及業(yè)務需求，充分考慮系統(tǒng)的可實現(xiàn)性及環(huán)境的復雜性進行設計解決，實現(xiàn)系統(tǒng)管理的高效性。（2） 可靠性平臺是一個長期運行并整合多子系統(tǒng)的復雜系統(tǒng)，設計時充分考慮后備以及災難恢復機制，使系統(tǒng)在部分故障時仍然能夠提供對用戶的服務，并且能夠很快的排除故障恢復正常運行。（3） 安全性安全性對于系統(tǒng)而言是極為重要的。建立系統(tǒng)的網(wǎng)絡安全機制，設置權限控制，通過網(wǎng)絡的自檢、實

4、時監(jiān)控和自動故障報警檢測以及一定程度的自恢復，確保網(wǎng)絡和數(shù)據(jù)安全，成為必須具有的特性。（4） 開放性整個內部網(wǎng)絡傳輸采用標準的TCP/IP協(xié)議；其他的系統(tǒng)也采用相應的工業(yè)標準，充分保證系統(tǒng)的開放性。并在設計時保留必要的接口，實現(xiàn)與其他系統(tǒng)的對接。（5） 可擴展性系統(tǒng)設計除了可以適應目前的需要以外，充分考慮用戶日后的業(yè)務發(fā)展需要。按最經濟的原則，規(guī)劃成一個擴展性很強且在擴容升級時浪費最少的系統(tǒng)。支持軟件支持二次開發(fā)，計算機網(wǎng)絡系統(tǒng)適應將來的廣域擴展。（6） 先進性在兼顧系統(tǒng)成熟性的前提下，采用業(yè)界先進的技術，以目前較為先進的方法實現(xiàn)需要的功能，既反應當今科技的先進水平，又具有發(fā)展?jié)摿Γ褂嬎銠C系

5、統(tǒng)發(fā)揮最大的效率。（7） 實時訪問性系統(tǒng)不僅可通過傳統(tǒng)PC端Web、客戶端等方式訪問，還將支持各類智能手機、平板電腦等移動設備的Wap及App方式訪問。3. 整合平臺設計（一期）3.1. 系統(tǒng)結構3.2. 權限管理3.2.1. 功能說明權限管理是為系統(tǒng)中的每一個使用者維護各自的權限，使其只能根據(jù)自己的職位和職責在系統(tǒng)中進行相應的工作。根據(jù)權限管理的思想，將系統(tǒng)中的操作各類模塊的權限按部門和工作性質進行分類，歸類的結果作為該部門分管的角色。每個角色可以操作其工作范圍內的模塊；而每個用戶又可以對應一種或多種角色。按照這種方式，對應于不同工作范圍的不同角色用戶，所能操作控制的業(yè)務模塊也就不同。3.2

6、.2. 整合設計對于各個子系統(tǒng)權限管理功能的整合，需要根據(jù)子系統(tǒng)實際情況進行。主要需要分析原有子系統(tǒng)權限管理現(xiàn)有方式，按照方式的不同可采用兩種不同的策略。l 松耦合現(xiàn)有子系統(tǒng)其權限管理和模塊功能間采用松耦合的方式，即子系統(tǒng)內部權限管理模塊與業(yè)務功能模塊間緊靠消息方式傳遞數(shù)據(jù)。權限管理模塊對實際業(yè)務模塊及模塊內數(shù)據(jù)沒有實際控制能力。業(yè)務模塊的訪問控制、數(shù)據(jù)控制緊靠權限管理模塊提供的數(shù)據(jù)支持。這種權限管理方式常用于Web方式的子系統(tǒng)。對于采用本類權限管理的子系統(tǒng)，最佳整合方式為用整合后的新權限管理模塊替換原系統(tǒng)權限管理模塊。新權限管理模塊按照原子系統(tǒng)權限管理與業(yè)務模塊間數(shù)據(jù)訪問接口提供訪問，以達到

7、權限管理的無縫對接。l 緊耦合現(xiàn)有子系統(tǒng)其權限管理和模塊功能間采用緊耦合的方式，即子系統(tǒng)內部依靠權限管理模塊直接控制業(yè)務模塊及其相關業(yè)務數(shù)據(jù)的訪問。這種形式的權限管理方式，權限管理功能滲入每個業(yè)務模塊內部，常用于客戶端形式和早期采用Java applet方式的子系統(tǒng)。對于采用本類權限管理的子系統(tǒng)，由于原有權限管理滲入系統(tǒng)內每個環(huán)節(jié)，不易于替換。因此最佳整合方式為在不改變舊系統(tǒng)程序的基礎上，采用數(shù)據(jù)庫訪問中間件的形式。即按照整合后權限管理建立后臺數(shù)據(jù)結構的基礎上，按照舊權限管理數(shù)據(jù)庫訪問規(guī)則，編寫數(shù)據(jù)庫訪問中間件。該中間件可將新權限管理數(shù)據(jù)庫結構與數(shù)據(jù)按照舊系統(tǒng)訪問規(guī)則整理；舊系統(tǒng)權限管理模塊訪

8、問采用整合權限管理模塊定制數(shù)據(jù)結構的數(shù)據(jù)庫時，依然可以獲得原格式數(shù)據(jù)，以達到新舊權限管理的兼容。3.2.3. 模塊內部設計（此設計為初步設計，需根據(jù)各子系統(tǒng)實際情況增加管理功能）3.2.3.1. 模型設計權限往往是一個極其復雜的問題，但也可簡單表述為這樣的邏輯表達式：判斷“Who對What(Which)進行How的操作”的邏輯表達式是否為真。權限系統(tǒng)的核心由以下三部分構成：創(chuàng)造權限、分配權限、使用權限。系統(tǒng)各部分的主要參與者對照如下：創(chuàng)造權限Creator創(chuàng)造分配權限Administrator分配使用權限UserCreator創(chuàng)造PrivilegeCreator在設計和實現(xiàn)系統(tǒng)時會劃分，一個子

9、系統(tǒng)或稱為模塊，應該有哪些權限。這里完成的是Privilege與Resource的對象聲明，并沒有真正將Privilege與具體Resource 實例聯(lián)系在一起，形成Operator。Administrator指定Privilege與Resource Instance的關聯(lián)通過指定權限與資源關系，權限真正與資源實例聯(lián)系到了一起，產生了Operator（Privilege Instance）。Administrator利用Operator這個基本元素，來合理創(chuàng)造權限模型。如，創(chuàng)建角色，給用戶分配角色等等。這些操作都是由Administrator來完成的。User使用Administrator分配

10、給的權限去使用各個子系統(tǒng)用戶通過Administrator設定的User和角色Role的對應關系，訪問到其可控制資源。權限管理模型入圖3-2所示：圖3-2 權限管理模型3.2.3.2. 數(shù)據(jù)庫設計圖3-3為整合平臺框架中權限管理的數(shù)據(jù)庫設計：圖3-3 權限管理數(shù)據(jù)庫關系圖角色表：維護各個部門下的所有角色及說明信息。權限清單表：角色表的的子表，記錄每一種角色所可以操作的業(yè)務模塊。對于某個角色所能操作的每個模塊都對應表中的一條記錄。操作人員表：記錄系統(tǒng)中的每一位操作員的信息。用戶角色表：記錄用戶和角色的對應關系，一個用戶可以對應多種角色，也就是表中的多條記錄。3.2.3.3. 實現(xiàn)原理權限分配首先

11、通過在“角色表”中建立確定部門下新的角色，然后選擇該角色可以控制的業(yè)務模塊，將其存放在“權限清單表”中，最后為每個用戶選擇其所屬的角色存入“用戶角色表”。完成這些工作，系統(tǒng)就可以根據(jù)用戶所具有的不同權限控制其對系統(tǒng)的操作了。操作人員登錄后，系統(tǒng)根據(jù)其所屬部門和用戶名從“用戶角色表”中獲得該用戶對應的角色；再根據(jù)角色從“權限清單表”中獲得該用戶可以控制的模塊編號。對于一個用戶對應不同角色，而不同角色對同一模塊的操作權限又不同時，該用戶對這個模塊的權限取權限級別高的。當取得對應于當前用戶的可操作業(yè)務模塊后，系統(tǒng)將這些模塊列表以目錄樹的方式顯示，供用戶選擇操作；而對于其他業(yè)務模塊，用戶無權限操作，系

12、統(tǒng)不顯示，不提供入口。3.3. 模塊管理3.3.1. 整合設計模塊管理可以為系統(tǒng)內各個子系統(tǒng)的功能模塊提供統(tǒng)一的入口，即在整合平臺主界面下，采用模塊列表等形式，直接、快捷的訪問各子系統(tǒng)內部功能模塊。本部分整合主要針對原采用Web方式訪問的子系統(tǒng)，通過模塊地址的配置，以達到統(tǒng)一界面、統(tǒng)一登錄、統(tǒng)一入口的形式。3.3.2. 模塊內部設計3.3.2.1. 模型設計模塊系統(tǒng)主要完成的功能如圖3-4所示：圖3-4 模塊系統(tǒng)功能模塊管理作為整合平臺框架的重要組成部分，其主要包含兩部分功能：為系統(tǒng)框架掛接業(yè)務模塊提供接口系統(tǒng)中為了便于業(yè)務模塊的開發(fā)和修改，框架內采用強內聚，模塊間采用松散耦合的組合模式。模塊

13、之間相互獨立，各個業(yè)務模塊通過模塊管理功能，掛接在系統(tǒng)上，通過系統(tǒng)調用。為權限系統(tǒng)提供過濾條件針對不同角色所屬部門及權限不同，在模塊系統(tǒng)中維護對其操作數(shù)據(jù)的濾條件，使用戶僅能訪問其授權資源。3.3.2.2. 數(shù)據(jù)庫設計模塊管理數(shù)據(jù)庫設計如圖3-5所示：圖3-5 模塊管理數(shù)據(jù)庫設計模塊信息：包括模塊編號、模塊名稱、模塊類別、提示信息、模塊圖標字段。記錄業(yè)務模塊的各種基礎信息。模塊關系：包括上級模塊編號、是否終結點字段。記錄模塊之間的相互關系，以維護模塊關系樹。管理過濾條件：包括集中管理、集中管理條件、人員分管、人員分管條件、部門管理、部門分管條件字段。根據(jù)管理模式進行分類，維護進入模塊的初始過濾

14、條件。查詢條件：包括查詢ID、查詢標志、查詢SQL、打印標志字段。在模塊中提供查詢、打印功能的條件設置。模塊調用：Url字段。提供系統(tǒng)框架對模塊的調用地址。3.3.2.3. 實現(xiàn)原理系統(tǒng)中的業(yè)務模塊是通過在模塊清單中添加模塊信息將其掛接在系統(tǒng)框架上，在系統(tǒng)運行中通過樹形菜單調用。樹形菜單是通過“模塊清單表”中模塊關系相關字段進行維護和控制，自根節(jié)點逐級自動生成的。當在菜單中調用某一模塊時，系統(tǒng)通過該記錄“Url”字段獲取模塊地址信息，將主界面轉向其鏈接地址顯示該模塊界面。當進入該模塊時，系統(tǒng)跟據(jù)企業(yè)管理模式和過濾條件，自動對模塊中可操作的信息進行過濾。過濾條件記錄在該模塊記錄的管理過濾條件字段

15、中。3.4. 數(shù)據(jù)交換3.4.1. 功能說明在業(yè)務模塊內部，各類單據(jù)通過其特定的工作流程來進行處理，這是一種工作流的管理方式。為了實現(xiàn)這種工作流的管理控制，在系統(tǒng)中設計流程管理模塊。各類單據(jù)按照預先定義的維護、提交、審批等流程在系統(tǒng)中處理，系統(tǒng)記錄每一步處理結果，并將該單據(jù)自動提交下一業(yè)務流程節(jié)點。3.4.2. 整合設計針對流程功能的整合，一期主要完成子系統(tǒng)間的流程整合，二期完成子系統(tǒng)內部流程整合。針對各子系統(tǒng)內部單據(jù)多樣、復雜的特點，以及現(xiàn)有子系統(tǒng)單據(jù)流轉的數(shù)據(jù)格式不通性與阻塞性，整合系統(tǒng)流程管理需要具有單據(jù)的通用性、可配置型等特點。整合后流程管理并不針對特定單據(jù)的特定形式數(shù)據(jù)，而是將進入流

16、程的單據(jù)綁定單號實例化，通過原系統(tǒng)的單據(jù)訪問實現(xiàn)以單號控制的業(yè)務流轉。3.4.3. 模塊內部設計3.4.3.1. 模塊設計流程關系系統(tǒng)模型如圖3-6所示：圖3-6 流程管理模型3.4.3.2. 數(shù)據(jù)庫設計流程管理數(shù)據(jù)庫設計如圖3-7所示：圖3-7 流程管理數(shù)據(jù)庫設計模塊信息表：記錄流程對一類業(yè)務單據(jù)的相應處理，包括通過、駁回等。流程模板表：記錄與一類業(yè)務單據(jù)對應的流程處理模板信息。模板節(jié)點表：記錄確定流程模板上所需經歷的流程節(jié)點信息。流程實例定義：根據(jù)流程模板生成某類單據(jù)的實例信息，對應于系統(tǒng)中一張確定單據(jù)。實例節(jié)點定義：記錄實例單據(jù)所經歷每一個流程節(jié)點信息，即流程處理的每一步驟。3.4.3.

17、3. 實現(xiàn)原理在系統(tǒng)初始化的過程中，在“模塊信息表”中為每一類單據(jù)定義其相應處理須執(zhí)行的SQL語句，即在審批通過或否決時需要更新單據(jù)狀態(tài)字段的SQL語句。系統(tǒng)管理員或實施人員根據(jù)單據(jù)類別和業(yè)務流程，在系統(tǒng)中維護相應流程模板，模板主信息記錄在“流程模板表”中，模板對應節(jié)點信息記錄在“模板節(jié)點表”中，每個模板節(jié)點包括可操作該節(jié)點的人員角色和權限。在業(yè)務處理過程中，當某一單據(jù)進入流程后，系統(tǒng)根據(jù)該單據(jù)類型對應的模板自動生成流程實例。流程實例的主信息存儲在“流程實例定義表”中；初始化實例流程的每個節(jié)點將信息存儲在“實例節(jié)點定義表”中。單據(jù)在流程中進行的每一步操作修改實例流程進度信息和對應實例節(jié)點信息。

18、當流程中每個節(jié)點全部通過單據(jù)，則模板執(zhí)行單據(jù)通過SQL；一旦流程中某一節(jié)點否決單據(jù)，終止流程執(zhí)行單據(jù)否決SQL。3.5. 界面管理3.5.1. 功能說明針對整合后的平臺，所有業(yè)務界面需要統(tǒng)一風格。因此要求各子系統(tǒng)界面風格具有可配置性。3.5.2. 整合設計針對現(xiàn)有系統(tǒng)界面改造，需要由原系統(tǒng)開發(fā)公司將界面風格模板化，便于界面風格的統(tǒng)一管理與更新。對于平臺整合后的新系統(tǒng)，由于采用Web模式，因此可以模塊通用設計模板來開發(fā)，以實現(xiàn)程序設計的快捷性與統(tǒng)一性。3.5.3. 模塊設計在整合平臺中，為了后續(xù)開發(fā)的簡單化和快速化，引入使用了通用模板的概念。通用模板設計采用了設計模式的思想，對業(yè)務規(guī)則進行抽象化實現(xiàn)。使用通用模板的好處是使用戶界面風格統(tǒng)一、縮小開發(fā)周期、增加系統(tǒng)靈活性和使系統(tǒng)便于維護。在系統(tǒng)中間層上，模板提供通用業(yè)務規(guī)則的實現(xiàn)，及實現(xiàn)特殊規(guī)則的接口；在與用戶接口的Web層上，系統(tǒng)中提供兩條不同思路通用模板的實現(xiàn)：動態(tài)界面生成模板和靜態(tài)界面生成模板。兩種模板的各有優(yōu)缺點。靜態(tài)界面生成需要開發(fā)人員根據(jù)需求，在程序模板中靜態(tài)設置界面的各種屬性。這樣做降低了程序修改的靈活性，當界面隨用戶需求發(fā)