IoT Tips

  Create An Application Key Guide   Overview   In order for a device to send data to the Platform, it needs to be authenticated. One authentication method is to use an Application Key. Application Keys, or appKeys, are security tokens used for authentication in ThingWorx. They are associated with a given User and have all of the permissions granted to the User with which they are associated. This is one of the most common ways of assigning permission control to a connected device. NOTE: This guide's content aligns with ThingWorx 9.3. The estimated time to complete this guide is 30 minutes.    Step 1: Learning Path Overview   This guide explains the steps to create a ThingWorx Application Key, and is part of a Learning Path. You can use this guide independently from the full Learning Path. If you want to learn to create a ThingWorx Application Key, this guide will be useful to you. When used as part of the Industrial Plant Learning Path, you should already have installed ThingWorx Kepware Server. We will use the Application Key to send information from ThingWorx Kepware Server into ThingWorx Foundation. Other guides demonstrate Foundation's Mashup Builder to construct a website dashboard that displays information from ThingWorx Kepware Server. We hope you enjoy this Learning Path.   Step 2: Create Application Key   Application Keys are assigned to a specific User for secure access to the platform. Using the Application Key for the default User (Administrator) is not recommended. If administrative access is absolutely necessary, create a User and place the User as a member of the SecurityAdministrators and Administrators User groups. Create the User the Application Key will be assigned to. 1. On the Home screen of Composer click + New. 2. In the dropdown list, click Applications Key. 3. Give your application key a name (i.e. MyAppKey). 4. If Project is not already set, click the + in the Project text box and select the PTCDefaultProject. 5. Set the User Name Reference to a User you created. 6. Update the Expiration Date field, otherwise it will default to 1 day. 7. Click Save. A Key ID has been generated and can be used to make secure connections.   IP Whitelisting for Application Keys   One of the features of an Application Key is the ability to set an IP whitelist. This allows the server to specify that only certain IP addresses should be able to use a given Key ID for access. This is a great way to lock down security on the platform for anything that will maintain a static IP address. For example, connected Web-based business systems may have a static IP from which all calls should be made. Similarly, you can use wildcards to specify a network to narrow the range of IP addresses allowed while still offering some flexibility for devices with dynamic IP addresses. Extremely mobile devices should likely not attempt to implement this, however, as they will often change networks and IP addresses and may lose the ability to connect when the IP whitelist feature is used.   Interact with Application Keys Programmatically Service Name Description GetKeyID Returns the ID of this Application Key GetUserName Get the username associated with this Application Key IsExpired Returns if this Application Key is expired ResetExpirationDateToDefault Resets the expiration date of the Application Key to the default time based on configuration in the UserManagement subsystem SetClientName Sets the client name for this Application Key SetExpirationDate Sets the expiration date of this Application Key to a provided date SetIPWhiteList Sets the values for the IP whitelist for this Application Key SetUserName Sets the associated user name for this Application Key   Tip: To learn more about Application Keys, refer to the Help Center   Step 3: Next Steps   Congratulations! You have successfully created an application key. We hope you found this guide useful.     The next guide in the Connect and Monitor Industrial Plant Equipment learning path is Install ThingWorx Kepware Server.    The next guide in the Azure MXChip Development Kit learning path is Connect Azure IoT Devices.   The next guide in the Medical Device Service learning path is Use the Edge MicroServer (EMS) to Connect to ThingWorx.   The next guide in the Using an Allen-Bradley PLC with ThingWorx learning path is Model an Allen-Bradley PLC.

Integrating LDAP authentication into Thingworx is fairly simple. Since release 5.0 and later, the out-of-the-box (OOTB) Thingworx authenticators already include the necessary code to validate a user's credentials against an LDAP server. These authenticators look to see if an LDAP server is connected every time a user attempts a login, and then further check to see if this user exists in the LDAP server. If the username does exist in LDAP, then Thingworx will check if the password entered is a match to the password stored within LDAP. If the password entered does not match the password stored in LDAP, then Thingworx will next check if the password matches the one stored in Thingworx for that user. So in order for a user to login to Thingworx, they must have a user Thing created for them within Thingworx Composer (this can be done programmatically, see below), and a valid password which matches either an LDAP account password or the password as it is set for that user on the Thing in Thingworx Composer. The first thing a developer needs to do to integrate LDAP is configure their Thingworx instance so that it can find the LDAP server and access its contents. This is done by importing an XML file which will allow the developer to see a Thing that comes with the Thingworx platform (see attached file "directoryServices.xml"). The Thing that needs configuring is called ApacheDS3 and it is a DirectoryServices Thing. The largest task for a developer to do to integrate LDAP into Thingworx involves importing their LDAP users into Thingworx. Getting the LDAP usernames out of the LDAP server will vary depending on which distribution of LDAP is in use. However, once the developer acquires this information, using it to create users in Thingworx is simple. The developer will need to create a Thing Service which creates a dummy password and assigns the LDAP username in the parameters. Then they can pass the parameters into the CreateUser service of the “EntitiyServices” resource: var params = { password: "SOMETHING_COMPLICATED", //dummy password does not matter, but you don't want an accidental match, so make it something very complicated, and standard to your company's LDAP users name: ldap_username, //retrieve from LDAP description: "This user was created as part of LDAP import", //can be whatever you'd like tags: undefined }; Resources["EntityServices"].CreateUser(params); // no return Any users created in this way will be redirected to Squeal if there is no home mashup assigned, so you will have to add an additional bit of code which assigns the home mashups to users, looping through something like this: var params = {     name: "dashboard" //replace this with String name of dashboard (must exist) }; Users[username].SetHomeMashup(params); For full steps on integrating LDAP and Thingworx, including instructions on how to set up an ApacheDS test LDAP server, see the Thingworx support article titled “Integrate LDAP Authentication and Import LDAP User Directory into Thingworx” (reference document – CS221840).

