在一套仍然运行着 SAP CRM、WebClient UI、BOL 和 GenIL 的经典 SAP Business Suite 系统里，经常会遇到这样一种需求，后台已经存在成熟的业务对象模型，销售机会、Business Partner、产品、市场活动、服务请求等业务能力也已经通过 GenIL 暴露给 WebClient UI 使用，现在希望移动应用、SAPUI5 应用或者其他 HTTP 客户端也能够访问这些业务数据。一种直接思路是重新开发一套 SAP Gateway OData Service，把 Entity Type、Entity Set、Association、Navigation Property、Query、Create、Update、Delete 等逻辑全部重新实现。但对于已经由 GenIL 建模的业务对象，这样做往往重复了大量已有工作。SAP Gateway 为此提供了一个很有代表性的 Integration Scenario，也就是把现有 GenIL 模型重新定义为 Gateway OData Service。SAP 官方对这种集成方式的定位很明确，GenIL 与 SAP Gateway 的集成可以把已有业务数据快速暴露成 OData Service，而 SAP Gateway Service Builder 中的Redefine service开发方式，本来就是为 SPI、BW Query、GenIL 等既有框架准备的复用机制。理解这套机制时，我更愿意把它看成一个模型适配器，而不是一个普通的代码生成器。在 SAP CRM 的经典 WebClient UI 架构里，Business Object Layer，也就是 BOL，负责向上
在一套仍然运行着 SAP CRM、WebClient UI、BOL 和 GenIL 的经典 SAP Business Suite 系统里，经常会遇到这样一种需求，后台已经存在成熟的业务对象模型，销售机会、Business Partner、产品、市场活动、服务请求等业务能力也已经通过 GenIL 暴露给 WebClient UI 使用，现在希望移动应用、SAPUI5 应用或者其他 HTTP 客户端也能够访问这些业务数据。一种直接思路是重新开发一套 SAP Gateway OData Service，把 Entity Type、Entity Set、Association、Navigation Property、Query、Create、Update、Delete 等逻辑全部重新实现。但对于已经由 GenIL 建模的业务对象，这样做往往重复了大量已有工作。SAP Gateway 为此提供了一个很有代表性的 Integration Scenario，也就是把现有 GenIL 模型重新定义为 Gateway OData Service。SAP 官方对这种集成方式的定位很明确，GenIL 与 SAP Gateway 的集成可以把已有业务数据快速暴露成 OData Service，而 SAP Gateway Service Builder 中的Redefine service开发方式，本来就是为 SPI、BW Query、GenIL 等既有框架准备的复用机制。理解这套机制时，我更愿意把它看成一个模型适配器，而不是一个普通的代码生成器。在 SAP CRM 的经典 WebClient UI 架构里，Business Object Layer，也就是 BOL，负责向上
