今天我看了SAP Cloud for Customer UI的JavaScript代碼，下面我是結合S/4 HANA和CRM，以及SAP Engagement Center，Revenue Cloud的UI開發，畫的一個圖。

從上圖能夠看出，這些UI開發可以歸納為兩種方式:

(1) metadata drive development - 元數據驅動的開發模式

developer不直接和JavaScript和Html打交道，而是用SAP自己開發的工具來開發UI metadata，這些UI metadata可能以json， xml或者純文本存儲在Server上.
例如CRM的WebClient UI workbench, S/4 HANA的ABAP development studio，以及C4C的UI designer，這些都是開發metadata的工具。Runtime時，SAP自己開發的UI framework，會自動讀取這些metadata，生成native的html source code.
end user永遠不會直接和metadata打交道，他們只能看見UI runtime翻譯好的native html code.

(2) native UI development - 原生UI開發方式

這就是現在CECenter, nGom, CaaS的developer的開發方都是: 用各種通用的UI開發工具直接開發native code. 這些native code雖然也不是最后end user直接看到的code，但是已經比較接近了，經過各種前端pack工具打包build之后，生成了最后end user看到的source code.

這兩種方式優缺點都很明顯。

Metadata drive development的優點

(1) 對應用developer的技術要求不高，新手經過簡單培訓即可上手。某些工具更是傻瓜化的，托托拽拽即可把UI畫出來。 通過這種UI開發工具畫UI就好象流水線作業。

(2) 大量build UI的routine work已經被各種開發工具封裝起來，開發復雜度已經轉嫁給UI Runtime Convert engine了。這樣developer用這種專門的開發工具，短時間內就能開發出look and feel一致，并且quality，performance, product standard各方面都自動被UI runtime framework所保證的應用出來。

根據我面試的經驗，BAT和國內其他稍具規模的公司，都有類似的自己的UI開發工具，最次也有自己的控件庫，應用developer很少直接從native html開始寫。

Metadata drive development的缺點

(1) 不夠靈活。某些功能如果開發工具不支持，那幾乎無法通過標準的辦法來做，只能想各種workaround. 當然設計得比較好的框架會為這種extensibility提供solution，比如S/4 HANA的smart template提供的breakout hook, 比如CRM WebClient UI的iterator能允許Developer直接渲染html. C4C UI是否有類似機制我還不清楚.

(2) 排錯麻煩。 因為大量細節被開發工具和UI framework掩蓋了，所以一旦遇到runtime behavior does not work as expected, 一般水平的developer要么求助老手，要么Google。而這些工具都是封閉的，只有SAP生態圈的人用，往往Google不出太多有用的信息。 我對這種錯誤也只能自己debug.

(3) 技術封閉. 外面的公司一般不用。

(4) 對于缺乏求知欲的developer來說，這種開發方式對他們技術提高沒啥幫助。如果developer對自己的要求只是把UI畫出來，不去了解背后的原理，那么他無論做再長的時間，最多也只是某種開發工具的熟練工而已。

Native UI development的優點

(1) 靈活。 因為是native開發了，加上現在JS提供了越來越強大的API support, 甚至能直接操作硬件。所以提這種開發方式理論上能實現一切需求。

(2) “對技術的投資有持續性”.

這是我直接引用一位新同事的原話。 因為native UI用的所有工具都是業界通用的，用的框架也都是open source的，比如現在部分team用的Angular。

(3) 相對metadata driven的開發方式，native 開發更鍛煉人.

這種開發方式很多routine的工作都得developer自己去做了，quality, performance, product standard這些都要自己去動腦筋。給Developer提供了很好的錘煉技術的機會。

Native UI development的缺點

應用開發周期長，對developer水平要求高， 容易出bug.

說了這么多，下面來說說C4C的UI 渲染。

我現在看到的這個UI是咋畫出來的？

前面已經說了，每個user登陸后能看到的Work center是后臺一個FM算出來的。 比如算出來default workcenter是Feed， 那么UI會發一個http 請求到后臺請求Feed workcenter的metadata：

請求里就有這個metadata的path:
https://my500046.c4c.saphybriscloud.cn/sap/ap/ui/json?app.component=/BYD_COD/UIInfrastructure/FEED/COD_FEED_WCVIEW.WCVIEW.uiwocview&h=cf58b5003a257fc7655b7cdafd674700&g=4ff52fb8fa91325afc38eef8d6b2640e

path:

/BYD_COD/UIInfrastructure/FEED/COD_FEED_WCVIEW.WCVIEW.uiwocview
通過這個path到metadata repository里找。

UI runtime framework拿到這個metadata后，就能把控件一個個畫出來。
比如我想看這個drop down list咋畫出來的：

可以在ControlFactory.createControl這個function里設置斷點，這是control繪制的入口:

最后你會發現drop down list的build就是在這里完成的：

要獲取更多Jerry的原創文章，請關注公眾號"汪子熙":

總結

以上是生活随笔為你收集整理的SAP不同产品的UI开发策略概述的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。