OData Service Project vs Integration Project when to use what in Cloud Platform Integration

With the July 2017 release of Cloud Platform Integration the OData Service project which is in Beta is made generally available. See the blog on usage of OData Provisioning via OData Service project here.

In this blog I try to explain when to use an OData Service and when to use Integration project .

Scenario 1

You have a system that sends payload in OData ATOM/JSON format and you would like to transfer this to a receiver system in a different format other than that received example XML.

In this above case you may use an Integration project with OData Sender channel.

The OData Sender channel converts the incoming message in OData ATOM/JSON format to XML internally. The payload that is available to you in the Cloud Integration pipeline is XML.

Scenario 2

You have a system that sends payload in OData ATOM/JSON format and you would like to transfer this to a receiver system in ATOM/JSON format only.

In this above case, you may use an Integration project with an HTTP Sender channel. This way you may avoid conversion of ATOM/JSON to XML format in the Sender channel.

Scenario 3

You are building a frontend application and would like to create an OData Service based on a SOAP or REST or another OData service.

In this case you would like to create an OData Service with Several EntitySets and operations. With an OData Sender channel in an Integration project you would be able to expose only one EntitySet and Operation combination but with an OData Service project you would be able to use the Binding Editor and have several Integration flows each for every EntitySet and Operation. On deployment the entire project is deployed as one service.

Scenario 4

You would like to enrich an existing OData Service implementation that was created using the IW_BEP component on an SAP ERP backend

In this case you would create an OData Service and use the ODC (OData Channel) as Receiver channel to map the existing EntitySets and operations available in your backend to the new service you are developing in Cloud Integration.

For differences between SAP Cloud Platform OData Provisioning and OData Provisioning available in Cloud Platform Integration see here

Busting some myths

1. If I use OData Service project I have to do no code
   • Cloud Integration provides you a modelling environment that allows you to create an OData Service based on an existing Data Source. The modelling capability is limited to the pipeline features of Cloud Integration. Any complex OData service requirements like navigation or deep insert would have to be implemented via coding using the script step as simply there is no means of representing and expressing this relationship to the backend data source.
2. I can only provision a service using OData or SOAP as backend
   • In the OData Service project you will be able to create a service definition automatically based on a SOAP wsdl or an existing edmx. This does not restrict you in any way and you can still go ahead and enhance or create the edmx manually.
   • There are primarily two activities in OData Service development. Service definition (creating and defining edmx) and Service implementation (connecting to the backend data source).
   • The OData service project provides you with template implementations when connecting to SOAP, OData or REST backend. This does not mean you cannot connect to other data sources. This only indicates that you will have to use one of these available templates in the Binding Editor and then modify the Receiver channel and iflow in case you would like to use another data source.