1、企業信息化系統集成方案目 錄 TOC o 1-4 f u 1項目概述 PAGEREF _Toc57140483 h 32詳細規劃方案 PAGEREF _Toc57140484 h 42.1技術實現方案 PAGEREF _Toc57140485 h 42.1.1集成方案 PAGEREF _Toc57140486 h 4技術管理建議方案 PAGEREF _Toc57140487 h 4統一用戶方案 PAGEREF _Toc57140488 h 29統一認證（單點登陸）方案 PAGEREF _Toc57140489 h 30統一待辦任務集成方案 PAGEREF _Toc57140490 h 33消息

2、集成方案 PAGEREF _Toc57140491 h 34移動集成規范方案 PAGEREF _Toc57140492 h 36UI規范方案 PAGEREF _Toc57140493 h 38項目概述通過架構頂層設計和統一管理，加強數據共享和業務協同、支撐未來業務快速上線。對于財務核算系統建設的總體目標，理解主要包括以下兩個方面：提升集團“財務服務能力”：基于統一核算規則，全流程貫通，全面協同，提升管理效率，降低管理成本，支持財務轉型；提升集團“財務管控能力”：一套系統、集中部署，落實全集團核算過程的統一，利用主數據、合并報告等手段，整體提升集團層面集中管控能力。具體來看，本期工程重點要達成以

3、下目的：建設集中化的財務核算系統，通過集團統一核算規則及管控規則的集中固化，替換原總部及各工程局、專業公司、設計院等子屬分散部署的財務核算系統；與資金系統、報賬系統集成，形成業財協同和財財融合體系，實現核算自動化，提升交易處理效率；實現總部、各工程局、專業公司、設計院等子屬之間的關聯交易協同，提升對賬準確性和及時率；與合并系統集成，實現對外披露報表的自動化，實現全集團報表一點出具；與預算系統、資金系統、稅務系統集成，提升財務專業運營能力，支撐管理會計體系的構建，助力財務轉型。通過上述目標的達成，最終實現“縱向上，集團管理貫穿所有組織層級，實現縱向信息穿透、管理一體化；橫向上，業務橫向貫穿業務部

4、門，實現業財協同；決策上，實現一個、一副面孔，一個數據口徑、一套決策體系” 的集中化財務管理平臺。詳細規劃方案技術實現方案集成方案技術管理建議方案客戶化開發工具及擅長的開發內容建議：ORACLE 開發工具優點劣勢XML PUBLISHERE擅長報表格式比較固定的報表；可以提供多種輸出方式：EXCEL,PDF,WORD,HTML等；可以做出與所提供報表格式比較一致的報表不擅長維度分析型報表；需采用請求方式提交報表，查詢結果不是很直觀BIEE擅長分析型報表，可對各分公司或項目放在一張報表中進行分析；多種展現形式：儀表盤，圖表等可導出成EXCEL可以使用ORACLE ERP一些內置模型進行報表開發和

5、展現；標準的數據倉庫技術需進行數據的ETL轉換將數據抽取到數據倉庫數據建模、開發工作量比較大一般不用來展現實時數據得單獨購買硬件、軟件。DBI擅長非復雜結構的報表展現，如一些單個指標類的數據；處理格式簡單的二維表比較容易。支持圖形和報表相結合進行展現可以輸出成excel數據展現部分開發方式容易掌握，業務人員都可進行報表展現調整。商務智能模塊已經預置一些指標和報表不支持格式復雜的固定報表如貴公司提供樣例中的項目成本管理報表；不支持多維度分析型報表，不支持維度拖拉拽的方式，如多個分公司或多個項目的數據橫行展示。輸出數據不是很直觀，操作者需改變查詢習慣。另外，ORACLE自帶的查詢可能與企業需求不相

6、符。WEB PAGE（OAF）符合ORACLE ERP產品未來發展趨勢；純WEB操作，簡單易用；查詢和展示比較靈活；可以在展示時進行復雜的業務邏輯轉換和運算；適合實時數據的查詢；可以開發出進行數據追溯等的復雜功能可實現對于一些需要進行數據錄入才能出來的報表的數據錄入和維護輸出界面比較直觀，與ORACLE標準功能界面也比較一致。開發的工作量比較大對于多維度分析型報表不支持需轉換展現方式對于輸出格式的支持力度不強，需要額外的進行開發。客戶化開發管理： 需求調研需求調研的最主要目的是明確開發內容，其次是評估開發耗費的人工時，并做出合理的開發計劃。其間應當遵循以下基本出發點：以實施方案為基準滿足方案中

7、確定的流程需求技術可行性參與人員與職責調研工作需要由開發人員、實施顧問、關鍵用戶、最終用戶完成。其中職責分配如下：關鍵用戶、最終用戶按照業務情況提出需求實施顧問對照實施方案確定該需求是否符合方案要求，是否必要開發人員確定該需求在技術實現上的可能性，做出初步實現方案，并對耗費的人工時作出預估需求一般是由關鍵用戶、最終用戶提出的。但在項目實施的初期，用戶由可能并不是完全對方案確定的流程、系統能夠提供的功能有透徹的了解，故此提出的需求往往是基于以往的工作經驗，以及原有系統的功能。對此，需要實施顧問按照實施方案的要求來判斷該需求是否合理、必要。這一步驟上，實施顧問應從滿足最基本的業務流程出發，對需求作

