答疑 - SAP OData 框架处理 Metadata 元数据请求的实现细节,前后端组件部署在同一台物理服务器

我的知识星球 里有一个朋友提出了 SAP OData 服务 metadata 缓存方面的疑问,本文就来详细说一说:

jerry,啥时候有时间给介绍一下fiori的Metadata数据系统的处理机制吧。我现在在做的一个项目,用rap开发的。rap开发的service binding,在maintain service注册时,开始注册的服务命名错了。后来发现了后就删除了重新创建了一次。结果就出现了一个很有意思的现象,有时候打开app,界面上的那些filtertable控件都不显示了。用前端的error_log看系统有个错误,是和以前创建的那个服务有关。可是那个服务明明已经删除了。后来我debug了一下,发现系统表/iwfnd/i_med_vaa表里确实有一条和以前的服务绑定的数据,很奇怪。我尝试了各种正常操作都不能删除这条数据。而且,更奇怪的是,前端的app并不是每次都会没有控件,有时候会有。下午大体跟了一下代码,感觉这个东西和metadata有关,还与缓存有关。感觉系统好像用到了share object缓存了数据,当缓存数据不存在时就会从vaa表去取,结果由于选的那条数据对应的服务不存在了就会异常,从而刷不出显示控件;而缓存有数据时就会用缓存的数据,所以就能显示。可缓存的数据怎么来的呢?感觉应该有个job会定时处理。可是搜了一圈,只找到一个ui5/upd_odata_metadata_cache的程序。可是这程序修改的表好像不是vaa的。感觉这里面的东西挺多的,jerry能给大体讲讲吗?或者能给点资料也行

SAP Fiori 技术架构存在 ABAP Frontend 服务器(有时也称为 Gateway 服务器,前台服务器) 和 ABAP Backend(后台)服务器两个角色,其中 Frontend 服务器上主要安装 SAP Gateway 组件(实现类和数据库表的命名空间为 /IWFND/) 和 SAP UI5 应用部署到 ABAP 系统后生成的 BSP 应用,后台服务器主要包含了 OData 服务的 ABAP 实现(DPC, DPC_EXT, MPC, MPC_EXT) ,即本教程开发的 OData 服务在事物码 SEGW里自动生成的以 Z 开头的一系列 ABAP 类:

以及 SAP OData 的框架代码,这些框架代码的命名前缀为 /IWBEP.

笔者的文章 SAP Fiori应用的三种部署方式

介绍过 Frontend 系统(下图红色区域)同 Backend 系统(下图绿色区域)在 SAP Fiori 架构体系中扮演的角色。

注意,理论上我们可以将上图 Frontend 和 Backend 系统组件部署在同一台物理服务器上,这也是最简单的一种部署体系架构。

因为一个 OData 元数据请求从浏览器或者 Postman 等工具发送,在 SAP 服务器响应过程中会依次经过 Frontend 和 Backend 服务器,其处理逻辑确实比较复杂,根据前台服务器和后台服务器的配置的不同排列组合,存在着非常多的处理分支,故我们不可能在一篇文章把所有这些处理分支全部介绍,故这个 OData Metadata 元数据的处理逻辑主题,笔者会利用几篇文章连续介绍。

本文介绍下图绘制的 SAP OData 元数据请求处理逻辑的蓝色块分支。其他颜色的分支逻辑,在后续文章继续介绍。

推荐阅读更多精彩内容