Dynamic HTTP or Odata Adapter – SAP Cloud Integration – CI/CPI

In this blog, I aim to simplify the use of dynamic resources/querying in Odata or HTTP.

To make it clearer for you, let's imagine the following scenario:

You need to perform a GET request in Odata on the S4hana Public Cloud, S4hana Private Cloud, or S4hana On-Premise, and you want to use the query options in a very dynamic and simple way.

Examples of queries:

https://myXXXXXX-api.s4hana.cloud.sap/sap/opu/odata/sap/API_BUSINESS_PARTNER/A_BusinessPartner('17300002')

https://myXXXXXX-api.s4hana.cloud.sap/sap/opu/odata/sap/API_BUSINESS_PARTNER/A_BusinessPartner?$filter=BusinessPartnerGrouping eq 'BP03'

 

Many times, we want to call SAP Cloud Integration - CPI from a SAP or non-SAP system, passing these parameters. How can we make CPI accept this without giving an HTTP 404 error?

Read More: C_C4H460_21: SAP Sales and Service Cloud - Developer

This is what I will teach you step-by-step in this blog, using the Odata Adapter and HTTP Adapter.

Let's get to work!

Spoiler alert: the end of our journey

Step 1:

The first thing we will do is put an asterisk '*' in the Address field of our HTTP adapter.

Example: /testURL*

With this in the CPI monitor, we will have a URL like the one below:

https://9265fbe0trial.it-cpitrial05-rt.cfapps.us10-001.hana.ondemand.com/http/testURL*

Step 2:

Configure the Router component.

Here we are using a Header to check whether to execute oData or HTTP; this step is entirely optional. I did it this way for didactic purposes, to show that it is possible to use both the odata adapter and the HTTP adapter. In this blog, you will see the difference between the two.

Step 3:

Create a local Integration Process.

Step 4:

Inside the local Integration Process, we will create a router. In this Router, we will check a standard CPI Header. If CPI is called with the URL below, it fills the CamelHttpPath.

https://myXXXXXX-api.s4hana.cloud.sap/sap/opu/odata/sap/API_BUSINESS_PARTNER/A_BusinessPartner('17300002')

In this case, we are searching for a record by its key field. So we will use the READ route.

Step 5:

We will add a Request Reply in the iflow.

Step 6:

We will add the Odata adapter.

If you don't have an S4hana environment to use, you can use the Sandbox from SAP Business Accelerator Hub.

Link to API Business Partner: https://api.sap.com/api/API_BUSINESS_PARTNER/overview

In the Address field, you either put the address of your S4hana environment or the SAP Sandbox.

https://sandbox.api.sap.com/s4hanacloud/sap/opu/odata/sap/API_BUSINESS_PARTNER/A_BusinessPartner

You should create your credentials in CPI, whether they are Basic, Oauth2, or even API Key (the latter should be passed in the header as Authorization).

In the Processing tab, select Operation Detail as READ(GET).

In the Resource Path, add the entity plus the header that contains the key field data.

Example: A_BusinessPartner${header.CamelHttpPath}

Step 7:

Now we will practically repeat the step to create another Request Reply and odata adapter.

The only additional point is that we will add a Groovy script to check if the CamelHttpQuery header is empty. If it is empty, we will create a property called isEmptyHeader and set it to ‘true’; otherwise, it will be ‘false’.

import com.sap.gateway.ip.core.customdev.util.Message;

import java.util.HashMap;

    

def Message processData(Message message) {    

 //Headers

 def headers = message.getHeaders();

 def isEmptyHeader = headers.get("CamelHttpQuery") == null || 

 headers.get("CamelHttpQuery").toString().isEmpty()

 message.setProperty("isHeaderEmpty", isEmptyHeader)

return message;

}

 

the Router we check this property.

If it follows the empty route, then we will create this header with a blank value using the content modifier.

Notice that in the Connection tab, it is identical to the previous one.

In the Processing tab, add the standard CPI header CamelHttpQuery.

This header is filled automatically when we send a URL like the one below, which is done when we pass a FILTER

The oData part is now done. Now let’s see how it works with HTTP.

Step 8:

Now we will create the Local Integration Process to use with the HTTP adapter.

Here is a detail: it is necessary to copy a header to a property because we need to delete the value of this header.

In this Content Modifier, we are moving a header to a property.

In this Content Modifier, the CamelHttpPath header is being deleted. This step is mandatory; if not done, it will cause an error in the HTTP call. I recommend you test without deleting it to understand why we remove it.

Step 9:

Now we will add a Request Reply and use the HTTP adapter.

In the HTTP adapter, we will configure it as follows. It will be the address of your S4hana endpoint or Sandbox, as we saw earlier, plus the property we created in the Content Modifier.

https://myXXXXXX-api.s4hana.cloud.sap/sap/opu/odata/sap/API_BUSINESS_PARTNER/A_BusinessPartner${prop...

Change the Method to GET. 

Add the credentials to access the environment. If using an API Key, add the Authorization header.

Our development is now complete.

Now let's test using POSTMAN.

Test 1:

We will call the Odata adapter without passing any parameters or filters. In this case, we want the Odata to return all the records in the database.

Test 2:

Calling by passing the key field in the URL. In this case, it will follow the READ route.

Test 3:

In this test, the Filter is being tested in the URL.

With this, the iFlow went through the QUERY route.

Test 4:

In this test, we are testing the HTTP adapter without sending any filter or key. We expect the return to be all BP records from S4hana.

Test 5:

In this test, we will test the HTTP adapter by passing a Key in the URL to return only one record. The adapter should perform a "READ".

Important: In this test, the CamelHttpPath header is filled, which is why we delete it in the Content Modifier. The HTTP adapter uses it automatically if it exists. Test to form your own conclusions! 

Test 6:

We will test the HTTP adapter by passing a filter in the URL.