Skip to Content
Personal Insights

Achieve near real-time reporting of SAP Ariba using the SAP Ariba APIs

In this blog post, I will share my findings while extracting data and developing a near real-time reporting solution of SAP Ariba by using the SAP Ariba APIs available. Also, I include a brief comparison between the Analytical Reporting and Operational Reporting APIs.

Unfortunately, there is no mechanism, e.g. webhooks, for an external application/listener to be notified when a particular object has changed in SAP Ariba. For example, receive a notification when a Sourcing Request has been created/updated/deleted. This means that we need to poll the APIs available to achieve near real-time reporting of SAP Ariba data. For this, you will need to use a combination of the Operational Reporting APIs and other object specific APIs available.

⚑️If you are unfamiliar with the SAP Ariba APIs, the SAP Ariba Developer Portal and don’t know where to start…. I recommend visiting this blog post first – SAP Ariba developer portal – How to create applications and consume the SAP Ariba APIs

Given that we are interested in near real-time reporting, we will be mainly using the Operational Reporting synchronous API. That being said, there are scenarios where the asynchronous API will be more suitable, e.g. migration, consolidation of data. Choose wisely when deciding which API will fit best your needs.

The examples below cover the Operational Reporting APIs for Sourcing. That being said, the principles mentioned apply for the Procurement Operational Reporting APIs as well.

Can I use the SAP Ariba Analytical Reporting APIs?
Short answer, no. SAP Ariba provides reporting out of the box but the reporting is based on analytical data. These analytical data is accessible via the SAP Ariba Analytical Reporting API but there is at least a 6 hour delay from the data being created/updated and it being available in the Analytical Reporting API. Below some differences between the Analytical and Operational Reporting APIs:

Analytical Reporting API Operational Reporting API
Data availability Delay of at least 6 hours Real-time
Document types Composed of Facts and Dimensions, exactly the same that are part of reporting within SAP Ariba Simple tables
Relationships The metadata provides us the relationships between document types, e.g. Fact table will have relationships with Dimensions No relationships between document types specified in metadata
Richness of Data Includes way more data than its equivalent in the Operational Reporting API Not as many tables (and fields) exposed as in the Analytical Reporting API
Filtering You are able to filter on almost any field that is selectable Not that many fields available for filtering. Generally, TimeCreated and TimeUpdated. It is likely that additional filtering will need to happen in the extraction program

If you want to know how to easily visualise the metadata of the Analytical Reporting API, check out this blog πŸ‘‰ https://blogs.sap.com/2020/10/28/generating-entity-relationship-diagrams-from-the-sap-ariba-analytical-reporting-metadata/. It shows you how to generate entity-relationship diagrams from the metadata.

Now that we are familiar with some of the differences between the Analytical and Operational reporting API, lets get back to the Operational Reporting APIs and its use when it comes to near real-time reporting.

Tips and Tricks

  • Get very familiar with the fields for each of the document types that you are interested in. Validate your assumptions and what the API returns against what you see in the SAP Ariba UI. Catching a data related bug in a report is much harder and costly than noticing it during development.
  • If the data is not available in the Operational Reporting API you might be able to use a subset of the data returned in the reporting API to call another API. For example, the Operational Reporting API does not expose Sourcing Requests as a document type but the Task document type returns tasks for Sourcing Requests. Also, the ProjectAuditInfo return information when a Sourcing Request is updated. We can use the Sourcing Request ID to call another API, e.g. External Approval API, and retrieve details of a Sourcing Request.
  • Supplier data is not available in the Operational Reporting API. For this, use the Supplier Data API with Pagination. You can filter by updated date to retrieve suppliers updated within a specific time frame.
  • Master data can be used to enrich the data returned by the Operational Reporting API. For this, you can use the Master Data Retrieval API.
  • It is possible to define view templates with time created and time updated as filters. Sometimes you might need to extract data based on when the data was created and other times it is better to extract data based on when it was last updated.
