在一个已经通过 SAP Gateway 暴露出来的 GenIL 服务里，最容易让开发人员产生错觉的地方，并不是 OData 的 Entity、EntitySet，也不是$filter本身，而是后台究竟拿哪一个 GenIL Query 去执行这次查询。
从 OData 消费端观察，一次请求可能只是访问某个 EntitySet，再附带几个过滤条件。可进入 SAP Gateway 后端之后，事情并没有停留在 EntitySet 这一层。Gateway 还需要知道，这个 OData Entity 对应哪个 GenIL Object，这个 Object 能不能直接查询，它关联了哪些 Query Object，其中哪一个 Query 应当承担当前请求。
SAP 为 GenIL 与 SAP Gateway 提供的集成框架，会让生成出来的 Model Provider Class 在运行时通过 GenIL API 获取模型信息，而不是单纯把全部模型关系静态写死在 MPC 代码里。SAP 官方文档同时给出了一个很关键的扩展入口，当一个 Root Object 或 Access Object 对应多个 Query，或者设计时自动确定的默认 Query 不符合实际业务需求时，可以增强生成的 Model Provider Class，并调整/IWGIL/IF_GENIL_MODEL_INFO~GET_DEFAULT_QUERY。
这段看起来很短的说明，实际上触及了 SAP Gateway 与 GenIL 集成里一个非常核心的问题，也就是 OData 查询语义怎样被路由到正确的 GenIL 查询模型。
