1、前言

1.1、背景

目前，運營商的業務支撐系統多采用傳統的“煙囪式”架構模式，即：按功能分為不同的子系統，根據不同需求獨立地進行設計和建設，系統架構從應用、數據再到基礎設施，都以煙囪式部署為主。這種系統架構模式的顯著特點是縱向統一，系統內部建設一體化。這種系統架構模式雖保證了各功能系統內部建設的統一，但同時也導致出現了系統系統間獨立性強、信息不透明、部門間橫向協調性差、共通性少及資源共享率不高等諸多問題。

近年來，隨著云技術的飛速發展和業務需求的持續擴大，運營商對業務支撐系統的橫向共通性要求也在不斷提高。鑒于傳統“煙囪式”架構已逐漸暴露出了設備利用率不高、數據通用性不佳、建設周期長、無法快速滿足業務支撐需求、缺乏動態適應市場變化和競爭需要能力等諸多弊端，顯然這種傳統架構已不能滿足運營商業務發展的支撐需求。

PaaS作為云計算的服務模式之一，其市場規模遠遠小于其他的兩種服務模式，但IaaS、SaaS發展在遇到瓶頸期后，也必然要回歸到PaaS中來，三者是相輔相成關系。從2012年開始，許多SaaS以及IaaＳ廠商開始推出自己的PaaS平臺運營服務，比如偉庫PaaS平臺、普元PaaS平臺、新浪SAE的IaaS+PaaS模式等，2013年一直主要發展云主機的騰訊云也推出了開放云平臺。根據諾達咨詢的調研，在對云計算了解而暫未部署PaaS服務的潛在用戶中，未來一年內有36%的潛在企業用戶有計劃部署PaaS服務，PaaS服務的使用率將在今年有大幅度的提升?；旧峡梢钥隙ǖ氖?，未來一到兩年內，將成為PaaS平臺部署的密集期，PaaS服務將迎來高速發展的一年。

為滿足企業辦公信息化需求，提高運營管理效率，提升經營發展能力，管理創新，推薦企業信息化部門采用基于PaaS平臺進行信息化建設。

1.2、術語與名詞解釋

本段內容是文中的術語、名詞的解釋，只限定文中所描述范圍使用，統一在相同的語境中。

（1）文件定義

文件是指公文管理中流轉文件的正文（Word格式文件），以及相關的附件，也包括流程管理、信息管理中的附件（圖片、文檔、表格等）。

（2）通用信息定義

在辦公系統環境中，通用信息是以文字、圖片、數字為主要傳播內容，并局限在辦公環境中，而且一般也不帶流程、業務處理的。例如：信息簡報、信息通報、新聞動態、論壇、微信、評論等。
（3）統一組織目錄定義

目錄服務表述的是一種層次似的存儲結構，適合描述同樣具有層次關系組織的服務資源。統一組織目錄是集中統一管理辦公系統中各個應用模塊的組織和用戶賬號信息為一套共享的組織、賬號信息。

（4）服務定義

平臺對外提供的基本能力單元，并且在平臺框架內進行注冊。根據其面向的目的，可分為業務服務和技術服務。服務包括部署態和運行態，部署態是指服務的包裝方式和部署形式，運行態特指服務的運行實例，一個服務可包含多個服務實例。

（5）流程服務定義

流程服務是在工作流引擎的基礎上，按辦公云平臺規范封裝API服務，并與辦公云平臺集成，以滿足辦公系統中業務應用的需求，規范管理工作流開發的接口，提供通用的開發功能支撐。

（6）公文定義

公文，是公務文書的簡稱，是黨政機關、社會團體、企事業單位以及其他社會組織行使法定職權、處理日常事務時經常使用的一種文體。公文有其特定的撰寫程式和行文格式，是傳達黨和國家的方針政策、發布黨規政令、指導和商洽工作、請示和答復問題、報告情況、交流經驗的一種重要文字工具。公文是應用文中最重要且用途最為廣泛的一種文體。

（7）業務流程定義

