在 SAP Gateway 项目里重定义CREATE_ENTITY时，经常会看到一行很短的代码，io_data_provider-read_entry_data。表面上，它只是把请求数据读进一个局部结构。真正把调用链往前追，会发现这一行代码正好卡在 HTTP 世界和 ABAP 类型世界的交界处。浏览器、SAPUI5、Postman 或外部系统发送过来的内容原本只是 OData 请求正文，到了 DPC 的业务实现里，却已经可以按MPC生成的 ABAP 类型来访问字段。中间完成这次转换的关键接口，就是/IWBEP/IF_MGW_ENTRY_PROVIDER。SAP 官方对这个接口的定义很直接，它用于访问并反序列化消费者在更新和创建请求中提交的数据。接口的核心方法是READ_ENTRY_DATA，参数ES_DATA接收应用侧结构，普通创建或更新使用扁平结构，Deep Insert 则需要嵌套结构。这段定义不长，但里面其实包含了 SAP Gateway 数据处理链路里几个很关键的设计点。IO_DATA_PROVIDER并不是业务实体本身，也不是 HTTP Request 的简单包装，更不是一段可以随意读取的 JSON 字符串。它扮演的是请求实体提供者，Gateway Framework 已经识别了 OData 元数据、请求实体和属性映射，应用代码再通过READ_ENTRY_DATA把这些内容落到一个 ABAP 目标结构里。它解决的并不是读取字符串
