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 元数据请求处理逻辑的蓝色块分支。其他颜色的分支逻辑，在后续文章继续介绍。