目錄
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/21/open-your-sap-gui-transaction-in-fiori-launchpad/
用瀏覽器訪問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/08/issue-lists-of-using-abap-webdynpro-in-crm-ui
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
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
奧妙就在於這裏使用了一個叫做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
以上僅僅是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/forcedotcom/aura
**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的開發技術有一些最基本的認識。
感謝閱讀。