業務流程是為達到特定的價值目標而由不同的人分別共同完成的一系列活動。活動之間不僅有嚴格的先后順序限定，而且活動的內容、方式、責任等也都必須有明確的安排和界定，以使不同活動在不同崗位角色之間進行轉手交接成為可能?；顒优c活動之間在時間和空間上的轉移可以有較大的跨度。而狹義的業務流程，則認為它僅僅是與客戶價值的滿足相聯系的一系列活動。

2、需求分析

本期建設需求涵蓋公文管理、通用辦公、流程管理三大類。其中，流程管理就是業務流程的管理，例如資費管理審批、業務申請單、通用便簽流程、業務需求申請單、經營管理0701－退費/返費申請（500元以下）、異常業務申報單（某地市）。

在部分流程管理業務中，含有數據統計、分析管理功能。有的有較強的業務信息管理，這樣與流程組合成辦公專業管理系統或模塊。

目前企業內部流程管理存在"非固化"、"固化"以及介于二者之間的"半固化"三種模式：

（1）非固化模式

從承辦人成功發起流程，系統可提示該類流程單據‘應走’的流轉路徑，但不做限制與驗證，而是業務處理人員根據流轉記錄判斷流程是否完整的模式。

（2）半固化模式

是指針對業務人員選定‘普通流程’或‘簡易流程’并成功發起流程后，流轉路徑上必須要經過的部門及其先后順序也同時確定，系統能夠進行驗證，但每個部門內部的流轉過程（如同一部門內處室之間或處室內部）系統不進行限制，可由每一當前處理人指定的模式。

（3）固化模式

是指依據業務規則與設置，該業務單據的流轉路徑上的流轉環節精確到崗位（甚至是用戶），流程承辦人一旦成功發起流程，業務單據的工作流將按照既定規則與每一當前處理人的處理結果自動執行，不允許人工指定的模式。

3、系統架構目標

為了應對企業面對的系統技術和業務挑戰，我們要建設的PaaS平臺應超越傳統PaaS范疇，在業務能力和技術能力組件上有所加強，形成更有針對性的“厚PaaS”平臺。通過這個平臺，我們可以統一技術框架、統一流程管理、提高數據一致性、提高資源利用率、提高服務和技術的標準化、簡化上層應用的開發和運維。

目標架構分為四層：外包資源（IaaS）層、業務運營PaaS平臺層、軟件服務層、復合應用層。并通過集團云門戶統一接入。

（1）外部資源層：目標架構搭建在企業內部虛擬化資源池上，由虛擬化資源池提供設備資源（虛擬機），以及所使用的Oracle、MySQL數據庫。

（2）業務運營PaaS平臺層：Cordys BOP4 平臺是企業內部辦公系統云計算PaaS平臺，為企業信息化提供統一的開發、運維、運營服務，并可以提供文件服務、報表服務、審批單框架服務、任務服務（是與云門戶統一待辦相關的服務）、主數據服務、流程服務、表單服務、用戶組織機構服務、監控服務、接口服務等。

這些服務是在原生服務基礎上進行的本地化，但是不會改造產品本身，特殊個性化仍用原生服務。

系統架構是在傳統PaaS平臺基礎上，提供貼近業務的專業PaaS服務：業務能力組件和技術能力組件。

（3）軟件服務層：在PaaS平臺上，開發軟件服務，在應用服務設計時，合理拆分為易組合的軟件組件服務，以滿足快速開發、實施的需求。整體上規劃出公文管理、通用辦公、流程管理、運維管理四大部分。并使用租戶模型，按分省公司、地市、虛擬組織及應用模式進行部署。服務中間件使用Cordys、Apache HTTP、Java EE。

（4）復合應用：就是展現用戶界面，按目標應用復合軟件組件服務，分別為不同用戶提供不同展現界面。界面技術使用Cordys XForm、HTML/HTML5、JavaScript、JSP等。

#p#

4、統一辦公運營平臺服務能力目標

