前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >SAP不同产品的UI开发策略概述

SAP不同产品的UI开发策略概述

作者头像
Jerry Wang
发布2019-05-31 15:20:48
4660
发布2019-05-31 15:20:48
举报

今天我看了SAP Cloud for Customer UI的JavaScript代码,下面我是结合S/4 HANA和CRM,以及SAP Engagement Center,Revenue Cloud的UI开发,画的一个图。

clipboard1
clipboard1

从上图能够看出,这些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是咋画出来的?

clipboard2
clipboard2

前面已经说了,每个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咋画出来的:

clipboard3
clipboard3

可以在ControlFactory.createControl这个function里设置断点,这是control绘制的入口:

clipboard4
clipboard4

最后你会发现drop down list的build就是在这里完成的:

clipboard5
clipboard5
本文参与 腾讯云自媒体分享计划,分享自作者个人站点/博客。
原始发表:2018年12月21日,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • Metadata drive development的优点
  • Metadata drive development的缺点
  • Native UI development的优点
  • Native UI development的缺点
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档