8、出過濾，減少開發不必要、或者是不是很迫切的功能。在經過實施顧問的過濾后，開發人員應對其技術實現的可能性、風險性作出評估。一般來說，只要需求是在邏輯上合理的，在技術上就有實現的可能。但開發人員應當注意到某些開發的風險性，如對底層數據庫的直接操作、對原有程序的修改等。由于沒有使用標準的接口、修改后程序可能被PATCH覆蓋等因素，我們不能支持此類開發能夠在任何時候支持百分之百的正確，故此應當作為潛在風險向客戶提出，并要求獲得客戶的確認。在確定開發內容后，開發人員應初步確定技術實現的大致方案，如整體框架、實現工具，并對需要的人工時作出預估，進而作出開發計劃。調研文檔需求調研的結果體現為調研文檔，其中包

9、含2項內容：開發方案及人工時預估、開發計劃。開發方案及人工時預估此文檔應涵蓋以下方面：開發整體構架開發項目列表實現工具人工時預估潛在風險此文檔需要經過實施方、客戶方項目經理的簽字認可后才可生效，并轉入下一步的開發工作。開發計劃開發計劃基于前一文檔中對開發人工時的預估。在考慮實際投入的開發資源后，排出具體的進度，用以控制開發的正常進行。此文檔中應明確：開發工作的結束時間。由于系統上線可能分若干個階段，故此也可再進行細分，并據此對每一時間段的開發工作進行明確，即為支持該階段系統上線所需要的開發任務能夠完成，將次要的開發任務推遲或取消。每一項開發任務的起始日期和結束日期。每一項開發任務上投入的人力資

10、源（即指定開發人員）。此文檔推薦使用MS PROJECT編寫。調研階段的結束調研工作以提交調研文檔，并獲客戶簽字認可為結束標志。實際開發工作開始后，應支持方案的穩定性、權威性，不得隨意修改。任何涉及整體構架、流程的變更需按照需求變更流程實現。功能設計在經過調研階段的初步討論和最終方案的指導下，需要將需求以盡可能詳盡的文字表達出來，即形成功能設計。參與人員與職責此文檔要求編寫者對ERP系統有較深入的了解，熟悉系統的操作風格，并按照ORACLE APPLICATION的標準術語來對希望實現功能進行描繪。功能設計需要由實施顧問完成，或者在實施顧問的指導下由關鍵用戶完成。文檔要求此文檔的基本要求是：詳

11、盡、準確、用語標準。此文檔應當向它的閱讀對象，即技術設計人員，描繪以下信息：該程序的業務背景（實施方案）、業務目的該程序的主要功能，如分析打印目標數據、生成目標數據該程序的界面表現，如輸出紙張大小、字段格式、排序方法、參數內容該程序的操作步驟此文檔中的用語應當符合原有系統程序的標準，并在操作風格上與之保持一致。功能設計的確認功能設計需要由技術設計人員審閱，確認其提出的每一細節均符合整體方案規范、符合程序標準、可以在程序中實現。對于技術設計人員認為可能引起歧義的地方，需要修改文檔，作出明確解釋。確認無誤后，須由客戶方和技術設計人員簽字人可，并將此文檔歸檔。已歸檔的功能設計在技術設計開始后，除非邏

12、輯結構有重大變化，否則不得隨意更改。其更改辦法參見需求變更流程。在以上基礎上方可轉入下一開發階段。技術設計按照需求設計的要求，以程序的語言描述該功能是如何實現的，即形成技術設計。參與人員與職責此文檔的編寫者應當是有開發經驗的技術人員，并應具備以下條件：了解ERP系統的構架了解ERP系統的程序實現方法了解ERP系統的各種開放接口了解Developer 10g、SQL等開發工具編寫者應結合功能設計的具體要求，選擇合適的開發工具，設計合理的邏輯結構，并對實現中的細節作出說明。文檔要求技術設計文檔應當涵蓋以下幾方面的內容：使用的開發工具程序的標準命名（如程序名、參數名、對象名等）程序所需參數的設置（如

13、類型、長度等）程序的邏輯流程（如流程圖、偽代碼等）細節功能的實現（如對象屬性設置、某字段的取值方法等）數據庫中所需的對象（如新建的VIEW、SEQUENCE等）ERP系統中必要的設置（如參數所用值集、預置文件等）開發工具的選擇主要基于實現的難度、與ERP系統的整合性。一般來說主要使用原有ERP系統的開發工具（Developer 10g, PL/SQL, java等）。ERP系統中的程序命名均有一定的標準，客戶化的程序也應當遵循，以保持與原系統的風格一致。技術設計中要使用盡可能詳細的程序語言來表述邏輯設計思想。其中可是用流程圖等工具，此外還可以編寫偽代碼。需要注意的是，偽代碼并不需要詳細到每個S

14、QL語句的具體寫法，而只是需要表明設計意圖即可。設計人員應當給代碼編寫人員留出一定的空間，方便其在實現代碼時作靈活的修改。對于需要在數據庫、ERP系統中新建對象、做必要設置等工作，技術設計應當做出詳細的描述。代碼編寫人員不得對此部分內容進行修改。此文檔對應于AIM中的MD070，并以此編號，可參照其標準格式。技術設計的確認技術設計文檔完成后，交開發人員確認，并轉入代碼編寫階段。代碼編寫依據技術設計所示的邏輯結構，將其翻譯成真正的程序，即代碼的編寫。參與人員與職責代碼編寫人員應具備以下條件：對ERP系統的構架有一定的了解熟悉Developer 2k/6i、SQL等開發工具的使用代碼編寫人員應遵循

