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 singleton processing via a 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. 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 with separated 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 |
| 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, 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
| Step | Function |
|---|
| 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 singleton 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 requests 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
| Object | Value | Description |
|---|
| Header Value | jmsProcessDirectPath | The ProcessDirect path of the Provider IFlow |
| Queue Name in JMS Receiver Adapter Configuration | aribaEventMgtQueue | Name of the JMS Queue. Externalisable value |
JMS Queue
All IFlows that forwards the processing to JMS Queue should have the following configuration settings in the JMS Receiver Adapter
| Object | Value | Description |
|---|
| Queue Name | aribaEventMgtQueue | The Unique name for the JMS Queue |
| Access Type | Non-Exclusive | Each JMS Queue entry will process independently of each other due to the Design Principles applied |
| 2 days |
|
| Expiration Period | 30 days |
|
JMS Events Router
Sender Adapter JMS Configuration
| Object | Value | Description |
|---|
| Queue Name in JMS Sender Adapter Configuration | aribaEventMgtQueue | Name of the JMS Queue. Externalisable value |
| Number of Concurrent Processes | 1 | Note: This value is important for Singleton Instance of the IFlow. This is vital for Serialised processing of the Queue |
| Retry Interval | 1 minute |
|
| Exponential Backoff | Ticked |
|
| Maximum Retry Interval | 60 minutes |
|
| Dead Letter Queue | Ticked |
|
| Maximum Retry Limit | 5 | The messeges are gracefully pushed to the DLQ. No further processing will be done after the configured number of retries. |
Receiver Adapter JMS Configuration - For Dead Letter Queue
| Object | Value | Description |
|---|
| Queue Name | DLQ_aribaEventMgtQueue | All messages after the configured number of Retries are moved to this DLQ |
| Access Type | Non-Exclusive | Since messages are not automatically reprocessed from this queue, this value is not relevant for the solution |
| Retention Threshold for Alerting | 2 days |
|
| Expiration Period | 30 days |
|
| Compress Stored Messages | Ticked |
|
| Encrypt Stored Messages | Not ticked |
|
| Transfer Exchange Properties | Ticked |
|
Other Configurations
| Object | Value | Description |
|---|
| maximumRetries | 5 | After the defined number of attempts, the message is pushed to JMS Queue. The Failed messages can be found in the Monitoring |
Provider IFlows Configuration Requirements
- Provider IFlows Sender ProcessDirector 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 in the Ariba Event Management API Connector IFlow and Keelvar API Connector IFlow
- 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 URL
Construction of the URL with an example:
| METHOD | https:// | <Ariba Base URL> | <Ariba URL Path> | ? | <Connector Defined Query Parameters> | & | <Received Query Parameters> |
|---|
| GET | https:// | eu.openapi.ariba.com/api/sourcing-events/v2/prod | /events/identifiers | ? | realm=7452####-SS-T&user=R_XXXXXXXX&passwordAdapater=XXXXXXXXX | & | $filter=(createDateFrom gt 1761418273 and createDateTo=1761464729) |
An IFlow calling the Adapter must provide the following Header Parameters to construct the API endpoint to Ariba
| Object | Header Name | Description |
|---|
| HTTP Method | aribaMethod | The HTTP Method for the API |
| Ariba Url Path | aribaUrlPath | The Path (i.e. the endpoint) that is amalgamated with the Base URL to construct the API endpoint |
| Query Parameters | aribaUrlQuery | The additional Query Parameters that must be amalgamated with the the Common Query parameters defined in the Adapter |
Additional Parameters
| Object | Description | Value Dev & Test | Value Prod |
|---|
| Ariba Base URL | Base URL to Ariba Event Management APIs. | eu.openapi.ariba.com/api/sourcing-event/v2/prod |
| Credential Name | OAuth Credential Name for Ariba Endpoint in SAP CPI | OAuth_Ariba_Sourcing_EventMgmtAPI |
|
| Ariba API Delay | The Delay to be implemented when the remaining API count is zero | 2 seconds |
|
| Ariba Password Adapter | Password Adapter defined for Technical Users in Ariba | ThirdPartyUser |
|
| Ariba Realm | Ariba tenant ID | 745255310-SS-T |
|
| Ariba User | Technical User for SAP CPI to extract events | R_BTP_ARB_ADMIN |
|
| Ariba API Key | Security Credential Name containing the API Key for Ariba Event Management | APIKEY_AribaSourcing_Keelvar_Dev |
|
Keelvar 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.
| METHOD | https:// | <Keelvar Base URL> | <Keelvar URL Path> | ? | <Query Parameters> |
|---|
| GET | https:// | test.keelvar.dev/api | /feeds/awards | ? | sourcing_event=$event_uuid' |
An IFlow calling the Keelvar Connector must providefollowing Header Parameters to construct the API endpoint to Keelvar
| Object | Header Name | Description |
|---|
| HTTP Method | keelvarVerb | The HTTP Method for the API |
| Keelvar Url Path | keelvarPath | The Path (i.e. the endpoint) that is amalgamated with the Base URL to construct the API endpoint |
| Query Parameters | keelvarQuery | The Query Parameters |
Additional Parameters
| Object | Description | Value Dev & Test | Value Prod |
|---|
| Keelvar Host | Base URL for Keelvar API | test.keelvar.dev/api | my.keelvar.app/api |
| Keelvar API Key | Security Material in CPI containing the Keelvar API Key | KeelvarToken |
|
Error Handling & Retry Strategy
| Scenario | Action |
|---|
| Retry Limit Reached | Pause for the configured length so that additional API calls are reached |
| Permanent API Error (HTTP 400/401/404) | Provider IFlow logs the error in MPL and push back to JMS Queue |
| JMS Retry Exhausted | Gracefully push the message to DLQ for analysis. |
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
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
