Skip to Content
Technical Articles

Understanding of the OData service in CPI in implementing looping process

Hello everyone, hope everyone is doing well and staying safe and healthy. For the past few months, I am working on an S4 greenfield implementation. In this project, the middleware that I had suggested was SAP cloud platform integration services aka CPI.

During the realization stage of integration scenarios, I was working on a particular scenario in which I had to use an OData service that was exposed from CDS view in S4 HANA to integrate to Salesforce and some 3 rd. party tools. Initially, I taught that it was a straightforward solution until I hit a roadblock which just halted my development. In this blog, I will provide you my understanding of OData service behavior that may be useful in developing complex i-flow using CPI.

The first thing to consider, when using the OData service exposed from an S4 On-Premise system is that there is always a possibility that a Fiori app is been used to trigger the process. When we have a Fiori app in the S4 system being used then SAML2 single sign-on (SSO) will be enabled. When you try to perform a GET query using an OData adapter then it may end up in processing status for multiple days. This means in the backend CPI is unable to bypass the SAML2 and executive your query.

Note: As a default step we all use POSTMAN client big time to get the initial testing of the APIs before implementing the same in CPI. I also did the same, but the POSTMAN client will resolve SAML2 automatically and get you the data. After some investigation, I understood that SAML2 was a culprit. The CUSTOM query in OData adapter came in handy using which I could configure the SAML2 = disable and then could fetch the query. Please see the screenshot below for configuration details.

Now, let’s talk about the second issue which halted my integration development. The above fix worked when there were a certain set of records in the table. I was able to retrieve around 3k records in a single FETCH. Initially, I taught the problem was fixed and so I had asked my team to load more data to test FETCH, it broke the integration and went into the status processing. Behind the scenes, it had impacted the CPI Node which was not allowing other i-flows to work.

I reached to SAP to get this investigation underway. Initially as usual they requested access to look into the issue and they said that it is a node issue so need a restart, but the bigger problem was to resolve the FETCH issue. Here is the SAP note if you get the i-flow in message processing status and need a node restart.

https://launchpad.support.sap.com/#/notes/0002399949

I knew that the looping concept would work for a large set of data but wanted to understand how and when to adapt the looping process. I just did not want to use looping processing blind-sided without knowing when to use. I worked with SAP for around 4 weeks to get the answer and finally found one issue from my investigation and reported the same to SAP which was a nextLink when a FETCH is done using postman as shown in the screenshot below.

This was the second culprit which was blocking the integration to FETCH the data. The issue here is that the OData service is returning the records with the next link in the response as below. In CPI, it needs to be looped on the next link until all records are fetched. This behavior cannot be changed since CPI adheres to the OData specifications.

<feed ……

…….

<link rel=”next” href=”ProductPrices?sap-client=900&amp;$skiptoken=100″/>
</feed>

As per the OData spec, the next link indicates that there are more records in the server and hence we use this link to fetch the remaining records.

In this service First call returns 89 records and nextlink <link rel=”next” href=”PP?sap-client=900&amp;$skiptoken=100″>

The nextLink response is empty feed with nextlink = PP

?sap-client=900&amp;$skiptoken=200

This next call gives empty feed with nextlink = PP?sap-client=900&amp;$skiptoken=300

The above call gives empty feed with PP?sap-client=900&amp;$skiptoken=400 and so on.

The response of the next link gives an empty feed with another next link indicating more records. and this goes on infinitely. So, whenever you test the API endpoint look for nextLink in your FETCH. If so, you can make a call to go to the looping process. As of now, we have a dependency on a POSTMAN client. I hope SAP will update the OData adapter to provide more information to the developer so that a correct decision can be made in developing the scenario. The reason I put out this blog is that I could not find any answer on the community for my posted questions. So, taught it would be helpful.

Hope this helps.

Happy Blogging.

