IoT & Connectivity Tips

Design and Implement Data Models to Enable Predictive Analytics Learning Path   Design and implement your data model, create logic, and operationalize an analytics model.   NOTE: Complete the following guides in sequential order. The estimated time to complete this learning path is 390 minutes.    Data Model Introduction  Design Your Data Model Part 1 Part 2 Part 3  Data Model Implementation Part 1 Part 2 Part 3  Create Custom Business Logic  Implement Services, Events, and Subscriptions Part 1 Part 2  Build a Predictive Analytics Model  Part 1 Part 2 Operationalize an Analytics Model  Part 1 Part 2  

Getting Started on the ThingWorx Platform Learning Path   Learn hands-on how ThingWorx simplifies the end-to-end process of implementing IoT solutions.   NOTE: Complete the following guides in sequential order. The estimated time to complete this learning path is 210 minutes.   Get Started with ThingWorx for IoT   Part 1 Part 2 Part 3 Part 4 Part 5 Data Model Introduction Configure Permissions Part 1 Part 2 Build a Predictive Analytics Model  Part 1 Part 2

Get Started with ThingWorx for IoT Guide Part 1   Overview   This project will introduce you to the principles of ThingWorx Foundation by creating a working web application. Following the steps in this guide, you will create the building blocks of your first application for the Internet of Things (IoT). You will use ThingWorx Composer to create Thing Templates, which are then used to create Things that model the application domain. A simulator is imported to generate time-series data that is saved to a Value Stream. After modeling the application in ThingWorx Composer, you'll use Mashup Builder to create the web application Graphical User Interface (GUI). No coding is required in modeling the application, or in composing the web GUI that displays dynamically-generated data. NOTE: This guide’s content aligns with ThingWorx 9.3. The estimated time to complete ALL 5 parts of this guide is 30 minutes.      Step 1: Data Model   Model-based design with reusable building blocks makes your applications scalable and flexible. A ThingWorx application is built from Things, each based on a Thing Template that defines the common Properties (characteristics) and Services (behaviors) for a set of entities. Once a Thing Template is created, you can easily instantiate multiple Things without duplicating effort. In this tutorial, we will develop an application for a house including a thermostat, an electrical meter, and a sensor data simulator. We will demonstrate how to capture, store, and visualize data using the ThingWorx Foundation Server.   You will create Thing Shapes that model both a thermostat and an electric meter. You will then create a Thing Template that represents a house based on these shapes and other Properties.   Step 2: Create Thing Shapes Thing Shapes are components that contain Properties and Services. In Java programming terms, they are similar to an interface. In this section, you will build Thing Shapes for an electric meter and a thermostat. Meter Start on the Browse, folder icon tab of ThingWorx Composer. Under the Modeling section of the left-hand navigation panel hover over Thing Shapes, then click the + button.   Type MeterShape in the Name field. NOTE: Thing Shape names are case sensitive   If Project is not already set, choose PTCDefaultProject. Click Save. Add Properties Click Properties and Alerts tab at the top of your shape.   Click + Add. Enter the property name from the first row of the table below into the Name field of the Thing Shape Name Base Type Persistent? Logged? meterID STRING X   currentPower NUMBER   X costPerKWh NUMBER X X currentCost NUMBER     Select the Base Type from the drop-down menu that is listed in the table next to the Property name.   Check Persistent and/or Logged if there is an X in the table row of the Property. NOTE: When Persistent is selected, the property value will be retained when a Thing is restarted. Properties that are not persisted will be reset to the default during a restart. When Logged is selected, every property value change will be automatically logged to a specified Value Stream. Click ✓+ button. TIP: When adding multiple properties at once, click Done and Add after each, once you've entered a Name, selected a Base Type and any other criteria. If adding a single property, click Done. Repeat steps 2 through 6 for each of the properties in the rows of the table. Click the done ✓ Button. You'll see that these Properties have been created for the Meter Thing Shape.   Click Save. Thermostat This time we will use a shortcut to create a Thing Shape. In the top, left of the screen you will find +, click the new entity icon, then select Thing Shape from the list.   TIP: This is a shortcut you can use to create anything you can access from the Home tab in Composer. Type ThermostatShape in the Name field. If Project is not already set, choose PTCDefaultProject. Select the Properties and Alerts tab at the top. Click + Add and create the following properties following the same steps as before: Name Base Type Persistent? Logged? thermostatID STRING X   temperature NUMBER X X setTemperature NUMBER X X message STRING   X Click Save. You'll see that these Properties have been created for the Thermostat Thing Shape.       Step 3: Create Thing Template You can create reusable building blocks called Thing Templates in ThingWorx to maintain scalability and flexibility of your application development. With Thing Templates you define a set of similar objects by specifying the Properties (characteristics) and Services (behaviors) that are common for all the objects. In Java programming terms, a Thing Template is like an abstract class and can be created by extending other Thing Templates. Once a Thing Template is defined and saved in ThingWorx Foundation Server, you can replicate multiple Things to model a complete set without duplicating effort. In this step, you will create a Thing Template that defines properties for a building. This building Template could be used to create multiple Things that each represent a specific home, business, or other building structure. Start on the Browse, folder icon tab on the far left of ThingWorx Composer.   Under the Modeling section of the left-hand navigation panel, hover over Thing Templates and click the + button Type BuildingTemplate in the Name field. NOTE: Thing Template names are case sensitive If Project is not already set, click the + in the Project text box and select the PTCDefaultProject. In the Base Thing Template box, click + to choose GenericThing as the Template.   In the Implemented Shapes field, click the + to select the MeterShape Thing Shape.   Click Save. Add Properties In this step, you will specify the Properties that represent the characteristics of a building. Some Properties like the building location may never change (static), while other properties like power and temperature information may change every few seconds (dynamic). Select the Properties and Alerts tab under Thing Template: BuildingTemplate.   Click the Edit button if the Template is not already open for editing, then click + Add next to My Properties. Enter the property name in the Name field copied from a row of the table below, Select the Base Type of the property from the drop down menu. Check Persistent and/or Logged if there is an X in the table row of the Property. NOTE: When Persistent is selected, the property value will be retained during a system restart. Properties that are not persisted will be reset to the default during a system restart. When Logged is selected, every property value change will be automatically logged to a specified Value Stream. Click the ✓+ button. TIP: When adding multiple properties at once, click Check+ after each, once you've entered a Name, selected a Base Type and any other criteria. If adding a single property, click Check button. Repeat steps 3 through 6 for each of the properties in the rows of the table. Name Base Type Persistent Logged buildingID STRING x   building_lat_long LOCATION x   watts NUMBER x x After entering the final property, click the ✓ button. Click Save. You should see the following properties in your Composer.   In the next part of this introductory exercise, we will create a single Thing based on this Template to represent a house.

