关于sap:谈谈-SAP-产品-UI-开发中的组件概念

1次阅读

共计 5301 个字符，预计需要花费 14 分钟才能阅读完成。

这是 Jerry 2021 年的第 54 篇文章，也是汪子熙公众号总共第 331 篇原创文章。

任何企业级软件的前端开发，都离不开组件 (Component) 这个概念。撇开具体的 UI 开发技术不谈，所谓组件，就是界面的组成部分(UI Building Blocks). 组件在视觉或者业务性能上，可能被视为繁多元素。

组件可能被形成应用程序的其余组件重用，也可能蕴含其余组件。现实状况下，一个设计良好的组件，其同其余组件或者内部服务的依赖关系，能够被失当地隔离，从而可能独自对组件进行单元测试甚至自动化测试。

近些年随着微服务架构浪潮而衰亡的微前端设计理念，甚至反对同一利用内不同的 UI 组件，采取不同的前端技术进行开发，这些异构的 UI 组件，能够独立地进行开发，测试，部署和交付，通过对立的微前端容器进行治理，并形成最终由用户应用的前端程序。

Luigi 就是 SAP 推动的一个微前端框架。

微前端框架的应用曾经超出了本文探讨的领域。本文就 SAP 下列四种产品所应用的前端开发框架 / 工具中蕴含的组件概念，开展进行介绍。

SAP CRM / SRM
SAP S/4HANA
SAP Cloud for Customer
SAP Commerce Cloud

本世纪初，随着企业应用软件从 Client/Server 模式往 Browser/Server 模式的迁徙，SAP CRM 和 SAP SRM 的前端开发技术，也踏上了不同的两条演进路线：别离基于 SAP WebClient UI 和 ABAP Webdynpro. 对于这两项技术更多的介绍和 SAP UI 开发技术的演进之路，请参考 Jerry 之前的文章：SAP UI 和 Salesforce UI 开发漫谈。

SAP WebClient UI 的前身是 SAP BSP – Business Server Page.WebClient UI 在其根底上，引入了组件的概念，并且在视图层削减了对 BSP 扩大标签库的反对，使得其开发效率大大提高。基于 SAP WebClient UI 的开发方式，至今仍在 SAP S/4HANA Service 模块畛域中采纳。

一个基于 SAP WebClient UI 的利用，通常由多个组件形成。单个组件的开发，依然基于传统的 MVC，其中 Model 层的 Context Node，由 ABAP Class 实现，而 ABAP Webdynpro 中的 Context Node，采取的是 ABAP DDIC 数据字段中的数据结构。

WebClient UI 组件的视图层基于 HTML，能重用 SAP 规范 BSP Extension 中提供的 HTML 标签。绝大多数状况下，利用开发人员无需编写原生的 HTML 代码，这也升高了开发门槛。ABAP Webdynpro 组件视图层开发，在 SAP 提供的所见即所得的布局编辑器中进行，开发人员无奈应用原生的 HTML 编辑形式开发视图。

WebClient UI 里有一类非凡的组件，起着容器的作用，负责将其蕴含的其余组件的视图依照用户配置显示进去。

下图是一个例子：SAP CRM 产品概览页面，右边红色区域，是该容器组件反对的所有组件和组件视图列表，左边是以后用户配置的该容器到底要显示哪些组件视图，及这些组件视图的加载形式：间接加载或者提早加载。这种从一个反对组件列表里抉择局部加载的配置形式，在本文后续介绍 SAP Commerce Cloud 组件时会再次提及。

前文曾经介绍过，SAP S/4HANA Service 模块的 UI，依然基于 SAP WebClient UI 开发。Service 模块在 SAP 外部简称为 S4CRM，官网称呼为 S/4HANA for Customer Management，详情参考 Jerry 的文章：Hello World, S/4HANA for Customer Management 1.0.

SAP S/4HANA 除了 Service 之外的其余模块，其 UI 通过 SAP Fiori Elements 开发，该框架后盾模型为加上了注解的 SAP CDS view 即裸露给外界生产的 OData 服务，前台开发框架为 SAP UI5. Component.js 是所有配置到 SAP Fiori Launchpad 中的 SAP UI5 利用的入口。

以 SAP S/4HANA Sales Management Overview 这个 Fiori 利用为例：

