做 SAP Gateway 开发时，有一类问题很容易把排查方向带偏。一个 OData 服务本身可以正常访问，$metadata也能生成，Entity、Property、Association 都没有问题，SAP Fiori elements 页面甚至已经可以打开，但 Annotation 里的某些Label却突然变成空字符串。开发人员很自然地会想到 Metadata Cache，于是开始执行/IWFND/CACHE_CLEANUP、/IWBEP/CACHE_CLEANUP，重新加载 Metadata，甚至重新注册 OData Service。缓存全部清掉之后，结果依然没有变化。这类问题里，有一个并不显眼却非常关键的扩展点，就是/IWBEP/CL_MGW_ABS_MODEL里的GET_VOCAN_PROVIDER_TEXTS。SAP 官方文档把/IWBEP/CL_MGW_ABS_MODEL定义为 Model Provider Class，也就是 MPC 的抽象基类。具体的 Model Provider 实现都会建立在这个抽象模型之上。除了我们熟悉的DEFINE、GET_LAST_MODIFIED之外，它还承担了 Vocabulary Annotation 文本解析的一部分职责。GET_VOCAN_PROVIDER_TEXTS看起来只是一个取文本的方法，但真正理解它，需要先把 OData Annotation、Annota
做 SAP Gateway 开发时，有一类问题很容易把排查方向带偏。一个 OData 服务本身可以正常访问，$metadata也能生成，Entity、Property、Association 都没有问题，SAP Fiori elements 页面甚至已经可以打开，但 Annotation 里的某些Label却突然变成空字符串。开发人员很自然地会想到 Metadata Cache，于是开始执行/IWFND/CACHE_CLEANUP、/IWBEP/CACHE_CLEANUP，重新加载 Metadata，甚至重新注册 OData Service。缓存全部清掉之后，结果依然没有变化。这类问题里，有一个并不显眼却非常关键的扩展点，就是/IWBEP/CL_MGW_ABS_MODEL里的GET_VOCAN_PROVIDER_TEXTS。SAP 官方文档把/IWBEP/CL_MGW_ABS_MODEL定义为 Model Provider Class，也就是 MPC 的抽象基类。具体的 Model Provider 实现都会建立在这个抽象模型之上。除了我们熟悉的DEFINE、GET_LAST_MODIFIED之外，它还承担了 Vocabulary Annotation 文本解析的一部分职责。GET_VOCAN_PROVIDER_TEXTS看起来只是一个取文本的方法，但真正理解它，需要先把 OData Annotation、Annota