Design Your Data Model Guide Part 1   Overview   This project will introduce the process of taking your IoT solution from concept to design. Following the steps in this guide, you will create a solution that doesn’t need to be constantly revamped, by creating a comprehensive Data Model before starting to build and test your solution. We will teach you how to utilize a few proposed best practices for designing the ThingWorx Data Model and provide some prescriptive methods to help you generate a high-quality framework that meets your business needs. NOTE: This guide’s content aligns with ThingWorx 9.3. The estimated time to complete ALL 3 parts of this guide is 60 minutes. All content is relevant but there are additional tools and design patterns you should be aware of. Please go to this link for more details.    Step 1: Data Model Methodology   We will start by outlining the overall process for the proposed Data Model Methodology.       Step Description 1 User Stories Identify who will use the application and what information they need. By approaching the design from a User perspective, you should be able to identify what elements are necessary for your system. 2 Data Sources Identify the real-world objects or systems which you are trying to model. To create a solid design, you need to identify what the “things” are in your system and what data or functionality they expose. 3 Model Breakdown Compose a representative model of modular components to enable uniformity and reuse of functionality wherever possible. Break down user requirements and data, identifying how the system will be modeled in Foundation. 4 Data Strategy Identify the sources of data, then evaluate how many different types of data you will have, what they are, and how your data should be stored. From that, you may determine the data types and data storage requirements. 5 Business Logic Strategy Examine the functional needs, and map them to your design for proper business logic implementation. Determine the business logic as a strategic flow of data, and make sure everything in your design fits together in logical chunks. 6 User Access Strategy Identify each user's access and permission levels for your application. Before you start building anything, it is important to understand the strategy behind user access. Who can see or do what? And why? NOTE: Due to the length of this subject, the ThingWorx Data Model Methodology has been divided into multiple parts. This guide focuses on the first three steps = User Stories, Data Sources, and Model Breakdown. Guides covering the last three steps are linked in the final Next Steps page.    Step 2: User Stories     With a user-based approach to design, you identify requirements for users at the outset of the process. This increases the likelihood of user satisfaction with the result. Utilizing this methodology, you consider each type of user that will be accessing your application and determine their requirements according to each of the following two categories: Category Requirement Details Functionality Determine what the user needs to do. This will define what kind of Services and Subscriptions will need to be in the system and which data elements and Properties must be gathered from the connected Things. Information What information do they need? Examine the functional requirements of the user to identify which pieces of information the users need to know in order to accomplish their responsibilities.   Factory Example   Let’s revisit our Smart Factory example scenario. The first step of the User Story phase of the design process is to identify the potential users of your system. In this example scenario, we have defined three different types of users for our solution: Maintenance Operations Management Each of these users will have a different role in the system. Therefore, they will have different functional and informational needs.   Maintenance   It is the maintenance engineer’s job to keep machines up and running so that the operator can assemble and deliver products. To do this well, they need access to granular data for the machine’s operating status to better understand healthy operation and identify causes of failure. They also need to integrate their maintenance request management system to consolidate their efforts and to create triggers for automatic maintenance requests generated by the connected machines. Required Functionality Get granular data values from all assets Get a list of maintenance requests Update maintenance requests Set triggers for automatic maintenance request generation Automatically create maintenance requests when triggers have been activated Required Information Granular details for each asset to better understand healthy asset behavior Current alert status for each asset When the last maintenance was performed on an asset When the next maintenance is scheduled for an asset Maintenance request for information, including creation date, due date, progress notes   Operations   The operator’s job is to keep the line running and make sure that it’s producing quality products. To do this, operators must keep track of how well their line is running (both in terms of speed and quality). They also need to be able to file maintenance requests when they have issues with the assets on their line. Required Functionality File maintenance request Get quality data from assets on their line Get performance data for the whole line Get a prioritized list of production orders for their line Create maintenance requests Required Information Individual asset performance metrics Full line performance metrics Product quality readings   Management   The production manager oversees the dispatch of production orders and ensures quotas are being met. Managers care about the productivity of all lines and the status of maintenance requests. Required Functional Create production orders Update production orders Cancel production orders Access line productivity data Elevate maintenance request priority Required Information Production line productivity levels (OEE) List of open maintenance requests   Step 3: Data Sources – Thing List     Thing List   Once you have identified the users' requirements, you'll need to determine what parts of your system must be connected. These will be the Things in your solution. Keep in mind that a Thing can represent many different types of connected endpoints. Here are some examples of possible Things in your system: Devices deployed in the field with direct connectivity or gateway-connectivity to Foundation Devices deployed in the field through third-party device clouds Remote databases Connections to external business systems (e.g., Salesforce.com, Weather.com, etc.)   Factory Example   In our Smart Factory example, we have already identified the users of the system and listed requirements for each of those users. The next step is to identify the Things in our solution. In our example, we are running a factory floor with multiple identical production lines. Each of these lines has multiple different devices associated with it. Let’s consider each of those items to be a connected Thing. Things in each line: Conveyor belt x 2 Pneumatic gate Robotic Arm Quality Check Camera Let's also assume we already have both a Maintenance Request System and a Production Order System that are in use today. To add this to our solution, we want to build a connector between Foundation and the existing system. These connectors will be Things as well. Internal system connection Thing for Production Order System Internal system connection Thing for Maintenance Request System NOTE: It is entirely possible to have scenarios in which you want to examine more granular-level details of your assets. For example, the arm and the hand of the assembly robot could be represented separately. There are endless possibilities, but for simplicity's sake, we will keep the list shorter and more high-level. Keep in mind that you can be as detailed as needed for this and future iterations of your solution. However, being too granular could potentially create unnecessary complexity and data overload.    Click here to view Part 2 of this guide.

Create Custom Business Logic    Overview   This project will introduce you to creating your first ThingWorx Business Rules Engine.   Following the steps in this guide, you will know how to create your business rules engine and have an idea of how you might want to develop your own. We will teach you how to use your data model with Services, Events, and Subscriptions to establish a rules engine within the ThingWorx platform.   NOTE: This guide's content aligns with ThingWorx 9.3. The estimated time to complete this guide is 60 minutes.    Step 1: Completed Example   Download the attached, completed files for this tutorial: BusinessLogicEntities.xml.   The BusinessLogicEntities.xml file contains a completed example of a Business Rules Engine. Utilize this file to see a finished example and return to it as a reference if you become stuck during this guide and need some extra help or clarification. Keep in mind, this download uses the exact names for entities used in this tutorial. If you would like to import this example and also create entities on your own, change the names of the entities you create.   Step 2: Rules Engine Introduction   Before implementing a business rule engine from scratch, there are a number of questions that should first be answered. There are times in which a business rule engine is necessary, and times when the work can be down all within regular application coding.   When to Create a Rules Engine: When there are logic changes that will often occur within the application. This can be decisions on how to do billing based on the state or how machines in factories should operate based on a release. When business analysts are directly involved in the development or utilization of the application. In general, these roles are often non-technical, but being involved with the application directly will mean the need for a way to make changes. When a problem is highly complex and no obvious algorithm can be created for the solution. This often covered scenarios in which an algorithm might not be the best option, but a set of conditions will suffice.   Advantages of a Rules Engine The key reward is having an outlet to express solutions to difficult problems than can be easily verifiable. A consolidated knowledge base for how a part of a system works and a possible source of documentation. This source of information provides people with varying levels of technical skill to all have insight into a business model.   Business Logic with ThingWorx Core Platform: A centralized location for development, data management, versioning, tagging, and utilization of third party applications. The ability to create the rules engine within the ThingWorx platform and outside of ThingWorx platform. Being that the rules engine can be created outside of the ThingWorx platform, third party rules engines can be used. The ThingWorx platform provides customizable security and provided services that can decrease the time in development.     Step 3: Establish Rules   In order to design a business rules engine and establish rules before starting the development phase, you must capture requirements and designate rule characteristics.   Capture Requirements The first step to building a business rules engine is to understand the needs of the system and capture the rules necessary for success.   Brainstorm and discuss the conditions that will be covered within the rules engine Construct a precise list Identify exact rules and tie them to specific business requirements.   Each business rule and set of conditions within the business rule will need to be independent of other business rules. When there are several scenarios involved, it is best to create multiple rules – one handling each. When business rules are related to similar scenarios, the best methodology is to group the rules into categories.   Category Description Decision Rules Set of conditions regarding business choices Validation Rules Set of conditions regarding data verifications Generation Rules Set of conditions used for data object creation in the system Calculation Rules Set of conditions that handle data input utilized for computing values or assessments   Designate Rule Characteristics Characteristics for the rules include, but are not limited to: Naming conventions/identifiers Rule grouping Rule definition/description Priority Actions that take place in each rule.   After this is completed, you will be ready to tie business requirements to business rules, and those directly to creating your business rules engine within the platform.   Rules Translation to ThingWorx There are different methods for how the one to one connections can be made between rules and ThingWorx. The simplified method below shows one way that all of this can be done within the ThingWorx platform:   Characteristic  ThingWorx Aspect Rule name/identifier Service Name Ruleset  Thing/ThingTemplate Rule definition  Service Implementation Rule conditions Service Implementation Rule actions Service Implementation Data management DataTables/Streams   Much of the rule implementation is handled by ThingWorx Services using JavaScript. This allows for direct access to data, other provided Services, and a central location for all information pertaining to a set of rules. The design provided above also allows for easier testing and security management.   Step 4: Scenario Business Rule Engine    An important aspect to think about before implementing your business rules engine, is how the Service implementation will flow.   Will you have a singular entry path for the entire rules engine? Or will you have several entries based on what is being requested of it? Will you have create only Services to handle each path? Or will you create Events and Subscriptions (Triggers and Listeners) in addition to Services to split the workload?   Based on how you answer those questions, dictates how you will need to break up your implementation. The business rules for the delivery truck scenario are below. Think about how you would break down this implementation.   High Level Flow 1 Customer makes an order with a Company (Merchant). 1.A Customer to Merchant order information is created. 2 The Merchant creates an order with our delivery company, PTCDelivers. 2.A Merchant order information is populated. 2.B Merchant sets delivery speed requested. 2.C Merchant sets customer information for the delivery. 3 The package is added to a vehicle owned by PTCDelivers. 4 The vehicle makes the delivery to the merchant's customer.   Lower Level: Vehicles 1 Package is loaded onto vehicle 1.i Based on the speed selected, add to a truck or plane. 1.ii Ground speed option is a truck. 1.iii Air and Expedited speed options are based on planes usage and trucks when needed. 2 Delivery system handles the deliveries of packages 3 Delivery system finds the best vehicle option for delivery 4 An airplane or truck can be fitted with a limited number of packages.   Lower Level: Delivery 1 Delivery speed is set by the customer and passed on to PTCDelivers. 2 Delivery pricing is set based on a simple formula of (Speed Multiplier * Weight) + $1 (Flat Fee). 2.i Ground arrives in 7 days. The ground speed multiplier is $2. 2.ii Air arrives in 4 days. The air speed multiplier is $8. 2.iii Expedited arrives in 1 day. The expedited speed multiplier is $16. 3 Deliveries can be prioritized based on a number of outside variables. 4 Deliveries can be prioritized based on a number of outside variables. 5 Bulk rate pricing can be implemented.   How would you implement this logic and add in your own business logic for added profits? Logic such as finding the appropriate vehicle to make a delivery can be handled by regular Services. Bulk rates, prioritizing merchants and packages, delivery pricing, and how orders are handled would fall under Business Logic. The MerchantThingTemplate Thing contains a DataChange Subscription for it's list of orders. This Subscription triggers an Event in the PTCDelivers Thing.   The PTCDelivers Thing contains an Event for new orders coming in and a Subscription for adding orders and merchants to their respective DataTables. This Subscription can be seen as the entry point for this scenario. Nevertheless, you can create a follow-up Service to handle your business logic. We have created the PTCDeliversBusinessLogic to house your business rules engine.   Step 5: Scenario Data Model Breakdown   This guide will not go into detail of the data model of the application, but here is a high level view of the roles played within the application.   Thing Shapes ClientThingShape Shape used to represent the various types of clients the business faces (merchants/customers). VehicleThingShape Shape used to represent different forms of transportation throughout the system.   Templates PlaneThingTemplate Template used to construct all representations of a delivery plane. TruckThingTemplate Template used to construct all representations of a delivery truck. MerchantThingTemplate Template used to construct all representations of a merchant where goods are purchased from. CustomerThingTemplate Template used to construct all representations of a customer who purchases goods.   Things/Systems PTCDeliversBusinessLogic This Thing will hold a majority of the business rule implementation and convenience services. PTCDelivers A Thing that will provide helper functions in the application.   DataShapes PackageDeliveryDataShape DataShape used with the package delivery event. Will provide necessary information about deliveries. PackageDataShape DataShape used for processing a package. OrderDataShape DataShape used for processing customer orders. MerchantOrderDataShape DataShape used for processing merchant orders. MerchantDataShape DataShape used for tracking merchants.   DataTables OrdersDatabase DataTable used to store all orders made with customers. MerchantDatabase DataTable used to store all information for merchants.     Step 6: Next Steps   Congratulations! You've successfully completed the Create Custom Business Logic guide, and learned how to: Create business logic for IoT with resources provided in the ThingWorx platform Utilize the ThingWorx Edge SDK platforms with a pre-established business rule engine   We hope you found this guide useful.    The next guide in the Design and Implement Data Models to Enable Predictive Analytics learning path is Implement Services, Events, and Subscriptions.     

