Access the SAP IoT Application Enablement APIs using Postman
The information provided here also applies for the SAP Leonardo IoT APIs and several other apps on Cloud Foundry.
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.
This feature is only available in the Postman Chrome App, which is deprecated. In the Postman Desktop App it is not available. For more information click here.
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. You can find the client_id and client_secret in the Cloud Platform Cockpit. For more information please refer to the documentation.
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.
Thanks for the blog on usage of postman for IoT AE.
Hi Jan Reichert , I want to create an event in my IoT AE instance using the REST API (see https://answers.sap.com/questions/406975/how-to-make-use-of-iot-application-enablement-rest.html?childToView=405677#answer-405677)
Using your tutorial, I got the access_token. Nicely explained by the way 🙂
However, I struggle now sending the Postman request. You stated that the endpoint changes. In my example, I created events using 'https://<my tenant>.sb-iot-sap.cfapps.sap.hana.ondemand.com/appiot-mds/Events'. Following your logic I should now use 'https://appiot-mds.cfapps.sap.hana.ondemand.com/Events'. Unfortunately, this doesn't work for me. I get a http 404 error.
How should I transform the url?
As discussed internally this issue was something specific to our internal deployment. Partners and customers should be able to transform the URL as described in the blog.
THX for the blog.
First all, Thanks a lot for such a wonderful explanation.
I am stuck in a "post" cal for .xsodata service (to create a record).
First I made a get call to xsodata to fetch x-csrr-token.(PFB image)
To create a record I make a "POST" request, with the environment variable i.e fetched token enabled (in header section) . Body Containing data to be created. PFB screenshot
But, when I send the request , I get an error - 405 Method not allowed.(PFB image)
Please help me understand how to pass the fetched token to a "POST" request.
Do i need to make any changes in the URL or add params? I have tried all my ways but still no luck.
I have also attached my .xsaccess and .xsodata file below.
Thanks in advance for the help.
As far as I can see this question is not related to Application Enablement, is it? But let me still try to help you.
According to the RFC for HTTP, a 405 indicates that the server knows the method but can’t handle it . So, I guess that for your OData Service the POST method is not implemented yet . It’s not a problem with the X-CSRF-Token, which would result in a 403 error .