IoT & Connectivity Tips

Meet Neal. When Neal joined PTC five years ago, he immediately hit the ground running on IoT initiatives, working in multiple areas ranging from pre-sales to partner relations. Today, he is a Worldwide ThingWorx Center of Excellence Principal Lead at PTC, and his biggest focus is supporting the go-to-market for the Microsoft partnership.   I sat down with Neal recently to hear the details on exactly how Azure and ThingWorx can be used to develop world-class IIoT applications.   Kaya: Can you explain how Azure and ThingWorx work together? Neal: Yes, so Azure provides the cloud infrastructure that our customers need in order to deploy ThingWorx.   By having Azure as our preferred cloud platform, we’re able to specialize our R&D efforts into utilizing functionality that is available in Azure, rather than having to reinvent the wheel ourselves for each cloud platform in the attempt to remain cloud-agnostic. By leveraging a single, already quite powerful, cloud platform through Azure, we’re able to maximize our development efforts.   Kaya: What was the major problem that led to us investigating cloud options? Neal: There were two issues that our users had. The first was we often had complicated installs and setup procedures because we were genericizing the whole process, so the initial setup and run was complicated and expensive. For example, we were requiring them to setup additional VMs and components, and we were giving them generic instructions because we were being very agnostic, when they had already chosen outside of us to use one of the cloud platforms. We knew our customers wanted to move fast, so we had to make it easier and faster for them to see results.   The other issue we ran into with customers was the confusion in the offerings. For ThingWorx, ingest is just one aspect of IoT. ThingWorx is particularly strong in areas like enabling mixed reality and augmented reality as well as application enablement. And, while we also have the ability to perform ingest capabilities, Microsoft is especially powerful when it comes to ingest capabilities and security. We decided that the smartest solution was to leverage Microsoft’s expertise in data ingestion to make ThingWorx even more powerful; so, we made the Azure IoT Hub Connector. By partnering with Microsoft, we have joint architecture where you can see how Microsoft provides key features and ThingWorx will run on top of those features and get you faster to the market to develop the application.   Below is an example of a high-availability deployment of ThingWorx on Azure that utilizes ThingWorx Azure IoT Connectors to access an Azure IoT Hub.  High-Availability Deployment of ThingWorx on Azure Kaya: Why did we partner with Azure? What specific benefits does Azure offer over other cloud services providers? Neal: When we started to look at what our customers were using for cloud services, we noticed that a lot were using Microsoft. When we join forces with Microsoft, we have a much more wholistic offering around digital transformation. With the partnership, PTC and Microsoft are able to leverage each partner’s respective strengths to provide even more powerful IIoT solutions. You have Windchill and Microsoft’s business application strategies; you have Vuforia and Microsoft’s mixed reality and augmented reality strategies; and, you have ThingWorx on the Microsoft Azure cloud. Overall, you have a much more complete and powerful offering together.   Kaya: What is your favorite aspect about working at PTC? Neal: The growth. There’s been a lot of changes over the last five years that I’ve been here. PTC has been able to leverage its strengths and long-time experience in the CAD and PLM markets to enter and ultimately become a leader in the IIoT market, according to reports by research firms like Gartner and Forrester. In short, the growing IIoT market and PTC’s leadership in the industry.   Note to Readers: You’ve likely heard about our major strategic partnership with Microsoft to leverage our respective IIoT and cloud technologies to optimize the creation, deployment, management and overall use of your IIoT applications. If you haven’t heard about the partnership, check out the press release here. If you’re curious about more aspects of PTC’s partnership with Microsoft, check out this site devoted to sharing how ThingWorx and Azure are better together.

Just like the perfect sandwich, we know that you have specific preferences and requirements for your ThingWorx deployment. Whether you like to keep things simple with a classic grilled cheese or you like to spice things up with a more elaborate chipotle mayo BLT, we’ve got you covered. Our ThingWorx Deployment Architecture Guide explains what you’ll need to deploy ThingWorx in three different scenarios: production, enterprise and high-availability (pictured below).   Deployment Architecture for ThingWorx on Azure in High-Availability We’ve recently published Version 1.1 of the ThingWorx Deployment Architecture Guide. In it, you can find updated deployment architecture diagrams to more distinctly show the data and application layers within a ThingWorx environment. Our team has also added a new section on what you’ll need to deploy ThingWorx on Microsoft Azure, PTC’s preferred cloud platform.   Check it out here or in the attachment section on the right.   Stay connected, Kaya

I got this excellent question and I thought it worthwhile to put my answer here as well.   There are two ways to segregate information between clients. By default we use a ‘software’ approach to segregation by using Organizations. This allows you to designate a Client to an Organization/Organizational nodes and give those nodes ‘visibility’ to specific entities within the software. This will mean that ‘through software logic’ users can only see what they’ve been given visibility to see. This mainly applies to all the client’s equipment (Thingworx Things). They can only see their own equipment. This would also apply to a specific set of their data which is ValueStream data because that can only be retrieved from the perspective of a Thingworx Thing   Blog/Wiki/DataTable/Streams can store data across clients and do not utilize visibility on a row basis, in this case appropriate queries would need to be created to allow retrieval for only a specific client. In this case we use a construct for security that utilizes what we call the ‘system user’ and wrapper routines that work of the CurrentUser context, this allows you to create enforced validated queries against the data that will allow a user to only retrieve their specific data.   In regards to the data itself, if you need to, you can provide actual ‘physical’ segregation by using multiple persistence provider and mapping Blog/Wiki/DataTable/Streams/ValueStreams to different persistence providers. Persistence providers are basically additional database schemas (in one and the same database or different database) of the Thingworx data storage schema, allowing you to completely separate the location of where data is stored between clients. Note that just creating unique Blog/Wiki/DataTable/Streams/ValueStreams per client and using visibility is still only a logical / software way of providing segregation because the data will be stored in one and the same database schema also known as the Thingworx data persistence provider.

In this session, we pick up where we left off with the mashup which was worked on in part 1 of our Advanced Mashup Expert Session series. Specifically, we will explore the concepts of master mashups, session variables, and media entities, using each to further enhance the look and feel of our mashup.     For full-sized viewing, click on the YouTube link in the player controls. Visit the Online Success Guide to access our Expert Session videos at any time as well as additional information about ThingWorx training and services.