15、技術設計中明確的邏輯結構，將其用具體的真實代碼再現。程序要求代碼編寫人員在具體的開發工作中應遵循以下要求：嚴格遵循技術設計中的邏輯結構在代碼的實際寫法中可有靈活的修改代碼規范應符合“ORACLE APPLICATION開發員手冊”中的要求注意代碼的性能 代碼編寫的完成程序開發完成后，開發人員須作初步的測試，支持程序可正常運行后，再交由測試人員進行測試。代碼測試參與人員與職責參與代碼測試的人員主要為提出需求的關鍵用戶或實施顧問、代碼開發人員。參照功能設計文檔，需求提出人員檢查程序是否符合所提出的要求；當發現問題時，及時反饋給代碼開發人員，由其負責修改代碼。整個測試過程按照“測試-修改-再測試”的

16、循環進行，直至問題均解決。文檔要求測試文檔應當涵蓋如下內容：測試方法測試數據測試日志測試方法與測試數據將依據功能設計、技術設計而編寫。根據程序的復雜程度，測試方法與測試數據的內容詳細程度可不同，簡單的程序只要闡述出測試方法和所預期的結果既可；復雜的程序則要設計詳細的測試步驟、測試數據。測試日志用于記錄測試中出現的問題，以及解決結果。測試人員與開發人員循環檢查該文檔，并根據需要進行修改、填寫。此文檔對應于AIM中的TE020/TE040，并以此編號，可參照其標準格式。測試階段的結束測試階段將以所有測試均順利通過、所有發現的問題均解決為結束標志。安裝手冊及用戶手冊參與人員與職責安裝手冊由技術設計人

17、員或代碼開發人員編寫。用戶手冊由功能設計人員編寫。文檔要求安裝手冊應當涵蓋以下內容：安裝環境必要的application設置必要的數據庫對象代碼的復制、編譯其他的注意事項安裝手冊對應于AIM中的MD120，并以此編號，可參照其標準格式。用戶手冊依據功能設計編寫，應當涵蓋以下內容：相關的業務背景運行程序的步驟用戶手冊對應于AIM中的DO070，并以此編號，可參照其標準格式。需求變更變更流程需求的變更往往是造成開發任務無法及時完成的重要原因，所以在前期應充分全面地考慮開發需求及方案，盡量避免在開發過程中對需求進行反復的修改。在必須進行變更的情況下，則按照以下原則、流程進行：已確認的方案、設計不可隨

18、意更改需求的變更申請須使用標準文檔提交變更申請文檔需要經過客戶、顧問雙方的經理簽字確認后，方可實施修改需求變更后，必須按照以下順序逐個修改相應文檔、程序：修改整體方案修改功能設計修改技術設計修改程序代碼修改測試文檔，重新測試修改安裝手冊、用戶手冊文檔要求需求變更文檔對應于AIM中的CR060，并以此編號，可參照其標準格式。相關工具的使用本節講述在二次開發工作中可使用的若干工具。開發計劃及進度控制軟件目前使用的開發計劃及進度控制軟件為 MicroSoft Project。使用該軟件可方便地進行維護開發列表、跟蹤開發進度等工作。開發匯總表為了更好的管理開發項目中的文檔和代碼，要求各個項目均有一份開

19、發匯總表。該文檔用EXCEL編寫，其包含如下列內容：所屬模塊（如PO、FA、GL等）程序中文名、中文描述程序類型（如FORM、REPORT、SQL腳本、PL/SQL存儲過程等）程序名（程序文件名、相關腳本文件名等）總體方案文檔名功能設計文檔名技術設計文檔名安裝手冊文檔名用戶手冊文檔名編碼標準本節講述在OA開發中應遵循的編碼標準。具體內容分以下3部分：CODING原則標準開發環境命名標準CODING原則進行OA開發，首先必須遵循以下原則：代碼要保持良好的可讀性和可維護性代碼要支持在繁忙網絡條件下仍然擁有良好的性能代碼要有良好的可重用性代碼要有良好的跨操作平臺能力盡量使用FORM、PL/SQL等工

20、具完成所有的編碼（盡量避免使用其它編程語言編寫復雜的用戶出口函數）代碼要保持良好的可讀性和可維護性在FORM的開發過程中，對TABLE、ITEM等對象盡量地使用HANDLER進行操作。使用HANDLER可以避免代碼分散在大大小小的TRIGGER中，對代碼進行集中管理。有利于開發、維護及調試。代碼要支持在繁忙網絡條件下仍然擁有良好的性能在網絡條件下要支持程序的良好性能，其關鍵在于減少網絡流量。代碼盡可能地在服務器端完成盡可能地在本地取得所需變量代碼要有良好的可重用性將可重用的代碼以庫的形式保存在數據庫中FORM中，可重用的代碼應盡量寫成單獨的PROCEDURE代碼要有良好的跨操作平臺能力避免直接

