SAP UI 和 Salesforce UI 開發漫談

目錄

SAP UI

• SAP GUI + Dynpro
• Web Dynpro
• BSP/CRM WebClient UI
• SAP UI5/Fiori
• UI5 in SAP Cloud for Customer
• Hybris Enterprise Commerce Platform
• • *

Salesforce UI

• Apex
• Lightning Experience
• Aura Framework
• Lightning Component Framework
• Visualforce

SAP GUI + Dynpro

用SAP GUI + Dynpro 開發應用的UI界面彷彿是石器時代的事情了。據我所知，至少在SAP成都研究院已經沒有團隊仍舊使用這種古老的技術來開發UI了。雖然S/4HANA的後臺還有大量事務碼可供終端用戶使用，可是，藉助SAP Internet Transaction Server(ITS)，這些基於SAP GUI的事務碼能夠直接運行在瀏覽器端，而且具備Fiori應用的外觀。

也就是說，若是您的S/4HANA On Premise客戶須要一些新的UI, 除了常規的UI5開發方式以外，從技術上說，您徹底能夠仍然用SAP GUI開發一個Dynpro Screen, 而後封裝成一個事務碼，最後把這個事務碼分配到S/4HANA Fiori launchpad的某個tile上。具體作法能夠參考個人博客：Open your SAP GUI transaction in Fiori launchpad

https://blogs.sap.com/2016/12...

用瀏覽器訪問SAP GUI 事務碼SE80的效果以下：

實際上，S/4HANA的不少標準應用也採用了這種作法。以物料主數據管理應用爲例，S/4HANA既存在採用這種「障眼法」打造而成的僞Fiori應用（下圖標註了事務碼的3個tile），也存在下文要介紹的根正苗紅的原生Fiori應用（下圖藍色tile所示）。

Web Dynpro

從實現語言上分爲ABAP Web Dynpro和Java Web Dynpro。據我所知基於ABAP Web Dynpro開發的SAP標準應用比Java Web Dynpro多得多, 好比SAP SRM的標準UI就基於ABAP Web Dynpro。另外有不少屬於SAP_BASIS software component的應用或框架，其UI也是使用ABAP Web Dynpro開發的，最著名的莫過於BRF(Business Rule Framework) 。

做爲Netweaver ABAP棧的一部分，BRF和其升級版BRF+在SAP許多產品裏都發揮了重要做用。典型的例子有SAP Solution Manager的Incident Management和SAP Cloud for Customer的Service Request應用場景裏的Support Team Determination功能。經過BRF咱們能夠配置一系列規則(rule)，這些規則基於Incident的component，system id, client id和priority等字段。BRF可以根據用戶配置的這些規則，自動決定出哪一個團隊應該處理該Incident / Service Request。

再有就是SAP Document Builder，一款複雜文檔生成的解決方案。文檔管理員負責配置符合實際業務中使用文檔外觀及格式的文檔元素(element), 這些經過Word編輯的文檔元素是最終生成文檔的組成部分。用戶訪問ABAP Web Dynpro UI，填寫一些關鍵字段，最後一鍵生成PDF，Word，HTML或者XML格式的文檔。

該技術尤爲適用於部分國內客戶，這些客戶認爲SAP標準UI導出而成的文檔格式和客戶平日使用的紙質文檔（好比銷售合同）的外觀相去甚遠。經過Document Builder，客戶能夠用Word設計符合本身格式和外觀要求的文檔元素做爲模板而後上傳到系統裏，基於這些模板生成最終文檔。

SAP Document Builder的ABAP Web Dynpro UI：

此外，ABAP Web Dynpro上手快，學習曲線相對平緩，具備接近所見即所得的UI編輯方式。做爲一個MVC框架，ABAP Web Dynpro不須要像CRM WebClient UI那樣必須開發一個真正意義上的Business Object(如下簡稱爲BO)做爲模型，而是能夠直接在controller裏面調用底層API。這種簡單快捷的開發方式深受Partner的歡迎。在我支持過的每個On Premise項目的二次開發裏幾乎都能看到ABAP Web Dynpro的身影。

儘管ABAP Web Dynpro有這麼多優勢，但並不意味着它是一個萬能的解決方案。由於沒法很好的適配移動設備，在Fiori誕生以後，ABAP Web Dynpro逐漸退出UI開發的歷史舞臺了。

須要提醒的一點:

若是一個SAP標準產品的UI不是使用ABAP Web Dynpro開發的，那麼在您決定使用這個技術進行二次開發以前，請慎重考慮，由於您極可能會遇到這些坑：