This video builds upon the mashup created in the basic session, and strives to create a more polished, user-friendly interface that is ready for deployment. In part 1, we’ll take a look at advanced layout designs and include a more varied set of widgets to help draw attention to some of the more pertinent properties being captured within the mashup.   For full-sized viewing, click on the YouTube link in the player controls. Visit the Online Success Guide to access our Expert Session videos at any time as well as additional information about ThingWorx training and services.  

Underneath video walks through how to Publish a Model from Analytics Builder into Analytics Manager using the connector named TW.AnalysisServices.AnalyticsServer.AnalyticsServerConnector.

Previously Installing & Connecting C SDK to Federated ThingWorx with VNC Tunneling to the Edge device   Pre-requisite Download and install Web Sockets Tunnels Widget and Library Extension from PTC Marketplace   Configuring Tunnel Subsystem   1. Logon to ThingWorx Composer > System > Tunnel Subsystem > Configuration 2. Public host name used for tunnels & Public port used for tunnels parameters require publically address FQDN or IP of the instance running ThingWorx server and the port on which its listening. 3. From the screenshot above the TW802Neo is the name of the server and 443 is the port configured for ThingWorx to listen on 4. Navigate back to the RemoteThing we created above to connect our C SDK client to on the ThingWorx platform and ensure that the Enable Tunnelling is turned on   5. Click on Configuration and click Add My Tunnel button to configure where should the tunnel be opened to   6. In the above example Host and Port parameter is from the Ubuntu machine were my C SDK client is running together with the VNC server. If you are looking for more detail on how to configure these topics refer to the Simple diagnostic utility to analyse tunneling performance in ThingWorx 7. Once done, Save the entity   Configuring Remote Access & WebSocket tunnel widgets in a Mashup   1. Navigate to the ThingWorx Composer > Visualization > Mashups > New to create a Mashup 2. From the list of Widgets drag and drop following two widgets that are added as part of the Web Socket Tunnel Widget and Library extension Remote Access Web Socket Tunnel AcceptSelfSignedCert (if you are configuring ThingWorx with self-signed certificate)   4. Since I have my C SDK client binding to SteamSensor2 (remember it was created with RemoteThingWithTunnel ThingTemplate) I have that selected that as RemoteThingName 5. TunnelName is the vnc as configured in the SteamSensor2 configuration 6. For Web Socket Tunnel Widget following configuration is required RemoteThingName TunnelName VNCPassword 7. Parameters defined in a & b point are exactly the same as already done for the Remote Access Widget parameter above, the VNCPassword is the same password with which you have configured your VNC server with   8. Once done Save the mashup and View it   9. Click on the Remote Access to download the websocket adapter plugin, once downloaded click on it to initiate the websocket you will be prompted with following     Accept and Run   This will open the Remote tunnel with following confirmation, Don't click on OK else it will close   You can now utilize this tunnel to perform required action. Note that if in case there is no connection through this opened tunnel it will time out and will close automatically. 10. For doing remote desktop to the edge device I will use the Remote Device button , which will open a new browser window like so 11. Click on Connect to initiate the remote desktop session, like so 12. I can now start the terminal on the edge device and navigate through    Up Next Configuring ThingWorx Federation for Fetching data from the C SDK client from Publisher to subscriber ThingWorx entity

Content Configuring ThingWorx C SDK Configuring C SDK client example for Tunneling Accepting Self Signed certificate Installing and configuring VNC Extension on ThingWorx Platform Configuring Tunnel Subsystem Configuring Remote Access & WebSocket tunnel widgets in a Mashup Setting up Federated ThingWorx   NOTE : For sake of brevity I'll divide this blog in sub blogs and will link them where ever needed.   Configuring ThingWorx C SDK   Pre-requisite Ensure that following two utilities are installed Cmake Make For linux platform both will likely be pre-installed Have ThingWorx configured with self-signed certificate (optional), refer to this article ThingWorx setup SSL / HTTPS on Tomcat with Self-Signed Certificate Create a Thing to which you want to bind to from the csdk example, e.g. create SteamSensor2 with ThingTemplate RemoteThingWithTunnels (below screenshot shows ThingTemplate RemoteThingWithTunnelsAndFileTransfer - this is not must for this blog we just need RemoteThingWithTunnels as we want to have our thing connected to receive property updates and also do tunneling)   Create an Application key with user that has sufficient access rights to work with remote entities Install and configure VNC server for tunneling using this blog Tunneling with ThingWorx and an Edge Device Note : Above mentioned blog is done using ThingWorx Edge Microserver, however we are only interested in installation and configuration related to the VNC server. You don't need to configure the edge device for tunneling from the above mentioned blog as we will do this later in this blog for C SDK.   Installing, configuring and launching the C SDK based client on Linux platform   To begin with ensure that you have downloaded the ThingWorx C SDK from PTC Marketplace or PTC Software Download page. Let's configure the CSDK 1. Navigate to the C SDK root directory and create a directory e.g. /csdk/cmake 2. Change directory into cmake/ 3. Check for the available compilers on the platform, with command cmake -G list   4. Choose as per your requirement, for our example here 'll pick "Unix Makefiles" Note : I'm compiling on Ubuntu 16 OS 5. Execute following command from csdk/cmake/ , eg. cmake -G "Unix Makefiles" ..   This will result in following compilation details : 6. Cmake folder now have some build files created  7. Configure the example SteamSensor for tunneling and for accepting self-signed certificate, as my ThingWorx is currently configured with HTTPS 8. Navigate to root directory and edit the main.c for SteamSensor, e.g. sudo gedit main.c Note: Feel free to use any editor of your choice, I'm using gedit Add following to enable tunneling and accepting self-signed certificates     #define ENABLE_TUNNELING 1 void twApi_SetSelfSignedOK();   9. Save the file and close 10. Make the solution to create executable out of the example SteamSensor we edited 11. Navigate to the SteamSensor example under the cmake e.g. 12. Key in command make and press enter, e.g. ~/csdk/cmake/examples/SteamSensor$ make This will build the solution and once finished it will put some new files and an executable file in the /csdk/cmake/examples/SteamSensor       Once the build is finished,    Great! now then, let's crack on with the SteamSensor executable.   13. To launch the executable it requires following syntax ./SteamSensor <hostname> <port> <appKey> <thingname> , e.g. ./SteamSensor tw802neo 443 11c784ab-dde7-400f-b244-fd7c4b217869 SteamSensor2 14. Once launched & if its successfully connected you can check the remote entity created in ThingWorx Composer, as we can see below entity as connected. Notice that in below screenshot there are some sample properties that are being pushed from the C SDK based client. You may not have them at first   15. In case you see isConnected as true but no property listed for your Thing, edit the Thing and click on Manage Bindings     Click on Remote tab to see which properties are pushed, then you have the option to either click on Add All Above Properties on the right side, which will automatically create properties under the Thing, or you can drag and drop properties on the right to bind with if you are using properties with different name. Ensure that the data type matches with the remote properties.     Done and Save.   So far C SDK installed and configured VNC server installed A Thing created with RemoteThingWithTunnel ThingTemplate An Application key to connect C SDK based client to RemoteThing in ThingWorx Bound remote properties from the C SDK client built above to the Remote Thing on ThingWorx Up Next Installing and configuring Web Socket Tunnel Extension on ThingWorx Platform Configuring ThingWorx Federation