和其余所有基于 Fiori Elements 开发的利用一样，Sales Management Overview 利用工程内仅蕴含一个 Component.js, 该文件内申明了对 manifest.json 文件的援用。其余在 Freestyle SAP UI5 开发模式下须要利用开发人员编写的 Controller，View 等资源文件，在 Fiori Elements 利用里均被 SAP UI5 框架提供的模板版本所取代。

在 manifest.json 文件里，咱们能失去下列这些信息：

该 Fiori 利用生产的 OData 服务名称，SD_OVP_SM
该 Fiori 利用生产的 OData 服务基于的 CDS view 名称：C_PROFITMARGINBYMONTHQUERY_CDS
Fiori 利用 ID：F2601

有了 F2601 这个 Fiori ID 之后，从 Jerry 文章 SAP Fiori 利用索引大全里介绍的网站上，依据该 ID，即可查问到该 Fiori 利用的设计详情：

对于 SAP Fiori Elements 利用 manifest.json 更多的细节介绍，请参考 Jerry 之前的文章：

在没有任何前端开发教训的根底上, 创立第一个 SAP Fiori Elements 利用
答网友发问：应用 SAP Fiori Tools 创立的 Fiori Elements 利用，如何进行二次开发？

对于 SAP Fiori Elements 开发的更多介绍，能够参考 Jerry 翻译的 OpenSAP 上的公开课。因为工作忙碌，目前只实现了前四期视频的翻译工作：

OpenSAP Fiori Elements 公开课第一单元：总体介绍
OpenSAP Fiori Elements 公开课第二单元：架构介绍
OpenSAP Fiori Elements 公开课第三单元：OData 服务和注解介绍
OpenSAP Fiori Elements 公开课第四单元：开发环境搭建

同 ABAP Webdynpro 一样，SAP Cloud for Customer 的组件开发，也是在所见即所得的编辑器里进行，这个编辑器叫做 UI Designer.

如果说 SAP Fiori Elements 是基于 CDS view 以及 OData 服务进行的组件开发，那么 SAP Cloud for Customer 的组件开发则是基于 Business Object 驱动的。

开发人员应用 SAP Cloud Application Studio 实现 Business Object 模型创立后，能够应用向导，一键生成针对该 BO 进行增删改查操作的全套 UI. 这些 UI 类型各异, 由不同的组件所实现。

关上任意一个 UI 组件，发现其依然分为 MVC 三层。其中视图层，开发人员能够在 Toolbox 面板中拖拽适合的 UI 控件，以所见即所得的形式设计视图;

在模型层，抉择 C4C 规范的 BO 或者 Partners 二次开发的 BO, 能够实现视图控件字段同 BO 字段的数据绑定;

在控制器层面，能够采纳非编码的申明形式，指定该视图响应用户操作之后，应该执行何种业务逻辑。

因为历史起因，SAP C4C 用户拜访入口，并不是像 S/4HANA 那样采纳了 Fiori Launchpad，而是同 SAP CRM 一样，抉择工作核心 (Work Center) 作为入口。

用户被调配的业务角色 (Business Role) 决定了其可能拜访的工作核心。C4C 的 UI 组件被增加到工作核心视图中，后者再被增加到工作核心内，从而被用户拜访。

因为并未通过 Fiori Launchpad, 进行治理，所以 C4C 组件也就不存在 Component.js. 每个 C4C UI 组件实质上是一个 XML 文件，该文件存储在 C4C 后盾一个叫做 X-Repository 的基础设施上。

运行时当所属的工作核心视图被拜访时，UI 组件的源代码从 C4C 后盾加载到浏览器，被 SAP UI5 框架解析。后者依照 C4C 特有的视图格局，依据组件源代码里蕴含的控件定义内容，创立对应的 UI5 控件实例。这些控件实例再应用对应的渲染器，依照文章深刻学习 SAP UI5 框架代码系列之二：UI5 控件的渲染器里介绍的逻辑，生成最终的原生 HTML 源代码。

传统的 SAP UI5 利用里，UI5 框架基于 JavaScript 或者 XML 视图文件，创立对应的 SAP UI5 控件实例。而 C4C 则是基于组件视图文件，进行控件实例化，这算是 C4C 组件应用 SAP UI5 的独特之处。

