Hi Community,
Although we have reference architectures and integration paths for connecting devices to ThingWorx through Azure IoT; no one has ever written anything about doing the same from one ThingWorx to another. I thought I’d change that and put some ideas out there around how one might go about doing this. Although this is not officially supported or recommended by PTC; I have consulted with a number of leading SMEs on the subject, which have participated in forming the basis of my thinking outlined here.
Components Required (in order of communication path):
- On-premise ThingWorx Platform
- Protocol Adapter Toolkit* (CXS) - MQTT
- Azure IoT Edge
- Azure IoT Hub
- ThingWorx Azure IoT Hub Connector (CXS)
- Azure Cloud-hosted ThingWorx Platform
PAT (2) with codec to encode MQTT messages publishes to on-premise IoT Edge MQTT endpoint which handles store-and-forward of messages to IoT Hub. An Azure IoT device would exist for each Thing you wish to represent on the ThingWorx servers. The Azure IoT Hub Connector would pick-up the incoming messages and pass them on to the cloud ThingWorx which would decode the MQTT payload and map to Thing property updates.
The only part that I presently don’t like about this approach is that you’ll need to decode the MQTT messages on the ThingWorx platform in the cloud when they are received from the IoT Hub, and this mechanism will need to also need to handle encoding and publishing back to the IoT Hub if C2D (Cloud-to-Device) messages are to be implemented (aka bi-directional). This is required as ThingWorx only supports AlwaysOn as an application level protocol so some form of mapping needs to be done.
* Another approach would be to replace the PAT with a custom agent which implements both the ThingWorx Edge SDK and the Azure IoT device SDK
Regards,
Greg Eva
