ThingWorx Marketplace Publication Process

[Overview]

What technology should I use to build my integration?

Inside Thingworx
  • Packaged Entities: Packaged entities allow you to build and test all of your functionality through the ThingWorx composer. This allows for multiple different connected entities to be built in a way that allows a full or partial solution to be exported into a bundle and distributed for re-use.

    Pros: Allows user to change and customize the functionality based on their needs. Add/Remove unneeded components, update service functionality and enable/disable subscriptions.

    Cons: Can be modified by the user resulting in different versions that are difficult or impossible to support. Cannot include configuration tables, custom widgets or third party java libraries. Service source code will be visible to all users with access to the entities.

  • Extensions: Extensions allow you to do everything packaged entities do and more. Exported entities can be included in the extension which means you can start with packaged entities and change to extensions easily. The major difference between packaged entities and extensions in this context is that those entities can no longer be modified or removed once they are uploaded as part of an extension. Extensions also have some special functionality you wont find in other parts of the platform. This includes custom widgets, configuration tables for things, third party java libraries and hidden service source code.

    Pros: More functionality available, hidden service source code, custom UI components, easily supportable since the user cannot modify it.

    Cons: Cannot modify to create a customized version


Outside of Thingworx
  • ThingWorx API : Allow Integrated Systems or devices to easily connect with a ThingWorx platform. Anything that can make an HTTP POST can read and update properties or execute services on a ThingWorx platform

    Pros: Allows user to create an integration easily with minimal dependencies on ThingWorx specific training. Dynamic API generation on the ThingWorx platform exposes APIs based on user customization.

    Cons: Platform cannot trigger a service on Integrated systems or devices and properties are updated only when the Integrated system or device "polls" the platform for updates.

  • Edge MicroServer (pre-built agent) : A binary executable available for Integrated systems or devices that run Windows or Linux. The EMS is often used in gateway devices to provide a local reflection of the ThingWorx platform API so devices that are not capable of making TLS connections can securely interact with the platform.

    Pros: Just simple scripting required to allow ThingWorx platform to interact with Integrated system or device

    Cons: Requires Integrated System or device running an operating system and about 1.5MB of RAM

  • Edge SDK: Java, C, iOS, Android and .Net wrapper for the “Always On”<link> protocol used to connect to the ThingWorx Platform. Presented as a toolkit with no built in functionality.

    Pros: Allows creation of and interaction with fully capable Things on the ThingWorx platform in many Integrated System or devices. Portable architecture.

    Cons: Nothing is running out of the box and customized functionality needs to be built.

  • AWS / Azure Integrations: Allow Integrated Systems or devices that connect with AWS or Azure to connect with ThingWorx platform

    Pros: Allows Integrated System or devices to connect using public machine clouds

    Cons: Adds dependency to system

Still can’t find a suitable Technology? Read further…
  • Protocol Adapter: Integrated systems or devices that are not able to run the ThingWorx EMS or one of the ThingWorx edge SDKs can still connect to a ThingWorx platform by using a Protocol Adapter server. This server will open a networking port and listen for messages from the Integrated systems or devices while also establishing a connection with the target ThingWorx platform.
  • Custom Java integration: This enables the developer to leverage any java library to build an integration that works for their particular scenario. Ex. MQTT, AMQP, WS, UDP, TCP, etc.
  • Pre-Built Integrations: There are multiple pre-built ThingWorx platform extensions that enable integration with common messaging protocols. Two examples of this are the ActiveMQ Extension and MQTT These are helpful to get started, but are not supported and will have to be tested to production level loads.
  • Shoulder Tap: A custom service can be created on the ThingWorx platform that triggers an integrated system or device to push or pull data assuming this is available on the integrated system or device.

[Go back to Develop main page]