Search code examples
sap-cloud-sdk

Guidance Required - Approach to consume ODATA Service


We understand that these are the options available from SDK to connect to ODATA Service

Option 1 - If the ODATA Service is not supported implicitly by SDK, Use com.sap.cloud.sdk.odatav2.connectivity.1.ODataCreateRequestBuilder

Option 2 - If the ODATA Service is not supported implicitly by SDK, Use VDM generation approach. Call the services using generated Java classes

Option 3 - If the ODATA Service is supported implicitly by SDK, Use the already available class e.g. 2> com.sap.cloud.sdk.s4hana.datamodel.odata.services.OutboundDeliveryService

Now we have have some questions and need expert guidance here

Question 1 - We have a use case where we need to call oDATA Services from a third party system which option we should go for Option 1 or Option 2 ?

Question 2 - What are these cases where Option 1 is preferred over Option 2?

Question 3 - We also have a use case where we need to call S4HANA ODATA service related to OutboundDelivery. Service is supported by SDK by class com.sap.cloud.sdk.s4hana.datamodel.odata.services.OutboundDeliveryService But there is one new field is getting added to the service during current release. We need to update this field In this case which option is suggested?

Question 4 - How frequently new fields on existing S4HANA odata services are included in SDK?


Solution

  • I hope I can enlighten you a little here:

    Regarding 1: Personally, I'd still recommend going with option 2 and generate client code using our generator. This will give you the same convenience that you know from the S/4 services for any other OData service. If, for some reason, the generated code does not work against your third party service, you can still use option 1 as a fallback. Generally speaking, our generator should work for any OData v2 service, not just SAP services.

    Regarding 2: As already mentioned, the generic OData client always works well as a fallback, if the generated client does not work whatever reason. The other case I can think of (and this should be rather rare), is that you yourself are exposing one service that retrieves it data from several downstream OData services. In this case, the generic client might give you some advantages over the generated one. Apart from that, I'm not aware of any use cases where I'd personally go with the generic client over the generated one.

    Regarding 3 and 4: The VDM packages that we ship as part of the SAP Cloud SDK contain the OData client code for the current release of SAP S/4HANA Cloud. So if the services in SAP S/4HANA Cloud are updated, our packages will reflect that update. If you're working with SAP S/4HANA On-Premise, there's generally a good chance that the service is compatible with the Cloud version. If not, you can still use our generator to generate client code with the metadata of the respective On-Premise service.