- 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 UI
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
用浏览器访问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.
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
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
奥妙就在于这里使用了一个叫做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在他的微信公众号文章有详细的介绍：
SAP成都研究院C4C光明左使：SAP Cloud for Customer 使用SAP UI5的独特之处
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
以上仅仅是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
Jerry处于兴趣也在业余时间对这些概念做了粗浅的研究，详情可以参考我这篇微信公众号文章。
- SAP Managed Tags:
