0 引言
企業(yè)門戶的發(fā)展依次經(jīng)歷了分散的應(yīng)用系統(tǒng)、企業(yè)信息門戶(EIP)、企業(yè)知識門戶(EKP)三個階段。美林公司的一份研究報告首次提出信息門戶的概念,認為它是企業(yè)管理內(nèi)部和外部信息資源的應(yīng)用程序,是為用戶提供進行商業(yè)決策所需的個性化信息的唯一途徑。EIP是基于Web的系統(tǒng),集成企業(yè)的所有應(yīng)用和數(shù)據(jù),提供給用戶統(tǒng)一的界面。而企業(yè)知識門戶,更關(guān)注企業(yè)內(nèi)部員工和信息內(nèi)容,它是知識管理系統(tǒng)KM與企業(yè)信息門戶的結(jié)合,其目標是知識生產(chǎn)、知識集成和知識管理。
EKP的主要功能是管理和組織知識資源并尋找之間的聯(lián)系,提供給用戶準確的知識導航和交互環(huán)境。此外,宋紹成等認為智能企業(yè)門戶是融入智能技術(shù),集中在智能門戶和決策支持兩個方向。然而,無論是企業(yè)信息門戶還是企業(yè)知識門戶,其基礎(chǔ)架構(gòu)、實現(xiàn)功能差別不大,都為企業(yè)提供了一個單一訪問各種信息資源的入口,無縫集成企業(yè)內(nèi)容,為企業(yè)信息系統(tǒng)提供穩(wěn)定、可靠的架構(gòu)。國外對于智能企業(yè)門戶的研究在系統(tǒng)設(shè)計、開發(fā)、實驗階段做了大量工作,包括首次提出智能門戶的EOSCENE公司宣稱其產(chǎn)品整合各種ERP、CRM、SCM等系統(tǒng)和信息源,給出了其結(jié)構(gòu)模型、元數(shù)據(jù)模型、平臺支持技術(shù)等相關(guān)闡述。但是,總的來說,智能門戶的研究仍然處在研究發(fā)展階段,并沒有一個標準的系統(tǒng)論述。實際上,相當多的實施SAP門戶項目的企業(yè)其主要軟件產(chǎn)品可以以服務(wù)的方式供應(yīng)或者交付。此類企業(yè)對于門戶的智能性有著更迫切的需求,急于尋求一種整合軟件服務(wù)流程的門戶解決方案以降低傳統(tǒng)的供應(yīng)鏈、人力等方面資源耗費,提高效率,增加收益;诖,如果采用SaaS(軟件及服務(wù))思想改善企業(yè)的軟件服務(wù)供應(yīng)流程并整合進企業(yè)的門戶之中,對于智能企業(yè)門戶的研究與實際應(yīng)用都有著相當重大的意義。SAP Web Dynpro是一種采用高級的MVC/DataBinding架構(gòu)模式的Web應(yīng)用開發(fā)工具,允許業(yè)務(wù)應(yīng)用程序以獨立于后臺業(yè)務(wù)平臺以及前端表現(xiàn)層的形式而存在。ABAP是SAP系統(tǒng)的開發(fā)語言。本研究將基于SAP平臺企業(yè)門戶框架,結(jié)合WebDynpro及ABAP語言的功能,采用SaaS思想改善并整合軟件服務(wù)流程,實現(xiàn)智能企業(yè)門戶的開發(fā)。
1 需求實例分析
假設(shè)H公司主要軟件服務(wù)是提供對客戶SAP系統(tǒng)的性能、安全、數(shù)據(jù)三方面分析,幫助客戶減少生產(chǎn)機數(shù)據(jù)量提高系統(tǒng)性能,減少系統(tǒng)的升級、備份和恢復所需時間,提高數(shù)據(jù)訪問的安全與高效性,增強數(shù)據(jù)生命周期的管理,以滿足企業(yè)對風險控制、訪問控制、流程控制三大需求。智能企業(yè)門戶實施前的軟件服務(wù)流程是:H公司顧問將該公司軟件產(chǎn)品安裝在客戶SAP系統(tǒng)上并運行數(shù)據(jù)采集、分析程序,之后卸載軟件,將分析后的數(shù)據(jù)帶回公司做成分析報告,再以郵件等方式交付給客戶分析評估結(jié)果;赟aaS思想重新設(shè)計該服務(wù)供應(yīng)流程,其結(jié)果是:分離出數(shù)據(jù)采集程序通過企業(yè)間安全網(wǎng)絡(luò)連接從客戶SAP生產(chǎn)機上抓取所需分析數(shù)據(jù),將抓取的數(shù)據(jù)回傳并導入H公司的SAP服務(wù)器運行分析程序,分析服務(wù)的結(jié)果以商務(wù)報告、高級報表等形式置于企業(yè)門戶上交付給客戶。據(jù)此服務(wù)流程可以使客戶方在線瀏覽、下載分析報告,公司業(yè)務(wù)顧問借助企業(yè)門戶實施服務(wù)和維護。圖1顯示了此智能門戶開發(fā)項目架構(gòu)圖。
圖1 H公司門戶開發(fā)架構(gòu)圖
由圖1可知,此門戶的開發(fā)工作分為三部分:前端UI的設(shè)計和Web應(yīng)用、后端與SAP系統(tǒng)交互的Web應(yīng)用以及用戶的權(quán)限分配管理與訪問控制。SAPEP的框架提供了對SAP系統(tǒng)極好的集成性,在此框架內(nèi),容易實現(xiàn)業(yè)務(wù)顧問單點登錄多個SAP系統(tǒng),用戶權(quán)限訪問管理也可以通過其提供的配置工具快速實現(xiàn)。Web Dynpro根據(jù)開發(fā)環(huán)境的不同分為Web Dynpro Java(WDJ)和Web Dynpro ABAP(WDA)。在此實例中,前端的應(yīng)用主要是提供對分析出的數(shù)據(jù)結(jié)果在UI展現(xiàn)方式上的支持,H公司對于前端UI的動態(tài)性和美觀度有著較高的要求,希望客戶登錄門戶之后可以以動態(tài)的形式查閱報告?紤]到語言的可擴展性,采用Web Dynpro Java嵌入FLASH技術(shù)可以達成公司的需求。門戶后端的Web應(yīng)用主要基于SAP系統(tǒng),選用Web Dynpro ABAP對應(yīng)用的穩(wěn)定性與時間相關(guān)性能的表現(xiàn)有著較高的保證。兩者的架構(gòu)以及開發(fā)的過程大體相同,圖2顯示了兩者的運行機制。從圖中可以看出,兩者的應(yīng)用實現(xiàn)都需要運行在各自的運行時環(huán)境之上,并基于對應(yīng)的網(wǎng)絡(luò)協(xié)議與后臺服務(wù)端提供的相應(yīng)接口完成底層數(shù)據(jù)訪問或?qū)崿F(xiàn)與前端UI的交互。下面就以WDA為例闡述并探討開發(fā)方法的設(shè)計與實現(xiàn)。
圖2 WebDynpro運行機制
2 WDA的開發(fā)與門戶實現(xiàn)
2.1 WDA的功能分析
對應(yīng)圖1中門戶與H公司的SAP服務(wù)器交互的部分,結(jié)合實例的需求分析,WDA的Web應(yīng)用主要完成四大功能:客戶維護、服務(wù)維護、服務(wù)合同維護和數(shù)據(jù)采集器維護。
客戶維護 維護客戶方在系統(tǒng)中的主數(shù)據(jù),包括為客戶在系統(tǒng)中創(chuàng)建業(yè)務(wù)伙伴賬號,分配給相應(yīng)的組織,維護客戶基本信息等。
服務(wù)維護 提供給客戶的各項服務(wù)主數(shù)據(jù)維護,包括服務(wù)所屬的項目號、服務(wù)運行所在的系統(tǒng)、服務(wù)類型、服務(wù)狀態(tài)等。
服務(wù)合同維護 與客戶簽署服務(wù)合同后,需要對合同業(yè)務(wù)數(shù)據(jù)進行相應(yīng)維護,主要包括服務(wù)訂單、狀態(tài)、所屬客戶方、公司聯(lián)系人、客戶的SAP系統(tǒng)、服務(wù)條目、每一項條目的具體信息等。
數(shù)據(jù)采集器維護 數(shù)據(jù)采集器是從客戶生產(chǎn)機上抓取所需分析數(shù)據(jù)的采集程序,對主數(shù)據(jù)的維護包括采集器名、采集器類型、采集器所屬類、采集器版本、采集器的維護者信息等方面。
2.2 基于WDA的開發(fā)和技術(shù)難點的解決
Web Dynpro ABAP應(yīng)用程序是依照改進的MVC模型建模的,它沒有具體的Model對象,而是采用如Function Module,Class Method作為業(yè)務(wù)邏輯的封裝,View負責數(shù)據(jù)在瀏覽器中的表現(xiàn),Controller介于view和model之間。Controller格式化顯示在view中的數(shù)據(jù),處理用戶的操作,并返回給功能模塊或類的方法。WDA將業(yè)務(wù)邏輯與顯示邏輯清楚地分開。一個運行在前端的WDA應(yīng)用通過一個服務(wù)訪問本地或遠程的后端系統(tǒng)。這意味著顯示邏輯被包含在WDA應(yīng)用中,業(yè)務(wù)邏輯和持久化的業(yè)務(wù)對象運行在后端系統(tǒng)。WDA采用組件化的開發(fā)思想,每一個組件(Component)被視為一個可重用的實體和最基本的功能單位,組件之間可以相互包含,一個應(yīng)用的實現(xiàn)可以只基于一個組件或是由多個組件組合而成。一個Component負責一個具體業(yè)務(wù),它可以通過Componentinterface調(diào)用其他組件提供的功能。每一個組件的全局控制器(ComponentController),為所有視圖提供通用性的服務(wù)。開發(fā)者可以根據(jù)需要創(chuàng)建自身的全局控制器。Controller中則負責處理與屏幕元素的交互,調(diào)用模型層業(yè)務(wù)邏輯等功能。視圖(View)提供對UI的布局(Lay out)以及行為的描述,視圖被嵌入到窗口(Window)中才可以被瀏覽器顯示。因此窗口總是包含一個或多個視圖。窗口是應(yīng)用的屏幕交互元素的容器,窗口對外表現(xiàn)為接口視圖(Interface view)視圖,同樣的,組件控制器對外表現(xiàn)為接口控制器,然后才可被外部處理。視圖和窗口可以包含輸入和輸出(Outbound,Inbound)Plug,用作導航時的出發(fā)點或目標點,視圖間的導航通過在窗口中創(chuàng)建導航鏈接(Navigationlinks)實現(xiàn)。視圖和窗口也具有自身的本地控制器。所有控制器對行為的控制都通過操作其包含的方法(Methods)。WDA的組件模型如圖3所示。
圖3 WDA的組件模型
在此例中,客戶維護、服務(wù)維護、服務(wù)合同維護和數(shù)據(jù)采集器維護四項業(yè)務(wù)功能每一項分別由一個組件實現(xiàn)。依據(jù)圖3的組件模型,開發(fā)的過程實際上是對改進的MVC模型每一層的具體實現(xiàn)?紤]到本例的實際應(yīng)用環(huán)境,業(yè)務(wù)顧問的需求具有較大的不確定性,需求共識需要反復修改才可達成,從而影響到視圖層的元素設(shè)計。然而,視圖層的元素設(shè)計直接影響模型層中功能模塊或類方法中參數(shù)的設(shè)計,進而影響到程序代碼的具體實現(xiàn)方式。因此在這里,針對需求不確定度較高的情況,借鑒軟件工程中以需求驅(qū)動開發(fā)的思想,站在使用者的角度,以需求為第一優(yōu)先,驅(qū)動整個開發(fā)過程,按照V-M-C即視圖層-模型層-控制層的開發(fā)順序進行開發(fā)。
視圖層的開發(fā) 以需求作為驅(qū)動,首先進行頁面元素的設(shè)計。確定視圖Layout的控件類型,明確業(yè)務(wù)顧問的業(yè)務(wù)流程,完成布局的設(shè)計。視圖Layout的頁面元素的數(shù)據(jù)載體實際是該視圖Context中每一個節(jié)點的具體屬性,所以之后需要分析頁面元素所對應(yīng)的數(shù)據(jù)類型。WDA對顯示邏輯數(shù)據(jù)承載與傳遞的方法是采用Binding/Mapping的兩級三層的機制。頁面元素所需的數(shù)據(jù)載體必須先在組件控制器的Context中創(chuàng)建包含相應(yīng)屬性類型的節(jié)點。視圖Context中的所有節(jié)點通過從組件控制器的Context中的節(jié)點映射而來。映射機制相當于是對本體創(chuàng)建了一個映像,映像與本體之間存在關(guān)聯(lián)性,任何對映像的修改都會反映到本體中。這樣的設(shè)計可以實現(xiàn)對本體數(shù)據(jù)的實時共享與同步操作,當多個視圖需要實時獲取同一本體進行業(yè)務(wù)操作時,這樣設(shè)計的好處尤其明顯。視圖Context的節(jié)點屬性綁定到視圖Layout上之前設(shè)計的頁面元素之后,完成數(shù)據(jù)承載關(guān)系的建立。服務(wù)合同維護功能的視圖層開發(fā)結(jié)果如圖4所示。
圖4 服務(wù)合同維護的視圖
模型層的開發(fā) 實際上是實現(xiàn)業(yè)務(wù)邏輯需要的功能模塊和類的開發(fā)。功能模塊(FM)是SAP開發(fā)語言ABAP所提供的完成某一特定功能的程序模塊,可以被其他程序或者功能模塊所調(diào)用,類似于子程序的概念。此部分的開發(fā)是整個WDA開發(fā)過程中的重點與難點,要在深入理解用戶需求與業(yè)務(wù)邏輯的基礎(chǔ)上,遵循ABAP的語法規(guī)范完成程序的編寫。一段完成部分服務(wù)合同維護關(guān)鍵功能的FM代碼如下:
在本例中,每項服務(wù)是按照使用次數(shù)進行計費的,客戶每次使用服務(wù)時的操作流程完全相同,如何獲取客戶對某項服務(wù)的使用信息并出于訪問性能的考慮盡量減少變量的使用與流程的跳轉(zhuǎn)是開發(fā)中的一個難點。在此段程序中,引入了一項系統(tǒng)數(shù)據(jù)從而解決了問題。每當客戶登錄門戶查看分析報告時,系統(tǒng)后臺會自動在當前服務(wù)的頁面地址后加入一段唯一的標識RUN_GUID作為本次訪問的記錄。獲取這段含有唯一標識的地址可以作為服務(wù)使用次數(shù)統(tǒng)計的依據(jù)。此段代碼先生成一個服務(wù)合同類的對象實例,調(diào)用該類的方法得到具體的某一合同所包含的服務(wù)信息,并以此為參數(shù)傳遞給另一功能模塊完成獲取客戶使用某項服務(wù)所生成的所有唯一地址,并存放進一個內(nèi)存表中,供后續(xù)程序處理。
控制層的開發(fā) WDA包含四種控制器,分別是:組件控制器、視圖控制器、窗口控制器、自定義控制器,通過它們所包含的方法、屬動作等內(nèi)容實現(xiàn)控制層對顯示邏輯的控制以及模型層與視圖層之間的數(shù)據(jù)交互。一個單視圖完整功能的WDA開發(fā)過程如圖5所示。
圖5 WDA開發(fā)過程
實際上,包括WDA在內(nèi),軟件業(yè)務(wù)流程的開展全部通過Internet實現(xiàn)。H公司提供應(yīng)用服務(wù)并部署其在自身的服務(wù)器上,客戶方不再需要購買軟件,而是通過互聯(lián)網(wǎng)全天候獲取服務(wù)結(jié)果,且可以靈活定制所需服務(wù)項目,無需對軟件進行維護。此過程取消了傳統(tǒng)的軟件授權(quán)費用,免除了客戶服務(wù)器硬件、網(wǎng)絡(luò)設(shè)備、軟件升級維護的支出,僅通過Internet即可獲取所需服務(wù)。
以上正是SaaS理念的體現(xiàn)與價值所在。
2.3 門戶的實現(xiàn)
基于以上開發(fā)過程,完成了門戶后端客戶維護、服務(wù)維護、服務(wù)合同維護和數(shù)據(jù)采集器維護的WDA開發(fā)及前端客戶動態(tài)訪問分析報告的應(yīng)用開發(fā),實現(xiàn)了H公司對智能企業(yè)門戶的需求。圖6顯示的是該企業(yè)門戶。
圖6 門戶
此門戶結(jié)合了企業(yè)門戶的信息整合與SaaS架構(gòu)的思想,將傳統(tǒng)的軟件交付周期流程無縫集成進門戶系統(tǒng)中,這是一般意義門戶系統(tǒng)所不具備的特性。在此門戶內(nèi),業(yè)務(wù)流程的開展擯棄了過多的人工干預,核心功能全部自動實現(xiàn),無需繁瑣耗時系統(tǒng)配置、人力監(jiān)控運行過程。最重要的是,通過此門戶項目的實施改進了企業(yè)業(yè)務(wù)流程的方法論,一切基于服務(wù)的理念,而不再是傳統(tǒng)的實施、交付、運行、維護,從而實現(xiàn)智能的特性。
3 結(jié)語
本文針對已部署SAP系統(tǒng)的企業(yè)對智能企業(yè)門戶的需求,給出了利用SAP的Web Dynpro工具進行開發(fā)的方法與具體的實現(xiàn)。本研究認為,以下幾點是在開發(fā)過程中應(yīng)著重注意的:
(1)顯示邏輯與業(yè)務(wù)邏輯的分離。WDA改進的MVC模型使開發(fā)者可以專注于顯示邏輯的開發(fā),業(yè)務(wù)邏輯應(yīng)全部通過在后端系統(tǒng)中開發(fā)相應(yīng)的功能模塊或類方法來實現(xiàn),顯示邏輯的設(shè)計中不應(yīng)包含業(yè)務(wù)邏輯,降低兩者的耦合度可以極大地降低日后修改維護工作可能的工作量。(2)針對不同的需求業(yè)務(wù)背景,靈活地選擇開發(fā)方式。對于需求多變、不確定性較高的情況,采用需求驅(qū)動開發(fā)的思想往往能起到較好的效果。對于需求較為清晰的情況,從模型層開始實現(xiàn)是更為普遍認可的方式。(3)組件的可重用性。WDA是基于組件化的開發(fā)思想,較為復雜的功能實現(xiàn)可能需要重用多個組件,每一個組件在設(shè)計過程中應(yīng)更多地考慮本身結(jié)構(gòu)的獨立性與對外的接口,便于重用的實現(xiàn),降低開發(fā)量。
智能企業(yè)門戶是企業(yè)門戶的發(fā)展趨勢,它不再局限于技術(shù)工具,更是企業(yè)發(fā)展的戰(zhàn)略組成。它的理論與實際價值在于:融入的智能思想和技術(shù)能夠進一步完善發(fā)展門戶整合理論,改善企業(yè)的業(yè)務(wù)流程可以極大提升企業(yè)運營水平,并最終促進企業(yè)信息化管理體系的不斷創(chuàng)新。
轉(zhuǎn)載請注明出處:拓步ERP資訊網(wǎng)http://www.ezxoed.cn/
本文標題:基于SAPERP平臺的智能企業(yè)門戶的實現(xiàn)
本文網(wǎng)址:http://www.ezxoed.cn/html/consultation/1082058031.html