Smart Coffee Machine – Integration with SAP Backend
This blog is the last part of our blog series about the Smart Coffee Machine. In the previous blog we learned how to model our IoT devices and sensors. Now that our IoT setup is done, it is time do integrate our data with our SAP backend system.
More information about our current setup can be found in our previous blog posts:
Integration with SAP Backend
The data collected by the IoT setup can be used to trigger our SAP backend or inform other parties about possible incidents. This can easily be done by SAP Cloud Platform integration. For our case we created an Integration Flow that will gather the data from the exposed SAP IoT Thing Modeler OData services. Our backend services will then insert this data into a Z-table.
High-level overview of the CPI-Flow (Main):
High-level overview of the CPI-Flow (All):
The main flow will call the following 3 sub processes:
- Get IoT Token (get a token to authenticate to the IoT OData Service)
- IoT Device (Gets the IoT Data)
- SAP Create requisition (Calls SAP Backend and insert data into Z-Table)
The first sub process is the “Get IoT Token” sub process.
The “Set Post Data” content-modifier will prepare our headers to request a Bearer token on our IoT tenant. Once our headers are set, we will perform a request-reply on our IoT tenant with “/oauth/token” as endpoint. The response will contain an access-token in JSON-format.
Here is where the “JSON to XML Converter” kicks in. The JSON response is being converted to XML, so that in the content modifier the token can be accessed by using XPath expressions. We will save this bearer token as a property in the CPI-Flow so that we can use it as a Bearer token in the following calls to the IoT OData services.
Our second sub process “Get IoT Data” will handle the calls to our IoT tenant service.
In this sub process we start with setting our Thing id and timeframe on which we want to gather our data. Remember where to find the Thing Id in the SAP IoT Thing Modeler (see previous blog post.). Next we will set the “Auth-header” (Authorization) equal to our received Bearer token from our previous call.
The first call that will be executed is a call to get the default Thing data, containing the sales organization number and the equipment Number. This data can be filled in the Thing Modeler. We created a default-data property set and assigned this property to our thing type.
The second call will get the measures from the OData Service. The result of both calls will be converted from JSON to XML and then gathered/combined to create one result in XML-format.
The third and last sub process of our main-process is the “SAP Create Requisition” or “Call SAP Backend” sub process. This part of the flow will place the final data into the SAP Backend in a Z-Table.
In the content Modifier, which is the start of this sub process we tell the process to fetch the X-CSRF-Token when we will perform the call to the backend. With the “setIsValue” Groovy-script we check how long it took to make the coffee so we can decide if we want this data in our Z-Table or not.
Once we decided if we want this data in our Z-Table a GET request-reply is called on the backend to fetch the X-CSRF-Token, this token is used later to be able to POST our result into the Z-Table.
After some logging the final POST call is performed with the authentication header and the X-CSRF-Token, to insert the data into the backend through a custom gateway service.
With this data in our backend we created a full End-to-End flow from measuring our coffee data to posting it to IoT Services, mapping this with its Digital Twin, continuing with displaying them in a generated IoT UI5 Template app and adding the finishing touch by placing the data in the SAP Backend so the desired actions can be performed or triggered upon this data.
What did we do?
- We authenticated to our IoT service
- We fetched our IoT data based on some specified filters
- We called a custom Gateway service in which we save our data into a custom table