**目錄**

**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的效果如下：

![](https://img-blog.csdnimg.cn/img_convert/6a77af37265b680817425987bc070fa8.png)

實際上，S/4HANA的很多標準應用也採用了這種做法。以物料主資料管理應用為例，S/4HANA既存在採用這種“障眼法”打造而成的偽Fiori應用（下圖示註了事務碼的3個tile），也存在下文要介紹的根正苗紅的原生Fiori應用（下圖藍色tile所示）。

![](https://img-blog.csdnimg.cn/img_convert/5e7915ef70a1e0c2439dc9d0f7f2f5bf.png)

**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。

![](https://img-blog.csdnimg.cn/img_convert/e77195f02966b1bbed9da9ae71b445e5.png)

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

![](https://img-blog.csdnimg.cn/img_convert/a58ecc2d43ec37b8c543a1d2c4321a89.png)

該技術尤其適用於部分國內客戶，這些客戶認為SAP標準UI匯出而成的文件格式和客戶平日使用的紙質文件（比如銷售合同）的外觀相去甚遠。通過Document Builder，客戶可以用Word設計符合自己格式和外觀要求的文件元素作為模板然後上傳到系統裡，基於這些模板生成最終文件。

SAP Document Builder的ABAP Web Dynpro UI：

![](https://img-blog.csdnimg.cn/img_convert/8c707a673b5a4c971afcaf4c7caebb94.png)

此外，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程式碼。

![](https://img-blog.csdnimg.cn/img_convert/65799f4cf899bd2cf4abfbbbc58ddd79.png)

執行時這些ABAP程式碼在伺服器端執行，然後被合併到頁面原始碼中去，最後伺服器端將頁面原始碼傳送給瀏覽器，顯示給使用者。

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

![](https://img-blog.csdnimg.cn/img_convert/7f78daddb4ee0da601aeb4887e32dfd1.png)

![](https://img-blog.csdnimg.cn/img_convert/137c5127e0c9f4fde1fc5358e4b1f0bf.png)

從上面的介面也能看出，BSP應用缺乏MVC支援，並且僅能在其框架支援的6個事件響應位置進行ABAP程式設計。用BSP開發一些小工具還行，如果拿來開發企業級應用則顯得有些力不從心。正因為BSP的這個缺陷, CRM WebClient UI 才有了用武之地。

CRM WebClient UI應用本質上也是一個BSP應用，同傳統的BSP開發事務碼SE80不同，CRM WebClient UI有一個新的開發事務碼，該開發工具提供了使用BO作為MVC中模型層的原生支援，即開發人員可以在開發工具裡將BO某個欄位繫結到UI某個欄位上。

![](https://img-blog.csdnimg.cn/img_convert/cfc9fa7e472294663eaf3a5ab3740fa8.png)

WebClient UI和下面將要介紹的SAP UI5一樣，也包含了很多開箱即用的標準控制元件，只不過我們一般不用控制元件這個術語，而稱為元素(Element)。應用開發人員只需要使用這些標準元素，就能快速開發出高質量的UI介面。

舉個例子，下圖是一個典型的使用WebClient UI實現的搜尋頁面，第2行和第3行宣告瞭SAP標準元素庫thtmlb和chtmlb的引用，然後在第11行使用了thtmlb庫裡的元素searchFrame。有SAP UI5開發經驗的朋友可以把這種做法類別成在UI5的XML view裡使用SAP標準的UI5控制元件，原理是相同的。

![](https://img-blog.csdnimg.cn/img_convert/c3ab4d6f19315606b3ef17932d0d7cda.png)

短短29行程式碼，就繪製出了如下圖的搜尋介面：不僅支援通過下拉選單更換搜尋條件，也支援通過帶有+和-的圓形按鈕新增或者刪除搜尋條件。

![](https://img-blog.csdnimg.cn/img_convert/e0d156ae6b3f55c8c3fc6d7f5c9b953e.png)

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

![](https://img-blog.csdnimg.cn/img_convert/67a7489a82dd2ac1cc06006becee7759.png)

關於WebClient UI更多開發細節，請參考我的公眾號文章[Jerry的WebClient UI 42篇原創文章合集](http://mp.weixin.qq.com/s?__biz=MzI3MDE4MjM5Mg==&mid=2247483888&idx=1&sn=b94638f2be620423e2001943f4211783&chksm=ead5b367dda23a713af3fb13bda2334c715a8fc2a65222a9f8d3a6f8e8ee8a887196e05a5f2e&scene=21#wechat_redirect)。

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

![](https://img-blog.csdnimg.cn/img_convert/7af8a9f2051b02ce321b00654a9ae0e9.png)

關於這個執行時額外開銷的話題，我曾經做過評測，結果證明：假設用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/

![](https://img-blog.csdnimg.cn/img_convert/fc973155fa94cc6a51b3529e02dc9d46.png)

![](https://img-blog.csdnimg.cn/img_convert/3d19700d05ac7ea152ef7d04723bbd67.png)

**SAP UI5/Fiori**

這對術語經常伴隨著彼此同時出現，有的朋友對二者的區別和聯絡搞得不是太清楚。Fiori是SAP官方的設計語言，代表一種UI的設計風格，我的同事周帥在他的微信文章 [SAP成都C4C小李探花：淺談Fiori Design Guidelines](http://mp.weixin.qq.com/s?__biz=MzI3MDE4MjM5Mg==&mid=2247484260&idx=1&sn=534aca2616d51f9262d38f2c845a6b99&chksm=ead5b1f3dda238e559405b224b56a6c60277c5d4df38720d2cd3104227a4633485af57d836f8&scene=21#wechat_redirect) 裡對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

![](https://img-blog.csdnimg.cn/img_convert/35df7533b6c41ccf6f72e8f7e5a9f727.png)

該BSP應用在ABAP後臺開啟如下所示：

![](https://img-blog.csdnimg.cn/img_convert/51e33fa5bb92ac9ca6509caf3e8d9c04.png)

開發人員可以用WebIDE, Eclipse, Webstorm，Atom, Sublime Text或任何喜歡的其他IDE/編輯器進行SAP UI5開發。開發完成後，這些UI5應用一旦部署到Netweaver，SAP框架會自動建立一個BSP應用，儲存該UI5應用的全部內容。關於更多Fiori應用的部署細節，請參考我的公眾號文章 [SAP Fiori應用的三種部署方式](http://mp.weixin.qq.com/s?__biz=MzI3MDE4MjM5Mg==&mid=2247483825&idx=1&sn=3a4c175890e85df88236273763e06550&chksm=ead5b326dda23a30e20b192eeb1fe9838c900a05769a68dfe9aebf628424becc3190e402f363&scene=21#wechat_redirect)。

SAP UI5支援不同的view型別，最常用的是xml view和js view。對於xml view，在裡面宣告要使用哪些UI5控制元件。

![](https://img-blog.csdnimg.cn/img_convert/fed222fcfc1bba97c07a2cb7f1d670be.png)

在執行時，xml view被載入，內容被UI5框架的XMLTemplateProcessor解析成一顆DOM樹，樹上的每個葉節點對應xml view中一個UI5控制元件的宣告。然後深度遍歷這顆樹，建立UI5控制元件執行時例項。因為是深度遍歷，所以您能在下圖呼叫棧裡觀察到很多handleChildren和createRegularControls的遞迴呼叫。

![](https://img-blog.csdnimg.cn/img_convert/cd0ab5c06cc0022baf9c2dc06bbe9354.png)

同xml view相比，js view裡控制元件的例項化不是由XMLTemplateProcessor完成，而是開發人員在JavaScript程式碼裡自行實現。

![](https://img-blog.csdnimg.cn/img_convert/b38642b5f3eb8988ec17ae0c6e082e27.png)

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

然而有的S/4HANA Fiori應用，如果您按照我這篇文章 [Jerry和您聊聊Chrome開發者工具](http://mp.weixin.qq.com/s?__biz=MzI3MDE4MjM5Mg==&mid=2247484306&idx=1&sn=314d749da91a94064ef1e258657a0974&chksm=ead5b105dda23813addbca28689e3fcc22c0b47cb2d4f49557ec796edfa8fe88c43d2c70567a&scene=21#wechat_redirect) 介紹的方法，用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/

![](https://img-blog.csdnimg.cn/img_convert/82cd60ee242dde3ccdad3d030d671199.png)

奧妙就在於這裡使用了一個叫做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: 宣告該欄位渲染成搜尋欄位。

![](https://img-blog.csdnimg.cn/img_convert/2ef09bca69215957fcbefeb9882af141.png)

這些註解的詳細定義在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的詳細程式碼在我的部落格裡。

![](https://img-blog.csdnimg.cn/img_convert/1dc876d337630489d60d740b9a7550c4.png)

關於Smart Template的更多介紹，請參考我的公眾號文章 [Jerry的通過CDS view + Smart Template 開發Fiori應用的blog合集](http://mp.weixin.qq.com/s?__biz=MzI3MDE4MjM5Mg==&mid=2247483680&idx=1&sn=bbca83f9ce449e439dbd45f948a0ba2e&chksm=ead5b3b7dda23aa15e3d30d6867fcdc5df83d130e22dda5060507ec65d971e3cb173c16235af&scene=21#wechat_redirect) 。

**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開發。

![](https://img-blog.csdnimg.cn/img_convert/6fe1483d31bebe9d6acb283e35bc0323.png)

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

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

![](https://img-blog.csdnimg.cn/img_convert/13ace7b5c14c7c86e0d35d9a5a3c84f7.png)

這個標籤的定義位於檔案:

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

![](https://img-blog.csdnimg.cn/img_convert/1efecce92dbf6a91cd6f7e88a8177b34.png)

而標籤的實現位於檔案TestIdTag.java：

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

![](https://img-blog.csdnimg.cn/img_convert/bfb4b0f52e2ea45f0d4d605feef96577.png)

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

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

![](https://img-blog.csdnimg.cn/img_convert/e5214bcfdbd50f0c7507ab958e13fade.png)

而Hybris JSP標籤這套確保div id屬性全域性唯一的實現方式，和WebClient UI竟完全一致。從下圖一個WebClient UI頁面的原生HTML程式碼中我們能輕易發現id屬性值的整型字尾：

![](https://img-blog.csdnimg.cn/img_convert/db3306f382e05d390b600999733eadd2.png)

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

![](https://img-blog.csdnimg.cn/img_convert/66190588af4df781f51cab4b3ee6544a.png)

關於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）：

![](https://img-blog.csdnimg.cn/img_convert/034867d3db9040cdc5d23d41cb3357c4.png)

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

![](https://img-blog.csdnimg.cn/img_convert/397a650070eae17be3095c434132a07a.png)

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

*   beforeItem

*   renderItem

*   afterItem

![](https://img-blog.csdnimg.cn/img_convert/31aa8416a8dfd0544316881db1db03bf.png)

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

*   DO_AT_BEGINNING

*   RENDER

*   DO_AT_END

![](https://img-blog.csdnimg.cn/img_convert/2e624fca21f93cf07d41819af4a887d4.png)

至於通過WCMS建立的template在執行時如何生成最終的HTML原始碼，則是一個比較複雜的過程，這裡限於篇幅不做詳細介紹，大家可以參考Hybris官網上的幫助文件。

![](https://img-blog.csdnimg.cn/img_convert/95892fa4d9a054b0a93f2595b710388f.png)

**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%'.**

![](https://img-blog.csdnimg.cn/img_convert/6d29d9d04bbfb9f5872442767591bfec.png)

**Lightning Experience:** Salesforce的設計語言(Design Language), 相當於SAP Fiori，也支援移動裝置訪問。

下圖是在PC瀏覽器裡開啟的Salesforce Home頁面：

![](https://img-blog.csdnimg.cn/img_convert/575589a15dca084763effc4e38a3bf7b.png)

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

![](https://img-blog.csdnimg.cn/img_convert/b6ed198a748b17c7af0830f0268d8652.png)

**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。

![](https://img-blog.csdnimg.cn/img_convert/2e728e8103cdbbab7c53120755779ace.png)

**Visualforce:** Salesforce使用的基於MVC的UI開發框架。介面開發類似SAP UI5的xml view。介面繫結的模型宣告語法{}也和SAP UI5類似。介面繫結的Controller使用語言Apex開發。

![](https://img-blog.csdnimg.cn/img_convert/b95eb7a878ff51b4300e559b388bfc53.png)

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

![](https://img-blog.csdnimg.cn/img_convert/3d273998bc4e1ad9b8c9aa5ba9effb7f.png)

希望這篇文章能讓大家對SAP不同產品的UI和Salesforce UI的開發技術有一些最基本的認識。

感謝閱讀。

SAP UI 和 Salesforce UI 開發漫談

相關文章