辦公平臺服務能力由業務運營平臺（原生產品）所提供的服務能力與基于平臺所開發的本地業務化服務能力所組成。服務能力通過API服務（Web Service）與管理控制臺對外提供服務，其中，API服務為快速、規范化開發提供開發服務，控制臺為系統管理員提供系統管理服務，以及為運維人員提供運維服務。

辦公運營平臺服務能力目標如下：

（1）管理目標

通過API服務提供開發規范；

通過管理控制臺支撐系統管理及運維管理規范。

（2）技術目標

提供易用、快速開發基本軟件組件；

平臺原生服務有：目錄服務、流程服務（BPM）、單點登錄服務（SSO）、界面復合服務（CAF）、規則服務（Rule）、主數據管理服務（MDM）、業務活動服務（BAM）、個案管理服務（Case Management）、租戶服務（Tenant）。

基于平臺開發本地化辦公服務有：文件管理服務、信息管理基礎服務、流程管理基礎服務、菜單管理服務、權限安全服務、系統運維服務、系統接口服務、統一組織目錄服務、統一任務服務、用戶組織/角色服務、個人工作臺服務。

5、辦公化平臺服務能力設計方案

辦公化平臺服務能力是基于原生PaaS平臺產品，根據業務特點進行二次開發封裝的、更貼近業務的服務組件，用以支撐業務快速搭建實施，以及集中運維管理，其中，很多服務能力更多是為共享服務（組件）、開發規范、便于運維管理而設計，在實際落地設計開發時可以酌情處理，以實用化為主，根據項目工期、投入而定。能力服務有API、接口界面、控制臺構成，這里所設計內容主要是PaaS層的技術能力組件。

5.1、文件管理服務

文件管理服務是對文件生命周期及存儲、備份的基礎服務，是統一平臺上的文件管理規范和文件管理開發規范。

（1）文件的存儲

文件的存儲，原則上由應用模塊自行管理，也可以進行統一存儲管理。統一文件存儲管理需要文件管理服務器，以及需要規劃存儲空間。如果按統一文件存儲管理方案可以使用虛擬化資源中的存儲。文件存儲在文件系統中，并對文件名進行編碼，以防文件重名沖突。

（2）文件生命周期管理

文件生命周期管理是對文件的創建、修改、備份、銷毀進行管理，管理方案舉例如下：

創建文件，也就是系統上傳文件，提供規范API服務，由API服務記錄文件保存地址、時間等信息，文件信息相見文件屬性。上傳、下載操作，原則上由應用模塊自行管理，本服務只提供記錄上傳文件信息；

修改文件，實質是替換文件操作，過程可以描述如下：下載文件、修改（在個人客戶端）、自動備份原文件、上傳文件；

備份文件，是在系統平臺上，把文件拷貝到另一個文件系統中，并記錄相關操作信息；

銷毀文件，是先把文件移到垃圾箱，過了規定時間，系統按日期自動清理垃圾文件，防止誤操作，由此，引出另一個功能，恢復垃圾文件功能。

（3）文件的屬性信息

文件名稱、類型、存儲目錄、所屬業務（應用模塊）、創建時間、修改時間、業務ID、文件大小等。

（4）文件應用目錄管理

文件應用目錄管理是管理文件存儲目錄（文件系統上，含IP地址）與業務應用模塊對應關系，并提供按應用模塊查詢目錄、按目錄查詢應用模塊的功能。

（5）功能設計

創建文件、修改文件、備份文件、修改文件、文件應用目錄管理、存儲目錄管理。

5.2、通用信息管理基礎服務

通用信息管理基礎服務，是對通用信息分類、發布、展現、傳播的管理、控制。

（1）通用信息專欄

在辦公系統環境中，通用信息專欄是多個專題通用信息的集合，例如：客戶服務簡報、投訴通報、資料庫、論壇組成的客戶服務專欄。

（2）信息界面布局管理

是指信息內容展現界面的布局管理，例如信息專欄的左中右三行三列布局，再例如專題信息上下圖文混搭布局。信息界面布局管理包括信息專欄界面布局模板管理和信息展現模板管理。