21、對操作平臺中的對象進行操作使用APP_STANDARD.PLATFORM函數包校驗是否存在依賴操作系統平臺的代碼標準開發環境OA為開發者提供了一系列的工具，并用豐富的預定義資源組成了便利的開發環境。開發者在工作中需要加以注意使用，以加快開發速度和提高代碼質量。命名標準良好的命名方法能夠使得程序保持良好的易讀性，便于后期的維護工作。所以在開發過程中，必須依據以下規則對各個對象命名，盡量避免使用如misc、common、other等籠統的對象名。技術文檔交付和管理方案 技術文檔管理原則技術文檔特指與項目有關的各類資料，包括文件、通知、項目交付品、會議演示資料、發放的資料、宣傳資料、錄像、錄音等；技

22、術文檔的管理遵循如下原則：技術文檔特指與項目有關的各類資料，包括文件、通知、項目交付品、會議演示資料、發放的資料、宣傳資料、錄像、錄音等；必須基于項目的標準模版、命名規則和存儲要求；分發的確認和會簽的文件，必須建立跟蹤記錄；所有文件創建人、審核人、修改人都必須在文件的修改記錄內登記；所有簽字的文件必須完整地保留在項目的文件夾內；所有文件模板的建立與改動集中管理，實施文檔和日常項目管理文檔模板及其命名規則的建立和改動分別由專人負責；文檔存儲要求：應使用光盤或紙張（硬拷貝）等介質進行應用程序、數據及相應文檔的存儲；文檔編寫要求：文檔的編寫應符合中國國家標準及集團制定的有關標準和規定的要求；提交數量

23、：根據要求提交紙質文檔若干份，和一份以光盤為介質的電子文檔。技術文檔工具本項目將主要使用以下版本的文檔處理與查看軟件，以支持項目管理：Microsoft Word 2010文本文檔；Microsoft Excel 2010表格/數據文檔/項目計劃；Microsoft Powerpoint 2010演示/匯報；Microsoft Project 2010項目計劃；Microsoft Visio 2010流程描述；技術文檔安全技術文檔將在項目共享目錄下保存。技術文檔將作為項目工作成果，由項目管理小組指定專人負責備份。技術文檔一旦通過批準，則被標記為Final版本，將被保存。Final版本的文檔如需

24、變更，應按照嚴格的變更管理程序執行，并由項目管理小組負責管理文檔編碼的控制。技術文檔清單整個項目實施過程中，項目組提交的文檔以簡體中文編寫。階段名稱呈交文件/成果內容文檔編碼一建立實施策略質量計劃(包括范圍，目標，和方法)這份文檔概括描述了項目的各項工作的構成和總體框架。包括：系統結構、培訓、設計、數據轉換、項目組織、變更流程、項目風險與規避以及項目的關鍵目標CR.010/SOA項目工作計劃項目計劃：包含項目明細任務、資源分配、各里程碑的目標日期和關鍵路徑CR.PMP二業務流程分析未來業務流程模型未來業務流程圖定義了每個業務的流程及其子流程。主要為了定義遠景目標、重要特點和未來的業務流程藍圖。

25、BP.080業務要求差異文件所有業務需求和已定流程的匯總BR.030三設計解決方案系統設置文件根據方案匹配結果，滿足需求的Oracle產品各模塊功能設置明細記錄文檔BR.100四建立應用系統個別程序測試計劃，數據，與結果按照數據轉換和技術規格說明書的要求，每個程序完成后進行單元測試（包括測試數據和結果），要求是很完整的單元測試TE.020集成測試計劃，數據，與結果類似于單元測試報告的內容TE.040用戶測試認可證明書來自用戶的滿意度（對單個模塊）測試證明TE.UAC五系統切換系統切換方案新舊系統切換的方案、失敗回退方案系統切換計劃詳細切換步驟、時間安排系統切換報告切換后的成果報告六運行維護培訓

26、手冊類似于用戶手冊，但內容側重在培訓方面DO.070用戶手冊用戶手冊包含的內容：系統實施后，買方要進行的日常操作流程的描述TR.010系統投產驗收清單清單內容包含：所有的可提交結果或推廣前要達到并接受的所有里程碑PM.PAC實施推廣計劃一份計劃：包含實施時間、過程、期限、數據轉換計劃和驗收方法PM.010系統轉換計劃與數據一份計劃：包含所有轉換數據的提取時間、轉換次序和驗收方法CV.010系統投產驗收測試在數據轉換完成，系統已準備就緒，準備切換上線的驗收測試PM.PAT七項目結束項目實施總結報告系統實施后，實施回顧和用買方數據來驗證的一份總結報告項目初驗報告初驗運行情況、存在問題及其解決時間安

27、排項目初驗證書項目已通過初步驗收的證書項目終驗報告系統運行及試運行情況、初驗遺留問題解決情況項目終驗證書項目已通過最終驗收的證書八項目管理變更申請表項目周工作進度報告項目月工作進度報告會議紀要報告工時表項目管理過程文件CR.CRFCR.PWSCR.PMSCR.PMICR.PWS文檔傳遞規則為規范技術文檔的傳遞，建立完整、統一的文檔發出、接收、抄送程序，以方便項目人員參考，特制定本規則。本項目所進行的文檔傳遞須按此規則執行。項目組在項目管理過程中指定一名項目文檔管理員，具體的工作職責如下：負責項目文檔的收集和匯總；負責項目文檔的分類整理，并根據編碼規則對項目小組成員交付文檔的命名進行審核和修改；

