关于saprfc:聊聊-SAP-产品-UI-上的消息显示机制

5次阅读

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

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

本文从 StackOverflow 社区上来自 Partner 的一个 SAP Commerce Cloud Spartacus UI 的定制化需要说起。

这个需要的背景是，客户在 SAP 电商云的产品明细页面，能够留下本人的评论，点击 Submit 按钮提交。

提交之后，能看到“谢谢评论”的提醒音讯。

客户定制化需要是：不执行这个默认的音讯显示逻辑，即不显示音讯，而是执行其余逻辑，比方短信告诉或邮件告诉。

咱们先简略回顾 SAP 其余产品的 UI 音讯显示机制。

音讯是应用程序执行过程中给用户提供反馈的重要渠道之一，通常由用户某个动作间接触发，显示在产品界面上。当然应用程序后台作业运行到某个阶段，在满足指定条件时也能触发音讯显示。扼要、清晰而精确的音讯，能帮忙用户明确程序以后的运行状况，指引其下一步的操作。

SAP 产品 UI 显示的音讯文本，均有业余的 Knowledge Management 即 KM 团队负责审查和公布。

对于 SAP 开发人员来说，更关怀的则是这些音讯显示的上下文；换言之，看到 UI 上显示一条音讯之后，是否在最短的工夫内，高效定位到抛出该音讯的精确代码地位。

如下图所示，在经典的 SAPGUI SE38 ABAP 程序编辑器，输出一个不存在的报表名称，会显示一条音讯：

Program XX does not exist.

其中 XX 是占位符，会被用户理论输出的报表名称所替换。

基于 ABAP 实现的所有 SAP 产品，比方 SAP CRM，SAP SRM，SAP S/4HANA，SAP Cloud for Customer，UI 上显示的每一条音讯，在 ABAP 后盾均有一条对应的音讯记录，保护在事物码 SE91 里。

以上图的音讯为例，其号码为 DS017，其中 DS 为音讯类别, 017 为音讯编号，二者惟一确认一条音讯记录。

Jerry 之前的文章SAP 谬误音讯调试之七种武器：让所有的谬误音讯都能被定位，已经介绍过七种不同的办法，均能在 SAPGUI 环境里，已知音讯类和音讯编号，疾速找到抛出该音讯的精确地位。

到了 SAP CRM WebClient UI 里，浏览器上看到的每一条音讯，比方下图 Data Contains errors and cannot be saved, 依然惟一对应后盾一条音讯记录 CRM_BUPA_BOL/036:

这条音讯是由 Business Partner 利用负责保护的。

如何查找抛出 SAP WebClient UI 音讯的对应后盾代码地位，在 Jerry 的 SAP 社区博客上有介绍：

How to quickly locate the source code where a given message is raised in WebClient UI

到了 SAP Cloud for Customer，尽管 Partners 无奈间接登录 ABAP 后盾，然而依然能够通过 Chrome 开发者工具，失去 UI 音讯对应的 ABAP 后盾音讯记录的音讯类和音讯编号：

在 SAP Cloud for Customer 里，Partners 能够通过 Cloud Application Studio 新建 UI 音讯：

在 ABSL 代码里，通过 raise 语句显示音讯到 UI 上：

raise delivery_message.Create(“S”, this.OutboundDeliveryID);

运行时 delivery_message 定义的音讯文本里的 &1, 会被 this.outboundDeliveryID 字段的值取代。

到了 SAP S/4HANA 里，所有基于 Fiori Elements 创立的 Fiori 利用，共享同一套视图模板和控制器实现，因而大多数音讯不再由应用程序各自定义，而由框架对立保护。

比方下列 S/4HANA 物料主数据保护时的谬误音讯：

Product Type 03 is not valid：

这条音讯保护于所谓的 Business Suite Foundation Reusable Components 开发包中的音讯类 /BOFU/CODE_LISTS 外部。

咱们再来剖析本文结尾提到的 SAP Commerce Cloud 的音讯显示定制化需要。

“感激评论”的音讯文本 ID 为 productReview.thankYouForReview, 在 ProductReviewEffects 接管到 POST_PRODUCT_REVIEW_SUCCESS 这个 Action 之后通过 MessageService 显示到 UI 上。

一种最惯例的二次开发思路就是，继承 SAP Commerce Cloud UI 规范公布的 ProductReviewEffects 类，重载其接管到 POST_PRODUCT_REVIEW_SUCCESS 之后的实现代码，将调用 MessageService 抛出感激评论的代码删除掉即可。

然而 SAP Commerce Cloud UI 公布的所有 Effects 实现类都是不可扩大的，因而这条思路行不通。

Jerry 之前的文章：Jerry 在 2020 SAP 寰球技术大会的分享：SAP Spartacus 技术介绍的文字版，已经介绍过 SAP 电商云 Spartacus UI，同 Commerce 后盾交互的逻辑：

过后我着重论述的，是上图右侧红色高亮区域的交互原理。

Spartacus 同 Commerce 零碎的通信，通过 HTTP 协定调用 OCC API 实现。Connector 是 HTTP 调用的发起者，保护了动态的配置信息，即 API endpoint.