• 後退按鈕的處理
• 數據丟失的檢測和處理
• 會話處理
• 對UI可配置性(configurability)的支持
• 消息顯示區域的處理
• 對底層API不恰當的調用

這些坑都是我之前支持國內客戶項目時，發現大量ABAP Web Dynpro和CRM WebClient混合使用形成的。關於這些坑的更多細節，請參考個人博客

Issue lists of using ABAP Webdynpro in CRM UI

https://blogs.sap.com/2014/01...

BSP/CRM WebClient UI

SAP BSP是一項神奇而重要的技術。神奇，是由於它歷史實在太悠久了，據我所知從上世紀90年代年起一直服役至今。而它重要的一面，暫時賣個關子。

BSP和JSP的原理一致，能直接在前端HTML頁面裏經過<%和%>嵌入ABAP代碼。

運行時這些ABAP代碼在服務器端執行，而後被合併到頁面源代碼中去，最後服務器端將頁面源代碼發送給瀏覽器，顯示給用戶。

下圖是一個BSP應用的例子。BSP的HTML裏仍然能觸發一些事件，可是這些事件的響應函數不是JavaScript函數，而是由ABAP實現的代碼片斷，即下圖左邊的On開頭的一系列事件處理邏輯。

從上面的界面也能看出，BSP應用缺少MVC支持，而且僅能在其框架支持的6個事件響應位置進行ABAP編程。用BSP開發一些小工具還行，若是拿來開發企業級應用則顯得有些力不從心。正由於BSP的這個缺陷, CRM WebClient UI 纔有了用武之地。

CRM WebClient UI應用本質上也是一個BSP應用，同傳統的BSP開發事務碼SE80不一樣，CRM WebClient UI有一個新的開發事務碼，該開發工具提供了使用BO做爲MVC中模型層的原生支持，即開發人員能夠在開發工具裏將BO某個字段綁定到UI某個字段上。

WebClient UI和下面將要介紹的SAP UI5同樣，也包含了不少開箱即用的標準控件，只不過咱們通常不用控件這個術語，而稱爲元素(Element)。應用開發人員只須要使用這些標準元素，就能快速開發出高質量的UI界面。

舉個例子，下圖是一個典型的使用WebClient UI實現的搜索頁面，第2行和第3行聲明瞭SAP標準元素庫thtmlb和chtmlb的引用，而後在第11行使用了thtmlb庫裏的元素searchFrame。有SAP UI5開發經驗的朋友能夠把這種作法類別成在UI5的XML view裏使用SAP標準的UI5控件，原理是相同的。

短短29行代碼，就繪製出了以下圖的搜索界面：不只支持經過下拉菜單更換搜索條件，也支持經過帶有+和-的圓形按鈕添加或者刪除搜索條件。

如此一來，應用程序開發人員無需再去編寫原生的HTML代碼和CSS。在運行時期，searchFrame元素對應的Render類會負責生成原生的HTML代碼。

關於WebClient UI更多開發細節，請參考個人公衆號文章Jerry的WebClient UI 42篇原創文章合集。

此外，CRM WebClient UI和ABAP Webdynpro相比，多了下圖中紅色方框所示的Business Object Layer和Generic Interaction Layer，有的朋友可能認爲這兩層會帶來一些額外的運行時開銷(runtime overhead),致使WebClient UI的性能不如ABAP Web Dynpro。

關於這個運行時額外開銷的話題，我曾經作過評測，結果證實：假設用WebClient UI和ABAP Web Dynpro實現一樣的需求，WebClient UI引入BOL和GenIL層帶來的運行時開銷並不會致使其性能比ABAP Web Dynpro相差太多。底層API邏輯越複雜，這個運行時開銷越能夠忽略不計。

下圖就是我分別使用Social Post，Sales Order和Product三個應用測試出來的BOL和GenIL形成的運行時開銷明細。關於我作的這個性能評測的更多細節，請參考個人博客

Webclient UI vs ABAP webdynpro: performance loss in BOL / Genil Layer discussion

https://blogs.sap.com/2014/01...

SAP UI5/Fiori

這對術語常常伴隨着彼此同時出現，有的朋友對兩者的區別和聯繫搞得不是太清楚。Fiori是SAP官方的設計語言，表明一種UI的設計風格，個人同事周帥在他的微信文章 SAP成都C4C小李探花：淺談Fiori Design Guidelines 裏對SAP Fiori有着詳細介紹。而SAP UI5是一種UI開發技術, 一個基於jQuery的UI開發框架和UI控件庫。

目前S/4HANA, SAP Cloud for Customer, SAP Engagement Center, SAP Revenue Cloud這些產品的UI都基於SAP UI5。

