0 引言

    企業門戶的發展依次經歷了分散的應用系統、企業信息門戶(EIP)、企業知識門戶(EKP)三個階段。美林公司的一份研究報告首次提出信息門戶的概念，認為它是企業管理內部和外部信息資源的應用程序，是為用戶提供進行商業決策所需的個性化信息的唯一途徑。EIP是基于Web的系統，集成企業的所有應用和數據，提供給用戶統一的界面。而企業知識門戶，更關注企業內部員工和信息內容，它是知識管理系統KM與企業信息門戶的結合，其目標是知識生產、知識集成和知識管理。

    EKP的主要功能是管理和組織知識資源并尋找之間的聯系，提供給用戶準確的知識導航和交互環境。此外，宋紹成等認為智能企業門戶是融入智能技術，集中在智能門戶和決策支持兩個方向。然而，無論是企業信息門戶還是企業知識門戶，其基礎架構、實現功能差別不大，都為企業提供了一個單一訪問各種信息資源的入口，無縫集成企業內容，為企業信息系統提供穩定、可靠的架構。國外對于智能企業門戶的研究在系統設計、開發、實驗階段做了大量工作，包括首次提出智能門戶的EOSCENE公司宣稱其產品整合各種ERP、CRM、SCM等系統和信息源，給出了其結構模型、元數據模型、平臺支持技術等相關闡述。但是，總的來說，智能門戶的研究仍然處在研究發展階段，并沒有一個標準的系統論述。實際上，相當多的實施SAP門戶項目的企業其主要軟件產品可以以服務的方式供應或者交付。此類企業對于門戶的智能性有著更迫切的需求，急于尋求一種整合軟件服務流程的門戶解決方案以降低傳統的供應鏈、人力等方面資源耗費，提高效率，增加收益。基于此，如果采用SaaS(軟件及服務)思想改善企業的軟件服務供應流程并整合進企業的門戶之中，對于智能企業門戶的研究與實際應用都有著相當重大的意義。SAP Web Dynpro是一種采用高級的MVC/DataBinding架構模式的Web應用開發工具，允許業務應用程序以獨立于后臺業務平臺以及前端表現層的形式而存在。ABAP是SAP系統的開發語言。本研究將基于SAP平臺企業門戶框架，結合WebDynpro及ABAP語言的功能，采用SaaS思想改善并整合軟件服務流程，實現智能企業門戶的開發。

1 需求實例分析

    假設H公司主要軟件服務是提供對客戶SAP系統的性能、安全、數據三方面分析，幫助客戶減少生產機數據量提高系統性能，減少系統的升級、備份和恢復所需時間，提高數據訪問的安全與高效性，增強數據生命周期的管理，以滿足企業對風險控制、訪問控制、流程控制三大需求。智能企業門戶實施前的軟件服務流程是：H公司顧問將該公司軟件產品安裝在客戶SAP系統上并運行數據采集、分析程序，之后卸載軟件，將分析后的數據帶回公司做成分析報告，再以郵件等方式交付給客戶分析評估結果。基于SaaS思想重新設計該服務供應流程，其結果是：分離出數據采集程序通過企業間安全網絡連接從客戶SAP生產機上抓取所需分析數據，將抓取的數據回傳并導入H公司的SAP服務器運行分析程序，分析服務的結果以商務報告、高級報表等形式置于企業門戶上交付給客戶。據此服務流程可以使客戶方在線瀏覽、下載分析報告，公司業務顧問借助企業門戶實施服務和維護。圖1顯示了此智能門戶開發項目架構圖。

圖1 H公司門戶開發架構圖

    由圖1可知，此門戶的開發工作分為三部分：前端UI的設計和Web應用、后端與SAP系統交互的Web應用以及用戶的權限分配管理與訪問控制。SAPEP的框架提供了對SAP系統極好的集成性，在此框架內，容易實現業務顧問單點登錄多個SAP系統，用戶權限訪問管理也可以通過其提供的配置工具快速實現。Web Dynpro根據開發環境的不同分為Web Dynpro Java(WDJ)和Web Dynpro ABAP(WDA)。在此實例中，前端的應用主要是提供對分析出的數據結果在UI展現方式上的支持，H公司對于前端UI的動態性和美觀度有著較高的要求，希望客戶登錄門戶之后可以以動態的形式查閱報告。考慮到語言的可擴展性，采用Web Dynpro Java嵌入FLASH技術可以達成公司的需求。門戶后端的Web應用主要基于SAP系統，選用Web Dynpro ABAP對應用的穩定性與時間相關性能的表現有著較高的保證。兩者的架構以及開發的過程大體相同，圖2顯示了兩者的運行機制。從圖中可以看出，兩者的應用實現都需要運行在各自的運行時環境之上，并基于對應的網絡協議與后臺服務端提供的相應接口完成底層數據訪問或實現與前端UI的交互。下面就以WDA為例闡述并探討開發方法的設計與實現。