28、負責項目文檔按類別和編碼進行存檔和更新，并做好文檔記錄工作；根據項目經理的審核，進行項目文檔的相互傳遞和確認工作；負責項目文檔編碼的維護，包括編碼新增、刪除和更改，并及時進行相互間的通報；根據項目經理的審核，進行項目文檔的內部傳遞或抄送工作；項目小組的各級成員都必須積極配合項目文檔管理員的工作。文檔查閱管理凡涉及項目有關的文檔均屬于保密范疇。文檔資料按照公開的對象不同分為三級：項目經理及以上人員可以查閱且不能公開的資料為第一級；項目組成員可以查閱且不能公開的資料為第二級；公司所有員工均可以查閱的資料為第三級。項目相關的資料統一存放在公共服務器上，指定專人負責維護服務器，支持穩定運行、足夠的存儲

29、空間和數據安全。公共服務器上的資料按照級別對用戶進行管理。公共服務器上的資料由項目管理小組專人負責維護，需要及時更新。項目小組成員應嚴格遵守保密制度。技術開發流程 公司的Oracle ERP客戶化開發方法論如下：為了支持客戶化的開發質量，減少不必要的開發成本，加速知識轉移的進程度，所有的客戶化的開發都必須遵守下面的具體開發流程。每一個客戶化都有完整的生命周期，在項目的實施過程中，我們采用EXCEL模板方式的客戶化清單來評估開發的工作量，管理和控制開發的進度，根據項目實施的具體要求來調整客戶化的優先級等。模板示例如下：在ERP系統的開發工作中，客戶化開發將根據需要進行四個層面的測試。單元測試盡管

30、不要單獨交付，開發者還是需要對每個客戶化開發做單元測試。開發者將負責定義單元測試的Check List。單元測試將驗證程序的功能符合功能需求文檔，以及適當的異常操作。單元測試重點在從各個方面測試一塊代碼。開發者應該將重點放在錯誤處理。比如，當測試定制表單時，開發者應該放些特殊字符到所有字段盡可能讓表單去處理。單元測試一般由開發者自己執行。集成測試將客戶化開發放到業務流程中，進行端到端的測試，支持整個流程產生的結果是正確的。集成測試一般由功能顧問、關鍵用戶和開發人員共同執行。用戶接受度測試用戶接受測試執行一個“生命中的普通一天”的測試場景。例如，用戶執行每天，每星期，每月的普通工作流程。用戶接受

31、測試將驗證客戶化功能符合功能需求文檔。用戶接收測試通過后，客戶化開發才可以部署到生產環境。技術層面測試技術層面的測試包括：壓力測試和補丁程序測試。這些測試一般不針對某個具體的客戶化程序。技術方面的知識轉移為了實現技術知識的快速轉移，我們提供全面的開發人員技能培訓，針對集團技術人員基礎比較好的特點，可以適當減少簡單的數據庫知識和操作系統知識的培訓，增加專業性更強的各種開發工具培訓，如下圖所示：具體培訓內容如下：簡單的數據庫知識了解數據庫的技術架構，了解數據庫進程作用學習編寫SQL語句學習如何簡單優化SQL語句簡單的操作系統知識會簡單的系統操作如；cd，ls，cp等命令，會起停系統 會對源程序進行

32、編譯ERP各種開發工具FORM，REPORTXML PUBLISHERJava, OAF以及Jdeveloper等 PL/SQL.ERP系統管理知識如何管理用戶、管理職責 如何管理功能、管理請求； 如何檢查系統基本信息，如表單對應的后臺源程序等ERP系統各模塊的數據結構各模塊本身的數據結構 各模塊間數據關聯關系 ERP各模塊的功能總帳：如何錄入憑證；如何查找余額應收應付：如何創建發票，如何進行收款、付款等 庫存、采購、銷售、人力、項目、制造等模塊的基本功能操作ERP系統架構系統整體架構 系統運行原理 了解系統包含的組件及技術路線 采用的培訓方式見下表：客戶化開發工具在ERP系統的實施過程中，由

33、于本土化、個性化,以及集成上的需要,必然存在對標準產品的客戶化開發。在此我們對Oracle ERP客戶化工具、技術,客戶化，集成技術以及我們將來可能面對的部分接口做一下說明:客戶化開發工具ORACLE DEVELOPER SUITEOracle Developer Suite提供了很多功能，用以構建各種互聯網應用程序和由商務智能功能增強的Web服務。 Oracle Developer Suite可滿足所有事務處理應用程序開發和商務智能的需要。如何使用Oracle Developer Suite和使用哪些工具，這取決于終端用戶的需要、開發人員的技能和技術背景等。該套件中所包括的各個具體組件列于下

34、圖，并將在下面各節具體介紹。 圖： Oracle Developer Suite 的各個組件應用程序開發：Oracle JDeveloper 是一種結合了Java、XML和SQL技術的，用于開發高質量的J2EE應用程序和Web服務的集成開發環境（Integrated Development Environment，IDE）。Oracle JDeveloper支持完整的開發生命周期，包括：建模、編碼、調試、性能剖視、優化和部署。 Oracle JDeveloper還可以作為單獨的產品，用于滿足Java開發人員的需要。Oracle JDeveloper 是Oracle應用服務器Java版的一個組成

35、部分。 Oracle Forms Developer是一種說明性的快速應用程序開發（Rapid Application Development，RAD）工具，PL/SQL開發人員在無需用Java編碼的情況下，可以使用它構建高度交互式的基于Java的Web客戶端程序。 Oracle Designer是一種用于構建完整的應用程序和數據庫的建模和生成工具。它還能夠逆向設計現有的Oracle和非Oracle數據庫，來創建Oracle數據庫模型。 Oracle軟件配置管理器（Oracle SCM）是一種用于存儲所有與應用程序開發過程相關的文件和對象，并進行版本控制的軟件配置管理資源。Oracle SCM

