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

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

(1) metadata drive development - 元數(shù)據(jù)驅(qū)動(dòng)的開發(fā)模式

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

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

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

這兩種方式優(yōu)缺點(diǎn)都很明顯。

Metadata drive development的優(yōu)點(diǎn)

(1) 對(duì)應(yīng)用developer的技術(shù)要求不高，新手經(jīng)過簡(jiǎn)單培訓(xùn)即可上手。某些工具更是傻瓜化的，托托拽拽即可把UI畫出來。 通過這種UI開發(fā)工具畫UI就好象流水線作業(yè)。

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

根據(jù)我面試的經(jīng)驗(yàn)，BAT和國(guó)內(nèi)其他稍具規(guī)模的公司，都有類似的自己的UI開發(fā)工具，最次也有自己的控件庫(kù)，應(yīng)用developer很少直接從native html開始寫。

Metadata drive development的缺點(diǎn)

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

(2) 排錯(cuò)麻煩。 因?yàn)榇罅考?xì)節(jié)被開發(fā)工具和UI framework掩蓋了，所以一旦遇到runtime behavior does not work as expected, 一般水平的developer要么求助老手，要么Google。而這些工具都是封閉的，只有SAP生態(tài)圈的人用，往往Google不出太多有用的信息。 我對(duì)這種錯(cuò)誤也只能自己debug.

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

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

Native UI development的優(yōu)點(diǎn)

(1) 靈活。 因?yàn)槭莕ative開發(fā)了，加上現(xiàn)在JS提供了越來越強(qiáng)大的API support, 甚至能直接操作硬件。所以提這種開發(fā)方式理論上能實(shí)現(xiàn)一切需求。

(2) “對(duì)技術(shù)的投資有持續(xù)性”.

這是我直接引用一位新同事的原話。 因?yàn)閚ative UI用的所有工具都是業(yè)界通用的，用的框架也都是open source的，比如現(xiàn)在部分team用的Angular。

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

這種開發(fā)方式很多routine的工作都得developer自己去做了，quality, performance, product standard這些都要自己去動(dòng)腦筋。給Developer提供了很好的錘煉技術(shù)的機(jī)會(huì)。

Native UI development的缺點(diǎn)

應(yīng)用開發(fā)周期長(zhǎng)，對(duì)developer水平要求高， 容易出bug.

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

我現(xiàn)在看到的這個(gè)UI是咋畫出來的？

前面已經(jīng)說了，每個(gè)user登陸后能看到的Work center是后臺(tái)一個(gè)FM算出來的。 比如算出來default workcenter是Feed， 那么UI會(huì)發(fā)一個(gè)http 請(qǐng)求到后臺(tái)請(qǐng)求Feed workcenter的metadata：

請(qǐng)求里就有這個(gè)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
通過這個(gè)path到metadata repository里找。

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

可以在ControlFactory.createControl這個(gè)function里設(shè)置斷點(diǎn)，這是control繪制的入口:

最后你會(huì)發(fā)現(xiàn)drop down list的build就是在這里完成的：

要獲取更多Jerry的原創(chuàng)文章，請(qǐng)關(guān)注公眾號(hào)"汪子熙":

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。