12 Comments
You must be Logged on to comment or reply to a post.
  • Hi Hari,

    Thank you so much for sharing your experience and the knowledge, very helpful.

    Is your issue resolved now? how did you manage to do the looping in CPI?

     

    Regards,

    Srinivas

    • Srinivas-

      Yes. I have resolved the issue. You can follow the below blog for achieving the looping process. If any specific questions. Please let me know.

       

      https://blogs.sap.com/2017/08/22/handling-large-data-with-sap-cloud-platform-integration-odata-v2-adapter/

      Regards

       

      HS

       

  • Hi Hari ,

    I hope you are doing well .

     

    I wanted to know if you could help me in finding the best practice of using an OData from ECC System *(  where I get the information from a custom table ) inside an iFlow in CPI ?

    Best regards

    Arnold

     

    • Hi Arnold,

      What exactly are you looking for, w.r.t to OData? Please provide me some more information so that I can assist you better.

       

      Thanks

       

      HS

      • Hi Hari

        Thnx for the reponse.

        So the big picture is :

        1. Create connection On-premise <--> CPI
        2. Create an ABAP Proxy for sending some data to CPI
        3. Build an iFlow to send a csv file to the client
        4. Use the data from Proxy for wrintnf to csv file that will be send
        5. Use OData inside the iFlow to filter some records in the csv file before sending to a specific client

        That is how I have imagined the project flow, maybe something is not right, I am not sure 100 %.

         

        So for the reason I am a begginer in PO/PI, I feel a little confused for the points above and it would be very kind if you could help me a little with the topics .

        Thank you very much !

        Arnold

        • Please find my comments below. I think you find many blogs for your below-mentioned scenarios. This is straight forward one.

          1. Create connection On-premise <--> CPI
            • You can use SAP Cloud Connector to create a connection between the above-mentioned systems.
          2. Create an ABAP Proxy for sending some data to CPI
            • You create an ABAP proxy and expose it as a web service and use the same in CPI and use a SOAP adapter to get the data. You can use the SOA manager to bind the CPI endpoint and proxy.
          3. Build an iFlow to send a CSV file to the client
            • You can use CPI to get the data from ECC (assuming) using SOAP and SFTP to create the file. Now FTPS is also available as an adapter.
          4. Use the data from Proxy for writing to CSV file that will be send
            •  You can use XML to CSV converter to convert the XML to CSV format. For which you need to get XSD created using XML data. Many online XML to XSD converter tools are available.
          5. Use OData inside the iFlow to filter some records in the CSV file before sending them to a specific client
            • No need for OData, you can use Filter in CPI to filter out the data. OData is primary used to extract entity list that is exposed in Target or Sorce system.
          • Thank you very much Hari !

            The idea of using OData in iFlow is that the information for filtering is found in ECC System in a custom table .

             

            Best regards !

            Arnold

  • Hello Hari Sonnenahalli I hope you are well .

     

    I would like to explain my situation with the WSDL from ERP side and iFlow in CPI *( which i want to create now ) and i would like a little help from your side if you can.

    So i have created in ERP system :

    • Service Definition from a RFC Function Module
    • Service Consumer from the WSDL URL of the service definition
    • Simple report that triggers the service consumer using the method from it's class

    Now in the Connection Tab of SOAP Adapter, how do I implement the WSDL thing to be able to receive the data i send from ERP ?

    Previewing temp_image_20210413_123915_147c1943-b98f-4bce-9a92-5d4748d2ea76.jpg

    Thank you !!

    /
    Previewing temp_image_20210413_123915_147c1943-b98f-4bce-9a92-5d4748d2ea76.jpg
  • You need to expose the WSDL as a web service and then consume it in SOAP. You need to make sure the connection between CPI and ERP is established. Please check the below the blog.

     

    https://blogs.sap.com/2020/02/24/sap-cloud-connector-how-to-connect-an-abap-system-with-sap-cloud-platform/

     

    Regards

     

    HS