信息專欄界面布局模板管理，就是為了快速開發信息專欄業務，根據業務現狀事先編制好的不同風格的信息專欄界面，界面中的具體欄目主題可以更換，提示文字可換，界面的色彩通過CSS皮膚可調換。主要功能有模板查詢目錄、模板使用情況、創建信息專欄界面等，以及欄目中信息專題的展現。

信息展現模板，就是為了快速實現信息展現業務，根據業務現狀梳理，事先編制不同風格、主題的信息展現界面，界面中信息主題可以更換，界面的色彩通過CSS皮膚可調換。主要功能有模板查詢目錄、模板使用情況、創建信息展現界面等。

（3）信息發布模板管理

信息發布模板包括信息發布流程管理和界面發布模板。信息發布流程模版是指信息發布需要編輯、校稿、審核管理過程，有的可以直接發布，嚴格的走流程，在業務實現時選擇相應的管理流程。界面發布模版是指發布文字、圖片、多媒體、圖文混排等信息內容的模版，其中，界面上的提示文字應可以配置。

（4）信息互動管理

信息互動是管理論壇、評論模版，以及管理互動信息管理控制臺，例如有審核、刪除評論等功能。

（5）靜態信息管理

靜態信息管理是管理靜態網頁、動畫頁面等資源，提供共享靜態信息目錄、靜態信息生命周期管理、使用情況、訪問記錄/日志等功能和管理手段。

（6）數據信息定義管理

數據信息定義管理是指數據上報功能的基礎模版管理，數據項名稱、格式可配置，展現形式通過模版來提供，并可以定義匯總配置。

（7）信息分類管理

信息分類管理，一是定義信息基礎分類，例如：文字、圖片、多媒體、靜態、文件、圖文混排、數字等；二是業務使用信息模版的記錄。

#p#

5.3、流程管理基礎服務

流程管理基礎服務簡稱流程服務，是對原生BPM流程的二次封裝，使其更加貼近業務，以及流程審批單基礎框架。從流程配置管理上看，需要支撐流程模版、流程圖、流程規則的分級管理與控制。

5.3.1 流程服務

（1）任務處理功能

任務處理功能是在工作流基礎上，與流程業務及任務相結合的基礎功能，可以在不同業務流程中復用。舉例說明表現形式，例如審簽單上的退回、追回按鈕，就是這里的任務處理功能。下圖是推薦參考以前項目的任務處理功能。

 

（2）流程流轉記錄及展現服務

提供統一的流程流轉記錄服務，并提供標準的展現界面。

5.3.2 工作流管理

（1）工作流目錄管理

管理生產環境上的所有工作流，形成管理列表，列表信息包括：流程名稱、使用者（應用模塊）、關聯表單、創建時間、版本號等。

（2）工作流模版管理

建立工作流模版列表，使用方法（含業務流程圖），提供追加、導出流程配置等功能，例如順序十步主流程模版、并發自流程模版等。

（3）工作流生命周期管理

管理流程的生命周期，流程的生命周期可以分為如下幾個階段：

• 第一階段，流程建模階段
• 第二階段，流程模擬階段

在流程設計完成后，需要通過模擬運行來發現流程的關鍵路徑、瓶頸和需要改進的地方。

• 第三階段，流程實現階段

流程實現階段需要將靜態的流程定義轉化為可執行的動態的流程，供下一階段流程部署與執行。

• 第四階段，流程部署與執行階段

流程定義在這一階段被部署到流程管理系統引擎，通過人工與系統的交互達成業務流程的流轉并充分利用流程管理系統的功能使業務價值達到最大化。

• 第五階段，流程監控階段

在流程執行過程中，相關業務績效指標需要在此階段被收集、分析，為業務流程的優化提供數據。

5.3.3 審簽單管理

（1）審批單目錄管理

管理系統中所有審批單，生成審批單目錄列表，管理審批單生命周期。

（2）審批單模板管理

