在 SAP Gateway Foundation 里开发 OData V4 服务时，有一个阶段特别容易被低估，那就是元数据模型的构建。很多项目中的注意力会自然落到 DPC、HTTP 请求、$filter、$expand、分页或者业务查询逻辑上，可真正决定客户端如何理解整个服务的，却是 MPC 中生成的 metadata model。一个 Entity Type 叫什么，一个 Property 对外暴露什么名字，一个 ABAP 字段最终成为Edm.String还是Edm.Decimal，某个字段是否带有 Label、Conversion、Value Help，一段业务逻辑究竟表现为普通 Function 还是 Bound Function，这些事情都发生在元数据层。SAP Gateway Foundation 的 OData V4 模型并不是简单地拼出一份$metadataXML。MPC 中的/IWBEP/IF_V4_MP_BASIC~DEFINE执行结束后，Gateway Framework 还会继续完成 model finalization，包括补齐没有显式设置的默认值、完善 metadata artefact 之间的引用关系、推导运行期使用的内部信息，并对模型做一致性校验。完成这些工作后，模型会进入只读状态。运行期间如果只是读取模型，需要使用带_R后缀的 read access interface，而不是继续通过模型创建接口修改 metadata。理解这一层以后，很多 Gateway V4 问题会清晰很多。开发阶段 从 ABAP 结构到 OData V4 元数据，读懂 SAP Gateway Foundation 的模型构建逻辑
在 SAP Gateway Foundation 里开发 OData V4 服务时，有一个阶段特别容易被低估，那就是元数据模型的构建。很多项目中的注意力会自然落到 DPC、HTTP 请求、$filter、$expand、分页或者业务查询逻辑上，可真正决定客户端如何理解整个服务的，却是 MPC 中生成的 metadata model。一个 Entity Type 叫什么，一个 Property 对外暴露什么名字，一个 ABAP 字段最终成为Edm.String还是Edm.Decimal，某个字段是否带有 Label、Conversion、Value Help，一段业务逻辑究竟表现为普通 Function 还是 Bound Function，这些事情都发生在元数据层。SAP Gateway Foundation 的 OData V4 模型并不是简单地拼出一份$metadataXML。MPC 中的/IWBEP/IF_V4_MP_BASIC~DEFINE执行结束后，Gateway Framework 还会继续完成 model finalization，包括补齐没有显式设置的默认值、完善 metadata artefact 之间的引用关系、推导运行期使用的内部信息，并对模型做一致性校验。完成这些工作后，模型会进入只读状态。运行期间如果只是读取模型，需要使用带_R后缀的 read access interface，而不是继续通过模型创建接口修改 metadata。理解这一层以后，很多 Gateway V4 问题会清晰很多。开发阶段