这是Jerry在2021年的第54篇文章，也是王子熙第331篇原创文章公众号。任何企业级软件的前端开发都离不开组件的概念。不管具体的UI开发技术如何，所谓的组件就是界面的组件（UIBuildingBlocks）。组件在视觉或业务功能上可以看作是一个单一的元素。组件可以被组成应用程序的其他组件重用或包含。理想情况下，对于一个设计良好的组件，它对其他组件或外部服务的依赖可以被适当地隔离，从而使该组件可以进行单元测试甚至自动化。近年来，随着微服务架构的浪潮而兴起的微前端设计理念，甚至在同一个应用中支持不同的UI组件，采用不同的前端技术进行开发。这些异构的UI组件可以独立开发、测试、部署和交付，通过统一的微前端容器进行管理，构成最终被用户使用的前端程序。Luigi是SAP推出的微前端框架。微前端框架的使用超出了本文的范围。本文介绍了以下四款SAP产品使用的前端开发框架/工具中包含的组件的概念。SAPCRM/SRMSAPS/4HANASAPCloudforCustomerSAPCommerceCloud本世纪初，随着企业应用软件从Client/Server模式向Browser/Server模式迁移，SAPCRM和SAP的前端开发技术SRM也走上了不同的道路。两条进化路径：分别基于SAPWebClientUI和ABAPWebdynpro。关于这两种技术的更多介绍以及SAPUI开发技术的演进路径，请参考Jerry的上一篇文章：浅谈SAPUI与SalesforceUI开发。SAPWebClientUI的前身是SAPBSP-BusinessServerPage。WebClientUI在此基础上引入了组件的概念，并在视图层增加了对BSP扩展标签库的支持，大大提高了其开发效率。SAPS/4HANAService模块领域依然采用基于SAPWebClientUI的开发方式。基于SAPWebClientUI的应用程序通常由多个组件组成。单个组件的开发还是基于传统的MVC，其中Model层的ContextNode由ABAPClass实现，而ABAPWebdynpro中的ContextNode采用的是ABAPDDIC数据域中的数据结构。WebClientUI组件的视图层基于HTML，可以复用SAP标准BSPExtension中提供的HTML标签。大多数情况下，应用开发者不需要编写原生的HTML代码，这也降低了开发门槛。ABAPWebdynpro组件视图层开发是在SAP提供的所见即所得的布局编辑器中进行的，开发者不能使用原生的HTML编辑方式来开发视图。WebClientUI中有一类特殊的组件，它充当容器的角色，负责根据用户配置显示其包含的其他组件的视图。下图为示例：SAPCRM产品概览页面，左侧红色区域为容器组件支持的所有组件和组件视图的列表，右侧为当前用户配置的容器显示哪个组件视图和这些组件视图的加载方法：直接加载或延迟加载。这种从支持的组件列表中选择部分加载的配置方式，本文后面在介绍SAPCommerceCloud组件时会再次提到。SAPS/4HANA如前所述，SAPS/4HANAService模块的UI仍然是基于SAPWebClientUI开发的。Service模块在SAP内部简称为S4CRM，正式名称为S/4HANAforCustomerManagement。详见Jerry的文章：HelloWorld,S/4HANAforCustomerManagement1.0.SAPS/4HANA除Service外的其他模块，其UI是通过SAPFioriElements开发的，框架的后台模型是带注解的SAPCDS视图，是暴露给外部消费的OData服务，前端开发框架是SAPUI5。Component.js是所有在SAPFioriLaunchpad入口配置的SAPUI5应用。以SAPS/4HANASalesManagementOverview的Fiori应用为例：与所有其他基于FioriElements开发的应用一样，SalesManagementOverview应用项目只包含一个Component.js，它声明了对manifest.json文件的引用。FreestyleSAPUI5开发模式下剩余的Controller、View等需要应用开发者编写的资源文件在FioriElements应用中替换为SAPUI5框架提供的模板版本。在manifest.json文件中，我们可以得到如下信息：Fiori应用消费的OData服务名称，SD_OVP_SM基于Fiori应用消费的OData服务的CDS视图名称：C_PROFITMARGINBYMONTHQUERY_CDSFiori应用ID：F2601有了FioriID之后F2601，从Jerry的文章SAPFiori应用索引大全中介绍的网站，根据ID可以查询到Fiori应用的设计细节：SAPFioriElements应用manifest.json的更多细节可以参考Jerry之前的文章:在没有任何前端开发经验的基础上，创建第一个SAPFioriElements应用，回答网友提问：用SAPFioriTools创建的FioriElements应用如何进行二次开发？关于SAPFioriElements开发的更多介绍，可以参考Jerry翻译的关于OpenSAP的公开课。由于工作繁忙，只完成了前四个视频翻译：OpenSAPFioriElementsOpenCourseUnit1:GeneralIntroductionOpenSAPFioriElementsOpenCourseUnit2:ArchitectureIntroductionOpenSAPFioriElementsOpenCourseUnit3:ODataServiceandNotes介绍OpenSAPFioriElementsOpenCourseUnit4:DevelopmentEnvironmentBuildingSAPCloudforCustomer和ABAPWebdynpro一样，SAPCloudforCustomer的组件开发也是在一个名为UIDesigner的所见即所得的编辑器中进行的。如果说SAPFioriElements是基于CDS视图和OData服务的组件化开发，那么SAPCloudforCustomer的组件化开发是由BusinessObject驱动的。开发者使用SAPCloudApplicationStudio完成BusinessObject模型的创建后，可以通过向导生成一整套BO的增删改查UI，一键生成。这些UI的类型不同，由不同的组件实现。打开任意一个UI组件，发现还是分为三层MVC。在视图层，开发者可以在工具箱面板中拖放合适的UI控件，以所见即所得的方式设计视图；在模型层，选择C4C标准BO或Partners二次开发BO，完成视图控制字段与BO字段的数据绑定；在控制器层面，可以使用非编码声明来指定视图响应用户操作后应该执行哪些业务逻辑。由于历史原因，SAPC4C用户访问入口没有像S/4HANA那样使用FioriLaunchpad，而是像SAPCRM一样选择WorkCenter作为入口。用户分配的业务角色（业务角色）决定了用户可以访问的工作中心。C4C的UI组件被添加到工作中心视图，然后添加到工作中心以供用户访问。因为不是通过FioriLaunchpad管理的，所以没有用于C4C组件的Component.js。每个C4CUI组件本质上都是一个XML文件，存储在C4C后台一个叫做X-Repository的基础设施上。运行时，当访问其所属工作中心的视图时，UI组件的源代码从C4C后台加载到浏览器，由SAPUI5框架解析。后者根据C4C特有的视图格式，根据组件源码中包含的控件定义内容，创建对应的UI5控件实例。这些控件实例再根据深入学习SAPUI5框架代码系列之二：UI5控件的Renderer一文介绍的逻辑，使用相应的renderer生成最终的nativeHTML源码。在传统的SAPUI5应用中，UI5框架根据JavaScript或XML视图文件创建对应的SAPUI5控件实例。C4C基于组件视图文件进行控件实例化，这是C4C组件使用SAPUI5的独特之处。关于C4C组件的更多设计细节以及与SAPUI5框架交互的深入分析，请参考我同事YangJoey的文章：UniquefeaturesofSAPCloudforCustomerusingSAPUI5。SAPCommerceCloudSAPCommerceCloudUI作为HeadlessCommerce的前端表示层，是一个100%API驱动的电子商务Storefront：商店中要显示的组件列表由Commerce的后端内容管理云端通过API调用系统（ContentManagementSystem，简称CMS），店铺具体展示的视图效果和与用户交互的逻辑都是基于Angular的前端组件实现的。以打开SAPCommerceCloudUI后显示的默认首页为例。该页面的id为首页，页面显示的内容列表在SAPCommerceCloudBackofficeCMS控制台定义。SAPCommerceCloud中的一个页面分为几个区域，这些区域由所谓的ContentSlot（内容槽）区分。这个名字很形象——每个内容槽允许插入一个或多个组件。在CMS页面编辑页面，点击ContentSlots面板，定义页面由哪些内容槽组成：如下图所示，首页由内容槽Section1、Section2A、Section2B、Section2C等区域组成。一个ContentSlot可以容纳多个组件。下图显示了ContentSlotSection1，其中包含ElectronicsHomepageSplashBanner组件和ElectronicsHomepageSplashDiscount组件。您可以将其与前面介绍的SAPCRM容器组件进行比较。用户可以指定在容器组件中显示其他组件的哪些视图。两者的设计思路是一样的。SAPCommerceCloudCMS只负责定义页面的ContentSlots信息和ContentSlots包含的组件信息，不负责具体的页面视图开发和用户交互逻辑开发——后者由Jerry的团队开发，SAPSpartacus在这个开源项目中实现。SAPCommerceCloudCMS中定义的每个组件在SAPSpartacus中都有对应的Angular组件。在浏览器中打开SAPCommerceCloudUI时，SAPSpartacus会调用API以从CommerceCloud后端请求页面的CMS信息。下图是CMS中主页的建模信息，通过API调用返回给SAPSpartacus：Section1的ContentSlot中包含的两个Components名称正是我之前在CommerceCloudCMS中维护的两个Component：SAPSpartacus收到这些API响应后，解析出CMS组件的名称和对应的Angular组件的名称，并动态渲染后者。下图是SAPCommerceCloud的默认主页：我怎么知道哪个区域代表了我前面提到的内容槽Section1以及放置在其中的两个组件？我在SAPSpartacus渲染ContentSlots放置组件代码的位置添加了一些调试信息，并打印出SlotID和ComponentID，方便理解：刷新SAPCommerceCloud页面：根据页面打印的调试信息，一目了然，下图中黄色高亮部分代表ID为Section1的contentslot在页面中的起始位置。绿色高亮部分是Section1中包含的两个组件的ID，红蓝矩形框分别代表这两个组件经过Angular渲染后的最终展示效果：总结本文提供了SAPCRM、SAPS/4HANA的概述,SAPCloudforCustomer和SAPCommerceCloud四款产品中前端UI开发使用的组件概念。虽然具体实现技术不同，但这四款产品的前端组件都体现了对各自功能的封装，以及作为应用程序前端界面的积木。由于篇幅有限，本文无法对每个产品进行一一深入介绍。大家可以使用我的文章《如何高效搜索王子熙公众号发表的文章》中的搜索功能，搜索在此公众号之前发表的文章。深入了解这些产品的UI开发技术。谢谢阅读。更多Jerry原创文章在这里：《王子熙》：
