
What is an API?
API stands for Application Programming Interface. It's groups a set of rules, protocols, and tools that allows different software applications to communicate with each other.
APIs disposes of methods and data formats that developers can use to interact with a particular software component or service.
APIs can be seen as messengers that can get or set data and, in the process, takes, process and return information.
APIs are used extensively in software development to enable different systems to work together, access each other's functionality, and share data securely and efficiently.
SAP Ariba APIs
Ariba REST APIs are constantly being developed and improved by SAP Solution Team, available for consumers and developers in https://developer.ariba.com/api.
In this portal, it's possible to identify all available APIs based on their respective fronts of operation, which vary depending on the SAP Ariba solution:
The portal also provides information regarding each API: the description of its purpose, mandatory and optional parameters, call URLs, Standard Rate Limits, as well as all necessary documentation for its consumption. Besides, all the documents and information can also be found in: SAP Ariba APIs | SAP Help Portal.
It's also important to mention that while many Ariba APIs are currently available for consumption, it doesn't guarantee that all the necessary information will be readily accessible. Some fields and data may not be included in the available APIs, so it's crucial to conduct an analysis before implementing the API in a real-world scenario (in ABAP, BTP, CPI, etc.).
In such cases, leveraging Postman calls can be beneficial for this initial check as a complement to the documentation.
Consuming Ariba API using Postman
Prerequisites:
That information must be provided to you by the Customer’s Administrator.
But, in the case where a customer hasn’t requested or has never used this API before, some steps are needed:
Choose:
When the entire process and approvals are completed, you should have all the necessary information for consuming the API. This is how the workflow should look like:
Steps to call API using Postman
Along with the provided documentation, you can also download the Swagger* for this API.
Download the API Spec (Swagger).
A popup will be opened. Click in Upload Files:
Search for the downloaded Swagger in your local directory and click in Import:
The project will be imported in Postman:
Check the Collection in the left side of Postman:
Before consuming the API, it’s necessary to get the Access Token for it.
Basically, it’s a credential that represents the authorization of a specific user/call to access resources on a specific server. When a user or application wants to access an API, they typically need to authenticate themselves to ensure that they have the authorization to get/change any data related to the process encoded by the API.
Access tokens usually have a limited lifespan and may need to be refreshed periodically to maintain the access available.
There are several methods for generating this token, each demonstrating a different approach. There's no difference between them in terms of results, but the choice will depend on personal criteria for usage.
This difference will be demonstrated visually in the next steps
Postman Request must look like:
Now, here is where it should be decided which token option is going to be used (1-By Client ID and Secret or 2-By oAuthBase64)
OPTION 1 = By Client ID and Client Secret
In Postman, select “Params” tab and set:
grant_type = client_credentials
client_id = <your client ID>
client_secret = <your client secret>
OPTION 2 = By oAuth64
In Postman, select “Params” tab and set:
grant_type = openapi_2lo
In “Headers” tab, set:
Content-Type = application/json
Authorization = Basic XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX (your oAuthbase64)
For both options the result must be the same: the token must be returned
It is possible for an API to contain multiple endpoints, each performing different actions. For example, within a "Customers API," you might find one endpoint for querying data, another for retrieving addresses, and yet another for updating values for a specific customer.
The same applies to Ariba APIs. Both in the portal and in the imported Swagger, various consumption possibilities of the API are available. It is up to the analyst and the client to determine what best fits the business needs.
In this example of Master Data API, notice that three different endpoints are available:
For demonstration purpose only, we are going to consume the first endpoint: GET ENTITY TYPES
I hope it helps everyone!
Regards
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
13 | |
11 | |
8 | |
6 | |
6 | |
6 | |
6 | |
5 | |
5 | |
5 |