In many integration scenarios, your sender communicates over HTTP and expects a synchronous response within a strict timeout window. Meanwhile, your integration flow may involve asynchronous processing that takes significantly longer.

Recently our integration partner expressed a concern that their timeout cannot exceed 3 seconds, but processing at our side took over a minute. In such case you have a few options how to decouple the integration flow, respond to your sender and continue processing the request:

• JMS queue

• Event-based platform

• SOAP adapter

• DataStore

JMS queue

Recommended and most common option

• Use case: Ideal when you want to immediately acknowledge the HTTP request and process it asynchronously

• How it helps: You can push the message to a JMS queue quickly, send an HTTP 200/202 response back to the sender within their timeout, and continue processing in a separate flow that consumes from the queue

• Benefits: Reliable, durable, retry mechanisms, and native to CPI

• Limitation: Certain number of JMS queues. Especially if you have AS2 integration partners, you can quickly run out of your available JMS queues

Event-Based Platform

Stand-alone software products like SAP Event Mesh or Kafka

• Use case: When you're operating in an event-driven architecture and want to loosely couple components

• How it helps: You can publish an event to a broker, respond quickly to the sender, and let a separate consumer handle the processing

• Benefits: Scales well, decouples systems further, fits microservice/event-driven design

• Limitation: May be a little of overkill for a single-use scenario, complex setup and requires integration with Event Mesh or external brokers

SOAP adapter

You create a small helper iflow with HTTP Sender, where you just provide answer to the Sender and call your processing iflow via SOAP adapter.

This approach requires modifying the sender configuration of your processing iFlow to accept SOAP requests. You’ll also need to configure the SOAP adapter to allow asynchronous behavior.

This settings ensures that the caller receives immediate response and processing continues further in more of an asynchronous way. 

• Use case: Simple calls, where we can easily transform the HTTP call into a SOAP call. That also requires converting any incoming payload into XML

• How it helps: SOAP can work in both sync and async behavior, based on the SOAP Sender adapter setting 

• Benefits: Quick-win solution for simple calls, doesn't require queues, persistence or dedicated software

• Limitation: Large payloads in non-XML format will be complicated to handle

DataStore

A fall-back option, not really recommended, but still usable if above options are not for you

• Use case: When you don't have access to JMS queues or Event Mesh, and you're dealing with low-to-medium volume messages that can tolerate delayed, batch-style processing.
  
  

• How it helps: You persist the incoming message to the CPI Datastore, respond immediately to the HTTP sender (e.g., with HTTP 202 Accepted), and then use a separate, scheduled iFlow to retrieve the message from the Datastore and continue processing asynchronously.
  
  

• Benefits: Provides basic persistence and decoupling, useful for non-critical or internal scenarios.
  
  

• Limitation: No built-in retry mechanism, requires manual polling logic via scheduler, not suited for high-throughput or time-sensitive processing.

As we can see, all above solutions have their pros and cons. Ideally, the best option would be to achieve this at the HTTP adapter itself. Nevertheless, HTTP adapter is synchronous by design and there is no configuration which could change this.

We also explored workarounds such as routing the HTTP request through a parallel or sequential multicast before forwarding it to the processing iFlow. However, this approach did not reliably solve the issue.

I will be grateful for any tip or insight on this topic, solving the issue with HTTP adapter or in any other way.

It was also published here:

https://community.sap.com/t5/technology-blog-posts-by-members/decoupling-strategies-for-http-based-integrations-in-sap-cloud-integration/ba-p/14167141