比方，从 Commerce 零碎读取产品主数据，读取的字段列表以 url 参数的模式呈现在 API endpoint 里。这些字段列表能够在 Connector 的动态配置点里进行配置。

Connector 并不会间接同 Commerce 交互，而是把申请转发给 Adapter，具体通信由 Adapter 实现，Connector 只负责调度 Adapter. Spartacus 公布的 Adapter 默认应用 OCC Module，即 Commerce 规范的 OCC Restful API，然而客户也能够实现本人的 Adapter，连贯 Commerce 之外的其余后盾零碎。

Connector 将 Adapter 取回的数据交给 NgRx Store 构造对立治理，后者的复杂度被 Facade 层所暗藏，而 Spartacus UI 组件只会同 Facade 层交互，进行数据绑定和页面展现。这体现了关注点拆散的设计准则。

再回到本文结尾客户提出的定制化需要。为了实现该需要，咱们须要深刻理解下图红色高亮区域即 NgRx Store 和 SAP Spartacus Connector 交互的细节。

NgRx 是 Angular 基于 RxJs 的一个响应式状态治理库，蕴含下列外围概念，Jerry 会联合 SAP Commerce Cloud UI 对 NgRx 的理论应用状况来举例说明。

Action：其实就是编程畛域的事件的别名。SAP Commerce Cloud UI 组件，能响应用户操作，通过组件的 Service 实例，投递出相应的 Action. Action 投递方和 Action 接管方是解耦的，彼此感知不到对方。

下图是 SAP 电商云产品明细页面评论区域的 Submit 按钮被点击之后，对应的 Service 类抛出 PostProductReview Action 的代码：

ProductActions.PostProductReview 是 NgRx Action 的一个子类，type 字段为 POST_PRODUCT_REVIEW，构造函数的参数 payload，定义了调用 Commerce OCC API 长久化用户评论须要传递的数据结构：

Effects：SAP Commerce Cloud UI Action 的接管方之一。下图 Effects 代码的语义是：接管类型为 POST_PRODUCT_REVIEW 的 Action(第 46 行)，调用前文介绍的 Connector，向 Commerce 后盾发动 OCC API 调用(第 49 行)，依据 API 返回后果，别离投递评论保留胜利或失败的 Action：
PostProductReviewSuccess(第 53 行)
PostProductReviewFail(第 56 行)

Store：Angular 利用保护在内存中的存储构造，寄存了 SAP Commerce Cloud UI 所有组件的运行时数据。每当 Effects 调用 Commerce OCC API 拿到新的数据时，调用 Reducer，将增量数据填充到 Store 中去。
Reducer：实质上是一个无限状态自动机，每当收到代表来自 Commerce 后盾的数据发生变化的 Action 时，状态机驱动对应的 Reducer, 依据新的 Action 蕴含的负载，对 Store 中的数据进行调整。

例如产品明细页面第一次渲染时，Effects 须要从 Commerce 后盾读取所有的评论数据。读取胜利后，抛出 LOAD_PRODUCT_REVIEWS_SUCCESS Action. 下图的 ProductReviewsReducer 接管到该 Action，从其 payload 中解析出理论评论数据并返回。这些返回的数据会被 NgRx 框架接管，并合并到 Store 中去。

Selector：纯函数，作为应用程序从 NgRx Store 中读取最新数据的接口。

理分明 SAP Commerce Cloud UI 应用 NgRx 进行状态治理的细节之后，对于文章结尾的客户定制化需要，也就不难实现了。

既然下图所示的 SAP Commerce Cloud UI 规范的 Effects 无奈扩大，咱们留神到 UI 组件的 Service 层，才是所有事件流的起始点，因而能够实现新的 Service，来替换 SAP 电商云 UI 规范的 Service，而后基于该定制化 Service，实现配套的 Effects 和 Action.

如此一来，规范的和用户评论相干的逻辑流 (如下图 1-2-3 所示) 将不会再失去执行，取而代之的是咱们本人定制化的执行流，如下图 A-B-C 所示，其中蓝色的图例均为 Partners 须要开发的定制化代码。

这个解决方案的简要介绍：

(1) 创立新的 Action CustPostProductReview，CustPostProductReviewSuccess 和 CustPostProductReviewFail. 其实就是在规范的实现类之前，增加 Cust 的前缀。

(2) 创立新的 CustProductReviewService，继承规范的 ProductReviewService. 重载其 add 办法，抛出新的 CustPostProductReview Action.

(3) 新建 CustProductReviewsEffects，接管新的 Action CUST_POST_PRODUCT_REVIEW(第 25 行)，仍旧调用 Connector 将用户评论长久化到 Commerce 后盾(第 28 行)，而后抛出新的 Action CustPostProductReviewSucess.

自定义 Effect 接管到新的 Action CUST_POST_PRODUCT_REVIEW_SUCCESS 之后，就能够进行自定义逻辑编写。

(4)将自定义的 Effect 和 Service 实现，通过 Angular 依赖注入框架，配置到对应的 Module 中。

本需要在 SAP Spartacus 3.1 版本测试通过。

更多浏览