在SEGW里生成一个经典的 SAP Gateway OData V2 服务后，进入 Runtime Artifacts，经常会看到一组非常熟悉的 ABAP 类，XXX_MPC、XXX_MPC_EXT、XXX_DPC和XXX_DPC_EXT。平时业务开发最容易把精力放在DPC_EXT，因为读取订单、创建业务对象、处理$filter、实现 Function Import 等业务逻辑，大多发生在那里。可是一旦碰到$metadata不更新、前端仍然拿到旧字段、Transport 导入以后新属性迟迟不出现，或者 Gateway 元数据缓存反复被刷新，真正需要研究的往往不是DPC_EXT，而是隐藏在整个 Model Provider Class 继承体系底部的/IWBEP/CL_MGW_ABS_MODEL。SAP 官方对它的定位很直接，它是 Model Provider Class，也就是MPC的抽象基类。一个具体的 Model Provider 实现，最终都建立在这套基础能力之上。这个类里最关键的成员是MODEL，它就是构造 OData Channel Data Model 的入口对象。EntityType、EntitySet、Property、Association、Navigation Property、Complex Type、Function Import 以及各种 S
在SEGW里生成一个经典的 SAP Gateway OData V2 服务后，进入 Runtime Artifacts，经常会看到一组非常熟悉的 ABAP 类，XXX_MPC、XXX_MPC_EXT、XXX_DPC和XXX_DPC_EXT。平时业务开发最容易把精力放在DPC_EXT，因为读取订单、创建业务对象、处理$filter、实现 Function Import 等业务逻辑，大多发生在那里。可是一旦碰到$metadata不更新、前端仍然拿到旧字段、Transport 导入以后新属性迟迟不出现，或者 Gateway 元数据缓存反复被刷新，真正需要研究的往往不是DPC_EXT，而是隐藏在整个 Model Provider Class 继承体系底部的/IWBEP/CL_MGW_ABS_MODEL。SAP 官方对它的定位很直接，它是 Model Provider Class，也就是MPC的抽象基类。一个具体的 Model Provider 实现，最终都建立在这套基础能力之上。这个类里最关键的成员是MODEL，它就是构造 OData Channel Data Model 的入口对象。EntityType、EntitySet、Property、Association、Navigation Property、Complex Type、Function Import 以及各种 S
