SAP UI 和 Salesforce UI 开发漫谈

目录

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...

用浏览器访问SAP GUI 事务码SE80的效果以下：

实际上，S/4HANA的不少标准应用也采用了这种作法。以物料主数据管理应用为例，S/4HANA既存在采用这种“障眼法”打造而成的伪Fiori应用（下图标注了事务码的3个tile），也存在下文要介绍的根正苗红的原生Fiori应用（下图蓝色tile所示）。

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。

再有就是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...

BSP/CRM WebClient UI

SAP 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...

SAP UI5/Fiori

这对术语常常伴随着彼此同时出现，有的朋友对两者的区别和联系搞得不是太清楚。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...

奥妙就在于这里使用了一个叫作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...

以上仅仅是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

谈起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%'.

Lightning Experience: Salesforce的设计语言(Design Language), 至关于SAP Fiori，也支持移动设备访问。

下图是在PC浏览器里打开的Salesforce Home页面：

下图是在手机上打开的业务机会(Opportunity)建立页面:

Aura Framework: 一个开源的Web应用开发框架，源代码在github上：

https://github.com/forcedotco...

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的开发技术有一些最基本的认识。

感谢阅读。