管理系統中所有審批單模板，可以創建、到處審批單包（或代碼），管理審批單模板生命周期。

審批單模板規劃可以使用下面幾種原則，一是按數據存儲方式，單數據庫表（Table）審批單，主從表的審批單二是按審批單內容，文本型審批單，數字型審批單。按此組合規劃審批單模板。

（3）審批單擴展開發

審批單擴展開發，主要是針對模板以外審批單的個性化開發，見下一章節“審批單分析與設計”。

5.3.4 審批單分析與設計

（1）審批單界面分析

如上圖所示，界面分為4個核心功能區域：

功能按鈕區：放置業務審批單功能按鈕的區域，按鈕可以分成三種類型：流程專用、業務專用、混合功能；
特殊功能區：用于個性化業務、流程功能所使用功能按鈕、下拉列表等；
業務表單區：放置具體業務單據的區域，文件類業務可以隱藏此部分內容；
審批意見區：是可以設置成顯隱的區域，用于顯示審批意見，對于文件類業務，直接顯示個性化審批單。

（2）按鈕功能分析及設計

以“保存”按鈕為例，保存操作在不同環節所實現的功能是不一樣的，例如：申請時保存操作核心是插入并保存業務單據數據，而審批過程中，一般對業務數據是很少操作的，因此，在其他流程環節中，“保存”操作可能只是保存審批意見，以及操作流程，因此設計方案可以有兩個：

方案一：直接在界面中開發“保存”按鈕功能，再根據環節判讀，執行不同的功能；

方案二：在不同環節中使用不同的函數（方法），替換執行其“保存”操作，相當于有很多保存按鈕定義在界面中，這樣需要定義按鈕，按鈕也就相當于接口，動態加載類（代碼），按環節定義來執行代碼。

（3）審批意見填寫的設計方案

方案一：審批單上直接顯示意見填寫輸入框，通過“保存”或“送出”按鈕直接保存意見內容；

方案二：單獨設置審批意見操作按鈕，或送出中隱含，此功能相當于新開意見輸入窗口，進行意見填寫操作。

學習發微博方式填寫意見，實時反饋還可以輸入多少個字符，防止出現多寫保存不上的問題。講個故事，某天省公司老總批文填寫意見，寫了700多字，提交保存時被告知超限，沒了！還好，系統有個后臺日志功能記錄了此事，否則，不知有多少人挨罵了。

 

（4）審批單數據規則設計

審批單上的數據項分為顯示/隱藏、讀/寫等控制規則，也包括顯示樣式、數據有效性等控制規則，以及數據回寫控制等等。

（5）審批單框架設計

審批單框架是設計核心，在辦公平臺上形成固化模板，內嵌入業務表單。

5.4、菜單管理服務

菜單管理服務，是統一管理辦公平臺上所有的功能模塊和相關層級關系。

（1）功能菜單列表，列表信息包括功能名稱、功能簡介、業務分類、關鍵字、上線時間、版本、使用租戶等；

（2）菜單（某應用模塊）生命周期管理，包括菜單添加（應用上線）、版本更新、撤銷菜單、銷毀等；

（3）菜單簿管理

菜單簿管理，是管理業務應用組合，例如：通用辦公（root節點），下面有公告、通知、會議室、車輛管理等子項目，公告下面還有起草、發布等子項目。菜單簿本身也是一個集合，把多個應用系統的菜單集中統一管理，也是為了共享功能模塊。

5.5、權限安全服務

通過對系統平臺產品的二次封裝，快速提供安全管理服務。

（1）權限管理

（2）身份認證管理

身份認證管理，主要是針對非平臺產品接入認證管理，建立外部接入系統列表，并進行有效的監控管理。

（3）數據安全管理

管理OLE DB/JDBC接入數據庫用戶和密碼，定期進行更換。

#p#

5.6、系統運維服務

（1）數據維護