This is a basic troubleshooting guide for ThingWorx. It goes over the importance, types and levels of logs, getting started on troubleshooting the Composer, Mashup and Remote Connectivity.     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.

Overview of prerequisites and components required to achieve a successful installation PTC Navigate View ALM App and a brief functionality demonstration of the product.     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.

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

This post covers how to build and operationalize a time series model using Thingworx Analytics. A lookback window is used to read multiple previous rows before the current one, and base the prediction on those lookback rows.   In this example we use time series data to predict water flow for different water pumps in a system.   There is a full explanation of the method attached, also all necessary resources are included in the attached files.

Install ThingWorx Kepware Server Guide    Overview   This guide will walk you through the steps to install ThingWorx Kepware Server. NOTE: This guide's content aligns with ThingWorx 9.3. The estimated time to complete this guide is 30 minutes.    Step 1: Learning Path Overview   This guide is the first on the Connect and Monitor Industrial Plant Equipment Learning Path, and it explains how to get up and running with ThingWorx Kepware Server. If you want to learn to install ThingWorx Kepware Server, this guide will be useful to you, and it can be used independently from the full Learning Path. In the next guide on the Learning Path, we will create an Application Key which is used to secure the connection between Kepware Server and ThingWorx Foundation. Later in the Learning Path, we will send information from ThingWorx Kepware Server into ThingWorx Foundation. In other guides in this Learning Path, we will use Foundation's Mashup Builder to construct a website dashboard that displays information from ThingWorx Kepware Server. We hope you enjoy this Learning Path.   Step 2: Install ThingWorx Kepware Server   ThingWorx Kepware Server includes over 150 factory-automation protocols. ThingWorx Kepware Server communicates between industrial assets and ThingWorx Foundation, providing streamlined, real-time access to OT and IT data — whether that data is sourced from on-premise web servers, off-premise cloud applications, or at the edge. This step will download and install ThingWorx Kepware Server. Download the ThingWorx Kepware Server executable installer. Select your Language and click OK 3. On the "Welcome" screen, click Next.        4. the End-User License Agreement and click Next.   5. Set the destination folder for the installation and click Next.   6. Set the Application Data Folder location and click Next. Note that it is recommended NOT to change this path. 7. Select whether you'd like a Shortcut to be created and click Next. 8. On the "Vertical Suite Selection" screen, keep the default of Typical and click Next. 9. On the "Select Features" screen, keep the defaults and click Next. 10. The "External Dependencies" screen simply lists everything that will be installed; click Next. 11. On the "Default Application Settings" screen, leave the default of Allow client applications to request data through Dynamic Tag addressing and click Next. 12. On the “User Manager Credentials” screen, set a unique strong password for the Administrator account and click Next. Note that skipping setting a password can leave your system less secure and is not recommended in a production environment. 13. Click install to begin the installation. 14. Click finish to exit the installer.     Step 3: Open ThingWorx Kepware Server   Now that ThingWorx Kepware Server is installed, you will need to open it. In the bottom-right Windows Taskbar, click Show hidden icons. 2. Double-click on the ThingWorx Kepware Server icon. 3. ThingWorx Kepware Server is now installed. 4. For additional information on ThingWorx Kepware Server, click Server Help on the Menu Bar.   Step 4: Next Steps   Congratulations! You've successfully completed the Install ThingWorx Kepware Server guide. In this guide, you learned how to:   Download, install, and open ThingWorx Kepware Server   The next guide in the Connect and Monitor Industrial Plant Equipment learning path is Connect Kepware Server to ThingWorx Foundation.    The next guide in the Using an Allen-Bradley PLC with ThingWorx learning path is Connect to an Allen-Bradley PLC. . 