Durable Queues Are Here by Tori Firewind, Principal Cloud Architect   Introduction Well folks, the durable queue is here, and it is… durable! We tried everything in our dev ops arsenal to bring it down, but no matter what we threw at it, Event Hub stayed up. No data was lost in any test scenario. ThingWorx 10.0 is a remarkably more mature and stable offering than ever before with its new use of Kafka to prevent data loss, as well as internal queue management and queue diagnostics features.   As we announced last quarter, new diagnostics features allow us to record diagnostic data from the moment a problem starts, ensuring RCA can begin immediately, without further time spent waiting for issues to occur again. These are highly configurable, and PTC is ready to support customers opting-in to acceleration-based diagnostics!   Coming out now is the new internal throttling mechanism within ThingWorx, which ensures that even when queues max out, regardless of what those queues are doing, ThingWorx remains up and capable of other activity. In some of our failed scale test scenarios, the event queue was maxed out for many hours, without any subsequent out of memory crash of the Platform. It was remarkably durable!   Even better if the durable queue is opted-in, because then those events also happen faster and more reliably. The durable events fire immediately within the Platform when a durable property is updated. Both of these go to Event Hub simultaneously. The load within Event Hub is balanced independently and processed more quickly than by ThingWorx, improving overall performance of both property updates and events, while still leaning heavily on ThingWorx for the web access and data redirect and storage.   When the lag is well controlled, the subject of most of the rest of this article, the property values go in, they come out within milliseconds, and the latency is not significant in spite of the added component. And of course, if something happens to the Platform in the meantime, never fear, for the data truly is preserved and accessible within Event Hub.   Data loss is a thing of the past with ThingWorx 10.0!     Configuration Situation The one sacrifice of durability is scale, which can be challenging with Event Hub.  There are some key considerations when optimizing ThingWorx for throughput, which should be considered necessary, as well as when sizing Event Hub.   ThingWorx Throughput Optimization Within ThingWorx, go to the system object and edit it (may require admin permissions). Modify the Configuration to reduce the overall number of threads, which in turn reduces the distribution of the Event Hub load, allowing each to be processed more quickly. Also lower the buffer scan rate for persistent properties so they flush more often.   Especially lower the max number of items before flushing, the buffer that usually delays writes to the database so as not to overwhelm it. That is less of a factor here as Event Hub has an internal load balancer. Event Hub is better for throughput than a database would be, and these are the settings to put on all opt-in queues for optimal performance.   Event Hub Sizing and Partition Optimization Within Event Hub, there are several types of processing units. We will focus on the lower two tiers, as the highest tier is very expensive and less common to use, and the concept is the same as the Premium (mid) tier.   The Standard Tier uses TUs, a.k.a. “Throughput Units”, and these are less performant but also less resource intensive, and so much less expensive. There is a maximum of 40 TUs overall, and 32 partitions per Event Hub in Standard. There is one Event Hub each for Logged Properties, Persistent Properties, and Unordered Events in both Standard and Premium.   Premium Tier instead uses PUs, a,k.a. “Processing Units” and these are more performant and more resource intensive, with lower commit request latency, meaning the commits within Event Hub are happening faster. The data is received faster, and the cost for this is greater, but the stability is also greater and the risk of runaway lag or eventual data loss much lower. The risks are much more mild than before, and recovery is discussed below.   In Premium, there is a maximum of 100 partitions per Event Hub, with 200 total per PU. There is a maximum of 16 PUs, and these go only in increments of 2. There are diminishing returns with more resources, however, directly proportional to the number of things. More things overall will reduce the write capabilities within Event Hub, as more CPU resources have to be spent on the network communication portion of the data exchange. Low Partitions Medium Partitions High Partitions   It is better to use more partitions than less, and a higher number of partitions will result in less latency and lower mean lag. There is always some lag, however, as it is calculated from the number of items queued versus completed. Both of these queues are very active, and healthy lag is usually between 60 – 80% of the total property wps, with peaks that do not increase over time. Sometimes the lag can be spikey, which must be considered in the alerting infrastructure.   The mean load should be significantly less than 16 PUs and load tested, so that there is room to scale up and recover any lag that accrues from the unpredictable nature of production systems. Always leave room for spikes!   Recovery of the Event Hub The short version: do not modify the partitions to resolve runaway lag.    If more partitions are added while the lag is falling behind, then instead of helping to catch up, they significantly delay the recovery. Anything currently in Event Hub will not be distributed across the new partitions, only new things that are added later, but all of the partitions will still be polled for data, including the new ones, which will slow things down even more.   The right way to deal with runaway lag is to increase the TUs or PUs to a decently higher setting temporarily, let the lag catch up, and then increase the number of partitions, and then wait and see how the server responds before finally downsizing once again. It is important to consider that there is a maximum size for processing data, and a maximum number of partitions per Event Hub, creating a hard upper limit for performance and scale.   Make sure any Event Hub instance is sized small enough to allow for upsize in the case of runaway lag. Edge load is not guaranteed to remain perfectly steady, generally speaking, there can be surprise disconnections, reconnections, and spikes in utilization. There really is no other way to ensure no data loss occurs to runaway lag, especially since there usually is no way to turn off the Edge load at will in Production. Lag grew to the hundreds of thousands quickly, was surely beyond recovery at this size. The partitions were increased at 11:45 to demonstrate the poor distribution of data processing within Event Hub. Around 15 hours to recover. Here it is up close, see how every partition is doing a tiny amount of work, and it takes quite a long time? Too much lag, and the data will be lost in one of two ways: not being added to an already full queue within Event Hub, or by erroring out as Event Hub tries to pass it back with a variety of errors. If Event Hub backs up too much to be recovered by upsizing, or it cannot be upsized enough, it can be deleted, and only the type of data affected will see loss, and with no downtime for ThingWorx.   A Healthy Example An XL ThingWorx deployment was used to ensure that the Platform was not the limiting factor. The required TUs and PUs are the figures calculated by the Grafana dashboard, coming from the Kafka metrics. The average latency for subscriptions is calculated by having a start datetime property (not logged or persisted) update when the rest of the property updates fire, and then an end datetime property update when the subscriptions to the persistent properties run; the timespan is then calculated and written to the script log.   This example was an XL sized application, 80k things, each thing with  20 properties total, 10 Logged and 10 Persistent properties, that write to Event Hub twice in a minute. There were 5 events as well to measure the latency, but due to the design of the test (property updates fired from a timer subscription), opting in to Durable Events causes performance issues that affect the test results. That is why events show up in the Event Queue, which does not happen in opt-in tests. : These are calculated by the Kafka Metrics dashboard:  Required TUs:    115                Required PUs:   2        These were what was configured for this test: TUs Configured: N/A              PUs Configured: 16                Partitions (respectively): 100, 100, 0 Average Latency for Subscriptions: < 100ms   The test begins at 11 am. Lag is steady and the spikes are not increasing over time (though they come close).   The property write rate includes the 20 properties that go to Event Hub, plus the 10 date time properties for measuring latency, and one additional info table property for a more realistic load.   This looks the same as it usually does, there is no change to performance.   This is high because of the design of the test, all of the things update on thing template level timer subscriptions. This is much lower with opt-in for durable events.     How durable!

Leveraging ThingWorx for Unified Namespace with Sparkplug B Integration   Abstract   The industrial IoT (IIoT) landscape demands scalable, interoperable, and real-time data architectures to enable seamless communication across heterogeneous systems. Unified Namespace (UNS) has emerged as a new approach to organizing and contextualizing data in a centralized, hierarchical structure accessible to all devices and applications. This article explores how PTC’s ThingWorx, a leading IIoT platform, can serve as a robust foundation for operationalizing a UNS, with a specific focus on integrating MQTT-based Sparkplug B messaging. Building on the open-source SparkplugB-Edge-SDK provided by the ThingWorx Customer Success team, we demonstrate how ThingWorx can bridge edge devices, industrial systems, and enterprise applications within a UNS framework, delivering real-time visibility, scalability, and operational efficiency.   1. Introduction   1.1 The Need for Unified Namespace   In traditional industrial environments, data silos and protocol disparities hinder operational efficiency and decision-making. A Unified Namespace (UNS) addresses these challenges by providing a single, logical, and hierarchical data structure that serves as a "single source of truth" for all systems. While customers using ThingWorx have been implementing UNS without realizing it, recently when people say UNS, they also associate it with leveraging MQTT with it.  MQTT (Message Queuing Telemetry Transport) as a lightweight messaging protocol, with Sparkplug B enhancing it by adding a standardized topic structure and payload format helps enterprises with a starting point for implementing UNS.     1.2 ThingWorx: An IIoT Platform for Modern Architectures   PTC ThingWorx is a comprehensive IIoT platform designed to model, connect, and manage industrial assets while providing tools for data visualization, analytics, and integration. Its extensible architecture and support for standards like MQTT make it an ideal candidate for operationalizing a UNS. This paper builds on an example implementation, the SparkplugB-Edge-SDK, to illustrate how ThingWorx can operationalize a UNS in real-world scenarios.   2. Understanding Unified Namespace and Sparkplug B   2.1 Unified Namespace Overview   A UNS is a hierarchical naming convention that organizes all data—sensors, machines, processes, and enterprise systems—into a structured, globally accessible namespace. For example, a UNS topic might look like: FactoryA/Line1/Machine1/Sensor1/Voltage This structure ensures that data is self-describing, context-rich, and universally interpretable across the enterprise.   2.2 Sparkplug B: Enhancing MQTT for Industrial IoT   Sparkplug B is an open specification that builds on MQTT to provide a standardized framework for IIoT data exchange. Key features include: Topic Namespace: A predefined structure (e.g., spBv1.0/GroupID/MESSAGE_TYPE/NodeID/DeviceID) for consistent data addressing. State Management: Birth and death certificates to manage device connectivity. Efficient Payloads: Binary encoding via Google Protocol Buffers for compact, high-performance data transfer. Sparkplug B aligns naturally with UNS by enforcing a structured, interoperable data model suitable for industrial environments.   3. ThingWorx and Sparkplug B Integration   3.1 The SparkplugB-Edge-SDK   PTC offers several connectivity options with Kepware for industrial connectivity providing protocol transformation, and ThingWorx Edge SDKs for custom connectivity in developer friendly languages such as C-SDK, .NET SDK, and Java SDK to connect any asset with ThingWorx natively using WebSocket based AlwaysOn protocol. The SparkplugB-Edge-SDK (source and executable JAR available at https://github.com/thingworx-field-work/SparkplugB-Edge-SDK) is a Java-based component developed using ThingWorx Edge Java SDK. It integrates ThingWorx with Sparkplug B-enabled edge devices, enabling bidirectional communication over MQTT. Key components include: MQTT Client: Connects to an MQTT broker (e.g., Eclipse Mosquitto, HiveMQ) to publish and subscribe to Sparkplug B topics. ThingWorx Edge SDK Integration: Maps Sparkplug B data to ThingWorx entities (Things, Properties, Services). Configuration Flexibility: Supports customizable mappings between Sparkplug B metrics and ThingWorx data models. This SDK serves as a reference implementation for bridging edge devices with ThingWorx in a UNS context.   3.2 Architecture Overview   The proposed architecture integrates ThingWorx with a UNS as follows: Edge Layer: Devices publish data to an MQTT broker using Sparkplug B topics Broker Layer: An MQTT broker (e.g., Mosquitto) acts as the central hub, routing Sparkplug B messages. Application Layer: ThingWorx subscribes to the broker, ingests data, and maps it to its internal data model, exposing it via REST APIs, mashups, or analytics. This layered approach ensures scalability and decoupling of edge and enterprise systems.     4. Implementation Details   4.1 Setting Up the Environment   To implement a UNS with ThingWorx and Sparkplug B: Deploy an MQTT Broker: Install and configure an MQTT broker (e.g., Mosquitto) to handle Sparkplug B traffic. Configure the SparkplugB-Edge-SDK: Clone the repository: git clone <https://github.com/thingworx-field-work/SparkplugB-Edge-SDK.> Update configuration files (e.g., SparkplugBEdge.json) with MQTT broker details and ThingWorx connection credentials (URL, AppKey). Deploy the SDK on edge devices or gateways. Model in ThingWorx: Create Thing Templates and Things corresponding to edge devices. Define Properties to mirror Sparkplug B metrics (e.g., Voltage, Temperature, Pressure).   4.2 Mapping Sparkplug B to ThingWorx   The SDK maps Sparkplug B payloads to ThingWorx entities. For example: Sparkplug Topic: spBv1.0/FactoryA/DDATA/Node1/Device1/Voltage ThingWorx Entity: A Thing named FactoryA_Node1_Device1 with a Property Voltage. The SDK handles: Data Ingestion: Subscribes to Sparkplug B topics and updates ThingWorx Properties in real time. Event Handling: Processes Birth/Death messages to manage device state in ThingWorx.   4.3 Extending the UNS   ThingWorx’s extensibility allows the UNS to evolve: Services: Custom services can aggregate or transform data (e.g., calculating averages across a production line). Mashups: Visualize the UNS hierarchy using ThingWorx’s UI tools. Analytics: Integrate with ThingWorx Analytics to derive insights from UNS data.   5. Benefits of ThingWorx in a UNS   Scalability: ThingWorx’s distributed architecture supports thousands of edge devices within a UNS. Interoperability: Seamless integration with edge using Sparkplug B and with different systems using REST API OR OOTB connectors ensures compatibility with diverse industrial protocols and systems. Real-Time Visibility: Immediate data updates enable responsive decision-making. Extensibility: Developers can enhance the UNS with custom logic, integration, and visualizations.   6. Case Study: Manufacturing Line Monitoring   Consider a factory with multiple production lines. Using the SparkplugB-Edge-SDK: Edge sensors publish data to spBv1.0/FactoryA/DDATA/Line1/Machine1/ Voltage. The SDK relays this to ThingWorx, updating the Line1_Machine1 Thing’s Voltage Property. A ThingWorx mashup displays real-time Voltage (and properties like RPM, Torque/Current, Power Factor, etc.,) across all machines, organized by the UNS hierarchy. Alerts trigger if Voltage exceed thresholds, demonstrating actionable insights derived from the UNS. This setup provides a cohesive, scalable monitoring solution.   7. Challenges and Considerations   Network Reliability: MQTT requires a stable connection; ThingWorx’s data storage capabilities can mitigate disruptions. Data Volume: High-frequency updates may strain resources; optimize payload sizes and subscription rates. Security: Secure MQTT with TLS and enforce ThingWorx access controls to protect the UNS.   8. Conclusion   ThingWorx, offers a powerful platform for operationalizing a Unified Namespace in industrial IoT environments. By leveraging Sparkplug B’s standardized messaging and ThingWorx’s robust data management and visualization capabilities, organizations can achieve a scalable, interoperable, and real-time data architecture. This article provides a high-level blueprint for integrating these technologies, empowering industries to unlock the full potential of their data.   9. Road ahead   ThingWorx already ingests data over MQTT using the MQTT extension, this Sparkplug-edge SDK, Kepware, or via Azure IoT hub, but with IoT Streams capability introduced in ThingWorx v10.0, users will have the ability to send contextualized IoT data for further analysis and intelligence for end to end Industrial Data Management and UNS needs. PTC plans to provide more OOTB capabilities to ingest MQTT data coming into ThingWorx, contextualize it, and make that contextualize data rapidly available over MQTT to other resources at scale. Stay tuned!     As ThingWorx community members get further along their journey of implementing UNS using ThingWorx, please do not hesitate to provide us your feedback or ask questions in the ThingWorx IoT community.       Cheers, Ayush Tiwari Director Product Management, ThingWorx.  

ThingWorx has long been a trusted platform in the industrial IoT space, helping organizations build and scale connected solutions. With the release of ThingWorx 10.0, we're introducing meaningful updates that make it easier, faster, and more secure to develop and manage industrial IoT applications — while keeping the core strengths that customers rely on.   ThingWorx 10.0 isn't just about new features; it's about making the platform more efficient, more reliable, and better aligned with today’s enterprise needs. Key enhancements focus on improving performance at scale, streamlining developer workflows, and strengthening security frameworks — essential capabilities for any modern IoT deployment. While security improvements are critical, they represent the standard customers expect, and we’ve invested in making sure ThingWorx continues to meet and exceed those expectations.   Here is a summary of the latest security updates for ThingWorx, including patches and vulnerability fixes. Reviewing and applying these updates is essential to protect your systems from emerging threats and ensure the ongoing security and stability of your ThingWorx environment.   JAVA 21 Support   Future-Proofing Your Applications ThingWorx 10.0 now supports Java 21, ensuring that your applications benefit from the latest language improvements and long-term support. Starting with ThingWorx 10, Java 21 will be the only supported version, marking the end of Java 11 support for the core platform. Enhanced Performance and Security Java 21 brings improved garbage collection, better memory management, and access to the latest security patches, which are essential for sustaining platform stability in today’s fast-paced technology environment.   TLS 1.3 Support   Evolving Encryption Standards with TLS 1.3 Support Leading up to the release of ThingWorx 10.0, PTC has progressively introduced TLS 1.3 support across recent platform versions, including ThingWorx 9.6, 9.7, and now in ThingWorx 10.0. This phased rollout ensures customers benefit from stronger encryption, faster handshake processes, and reduced latency — all critical improvements for securing data in modern industrial IoT environments. Continued Backward Compatibility We recognize that many customers operate in diverse and complex environments. To support a smooth transition, ThingWorx continues to maintain full backward compatibility with TLS 1.2. Customers who are not yet ready to move fully to TLS 1.3 can continue to operate securely without disruption.   Tomcat 11 Support   Enhanced Performance & Scalability Leveraging Apache Tomcat 11, ThingWorx 10.0 provides improved handling of concurrent connections, faster response times, and better resource management. Stronger Security Configurations The latest Tomcat version comes with refined security settings, reducing the attack surface and offering robust default configurations.   Custom Logback Support   Logback is a widely used logging framework for Java applications, chosen for its speed, flexibility, and reliability. It helps developers capture and manage logs efficiently, which is critical for debugging, monitoring, and maintaining system health. For customers, this means faster issue resolution, improved system stability, and better performance insights. With Logback in place, engineering teams can proactively identify and address problems, minimizing downtime and enhancing the overall user experience. In essence, robust logging through Logback directly contributes to a more reliable and responsive product for customers. With the launch of ThingWorx 10, we've made some important updates behind the scenes to improve system reliability and performance. One of these changes involves how logging is handled, which helps us monitor and troubleshoot the platform more effectively. To make this transition smooth for users who have made custom settings, we've provided a simple tool that automatically updates those settings to work with the latest version. It's a quick and easy process, and for those who prefer to make changes manually, we’ve also included clear step-by-step instructions. These updates help ensure a more stable, consistent experience as we continue to evolve the platform.   Spring Framework 6 Support   Modern Application Framework: By integrating Spring framework 6, developers can build more modular and resilient applications. This not only enhances performance but also simplifies the integration of security features. Improved Security Features: The new framework version offers enhanced support for dependency injection and security configuration, which aligns perfectly with our secure coding practices.   Enhanced Content Security Policy (CSP) Features   Foundational Defense Against Web-Based Threats ThingWorx 10.0 continues to enhance platform security with expanded support for Content Security Policy (CSP). While CSP functionality was first introduced in ThingWorx 9.3.15, 9.4.5, 9.5.1, and 9.6.0, this release builds on that foundation to improve defenses against common web-based threats such as cross-site scripting (XSS), data injection, clickjacking, and man-in-the-middle attacks. Phased Adoption Approach For ThingWorx 10.0, CSP support will be available but disabled by default. Cloud customers interested in enabling CSP will need to contact PTC Support to request activation. This approach ensures a smooth rollout while giving organizations flexibility based on their deployment and testing timelines. The current implementation lays the groundwork for a future where CSP could be enabled out-of-the-box (OOTB) in upcoming releases. For more details please visit help center   Remote Access and Control updates   The latest RAC enhancements in ThingWorx 9.7 continue to build on functionality introduced in earlier releases, delivering even stronger security, visibility, and scalability for Remote Service Engineers and ThingWorx Administrators. Engineers, who often operate behind proxies, now have an easier and more secure way to configure proxy settings for remote access.   Administrators benefit from enhanced remote session metrics, allowing them to better track and associate sessions with specific work orders. Additionally, improved tunneling support enables more scalable Remote Access Sessions, meeting the needs of advanced customer environments. These updates reinforce the security and manageability improvements first introduced in previous versions and take another step toward streamlining remote access management and enhancing scalability across the ThingWorx ecosystem.   Additional Third Party Stack Support Updates   With ThingWorx 10.0, we’re expanding compatibility across databases, middleware, and runtime environments to offer greater flexibility, security, and performance. These updates help organizations modernize their infrastructure while ensuring seamless integration with the latest technologies. Here’s a summary of the new supported platforms:   Category Sub-Category Supported Version Persistence Providers PostgreSQL v16.X v15.X v14.X   Microsoft SQL Server v2022.X   Azure DB for PostgreSQL Flex server v16.X v15.X v15.X   Azure SQL DB  v12.X   InfluxDB v1.11.X v2.7.X Operating System Windows and Linux Windows Server 2022 RHEL 8.10 and 9.4 Ubuntu 22.04.X   NOTE: Please refer to the Release Advisor as the single source of truth for the most accurate and up-to-date information.   PTC’s Commitment to Security and Innovation   At PTC, security is at the core of everything we do. Every product is built with a “security-first” mindset, ensuring that robust protection is woven into our development processes, architecture, and deployment practices. Our commitment is backed by a comprehensive Secure Development Lifecycle (SDLC) that includes advanced security practices such as SAST/DAST, secure coding standards, proactive vulnerability management, and rigorous penetration testing. These practices are designed not only to protect against known threats but also to continuously evolve with emerging risks. In addition, our shared security model clearly delineates the responsibilities between PTC and our customers, ensuring clarity and accountability in every deployment.   Our internal security policies and processes are a testament to our commitment:   Secure Development Lifecycle (SDLC): Static and Dynamic Analysis: We integrate Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST) throughout our development cycle. Vulnerability Management: Continuous scanning and timely updates for third-party libraries ensure that any potential vulnerabilities are swiftly identified and addressed. Penetration Testing: Both internal and external penetration tests are conducted periodically to uncover and mitigate risks. Compliance and Governance: We align our practices with industry standards such as ISO 27001 and GDPR, ensuring our products meet stringent regulatory requirements. A comprehensive set of deployment guides and configuration checklists helps maintain a secure environment throughout the product lifecycle. Training and Secure Design: Our teams are well-trained in the latest security methodologies through ongoing training initiatives, including role-based training sessions and tech talks. Security release criteria, threat modeling, and secure coding practices are integral to our product design. Secure Deployment Hub: Customers can always visit our Secure Deployment Hub to ensure any of the ThingWorx environment is deployed following best practices for maximum security and resilience not just ThingWorx 10.0.   These efforts not only strengthen the security of our products but also reassure our customers that each release is built with rigorous security standards at its core. They reflect just a portion of our broader commitment to proactive security, and we’re proud to be the trusted platform that enterprises rely on. The ThingWorx 10.0 preview release is now available for evaluation! This powerful, secure, and intelligent IoT platform is designed to elevate your industrial operations to the next level. To join the Private Preview Program, reach out to your account rep or customer success team. You can also comment on this post or submit a Tech Support ticket, and we’ll follow up to get you started. Vineet Khokhar Principal Product Manager, IoT Security   Stay tuned for more updates as we approach the release of ThingWorx 10.0, and as always, in case of issues, feel free to reach out to <support.ptc.com>  

Get Started with ThingWorx for IoT Guide Part 2   Step 4: Create Thing   A Thing is used to digitally represent a specific component of your application in ThingWorx. In Java programming terms, a Thing is similar to an instance of a class. In this step, you will create a Thing that represents an individual house using the Thing Template we created in the previous step. Using a Thing Template allows you to increase development velocity by creating multiple Things without re-entering the same information each time. Start on the Browse, folder icon tab on the far left of ThingWorx Composer. Under the Modeling tab, hover over Things then click the + button. Type MyHouse in the Name field. NOTE: This name, with matching capitalization, is required for the data simulator which will be imported in a later step. 4. If Project is not already set, click the + in the Project text box and select the PTCDefaultProject. 5. In the Base Thing Template text box, click the + and select the recently created BuildingTemplate. 6. In the Implemented Shapes text box, click the + and select the recently created ThermostatShape. 7. Click Save.     Step 5: Store Data in Value Stream   Now that you have created the MyHouse Thing to model your application in ThingWorx, you need to create a storage entity to record changing property values. This guide shows ways to store data in ThingWorx Foundation. This exercise uses a Value Stream which is a quick and easy way to save time-series data.   Create Value Stream   Start on the Browse, folder icon tab on the far left of ThingWorx Composer. Under the Data Storage section of the left-hand navigation panel, hover over Value Streams and click the + button. Select the ValueStream template option, then click OK. Enter Foundation_Quickstart_ValueStream in the Name field. If Project is not already set, click the + in the Project text box and select the PTCDefaultProject.   Click Save.   Update Thing Template   Navigate to the BuildingTemplate Thing Template. TIP: You can use the Search box at the top if the tab is closed.       2. Confirm you are on the General Information tab.       3. Click Edit button if it is visible, then, in the Value Stream text entry box, click the + and select Foundation_Quickstart_ValueStream               4. Click Save     Step 6: Create Custom Service   The ThingWorx Foundation server provides the ability to create and execute custom Services written in Javascript. Expedite your development with sample code snippets, code-completion, and linting in the Services editor for Things, Thing Templates, and Thing Shapes. In this section, you will create a custom Service in the Electric Meter Thing Shape that will calculate the current hourly cost of electricity based on both the simulated live data, and the electricity rate saved in your model. You will create a JavaScript that multiplies the current meter reading by the cost per hour and stores it in a property that tracks the current cost. Click Thing Shapes under the Modeling tab on the left navigation pane; then click on MeterShape in the list. Click Services tab, then click + Add and select Local (Javascript). Type calculateCost into the Name field. Click Me/Entities to open the tab. Click Properties. NOTE: There are a number of properties including costPerKWh, currentCost and currentPower. These come from the Thing Shape you defined earlier in this tutorial. 6. Click the arrow next to the currentCost property. This will add the Javascript code to the script box for accessing the currentCost property. 7. Reproduce the code below by typing in the script box or clicking on the other required properties under the Me tab:           me.currentCost = me.costPerKWh * me.currentPower;           8. Click Done. 9. Click Save. NOTE: There is a new ThingWorx 9.3 feature that allows users to easily Execute tests for ‘Services’ right from where they are defined so users can quickly test solution code.    Click here to view Part 3 of this guide. 

Original Post Date:            June 6, 2016   Description: This is a video tutorial on creating a Stream, adding a Data Shape with properties, and writing values to the Stream.    

KEPServerEX requires the 32-bit version of Java if you are using the IoT Gateway Plug-in. If you do not have the 32-bit version installed and attempt to connect the IoT Gateway, the KEPServerEX Event Log will report the following error: “IoT Gateway failed to start, 32-bit JRE required." Some of the Manufacturing Applications training content relies on this Plug-in, as well. As a best practice, it is recommended that both the 32-bit and 64-bit versions of Java be installed. This install is available for download from the Oracle website, here: Java SE Runtime Environment 8 - Downloads

Distributed Timer and Scheduler Execution in a ThingWorx High Availability (HA) Cluster Written by Desheng Xu and edited by Mike Jasperson    Overview Starting with the 9.0 release, ThingWorx supports an “active-active” high availability (or HA) configuration, with multiple nodes providing redundancy in the event of hardware failures as well as horizontal scalability for workloads that can be distributed across the cluster.   In this architecture, one of the ThingWorx nodes is elected as the “singleton” (or lead) node of the cluster.  This node is responsible for managing the execution of all events triggered by timers or schedulers – they are not distributed across the cluster.   This design has proved challenging for some implementations as it presents a potential for a ThingWorx application to generate imbalanced workload if complex timers and schedulers are needed.   However, your ThingWorx applications can overcome this limitation, and still use timers and schedulers to trigger workloads that will distribute across the cluster.  This article will demonstrate both how to reproduce this imbalanced workload scenario, and the approach you can take to overcome it.   Demonstration Setup   For purposes of this demonstration, a two-node ThingWorx cluster was used, similar to the deployment diagram below:   Demonstrating Event Workload on the Singleton Node   Imagine this simple scenario: You have a list of vendors, and you need to process some logic for one of them at random every few seconds.   First, we will create a timer in ThingWorx to trigger an event – in this example, every 5 seconds.     Next, we will create a helper utility that has a task that will randomly select one of the vendors and process some logic for it – in this case, we will simply log the selected vendor in the ThingWorx ScriptLog.     Finally, we will subscribe to the timer event, and call the helper utility:     Now with that code in place, let's check where these services are being executed in the ScriptLog.     Look at the PlatformID column in the log… notice that that the Timer and the helper utility are always running on the same node – in this case Platform2, which is the current singleton node in the cluster.   As the complexity of your helper utility increases, you can imagine how workload will become unbalanced, with the singleton node handling the bulk of this timer-driven workload in addition to the other workloads being spread across the cluster.   This workload can be distributed across multiple cluster nodes, but a little more effort is needed to make it happen.   Timers that Distribute Tasks Across Multiple ThingWorx HA Cluster Nodes   This time let’s update our subscription code – using the PostJSON service from the ContentLoader entity to send the service requests to the cluster entry point instead of running them locally.       const headers = { "Content-Type": "application/json", "Accept": "application/json", "appKey": "INSERT-YOUR-APPKEY-HERE" }; const url = "https://testcluster.edc.ptc.io/Thingworx/Things/DistributeTaskDemo_HelperThing/services/TimerBackend_Service"; let result = Resources["ContentLoaderFunctions"].PostJSON({ proxyScheme: undefined /* STRING */, headers: headers /* JSON */, ignoreSSLErrors: undefined /* BOOLEAN */, useNTLM: undefined /* BOOLEAN */, workstation: undefined /* STRING */, useProxy: undefined /* BOOLEAN */, withCookies: undefined /* BOOLEAN */, proxyHost: undefined /* STRING */, url: url /* STRING */, content: {} /* JSON */, timeout: undefined /* NUMBER */, proxyPort: undefined /* INTEGER */, password: undefined /* STRING */, domain: undefined /* STRING */, username: undefined /* STRING */ });   Note that the URL used in this example - https://testcluster.edc.ptc.io/Thingworx - is the entry point of the ThingWorx cluster.  Replace this value to match with your cluster’s entry point if you want to duplicate this in your own cluster.   Now, let's check the result again.   Notice that the helper utility TimerBackend_Service is now running on both cluster nodes, Platform1 and Platform2.   Is this Magic?  No!  What is Happening Here?   The timer or scheduler itself is still being executed on the singleton node, but now instead of the triggering the helper utility locally, the PostJSON service call from the subscription is being routed back to the cluster entry point – the load balancer.  As a result, the request is routed (usually round-robin) to any available cluster nodes that are behind the load balancer and reporting as healthy.   Usually, the load balancer will be configured to have a cookie-based affinity - the load balancer will route the request to the node that has the same cookie value as the request.  Since this PostJSON service call is a RESTful call, any cookie value associated with the response will not be attached to the next request.  As a result, the cookie-based affinity will not impact the round-robin routing in this case.   Considerations to Use this Approach   Authentication: As illustrated in the demo, make sure to use an Application Key with an appropriate user assigned in the header. You could alternatively use username/password or a token to authenticate the request, but this could be less ideal from a security perspective.   App Deployment: The hostname in the URL must match the hostname of the cluster entry point.  As the URL of your implementation is now part of your code, if deploy this code from one ThingWorx instance to another, you would need to modify the hostname/port/protocol in the URL.   Consider creating a variable in the helper utility which holds the hostname/port/protocol value, making it easier to modify during deployment.   Firewall Rules: If your load balancer has firewall rules which limit the traffic to specific known IP addresses, you will need to determine which IP addresses will be used when a service is invoked from each of the ThingWorx cluster nodes, and then configure the load balancer to allow the traffic from each of these public IP address.   Alternatively, you could configure an internal IP address endpoint for the load balancer and use the local /etc/hosts name resolution of each ThingWorx node to point to the internal load balancer IP, or register this internal IP in an internal DNS as the cluster entry point.