數據維護是系統運維人員使用的功能，摒棄早先直接到數據庫修改數據的不規范操作，由平臺提供規范的數據維護界面，維護內容通過數據適配接口進行配置提供。相應的功能有：維護專題管理、數據查詢定位、修改數據、數據恢復等。

（2）數據適配接口

配置數據維護專題及具體維護的數據表，以及數據處理規則，原則上不允許刪除數據。

（3）維護日志管理

系統運維工作要留有痕跡，或者是系統自動記錄操作日志，或者是通過管理工具記錄操作日志，并且每周形成維護周報。

（4）維護權限管理

維護權限分三級，一級是應用模塊管理員，處理其管理界面的維護工作，例如應用模塊的角色管理；二級是系統運維人員，例如進行數據維護工作；三級是最高級維護，可以直接深入平臺進行維護，但相應的維護工作要有工作協調單和維護報告。

（5）任務維護

任務維護主要是指與門戶待辦接口，以及系統平臺待辦消息故障的日常維護管理。其中，任務稽核功能是門戶與系統任務管理核對任務，如有異常，則有任務維護進行處理；另外，系統平臺流程服務與應用模塊間也要有任務稽核，出現問題也要進行處理。

（6）流程維護

流程維護分為流程日常管理和流程異常維護，流程日常管理通過工作流管理、流程管理等控制臺界面進行工作；流程異常維護依賴于系統平臺，通過系統平臺提供工具進行維護工作。

5.7、系統接口服務

系統接口服務包括外部接口和內部接口，并為內外接口制定接口規范。辦公化平臺對接口信息進行集中統一管理，并進行監控。外部接口主要有：集團公文網關、門戶接口、短信接口、云數字檔案接口、跨域接口等；內部接口有：文件服務器接口、數據庫接口、地市公文網關接口、異構系統接口等。

（1）外部接口規范

對外提供標準的Web Service接口API。

（2）內部接口規范

內部接口主要是通過API服務方式提供。

（3）接口適配服務

辦公系統上應用模塊使用統一接口規范API，API通過參數識別實際接口，進行自動適配。

（4）接口使用情況管理

展現接口使用者列表，以及每個接口運行情況，并標示出異常接口。

（5）接口配置

配置管理實際接口，例如配置IP地址、端口號、用戶、密碼等。每個接口一套配置。對每個接口進行如下管理：一是創建接口、二是維護、三是形成接口列表目錄，并能自動獲取接口的使用者（指應用模塊）。

（6）接口日志

接口啟停、傳遞信息都應詳細的記錄日志，并對日志進行監控管理，日志信息定期人工或自動清理。

5.8、統一組織目錄服務

辦公系統平臺為平臺上所有應用模塊提供統一賬號、組織目錄服務，并負責與云門戶4A同步用戶賬號信息，組織目錄統一維護管理，主要功能有：

（1）添加用戶賬號

（2）組織目錄管理

（3）提供用戶賬號查詢驗證服務，提供組織目錄及相關人員查詢服務。

5.9、統一任務服務

統一任務服務主要是管理流程待辦和待閱消息兩部分內容，這兩部分內容應從底層分開，需要集中監控、分別管理。

5.9.1 待辦任務管理

在流程流轉產生待辦任務，以及待辦狀態更新時，流程服務PUSH數據到統一待辦中。

（1） 按流程定義業務應用消息數據項推送待辦到云平臺統一待辦接口中；

（2） 推送流轉待辦消息包含業務自定義業務信息URL；

（3） 按流程消息ID推送更改待辦狀態請求。

下圖以啟動流程或送出下一步為例，介紹任務管理。

任務服務需要功能有：門戶接口調用服務、任務稽核服務、待辦或辦結任務展現。

5.9.2 待閱消息管理

待閱消息是指點到點的信息發布信息、評價信息、催辦信息，他們的特別是不通過流程服務產生的消息。待閱消息量比較大，需要進行有效的管理。因此對消息進行分級、待閱/閱畢查詢、處理時效監控管理等。

（1）消息分級管理

對消息按業務、人員崗位，分為非常重要、重要、普通等三級管理。

