目錄
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 開發應用的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所示）。
從實作語言上分為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-uiSAP 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/02/webclient-ui-vs-abap-webdynpro-performance-loss-in-bol-genil-layer-discussion/ 這對術語經常伴随着彼此同時出現，有的朋友對二者的差別和聯系搞得不是太清楚。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/31/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
https://blogs.sap.com/2018/02/02/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，會遇到以下一些名詞：
**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的開發技術有一些最基本的認識。