36、與Oracle Developer Suite中的所有開發工具集成在一起。 商務智能： Oracle Developer Suite包括各種通過商務智能功能增強事務處理應用程序的性能，以便更深入地理解有關數據的商務智能工具。 Oracle Warehouse Builder（OWB）是一種企業數據集成工具，它提供一種經濟有效、可伸縮和易于使用的數據提取、轉換和加載工具，使數據庫管理員和開發人員能更快、更高效地設計和構建商務智能應用程序。 Oracle Reports Developer 是一種說明性的企業報表編制工具，可用于通過使用能夠以任何形式安全地發布到任何目的地的數據源來創建精確的報表。

37、 Oracle Discoverer提供一種直觀的特定查詢、報表編制和分析工具，用以滿足終端用戶簡化信息訪問的需要。 Oracle Business Intelligence Beans （Oracle BI Beans）提供一套基于標準的可重復使用的JavaBean組件，用于快速用Java實現高級分析型應用程序。 Oracle Workflow builder 提供了一個察看，修改，建立工作流的圖形化工具（不是developer suite 的組件）Oracle XML Publisher 是Oracle提供的報表開發工具，將數據邏輯，版式和頁面翻譯分離開來，技術人員專注數據邏輯的實現，業務

38、人員可使用OFFICE工具進行版式的設計更加貼近用戶的需求。同時提供多種輸出方式EXCEL,PDF,WORD,HTML等，適應不同用戶的需要。Oracle Developer Suite的主要優勢 Oracle Developer Suite具有以下主要優勢，以支持更好、更快、更經濟高效地開發互聯網應用程序和Web服務： 完整性 集成化 基于標準 Oracle Developer Suite提供一整套功能，可以滿足多種要求。它基于最新的行業標準，是一套集成化的、可協同工作并與Oracle數據庫和Oracle應用服務器高度集成的組件。完整性Oracle Developer Suite以單一套件的

39、形式提供一套最完整的工具。其所提供的工具能夠支持任何語言（Java、XML和SQL），以及從建模、說明性方法到3GL編碼的任何開發風格。 本產品覆蓋開發生命周期的所有階段：建模、設計、編碼、編譯、調試、源控制、部署、調優和監控。 Oracle Developer Suite還可以用在任何操作系統平臺上，包括 Windows、Unix或者Linux。使用這個套件構建的應用程序能夠運行在任何類型的設備上，如臺式機、瀏覽器、移動電話或者掌上設備。 集成化Oracle Developer Suite提供了三種類型的集成：Oracle Developer Suite提供的各種工具之間的集成、與Oracl

40、e應用服務器的集成，以及與Oracle數據庫的集成。 Oracle Developer Suite中有大量的集成。Oracle Designer能夠生成包括Oracle Forms在內的完整的應用程序。現有的Forms能夠被逆向設計成Designer環境。Oracle Designer生成Business Components for Java，以便用于Oracle JDeveloper項目。Oracle JDeveloper已集成了對Oracle BI Beans的支持，以便在J2EE應用程序中實現強大的商務分析功能。除了與Oracle Designer和Oracle Forms Devel

41、oper的集成以外，Oracle SCM還與Oracle JDeveloper集成，從而使開發人員能夠只需一次點擊即可實現對源的控制操作，如版本控制和依賴性管理等。這種集成使開發團隊能夠很容易做到組織有序，并能夠甚至在最分散的開發項目中密切合作。 盡管Oracle Developer Suite對其他遵循JDBC和ODBC的數據庫是開放的，但是，它是完全重新開發的，以便與Oracle數據庫協同工作并充分利用Oracle數據庫的獨特功能。可以使用Oracle開發人員早已熟悉的諸如SQL、PL/SQL、Java和XML等語言和工具來構建數據庫驅動的網站和商務應用程序。Oracle Develope

42、r Suite已經過測試并通過了Oracle數據庫各個版本的驗證，并且由一個單一的支持機構進行支持。 作為應用程序部署平臺，Oracle Developer Suite還提供與Oracle應用服務器的在線集成。通過一次點擊部署的方法，Oracle使得在其平臺上構建高性能應用程序的工作變得簡單易行。此外，使用Oracle JDeveloper構建的應用程序能夠輕松地部署在任何其他符合J2EE規范的應用服務器上。這是Oracle對開放性作出貢獻的集成優勢的真實寫照。 基于標準Oracle Developer Suite是根據Oracle對開放式體系結構的承諾以及通過支持標準和趨勢推動互聯網發展的承

43、諾而開發的。Java的可移植性和通用性是Oracle Developer Suite的核心。此外，經過認證Oracle JDeveloper 符合最新的J2EE規范。Oracle Developer Suite支持的標準包括J2EE、XML、SQL和Web服務標準（即：SOAP、UDDI、WSDL和JAXR），以及其他諸如UML、XMI和WebDAV等重要的行業標準。其他系統客戶化開發開發過程中，公司不會使用有版權或知識產權問題控件、第三方插件等。統一用戶方案公司根據本次項目特點并結合已成功實施的多個項目經驗，建議本次項目采用CAS作為單點登錄系統，所有支持單點技術的系統，只需登錄一次，統一登