（2）待閱/閱畢查詢

（3）處理時效監控管理

5.10、用戶組織及角色服務

用戶組織及角色服務是管理用戶信息、組織信息和角色信息，最主要的是管理應用模塊中的組織、角色，以及虛擬組織。

（1）用戶信息管理

管理用戶辦公基本信息，例如：辦公電話、手機、郵箱、微博、愛好等，除了賬號、姓名、性別外，其他信息可以自行維護。

（2）組織結構管理

本地組織結構管理與統一組織目錄要嚴格區分開，本地組織結構管理僅是為應用模塊提供個性化服務的。原則上，應用模塊應使用統一組織目錄，但在統一組織目錄無法滿足需求時，不是通過擴展統一組織目錄功能實現，而是通過本地個性化組織結構管理來提供支撐。

為了共享數據、快速支撐，設計了本地組織結構集中管理，做到盡量復用，主要功能如下：

本地組織結構生命周期管理，管理某組織結構的創建、維護、作廢；
本地組織結構使用者管理，管理應用模塊使用各個組織結構的情況，如果現有的不能滿足，則新建。這里關鍵點是應用模塊與組織結構對應關系，如果某組織結構多個應用模塊使用了，則不能任意變動；
平臺提供統一組織結構接口API，通過參與適配相關組織結構。

（3）虛擬組織管理

虛擬組織管理是本地組織結構管理的擴展，提供虛擬團隊、臨時組等管理，也存在其生命周期管理。

（4）組織使用情況

提供系統平臺中所有組織結構（含虛擬組織）的目錄列表，查詢組織結構的使用者（應用模塊）。

#p#

5.11、通用快速報表服務

（1）報表的定義
常用二維報表格式是由表頭和數據區組成，并很規則，因此報表的表頭可以用樹來描述，如下表所示報表，如果把表的表頭描述成樹，其結果如下圖所示。數據區可以簡單地描述成二維數組。

在圖中，根節點“root”是個虛節點，非葉子節點（B、C）都不對應數據，葉子節點（A、B1、B2、B3、C1、C2、C3）對應報表中的具體數據。對照上表，每個葉子節點對應數據表中的具體數據列（字段名或函數、表達式），也就可以把這些數據列名組成查詢用的SQL語句。

（2）超文本鏈接標示語言（HTML）中表格的描述

在HTML語言中，表格通過標記<table>和<td>表示，對整個表格可以描述成樹狀結構，表格的行與列信息通過參數rowspan、colspan說明，例如：

<td rowspan="2" colspan="2">&nbsp;</td>

此語句表示此單元格由2行2列組成。

如果通過程序生成表格，其單元格位置的計算公式如下：

colspan = 此列下所有的葉子節點

rowspan = 當前行的行數 - 當前樹的深度 + 1

（3）通用快速報表服務管理

通用快速報表服務管理主要功能有：報表生命周期管理（創建、修改、銷毀）、報表目錄列表（應用模塊、創建時間、功能、展現界面、數據來源、數據產生服務等）、報表使用情況等。

5.11.1 通用快速報表生命周期管理

（1）創建報表

按需求和數據源選擇模板，或者自動快速配置來定義報表，按文中所述，分成表頭和數據內容定義。其中，報表數據源分為靜態和動態兩類，由配置適配器自適應控制使用。

（2）報表修改

平臺提供報表修改功能，修改后產生新版本，原報表為歷史數據。

（3）報表應用

把報表加入管理目錄，并發放到相應的應用模塊中使用。

（4）報表銷毀

報表下線停止使用，系統標記為下線，配置數據保留。

5.11.2 報表目錄列表

報表目錄是指系統中所有報表清單的管理，包括個性化開發報表，提供查詢、維護報表目錄列表功能。此功能由系統運維人員使用。

（1）查詢報表目錄

查詢報表目錄功能是與系統應用模塊目錄配合使用，提供兩種視角查詢：一是按應用模塊查詢；二是按報表直接查詢，內容含應用模塊信息。

