Postman is a popular and easy to use Rest Client. Therefore, it is well known and often used by a lot of developers out there. But still, a lot of customers and partners struggle using the SAP IoT Application Enablement APIs due to the fact, that AE is not supporting Basic Authentication. That’s why I want to show you today how to access the APIs, test them and later build amazing apps on top of Application Enablement.
Overall there are two different way to access the APIs. One is to use your user’s session from the Chrome browser and the other one is to get an OAuth token and use this to authenticate your request. They both differ in the way you would use them in a project. The Chrome session has a user context and you can use this method if you want to test APIs for frontend apps. In Frontend apps, a user should log in and then only see the data which he’s allowed to consume. Please have a look at the official SAP IoT Application Enablement documentation, to get a better understanding of the authentication concept.
However, the OAuth token is received using the client secret you’ll get once you order an Application Enablement tenant. This client secret is, of course, individual for every tenant, but within the tenant you can consume all APIs and data. This kind of authentication would be used for backend apps, where you don’t have a user context. You can automate thing configuration, insert data or consume data with this token.
But now let’s see how to use them.
To be able to use the Chrome session you need an extension for Chrome and Postman – the Postman Interceptor. Add it to your Chrome browser, turn it on in Postman, log in to the Launchpage of your Application Enablement tenant and here you go, you’re now using your AE session from Chrome in Postman.
To see which APIs you’re now able to access I want to point out the Application Enablement documentation once more, where all APIs are described.
By the way, if you now tested this using a POST, PUT or DELETE request and got the error ‘403 – Forbidden’, that’s not a problem with the authentication itself, but you probably missed to add an X-CSRF-Token to your request. So, go back to any GET request, add the Header ‘X-Csrf-Token: Fetch’ and you’ll receive one in the headers of the response. This can be added to your request (X-Csrf-Token: i8XNjC4b8KVok4uw5RftR38Wgp2BFwql) and your request will work.
So, that one was easy, let’s see how the Service2Service communication works.
To use an OAuth token, you of course first should get one. Therefore all tenants have this API endpoint:
If the interceptor in Postman is still turned on, turn it off and send a POST request to this endpoint using the following headers and body:
If you used the right client secret, you should receive a response with three important values:
- token: This is you Bearer token you can now use to authenticate your requests
- expiresIn: This value tells you how long (in seconds) the token you received is valid
- scope: This shows the scope your token has and what you can do using it
Now to see some data using the Bearer token, there is one more thing to keep in mind. Instead of accessing the data using the app router of cloud foundry like we did before, we are now accessing the apps directly. That means that the API endpoints will change a little.
Here is an example:
Before you used an application router at this endpoint ‘https://<your tenant>.iot-sap.cfapps.eu10.hana.ondemand.com/appcore-conf/Configuration’ to access the configuration of your tenant. But now with the Service2Service communication, this endpoint will change a little to ‘https://appcore-conf.cfapps.eu10.hana.ondemand.com/Configuration’ as you are now able to point your requests directly to the microservice for thing configuration.
Now add the Header ‘Authorization: Bearer <your token>’ to the request with the new endpoint and you’ll see the configuration data of your tenant.
I hope this blog helps you to use the SAP IoT Application Enablement APIs and if not feel free to ask your questions in the comments.