The following code snippet will retrieve a months worth of data from the system and return it as a CSV document suitable for import into your spreadsheet or reporting tool of choice. import static com.axeda.sdk.v2.dsl.Bridges.* import com.axeda.drm.sdk.Context import com.axeda.common.sdk.id.Identifier import com.axeda.services.v2.* import com.axeda.sdk.v2.exception.* def ac = new AuditCriteria() ac.fromDate = Date.parse('yyyy-MM-dd', '2017-03-01') ac.toDate   = Date.parse('yyyy-MM-dd', '2017-03-31') def retString = '' tcount = 0 while ( (results = auditBridge.find(ac)) != null  && tcount < results .totalCount) {   results.audits.each { res ->     retString += "${res?.user?.id},${res?.asset?.serialNumber},${res?.category},${res.message},${res.date}\n"     tcount++   }   ac.pageNumber = ac.pageNumber + 1 } return retString

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.

  Meet Chris. Chris leads the ThingWorx Flow portfolio, which will be releasing in 8.4. Chris has “a long history with workflow and a lot of interest in it.” He was originally hired as a product manager by Jim Heppelmann [PTC’s CEO] about 20 years ago to build a workflow engine for Windchill, our PLM solution. As a matter of fact, this feature is still a part of Windchill today. Pretty neat, right? We were able to leverage Chris’ workflow expertise and experience to create ThingWorx Flow. Check out more below.   Kaya: Why did we create ThingWorx Flow? What challenge does it solve? Chris: In order for customers to realize the full business value for connected solutions, it typically isn’t enough to just surface an alert to show a dashboard of health. Customers want to automatically do things like create service tickets or automatically order consumables as they run low. To do that—to realize that automated value—you need a couple of things. First, you need to be able to easily connect to enterprise systems (like SAP, Salesforce or Microsoft Dynamics) to create service cases. Second, you need to be able to define and execute your business process logic.   Kaya: Can you give me an example? Chris: Definitely. The business process may involve the need to replace a filter based on a contamination alert. After I receive the alert, I need to look up in the bill of materials to find out which filter is applicable to that particular device or product; if it’s not in stock onsite, I need to order it. When it arrives, I then need to schedule the service, knowing that it’s going to be there at a particular time, which entails working with another service system like Salesforce.   So, you have a number of these different enterprise systems that you need to connect to, and you need to support that orchestrated business process to realize the value of a fully automated flow. That’s what has really led us to do it—because, again, the compelling business value in these connected device solutions is often around an automated approach to service or maintenance issues. The value is compelling because automated processes minimize delays, support business growth and scale without hiring as many additional people and eliminate human errors and variability that lead to improved quality at lower costs or stronger margins. Sample ThingWorx Orchestrate Workflow: Send RFQ to Supplier and Add Part to List If State ChangesKaya: So, who ultimately benefits from Flow? Chris: The benefits are realized by an organization as a whole in terms of increased responsiveness, flexibility, reduced costs and higher availability. The ThingWorx solution is unique in that it allows an organization to quickly realize these benefits by optimizing the participation of several key roles. As a result, no role becomes a bottleneck to addressing an urgent business need.   In addition to developers, the many business analysts across the organization are now empowered to define and modify their business processes themselves through Flow. They do this by using the system connections (or subflows) created by their system experts and ThingWorx models that were defined by developers. All of this work is achieved using our visual modeling tool without the need for extensive training.   The system experts can define portions of flows or subflows that get, create or edit information in the systems they understand most within the Flow editor. This enables each role to focus on using their most valuable skills and ultimately eliminates the bottlenecks that cause reduction in business responsiveness when everything must be done by a few highly-specialized experts. Now, developers can leverage the outputs of flows to drive behavior in the application and visualize key KPIs and overall health.   Kaya: So, I see that we’re not only connecting business systems, but we’re also connecting people. We enable them to leverage each other’s different perspectives and areas of expertise. I know we gave developers a sneak peek of ThingWorx Flow in one of our latest posts. Do you have a more detailed demo that we could share this week? Chris: Sure thing. Check this out. (view in My Videos)   Kaya: Wow! I can definitely see how Flow saves immense time in workflow creation. Now, final question: what is your favorite aspect about working at PTC? Chris: The most interesting thing to me is that I get to work with so many different customers in so many different verticals that have such a diverse set of challenging and interesting problems. It’s fun to work together with these customers for us to understand their problems, their unique environments and then to, with them, build solutions using a combination of our products and their existing systems and tooling—that’s what I think is most fascinating.   I learn something new about the way things are made, manufactured, built and serviced every day, and it just makes my life much more interesting. I don’t feel like I’m doing the same thing every day. Working with customers to understand and address their challenges and help them realize their business goals is really rewarding and, again, the diversity of those requests is what makes the job particularly interesting and fascinating.

