Skip to Content
Technical Articles

Device Connectivity Feature in SAP IoT vs. SAP Cloud Platform Internet of Things differences

How is the new device connectivity feature in SAP IoT different from what was offered in SAP Cloud Platform as a standalone service?

The easiest way for a developer to answer this question is to look at the differences at the API level. This is where the below chart comes in. It basically crosses out APIs or the part of the API, that is not available (anymore) for easy reference. Here is the legend for the numbers shown on the chart:

  1. Instead of authentication in a proprietary way the regular Cloud Foundry authentication with SAML/OAUTH2 is supported. So all APIs dealing with Users and Sessions are gone and authentication is simpler and more secure for applications and users defined the SAP Cloud Platform way. Also tools like the SAP IoT SDK for NodeJS (github.com/SAP/leonardo-iot-sdk-nodejs) can be used for both the traditional SAP IoT APIs and for the new device connectivity APIs out of the box.
  2. Instead of a proprietary tenant mechanism the Cloud Foundry tenant mechanism is used. This means for most of the APIs the tenant ID is known and unique within a cloud foundry subaccount and should not/can not be provided anymore. This makes the API calls shorter and simpler to call.
  3. An ability to temporarely store raw measurements in our internal PostgresSQL or your Hana database is not available in SAP IoT. Incoming measurements are always and only stored in SAP IoT. If there is a mapping to a thing in SAP IoT then the data ends up there and you can call the variety of SAP IoT query APIs documented at help.sap.com Thing Data APIs with full business context. If there is no mapping defined then the data will end up in the SAP IoT Ingestion Error Log.
  4. An ability to directly forward raw data to multiple places different then SAP IoT is not available. One option you have is to translate the filtering logic you used in the past into an SAP IoT rule condition and then use actions to selectively act on the data. Different to the former approach this has full access to the business context in streaming.

For other, smaller differences please make sure to refer to the SAP IoT documentation and look for “device connectivity”. A set of tutorials showing how to make use of the new APIs has been posted at developers.sap.com/tutorials/iot-model-create and developers.sap.com/tutorials/iot-onboard-device.

The new device connectivity feature is exclusively available with the new, simplified, capacity unit based licensing for SAP IoT. Don’t worry, if you are using the old APIs you can continue to use them until you are ready to move on to the new license and the new device connectivity feature.

If you have questions or feedback on this change please use the comment function below for clarification questions or discuss the changes in more detail in our online community at answers.sap.com SAP IoT. Find more learning and enablement material around SAP IoT and Edge in the learning journey at learning hub SAP IoT and Edge and on our community page at community.sap.com/topics/internet-of-things.

api%20list%20showing%20the%20differences

API list showing the differences

/
api%20list%20showing%20the%20differences
6 Comments
You must be Logged on to comment or reply to a post.
  • Thank you Marcus. This is a very informative article. I look forward to the simplicity offered by these changes - especially for mass-onboarding IoT objects via API.

    • Hi Ulrich, I assume you meant to say "we use HTTP-forwarding of measures to our application for fast processing with SAP Cloud Platform Internet of Things". Yes, this feature is not available with the device connectivity provided in the new oneproduct service plan/license 8008796 for SAP IoT.

      I see the following options:

      1. You can do screening of the stream or of stream windows (aka batches) with streaming or batch rules in SAP IoT. The rule can for example check, if a threshold was exceeded. Let's say in 1 out of 1 million cases the threshold is exceeded then the rule would fire. This could lead to an event which can be picked up by an action that then can trigger a notification or can do a call to another system via the destination service (e.g. to create a service ticket in the backend automatically).
      2. You can use derivation rules to generate additional data (which then again can be checked with streaming rules) on the fly.
      3. If you mean "fast processing" as efficient or performant processing then considering to run batch jobs that read the ingested data from SAP IoT apis in batches might offer you an alternative.
      4. We are planning to provide an ability for customers to hook themselves into our Kafka message broker and pick up the processed time series (with business context) there. This would allow all data to be looked at by your code/server that would act as a Kafka consumer. Of course this requires your implementation to be scaling to the load as it increases. I cannot give you an estimate on when we will provide this.

      I hope this list helps but it would also be good to understand the use case and the requirement in more detail. If you could outline them here (without giving away confidential details) more specific advise could be provide by me or by others.

      Regards, Marcus

  • Hi Marcus,

    our application manage and control access rights inside buildings and support time bookings of employees. Our IoT devices/sensors are card readers/access-controllers or time booking terminals.
    On the edge the devices/sensors are managed and configured by an unix-based PC(IoTBox) which communicates by SAP-IOT-MQTT with our application inside SAP Cloud Foundry. Very important is that our measures are not signals. Our measures are bookings like employee enter/leave an area (access booking) or employee starts/stops work or make a break (time booking).

    Our use cases for the HTTP forwarding currently are

    1. Event-Driven reactive request/response communication to our IoTBox
      For a request/response communication from our cloud application with our IoTBox, we have defined one command capability (request) and one measure capability (response). By this we transfer all  access rights and time booking rights for every device and employee to the box and also can request information from the box. At the beginning of the development we poll the measures (not the time series!) for the response and than use the HTTP forwarding to send the response measure directly to our application to be more reactive for an interactive user scenario.
    2. Event-Driven Processing of time booking measures
      To provide SAP Success Factor with time booking data online we have to build time booking data sets (time pairs) out of the single time booking measures. This time pairing logic inside our application is triggered by receiving the time booking measures directly by HTTP forwarding and the resulting time pairs are send directly to SAP Success Factor.

    I hope that I could explain our system in short. With the HTTP forwarding it was very easy to solve this requirements and we do not want to go back to polling mechanism.

    Kind regards
    Ulrich

  • Hi, some of the customers considering to move to oneproduct would like to do this in an existing tenant. The only way today to do this is today is to unsubscribe from the old plan "standard" and to subscribe to the new "oneproduct" plan. Please be aware that this deletes all data including thing model, thing data and all other meta-data and data. We do not yet offer a migration, that would retain this data and/or would import the device connectivity data from the old instance of the old IoT Service product.

    Pre-requisite is that you have the entitlement for the new plans in place in the global account in question. This is the case if for example you have a license for PAI/PDMS (which provides both the old and new plans in its entitlements) or if you have a CPEA license (Cloud Platform Enterprise Agreement) or if you have explicitly licensed the new SAP IoT plan.

    If you go down this road please be aware that you should wait 15 minutes after hitting unsubscribe before doing a new subscription to allow for some clean up of the platform that takes some time after unsubscription. If you try to subscribe to early again it will fail with an error message that will not indicate that you should try later. We are working on a better error message but until then please simply wait 15 minutes.

    Regards, Marcus Behrens and the IOT-BSV-OPS-ONB team.

  • Hi Marcus,

    thank you for your analysis. I think you should include in the list of major differences the removal of the IoT Service Cockpit user interface to manage Devices, Sensors, SensorTypes, Capabilities and Gateways. As of the time of this comment, with oneproduct this can be done solely via API.

     

    Is there a way to make the Thing Modeler Portal App to use the /ThingConfiguration/v2/Packages('<package name>')/ThingTypes creation method (as documented here: https://help.sap.com/viewer/fffd6ca18e374c2e80688dab5c31527f/2106a/en-US/d07264e4c1254f9ead7b2ced04655476.html) instead of the v1?

    Thank you for your time

    Regards, Edoardo