在 SAP Gateway 项目里调试一个GET_ENTITY或GET_ENTITYSET请求时，经常会出现一种很有意思的现象。浏览器或者 SAP Fiori 前端明明又发起了一次GET请求，后端也收到了请求，可是在 HTTP Response 中并没有重新返回完整的 JSON 数据，而是只看到一个304 Not Modified。从 HTTP 网络传输角度看，这次请求几乎什么业务数据都没有传。但从客户端角度看，页面上的数据依旧能够正常显示。这里并不是 SAP Gateway 偷懒，也不是请求被某个神秘缓存直接吃掉了，而是标准 HTTP Conditional Request，也就是条件请求机制正在工作。而在经典 SAP Gateway Foundation 编程模型中，与这套机制关系非常密切的一个接口，就是/IWBEP/IF_MGW_CONV_SRV_RUNTIME其中又有一个很容易被忽略，却相当实用的方法CHECK_IF_IS_NOT_MODIFIEDSAP 官方把/IWBEP/IF_MGW_CONV_SRV_RUNTIME定义为一个由 Gateway Framework 提供便利方法的接口。除了本文重点讨论的CHECK_IF_IS_NOT_MODIFIED，接口中还提供COPY_DATA_TO_REF、SET_HEADER、
深入理解 SAP Gateway 的 /IWBEP/IF_MGW_CONV_SRV_RUNTIME，为什么一个时间戳比较就能省掉整次 OData 数据传输
在 SAP Gateway 项目里调试一个GET_ENTITY或GET_ENTITYSET请求时，经常会出现一种很有意思的现象。浏览器或者 SAP Fiori 前端明明又发起了一次GET请求，后端也收到了请求，可是在 HTTP Response 中并没有重新返回完整的 JSON 数据，而是只看到一个304 Not Modified。从 HTTP 网络传输角度看，这次请求几乎什么业务数据都没有传。但从客户端角度看，页面上的数据依旧能够正常显示。这里并不是 SAP Gateway 偷懒，也不是请求被某个神秘缓存直接吃掉了，而是标准 HTTP Conditional Request，也就是条件请求机制正在工作。而在经典 SAP Gateway Foundation 编程模型中，与这套机制关系非常密切的一个接口，就是/IWBEP/IF_MGW_CONV_SRV_RUNTIME其中又有一个很容易被忽略，却相当实用的方法CHECK_IF_IS_NOT_MODIFIEDSAP 官方把/IWBEP/IF_MGW_CONV_SRV_RUNTIME定义为一个由 Gateway Framework 提供便利方法的接口。除了本文重点讨论的CHECK_IF_IS_NOT_MODIFIED，接口中还提供COPY_DATA_TO_REF、SET_HEADER、