This example provides the ability to generate a simple entity structure and some historical data for each entity. Historical data is run through a ThingWorx service to generate histogram data for display in a bar chart.  The provided ThingWorx entities and PDF document provide the example as well as documentation.

Introduction SAP HANA database is among the several options available for ThingWorx as persistence provider, in this blog I'll share the experience and challenges I had while setting up the SAP HANA and then configuring it to run as Persistence Provider for ThingWorx Pre-requisite Eclipse Mars or higher SAP Hana Express Edition 2.0 ThingWorx Hana Persistence Provider Package​ Setting up SAP Hana SAP Hana Express Edition 2.0 is freely available from SAP via the download with a pre-built machine with SUSE Enterprise OS. For this blog I used the SAP Hana Express Edition 2.0 Server only version while downloading the pre-built VM from SAP Download the Server only or Server + Application VM from the SAP's website           2. Unzip and open the hxe.ova (file name will differ if you are downloading the server + application VM) file in one of the hyper-visor, in my case I'll be using VMWare Workstation, but should work just fine with others e.g. Oracle VirtualBox      3. Once opened in a hypervisor SUSE will boot up and you will be prompted for the new password, as VM is configured for force first time password change      4. If you are unsure of the next steps to follow refer to the Getting Started with SAP Hana express edition guide which is selected by default and gets downloaded when the VM is downloaded      5. Another thing to note about the PDF that it contains all the details on the username and password required for initial setup      6. Provide the password for the OS user which is hxeadm, note you can always refer to the PDF file which we downloaded while downloading the VM from SAP's download manager      7. Once the password is changed for the OS user, you will also be prompted to change the master DB user's password as well      8. Make note of these passwords SAP HANA DB Instance After completing the initial steps for setting up the VM and changing the password we can now check the pre-built database installed on the VM which is called as SystemDB. You can check that and same basic settings running on the instance by using the following command in the shell $ HDB info This command will print out the features and components installed on the VM, if you are using Server only VM as I did you shall see something of this printed on the shell. In case it doesn't show up you can start the database and check again of the running services $ HDB start The output will be something like this, note the highlighted part for below output already include couple of additional services that is because i have already created the ThingWorx Database : FYI: If you wish to shut down the database you can use following command: $ HDB Stop With this let's move to the next step to create the new database which will be used by the ThingWorx application. One thing to note that you can run the SAP Hana in multi-tenant or in single tenant mode. With the free edition i.e. the SAP Hana Express Edition multi-tenant is the only available option. This is why we will create the ThingWorx DB and the schema and use that to populate it with the required tables and other DB entities needed to support the persistence provider from ThingWorx webapp Creating and configuring the ThingWorx Database with ThingWorx Schema For this you'll be required to download from the PTC Software download page the package for the ThingWorx with SAP Hana Persistence provider package which contains the DB creation scripts. You can now choose to create the schema in two ways i.e.      a. Creating and Configuring the Database using PTC provided Bash Scripts      b. Manually Creating and configuring the SAP Hana Database Both of these details are covered in the Getting Started with SAP Hana and ThingWorx Guide For this blog I created everything manually that is by connecting via the client which i have installed as plugin in my existing Eclipse Mars. If you are running different version of Eclipse check this link If you are also using the Eclipse Mars you can use this link in Eclipse > Help > Install New Software > https://tools.hana.ondemand.com/mars/ Once installed make sure to restart the eclipse and open the SAP Hana Administration Console perspective, which should come up something like this: Since I have already installed and created some connections to the DB they are visible on the left side of the Eclipse. Creating Connection to the SAP Hana Database      1. Navigate to the Systems tab on the left in the SAP Hana Administration Console perspective in Eclipse      2. Click on the Add Systems icon located right on the Systems tab, like so      3. Provide some basic connection details like           a. Host Name: IP or machine name of the VM running the SAP Hana Express edition           b. Instance Number: 90           c. Mode: If you are using free express edition as I have used for this blog you will be required to select Multiple containers. As soon you will see that we will create ThingWorx as tenant DB alongside the System DB           d. Select System Database since for now we have not yet created a database called ThingWorx. Click next.      4. On the next page provide the username/password, i will be logging in as SYSTEM user since I have not yet created any other user and I'll use the master DB password which I'd set when      configuring the VM for the first time.      5. Click Finish to complete and test the connection Creating ThingWorx User and ThingWorx Database Successful connection creation will show the connection with green icon under the Systems tab which will allow you to then explore the connection for different objects existing under the SYSTEM database. To begin using the SQL statements select the connection and click on the SQL tab as highlighted in the screenshot below: With this you have now successfully created the connection and also have a SQL client to execute SQL tasks As mentioned previously you have two options to setup the schema and the data model for the ThingWorx Database, these are      1. Using the shell script to create and configure the ThingWorx Database and it's schema together with the required User and the data model. For this you will need following:           a. thingworxHanaDatabaseSetup.sh           b. thingworxHanaSchemaSetup.sh Note: These two shell scripts will call the SQL procedures provided in the install folder ThingWorx-Platform-Hana-X-X-X.zip you have downloaded from the PTC Software Download ThingWorx-Platform-Hana-X-X-X.zip package incorrectly provides sample platform-settings.json with PostgresPersistenceProviderPackage configuration for ThingWorx Installation. So make sure that user executing those scripts should have all the required files in place, preferably in same folder as the script files and should have sufficient access rights to execute the scripts      2. The other option is to do everything manually i.e. create Database and it's schema, it's user and the data model via the SQL scripts provided in the install folder Both of these options are covered quite in detail in the installation guide so I'd recommend referring to that for step by step process. For creating a SQL connection using the newly created TWADMIN user follow the steps described in the section Creating Connection to the SAP Hana Database above. Here's how the configuration for connecting to the ThingWorx DB will look like With this we are now connected to an empty THINGWORX database under which TWADMIN schema will be created using the SQL scripts provided in the install directory of ThingWorx-Platform-Hana-X-X-X.zip package. Note that it's important that below listed scripts are executed in following order      1. thingworx-model-schema.sql      2. thingworx-data-schema.sql      3. thingworx-property-schema.sql      4. thingworx-data-proc.sql Checking the port for ThingWorx Database created in SAP Hana This can be checked by executing the following command directly from the SQL Client in the Eclipse. You may need to execute this command using SYSTEM user account, if any permission objections are raised in the client select * from "SYS_DATABASES".m_services This will return the result of all the databases and services with their port, check the SQL Port for the ThingWorx database : Configuring the SAP Hana Persistence Provider Now that we have met all the pre-requisites to connect to the our ThingWorx Database in SAP HANA let's configure the platform-settings.json file under placed under the \\<ThingworxInstallationDirectory>\ThingworxStorage\ Note: The sample platform-settings.json included with the downloaded ThingWorx-Platform-Hana-X-X-X.zip package incorrectly includes the PostgresPersistenceProviderPackage. A Jira is already filed and can be tracked via this knowledge base article ThingWorx-Platform-Hana-X-X-X.zip package incorrectly provides sample platform-settings.json with PostgresPersistenceProviderPackage configuration for ThingWorx Installation As a workaround for now, make sure to replace the PostgresPersistenceProviderPackage with HanaPersistenceProviderPackage, like so { "PersistenceProviderPackageConfigs": { "HanaPersistenceProviderPackage": { "ConnectionInformation": { "driverClass": "com.sap.db.jdbc.Driver", "jdbcUrl": "jdbc:sap://<IPAddressForSAPHana>:39041/?autocommit=false&currentschema=TWADMIN", "dbSchema": "TWADMIN", "username": "TWADMIN", "password": "Thingworx123", "acquireIncrement": 5, "acquireRetryAttempts": 50, "acquireRetryDelay": 10000, "checkoutTimeout": 1000000, "fetchSize": 5000, "idleConnectionTestPeriod": 60, "initialPoolSize": 5, "maxConnectionAge": 0, "maxIdleTime": 0, "maxIdleTimeExcessConnections": 300, "maxPoolSize": 100, "maxStatements": 100, "minPoolSize": 5, "numHelperThreads": 8, "testConnectionOnCheckout": false, "unreturnedConnectionTimeout": 0                }           }      }     } Configuring Tomcat to connect to SAP Hana ThingWorx Database Thingworx SAP Hana persistence provider connects to the SAP Hana database instance using the ngdbc.jar. As mentioned in the Getting Started with SAP Hana and ThingWorx guide this jar is required to placed under the  <TomcatInstallationDirectory>\lib location (for more detail see ThingWorx SAP Hana Guide). You can obtain this jar by installing this SAP Hana Client or SAP Hana plugin installed in Eclipse. Note: Currently there's a known issue around ThingWorx failing to connect to SAP Hana Express Edition v2.0 due to the use of newer version of ngdbc.jar i.e. v2.0 or above. A Jira, already filed for this, can be tracked in this PTC Knowledgebase Article : Tomcat fails to start with error "Failed to create com.thingworx.persistence.hana.HanaPersistenceProviderPackage. Cause was due to 'null'" when installing ThingWorx with SAP Hana Persistence Provider You can download the jar directly from SAP Hana webpage with a valid service account. Since the older version is not available for direct download without service account from the SAP's download page, this jar can be obtained by installing the old Eclipse e.g. Kepler and then install the SAP Hana plugin on top of it which includes the jar version 1.XX in the folder created by the SAP Hana Tools For more detail on installing and configuring Tomcat or setting up the license file refer to the ThingWorx Core Installation guide Verifying the installation Finally, start the Tomcat service and try to access the ThingWorx Composer by typing in the URL e.g. http://localhost:8080/Thingworx You can also verify the connectivity between the ThingWorx and the SAP Hana by navigating to the application.log located under ThingworxStorage\logs and look for INFO [T: localhost-startStop-1] Database initialization complete. This will confirm the database was initialized and connected to successfully Common connectivity issues Issue 1: After deploying and starting up the Tomcat you may see that the ThingWorx webapp is stalling despite logging the message that the database initialization started Cause: This could happen for variety of reasons e.g.      a. Incorrect port was used in the JDBC connection URL in the platform-settings.json      b. ThingWorx database is incorrectly spelled      c. Connection is timing out e.g. due to network issues Solution:      a. For port ensure that correct port is used by executing this command to verify on which port the database service listening      b. Connection retries could be increased in the platform-settings.json file      c. Reconfirm the correct username Issue 2: Application log in ThingWorx Tomcat would log the error that persistence provider is null Cause: Incorrect jar version is used. Solution:      a. Recheck the jar version which has been used under tomcat\lib folder

