When Synchronous OData Failed for bulk data processing: How I Solved Problem Using OData V4 Async :

[pavanKolla]

The Business Context:

• BlueYonder sends planning and operational data
• The data volume is large
• Data needs to be posted into SAP S/4HANA Public Cloud
• SAP exposes this functionality via OData V2 and V4 APIs

The expectation was simple: “Send data from BlueYonder and create/update records in S/4HANA.” But in reality, it was not that easy.

Introduction:

In real projects, integrations look simple on paper but behave very differently in production.

This blog is about a real-time problem I faced while integrating BlueYonder planning data into SAP S/4HANA Public Cloud using OData V2 Inbound.

The solution was understanding how OData V4 async processing works and using one small but powerful HTTP header.

In this blog, I will explain:

• What problem I faced
• Why synchronous processing failed
• How I implemented async OData V4 processing with API proxy(through URL).
• What changed after enabling async

The Actual Problem

Initially, I implemented the integration in a synchronous way.

What Happened

• CPI sent data to S/4HANA public cloud using standard OData V2 synchronous Api
• The backend took time to process the payload
• CPI waited for the response
• Requests started failing due to:
• Timeouts
• Long-running backend processing
• Unstable behaviour during peak loads

The Key Issue

OData V2 APIs are synchronous by default. This means:

• CPI waits until S/4HANA public cloud finishes posting
• Large payloads increase risk
• One slow request can block the entire flow This was not acceptable for a production-grade integration.
• Chunking the payload using General splitter and streaming could increase the number of API Calls and may increase the load on Public cloud.

Design:

While analysing SAP documentation, I came across the asynchronous processing capability of OData V4. SAP provides a standard way to tell the backend: “Accept the request, process it in the background, and do not keep the connection open.”
This is done using the HTTP header: Prefer = respond-async

Step-by-Step Implementation :

Step 1: Receiving HighRadiusData in CPI

• BlueYonder sends data in Flatten File.
• CPI receives the data and prepares it for S/4HANA public cloud.

Data structure is aligned to OData V4 expectations At this point, the flow is still normal.

• *Here I had implemented the Retry mechanism using JMS Queues which is the best practice for the SAP integrations ,If you like you implement it do check out my previous Blog that I had posted in the SAP Community.
  Blog URL – {https://community.sap.com/t5/technology-blog-posts-by-members/handling-connectivity-and-recoverable-...}

Step 2: Setting the Async Header (Most Important Step)

In CPI, I used a Content Modifier to add HTTP headers.

Header : Prefer Header Prefer = respond-async This header completely changes how the request is handled.

What Happens After Adding respond-async

Once this header is added:

• CPI sends the request
• S/4HANA immediately responds with HTTP 202 – Accepted
• Backend processing continues asynchronously
• CPI does not wait for the final processing result This single header removed timeout risks completely.

Step 3: Posting Data via API Proxy

* Here, I had used OAuth 2.0 Authentication between Integration suite to API Proxy and between API Proxy and S/4 Hana public cloud I had used Certificate Based Authentication.

• CPI sends the request to an API Proxy
• The proxy forwards the call to the OData V4 API from SAP Business Accelerator Hub
• The proxy is created using the URL-based option

Note : OData V4 services do not appear in the API Provider’s service catalog in SAP API Management, so discovery isn’t possible — and that’s why I go with the URL method, so if you want to create proxy for OData V4 public cloud the correct approach is just go with the URL Option don’t fall for this pitfall.

If you want to leverage more on how to create API Proxy with URL option follow SAP Official Documentation.
Official documentation: {https://help.sap.com/docs/sap-api-management/sap-api-management/create-api-proxy-by-providing-direct...}

From CPI’s perspective:

• The request is completed successfully

No long-running connection is maintained

• 

  What Changed After This Implementation

  Before Async

  • Timeouts during high data volume
  • Unstable integration behaviour
  • Risk of message failures

  After Async

  • Immediate response to CPI
  • Backend processing happens safely
  • No timeout issues
  • Integration became stable and predictable

  This was a real production-grade improvement, not just a theoretical change, I hope this helps you folks that don’t fall for this pitfall in your production.