Check out this new framework to achieving digital manufacturing success. Learn about the top 3 areas teams need to consider!    Identify a unified end goal Align it with the most impactful use cases Formulate a lasting strategy that resonates their long-term vision Discover More! 

ThingTemplate   A ThingTemplate, at it's root is nothing but a class definition. Things are instances of a ThingTemplate which encapsulates business logic for a specific asset class.   This could be equated to that of a Class in an object-oriented programming concept. ThingTemplates provides initial state & implementation of behaviour for the Things implementing it. See ThingTemplates in Help Center & Similarities to Object-Oriented Programming for more.   ThingTemplate Use Cases   It's among the many building blocks for an IoT Solution which belong to the highest level objects created and maintained, i.e. Entities. There are several Entity Types in ThingWorx allowing users to model the physical world within the virtual realm of ThingWorx platform. There are following type of entities available within ThingWorx for modeling:   Things Thing Shapes Thing Templates Additional useful read Programming for the IoT Thing-Centric vs Traditional Query Approaches Model-View-Controller (MVC)   Ways to explore the out of the box provided ThingTemplates   All the available ThingTemplates can be listed and reviewed by navigating to the /Server via the ThingWorx REST API. List of ThingTemplates can be reviewed by using one of the following : <serverName>:<portNumber>/Thingworx/Server in a web browser and then locate and click on the ThingTemplates, or by; Typing <serverName>:<postNumber>/Thingworx/ThingTemplates in the web browser Either of the above listed options will display the following list in the web browser   List of ThingTemplates List shows all available ThingTemplates i.e. ThingTemplates that were provided OOTB and the ones that were created by the users as well. Using the column isSystemObject one can verify if the displayed ThingTemplate is provided OOTB or is custom one created by the user.   Accessing ThingTemplate Class description / details   This is covered under the JavaDocs for the ThingWorx Platform API, which can be accessed via the API Documentation   Search for ThingTemplate for following result   API Documentation: ThingTemplate While creating a custom ThingTemplate outside of ThingWorx composer, e.g. creating ThingWorx extension it is must to have following two entities in the metadata.xml file.     <Entities> <ThingTemplate> </ThingTemplate> </Entities> Note: If Eclipse Plugin is used for creating the ThingTemplate, above mentioned entries will automatically be created in the metadata.xml     Tips & tricks How to modify Base Template for a ThingTemplate for a Thing How to iterate through list of Things to identify their ThingTemplate & based on that set a particular property in those Things Add run time permissions through script to Thing Templates, Thing Shapes, etc Changing a Thing's implemented ThingTemplate after it has been created in ThingWorx Basic troubleshooting  Error "Thing [] is not running" when editing ThingTemplates in ThingWorx Troubleshooting Entity Relationship issues in ThingWorx Best Practises How to search for All entities in ThingWorx or by Thing Type How to create custom ThingTemplate when developing custom ThingWorx Extension Inheriting Permissions from a ThingTemplate      

This Best Practices document should offer some guidelines and tips & tricks on how to work with Timers and Schedulers in ThingWorx. After exploring the configuration and creation of Timers and Schedulers via the UI or JavaScript Services, this document will also highlight some of the most common performance issues and troubleshooting techniques.   Timers and Schedulers can be used to run jobs or fire events on a regular basis. Both are implemented as Thing Templates in ThingWorx. New Timer and Scheduler Things can be created based on these Templates to introduce time based actions. Timers can be used to fire events in a certain interval, defined in the Timer's Update Rate (default is 60000 milliseconds = 1 minute). Schedulers can be used to run jobs based on a cron pattern (such as once a day or once an hour). Schedulers will also allow for a more detailed time based setup, e.g. based on seconds, hours, days of week or days months etc. Events fired by both Timers and Schedulers can be subscribed to with Subscriptions which can be utilized to execute custom service scripts, e.g. to generate "fake" or random demo data to update Remote Things in a test environment. In general subscriptions and scripts can be used to e.g. run regular maintenance tasks or periodically required functions (e.g. for data aggregation) For more information about setting up Timers and Schedulers it's recommended to also have a look at the following content:   How to set up and configure Timers How to set up and configure Schedulers How to create and configure Timers and Schedulers via JavaScript Services Events and Subscriptions for Timers and Schedulers   Example   The following example will illustrate on how to create a Timer Thing updating a Remote Thing using random values. To avoid any conflicts with permissions and visibility, use the Administrator user to create Things.   Remote Thing   Create a new Thing based on the Remote Thing Template, called myRemoteThing. Add two properties, numberA and numberB - both Integers and marked as persistent. Save myRemoteThing. Timer Thing   Create a new Thing based on the Timer Template, called myTimerThing. In the Configuration, change the Update Rate to 5000, to fire the Event every 5 seconds. User Context to Administrator. This will run the related services with the Administrator's user visibility and permissions. Save myTimerThing. Subscriptions   To update the myRemoteThing properties when the Timer Event fires, there are two options: Configure a Subscription on myRemoteThing and listen to Timer Events on the myTimerThing. Configure a Subscription on myTimerThing and listen to Timer Events on itself as a source. In this example, let's go with the first option and Edit myRemoteThing. Create a new Subscription pointing to myTimerThing as a Source. Select the Timer Event Note that if no source is selected, the Timer Event is not availabe, as myRemoteThing is based on the Remote Thing Template and not the Timer Template Enable the Subscription. In the Script area use the following code to assign two random numbers to the Thing's custom properties: me.numberA = Math.floor(Math.random() * 100); me.numberB = Math.floor(Math.random() * 100); Save myRemoteThing. Validation   The Subscription will be enabled and active on saving it. Switch to the myRemoteThing Properties Refreshing the Values will show updates with random numbers between 0 and 99 every 5 seconds (Timer Update Rate).   Performance considerations   Timers and Schedulers are handled via the Event Processing Subsystem. Metrics that impact current performance can be seen in Monitoring > Subsystems > Event Processing Implementing Timers and Schedulers on a Thing Template level might flood the system with services executions originating from Subscriptions to Timer / Scheduler triggered Events. Subscribing to another Thing's Events will be handled via the Event Processing Subsystem. Subscribing to an Event on the same Thing will not be handled via the Event Processing Subsystem, but rather execute on the already open in memory Thing. If Timers and Schedulers are not necessarily needed, the Services can be triggered e.g. via Data Change Events, UI Interactions etc. Recursion can be a hidden performance contributer where a Subscription to a certain Event executes a service, triggering another Event with recursive dependencies. Ensure there are no circular dependencies and service calls across Entities. If possible, reads for each and every action from disk should be avoided. Performance can be increased by storing relevant information in memory and using Streams or Datatables or for persistence. If possible, call other Services from within the Subscription instead of handling all code within the Subscription itself. For full details, see also Timers and Schedulers - Best Practice   How to identify and troubleshoot technical issues   Check the Event Processing Subsystem for any spikes in queued Events (tasks submitted) while the total number of tasks completed is not or only slowly increasing. For a historical overview, search the ApplicationLog for "Thingworx System Metrics" to get system metrics since the server has been (re-) started. In the ApplicationLog the message "Subsystem EventProcessingSubsystem is started" indicates that the Subsystem is indeed started and available. Use custom loggers in Services to get more context around errors and execution in the ScriptLog Custom Loggers can be used to identify if Events have fired and Subscriptions are actually triggered Example: logger.debug("myThing: executing subscribed service") For issues with Service execution, see also CS268218 Infinite loops in Services could render the server unresponsive and might flood the system with various Events To change the timing for a Timer, restarting the Thing is not enough. The Timer must be disabled and enabled at the desired start time. Schedulers will allow for a much more flexible timing and setting / changing execution times in advance. For further analysis it's recommended to generate Thread Dumps to get more information about the current state of Threads in the JVM. The ThingWorx Support Tools Extension can help in generating those. See also CS245547 for more information and usage.