In this blog I will be inspecting the setup below, using the REST APIs exposed by the different components (log-analysis-free guaranteed).   The components are started in stages, and I will do some exploration between each stages : EMS only EMS + LSR 1 EMS + LSR 1 + LSR 2    The REST APIs   Edge MicroServer (EMS) REST API This API is very similar to the ThingWorx platform REST API, see REST APIs Supported by WS EMS for specificity. I will be monitoring the EMS using the LocalEms virtual Thing (EMS only) ThingWorx Platform REST API This is the well known ThingWorx Core REST API -  see REST API Core Concepts I will be monitoring the EMS, from the platform, using an EMSGateway thing. The EMSGateway exposes on the platform some of the LocalEms services (like GetEdgeThings). I'm also inspecting the remote properties / services / events exposed on the things using the RemoteThing::GetRemoteMetadata service. Lua Script Resource (LSR) REST API This API largely differs from the ones above, the API documentation is served by the LSR itself (e.g. http://localhost:8001/)   I will use it to list the scripts loaded by the LSR process.  Configuration   See above diagram - Platform is listening on port 8084, no encryption, EMS and LSRs on the same host...   Platform configuration : for each edge thing, a corresponding remote thing was manually created on the platform EMSGateway1 as a EMSGateway Thing Template EMSOnlyThing as a RemoteThingWithFileTransfer LUAThing2 as a RemoteThing LUAThing1 as a RemoteThing LUAOnlyThing as a RemoteThing   EMS configuration : /etc/config.json - listening on default port 8000   {     "ws_servers": [{             "host": "tws74neo",             "port": 8084         }     ],     "appKey": "xxxxxx-5417-4248-bc01-yyyyyyy",     "logger": {         "level": "TRACE"     },     "ws_connection": {         "encryption": "none"     },     "auto_bind": [{             "name": "EMSGateway1",             "gateway": true         }, {             "name": "EMSOnlyThing",             "gateway": false         }, {             "name": "LUAThing2",             "host": "localhost",             "port": 8002,             "gateway": false         }, {             "name": "LUAThing1",             "gateway": false         }     ],     "file": {         "virtual_dirs": [{                 "emsrepository": "E:\\ptc\\ThingWorx\\EMS-5-3-2\\repositories\\data"             }         ],         "staging_dir": "E:\\ptc\\ThingWorx\\EMS-5-3-2\\repositories\\staging"     } } LSR process (1) : /etc/config.lua - listening on default port 8001 (using the out of the box sample Lua scripts)   scripts.log_level = "INFO"   scripts.LUAThing1 = {     file = "thing.lua",     template = "example", }   scripts.sample = {   file = "sample.lua" } LSR process (2) : /etc/config2.lua - listening on port 8002 (using the out of the box sample Lua scripts) This LSR process is started with command "luaScriptResource.exe -cfg .\etc\config2.lua"   scripts.log_level = "INFO" scripts.script_resource_port = 8002 scripts.LUAThing2 = {     file = "thing.lua",     template = "example", }   scripts.LUAOnlyThing = {     file = "thing.lua",     template = "example", }   Stage 1 : EMS only     ThingWorx REST API   Request: Call the GetEdgeThings service on the EMSGateway1 thing POST  twx74neo:8084/Thingworx/Things/EMSGateway1/Services/GetEdgeThings Response: As expected, only the remote things flagged as auto_bind are listed   name host port path keepalive timeout proto user accept EMSGateway1   8001.0 / 60000.0 30000.0 http   application/json EMSOnlyThing   8001.0 / 60000.0 30000.0 http   application/json LUAThing1   8001.0 / 60000.0 30000.0 http   application/json LUAThing2 localhost 8002.0 / 60000.0 30000.0 http   application/json                                                               Request: Call the GetRemoteMetadata service on the LUAThing1 thing POST  twx74neo:8084/Thingworx/Things/LUAThing1/Services/GetRemoteMetadata Response: As expected, remote properties / services and events are not available since the LSR associated with this thing is off.   Unable to Invoke Service GetRemoteMetadata on LUAThing1 : null   EMS REST API   Request: Call the GetEdgeThings service on the LocalEms virtual thing POST  localhost:8000/Thingworx/Things/LocalEms/Services/GetEdgeThings Response: output is identical to the gateway thing on the platform   { "name": "EMSGateway1", "host": "", "port": 8001, "path": "/",  "keepalive": 60000, "timeout": 30000, "proto": "http", "user": "", "accept": "application/json" }, { "name": "EMSOnlyThing", "host": "", "port": 8001, "path": "/", "keepalive": 60000, "timeout": 30000, "proto": "http", "user": "", "accept": "application/json" }, { "name": "LUAThing1", "host": "", "port": 8001, "path": "/", "keepalive": 60000, "timeout": 30000, "proto": "http", "user": "", "accept": "application/json" }, { "name": "LUAThing2", "host": "localhost", "port": 8002, "path": "/", "keepalive": 60000, "timeout": 30000, "proto": "http", "user": "", "accept": "application/json"}            LSR REST API N/A - no LSR process started yet.   Stage 2 : EMS + LSR 1 (8001)     ThingWorx REST API   Request: Call the GetEdgeThings service on the EMSGateway1 thing POST  twx74neo:8084/Thingworx/Things/EMSGateway1/Services/GetEdgeThings Response: LUAThing1 is associated to an LUA script   name host port path keepalive timeout proto user accept EMSGateway1   8001.0 / 60000.0 30000.0 http   application/json EMSOnlyThing   8001.0 / 60000.0 30000.0 http   application/json LUAThing1 localhost 8001.0 /scripts/Thingworx 60000.0 15000.0 http   application/json LUAThing2 localhost 8002.0 / 60000.0 30000.0 http   application/json   Request: Call the GetRemoteMetadata service on the LUAThing1 thing POST  twx74neo:8084/Thingworx/Things/LUAThing1/Services/GetRemoteMetadata Response: Now that the Lua script for LUAThing1 is running, remote properties / services and events are available   {"isSystemObject":false,"propertyDefinitions":{"Script_Pushed_Datetime":{"sourceType":"ThingShape","aspects":{"isReadOnly":false,"dataChangeThreshold":0,"defaultValue":1495619610000,"isPersistent":false,"pushThreshold":0,"dataChangeType":"VALUE","cacheTime":0,"pushType":"ALWAYS"},"name":"Script_Pushed_Datetime","description":"","category":"","tags":[],"baseType":"DATETIME","ordinal":0},"Pushed_InMemory_Boolean":{"sourceType":"ThingShape","aspects":....   EMS REST API      LocalEms::GetEdgeThings returns same output as EMSGateway::GetEdgeThings   LSR REST API (port 8001)   Request: List all the scripts running in the first LSR GET  localhost:8001/scripts?format=text/html Response: We find our sample script and the script associated with LUAThing1 (the Thingworx script is part of the infrastructure and always there)   Name Status Result File LUAThing1 Running   E:\ptc\ThingWorx\EMS-5-3-2\etc\thingworx\scripts\thing.lua sample Running   sample.lua Thingworx Running   E:\ptc\ThingWorx\EMS-5-3-2\etc\thingworx\scripts\thingworx.lu   Stage 3 : EMS + LSR 1 (8001) + LSR 2 (8002)     ThingWorx REST API   Request: Call the GetEdgeThings service on the EMSGateway1 thing POST  twx74neo:8084/Thingworx/Things/EMSGateway1/Services/GetEdgeThings Response: LUAOnlyThing is now listed and LUAThing2 is associated with a LUA script   name host port path keepalive timeout proto user accept EMSGateway1   8001.0 / 60000.0 30000.0 http   application/json EMSOnlyThing   8001.0 / 60000.0 30000.0 http   application/json LUAOnlyThing localhost 8002.0 /scripts/Thingworx 60000.0 15000.0 http   application/json LUAThing1 localhost 8001.0 /scripts/Thingworx 60000.0 15000.0 http   application/json LUAThing2 localhost 8002.0 /scripts/Thingworx 60000.0 15000.0 http   application/json   EMS REST API      LocalEms::GetEdgeThings returns same output as  EMSGateway::GetEdgeThings   LSR REST API (port 8002)   Request: List all the scripts running in the second LSR GET  localhost:8002/scripts?format=text/html Response: Returns the status of all the scripts currently loaded   Name Status Result File LUAOnlyThing Running   .\etc\thingworx\scripts\thing.lua LUAThing2 Running   .\etc\thingworx\scripts\thing.lua Thingworx Running   .\etc\thingworx\scripts\thingworx.lua

