共计 1334 个字符，预计需要花费 4 分钟才能阅读完成。
SAP Gateway Foundation 缓存服务的元数据信息以显着进步性能。SAP 提供了三种类型的缓存：
- 在 hub 上缓存。
在 Hub 零碎上缓存了元数据模型、正文模型以及服务的正文文本。
- 在后端缓存。
在后端仅缓存元数据模型和正文模型。后端不须要正文文原本进行服务实例化，因而不会在此处缓存。
- co-deployment 场景。
共部署场景是指 hub 和 backend 是一个零碎。因而，缓存只需为 hub 和每个后端系统执行一次。
SAP 举荐在开发零碎上不关上缓存 cache：
在 OData 通道编程范例中，蕴含最初批改工夫戳的模型提供程序类仅在最后加载元数据并将其存储在 SAP Gateway Foundation 元数据缓存中时调用一次。如果之后更改了模型提供者类（例如，因为编码更改或因为导入更改后的模型提供者类），元数据缓存会为每个服务文档或服务元数据文档申请执行一次握手，并查看缓存是否蕴含最新的元数据。如果元数据已过期，则会主动触发缓存刷新。
SAP Gateway 元数据组件容许齐全缓存元数据，从而显着进步通过 SAP Gateway 发送的申请的性能。
存在三种不同的拜访场景：
- 须要满足对 OData 服务文档或 OData 服务元数据文档的申请。
- SAP Gateway 运行时自身须要拜访元数据能力解决申请。
- IW_BEP 软件组件须要拜访元数据能力解决申请。
SAP Gateway 通过提供三级缓存策略为所有这些场景提供性能。
Access Scenario 1 – Web Infrastructure Cache
在这种状况下，存在获取服务文档或服务元数据文档的消费者申请。这意味着对资源的申请在生产环境中很少扭转。
为了应用 HTTP 规范技术，SAP Gateway OData Channel 依据 HTTP 缓存规范（Last-Modified）设置服务（元数据）文档的 HTTP 响应标头。如果之前曾经申请过资源，则此参数使 Web 根底结构组件（例如，Web 服务器和浏览器）可能满足其缓存之外的申请。
特定于应用程序的模型提供程序类能够通过实现办法 GET_LAST_MODIFIED 影响此工夫戳。此办法的默认实现依据模型提供程序类 (MPC) 的更改工夫戳派生最初批改的工夫戳。如果不适合，应用程序能够笼罩逻辑。
Access Scenario 2 – SAP Gateway Metadata Cache
如果无奈通过 Web 基础架构缓存满足申请，或者 SAP Gateway 运行时自身须要拜访元数据，例如读取提要，则会查看以后服务的元数据是否已存在于 SAP Gateway 元数据中 缓存（如果启用）。
如果存在，则间接从缓存中检索数据。另一方面，如果它不存在，则从相应的数据源读取数据并传回。数据源的一个示例是模型提供程序类或 SAP Gateway 元数据持久性，存储在 SAP Gateway 元数据缓存中以服务来自它的后续申请。
Access Scenario 3- IW_BEP Metadata Cache
IW_BEP 上的缓存无奈禁用，须要正确实现模型提供程序类办法能力检索最初批改的工夫戳。
如果模型提供者类未更改，但底层 ABAP 字典绑定（例如 ABAP 构造中字段类型的定义），则更改不会间接反映进去，因为没有 ABAP 字典更改的挂钩。在这种状况下，须要手动革除 IW_BEP 上的元数据缓存。
