I've recently had a number of questions from colleagues around architectures involving MQTT and what our preferred approach was. After some internal verification, I wanted to share an aggregate of my findings with the ThingWorx Architect and Developer Community.
PTC currently supports four methods for integrating with MQTT for IoT projects.
Choice is nice, but it adds complexity and sometimes confusion. The intent of this article is to clarify and provide direction on the subject to help others choose the path best suited for their situation.
ThingWorx MQTT Extension
The ThingWorx MQTT extension has been available on the marketplace as an unsupported “PTC Labs” extension for a number of years. Recently its status has been upgraded to “PTC Supported” and it has received some attention from R&D getting some bug fixes and security enhancements. Most people who have used MQTT with ThingWorx are familiar with this extension. As with anything, it has advantages and disadvantages. You can easily import the extension without having administrative access to the machine, it’s easy to move around and store with projects, and can be up and running quite quickly. However it is also quite limited when it comes to the flexibility required when building a production application, is tied directly to the core platform, and does not get feature/functionality updates.
The MQTT extension is a good choice for PoCs, demos, benchmarks, and prototypes as it provides MQTT integration relatively quickly and easily. As an extension which runs with the core platform, it is not a good choice as a part of a client/enterprise application where MQTT communication reliability is critical.
ThingWorx Azure IoT Hub Connector
Although Azure IoT Hub is not a fully functional MQTT broker, Azure IoT does support MQTT endpoints on both IoT Hub and IoT Edge. This can be an interesting option to have MQTT devices publish to Azure IoT and be integrated to ThingWorx using the Azure IoT Hub Connector without actually requiring an MQTT broker to run and be maintained. The Azure IoT Hub Connector works similarly to the PAT and is built on the Connection Server, but adds the notion of device management and security provided by Azure IoT.
When using Azure IoT Edge configured as a transparent gateway with buffering (store and forward) enabled, this approach has the added benefit of being able to buffer MQTT device messages at a remote site with the ability to handle Internet interruptions without losing data.
This approach has the added benefit of having far greater integrated security capabilities by leveraging certificates and tying into Azure KeyVault, as well as easily scaling up resources receiving the MQTT messages (IoT Hub and Azure IoT Hub Connector). Considering that this approach is build on the Connection Server core, it also follows our deployment guidance for processing communications outside of the core platform (unlike the extension approach).
ThingWorx Kepware Server
As some will note, KepWare has some pretty awesome MQTT capabilities: both as north and southbound interfaces. The MQTT Client driver allows creating an MQTT channel to devices communicating via MQTT with auto-tag creation (from the MQTT payload). Coupled with the native ThingWorx AlwaysOn connection, you can easily connect KepWare to an on-premise MQTT broker and connect these devices to ThingWorx over AlwaysOn.
The IoT Gateway plug-in has an MQTT agent which allows publishing data from all of your KepWare connected devices to an MQTT broker or endpoint. The MQTT agent can also receive tag updates on a different topic and write back to the controllers. We’ve used this MQTT agent to connect industrial control system data to ThingWorx through cloud platforms like Azure IoT, AWS, and communications providers.
ThingWorx Product Segment Direction
A key factor in deciding how to design your solution should be aligned with our product development direction. The ThingWorx Product Management and R&D teams have for years been putting their focus on scalable and enterprise-ready approaches that our partners and customers can build upon. I mention this to make it clear that not all supported approaches carry the same weight. Although we do support the MQTT extension, it is not in active development due to the fact that out-of-platform microservices-based communication interfaces are our direction forward.
The Azure IoT Hub Connector, being built on the Connection Server is currently the way forward for MQTT communications to the ThingWorx Foundation.
Since a couple of months it has been exposed that Protocol Adapter Toolkit was going to be discontinued.
Is this true ?
What are the replacement plans for on-premise deployments ?
Yes, you're correct. Due to PTC's strategic direction towards offering solutions, and less market demand for the product, we Ended the Sale (EOS) of the Protocol Adapter toolkit (PAT). Please see the KS article for further information and do not hesitate to reach back to us in case of further questions, concerns, or feedback
In continuation of one of the above mentioned supported paths for MQTT integration to ThingWorx, you might find this related post, video, and utilities of value.