Disclaimer: This post does of course not express any political views.   Pie Chart Coloring   In ThingWorx Pie Charts use a default color schema based on the DefaultChartStyle Definitions. These schemas are using fixed numbering and coloring systems, e.g. 1 is blue, 2 is green, 3 is red and so on. All Pie Charts will be rendered with these colors in the same order, no matter which data the chart is using. Visualization of data with the default colors might not necessarily help in creating an easy to read chart.   Just take a look at the following example with the default color schema. Let's just take political parties - as they are usually associated with a distinct color - to illustrate how the default color schema will fail depending on the data displayed.         In the first example, just by sheer coincidence the colors are perfectly matching the parties. When introducing a new party to the pool suddenly the blues are rendered green and the yellows rendered light-blue etc. This can be quite confusing, especially on election night 😉   Custom Color Schema   PoliticalParties Thing   To test a custom color schema, we first need to create a new Thing: PoliticalParties as a GenericThing Add a dataset property with the following PoliticalParties DataShape.         Save the Thing and set the InfoTable to:   Key Value The Purples 20 The Blues 20 The Greens 20 The Reds 20 The Yellows 20 Others 20   Number values don't actually matter too much, as the Pie Chart will automatically distribute them according to their percentage.   PoliticalParties Mashup   Create a new Mashup and add a PieChart to the canvas. Bind the PoliticalParties > GetPropertyValues > dataset to the Data input of the Widget. Ensure to set the LabelField to key and the ValueField to value for a correct mapping.     Save the Mashup and preview it.   It should show a non-matching color for each party listed in the InfoTable.   Custom Styles and States   Create new custom Style Definitions for each political party. As the Pie Chart is only using the Background Color other properties can stay on the default. I chose to go with a more muted version of the colors to make the chart easier to look at.         With the newly defined colors we can now generate a new State Definition as follows:       The States allow to evaluate the key-Strings in the Thing's InfoTable and assign a Style Definition depending on the actual value. In this definition we map a color schema based on the InfoTable's key-value to create a 1:1 mapping for the Strings.   This means, no matter where a certain party is positioned in the chart it will be tinted with its associated color.   Refining the Mashup   Back in the Mashup, select the PieChart. In the ColorFormat property choose the newly created State Definition.     Save the Mashup and preview it. With the States and Styles applies, colors are now displayed correctly.       Even when changing positions and numbers in the original InfoTable of the PoliticalParties Thing, the chart now considers the mapping of Strings and still displays the colors correctly.  

Saw this great question in the Developers forum https://community.ptc.com/t5/ThingWorx-Developers/Thingworx-Permission-Hierarchy/m-p/556829#M29312. Answered it there, copying it to here: Question Hi, I have a few of questions regarding the permissions model in Thingworx. I can't find any documentation that explains it clearly. Hoping someone can help, or point me in the right direction for more in depth documentation.   My understanding is that permissions can be set at a number of different levels.  Collection Level Template Level Instance Level Thing level My question is, how do these levels interact with one another. Do they all get 'AND'ed together, or do those at the lower levels supersede the ones set at higher levels. e.g.  If I set some visibility at collection level would this overridden by me setting a different visibility at say the Template instance level, or would both visibility permissions be valid. At each of level there is the ability to override (e.g. for a particular property or service). How does that fit in the hierarchy. I have read that in Thingworx 'deny' always supersedes an 'allow' permission. Is this still the case if I set deny at collection level and then at a lower level I gave 'allow' permissions would the deny take precedence. As far as I can tell 'Create' permissions can only be set at collection level. Does this mean that I am unable to restrict one set of users to create things of one template, and a different set of users to create another type of thing. Thanks in advance for any replies   Answer: Great question Thing/Entity level permissions always take precedence So if you set on Collection then on Template then on Entity it will first look at Entity then fill in with Template and Permission So if Collection says can't do Service Execute Template says Can execute Service 1 but not Service 2 Entity says Can execute Service 2 and leaves Service 1 as inherited the end result is that the user can execute service 1 and 2   In Template and Entity you can find the Override ability, that is to specifically allow or disallow the execution of a Service or read/write of a Property   What is a BEST PRACTICE? 1. Give the System user all service execute on collection level 2. Give User Groups 'blanket' permissions to Property Read/Write on ThingTemplate Level 3. Give User Groups only Override permission to execute Services on ThingTemplate Level 4. Override User Group permission to DENY property read on potential properties they are not supposed to read on the ThingTemplate Level   Generally most properties all users can access fully and the blanket permission on a ThingTemplate is fine It is very BAD to give user groups blanket permission to Service execute and should always be done by Override   Entity Hierarchy overrides the Allow Deny hierarchy, but within a single level (Collection / Template / Entity) Deny wins over Allow.   Create is indeed only set on the Collection Level, however the way to secure this is to give the System user the Create ability and create Wrapper services that use the CreateThing service which you can then secure for specific Groups. So you could create a CreateNewThingType1 and CreateNewThingType2 for example and give User Group 1 permission to Type 1 creation and User Group 2 permission to Type 2 creation.   Hope that helps.