对于 C4C 组件设计的更多细节和其与 SAP UI5 框架交互的深入分析，请参考我的共事 Yang Joey 的文章: SAP Cloud for Customer 应用 SAP UI5 的独特之处。

SAP Commerce Cloud UI 作为 Headless Commerce 即无头电商架构的前端展示层，是一个 100% API 驱动的电商 Storefront：店铺待显示的组件列表，通过 API 调用的形式从 Commerce Cloud 后盾端的内容管理系统 (Content Management System，简称 CMS) 中获取，而店铺具体显示的视图成果和与用户交互的逻辑，由前端基于 Angular 的组件实现。

以 SAP Commerce Cloud UI 关上后显示的默认主页为例，该页面的 id 为 homepage，其页面显示的内容列表，在 SAP Commerce Cloud Backoffice CMS 控制台中定义。

SAP Commerce Cloud 中一个页面被划分成若干个区域，这些区域被所谓的 ContentSlot(内容插槽)来辨别，这个名称很形象——每个内容插槽，容许插入一个或者多个组件。

在 CMS Page 编辑页面里，点击 Content Slots 面板，定义该页面由哪些内容插槽组成：

下图展现了 homepage 由内容插槽 Section1, Section2A，Section2B，Section2C 等区域组成。

一个 Content Slot 能够包容多个组件，下图展现了 Section1 这个 Content Slot，包容 Electronics Homepage Splash Banner Component 和 Electronics Homepage Splash Discount Component 这两个组件。

大家能够类比前文介绍的 SAP CRM 容器组件，用户能够指定容器组件内显示哪些其余组件的视图，二者的设计思路是统一的。

SAP Commerce Cloud CMS 只负责定义页面的 Content Slots 信息和 Content Slots 内蕴含的组件信息，而不负责具体的页面视图开发以及用户交互逻辑开发——后者均是由 Jerry 所在的团队，开发的 SAP Spartacus 这个开源我的项目里实现。

每一个在 SAP Commerce Cloud CMS 中定义的组件，在 SAP Spartacus 中都有一个与之一一对应的 Angular 组件。

当在浏览器中关上 SAP Commerce Cloud UI 时，SAP Spartacus 会发动一个 API 调用，向 Commerce Cloud 后盾索取该页面的 CMS 信息。下图展现了 homepage 在 CMS 中的建模信息，通过 API 调用的形式返回给 SAP Spartacus：

其中 Section1 这个 Content Slot 里蕴含的两个 Components 名称，正是我之前在 Commerce Cloud CMS 里保护的两个 Component：

SAP Spartacus 接管到这些 API 响应后，解析出 CMS Component 的名称以及与其一一对应的 Angular Component 的名称，将后者动静渲染进去。

下图是 SAP Commerce Cloud 默认的主页：

如何能力晓得其中哪个区域，代表我前文提到的内容插槽 Section1，及搁置在其中的两个组件呢？

我在 SAP Spartacus 渲染 Content Slots 中搁置的组件代码地位处，加上了一些调试信息，打印出了 Slot ID 和 Component ID，便于大家了解：

刷新 SAP Commerce Cloud 页面：

依据页面上打印的调试信息，高深莫测，下图黄色高亮局部，代表 ID 为 Section1 这个内容插槽在页面上的起始地位。绿色高亮为 Section1 蕴含的两个组件的 ID，而红色及蓝色矩形框，代表的是这两个组件被 Angular 渲染后的最终显示成果：

本文概述了 SAP CRM，SAP S/4HANA，SAP Cloud for Customer 和 SAP Commerce Cloud 这四个产品中前端 UI 开发中应用到的组件理念。尽管具体实现技术不同，但这四个产品前端的组件，都体现了对各自实现性能的封装，以及作为应用程序前端界面构建块的用处。

因为篇幅所限，本文没有方法针对每个产品逐个开展深刻介绍，大家能够应用我这篇文章如何高效搜寻汪子熙公众号发表的文章介绍的搜寻性能，搜寻本公众号之前公布的文章，以对这些产品的 UI 开发技术进行深刻理解。

感激浏览。

更多 Jerry 的原创文章，尽在：” 汪子熙 ”:

正文完