圖2 WebDynpro運行機制

2 WDA的開發與門戶實現

    2.1 WDA的功能分析

    對應圖1中門戶與H公司的SAP服務器交互的部分，結合實例的需求分析，WDA的Web應用主要完成四大功能：客戶維護、服務維護、服務合同維護和數據采集器維護。

    客戶維護 維護客戶方在系統中的主數據，包括為客戶在系統中創建業務伙伴賬號，分配給相應的組織，維護客戶基本信息等。

    服務維護 提供給客戶的各項服務主數據維護，包括服務所屬的項目號、服務運行所在的系統、服務類型、服務狀態等。

    服務合同維護 與客戶簽署服務合同后，需要對合同業務數據進行相應維護，主要包括服務訂單、狀態、所屬客戶方、公司聯系人、客戶的SAP系統、服務條目、每一項條目的具體信息等。

    數據采集器維護 數據采集器是從客戶生產機上抓取所需分析數據的采集程序，對主數據的維護包括采集器名、采集器類型、采集器所屬類、采集器版本、采集器的維護者信息等方面。

    2.2 基于WDA的開發和技術難點的解決

    Web Dynpro ABAP應用程序是依照改進的MVC模型建模的，它沒有具體的Model對象，而是采用如Function Module，Class Method作為業務邏輯的封裝，View負責數據在瀏覽器中的表現，Controller介于view和model之間。Controller格式化顯示在view中的數據，處理用戶的操作，并返回給功能模塊或類的方法。WDA將業務邏輯與顯示邏輯清楚地分開。一個運行在前端的WDA應用通過一個服務訪問本地或遠程的后端系統。這意味著顯示邏輯被包含在WDA應用中，業務邏輯和持久化的業務對象運行在后端系統。WDA采用組件化的開發思想，每一個組件(Component)被視為一個可重用的實體和最基本的功能單位，組件之間可以相互包含，一個應用的實現可以只基于一個組件或是由多個組件組合而成。一個Component負責一個具體業務，它可以通過Componentinterface調用其他組件提供的功能。每一個組件的全局控制器(ComponentController)，為所有視圖提供通用性的服務。開發者可以根據需要創建自身的全局控制器。Controller中則負責處理與屏幕元素的交互，調用模型層業務邏輯等功能。視圖(View)提供對UI的布局(Lay out)以及行為的描述，視圖被嵌入到窗口(Window)中才可以被瀏覽器顯示。因此窗口總是包含一個或多個視圖。窗口是應用的屏幕交互元素的容器，窗口對外表現為接口視圖(Interface view)視圖，同樣的，組件控制器對外表現為接口控制器，然后才可被外部處理。視圖和窗口可以包含輸入和輸出(Outbound，Inbound)Plug，用作導航時的出發點或目標點，視圖間的導航通過在窗口中創建導航鏈接(Navigationlinks)實現。視圖和窗口也具有自身的本地控制器。所有控制器對行為的控制都通過操作其包含的方法(Methods)。WDA的組件模型如圖3所示。

圖3 WDA的組件模型

    在此例中，客戶維護、服務維護、服務合同維護和數據采集器維護四項業務功能每一項分別由一個組件實現。依據圖3的組件模型，開發的過程實際上是對改進的MVC模型每一層的具體實現。考慮到本例的實際應用環境，業務顧問的需求具有較大的不確定性，需求共識需要反復修改才可達成，從而影響到視圖層的元素設計。然而，視圖層的元素設計直接影響模型層中功能模塊或類方法中參數的設計，進而影響到程序代碼的具體實現方式。因此在這里，針對需求不確定度較高的情況，借鑒軟件工程中以需求驅動開發的思想，站在使用者的角度，以需求為第一優先，驅動整個開發過程，按照V-M-C即視圖層-模型層-控制層的開發順序進行開發。

    視圖層的開發 以需求作為驅動，首先進行頁面元素的設計。確定視圖Layout的控件類型，明確業務顧問的業務流程，完成布局的設計。視圖Layout的頁面元素的數據載體實際是該視圖Context中每一個節點的具體屬性，所以之后需要分析頁面元素所對應的數據類型。WDA對顯示邏輯數據承載與傳遞的方法是采用Binding/Mapping的兩級三層的機制。頁面元素所需的數據載體必須先在組件控制器的Context中創建包含相應屬性類型的節點。視圖Context中的所有節點通過從組件控制器的Context中的節點映射而來。映射機制相當于是對本體創建了一個映像，映像與本體之間存在關聯性，任何對映像的修改都會反映到本體中。這樣的設計可以實現對本體數據的實時共享與同步操作，當多個視圖需要實時獲取同一本體進行業務操作時，這樣設計的好處尤其明顯。視圖Context的節點屬性綁定到視圖Layout上之前設計的頁面元素之后，完成數據承載關系的建立。服務合同維護功能的視圖層開發結果如圖4所示。

