In this blog post we'll be wrapping up the SAP Cloud Platform Internet of Things Q2. The webinar had two main focus points: interceptors in Gateway Edge and sending commands to establish a two-way communication between the cloud backend and devices in the field.
In Gateway Edge there is the possibility to perform actions on the data flowing through the Edge component by means of Interceptors. Interceptors are (as their name implies) able to intercept data flows to enhance data or send it to another application. It's an extension of edge computing: it's possible to manipulate incoming sensor data and/or outgoing commands to actuators eg. data thinning via filters, routing, exception handling or cloud communication.
Further use cases include data enrichment, collection of statistics, integration with other systems, and triggering of actions based on measurements incoming from the field.
Interceptors are always applied in sequence. There is no interceptor of the shelve; this has to be implemented by the user. Template interceptors for integration with data flows are available. They can be deployed to gateway edge via core apis or directly out the users IDE.
With SAP Cloud Platform IoT Service it's possible to establish a two-way communication link between devices and the cloud backend supporting different data types. Native commands from specific protocols eg. MODBUS, OPC UA are leveraged. Command issuing is tailored to the specific protocol used. For MQTT gateway edge/cloud publishes commands on a specific topic and the device consumes these messages. For HTTP the device itself calls gateway APIs to consume commands. For Modbus registry values are written, while for OPC UA: attributes are written in server component.
The demo scenario where both interceptors and the sending of commands were applied and which was shown in the webinar is outlined below:
The data originating from a (virtual) hydraulic flow meter are aggregated with an interceptor running in a Gateway Edge instance. In a second interceptor the values are filtered. Based on those filtered values a command is issued when a certain threshold is reached in order to close the virtual valve.
The recording of the webinar is available here: https://www.sap.com/assetdetail/2018/07/fefee10e-127d-0010-87a3-c30de2ffd8ff.html
The slides presented during the webinar can be found here: https://www.sap.com/documents/2018/07/a609e210-127d-0010-87a3-c30de2ffd8ff.html
Interceptors
In Gateway Edge there is the possibility to perform actions on the data flowing through the Edge component by means of Interceptors. Interceptors are (as their name implies) able to intercept data flows to enhance data or send it to another application. It's an extension of edge computing: it's possible to manipulate incoming sensor data and/or outgoing commands to actuators eg. data thinning via filters, routing, exception handling or cloud communication.
Further use cases include data enrichment, collection of statistics, integration with other systems, and triggering of actions based on measurements incoming from the field.
Interceptors are always applied in sequence. There is no interceptor of the shelve; this has to be implemented by the user. Template interceptors for integration with data flows are available. They can be deployed to gateway edge via core apis or directly out the users IDE.
Sending Commands
With SAP Cloud Platform IoT Service it's possible to establish a two-way communication link between devices and the cloud backend supporting different data types. Native commands from specific protocols eg. MODBUS, OPC UA are leveraged. Command issuing is tailored to the specific protocol used. For MQTT gateway edge/cloud publishes commands on a specific topic and the device consumes these messages. For HTTP the device itself calls gateway APIs to consume commands. For Modbus registry values are written, while for OPC UA: attributes are written in server component.
Demo Scenario
The demo scenario where both interceptors and the sending of commands were applied and which was shown in the webinar is outlined below:
The data originating from a (virtual) hydraulic flow meter are aggregated with an interceptor running in a Gateway Edge instance. In a second interceptor the values are filtered. Based on those filtered values a command is issued when a certain threshold is reached in order to close the virtual valve.
Webinar Resources
The recording of the webinar is available here: https://www.sap.com/assetdetail/2018/07/fefee10e-127d-0010-87a3-c30de2ffd8ff.html
The slides presented during the webinar can be found here: https://www.sap.com/documents/2018/07/a609e210-127d-0010-87a3-c30de2ffd8ff.html
- SAP Managed Tags:
