IoT Tips

  Hello, IIoT Developers!   Today, I’m going to provide you an overview of a new SDK we’re offering for developers to build custom web content. It’s called our Visual SDK. We released 9.0 in June, so it’s time to start getting excited! In case you missed it, check out these other 9.0 posts on active-active clustering, Composer and Mashup Builder, and the 9.0 release overall.   In 8.4, we introduced a new visualization architecture and set of web components based on Polymer. We’ve continually updated and added new widgets and features with this architecture each release, including new Chart Components in 9.0. This SDK was previously available mostly as a style guidance, informing designers and developers what elements and behaviors were available in the new PTC web component-based widgets. You could use this SDK to style in CSS custom elements of the web components in a mashup-based application. You weren’t, in 8.4, really able to use this SDK yet to actually create your own Polymer web components and have them be as robust in the Mashup Builder in ThingWorx.   In 9.0, this SDK has been expanded so you not only have style and behavioral descriptions of PTC components, but you also have tutorials and utilities that let you create your own components and import them into the Mashup Builder. The possibilities are endless here for custom content, so let’s look at what’s inside.   The SDK guide has a quick outline of some pre-requisites you should know about as you enter custom web development with ThingWorx. Things like knowledge of Polymer 3, downloading common tools like NPM and Gulp CLI, Aurelia, etc. Much of this info is also included in markdown documents within the SDK files, but the SDK web content makes it easier to follow and search.   From there, the guide walks you through more setup of your SDK directories, NPM install of PTC components, and basics around dependencies, styling, and demo pages. Each PTC-developed web component is also available in the SDK pages as well with more information on what they offer and their basic designs. This is useful if you would like to reference the PTC components as imports into your own web component. This technique is very useful for re-use and upgrade safety when developing custom components on top of ThingWorx. Sample overview pages in the SDK for ptcs-chart The SDK also includes a getting started tutorial and a sample Polymer component and a widget called simple-el , which are helpful as you want to reference during development and familiarizing yourself with concepts. The component is functional and offers a theme dropdown so you can see how the theming engine and events work. Sample Polymer component included in the SDK called simple-elOnce you have created your web component, there is also a new utility called mub, which scans your component project and wraps it in a shell for the Mashup Builder. If you run the mub utility on your component, you’ll find it produces a zip file with the relevant design and runtime wrappers for the mashup environment already mapped to your component. You can also use it to define properties for your new component in the mashup environment, include custom code for defining the widgets at design and runtime behaviors, and to add icons, categories and other standard platform features. Running the mub utility on a web component project Once you have run the utility, you just import the artifact into a ThingWorx platform and it will be available for your application developers to use in their mashups as a widget. Again, how it appears in the design experience, what properties are exposed, how it responds to platform binding and theming events are all customizable in the SDK. Sample Polymer Component wrapped as a widget for use in a Mashup Once you get the hang of things with the sample code and understand the ins and outs, you can then use those same patterns to develop your own content! These are the same techniques that the PTC R&D team uses when they make each of the new widgets that you see in our product, like the 9.0 charts! Uber cool stuff!   Like what you see? Have a question? Drop us a line in the comments!   Stay connected! Kaya    

    Hi, everyone!   In previous tech tips, I’ve introduced the ThingWorx 9.0 active-active clustering feature and provided architectural details and configurations. If you haven’t already, I recommend you check them out to learn more about how active-active clustering enables higher availability for ThingWorx: 9.0 Sneak Peek: Active-Active Clustering for ThingWorx 9.0 Sneak Peek: ThingWorx Architecture for Active-Active Clustering 9.0 Sneak Peek: Flexible Deployments of Active-Active Clustering for ThingWorx “ThingWorx on Air” Ep. 08: FAQs: ThingWorx Active-Active Clustering for Higher Availability   Today, I’ll provide more details around the load balancer in the active-active clustering architecture, some of its requirements, and a few configuration examples. Ready? Here we go! Here are the top four FAQs around the load balancer that will help you maximize your use of active-active clustering.   What do you mean by load balancing? Load balancing is the process of distributing network traffic across multiple servers. An algorithm employed by the load balancer or a proxy, determines how the traffic is distrusted. Round robin, fastest response, and least established connections are some of the most common methods of load balancing and provide different benefits, but all fundamentally ensure no single server bears too much demand. By spreading the traffic, load balancing improves application responsiveness. It also increases availability of applications and websites for users. Modern applications cannot run without load balancers. In general load balancers can run as hardware appliances or as software-defined. Hardware appliances often run proprietary software optimized to run on custom processors. As traffic increases, the vendor simply adds more load balancing appliances to handle the volume. Software defined load balancers usually run on less-expensive, standard Intel x86 hardware. Installing the software in cloud environments like Azure VMs or AWS EC2 eliminates the need for a physical appliance.   Following the seven-layer Open System Interconnection (OSI) model, load balancing occurs between layers four to seven (L4-Transport, L5-Session, L6-Presentation and L7-Application), whereas network firewalls are at levels one to three (L1-Physical Wiring, L2-Data Link and L3-Network). Load balancers have a various capabilities, which include: L4 — directs traffic based on data from network and transport layer protocols, such as IP address and TCP port. L7 — adds content switching to load balancing. This allows routing decisions based on attributes like HTTP header, uniform resource identifier, SSL session ID and HTML form data. GSLB — Global Server Load Balancing extends L4 and L7 capabilities to servers in different geographic locations. More enterprises are seeking to deploy cloud-native applications in data centers and public clouds. This is leading to significant changes in the capability of load balancers. What is a load balancer’s role in the ThingWorx Active-Active Clustering setup? As is true of any load balancer, the load balancer required in the ThingWorx Foundation active-active clustering architecture is responsible for distributing incoming traffic across the nodes within the cluster.   In the Active-Active Clustering architecture for ThingWorx, the load balancer distributes the traffic using a round-robin method. Please note that there are a several algorithms that provide load balancing techniques and this article is a good read for further understanding of it. A round-robin method rotates servers by directing traffic to the first available server and then moves that server to the bottom of the queue.   In ThingWorx clustering setup, while both WebSocket and HTTP incoming traffic are handled in a round-robin manner, they are routed differently by the load balancer.   HTTP traffic is directly distributed amongst the ThingWorx Foundation Servers within the cluster. Sticky sessions are used for the HTTP sessions—sticky via cookie, so individual users are tied directly to a single server node and see all of their changes instantaneously.   WebSocket traffic is distributed across the and is balanced via source IP to ensure each request from a device goes through the same connection server. From the ThingWorx Connection Server, the device traffic is distributed amongst the underlying ThingWorx Foundation Servers, not requiring another load balancer between the ThingWorx Connection Servers and ThingWorx Foundation Servers.   Please note that the WebSocket traffic load does not necessarily get distributed evenly nor do the incoming requests due to stickiness. For example: 2 users connect HTTP, one sends 100 requests and the other sends 2. Since they are sticky, it is not distributed evenly. 2 devices connect to a ThingWorx Connection Server. 1 is a gateway for 100 other devices, all requests fthe gateway go to the same connection server. The Connection Server does a round-robin to the underlying Foundation Servers so that the load would be better distributed across, but the load balancer is sticky to a ThingWorx Connection Server.     Which load balancer can I choose for setting ThingWorx in an Active-Active Cluster mode? ThingWorx active-active clustering is pretty much load balancer agnostic, meaning if the load balancer of your choosing that you might be using in your IT center meets the requirements, it can be utilized within the active-active clustering architecture. The load balancer is required to support the following features: Based on Layer-7 architecture Supports HTTP and WebSocket traffic Ability to support sticky sessions for  traffic and/or IP based stickiness. IP based means all traffic from a specific IP will be routed to the same server (this can be a problem with gateway type scenarios). Sticky sessions are based on a cookie, sessions are routed to same server based on cookie. Different users same IP could route to different machines. Health checking on server endpoints. (optional) It can manage SSL termination and SSL internal endpoints. Supports Path based routing. This is the ability to route to specific backends based on the URL or part of the URL. By default, all routes should go to the platform servers, but the following routes should go to the connection server: /Thingworx/WS /Thingworx/WSTunnelServer /Thingworx/WSTunnelClient /Thingworx/VWS All servers should be setup to only be part of load balancing based on their health configuration.  When configuring health check frequency, they should be run at a rate based on the tolerance for bad requests to be processed. Thingworx Foundation has a /health and /ready endpoint.   The /Thingworx/ready endpoint should be used for the load balancer.  It will return a 200 when the server is ready to receive traffic.  Connection Server checks health requests on a specific port and will return 200 when healthy. What are some of the compatible load balancers that I can use? While you can use any load balancer that satisfies the above request and meets your IT standards, below are some of the third-party load balancers that provide the features that are required of the active-active clustering architecture: HAProxy - HAProxy is a free, open source software that provides a high availability load balancer and proxy server for TCP and HTTP-based applications that spreads requests across multiple servers. It is very powerful and supports monitoring capabilities out of the box. PTC tests the clustering architecture using HA Proxy and provides a reference document for the same through the ThingWorx Foundation help center docs. Please note that it runs only on Linux environments. For a quick reference example of how to set up an HAProxy load balancer, see our Help Center here. NGINX - NGINX is an HTTP and reverse proxy server, a mail proxy server, and a generic TCP/UDP proxy serve. NGINX provides proxy capabilities as well as web server options. Some features like sticky sessions, advanced monitoring are not available in the opensource version and require you upgrade to NGINX Plus.  If you’re a Windows shop or already use NGINX Plus in your IT, then you may choose this load balancer offering.  However, please note that PTC doesn’t provide any official configuration steps of setting it up through our Help Center documentation. For a quick reference example of how to set up an NGNIX load balancer, see our Help Center here. AWS Application Load Balancer - Application Load Balancer (ALB) is best suited for load balancing of HTTP and HTTPS traffic and provides advanced request routing targeted at the underlying ThingWorx applications. Operating at the individual request level (Layer 7), Application Load Balancer routes traffic to targets within Amazon Virtual Private Cloud (Amazon VPC) based on the content of the request. If you’re running ThingWorx deployments on AWS, then you may choose to use AWS-offered managed load balancing services. F5: F5 Networks through its BIG-IP Local Traffic Manager solution provides advance load balancing techniques such as a full proxy where you can inspect, manage, and report on application traffic entering and exiting your network with additional features around SSL and performance optimization. Load balancers are another area where ThingWorx allows for flexibility and extensibility by enabling you to use the load balancer of your choosing that you’re most comfortable with or that best suits your needs (provided it meets the criteria above). You can also configure SSL or TLS for HAProxy when using ThingWorx HA clustering for end-to-end security. I hope this tech tip helped you develop a deeper understanding of how active-active clustering leverages load balancers to further increase your performance and thus availability and machine uptime, among many others.   If you’re not already on 9.0 and using active-active clustering, be sure to upgrade!   Stay connected, Kaya  

Hello!   “ThingWorx on Air” Episode 9 is now available! Grab your headphones and listen to Neal, an Azure subject matter expert, and Janie, a PM focused on Azure functionality, introduce a new integration we’re working on between Kepware, Azure IoT Edge, Azure IoT Hub and ThingWorx.   Discover how you’ll be able to leverage and model OPC UA data directly in the Thing Model, how you’ll be able to connect just about any OPC UA device through the Azure stack and to the Cloud, and so much more. We can’t wait to continue to extend ThingWorx functionality to support industry standards like the OPC UA protocols.   Are you excited? Wish you could get your hands on this functionality early? You can! Reach out to Janie at jpascoe@ptc.com to learn how you can become involved in an exclusive OPC UA & ThingWorx preview program.   Enjoy the episode and let me know what you think below!   Stay connected, Kaya

  Hello, IIoT Developers!   9.0 is out—let’s dive right into what’s new with Composer and Mashup Builder. (If you haven’t already checked out what’s new in 9.0 with active-active clustering, be sure to check out this tech tip.) We have a lot of new functionality that we can’t wait for you to start using, so without further ado, let’s begin!   Mashup Builder   In 9.0, we continue to make great advancements to our Mashup Builder and visualization toolset. We’re all about productive developers building the coolest IIoT apps! Mashup in 9.0 with new Line Chart widgets!   Undo/Redo   Ever spent a good half hour arranging a layout, making some data bindings, adding some styles, and once you view the Mashup, you decide you aren’t quite happy with your last few tweaks? The panic sets in when you forget exactly what you changed, and you don’t want to lose all of your edits. What is a developer to do? In older versions of ThingWorx, you might cancel without saving your edits or you might try to surgically get back to a good state. Either way, you were not a happy developer.   ThingWorx 9.0 will make you happy again. All actions in the Mashup are now tracked by an undo/redo buffer. Buttons are now available in the toolbar to help you revert actions. An action history drop-down is also available if you want to undo or redo a few jumps at once. Sometimes, it’s the little things!   Undo and Redo actions now available in the Mashup Builder.   Mobile Settings   For a few releases now, we’ve been upgrading our visualization toolset and examining ways we can be better for desktop and mobile experiences. It starts with our latest layout engine/editor introduced in 8.4 and with new Polymer-based, responsiveness “designed-in” web components introduced in 8.4, 8.5, and 9.0. For the more adventurous folks out there, you can also use Custom CSS to do media queries and influence your layouts based on the viewport settings. There are also custom resolutions and screen orientations available in the Mashup Builder toolbar itself so you can view your content in design mode with each of those targets in mind.   In 9.0, we now have introduced a new Mobile Settings configuration editor on the Mashup. This allows you to define for mobile browsers your scaling and width as well as your height and zoom settings. There are even iOS-specific settings for shortcuts and the status bar.  Mobile Settings Editor and iPhone view of a 9.0 Mashup.   New Configure Bindings Dialog   The heart of any application is the data, and how it is leveraged in the UI. For Mashups, there many good ways to do that with our drag-and-drop functionality or our Bindings panel. But in 9.0, we have completely revamped the Configure Bindings Dialog. You’ll quickly notice when you open the new dialog that it has a more usable interface with more screen real estate to explore services, properties, sources and targets. There is now a good separation between the Widgets, Data and Function sources, which makes things easier to locate and build. You’ll also see, if you’ve made bindings already, the complete map of bindings for your context. New search enhancements and target bindings chip-based filters are also now added.   New Configure Bindings Dialog Another cool feature is that the bindings graph in the dialog will also show you any circular references you may have inadvertently created. If you can see in the diagram below, the red circle icon with a number 1 inside of it—this is almost always a bug, so we may as well tell you about it! New Circular references checking! New Web Components   If you look at almost any IIoT application, you’re almost sure to see a chart. IIoT decisions are always centered around looking at telemetry and KPIs at specific moments of time, events, history, and future projections. ThingWorx has new charts in 9.0 for Line, Bar, and Schedule. They look sharp, they are powerful, and are a true upgrade over the former ThingWorx charts.   Here are some highlights. All are based on D3 framework and follow the PTC Design System. The Line chart also supports sub types of Run, Step, Area, Streamgraph and Scatter plot. The Bar chart also supports a column-based view. The Schedule chart is a great way to visualize downtime events, production orders, machine states, or device alarms. All charts feature responsive layout, advanced performance and data sampling, tooltips, multiple series support, multiple orientations for legends and axis labels, and plenty of styling and data configurations. They also all have great zooming capability for larger data sets including horizontal and vertical pan, drag/lasso zoom, interval controls, range zoom and zoom slider controls. Line Charts with filters, zoom sliders, and markers   Bar Charts with zoom sliders, horizontal and vertical orientations, and configurable legends   Schedule Chart with drilldown and hover tooltips Other Coolness   The team was busy with these highlighted features, but there is so much more in 9.0! For Mashup, we also added: Improved tooltip and icon hover support for all web component-based widgets Accessibility improvements for keyboard navigation and focus New category filters for widget property configuration editors New data tools panel New context menu options New theming options for layout containers Composer For application development outside of the Mashup area, you’ll also notice some new changes in the Composer tool. One of our favorites is the new navigation panels. If you’ve been with ThingWorx for a few releases, you’ve seen many redesigns and updates to the Composer interface. We are constantly evaluating and testing this interface’s design with users to make it a highly productive and intuitive environment. You’ll now see much more horizontal real estate in the Composer because we’ve moved the top header bar into a new left-hand navigation. We’ve also improved the grid resizing in the entity and other list views in the interface to work better with larger result sets. New Composer Layout with updated left-hand navigation One more bonus feature to highlight! We now have quick copy buttons in common places in the interface where you might want to copy entity names or application keys. Just click and that text is in your clipboard. Very handy for searching or making bindings!   Quick copy buttons on entity names     As you can see, plenty of awesome new features and upgrades in the ThingWorx 9.0 application development tools. We also have a brand-new visual SDK available in the 9.0 release so that you can make your own widgets with Polymer and import them into the Mashup Builder. Stay tuned for another Ask Kaya tech tip soon on the SDK.   Like what you see? Have a question? Drop us a line in the comments!   Stay Connected! Kaya  

  It’s here! It’s happening! ThingWorx 9.0 released today!   Unleash the Power of Now and leverage exciting new features like: Improved performance and higher availability via active-active clustering Faster, more streamlined development with: New widgets like line, bar & schedule charts Undo & redo functionality in Mashup Builder (look out for an upcoming Ask Kaya tech tip) New Mashup mobile settings Simpler management of entities and applications: Improved auditing scale & usability Ability to group entities via Thing Groups Ability to deploy apps built prior to 8.5 with Solution Central And more—like: Confidence model training Delegated authorization for Flow [Navigate] Component-based app development for custom production use apps (upgrade-safe) And even more—the list goes on and on. Check out the full list of new functionality in the 9.0 release notes and discover our What’s New page.   Access 9.0 under “ThingWorx Foundation” on the PTC Downloads Page and unleash its power today! As you get started, check out the ThingWorx Help Center for guidance.   Enjoy 9.0 and let us know what you think below! Kaya

  Hello everyone!   We’re back with Episode 08 of ThingWorx on Air! In this episode, I sit down with Ryan Servais, one of our High Availability (HA) experts on the ThingWorx product management team. We continue our HA discussion from previous Ask Kaya tech tips and cover some frequently asked questions like what are the benefits of active-active clustering? How does active-active clustering enable horizontal scale? How can I get started? Brand-new to active-active clustering? Check out these tech tips to start: 9.0 Sneak Peek: Active-Active Clustering for ThingWorx 9.0 Sneak Peek: ThingWorx Architecture for Active-Active Clustering 9.0 Sneak Peek: Flexible Deployments of Active-Active Clustering for ThingWorx Click here to listen to how active-active clustering can help you in a variety of scenarios: If you have a request overflow in production and your servers are slowing down, try out active-active clustering! If your IT admin keeps delaying replacing the network card on your HPE rack server and you keep losing connections, check out the power of active-active clustering! If your team is challenged to provision 1000s of additional assets into your system and you’re worried one server can’t handle it, use active-active clustering for horizontal scale! Finally, if you haven’t already, check out Ryan’s LiveWorx session with Senior IoT Product Manager Ayush Tiwari where they break down availability into its core components and explain how you can leverage active-active clustering to achieve key benefits like reduced downtime, increased cost savings, and more.   Enjoy!   Stay connected, Kaya

Hiya,   I recently prepared a short demo which shows how to onboard and use Azure IoT devices in ThingWorx and added some usability tips and tricks to help others who might struggle with some of the things that I did.     The good news... I recorded and posted it to YouTube here.   •Connect Azure IoT Hub with ThingWorx (to be updated soon for 9.0 release) •Using the Azure IoT Dev Kit with ThingWorx •Getting the Azure IoT Hub Connector Up and Running (V3/8.5)   Enjoy, and don't hesitate to comment with your own tips and feedback.   Cheers,   Greg

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

Hi Community,   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. ThingWorx Azure IoT Hub Connector ThingWorx MQTT Extension ThingWorx Kepware Server 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.   Regards,   Greg Eva

  Ever dreamed of participating in the design of the latest ThingWorx features? Now’s your chance! Join the UX Lab in usability and research sessions to help inform the design of your favorite ThingWorx features from the Edge to Kepware to remote monitoring to Solution Central and more!   For those of you newer to PTC, the UX Lab is an opportunity to see early views of product mockups, wireframes, etc. to provide your direct feedback; the UX Lab is part of LiveWorx, our definitive event for digital transformation, and this year both are virtual!   Click here to influence the design of Edge, Kepware, remote monitoring, Solution Central, and so much more!   Reach out with any questions!   Stay connected, Kaya

  Hi, everyone!   In previous tech tips, we’ve introduced 9.0’s biggest feature, active-active clustering, and covered some of the main architectural components. Today, I’ll cover some other architectural configurations and the flexibility that active-active clustering provides to meet your IoT deployment needs.   Deployment Flexibility With Active-Active Clustering, ThingWorx allows you to achieve the highest availability of your IIoT system while still retaining the high degree of deployment flexibility that ThingWorx is known for.   It’s important to emphasize flexibility not only in where you deploy ThingWorx, but also in how  you deploy it. Flexibility is embedded in the ThingWorx architecture to suit your deployment needs. Let’s look at two interesting options.   Cost-Efficient Deployment The first example is deploying ThingWorx in a cost-efficient architecture for smaller or cost-sensitive deployments. Instead of each component on its own separate VM or box, ThingWorx Connection Server, ThingWorx Foundation Server, ZooKeeper, and Ignite are all installed on the same box.   With three boxes in parallel, the system still achieves high availability while reducing deployment costs by minimizing the number of servers utilized. A minimum of three servers is needed to achieve an odd number of instances required by ZooKeeper while still providing redundancy.   In order to optimize for cost while still providing high availability, there are a few factors to consider with this deployment. In this configuration, Ignite is run within the same JVM as ThingWorx Foundation, rather than on a different server. While this does reduce the overall footprint, Ignite will consume additional memory, sharing the resources with the ThingWorx Foundation platform. Since ThingWorx Connection Server is run on the same VM as ThingWorx Foundation Server, this introduces socket limitations, which can restrict the maximum number of connected devices.     In short, the example above illustrates how, while being in an active-active clustered environment, you still retain the deployment flexibility to optimize for your deployment needs. In this scenario, the architecture is optimized for a leaner, more cost-effective deployment at the expense of numbers of connections and memory.   Now, let’s walk through some common use cases where ThingWorx is deployed on premise on VMs or baremetal to support use cases that require a balance of availability and scalability at an affordable cost. A few of these examples include: On-premise deployment of ThingWorx Foundation to support a dedicated factory production line on a plant floor to improve its connected manufacturing operations. VM based on-site deployment of ThingWorx Foundation to support IoT applications for a Smart Building scenario. Smart Ship deployments managing key ship operations where ThingWorx is deployed on a ship and sends data intermittently to private data centers running ThingWorx on shore through a satellite network leveraging ThingWorx federation technology. A failover-proof redundant setup required to capture key service metrics for medical equipment for predictive failures and maintenance where ThingWorx is deployed in hospital premises. OEM Deployment with Common Components The second example covers how active-active clustering architectural components can be shared across multiple clusters to reduce the cost and complexity of deployment. This can include scenarios where a large deployment spans multiple sites, geographies or end customers.   In this deployment, there are two ThingWorx clusters that share a common ZooKeeper cluster and database layer. Within each cluster, both the Connection Server and ThingWorx Foundation with Ignite running as embedded are deployed on a VM.   For the shared components, proper separation measures must be taken to ensure security. For ZooKeeper, separate namespaces and authentication from the clients are required. For the shared database layer, each cluster must have a unique schema, a separate shared file system and separate user credentials with database-level isolation. Please note that with a large shared database across tenants, rather than a dedicated database for each tenant of HA cluster, there is a risk of impacting performance and availability of other tenants due to issues caused by one of the shared ones.     This architecture is optimized for a larger deployment comprised of multiple ThingWorx clusters requiring separation between the clusters, while still allowing the provider to share a common infrastructure for cost reduction.   Again, let’s walk through another few common use cases, including: A ThingWorx OEM hosting multiple ThingWorx Foundation instances in their managed data center or public cloud to offer applications with further customization abilities to their end users. In this case, an OEM vendor can offer multiple ThingWorx clusters in active-active cluster mode with shared pieces of infrastructure across multiple tenants. A ThingWorx enterprise customer looking to build and host different ThingWorx-based applications in their IT data center where each application is powered by an individual active-active cluster satisfying specific digital transformation use cases across the enterprise value chain, including those related to engineering, product, sales, marketing, supply chain, partners, service and support. A ThingWorx factory customer looking to host multiple ThingWorx applications from their main regional factory IT data center to cater to the IoT needs of different factories located in surrounding geographic regions. In this case, a customer could dedicate one HA cluster to each factory to enable that factory/site to power multiple IoT applications efficiently.   These two configurations are some of the lesser known—yet equally powerful—deployments of this new architecture. Again, flexibility of our deployment architecture is one of the key superpowers of the ThingWorx platform. And, the active-active fun doesn’t stop there! Be on the lookout for an upcoming LiveWorx session titled Active-Active Clustering with ThingWorx 9.0  (Session ID: IP1117B), future tech tips like this one, and, of course, the GA release of ThingWorx 9.0 (targeted for June 2020) where you can take advantage of this new functionality!   Let us know what you think in the comments!   Stay connected, Kaya      

  Hi everyone,   In anticipation of ThingWorx 9.0’s biggest feature, active-active clustering, we’d like to provide an architectural overview of a sample active-active configuration and its underlying components. If you haven’t already seen it, we invite you to read our previous Community tech tip, where we introduce the concept of active-active clustering for ThingWorx Foundation, which enables you to: significantly reduce unplanned downtime for your mission-critical services and apps support horizontal scalability of the ThingWorx Server where you can scale your services up and down based on your requirements easily run, package, deploy, and operate advanced apps and services with the help of intuitive browser-based navigation, interactive monitoring and debugging tools, and more deploy anywhere - public cloud, private datacenter, on-premise, hybrid, or even locally on your laptop with deep optimizations for Azure Now, before we go too deep, we’d like to let you know that you can continue to seamlessly upgrade from previous versions of ThingWorx releases to upcoming ThingWorx 9.0  releases. Previously, you could deploy ThingWorx Foundation in a “single server” mode, and, for a high availability in “active-passive cluster” mode (see here for details). In the ThingWorx 9.0 release and onwards, you’ll be able to continue to deploy ThingWorx Foundation in a “single server” mode and for high availability scenarios via our new “active-active cluster” mode. Please note that active-passive clustering configuration will no longer be supported in ThingWorx 9.0 or onwards.   Let’s start with a quick recap on how the ThingWorx Foundation 9.0 release would look like in single server deployment.   ThingWorx 9.0 Deployed in a "Single-Server" Architecture Below is a high-level diagram depicting the main architectural layers and components of ThingWorx Foundation deployed in a single server mode.   Deployment Components Below is a brief summary of all major architectural components and their purpose in the deployment architecture:   The Client Layer This layer is comprised of everything that connects with, sends data to, and receives content from the ThingWorx platform. It be broken down into two groups: Devices/Things: Things, devices, agents, and other assets. Users/Clients: People and the respective products (primarily web browsers) they use to access ThingWorx.   The Application Layer This layer is where ThingWorx Foundation and other applications deployed with ThingWorx Foundation reside, such as ThingWorx Analytics, ThingWorx Connection Server, ThingWorx Azure IoT Hub Connector and others. This layer provides connectivity to the client layer, performs authentication and authorization checks, ingests/processes/analyzes content, and reacts to conditions by sending alerts. For a specific ThingWorx Foundation deployment that needs basic device data ingestion, processing and storage, you can setup only ThingWorx Foundation server. In some cases, with large number of device connections, you may want to setup ThingWorx Connection Server with ThingWorx Foundation in a single server for further scalable connectivity. ThingWorx Foundation: ThingWorx Foundation is a java-based application that serves as a rapid, model-based application development platform. Shared File Storage: Shared Disk space to contain ThingWorx Storage repositories, store and archive log files accessed by all ThingWorx Foundation servers. A NAS file storage, AWS Elastic File System, or Azure Files and others could be used for this purpose.   The Data Layer ThingWorx Foundation includes several persistence provider implementations that enable you to choose a database option that best fits your use case. A persistence provider enables the connection to a data store and the ability to perform a CRUD operation on that data. See here for more information. Currently, there are two basic variations of persistence providers: Model Provider – Responsible for ThingWorx model metadata and system data. Data Provider – Responsible for runtime data ingested against the model elements, including streams, value streams, data tables, etc. ThingWorx supports H2 (in-memory Database), PostgreSQL, MS SQL Server and AzureSQL as both model and data providers, and InfluxDB as only a data provider. Please see here for model and data best practices.   ThingWorx 9.0 Deployed in an Active-Active Clustering Reference Architecture Below is a reference architecture diagram for ThingWorx 9.0 with multiple ThingWorx Foundation servers configured in an active-active cluster deployment. Please note that this is only one reference example of how ThingWorx 9.0 can be deployed in an active-active clustered environment. There could be other architectural configurations dependent upon the needs of the specific deployment. Deployment Components Once you have developed an understanding of the basic architectural components in a single server mode, below are the additional components required to run ThingWorx in active-active cluster mode.   The Client Layer This will be similar to what has been mentioned in the above single server configuration.   The Application Layer In this layer, if you’re familiar with ThingWorx active-passive cluster configuration, then you may be aware of most of the components used below—with the exception of a new component: Apache Ignite that provides Distributed Caching for the horizontally scalable ThingWorx Foundation servers. Load Balancer: A third-party device that receives network traffic and distributes requests among available servers. In active-active cluster configuration, the load balancer is used to direct WebSocket-based traffic to the ThingWorx Connection Servers while user requests (http/https) traffic is directly distributed to the ThingWorx Foundation servers. Users can continue to use a load balancer with ThingWorx 9.0 that they might already be using for their existing active-passive or single server deployments with ThingWorx 8.X or previous releases.  Some example load balancers include, but are not limited to: HAProxy, Azure Application Gateway, and AWS Application Load Balancer. ThingWorx Connection Services: These services handle all messages routing to and from devices, providing scalable connectivity to the ThingWorx Foundation Server. With the ThingWorx 9.0 release, ThingWorx Connection Services have been upgraded with many additional features to support active-active clustering of the ThingWorx Foundation servers, where now they route all WebSocket traffic in a round robin fashion to the connected ThingWorx Foundation servers. Depending upon the various use cases, one could use multiple ThingWorx Connection Services available, such as ThingWorx Connection Server, ThingWorx Azure IoT Hub Connector, and ThingWorx Protocol Adapter Toolkit. Please see here for further details. Please note that for ThingWorx 9.0 releases, ThingWorx Connection Server would be required in an active-active configuration to support all the WebSocket-based traffic routing, including egress of files and device messages from multiple ThingWorx Foundation servers back to the devices, and it would also serve as WebSocket communication from ThingWorx Mashup-based applications to ThingWorx Composer. ThingWorx Foundation: With ThingWorx 9.0 and onwards, you can set up ThingWorx Foundation servers in an N-active-active cluster model to provide higher availability to your applications and horizontally scale the Foundation server nodes up and down based on your scalability needs. Apache Zookeeper: Apache ZooKeeper is a centralized service for maintaining configuration information and naming as well as providing distributed synchronization and group services. It is a coordination service for distributed applications that enables synchronization across a cluster. Specific to ThingWorx, ZooKeeper is used for distributed locking, selecting a singleton server during the server initialization, service discovery for Apache Ignite, allowing it to find instances of ThingWorx Foundation servers. Apache Ignite: This offers a distributed cache for the active-active cluster setup. It is used by ThingWorx Foundation Servers to share state. It may be embedded with each ThingWorx instance or can be run as a standalone cluster for larger scale. In this configuration, Ignite is set up in a standalone cluster but can be run embedded within the ThingWorx Foundation. Running Ignite in a standalone cluster is more ideal for larger scale, as it supports higher vertical scale of memory in the deployment setup.   The Data Layer ThingWorx is largely database agnostic. You can continue to use officially supported persistence providers that you may already be using in your existing deployments based off of ThingWorx 8.X or previous releases. Please look out for an upcoming ThingWorx update as well as enhanced installation documents to help with your upgrade and migration questions with the general availability of ThingWorx 9.0. Please note that this diagram does not make the distinction between model and data providers; depending on your data ingestion needs, separate model and data providers can be used. As a reminder, all databases should be deployed in a high-availability configuration to help eliminate any single point of failure.   In closing, we can't wait to launch active-active clustering in 9.0 to help you: dramatically further reduce application downtime scale your deployments and more efficiently manage your apps, regardless of where they’re deployed   If you have any questions about active-active clustering or its architecture, please do not hesitate to reach out!   Stay connected! Kaya

  Hi, everyone!   We’re actively working towards the ThingWorx 9.0 release and we’re ready to provide a sneak peek into the biggest feature of 9.0: Active-Active Clustering for High Availability configuration.   You may be wondering: doesn’t ThingWorx already offer High Availability?   Yes, ThingWorx already supports a High Availability configuration. Previous versions of ThingWorx, such as ThingWorx 8.X version releases, support Active-Passive configuration, where one “active” ThingWorx server performs all processing and maintains the live connections to other systems such as databases and connected assets. Meanwhile, in parallel, there is a second “passive” ThingWorx server that is a mirror image and regularly updated with data but does not maintain active connections to any of the other systems. If the “active” ThingWorx server fails, the “passive” ThingWorx server is made the primary server, but this can take a few minutes to establish connections to the other systems.   So, how is ThingWorx Active-Active different?   Active-Active configuration differs from Active-Passive in that all the ThingWorx servers in the cluster are “active.” Not only is data mirrored across all ThingWorx servers, but all of the servers, instead of only one, maintain live connections with the other systems. This way, if any of the ThingWorx servers fail, the other ThingWorx servers take over instantaneously with no recovery time.   Since all ThingWorx servers are active, they are processing in parallel and, as a result, the cluster can process more data than that of a single server or a cluster with an Active-Passive configuration. Simply put, multiple servers working together outperform a single server. This allows customers to scale their deployment by simply adding more ThingWorx servers to the cluster (horizontally scaling), which does not have the same limitations of scale that is achieved by increasing the performance of the server itself.   What does that mean for me? Higher Availability - You can avoid single points of failure and configure the ThingWorx Foundation platform in an Active-Active cluster mode to achieve the highest availability for your IIoT systems and applications. Increased Scalability - Now, you can horizontally scale from one to many ThingWorx servers to easily manage large amounts of your IIoT data at scale more smoothly than ever before.   Stay tuned! We’ll be posting more information on Active-Active Clustering—how it's achieved in ThingWorx, architectural component overviews, and what it means for your ThingWorx deployment!   In the meantime, we're running the Active-Active Clustering Beta Program. Interested in participating? Reach out to Ryan Servais (rservais@ptc.com) or Ayush Tiwari (atiwari@ptc.com) to learn more about participation!   Stay connected! Kaya

  Hello, everyone! Discover how we embed security throughout the entire lifecycle of the ThingWorx platform in our latest “ThingWorx on Air” episode!   Hear Walter walk through how the ThingWorx platform is secured from end to end. Walter breaks it down into three simple parts: secure design, secure coding practices and continuous security improvements via our maintenance releases.   Listen to Episode 07 to hear the steps we’re taking in each of these areas and how security is at the forefront of what we do.   Finally, Walter mentions the Secure Deployment Hub, our brand-new set of resources to help you securely deploy your ThingWorx apps. Check out my last tech tip to learn more.   As always, stay connected, Kaya

  Whether your ThingWorx instances are deployed on premise, in the cloud or a hybrid of the two, I’d like you to imagine: You have a super cool app. You want to deploy it securely. You’re not a security expert. What do you do? How do you know how to securely deploy your app? Where do you go for security best practices? Introducing the new ThingWox Secure Deployment Hub!   The ThingWorx Secure Deployment Hub is a new section of our support site that will introduce you to the ThingWorx security landscape and direct you to security resources pertaining to the Edge, the platform and beyond.   From permissions and provisioning, to subsystems and SSO, the hub is packed with our recommendations and best practices for you to deploy your app in a secure fashion.   Happy deploying! Kaya

  Happy New Year, everyone! New year, same mission. As we continue to improve ThingWorx, we remain committed to taking into account what you, our users, are saying. What are you using ThingWorx for? What do you want it to do? What additional tools are you looking for?   To hear from you directly, our PM team has created a quick survey to understand your identity management and SaaS strategies a little better.   Complete the survey below for a chance to win a free Solution Central t-shirt! Loading…   Thanks in advance! At the end of the survey, all respondents will receive a link to check out the latest in our ThingWorx 8.5 release. One lucky winner will receive the Solution Central t-shirt.   Thanks for sharing your info! We’ll be sure to study it as we continue to develop our robust IoT solutions platform.   Stay connected in the New Year! Kaya

  Whether you’re new to ThingWorx or you’re a seasoned user, understanding the Thing Model is key to accelerating your IoT development. Today, I’ll dive into what ThingShapes, ThingTemplates and Things are and how to use them to accelerate development.   Before I dive into the definitions of these concepts, let’s first consider the wide array of machines that exist out there in world. The variety is huge—there’s MRI machines, 3D printers, laser cutters, CNC machines, tractors, and so much more.   At their core, all MRI machines share similar properties and capabilities—they have a name, a physical location, a magnetic strength, a radio frequency current, and the ability to visually display what’s going on inside the human body. There are, however, different types of MRI machines, and, while they are fundamentally the same type of machine, there are notable differences as well. When creating our IoT app, it’s important that we have a way to model these differences so that we can cascade changes across entities and reduce development time.   Let’s walk through an example using MRI machines. Consider the various MRI machines that exist today; there’s the traditional closed MRI machine, the open MRI machine and the standing/sitting MRI machine.   To represent the fundamental properties (i.e., characteristics or readings) and services (i.e., functionality) of a generic MRI machine—name, location, magnetic strength, etc.—we’ll create a ThingTemplate. The ThingTemplate is the general definition/representation of the real-world physical thing (i.e. the MRI machine) that is being modeled. You can think of a ThingTemplate as a blueprint of what you’re modeling. A ThingTemplate defines what a Thing is; if you’re familiar with object-oriented programming, a ThingTemplate is similar to the concept of inheritance; it defines a “is a” relationship. Using our ThingTemplate, we’re able to create multiple instances of the template that inherit the properties and services from that template. If you have 100 MRI machines in a particular region, rather than updating each one separately, simply updating the template will allow you to propagate these changes.   Let’s say that, of our 100 MRI machines, 40 are traditional closed machines, 30 are open machines and 30 are standing/sitting machines. The traditional machines have a specific diameter of the opening where the patient goes in to lay down and the sitting/standing machine may have a particular height of the seat where the patient sits. Due to the nature of the machines having unique components/parts, the different types of machines have difference maintenance service.   To model each of these “add-on” properties, we’ll want to create a ThingShape. A ThingShape is a representation of particular properties or services that may optionally come in some versions of the machine but not others. The ThingShape is a single feature or piece of the physical thing that’s being modeled. You can think of a ThingShape as a reusable part, or a set of properties/services that comes with some versions, but not all. A ThingShape defines what a Thing has; if you’re familiar with object-oriented programming, a ThingShape is similar to the concept of composition; it defines a “has a” relationship. So, for our MRI example, we could create one ThingShape for the standing MRI and a second ThingShape for the closed MRI. The StandingMRIThingShape would have a property of “SeatHeight” and a service of “StandingMRIMaintenanceService.” The ClosedMRIThingShape would have a property of “opening diameter” and a service of “ClosedMRIMaintenanceService.” Just like a ThingTemplate, the properties and services that make up a ThingShape are also inherited by the instances that use that ThingShape.   Finally, Things. A Thing is simply an instance of a ThingTemplate with (optionally) ThingShapes added for additional unique properties/services.   Let’s say we want to model a single closed MRI machine. We’ll represent the machine as a Thing that inherits from Templates and Shapes. We’ll start with the MRIMachineThingTemplate so that we can create an MRI Machine Thing (i.e., instance).   Since this is a closed MRI machine and has the additional property of opening diameter, we’ll want to make sure we include that property. To do this, we’ll add the ClosedMRIThingShape.   Viola! We now have a digital twin of our closed MRI machine with all the base properties of an MRI machines from our MRIMachineThingTemplate and all the special add-ons of the closed version with our ClosedMRIMachineThingShape.   Here’s a visual recap of what we just modeled.   If you’re looking for even further guidance on how to model your data with the Thing Model, check out the Data Model Introduction guide on the Developer Portal to get started and the Design Your Data Model guide to learn even more.   Happy data modeling!   Stay connected, Kaya  

  Hello, everyone!   With the release of ThingWorx 8.5, we’ve incorporated a lot of new functionality into our manufacturing and service apps. To cover a few, I’ve included the list below. We created a manufacturing common layer extension to bundle all the PTC-offered IoT apps (Operator Advisor, Asset Advisor, Production KPIs and Controls Advisor) into one extension to enable you to use them even more quickly. We added a UI to Operator Advisor to strengthen your development of work instructions. We introduced new shift and crew data models and user interfaces to standardize how to track workers’ shifts and crew availability. We also introduced Flexible KPIs to help you more rapidly develop apps to calculate common metrics. We enhanced the Operator Advisor MPMLink connector to allow users to access navigation criteria for filtering parameters based on required criteria with support for standard processes. We incorporated multiple context supports for assets—like different business units, separating maintenance views from production views or segmenting sites by location—to allow segmentation based on role and responsibility, showing the power of ThingWorx networks and permissions.   Today, I’d like to highlight one of these areas in particular: flexible KPI calculations.   I spoke with one of product managers, Ward (who you may recognize from this post) to learn more about what this new feature does and the value it brings the business. Here’s what he said:   Kaya: Why did we create flexible KPIs? What was the challenge users were facing that led us to create them? Ward: While there is an industry standard for KPIs such as OEE, availability, productivity and quality, many customers choose to customize the calculations slightly and use their own specific versions in their decision-making process or production monitoring.    Kaya: What do the flexible KPIs do? Can you provide an example? Ward: KPIs can now be customized by ThingTemplate; this allows users to calculate KPIs differently for different “classes” of things. Imagine you have a group of CNC machines and a group of pumps. You want to calculate the availability of each group, but the availability calculation for the CNC machines may differ slightly from the same availability calculations for pumps. With our new flexible KPIs, you’re able to customize the availability calculation to make slight tweaks or changes based on differences in machines or devices. So, you can calculate the availability for both your CNC machines and for your pumps using your customized availability calculations. You can also create your own KPIs to calculate metrics like safety incidents or waste.   Kaya: Let’s dive a little deeper there. If I want to create a quality station for my robot with custom KPIs, how exactly would I do that? Ward: Let’s consider OEE. We have an OEE ThingShape applied to our ISA95 physical ThingTemplate. This shape has services to perform the OEE calculation. You’re able to customize the service on this template, so you have the flexibility to change the way you perform OEE calculations. Now, let’s say you want to add a new KPI like mean time between repair (MTBR). To do so, you would create a MTBR ThingShape and add it to the ThingTemplates where you want OEE calculated. Then, you would update the KPI manager service GetKPINames to add your ThingShape to the list of KPIs to be executed each iteration. The SCO apps will then execute your MTBR service along with the other KPIs.   Kaya: What are their use cases? How does they improve the business? Ward: Customers can have their cells roll up OEE based on the worse performing asset and have their operations roll up on a different criterion.  If the customer wants to use a modified OEE on a machine that includes the size of the crew operating it, they can now do so on that one machine, on classes of machines or on all machines.   Kaya: Wow. You were certainly busy with 8.5 with all these new features. Can you tell me what you’re most excited about for 9.0? Ward: I’m most looking forward to High Availability. The ability to have multiple servers in an active-active mode allows me to do more processing in ThingWorx and provide a level of reliability to my customers. (Look out for info on this exciting new functionality in the future!)   Ready to get started using the flexible KPIs yourself? Check out the ThingWorx Apps Customization Guide! While you’re at it, be sure to also check out the other new features in 8.5 listed above!   Reach out with any questions and stay connected! Kaya

 Image Source: https://www.thefire.org/resources/spotlight/     Designed a super cool mashup? Have an innovative IoT app? Are you really proud of how you solved an IoT challenge? Are you using ThingWorx for a unique use case?   If so, we want to hear from you! I’m looking for a few ThingWorx developers that are interested in sharing their work to be showcased on the Ask Kaya blog! (Don’t worry—we can hide your confidential info and only share what you allow us to.) We’d love to highlight what our developers are doing with ThingWorx out in the real world. If you’re interested, comment below or message me directly!   As always, stay connected.  

    We’re back with a ThingWorx 8.5 highlight! Today, we’ll cover brand-new functionality within ThingWorx Flow—the Azure Connector!   Imagine you’re on the regal shores of ThingWorx, trying to reach the plentiful utopia of Azure IoT services and capabilities. How do you get there? Through the new Azure Connector for ThingWorx Flow!   The Azure Connector for ThingWorx Flow is an OOTB connector that enables you to leverage the power and breadth of Azure services directly in ThingWorx applications with ThingWorx Flow. If you have intermittent needs for high-scale processing, for example, the Azure connector can help optimize costs based on when you require a mighty powerful liege and where you only pay for the necessary processing capacity when it is important. Azure Functions are also useful when you want to leverage some special code that was written in a language like Python that you’d like to easily leverage, such as to pre-process information collected from a device.   With the Azure connector, you’re able to: Support execution of logic apps to access a large number of OOTB systems connectors and customer investments in apps. Enable execution of Azure functions wherever elastic scale is needed to cost-effectively support use cases that have intermittent high-scale needs, such as executing an analysis of device sensors leading up to and following a key alert or incident. Enable use of Azure Cognitive Services to easily leverage a rich set of capabilities from simple text to voice or voice to text to computer vision in end-to-end IoT use cases. A few examples include the ability to: Convert the alert text to speech to deliver to an operator to take urgent action. Convert a verbal description of an assembly problem to a textual description in an automatically generated problem report. Use computer vision for a quality check to automatically pass or fail a part based on a visual image and confidence level. Here are a few of the many different services you can leverage with the Azure Connector in ThingWorx Flow: Anomaly Detector Bing Search Computer Vision Custom Vision Execute Function Execute Logic App Face Recognition LUIS Prediction QnA Prediction Speaker Recognition Speech Service Text Analytics Check out this demo video to see an example in action. In the video, you’ll see us: Create an Azure Function app. Create a ThingWorx Flow that triggers from an alert on a ThingWorx thing. Within the flow, you’ll see us consume the alert information and send it to the Azure Function app, and the Azure function app will process and return a response. (view in My Videos)   While simple, this demo shows the ability to connect ThingWorx and Azure together for an incredibly flexible and powerful distributed IoT system.   Finally, if you’re looking for assistance on how to use the new connector, see our Help Center here.   Stay connected and go with the (ThingWorx) Flow! Kaya        

  After months of development, hours of user interviews and countless coffees, ThingWorx Solution Central is here!   I posted a few weeks ago introducing the new cloud solution management portal, but just as a reminder, ThingWorx Solution Central is a brand-new set of cloud services offered to help you more efficiently manage and deploy your solutions—ow ow!   ThingWorx Solution Central automatically identifies and packages up your dependencies so you can slash your time to deploy. Once you develop your solution in ThingWorx (using the Projects feature), ThingWorx Solution Central will then automatically package up all the artifacts and dependencies required for your solution to run, and then you can publish your “package” up to the cloud, where it will be ready to be deployed to your specified environment(s).     Ready to get started? Request access to ThingWorx Solution Central here and you’ll be on your way to easier solution deployments in no time.   And if you happen to run into any trouble, see the ThingWorx Solution Central Help Center.   Happy deploying!   Stay connected, Kaya