圖4 服務合同維護的視圖

    模型層的開發 實際上是實現業務邏輯需要的功能模塊和類的開發。功能模塊(FM)是SAP開發語言ABAP所提供的完成某一特定功能的程序模塊，可以被其他程序或者功能模塊所調用，類似于子程序的概念。此部分的開發是整個WDA開發過程中的重點與難點，要在深入理解用戶需求與業務邏輯的基礎上，遵循ABAP的語法規范完成程序的編寫。一段完成部分服務合同維護關鍵功能的FM代碼如下：

    在本例中，每項服務是按照使用次數進行計費的，客戶每次使用服務時的操作流程完全相同，如何獲取客戶對某項服務的使用信息并出于訪問性能的考慮盡量減少變量的使用與流程的跳轉是開發中的一個難點。在此段程序中，引入了一項系統數據從而解決了問題。每當客戶登錄門戶查看分析報告時，系統后臺會自動在當前服務的頁面地址后加入一段唯一的標識RUN_GUID作為本次訪問的記錄。獲取這段含有唯一標識的地址可以作為服務使用次數統計的依據。此段代碼先生成一個服務合同類的對象實例，調用該類的方法得到具體的某一合同所包含的服務信息，并以此為參數傳遞給另一功能模塊完成獲取客戶使用某項服務所生成的所有唯一地址，并存放進一個內存表中，供后續程序處理。

    控制層的開發 WDA包含四種控制器，分別是：組件控制器、視圖控制器、窗口控制器、自定義控制器，通過它們所包含的方法、屬動作等內容實現控制層對顯示邏輯的控制以及模型層與視圖層之間的數據交互。一個單視圖完整功能的WDA開發過程如圖5所示。

圖5 WDA開發過程

    實際上，包括WDA在內，軟件業務流程的開展全部通過Internet實現。H公司提供應用服務并部署其在自身的服務器上，客戶方不再需要購買軟件，而是通過互聯網全天候獲取服務結果，且可以靈活定制所需服務項目，無需對軟件進行維護。此過程取消了傳統的軟件授權費用，免除了客戶服務器硬件、網絡設備、軟件升級維護的支出，僅通過Internet即可獲取所需服務。

    以上正是SaaS理念的體現與價值所在。

    2.3 門戶的實現

    基于以上開發過程，完成了門戶后端客戶維護、服務維護、服務合同維護和數據采集器維護的WDA開發及前端客戶動態訪問分析報告的應用開發，實現了H公司對智能企業門戶的需求。圖6顯示的是該企業門戶。

圖6 門戶

    此門戶結合了企業門戶的信息整合與SaaS架構的思想，將傳統的軟件交付周期流程無縫集成進門戶系統中，這是一般意義門戶系統所不具備的特性。在此門戶內，業務流程的開展擯棄了過多的人工干預，核心功能全部自動實現，無需繁瑣耗時系統配置、人力監控運行過程。最重要的是，通過此門戶項目的實施改進了企業業務流程的方法論，一切基于服務的理念，而不再是傳統的實施、交付、運行、維護，從而實現智能的特性。

3 結語

    本文針對已部署SAP系統的企業對智能企業門戶的需求，給出了利用SAP的Web Dynpro工具進行開發的方法與具體的實現。本研究認為，以下幾點是在開發過程中應著重注意的：

    (1)顯示邏輯與業務邏輯的分離。WDA改進的MVC模型使開發者可以專注于顯示邏輯的開發，業務邏輯應全部通過在后端系統中開發相應的功能模塊或類方法來實現，顯示邏輯的設計中不應包含業務邏輯，降低兩者的耦合度可以極大地降低日后修改維護工作可能的工作量。(2)針對不同的需求業務背景，靈活地選擇開發方式。對于需求多變、不確定性較高的情況，采用需求驅動開發的思想往往能起到較好的效果。對于需求較為清晰的情況，從模型層開始實現是更為普遍認可的方式。(3)組件的可重用性。WDA是基于組件化的開發思想，較為復雜的功能實現可能需要重用多個組件，每一個組件在設計過程中應更多地考慮本身結構的獨立性與對外的接口，便于重用的實現，降低開發量。

    智能企業門戶是企業門戶的發展趨勢，它不再局限于技術工具，更是企業發展的戰略組成。它的理論與實際價值在于：融入的智能思想和技術能夠進一步完善發展門戶整合理論，改善企業的業務流程可以極大提升企業運營水平，并最終促進企業信息化管理體系的不斷創新。

轉載請注明出處：拓步ERP資訊網http://www.guhuozai8.cn/

本文標題：基于SAPERP平臺的智能企業門戶的實現

本文網址：http://www.guhuozai8.cn/html/consultation/1082058031.html