Skip to Content

IoT Prototype with Business Rules and Workflow – Blog Series 2.1/4

Part 2.1: Remote temperature and humidity control

Link to part 1 of the Blog Series –

Lets get started with the configuration for the first scenario in the prototype. Configuration is required in various services of SCP for the completion of the IoT prototype.

Step 1- Device management: Set up message types, device types and device in Internet of things cockpit.

Step 2 – Business Rules: Create business rule services and set up rules.

Step 3 -Workflow: Create workflow and related user interfaces in Web IDE. (check part 2.2 for details)

Step 4 – IoT application: Create Java application to integrate all these services and Python code to send the sensor data from the device .(check part 2.2 for details).

Since I will be covering the configuration in detail for the first scenario, I have decided to split Part 2 of the series into two. I will keep it brief for the next 2 scenarios as the steps are almost the same.

Steps 1 & 2 will be covered in this blog and Steps 3 & 4 in the next blog.

Make sure that the following services are enabled in SAP Cloud Platform Neo environment under your trial account.

  • Internet of Things
  • Business Rules
  • Workflow
  • Web IDE full stack

Step 1: Device Management

The device management steps shown below covers the configuration of all three scenarios of the prototype

Go to ‘Internet of Things’ cockpit –

Go to Device Management -> Message Types

Create four message types as shown below:

THSensorData: This message type will be used to send temperature and humidity data from device to SCP.


LowStockSensorData: This message type will be used to send the material type of the material with low stock.

ThicknessSensorData: This message type will be used to get the thickness information from the device    for scenario 3.

AdjustThicknessSensor: This message type will be used to send the corrected thickness data to the device.

Go to Device Management -> Device Types

Create one device type with all the above four message types. Three of the message types will be configured with direction ‘From Device’ and one with direction ‘To Device’.

Go to Device Management -> All Registered Devices

Register a device with the device type configured above. Note the device ID and the authentication token which the system generates during the device registration. These will be used in the Python script which runs in the device to send and receive sensor data.


Configure Processing Service Mappings

For all four message types, configure processing service mappings so that the messages received from the device are stored in our own set of tables instead of the auto generated T_IOT_<message type id> tables.

For more information about this topic, you can refer

Create three tables as below and map them to the corresponding message type/device type IDs .

T_TH_IOTMESSAGES – To store temperature and humidity data from device.

T_LS_IOTMESSAGES – To store data from low stock sensor.

T_THICK_IOTMESSAGES – To store data from thickness sensor.

Note that this step is optional. You can process the messages directly from the IOT message tables. I will mention where you have to make changes in the code to accommodate this.

Step 2: Business Rules

Lets configure the business rules for this scenario.

Go to Business Rule Editor –

Create a project to hold the business rule service for the scenario.


Create two Data Objects

measures: with two attributes – temperature and humidity



result: with one attribute to hold the result to indicate whether the temperature and humidity values are exceeded.



Create two Rules

Temperature Rule  – This is a simple text rule which returns true if the input temperature is more than the set limit.



Humidity Rule – This too is a simple text rule which returns true if the input humidity is more than the set limit.


Create two Rulesets

Check Temperature – Add Temperature rule to this rule set


Check Humidity – Add Humidity rule to this rule set


Create two Rule Services

Temperature Exceeded Service – This rule service takes the data object ‘measures’ as input and returns ‘result’ as output.

Humidity Exceeded Service – This rule service takes the data object ‘measures’ as input and returns ‘result’ as output.

Assign these rule services to the corresponding rule sets. Activate all the objects created in the steps above. Do not forget to deploy both the rule services.

The rule services will be called from the IoT application to validate the temperature/humidity from the sensors.

You can test the Business Rule Services by using Postman. Steps are mentioned below.

Testing Business Rules using Postman

Get the XSRF Token

Send HTTP request to (URL – get the XSRF token required to invoke the business rule service. Do not forget to set the authorization to basic and give your SCP trial account user/password.

Call the Business Rule Service

Invoke the Business Rule Service by passing the XSRF token from the response header of the previous request.

[ use the URL ]

Pass the input values as JSON in the request body.The rule service returns the result as true since the input temperature ’25’ is more than the set limit ’24’.




I tried to keep it very simple. Please feel free to comment if you have any questions. See you in Part 2.2 with the next steps for this scenario.

You must be Logged on to comment or reply to a post.
  • Hi Sharadha

    First of all thank You for this great Blog series!!


    But I've got a problem by fetching the X-CRSF Token and hoping you could give me solution.

    I'm using not the trial version and by trying to get the Token he sends me an 503 error as response.

    Do you got any idea why?

    • Kai,


      Can you try ? The URL you are using seems to be different.


      Let me know if this helps.




      • Thank You for your fast reply


        I've tried now with the as well but still got the same response.



        • Hi Kai,


          I have requested help from someone from SAP. Refer the comments section in the first part. Hopefully she will help us out.




        • Kai, I have posted the solution below in the community thread. hope it works for you.


          I too got a similar error when I tested in the non-trial environment but managed to find the cause. I used the URL below and got response as 200 and got the XSRF token too.

          I got the url (first part) from the URL mentioned under connectivity services -> destination ->bpmrulesruntime . If you notice closely the term 'rules' appear twice once before the runtime and once after. I guess you can try with the same URL or check and confirm once in your destinations.

          Hope this helps. Let me know if it works.


          • Hi Sharadha,

            Thanks a lot for your reply!!

            Now I get a token but with a 443 forbidden status.

            When I paste my token into the POST request I also get 443 status back.

            And it tells me that there is still a X-CRSF-Token required.

            Is there maybe more to do to give postman any other kind of authority for the X-CRSF-Token?

            best regards,


          • /
          • Can you add another header parameter 'Content-Type' with value 'application/json' and test again?




          • Sorry in the screenshot it's just one of many tries I did.

            I've tried it with varied version of the request to find out why it maybe don't work or rather how it works.

            I've tried it by addinng X-Requested-With : XMLHttprequest and DataServiceVersion : 2.0 in the header too.

            And I also tried out with contentt type but got the same result with 403 response status

          • Hello Kai and Shraddha,

            Sometimes postman caches the previous run configuration and posts all this issues. Few things:

            • Ensure that you have using the right API to get the token
              https://<bpmrulesruntime host>/rules-service/v1/rules/xsrf-token

              Headers as:
              X-CSRF-Token : Fetch


            • Username and Password which had RuleSuperUser role via Configure Business Rules Runtime option from cloud platform cockpit


            • If all the above is done then please close all the browser, open Postman and ensure interceptor is not switched on


            • As alternative option, you can also use API Business Hub to test your service. All you have to do is (a) logon to, (b) configure the environment and (c) run any of the business rules service

            Hope that helps,

          • Hi Kai,

            I got the same issue, It was basically due to cookies.

            When I did the get you effectively get the X-CRSF token, but please have a look on the cookie as well.

            You have a JESESSIONID

            You need to put it in the post request by adding this JESSIONID in the cookie of the request


  • Hi Archana -

    Really this is great block .

    Can not we single IoT table to store all the parameter of sensor data rather creating three IoT tables ...


    • Hi,


      This is Sharadha - Author of the blog series.

      The structure of the IoT tables differ based on the attributes of the message type. Since I have used different structures for all the message types, I have created separate tables.