In this video we cover the installation of the UploadThing module. This video applies to ThingWorx Analytics 52.2 till 8.0. This is no longer applicable with ThingWorx Analytics 8.1   Useful links: How to copy files from Windows to Linux Updated Link for access to this video:  Installing Thingworx Analytics Builder: Part 3 of 3  

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

Please find here an Labview implementation to connect to Thingworx via RestCalls. Have Fun using it. Any Feedback is appreciated. https://github.com/Seppel1985/LabVIEW_TWX_RestAPI

This is part of the continuing series of Blog posts regarding Troubleshooting the Application, this article will discuss more advance issues that some clients and customer have encountered while building or using ThingWorx Analytics. Packer Script Error – Unable to Download CentOS Image As the application is developed and built inside a CentOS image, the ThingWorx Analytics Packer Script tool for Virtual Machine Appliance creation utilizes the CentOS mirror repository in the creation process. When the end user is attempting to build the Virtual Machine Appliance with the Packer Script media creation tool, part of the process is to download the CentOS 7 ISO image file as the basis for the operating system that the ThingWorx Analytics Server software will be installed to. If CentOS updates or changes their mirror links for the source file ISO, you may encounter the following error: ==> virtualbox-iso: Downloading or copying Guest additions virtualbox-iso: Downloading or copying: file:///C:/Program%20Files/Oracle/VirtualBox/VBoxGuestAdditions.iso ==> virtualbox-iso: Downloading or copying ISO virtualbox-iso: Downloading or copying: file:///local-file-repo/CentOS-7-x86_64-Minimal-1511.iso virtualbox-iso: Error downloading: open local-file-repo/CentOS-7-x86_64-Minimal-1511.iso: The system cannot find the path specified. virtualbox-iso: Downloading or copying: http://mirror.spro.net/centos/7/isos/x86_64/CentOS-7-x86_64-Minimal-1511.iso virtualbox-iso: Error downloading: checksums didn't match expected: 88c0437f0a14c6e2c94426df9d43cd67 ==> virtualbox-iso: ISO download failed. Build 'virtualbox-iso' errored: ISO download failed. ==> Some builds didn't complete successfully and had errors: --> virtualbox-iso: ISO download failed. ==> Builds finished but no artifacts were created. Solution Method 1: Configuration File Replacement We have created a custom JSON configuration file that resolves the mirror issue for CentOS 7 v1611. You can download the JSON file here; you may have to right-click and “save link as” a JSON extension file. Also note, you will have to save/rename this JSON file as neuron-solo-variables.json. Using this file, navigate to your Packer Script builder directory, usually this is found in the following path: <PATH>\ThingWorx-Analytics-Server-Standalone\components\vm-builder\neuron-vm-builder Copy the new JSON file into this directory, and replace the current existing copy. You can now re-run the Packer Script for your desired Virtual Machine Appliance output. Method 2: Manual Configuration File Adjustment You will have to locate an active mirror for CentOS 7. A list of current active mirrors can be found here. When selecting a mirror, you will need to select the Minimal ISO install, as this is the base image that is used for the VM creation. Next, you will have to open the current neuron-solo-variables.json configuration file located in the <PATH>\ThingWorx-Analytics-Server-Standalone\components\vm-builder\neuron-vm-builder directory. You will have to replace the os_image_download_url value with an active Mirror URL from the list above. Next, for the os_iso_md5_checksum variable, you will need to replace the entry with the new SHA256 checksum from CentOS, which can be located here. Default Settings: New Settings: Save changes and close the neuron-solo-variables.json configuration file. CentOS has switched over from MD5 to SHA256 checksums. Even though in the following the variable name has “MD5” in the string, we will be modifying a second JSON configuration file to address this. In the same directory that we are currently working in, open the neuron-solo.json configuration file. You will need to modify the attribute iso_checksum_type to sha256 Default Settings: New Settings: Save changes and close the neuron-solo.json configuration file. You can now re-run the Packer Script for your desired Virtual Machine Appliance output.

Introduction to the ThingWorx Composer and a demonstration of how you go about building out the design plan.   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.

ThingWorx DevOps with Azure: The Comprehensive DevOps Guide Written by Tori Firewind, IoT EDC   As promised in a previous post,  attached here is a comprehensive guide to DevOps in ThingWorx, including tutorials and instructions for creating a continuous integration, continuous deployment (CI/CD) process for application development.  There are also updated scripts and entities attached, including an entire sample application for importing, exporting, and testing an application in ThingWorx. From Docker and Github to Azure DevOps and Solution Central, this guide has it all. Learn how to perform your role in the DevOps process whether an administrator or a developer, automate your deployments and testing, and create a more efficient process  for publication changes to production.  A complete DevOps process like this really does facilitate faster and easier updates with fewer risks, fewer delays, and a better pathway to success.  

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

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.