最近在看 SAP Gateway Foundation 2025 FPS01 的运行时对象文档时，有一个细节很容易被一带而过。我们在SEGW里设计好 Entity Type、Entity Set、Association、Property，再点击生成 Runtime Artifacts 之后，屏幕上那些看起来只是辅助生成物的MPC、MPC_EXT、DPC、DPC_EXT，实际上已经把一个 OData Service 分成了两套完全不同的运行时职责。其中最容易被低估的，就是 Model Provider Class，也就是大家熟悉的MPC。SAP 官方对它的定义非常简洁，Model Provider 中包含在运行时定义 OData Service 数据模型的 ABAP 代码。这句话看上去平淡，真正放进 SAP Fiori 的执行链路里，分量却很重。一个 Fiori Elements 应用访问 OData Service 时，并不是拿到 JSON 数据就开始画页面。它需要知道服务里有什么 Entity Type，一个 Entity 有哪些 Property，哪个字段是 Key，字段属于Edm.String还是Edm.Decimal，是否允许过滤，是否允许排序，Entity 之间有什么 Association，Navigation Property 指向哪里，以及哪些字段具有特定的 SAP Semantic。这些信息最终都会体现在 OData Metadata 中，也就
最近在看 SAP Gateway Foundation 2025 FPS01 的运行时对象文档时，有一个细节很容易被一带而过。我们在SEGW里设计好 Entity Type、Entity Set、Association、Property，再点击生成 Runtime Artifacts 之后，屏幕上那些看起来只是辅助生成物的MPC、MPC_EXT、DPC、DPC_EXT，实际上已经把一个 OData Service 分成了两套完全不同的运行时职责。其中最容易被低估的，就是 Model Provider Class，也就是大家熟悉的MPC。SAP 官方对它的定义非常简洁，Model Provider 中包含在运行时定义 OData Service 数据模型的 ABAP 代码。这句话看上去平淡，真正放进 SAP Fiori 的执行链路里，分量却很重。一个 Fiori Elements 应用访问 OData Service 时，并不是拿到 JSON 数据就开始画页面。它需要知道服务里有什么 Entity Type，一个 Entity 有哪些 Property，哪个字段是 Key，字段属于Edm.String还是Edm.Decimal，是否允许过滤，是否允许排序，Entity 之间有什么 Association，Navigation Property 指向哪里，以及哪些字段具有特定的 SAP Semantic。这些信息最终都会体现在 OData Metadata 中，也就
)