（2）維護報表目錄

維護報表增刪改在目錄中體現。

5.11.3 數據生成服務

數據生成服務主要是通過規范API服務來實現，此服務負責按定義提取報表展現數據到展現報表中，如果靜態數據已經存在，則越過提取數據處理。如果是動態實時提取數據，則數據生成服務的內容與報表展現內容處理方式一致，例如使用相同的查詢SQL語句。

（1）數據生成服務定義

數據生成服務定義主要是定義提取數據到靜態展現數據表中，如果是動態則獲取報表的定義，并作動態標記。數據生成服務在報表中注冊使用，使用時通過規范API自動適配進行處理。

數據生成服務還包括數據匯總功能，如果數據生成服務中含匯總定義，則報表展現不做處理，否則報表展現時需要按需求進行匯總處理。

（2）數據生成服務管理

主要是管理數據生成服務使用，并監控服務使用狀態。

#p#

5.11.4 報表展現及模板

報表展現可以快速自動生成，也可以按模板展現，根據需求進行開發。

5.11.5 報表模板管理

報表模板主要是體現報表展現樣式，設置多種樣式供選擇。例如：單行表頭模板、多行表頭模板、數據區可以滾動模板等。系統平臺提供報表模板生命周期管理，以及使用情況的管理。

（1）報表模板生命周期管理

（2）報表模板使用管理

5.11.6 報表導出下載

系統平臺提供報表導出Excel格式文件并下載，以及PDF格式文件并下載功能。

5.12、個人工作臺服務

個人工作臺服務是辦公化服務能力中針對個人個性化的基礎服務，提供常用的基礎數據服務API，統一管理個性化配置、使用情況，有效的管控個人行為，推薦出個人工作臺模版，方便用戶使用。

（1）任務管理

提供標準的待辦/在辦任務展現模版。

（2）個性化界面

個性化界面通過模版方式提供，平臺主要是提供對模版的管理，以及基礎資源的提供。（注：此部分不包括個人工作臺業務級應用，具體實現暫定放在陽光大廳中實現，也可能其他地方也用到。）

（3）個人工作臺使用管理

對于個人工作臺的使用，平臺提供集中監管界面。在監管界面中，可以看到所有用的個人工作臺使用情況，包括：選擇模版（含業務級擴展個性化模版）、模版中自助業務應用模塊列表、信息訂閱情況、使用頻率等內容。

6、辦公化平臺服務能力的使用方法

辦公化平臺服務能力的設計是為快速開發應用模塊服務的，也是為運維管理服務，所以，其易用性、規范性是重要的指標。辦公化平臺設計出來的功能是為了使用的，沒有必要開發出花瓶，要的是實用。因此，從使用者的視角，按使用方法提出具體設計要求：

6.1、規范化API服務

規范化的API服務，既包括實際的API（Web Service），也包括可共享的界面、JavaScript函數包，也包括開發規范。這里，需要特別強調開發規范，雖然沒有實際功能，但是是應用模塊、基礎平臺相互溝通、協調的橋梁，千萬不要再自己做自己的，再弄出來一套“煙囪系統”。

規范化API服務主要使用者是開發人員。

規范化API服務的使用，需要使用手冊和案例，需要設計人員提供。

6.2、控制臺

控制臺是辦公化平臺服務能力管控的支撐界面，主要使用者是運維人員。

7、編者后記

上述辦公化平臺服務能力規劃方案內容較多，都實現不易，自定向下瀑布模型開發更是難上加難，因此，建議采用敏捷開發模型，分階段、迭代逐步趨近式開發。最重要的是通過盡早和不斷交付有價值的軟件滿足客戶需要。

本文是作者根據多年項目實施經營總結出來的經驗談，屬于軟件產品規劃設計通用內容，針對性不強，通常是文中部分內容有成功案例，這些內容整合在一起，只做為具體項目規劃方案設計參考，拋磚引玉，歡迎反饋、交流。

原文出自：http://blog.csdn.net/xiaoyw71/article/details/40887707