44、錄平臺，告別繁復的登錄界面。CAS框架：CAS（Central Authentication Service）是實現SSO單點登錄的框架，由耶魯大學開發的單點登錄系統（SSO，single sign-on），應用廣泛，具有獨立于平臺的，易于理解，支持代理功能。該系統提供強大的用戶管理和認證中心功能，通過IDENTITY SERVER服務器完成統一用戶認證，登錄、認證請求，然后分發到相應應用，認證的同時在服務器和客戶端生成證書，支持鏈接的私密性和安全性，系統使用java Access Manager管理各接入系統的接入驗證。CAS提供以下功能及服務：訪問服務： SSO 客戶端發送請求訪問應用系統

45、提供的服務資源。定向認證： SSO 客戶端會重定向用戶請求到 SSO 服務器。用戶認證：用戶身份認證。發放票據： SSO 服務器會產生一個隨機的 Service Ticket 。驗證票據： SSO 服務器驗證票據 Service Ticket 的合法性，驗證通過后，允許客戶端訪問服務。傳輸用戶信息： SSO 服務器驗證票據通過后，傳輸用戶認證結果信息給客戶端。CAS系統服務端會接收并集成統一用戶中心的用戶信息，在本次項目范圍內的系統都不單獨維護用戶信息，用戶信息通過接口定時同步本地數據。CAS系統目前在公司其他的多個大型項目中都得到廣泛應用，目前已經有與Oracle ERP，Peoplesof

46、t，用友，和各主流OA產品的集成的成功案例。統一認證（單點登陸）方案單點登陸功能描述單點登陸由應用服務和數據庫服務（數據庫占用空間較小）組件組成，根據用戶業務特點，實現負載均衡、7*24小時部署方式、易維護、易擴展、高可用性、高安全、節約成本等。單點登錄應用服務采用兩臺雙機，加http負載均衡硬件設備；單點登錄數據庫采用兩臺Oracle RAC方式實現負載均衡部署方式；存儲兩臺互備方式，且存儲可與其他系統共享。CAS單點登陸的特性：開源的、多協議的SSO解決方案；Protocols：Custom Protocol、CAS、OAuth、OpenID、RESTful API、SAML1.1、SAM

47、L2.0等。支持多種認證機制：Active Directory、JAAS、JDBC、LDAP、X.509 Certificates等；安全策略：使用票據（Ticket）來實現支持的認證協議；支持授權：可以決定哪些服務可以請求和驗證服務票據（Service Ticket）；提供高可用性：通過把認證過的狀態數據存儲在TicketRegistry組件中，這些組件有很多支持分布式環境的實現，如：BerkleyDB、Default、EhcacheTicketRegistry、JDBCTicketRegistry、JBOSS TreeCache、JpaTicketRegistry、MemcacheTick

48、etRegistry等；支持多種客戶端：Java、.Net、PHP、Perl、Apache、uPortal等。CAS有服務器端和客戶端兩部分：服務器端 CAS Server：服務器端作為統一認證的地方，所以各個系統的用戶要統一。CAS支持目前業界幾種主流的認證方式：共享cookies基于共享同域的cookie是Web剛開始階段時使用的一種方式，它利用瀏覽同域名之間自動傳遞cookies機制，實現兩個域名之間系統令牌 傳遞問題；另外，關于跨域問題，雖然cookies本身不跨域，但可以利用它實現跨域的SSO。如：代理、暴露SSO令牌值等。缺點：不靈活而且有不少安全隱患，已經被拋棄。Broker-b

49、ased(基于經紀人)這種技術的特點就是，有一個集中的認證和用戶帳號管理的服務器。經紀人給被用于進一步請求的電子身份存取。中央數據庫的使用減少了管理的代價，并為認證提供 一個公共和獨立的第三方。例如Kerberos、Sesame、IBM KryptoKnight（憑證庫思想)等。Kerberos是由麻省理工大學發明的安全認證服務，已經被UNIX和Windows作為 默認的安全認證服務集成進操作系統。Agent-based（基于代理人）在這種解決方案中，有一個自動地為不同的應用程序認證用戶身份的代理程序。這個代理程序需要設計有不同的功能。比如，它可以使用口令表或加密密鑰來自動地將 認證的負擔從用