爲何我前面介紹BSP時說這項技術如此重要呢？SAP的旗艦產品S/4HANA, 其Fiori應用還是以BSP的方式存儲在Netweaver上。

好比S/4HANA物料主數據管理的Fiori應用，其BSP應用名稱：md_prod_mas_s1

該BSP應用在ABAP後臺打開以下所示：

開發人員能夠用WebIDE, Eclipse, Webstorm，Atom, Sublime Text或任何喜歡的其餘IDE/編輯器進行SAP UI5開發。開發完成後，這些UI5應用一旦部署到Netweaver，SAP框架會自動建立一個BSP應用，存儲該UI5應用的所有內容。關於更多Fiori應用的部署細節，請參考個人公衆號文章 SAP Fiori應用的三種部署方式。

SAP UI5支持不一樣的view類型，最經常使用的是xml view和js view。對於xml view，在裏面聲明要使用哪些UI5控件。

在運行時，xml view被加載，內容被UI5框架的XMLTemplateProcessor解析成一顆DOM樹，樹上的每一個葉節點對應xml view中一個UI5控件的聲明。而後深度遍歷這顆樹，建立UI5控件運行時實例。由於是深度遍歷，因此您能在下圖調用棧裏觀察到不少handleChildren和createRegularControls的遞歸調用。

同xml view相比，js view裏控件的實例化不是由XMLTemplateProcessor完成，而是開發人員在JavaScript代碼裏自行實現。

每一個UI5控件都有一個對應的渲染器(renderer), 負責在運行時根據實例包含的各項屬性渲染出對應的HTML原生代碼。

然而有的S/4HANA Fiori應用，若是您按照我這篇文章 Jerry和您聊聊Chrome開發者工具 介紹的方法，用Chrome開發者工具打開它的實現，會發現這個應用既沒有xml view，也沒有js和其餘類型的view。那麼，咱們看到的Fiori UI究竟是怎麼畫出來的呢？

舉個例子，若是您按照我這篇博客的步驟，您能夠在幾分鐘內，構造出一個支持Service Order增刪改查的Fiori應用出來，而且不須要寫一行JavaScript代碼。

Create a CRM Service Order Fiori application within a couple of minutes

https://blogs.sap.com/2016/03...

奧妙就在於這裏使用了一個叫作Smart Template的Fiori框架。使用這個框架，界面佈局信息再也不維護於xml或者js view裏，而是定義在CDS view內。

下圖是我博客裏提到的Service Order應用使用到的某個CDS view在ABAP Studio裏的顯示。能夠觀察到有不少annotation(註解), 其中名稱以@UI開頭的註解定義了一些元數據，描述了被註解的字段出如今Fiori UI上的具體位置。

@UI.lineItem: 以一個column的外觀出如今UI的搜索結果列表裏，具體位置經過屬性position指定。

@UI.selectionField: 聲明該字段渲染成搜索字段。

這些註解的詳細定義在SAP help上能找到。這就是元數據驅動(metadata-drive development)的UI開發方式。這種方式實際將UI開發的大部分複雜度從應用開發人員身上轉嫁到了Smart Template框架實現自己。使用這個框架，應用開發人員所須要作的就是專一於CDS view的開發，以及在view裏定義UI註解。在運行時，由SAP UI5框架將這些元數據讀取出來，而後負責生成原生的HTML代碼。

這解釋了爲何您在基於Smart Template的Fiori應用裏找不到xml或者js view，由於UI佈局壓根就再也不存儲於這些前臺資源裏，而是維護在ABAP後臺的CDS view裏。

下圖是以前提到的Service Order Fiori應用使用到的CDS view的層級結構。每一個view的詳細代碼在個人博客裏。

關於Smart Template的更多介紹，請參考個人公衆號文章 Jerry的經過CDS view + Smart Template 開發Fiori應用的blog合集 。

UI5 In SAP Cloud for Customer(C4C)

之因此要把C4C單獨拿出來說，是由於雖然C4C也基於SAP UI5，可是對SAP UI5的使用方式和SAP其餘產品，如S/4HANA, SAP Revenue Cloud， SAP Engagement Center相比還有所不一樣。SAP成都研究院C4C開發團隊的Yang Joey會在他的文章裏介紹具體的差別。

Hybris Enterprise Commerce Platform(ECP)

按照使用場景可分爲Storefront UI（前臺電商頁面）和Backoffice UI（後臺管理頁面）。

Storefront UI佈局和使用方式均和咱們天天用的淘寶京東等相似，採用JSP開發。

同前文介紹的CRM WebClient UI使用的BSP技術同樣，在Hybris Storefront UI的JSP開發中，Hybris也封裝了不少標準的UI元素供開發人員使用。在Hybris裏把這些標準UI元素稱爲Tag（標籤）。

