关于sap: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 的开发技术有一些最根本的意识。

感激浏览。