Events   Timers and Schedulers both come with a specific Event inherited from the Thing Template: Timer ScheduledEvent Both have a Data Shape allowing to capture the timestamp of when the Event was actually fired. Events in ThingWorx are triggered when a specific condition is met. In this context the condition is met and the Event is fired when a Timer has expired or a Scheduler's time is reached. Once an Event is triggered, Subscriptions will take care of executing custom Services to react to the Event. Subscriptions   Subscriptions listen to Events and can be used to react to certain Events with running custom Service scripts. To follow-up on Timers and Schedulers, a new Subscription must be created, listening to any related Event fired. Add a new Subscription to the Thing with       As the Subscription is usually listening to the Thing that it is configured on, the Source has to be left empty. When listening to other Entities' Subscriptions the corresponding Entity can be picked in the Source Entity picker. Ensure to check the Enabled checkbox to actually enable the Subscription and allow it for executing code in the Script area. The following Script will log into the ScriptLog once the Timer Event is fired     The following Script will log into the ScriptLog once the ScheduledEvent Event is fired  

Create a new Thing using the Scheduler Thing Template. The Scheduler Thing will fire a ScheduledEvent Event when the configured schedule is fired. The event is automatically present and does not need to be added manually. Configuration   The Scheduler Configuration is quite straightforward and allows for an exact setup of schedule based on units of time, e.g. seconds, minutes, hours, days of week etc. It can be accessed via the Thing's Entity Configuration   Configuration allows for Changing the runAsUser context - in which the Events will be handled. The user will need visibility and permission on e.g. executing Services or depending Things, which are required to run the Service triggered by the Event. Changing the Schedule - in which time the Events will be fired (by default every minute). The schedule is displayed in CRON String notation and can be changed and viewed in detail by clicking on "More". The CRON String will be generated automatically based on the inputs. Schedules can be configured in Manual mode - allowing for full configuration of each and every time based attribute. Schedules can be configured for a specific time Type - allowing for configuration only based on seconds, minutes, hours, days, weeks, months or years. Below screenshots show schedules running every minute and every Saturday / Sunday at 12:00 ("Every Weekend Day").     Services   Scheduler Things inherit two Services by default from the Thing Template DisableScheduler EnableScheduler These will activate / de-activate the Scheduler and allow / disallow firing Events once a scheduled time is reached If a Scheduler is currenty enabled or disabled can be seen in its properites  

Create a new Thing using the Timer Thing Template. The Timer Thing will fire a Timer Event when the Timer's Update Rate has expired. The event is automatically present and does not need to be added manually. Configuration   The Timer Configuration is quite straightforward. It can be accessed via the Thing's Entity Configuration. Configuration allows for Enabling the Timer on Thing-Startup - whenever the Thing is started, e.g. when restarting ThingWorx or via the RestartThing Generic Service, also the Timer is enabled and will fire Events. Changing the Update Rate - in which intervall the Events will be fired (by default every minute [60000 milliseconds]). Changing the User Context - in which the Events will be handled. The user will need visibility and permission on e.g. executing Services or depending Things, which are required to run the Service triggered by the Event.           Services   Timer Things inherit two Services by default from the Thing Template DisableTimer EnableTimer These will activate / de-activate the Timer and allow / disallow firing Events once the Update Rate has expired If a Timer is currently enabled or disabled can be seen in its properties  

Connectors allow clients to establish a connection to Tomcat via the HTTP / HTTPS protocol. Tomcat allows for configuring multiple connectors so that users or devices can either connect via HTTP or HTTPS.   Usually users like you and me access websites by just typing the URL in the browser's address bar, e.g. "www.google.com". By default browsers assume that the connection should be established with the HTTP protocol. For HTTPS connections, the protocol has to be specified explictily, e.g. "https://www.google.com"   However - Google automatically forwards HTTP connections automatically as a HTTPS connection, so that all connections are using certificates and are via a secure channel and you will end up on "https://www.google.com" anyway.   To configure ThingWorx to only allow secure connections there are two options...   1) Remove HTTP access   If HTTP access is removed, users can no longer connect to the 80 or 8080 port. ThingWorx will only be accessible on port 443 (or 8443).   If connecting to port 8080 clients will not be redirected. The redirectPort in the Connector is only forwarding requests internally in Tomcat, not switching protocols and ports and not requiring a certificate when being used. The redirected port does not reflect in the client's connection but only manages internal port-forwarding in Tomcat.   By removing the HTTP ports for access any connection on port 80 (or 8080) will end up in an error message that the client cannot connect on this port.   To remove the HTTP ports, edit the <Tomcat>\conf\server.xml and comment out sections like       <!-- commented out to disallow connections on port 80 <Connector port="80" protocol="org.apache.coyote.http11.Http11NioProtocol" connectionTimeout="20000" redirectPort="443" /> -->     Save and restart Tomcat. If opening Tomcat (and ThingWorx) in a browser via http://myServer/ the connection will fail with a "This site can’t be reached", "ERR_CONNECTION_REFUSED" error.   2) Forcing insecure connections through secure ports   Alternatively, port 80 and 8080 can be kept open to still allow users and devices to connect. But instead of only internally forwarding the port, Tomcat can be setup to also forward the client to the new secure port. With this, users and devices can still use e.g. old bookmarks and do not have to explicitly set the HTTPS protocol in the address.   To configure this, edit the <Tomcat>\conf\web.xml and add the following section just before the closing </web-app> tag at the end of the file:     <security-constraint>        <web-resource-collection>              <web-resource-name>HTTPSOnly</web-resource-name>              <url-pattern>/*</url-pattern>        </web-resource-collection>        <user-data-constraint>              <transport-guarantee>CONFIDENTIAL</transport-guarantee>        </user-data-constraint> </security-constraint>     In <Tomcat>\conf\web.xml ensure that all HTTP Connectors (port 80 and 8080) have their redirect port set to the secure HTTPS Connector (usually port 443 or port 8443).   Save and restart Tomcat. If opening Tomcat (and ThingWorx) in a browser via http://myServer/ the connection will now be forwarded to the secure port. The browser will now show the connection as https://myServer/ instead and connections are secure and using certificates.   What next?   Configuring Tomcat to force insecure connection to actually secure HTTPS connection just requires a simple configuration change. If you want to read more about certificates, encryption and how to setup ThingWorx for HTTPS in the first place, be sure to also have a look at   Trust & Encryption - Theory Trust & Encryption - Hands On

ThingWorx Manufacturing Tips & Tricks Webinar is a weekly opportunity to hear PTC Subject Matter Experts present on various topics related to the manufacturing space and applications.   Agenda for this week's recorded session - - Manufacturing Apps Overview - Christine Bahmer - Insight CM Integration - Aron Semle - 3rd Party Systems Integration - Varathan Ranganathan - Q&A