好比下圖使用標籤ycommerce:testId來分頁顯示產品搜索結果：

這個標籤的定義位於文件:

ext-template/yacceleratirstorefront/web/webroot/WEB-INF/common/tld/ycommercetags.tld

而標籤的實現位於文件TestIdTag.java：

ext-template\yacceleratorstorefront\web\src\de\hybris\platform\yacceleratorstorefront\tags

同前面講過的UI5控件的Renderer，WebClient UI元素的Renderer職責相同，該Java類也能看做是JSP標籤的Renderer，負責在運行時渲染JSP tag testId 對應的原生HTML代碼。

上圖註釋還提到，爲了確保id惟一，pageContext內部維護一個計數器，每次生成頁面元素後計數器加1。該計數器產生的整數值做爲最後生成原生HTML div標籤id屬性的後綴，確保每一個div標籤有全局惟一的id。

而Hybris JSP標籤這套確保div id屬性全局惟一的實現方式，和WebClient UI竟徹底一致。從下圖一個WebClient UI頁面的原生HTML代碼中咱們能輕易發現id屬性值的整型後綴：

WebClient UI裏id屬性計數器的累加在下圖第24行完成。

關於Hybris JSP標籤的更多細節，請查看個人博客：

JSP attribute tag used in Hybris UI implementation and counterpart in ABAP BSP

https://blogs.sap.com/2018/02...

以上僅僅是Hybris ECP storefront UI開發微觀層面的描述。從宏觀上來說，這些JSP開發而成的界面如何組裝起來最後造成用戶看到的電商頁面呢？相似SAP WebClient UI的Navigation Profile能夠基於業務角色（Business Role）定義一系列UI以及其頁面跳轉關係，Hybris ECP也有相似的模塊稱爲Web Content Management System（WCMS）：

在WCMS裏能夠定義一個頁面的模板(Template), 模板裏包含了不一樣的Page Slot，這些Slot裏放置具體的UI Component。好比下圖的homepage模板，定義了電商首頁的佈局，咱們能觀察到SiteLogoSlot位於TopHeaderSlot和ButtonHeaderSlot之間，包含了SiteLogoComponent，後者負責在電商頁面上顯示logo。

而UI component tag的渲染，分爲渲染前，渲染中和渲染後三個階段，分別對應renderItem方法中的三個子方法：

• beforeItem
• renderItem
• afterItem

這三個方法分別對應了WebClient UI中的這三個子方法：

• DO_AT_BEGINNING
• RENDER
• DO_AT_END

至於經過WCMS建立的template在運行時如何生成最終的HTML源代碼，則是一個比較複雜的過程，這裏限於篇幅不作詳細介紹，你們能夠參考Hybris官網上的幫助文檔。

Salesforce UI

談起Salesforce UI，會遇到如下一些名詞：

• Apex
• Lightning Experience
• Aura Framework
• Lightning Component Framework
• Visualforce

Apex: Apex是Salesforce推出的一門強類型面向對象的編程語言，語法相似Java。Apex之於Salesforce等同於ABAP之於SAP。有意思的是，Apex也能像ABAP Open SQL那樣，直接同Persistence Layer交互。

下圖兩行紅色的高亮代碼等價的ABAP Open SQL代碼爲：

DELETE FROM Account where name LIKE 'test%'.

Lightning Experience: Salesforce的設計語言(Design Language), 至關於SAP Fiori，也支持移動設備訪問。

下圖是在PC瀏覽器裏打開的Salesforce Home頁面：

下圖是在手機上打開的業務機會(Opportunity)建立頁面:

Aura Framework: 一個開源的Web應用開發框架，源代碼在github上：

https://github.com/forcedotco...

Lightning Component Framework: 基於上面提到的開源框架Aura, 做爲一個組件化前端框架，Salesforce用它開發可複用的UI Component。

下圖是Account視圖是如何由不一樣的UI Component構成的示意圖，你們能夠和前文介紹的SAP Hybris Storefront UI的WCMS相類比，思路其實都是一致的。再回憶一下：Hybris Storefront頁面模板裏包含若干個Page Slot，每一個Slot放置一個UI Component。

Visualforce: Salesforce使用的基於MVC的UI開發框架。界面開發相似SAP UI5的xml view。界面綁定的模型聲明語法{}也和SAP UI5相似。界面綁定的Controller使用語言Apex開發。

同前面介紹的JSP和SAP BSP同樣，Visualforce也是基於Server端渲染的技術。

但願這篇文章能讓你們對SAP不一樣產品的UI和Salesforce UI的開發技術有一些最基本的認識。

感謝閱讀。