50、戶移開。代理人被放在服務器上面，在服務器的認證系統和客戶端認證方法之間充當一個翻譯。例如SSH等。Token-based例如SecureID,WebID，現在被廣泛使用的口令認證，比如FTP、郵件服務器的登錄認證，這是一種簡單易用的方式，實現一個口令在多種應用當中使用。基于網關基于SAMLSAML(Security Assertion Markup Language，安全斷言標記語言）的出現大大簡化了SSO，并被OASIS批準為SSO的執行標準。開源組織OpenSAML實現了SAML規范。客戶端 CAS Client：負責處理對客戶端受保護資源的訪問請求，需要登錄時，重定向到 CAS Serv

51、er。CAS client支持非常多的客戶端，包括Java, .Net, PHP, Perl, Apache, uPortal, Ruby等單點登錄系統的Web應用。CAS實現單點登錄具體機制CAS包含兩個部分：CAS Server 和CAS Client需要獨立部署，主要負責對用戶的認證工作；CAS Client負責處理對客戶端受保護資源的訪問請求，需要登錄時，重定向到CAS Server.圖：CAS最基本的協議過程：CAS Client 與受保護的客戶端應用部署在一起，以Filter方式保護 Web 應用的受保護資源，過濾從客戶端過來的每一個 Web請求，同時， CAS Client會分析

52、HTTP 請求中是否包請求 Service Ticket，如果沒有，則說明該用戶是沒有經過認證的，于是，CAS Client會重定向用戶請求到，如果用戶提供了正確的Credentials， CAS Server 會產生一個隨機的 Service Ticket，然后，緩存該 Ticket ，并且重定向用戶到CAS Client（附帶剛才產生的Service Ticket）， Service Ticket 是不可以偽造的，于是CAS Client和 CAS Server之間完成了一個對用戶的身份核實，用Ticket查到 Username ，因為 Ticket是 CAS Server產生的，因此，所

53、以 CAS Server 的判斷是毋庸置疑的。該協議完成了一個很簡單的任務，所有與CAS的交互均采用SSL協議，確保ST和TGC的安全性。協議工作過程會有2此重定向過程，但是CAS Client與CAS Server之間進行ticket驗證的過程對于用戶是透明的。統一待辦任務集成方案集成范圍和功能用戶認證基于統一用戶進行用戶身份驗證，實現移動辦公與企業已有的應用的SSO單點登錄，只需要知道用戶的Login Name，其他人員信息如密碼、頭像等都可以忽略。待辦事項處理系統支持對各類待辦事項進行提醒、催辦，含各類文件會簽與審批等數據的推送消息推送系統支持對重要信息和自定義信息進行系統推送、瀏覽重點

54、關注：與財務門戶相關功能的信息推送集成技術架構ERP系統與財務門戶系統之間的接口實現財務門戶與ERP業務流程的集成，主要用于業務系統向門戶推送待辦任務和狀態消息，此接口開發工作由ERP系統與財務門戶系統共同完成。原則是利用財務門戶的集中展示優勢，提高系統用戶的系統體驗和工作效率。ERP系統與財務門戶的接口實現采用SOA WebService方式實現，具體實現如下圖所示：消息集成方案公司根據多個大型集團性企業的項目經驗和本次項目的需求，建議消息集成采用MQ產品+消息網關開發的集成方案。 HYPERLINK /item/%E6%B6%88%E6%81%AF%E9%98%9F%E5%88%97 t

55、_blank 消息隊列（MQ）是一種應用程序對應用程序的通信方法。應用程序通過讀寫出入隊列的消息（針對應用程序的數據）來通信，而無需專用連接來鏈接它們。消息傳遞指的是程序之間通過在消息中發送數據進行通信，而不是通過直接調用彼此來通信，直接調用通常是用于諸如 HYPERLINK /item/%E8%BF%9C%E7%A8%8B%E8%BF%87%E7%A8%8B%E8%B0%83%E7%94%A8 t _blank 遠程過程調用的技術。隊列的使用除去了接收和發送應用程序同時執行的要求。RabbitMQ是一個在 HYPERLINK /item/AMQP t _blank AMQP基礎上完成的，可復

56、用的企業消息系統，遵循Mozilla Public License HYPERLINK /item/%E5%BC%80%E6%BA%90%E5%8D%8F%E8%AE%AE t _blank 開源協議。選擇RabbitMQ主要基于以下兩大需求考慮：消息的集中管理和發放，可以實現一個消息多個抵達目標系統的集中管理消息消費端的靈活處理，可以對消息進行重復發送，丟棄等各種靈活處理企業級應用，在多個超大型互聯網企業已經有成功的實施案例集成范圍和功能用戶認證基于統一用戶進行用戶身份驗證，實現移動辦公與企業已有的應用的SSO單點登錄，只需要知道用戶的Login Name，其他人員信息如密碼、頭像等都可以忽

57、略。消息排隊系統支持Cache、硬盤、數據庫等多種消息隊列存儲方案，能有效防止消息的丟失和異常；支持排隊的多種策略；消息推送及路由系統支持對重要信息和自定義信息進行系統推送、瀏覽重點關注：與財務門戶相關功能的信息推送；支持多目標系統的統一發放；支持自定義的消息路由； 消息處理系統支持對消息的靈活處理策略，用戶可以根據消息的用途選擇失敗重復發送或失敗丟棄等方式；與消息消費端的網關接口集成可以實現消息處理多種方式，例如郵件，短信和APP使用集成技術架構RabbitMQ與主要用于各業務系統向外發布消息使用，此接口集成需要各消息的消費系統共同完成。原則是消息的發放和使用能做到有效管理和集中處理，提高系

58、統用戶的系統體驗和工作效率。RabbitMQ的系統架構及具體實現如下圖所示：圖：RabbitMQ系統架構圖公司本次提出的集成方案中RabbitMQ負責需要發送消息的接收存放，排隊，路由和錯誤處理，各消費端網關負責消息的渠道發送和展示。以下是本次項目中RabbitMQ需要集成的網關：財務門戶消息處理網關手機短信消息處理網關企業郵件處理網關移動平臺消息處理網關移動集成規范方案公司本次項目的移動集成與開發的功能支持基于IOS和安卓操作等系統移動應用，滿足對內及對外兩個層次。對內基于移動平臺搭建，對外基于H5的輕量APP開發，所有數據接口采用Web service技術，符合REST+Json接口標準。集成范圍和功能用戶認證基于統一用戶進行用戶身份驗證，實現移動辦公與企業已有的應用的SS