在一个经典的 SAP Gateway 项目里，经常会遇到这样一种现象。后端已经修改了 OData 的 UI Annotation，ABAP 类也成功激活，甚至在SE24或SE80里能够清楚看到最新代码，可是打开 SAP Fiori 应用之后，页面布局依旧没有变化。再去访问$metadata，看到的仍然像是旧版本。很多排查工作会自然地落到 SAPUI5 缓存、浏览器缓存或者前端代码上，但对于采用独立 Vocabulary Annotation Model 的项目来说，真正缺失的环节可能发生在 SAP Gateway 的 annotation registration、metadata cache 和 Catalog Service 这一整条链路上。这里涉及的核心配置就是Maintain Annotation Models。这个名字看起来像一个普通的 Customizing 配置项，但它所管理的并不是几行简单配置，而是把Annotation Provider Class、OData Service、SAP Gateway backend routing、metadata cache、repository object、transport request 和 Catalog Service 串联起来的一套运行时注册机制。理解这套机制以后，很多看起来莫名其妙的问题就容易解释了。为什么 Annotation Provider Class 已经激活，Fiori 页面仍然看不到新注解。为什么同一个 Annotation Model 可以服务多个 OData Service。为什么多个 S SAP Gateway Maintain Annotation Models 深度解析，独立注解模型如何完成注册、路由、缓存与运行时发布
在一个经典的 SAP Gateway 项目里，经常会遇到这样一种现象。后端已经修改了 OData 的 UI Annotation，ABAP 类也成功激活，甚至在SE24或SE80里能够清楚看到最新代码，可是打开 SAP Fiori 应用之后，页面布局依旧没有变化。再去访问$metadata，看到的仍然像是旧版本。很多排查工作会自然地落到 SAPUI5 缓存、浏览器缓存或者前端代码上，但对于采用独立 Vocabulary Annotation Model 的项目来说，真正缺失的环节可能发生在 SAP Gateway 的 annotation registration、metadata cache 和 Catalog Service 这一整条链路上。这里涉及的核心配置就是Maintain Annotation Models。这个名字看起来像一个普通的 Customizing 配置项，但它所管理的并不是几行简单配置，而是把Annotation Provider Class、OData Service、SAP Gateway backend routing、metadata cache、repository object、transport request 和 Catalog Service 串联起来的一套运行时注册机制。理解这套机制以后，很多看起来莫名其妙的问题就容易解释了。为什么 Annotation Provider Class 已经激活，Fiori 页面仍然看不到新注解。为什么同一个 Annotation Model 可以服务多个 OData Service。为什么多个 S