在调试一个SAP Gateway Foundation的OData V4服务时，有一种调用栈很容易让人产生疑惑。浏览器或者REST Client发出的明明只是这样一条普通的导航请求GET`…/iwbep/tea/default/iwbep/tea_busi/0001/EMPLOYEES('1')/EMPLOYEE_2_EQUIPMENTS`从 URL 表面看，我们只是从编号为1的Employee出发，沿着EMPLOYEE_2_EQUIPMENTS这个Navigation Property读取设备集合。按照比较直观的思路，我们可能会预期断点直接停在READ_ENTITY_LIST，因为客户端最终确实需要得到一个实体列表。实际调试SAP Gateway OData V4时，却可能先进入一个名字很长的方法/IWBEP/IF_V4_DP_BASIC~READ_REF_TARGET_KEY_DATA_LIST这个方法并不直接承担完整业务实体列表的读取工作。它关注的是另一件更基础的事情 从导航关系到目标键集合，深入理解 /IWBEP/IF_V4_DP_BASIC~READ_REF_TARGET_KEY_DATA_LIST 的运行机制
在调试一个SAP Gateway Foundation的OData V4服务时，有一种调用栈很容易让人产生疑惑。浏览器或者REST Client发出的明明只是这样一条普通的导航请求GET`…/iwbep/tea/default/iwbep/tea_busi/0001/EMPLOYEES('1')/EMPLOYEE_2_EQUIPMENTS`从 URL 表面看，我们只是从编号为1的Employee出发，沿着EMPLOYEE_2_EQUIPMENTS这个Navigation Property读取设备集合。按照比较直观的思路，我们可能会预期断点直接停在READ_ENTITY_LIST，因为客户端最终确实需要得到一个实体列表。实际调试SAP Gateway OData V4时，却可能先进入一个名字很长的方法/IWBEP/IF_V4_DP_BASIC~READ_REF_TARGET_KEY_DATA_LIST这个方法并不直接承担完整业务实体列表的读取工作。它关注的是另一件更基础的事情