"filterExpressions": [
    {
        "name": "createdDateTo",
        "field": "TimeCreated",
        "op": "<=",
        "defaultValue": null
    },
    {
        "name": "createdDateFrom",
        "field": "TimeCreated",
        "op": ">",
        "defaultValue": null
    },
    {
        "name": "updatedDateTo",
        "field": "TimeUpdated",
        "op": "<=",
        "defaultValue": null
    },
    {
        "name": "updatedDateFrom",
        "field": "TimeUpdated",
        "op": ">",
        "defaultValue": null
    }
]

Things to be aware of

  • Although it is possible to define a view template in the Operational Reporting API with a document type of the Analytical Reporting API, do not expect your requests to magically return real time data πŸ˜ƒ. This is a bug in the API.
  • Validate the structure of the underlying objects returned by a document type. There are document types that return data for different objects, e.g. Task document type in the Operational Reporting API. It can return tasks for Sourcing Requests, Sourcing Projects, Contract Workspaces. The structure of a task for a Sourcing Request, a Sourcing Project, and a Contract Workspace might vary slightly as some of these might contain additional data.

Recommendations

  • Given that data will be replicated and that there can be an issue when replicating it. There should be a mechanism to ensure that the integrity of the data has been transferred. For this, you can use the asynchronous APIs to extract the data for a day and use this to ensure that all data is in the target system/data warehouse.
  • Define view templates with only the data (select fields) that you require. This will reduce the load in the API, you will retrieve data faster and if using the asynchronous API, the size of the files returned will be more manageable.
  • Use a custom-schedule to extract data if possible. Depending on your business requirements, it might be the case that you don’t require real-time data 24/7. A custom schedule can be used to define the period of the day when near real-time data is required, e.g. running every 15 minutes during core business hours, and when a delay is acceptable, e.g. running every hour outside of core business hours. This will reduce the number of API calls and in a way, working around the API rate limits.
  • The different APIs have different rate limits, make sure that the scheduling and developments takes this in consideration.
  • The asynchronous API is your friend. It can be used for the initial load and to ensure data integrity.

I hope the information shared in this blog post makes you aware of some of the benefits and limitations that there are when trying to report on near real-time SAP Ariba data. It is possible that this blog post gets updated with time, as there might be additional tips/tricks/info that I find along the way which will be worth sharing.

Note: Special thanks to my colleague Mustafa Gilic for reading an initial draft of this blog post and providing valuable feedback πŸ‘

4 Comments
You must be Logged on to comment or reply to a post.
  • Hello everyone. A couple of days ago, we successfully completed a project to integrate SAP Ariba with the customer's ERP system. The main problem with the API was that within the API there are restrictions on API calls: 1 per second, 3 per minute, 50 per hour and 300 per day. Keep this in mind, because if the call goes through two different viewTemplates at the same time, it is highly likely to receive HTTP / 429.

    • Roman Velichko , first of all... Thanks for sharing your experience.

      Which API are you consuming? The main API mentioned in the blog post is the Operational Reporting API for Sourcing, which has the following rate limits -> Rate Limit (Requests): 1/second, 10/minute, 100/hour, 500/day. That being said, you are spot on... you need to be very aware of the API rate limits to achieve some type of near real-time reporting. To avoid calling two different view templates at the same time, you can add a delay to the extractions, so they don't bump into each other.

       

      • Hi. We know that Ariba API give us async call, but according to client requirements we have to send to Generic ERP system in single flow PR and PO changes both. πŸ™ for PR ΠΈ PO i have to create two different viewTemplates. AndΒ yes πŸ™‚ we create delay workaround in iflows.

        Operational Reporting for Procurement - Synchronous API

        The SAP Ariba Operational Reporting APIs for procurement enables you to report on the transactional procurement data that you need to make operational decisions. You use the API to create a client application that extracts reportable data.

        The SAP Ariba operational Reporting API can be used synchronously to retrieve smaller data sets for procurement objects. In the synchronous usage, the requested output is batched and paginated and results are returned one page at a time in JSON format. The maximum number of records returned is 10000.

        For complete documentation of this API, see Operational Reporting for Procurement - Synchronous API.

        Rate Limit (Requests): 1/second, 3/minute, 50/hour, 300/day (this limits for eu.developer.ariba.com/)

        /
        πŸ™