需要指导 - 使用 ODATA 服务的方法

Guidance Required - Approach to consume ODATA Service

我们了解到这些是 SDK 提供的用于连接到 ODATA 服务的选项

选项 1 - 如果 SDK 不隐式支持 ODATA 服务,请使用 com.sap.cloud.sdk.odatav2.connectivity.1.ODataCreateRequestBuilder

选项 2 - 如果 SDK 不隐式支持 ODATA 服务,请使用 VDM 生成方法。 使用生成的 Java classes

调用服务

选项 3 - 如果 SDK 隐式支持 ODATA 服务,请使用已经可用的 class 例如2> com.sap.cloud.sdk.s4hana.datamodel.odata.services.OutboundDeliveryService

这里有一些疑问,需要高手指点

问题 1 - 我们有一个用例,我们需要从第三方系统调用 oDATA 服务 对于选项 1 或选项 2,我们应该选择哪个选项?

问题 2 - 在哪些情况下选项 1 优于选项 2?

问题 3 - 我们还有一个用例,我们需要调用与 OutboundDelivery 相关的 S4HANA ODATA 服务。 class com.sap.cloud.sdk.s4hana.datamodel.odata.services.OutboundDeliveryService SDK 支持服务 但是在当前版本中有一个新字段被添加到服务中。我们需要更新这个字段 在这种情况下,建议使用哪个选项?

问题 4 - SDK 中包含现有 S4HANA odata 服务的新字段的频率如何?

希望在这里能给大家一点启发:

关于 1:就个人而言,我仍然建议使用选项 2 并使用我们的生成器生成客户端代码。这将为您提供与任何其他 OData 服务的 S/4 服务相同的便利。如果出于某种原因,生成的代码不能针对您的第三方服务工作,您仍然可以使用选项 1 作为后备。 一般来说,我们的生成器应该适用于任何 OData v2 服务,而不仅仅是 SAP 服务。

关于 2:如前所述,如果生成的客户端因任何原因无法工作,则通用 OData 客户端始终可以很好地作为后备。 我能想到的另一种情况(这种情况应该很少见)是,您自己公开了一项服务,该服务从多个下游 OData 服务中检索数据。在这种情况下,通用客户端可能会给您带来一些优于生成的客户端的优势。 除此之外,我不知道有任何用例我会亲自使用通用客户端而不是生成的客户端。

关于 3 和 4:我们作为 SAP Cloud SDK 的一部分提供的 VDM 包包含当前版本的 SAP S/4HANA Cloud 的 OData 客户端代码。因此,如果 SAP S/4HANA Cloud 中的服务更新,我们的包将反映该更新。如果您使用的是 SAP S/4HANA On-Premise,通常该服务很可能与云版本兼容。如果没有,您仍然可以使用我们的生成器生成带有相应本地服务元数据的客户端代码。