Summary

The integration solution is designed to solve a coordination and rate limit management problem between Ariba API and Keelvar APIs used in Sourcing Processes. 

During the implementation of Interfaces (see below) that require orchestration of the APIs between the two systems, it was discovered that strictly imposed rate limits in Ariba APIs mainly, but also Keelvar Intake and Export APIs, are reached, causing Integrations to fail.

To address this, an Integration Orchestration Solution is introduced using available tools in SAP CPI.  The major aspects of the solution are:

1. Use of JMS Queues, where required, shared by Interfaces utilising the mentioned APIs
2. Use of singleton processing via a Router IFlows  that sequentially and synchronously process messages from each JMS Queue
3. Use of dedicated "Connectors" to Ariba and Keelvar APIs that are rate-limit aware and pause if limits are reached.

Overall, this solution provides a robust, controlled, and extensible foundation for managing multiple API-based integrations between Ariba and Keelvar, ensuring operational stability and compliance with API usage policies in Ariba and Keelvar. Furthermore, this solution can be extended if and when further Integrations need to be implemented that utilise Ariba and Keelvar APIs, in addition to the 4 interfaces that currently ( as of 09-April-2026 ) utilise this:

Description

Ariba APIs contain both intake and export endpoints supporting Ariba Strategic Sourcing Platform to read, create and update Sourcing events, Scenarios, Awards and Suppliers.

Three Ariba APIs are part of this solution - Event Management API, Master Data Retrieval API for Sourcing, and Surrogate Bidding API. There is no documented rate limit for Surrogate Bidding API however, Event Management API and Master Data Retrieval API for Sourcing requests are rate-limit controlled as shown below:

• Event Management API: Enables Sourcing synchronisation with Keelvar

  Time limits	Number of Requests
  Per second	5
  Per minute	80
  Per Hour	3500

• Master Data Retrieval API for Sourcing: Enables Supplier Data synchronisation with Keelvar

  Time limits	Number of Requests
  Per second	10
  Per minute	40
  Per Hour	200
  Per Day	1000

Three Keelvar APIs are also used in these integration, each with its own rate-limits:

• Intake APIs: Enables Sourcing Event read, creation and update in Keelvar. In addition, APIs also contain services to check the Event Processing background job status. 
  

  API	Burst	Sustained
  Sourcing Events	120 per hour	500 per day
  Process Job Status	30 per minute	600 per hour

• Export APIs: Enables reading of Sourcing Events, Bids and Awards.
  

  API	Burst	Sustained
  Awards	60 per minute	43,200 per day
  Bids	60 per minute	43,200 per day
  Events	60 per minute	43,200 per day

• Supplier Management APIs
  

  API	Burst	Sustained
  Suppliers	30 per minute	600 an hour
  Supplier Changes ( Retrieve )	30 per minute	600 an hour
  Supplier Changes ( Update )	60 per hour	500 per day

To manage the constraint enforced by the rate-limits, this framework enables the orchestration of the APIs between the two systems, avoiding and recovering from rate-limiting exceptions as well as handling exceptions such as data errors, service unavailability etc.

The following guiding principles need to be applied in the IFlows pertaining to the Integration:

• All requests to APIs from IFlows will be via Request-Reply objects - this enables the ability to handle Exceptions by logging the response message bodies, return codes etc
• The Processing will be broken up into small Asynchronous sequential calls. This allows the integration to re-process only failed API calls and then, once successful, hand over to the next IFlow seamlessly
• The IFlows will be designed in such a way to reduce the number of API calls, ideally to contain only one API call for each system. Multiple APIs will orchestrate when strictly necessary, since this increases the chances of reaching the rate limit during processing of subsequent messages from the JMS Queue.
• The IFlows will be designed so that re-processing via the JMS Queue will not affect the outcome expected. 
• The IFlows will only use the Ariba and Keelvar Connector IFlows to access the APIs. This ensures that the API calls are sequential and each is completed before the next occurs
• The IFlows will handle and log the exceptions and raise a new exception to push it back to JMS Queue. This ensures that the Error notification is captured in CPI.
• The Sequence of the IFlows are via Process Direct direct endpoints to allow the Router to identify the Processing IFlow once it is pushed into JMS Queue

Solution Overview

Process Flow

Key Components of the JMS Solution

Technical Details

Invoker IFlow Configurations

IFlows that write entries into JMS Queues need to provide the following parameters

All IFlows that forwards the processing to JMS Queue should have the following configuration settings in the JMS Receiver Adapter

JMS Routers

Externalised Parameters

Sender Adapter JMS Configurations - Common to both JMS Routers

Receiver Adapter JMS Configuration - For Dead Letter Queue 

Provider IFlows Configuration Requirements

• Provider IFlows Sender ProcessDirect Adapter path must be defined as the header parameter jmsProcessDirectPath defined in the Invoker IFlow. 
• Header and Property definitions required for Ariba and Keelvar APIs must be defined as described below
• If the Provider IFlow injects any messages to the JMSQueue, then the parameters defined in the Invoker IFlow must also be defined 

Ariba Event Management API Connector IFlow

The Ariba Connector constructs the URL and the Authentication Parameters based on valued passed from the calling IFlow and configurable parameters in the Connector. The construct is shown below:

Ariba Event Management URL

Construction of the URL with an example:

An IFlow calling the Adapter must provide the following Header Parameters to construct the API endpoint to Ariba

Additional Parameters

Ariba Surrogate Bidding API Connector IFlow

Similar to Event Management API Connector, the Ariba Surrogate Bidding AI Connector also constructs the URL and the Authentication Parameters based on valued passed from the calling IFlow and configurable parameters in the Connector. The construct is shown below:

Ariba Surrogate Bidding URL

Construction of the URL with an example:

An IFlow calling the Adapter must provide the following Header Parameters to construct the API endpoint to Ariba

Additional Parameters

Ariba Master Data API Connector IFlow

Similar to Event Management API Connector, the Ariba Master Data API Connector also constructs the URL and the Authentication Parameters based on valued passed from the calling IFlow and configurable parameters in the Connector. The construct is shown below:

Ariba Master Data API for Sourcing URL

Construction of the URL with an example:

An IFlow calling the Adapter must provide the following Header Parameters to construct the API endpoint to Ariba

Additional Parameters

Keelvar Event API Connector IFlow

Keelvar URL

Similarly, the Keelvar Connector constructs the URL based on the values passed from the calling IFlow and configurable parameters in the Connector. 

An IFlow calling the Keelvar Connector must providefollowing Header Parameters to construct the API endpoint to Keelvar

Additional Parameters

Keelvar Supplier API Connector IFlow

Keelvar URL

Similarly, the Keelvar Connector constructs the URL based on the values passed from the calling IFlow and configurable parameters in the Connector. 

An IFlow calling the Keelvar Connector must provide the following Header Parameters to construct the API endpoint to Keelvar

Additional Parameters

Error Handling & Retry Strategy

Monitoring & Observability

Future Enhancements

Use API Header driven pause 

For the current solution, based on the number of calls and the schedule, the configurable pause time limit provides adequate support for re-processing of messages. However, if further integrations are added to the package, further design analysis may be required to control the length of the pause

Reprocessing from DLQ

At the moment, the DLQ is only used as a placeholder for any messages that have failed the number of retries configured. Currently, no retry from DLQ is enabled, and this solution may be enhanced to provide the ability to reprocess the messages in the DLQ back to the JMS Queue.

Change Log