This is going to cover one way of configuring an SSL passthrough using HAProxy.  This guide is intended to be a reference document, and administrators looking to configure an SSL passthrough should make sure the end solution meets both their company's business and security needs.   Why use SSL Passthrough instead of SSL Termination? The main reason for ThingWorx would be if a company requires encrypted communication internally, as well as externally.  With SSL Termination, the request between the load balancer and the client is encrypted.  But the load balancer takes on the role to decrypt and passes that back to the server.  With SSL Passthrough, the request goes through the load balancer as is, and the decryption happens on the ThingWorx Application server.   What you will need to continue with this guide:   HAProxy installed A working ThingWorx application server (Guide to getting one setup can be found here) Tomcat configured for ssl NOTE : Always contact your Security team and make sure you have a certificate that meets your business policy For this tutorial, I created a self-signed certificate following along with the below guide.  If you have already obtained a valid certificate, then you can just skip over the step of creating it, and follow along with the Tomcat portion https://www.ptc.com/en/support/article?n=CS193947 Once configured, restart Tomcat and verify it is working by navigating to https://<yourServer>:<port>/Thingworx   With ThingWorx running as SSL and HAProxy installed, we just need to make sure the HAProxy configuration is setup to allow SSL traffic through.  We use 'mode tcp' to accomplish this.   On your HAProxy machine, open /etc/haproxy/haproxy.cfg for editing.  While most of this can be customized to fit your business needs, some variation of the highlighted portions below need to be included in your final configuration:   global         log /dev/log    local0         log /dev/log    local1 notice         chroot /var/lib/haproxy         stats socket /run/haproxy/admin.sock mode 660 level admin         stats timeout 30s         user haproxy         group haproxy         daemon           # Default SSL material locations         ca-base /etc/ssl/certs         crt-base /etc/ssl/private           # Default ciphers to use on SSL-enabled listening sockets.         # For more information, see ciphers(1SSL). This list is from:         #  https://hynek.me/articles/hardening-your-web-servers-ssl-ciphers/         # An alternative list with additional directives can be obtained from         #  https://mozilla.github.io/server-side-tls/ssl-config-generator/?server=haproxy         ssl-default-bind-ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:RSA+AESGCM:RSA+AES:!aNULL:!MD5:!DSS         ssl-default-bind-options no-sslv3   defaults         log global          option tcplog          mode tcp          option http-server-close          timeout connect 1s          timeout client  20s          timeout server  20s          timeout client-fin 20s          timeout tunnel 1h          errorfile 400 /etc/haproxy/errors/400.http          errorfile 403 /etc/haproxy/errors/403.http          errorfile 408 /etc/haproxy/errors/408.http          errorfile 500 /etc/haproxy/errors/500.http          errorfile 502 /etc/haproxy/errors/502.http          errorfile 503 /etc/haproxy/errors/503.http          errorfile 504 /etc/haproxy/errors/504.http         frontend https          bind *:443          mode tcp          default_backend bk_app           backend bk_app          mode tcp          server TWXAPP01  <twxapp01IP>:<port>         In this example, the user would connect to https://<loadbalancer>/Thingworx and the load balancer would forward the requests to https://<twxapp01IP>:<port>/Thingworx   That’s it!   A couple of side notes:   The load balancer port the clients connect to does not need to be the same as the ThingWorx port the load balancer will forward to If working in a Highly Available configuration, each ThingWorx Application server needs to have its own certificate configured If HAProxy seems unstable, try updating to the latest release If it is on the latest release according to the Unix repository, check https://www.haproxy.org/ and see if there is a later stable release.  There have been some issues where Ubuntu's latest update in the repository is actually a few years old

One of the interesting features of ThingWorx Analytics Manager is its ability to run distributed models created in Excel (and more of course).  Most people having been tasked with understanding data have built models in Excel and have sometimes built quite complex models (or even applications) with it.   The ability to tie these models to real data coming from various systems connected through ThingWorx and operationalise their execution is a really simple way for people to leverage their existing work and I.P. on a connected analytics journey.   To demonstrate this power and ease of implementation, I created a sample data set with historical data, traffic profile, and a simple anomaly detection model to execute with Analytics Manager.  (files are attached)   The online help center was quite helpful in explaining the process of Creating the Excel Workbook, however I got stuck at the XML mapping stage.  The Analytics and Excel documentation both neglect to mention one important detail -- you must be using the Windows version of Excel in order to get the XML Source functionality (and I use Mac).  Once using Windows, it was easy to do - here is a video of the XML mapping part of the process (for the inputs and results).   

I always find it difficult to remember which version of software is supported with which version of ThingWorx, so I created a table for my reference. I hope this is also helpful to other people.   　 Oracle JDK Tomcat Database Options Memo PostgreSQL Neo4J H2 Microsoft SQLServer SAP HANA DetaStax Enterprise Edition ThingWorx 6.5 1.8.0(64-bit) 8.0.23(64-bit) 9.4.4 embedded N/A N/A N/A N/A IE 10 ThingWorx 6.6 1.8.0(64-bit) 8.0.23(64-bit) 9.4.4 embedded N/A N/A N/A N/A 　 ThingWorx 7.0 1.8.0(64-bit) 8.0.23(64-bit) 9.4.? embedded N/A N/A N/A N/A 　 ThingWorx 7.1 1.8.0_92-b14(64-bit) 8.0.33(64-bit) 9.4.5 embedded N/A N/A N/A 4.6.3 　 ThingWorx 7.2 1.8.0_92-b14(64-bit) 8.0.33(64-bit) 9.4.5 embedded embedded N/A N/A 4.6.3 IE 11 and later ThingWorx 7.3 1.8.0_92-b14(64-bit) 8.0.38(64-bit) 9.4.5 embedded embedded N/A SPS 11, 12 4.6.3, 5 　 ThingWorx 7.4 1.8.0_92-b14(64-bit) 8.0.38(64-bit) 9.4.5 embedded embedded 2014 and later SPS 11, 12 4.6.3, 5 　 ThingWorx 8.0 1.8.0_92-b14(64-bit) 8.0.44(64-bit), 8.5.13(64-bit) 9.4.5 embedded embedded 2014 and later SPS 11, 12 4.6.3, 5 　 ThingWorx 8.1 1.8.0_92-b14(64-bit) 8.0.44(64-bit), 8.5.13(64-bit) 9.4.5 embedded embedded 2014 and later SPS 11, 12 4.6.3, 5 　 ThingWorx 8.2 1.8.0_92-b14(64-bit) 8.0.47(64-bit), 8.5.23(64-bit) 9.4.5 embedded embedded 2014 and later SPS 11, 12 4.6.3, 5 　 ThingWorx 8.3 　 　 　 　 　 　 　 　 　

With the release of ThingWorx 8.2.1 , we now have the possibility to auto provision the user attributes along with the user on its first login in ThingWorx via Active Directory Authentication. In the previous releases this was not available and after the initial user provisioning, users had to fill in rest of the user attribute details e.g. zipCode, City, Title, MobilePhone , etc. However with ThingWorx 8.2.1 and later we have following new attributes for configuration when the Active Directory entity is created in ThingWorx, namely   activeDirectoryAttributeName userExtensionPropertyName userExtensionDefaultValue activeDirectoryAttributeName : Represents the attribute within AD for an user   userExtensionPropertyName : This represents the attribute available for the user, as defined in the UserExtensions ThingShape   userExtensionDefaultValue : Default value that will be assigned in case the attribute value in AD for a particular user is empty/null   XML representation for these new tags     <ConfigurationTable description="User Extension Property Mapping Configuration Table" isMultiRow="true" name="UserExtensionPropertyMapping" ordinal="6"> <DataShape> <FieldDefinitions> <FieldDefinition aspect.friendlyName="Active Directory Attribute Name" baseType="STRING" description="Active Directory Attribute Name" name="activeDirectoryAttributeName" ordinal="0"/> <FieldDefinition aspect.friendlyName="Provisioned User's User Extension Property Default Value" baseType="STRING" description="Provisioned User's User Extension Property Default Value" name="userExtensionDefaultValue" ordinal="2"/> <FieldDefinition aspect.friendlyName="Provisioned User's User Extension Property Name" aspect.isPrimaryKey="true" baseType="STRING" description="Provisioned User's User Extension Property Name" name="userExtensionPropertyName" ordinal="1"/> </FieldDefinitions> </DataShape> <Rows> <Row> <activeDirectoryAttributeName> <![CDATA[userPrincipalName]]> </activeDirectoryAttributeName> <userExtensionDefaultValue> <![CDATA[blah]]> </userExtensionDefaultValue> <userExtensionPropertyName> <![CDATA[emailAddress]]> </userExtensionPropertyName> </Row> <Row> <activeDirectoryAttributeName> <![CDATA[streetAddress]]> </activeDirectoryAttributeName> <userExtensionDefaultValue> <![CDATA[SomeDefaultValue]]> </userExtensionDefaultValue> <userExtensionPropertyName> <![CDATA[mailingAddress]]> </userExtensionPropertyName> </Row> <Row> <activeDirectoryAttributeName/> <userExtensionDefaultValue> <![CDATA[DefaultValue]]> </userExtensionDefaultValue> <userExtensionPropertyName> <![CDATA[title]]> </userExtensionPropertyName> </Row> <Row> <activeDirectoryAttributeName> <![CDATA[DefaultDemoTitle]> </activeDirectoryAttributeName> <userExtensionDefaultValue/> <userExtensionPropertyName/> </Row> <Row> <activeDirectoryAttributeName/> <![CDATA[pincode]> <userExtensionDefaultValue/> <userExtensionPropertyName> <![CDATA[zipCode]]> </userExtensionPropertyName> </Row> </Rows> </ConfigurationTable   Note: This is not a complete XML file for creating the Active Directory entity in ThingWorx, rather only a part of the XML for basic initial XML configuration refer to the Managing Users in Active Directory section in Security > Directory Service Authentication in ThingWorx Help Center   With the above configuration once the Active Directory entity is successfully created under the ThingWorx Composer > Security > Directory Services, navigate to it and scroll down to the section named User Extension Property Mapping Configuration Table   Configuration for Directory Service Extending on basic structure Once the Active Directory entity is successfully created and connected to the target Active Directory, all the users that now gets provisioned from Active Directory within ThingWorx will get their attributes filled up automatically, given that the mapping is correct and the value actually exists in Active Directory for those mapped attributes, something like this     PS: Attributes not mapped will be left blank in the user's user extension properties   Auto populating of entities will also happen even after the user has been created on first login. Meaning if there are further AD attributes which are mapped with the user's user extension properties, value for them will also be pulled on next login done by the user there is no need for ThingWorx restart here.   As shown in the screenshot above for section User Extension Property Mapping Configuration Table, these values can be added or deleted.   Pitfalls to avoid It may happen that despite the mapping values may not auto populate, for such scenarios ensure that:   AD attribute used in the section Active Directory Attribute Name must match exactly the way it is in the AD, e.g. zipCode mentioned in the section Active Directory Attribute Name may be called as Zip Code in the AD attribute. This may likely lead to error <attribute_name> attribute not found in ApplicationLog.log Empty/invalid values in AD's user attributes will not populate the User's user extension properties Attribute names used in the column Provisioned User's User Extension Property Name also need to exactly match the way they are defined in the UserExtensions ThingShape, failing to do so will likely lead to error  Property name: {} not found in UserExtensions properties in ApplicationLog.log To void using incorrect attribute name copy out the exact property names from UserExtensions ThingShape UserExtensions ThingShape can be located in ThingWorx Composer > Modeling > Thing Shapes ; click on the UserExtensions > Properties to view all available properties UserExtensions ThingShape can also be edited to add more properties to it, which can later be used for mapping it with the AD attributes   Additional read: An enhancement jira has been filed to allow users to have a drop down menu for column Provisioned User's User Extension Property Name, for quick and accurate selection, see Some User Extension Property Mapping fails with warning "Property name: not found in UserExtensions properties" in ThingWorx

DataShape Simply put, it represents the data in your model giving your application an in-built sense on how to represent the data in different scenarios. DataShape is defined with set of field definitions and related metadata e.g. DataType. DataShapes are must have (except for ValueStream) when creating entities that deal with data storage i.e. DataTable & Stream. For more detail on  DataShapes and the DataTypes see DataShapes in ThingWorx Help Center   Note: See ThingShape : Nuances, Tips & Tricks  for ThingShape vs DataShape   Ways to create DataShape   Via the ThingWorx Composer Navigate to ThingWorx Composer click on New > DataShape Provide a unique name to the DataShape entity DataShape creation in ThingWorx Composer Navigate to the Field Definition and add required Field Definition Defining Field for the DataShape Via a custom service in ThingWorx Navigate to an entity under which the service is to be created, e.g. Thing Switch to Services section for the Thing and click Add to create new service OOTB available service CreateDataShape can be used from the Resources > EntityService // snippet creating the infotable with the var params = { infoTableName : "InfoTable", dataShapeName : "DemoDataShape" }; // CreateInfoTableFromDataShape(infoTableName:STRING("InfoTable"), dataShapeName:STRING):INFOTABLE(DemoDataShape) var result = Resources["InfoTableFunctions"].CreateInfoTableFromDataShape(params); // snippet creating the DataShape using the Infotable queried above which returns the field and the metadata on those fields // DSName used below is created as the Resources["EntityServices"].CreateDataShape({ name: DSName /* STRING */, description: "Custom created DataShape" /* STRING */, fields: result /* INFOTABLE */, tags: undefined /* TAGS */ }); Here's how it'd appear in the Service editor :   DataShape creation with JavaScript service in ThingWorx Via the ThingWorx Extension SDK   Following example snippet shows the creation and usage of the DataShape while creating custom extension with the Extension SDK    @ThingworxConfigurationTableDefinitions(tables = { @ThingworxConfigurationTableDefinition(name = "ConfigTableExample1", description = "Example 1 config table", isMultiRow = false, dataShape = @ThingworxDataShapeDefinition(fields = { @ThingworxFieldDefinition(name = "field1", description = "", baseType = "STRING"), @ThingworxFieldDefinition(name = "field2", description = "", baseType = "NUMBER") })) }) Note: Refer to the ThingShape : Nuances, Tips & Tricks for Tips & Tricks   Other related reads How are DataShape used while storing the data in ThingWorx How to pass a DataShape as parameter Can two DataShapes have the same service name if used on the same thing in ThingWorx? DataShape in ThingWorx Help Center

  The latest release of ThingWorx, version 9.7, brings powerful updates across performance, scalability, security, and developer productivity. Designed to meet the evolving demands of IoT and AR solutions, this version equips businesses with the tools to build smarter applications, improve operational efficiency, and stay ahead of the curve.   Performance & Scalability ThingWorx 9.7 introduces key updates that enhance performance and scalability for large-scale operations. The addition of partitioned value streams enables faster queries and purging of massive data sets, streamlining data management. Lazy loading for grid components optimizes application responsiveness, ensuring a seamless user experience, even in data-intensive environments. Additionally, the new Data Ordering feature ensures that ingested data is processed in the exact order it is received, even across asynchronous systems. This capability guarantees accurate execution of application logic and precise end calculations, addressing critical needs in industries requiring serialized data processing.   Reliability Enhancements Reliability is critical in enterprise applications, and ThingWorx 9.7 delivers with automated disaster recovery, providing quick failover mechanisms for deployments on the PTC Cloud. Enhanced diagnostics and tools for high-availability environments address challenges such as large cache collections, helping maintain stability and preventing bottlenecks in mission-critical systems.   Developer Productivity ThingWorx 9.7 offers developers a range of productivity-boosting features. The Mashup Builder enhancements include binding filtering, container zooming, and intuitive design tools that make application development faster and more efficient. Grid customizations, like inline editing and bulk selection, further streamline workflows. Developers also benefit from the latest Eclipse plugin, ensuring compatibility with modern tools and technologies.   Security & Compliance Security continues to be our highest priority in this release. ThingWorx 9.7 fully supports Java 21, delivering enhanced memory management and access to the latest security patches. TLS 1.3 Phase-2 integration brings advanced encryption protocols to secure communication across platforms. Additional security measures, such as granular file permissions, give administrators more control over sensitive data and operations.   Industry-Specific Solutions ThingWorx 9.7 introduces several innovative features tailored for specific industries: Route Versioning in Connected Work Cells: Manufacturers can now revise and track work cell routes with precision, creating complete traceability for serial numbers, routes, and associated work instructions. This feature streamlines workflows, enhances traceability, and boosts operational efficiency. Enhanced Operational Insights: The release includes new key performance indicators (KPIs) and reporting tools to deliver actionable insights at the factory line, site, and enterprise levels. These updates help organizations measure efficiency, reduce downtime, and improve overall productivity. Asset Muting for Chatty Devices: In scenarios where connected devices become overly chatty—sending excessive or unnecessary data—administrators can now mute these assets. This prevents data overload and mitigates risks such as distributed denial-of-service (DDoS) attacks, optimizing platform performance and ensuring uninterrupted operations. Improved Deployment Reliability: Enhancements in software content management ensure reliable and scalable management of large-scale deployments, reducing downtime and improving device performance.   Third-Party Library Upgrades ThingWorx 9.7 includes key updates to its underlying technology stack, ensuring compatibility with modern enterprise systems, improved performance, and robust security. To stay future-ready, we have updated its core technology stack, including Tomcat 9.0.95, Ignite 2.16 and RabbitMQ 3.13.7 to highlight few.   Why Upgrade to ThingWorx 9.7? ThingWorx 9.7 sets a new benchmark for IoT platforms, offering enhanced scalability, state-of-the-art security, and intuitive tools for developers. The updates cater to both enterprise-scale deployments and industry-specific challenges, ensuring that businesses can innovate and operate with confidence in an increasingly complex digital landscape.   Upgrade to ThingWorx 9.7 today and unlock new possibilities for innovation and success! View release notes here for more details on exact updates and be sure to upgrade to 9.7! Vineet Khokhar Principal Product Manager- IOT Security  

In the evolving landscape of software development, ensuring support for the latest, most secure versions of programming languages is essential. At PTC, we continuously evaluate our technology stack, and Java is no exception. As part of our ongoing commitment to providing secure and high-performing products, we’re announcing some important updates to the Java support plans for ThingWorx.   Current Java Support in ThingWorx (Through Version v9.1.X - v9.6.X)   As of ThingWorx v9.6, Java 11 is the only supported version. This version has been a mainstay of our IoT platform, ensuring stability and performance across various use cases. However, Java 11 entered Extended Support in September 2023, meaning its standard support phase has ended. While this version will continue to receive security updates for a while, its lifecycle is winding down.   Introducing Java 21 Support in ThingWorx v9.7 (Planned Release: December 2024)   With ThingWorx 9.7, releasing in December 2024, we will introduce support for Java 21, the next Long-Term Support (LTS) version of Java. This upgrade brings key benefits, including improved performance, enhanced garbage collection, and increased security, ensuring that ThingWorx remains optimized for enterprise-scale IoT deployments. (More details: The Arrival Of JAVA 21) Given the diversity of our customer base, we know that some are still using Java 11, while others are ready to move to Java 21. ThingWorx 9.7 will support both versions, allowing customers the flexibility to upgrade to the latest ThingWorx version while preparing their environments for Java 21.   The Road to Java 21-Only: What to Expect in ThingWorx v10.0 (Planned Release: June 2025)   As we assess the adoption of Java 21 following the ThingWorx 9.7 release, our goal is to phase out support for Java 11 with ThingWorx 10.0, scheduled for release in June 2025. Starting with ThingWorx 10, Java 21 will be the only supported version, marking the end of Java 11 support for the core platform.   This is driven by the need to stay aligned with modern standards and best practices, including support for third-party technologies such as Tomcat v10 and Spring Framework v6, which require latest Java versions. These updates will ensure that ThingWorx continues to benefit from the latest advancements in the Java ecosystem. Next steps for ThingWorx users   As we approach the release of ThingWorx 9.7, we encourage customers to begin planning for the move to Java 21. While ThingWorx 9.7 will support both Java 11 and Java 21, we recommend upgrading to Java 21 to take full advantage of the enhancements it offers. For more detailed information on overall third party support, do check Release Advisor Vineet Khokhar Principal Product Manager, IoT Security   Stay tuned for more updates as we approach the release of ThingWorx v9.7, and as always, in case of issues, feel free to reach out to <support.ptc.com>  This post on ThingWorxTM status & roadmap is a preliminary version and not subject to your license agreement or any other agreement with ThingWorx. This post contains intended strategies, developments, and functionalities of the ThingWorxTM product. The information is furnished for information use only and is not intended to be binding upon ThingWorx to any particular course of business, product strategy, and/or development. Please note that this document is subject to change and may be changed by ThingWorx at any time without notice; accordingly, you should not rely on this data for production or purchasing decisions. ThingWorx assumes no responsibility for errors or omissions in this document.

Greetings, Community Members! PTC has launched ThingWorx 9.6.0 as of June, and it's now ready for your upgrade! Let's explore the key enhancements in this latest version of ThingWorx.   What are the top three areas of updates in ThingWorx 9.6?   Performance, Scalability, Reliability, and Security: There's a significant boost in file transfer performance between connected devices and the ThingWorx platform. A notable enhancement in server startup performance, with some instances showing an 84% reduction in startup time. Numerous logging improvements, including limitations on log verbosity, log filtration, and configurable log storage capabilities, contribute to the stabilization of the ThingWorx system. Additionally, ThingWorx now supports log extraction to third-party software like Sumologic, Datadog, Splunk, Grafana, etc., utilizing the industry-standard OpenTelemetry framework starting from TWX 9.6. Content Security Policy has been implemented, fortifying ThingWorx against script and data injection attacks, man-in-the-middle (MITM) attacks, and clickjacking. Several tech stack updates in 9.6; support now available for Azure B2C and TLS 1.3 (limited)   Developer Productivity: Introducing a new Collection widget with improved performance, enabling a transition away from the legacy Collection and Repeater widgets. Several other new widgets such as KPI dial widget, Tree selector widget, Progress Tracker widget and other critical enhancements for ThingWorx WebComponents are now available Support for viewing mashup configurations such as layouts, bindings, and widget properties in a read-only mode, helping improve user experience by allowing multiple users to review mashup designs simultaneously without making edits.   Solutions updates: Streamlined continuous improvement with the ability to View and Create Actions in One-Click from performance analysis screens for the Digital Performance Management (DPM) solution. Enhanced performance for the Asset Monitoring & Utilization (AMU) solution, with alarm events creation now handled asynchronously. Several fixes and improvements for Connected Work Cell (CWC), Real-Time Production Performance Monitoring (RTPPM), and DPM such as limits evaluation, messages not displayed, incorrectly calculated KPIs and issues with Running Time on the operator display and more, helping customers achieve continuous improvements in their manufacturing operations   View release notes here and be sure to upgrade to 9.6!   Dilanur Bayraktar ThingWorx Product Management

Hello everyone,   Following a recent  experience, I felt it was important to share my insights with you. The core of this article is to demonstrate how you can format a Flux request in ThingWorx and post it to InfluxDB, with the aim of reporting the need for performance in calculations to InfluxDB. The following context is renewable energy. This article is not about Kepware neither about connecting to InfluxDB. As a prerequisite, you may like to read this article: Using Influx to store Value Stream properties from... - PTC Community     Introduction   The following InfluxDB usage has been developed for an electricity energy provider.   Technical Context Kepware is used as a source of data. A simulation for Wind assets based on excel file is configured, delivering data in realtime. SQL Database also gather the same data than the simulation in Kepware. It is used to load historical data into InfluxDB, addressing cases of temporary data loss. Once back online, SQL help to records the lost data in InfluxDB and computes the KPIs. InfluxDB is used to store data overtime as well as calculated KPIs. Invoicing third party system is simulated to get electricity price according time of the day.   Orchestration of InfluxDB operations with ThingWorx ThingWorx v9.4.4 Set the numeric property to log Maintain control over execution logic Format Flux request with dynamic inputs to send to Influx DB  InfluxDB Cloud v2 Store logged property Enable quick data read Execute calculation Note: Free InfluxDB version is slower in write and read, and only 30 days data retention max.     ThingWorx model and services   ThingWorx context Due to the fact relevant numeric properties are logged overtime, new KPIs are calculated based on the logged data. In the following example, each Wind asset triggered each minute a calculation to get the monetary gain based on current power produced and current electricity price. The request is formated in ThingWorx, pushed and executed in InfluxDB. Thus, ThingWorx server memory is not used for this calculation.   Services breakdown CalculateMonetaryKPIs Entry point service to calculate monetary KPIs. Use the two following services: Trigger the FormatFlux service then inject it in Post service. Inputs: No input Output: NOTHING FormatFlux_CalculateMonetaryKPI Format the request in Flux format for monetary KPI calculation. Respect the Flux synthax used by InfluxDB. Inputs: bucketName (STRING) thingName (STRING) Output: TEXT PostTextToInflux Generic service to post the request to InfluxDB, whatever the request is Inputs: FluxQuery (TEXT) influxToken (STRING) influxUrl (STRING) influxOrgName (STRING) influxBucket (STRING) thingName (STRING) Output: INFOTABLE   Highlights - CalculateMonetaryKPIs Find in attachments the full script in "CalculateMonetaryKPIs script.docx". Url, token, organization and bucket are configured in the Persitence Provider used by the ValueStream. We dynamically get it from the ValueStream attached to this thing. From here, we can reuse it to set the inputs of two other services using “MyConfig”.   Highlights - FormatFlux_CalculateMonetaryKPI Find in attachments the full script in "FormatFlux_CalculateMonetaryKPI script.docx". The major part of this script is a text, in Flux synthax, where we inject dynamic values. The service get the last values of ElectricityPrice, Power and Capacity to calculate ImmediateMonetaryGain, PotentialMaxMonetaryGain and PotentialMonetaryLoss.   Flux logic might not be easy for beginners, so let's break down the intermediate variables created on the fly in the Flux request. Let’s take the example of the existing data in the bucket (with only two minutes of values): _time _measurement _field _value 2024-07-03T14:00:00Z WindAsset1 ElectricityPrice 0.12 2024-07-03T14:00:00Z WindAsset1 Power 100 2024-07-03T14:00:00Z WindAsset1 Capacity 150 2024-07-03T15:00:00Z WindAsset1 ElectricityPrice 0.15 2024-07-03T15:00:00Z WindAsset1 Power 120 2024-07-03T15:00:00Z WindAsset1 Capacity 160   The request articulates with the following steps: Get source value Get last price, store it in priceData _time ElectricityPrice 2024-07-03T15:00:00Z 0,15 Get last power, store it in powerData _time Power 2024-07-03T15:00:00Z 120 Get last capacity, store it in capacityData _time Capacity 2024-07-03T15:00:00Z 160 Join the three tables *Data on the same time. Last values of price, power and capacity maybe not set at the same time, so final joinedData may be empty. _time ElectricityPrice Power Capacity 2024-07-03T14:00:00Z 0,15 120 160 Perform calculations gainData store the result: ElectricityPrice * Power _time _measurement _field _value 2024-07-03T15:00:00Z WindAsset1 ImmediateMonetaryGain 18 maxGainData store the result: ElectricityPrice * Capacity lossData store the result: ElectricityPrice * (Capacity – Power) Add the result to original bucket   Highlights - PostTextToInflux Find in attachments the full script in "PostTextToInflux script.docx". Pretty straightforward script, the idea is to have a generic script to post a request. The header is quite original with the vnd.flux content type Url needs to be formatted according InfluxDB API     Well done!   Thanks to these steps, calculated values are stored in InfluxDB. Other services can be created to retrieve relevant InfluxDB data and visualize it in a mashup.     Last comment It was the first time I was in touch with Flux script, so I wasn't comfortable, and I am still far to be proficient. After spending more than a week browsing through InfluxDB documentation and running multiple tests, I achieved limited success but nothing substantial for a final outcome. As a last resort, I turned to ChatGPT. Through a few interactions, I quickly obtained convincing results. Within a day, I had a satisfactory outcome, which I fine-tuned for relevant use.   Here is two examples of two consecutive ChatGPT prompts and answers. It might need to be fine-tuned after first answer.   Right after, I asked to convert it to a ThingWorx script format:   In this last picture, the script won’t work. The fluxQuery is not well formatted for TWX. Please, refer to the provided script "FormatFlux_CalculateMonetaryKPI script.docx" to see how to format the Flux query and insert variables inside. Despite mistakes, ChatGPT still mainly provides relevant code structure for beginners in Flux and is an undeniable boost for writing code.  

The natively exposed ThingWorx Platform performance metrics can be extremely valuable to understanding overall platform performance and certain of the core subsystem operations, however as a development platform this doesn't give any visibility into what your built solution is or is not doing.   Here is an amazing little trick that you can use to embed custom performance metrics into your application so that they show up automatically in your Prometheus monitoring system. What you do with these metrics is up to your creativity (with some constraints of course). Imaging a request counter for specific services which may be incredibly important or costly to run, or an exception metric that is incremented each time you catch an exception, or a query result size metric that informs you of how much data is being queried from the database.   Refer to Resources > MetricsServices: GetCounterMetric GetGaugeMetric IncrementCounterMetric DecrementCounterMetric SetGaugeMetric You'll need to give your metric a name - identified by key - and this is meant to be dotted notation* which will then be converted to underscores when the metric is exposed on the OpenMetrics endpoint.  Use sections/domains in the dotted notation to structure your metrics in-line with your application design.   COUNTER type metrics are the most commonly used and relate to things happening through time.  They are an index which will get timestamped as they're collected by Prometheus so that you will be able to look back in time and analyse and investigate what happened when and what the scale or impact was.  After the fact functions and queries will need to be applied to make these metrics most useful (delta over time, increase, rate per second).   Common examples of counter type metrics are: requests, executions, bytes transferred, rows queried, seconds elapsed, execution time.     Resources["MetricServices"].IncrementCounterMetric({ basetype: "LONG", value: 1, key: "__PTC_Reported.integration.mes.requests", aggregate: false });     GAUGE type metrics are point-in-time status of some thing being measured.   Common gauge type metrics are: CPU load/utilization, memory utilization, free disk space, used disk space, busy/active threads.     Resources["MetricServices"].SetGaugeMetric({ basetype: "NUMBER", value: 12, key: "__PTC_Reported.Users.ConnectedOperatorCount", aggregate: true });     Be aware of the aggregate flag, as it will make this custom metric cluster level which can have some unintended consequences.  Normally you always want performance metrics for the specific node as you then see what work is happening where and can confirm that it is being properly distributed within the cluster.  There are some situations however where you might want the cluster aggregation however, like with this concurrently connected operators.   Happy Monitoring!