| ID | NFR-2007 |
|---|---|
| Name | Ariba Event Management Orchestration Framework |
| Author | Kapila Epasinghe ( kapila.epasinghe-ext@syensqo.com ) |
| Approver | Sascha Wenninger ( sascha.wenninger-ext@syensqo.com ) |
Summary
The integration solution is designed to solve a coordination and rate limit management problem between Ariba Event Management API and Keelvar APIs .
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 Event Management 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:
- Use of a single JMS Queue shared by all Interfaces utilising the mentioned APIs
- Use of single Router IFlow that sequentially and synchronously processes messages in the JMS Queue
- Use of Connectors to Ariba and Keelvar APIs that are rate-limit aware and automatically 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. And 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 3 interfaces that currently ( as of 24-October-2025 ) utilise this:
| ID | Description |
|---|---|
| ERP-108 | Synchronisation of Sourcing Events created and updated in Ariba to Keelvar |
| ERP-137 | Synchronisation of Award Bids and Bid Sheets from Keelvar to Ariba |
| ERP-138 | Notification of Keelvar Event Status changes to Ariba |
Description
Ariba Event Management API contains both intake and export endpoints supporting Ariba Strategic Sourcing Platform to read, create and update Sourcing events, Scenarios and Awards. The Event Management API requests are rate-limit controlled as shown below:
| Time limits | Number of Requests |
|---|---|
| Per second | 5 |
| Per minute | 80 |
| Per Hour | 3500 |
Keelvar Intake and Export APIs are two different sets of API Services that are utilised with the JMS Queue solution, with separated rate-limits:
- Intake APIs: Enables Sourcing Event read, creation and update in Keelvar. In addition, APIs also contains 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
In addition, Keelvar provides a Webhook management API which is utilised in the Event Management Orchestration between Ariba and Keelvar. However, this set of APIs do not have a published Rate-Limit controls and described in a separate document here.
To manage this constraint, the solution described in this document provides a framework to orchestrate the APIs to enable Integration implementations that can avoid or recover from rate-limiting exceptions as well as well as to handle exceptions such as data errors, service unavailability etc.
When using this solution, 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 enable the ability to handle Exceptions by logging the response message bodies, return codes etc
- The Processing will be broken up in to small Asynchronous sequential calls. This allows the processing 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 to the same system increases the chances of rate-limit failures.
- The IFlows will be designed so that re-processing via the JMS Queue will not effect the processing that was done in the failed execution.
- 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 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
| Step | Function |
|---|---|
| 1 | Invoker IFlow initiates the processing. Ideally, this IFlow will not contain any calls to Ariba or Keelvar APIs. |
| 2 | After defining the parameters (headers) necessary for processing at Provider IFlow, including the ProcessDirect Path of the Provider IFlow, the message is passed to the JMS Queue |
| 3 | The Router reads the message from the JMS Queue and routes the message directly to the ProcessDirect Path of the Provider IFlow, defined in the message |
| 4 | The Provider IFlow will execute any API calls to Ariba and Keelvar. If needed The Provider IFlow can invoke further JMS Entries |
Key Components of the JMS Solution
| Component | Description |
|---|---|
| JMS Queue | Central JMS Queue |
| Router IFlow | The only IFlow that directly reads from the JMS Queue. This is single threaded, controlled via standard JMS Sender Configuration. |
| Ariba Event Management API Connector | Handles all API requets to Ariba Event Management API. Errors are logged but also returned to the calling IFlow. |
| Keelvar API Connector | Handles all API requests to Keelvar Intake and Export APIs. Errors are logged but also returned to the calling IFlow |
Technical Details
Invoker IFlow Configuration Requirements
JMS Queue
| Property | Value / Description |
|---|---|
| Queue Type | Standard |
| Concurrent Consumers | 1 (single-threaded) |
| Retry Count | Configurable (e.g., 5 attempts) |
| Dead Letter Queue | Enabled |
| Visibility Timeout | Based on processing time |
JMS Router
Provider IFlows Configuration Requirements
Ariba Event Management API Connector IFlow
Keelvar API Connector IFlow
Error Handling & Retry Strategy
| Scenario | Action |
|---|---|
| Temporary API Failure (HTTP 429/503) | Pause and retry after wait time. |
| Permanent API Error (HTTP 400/401/404) | Log to MPL and move to DLQ. |
| JMS Retry Exhausted | Message flagged as ignored; alert triggered. |
| Rate-Limit Exceeded | Connector pauses until limit resets. |
Monitoring & Observability
| Tool | Usage |
|---|---|
| CPI Message Monitoring | Track message status, errors, and retries. |
| JMS Queue Monitor | Check pending, in-flight, and DLQ messages. |
| MPL Logs | Track API call results and pause events. |
Future Enhancements
- Use API Header driven pause
- DLQ