IoT & Connectivity Tips

In this blog I will be testing the SAPODataConnector using the SAP Gateway - Demo Consumption System.   Overview   The SAPODataConnector enables the connection to the SAP Netweaver Gateway through the ODdata specification. It is a specialized implementation of the ODataConnector. See Integration Connectors for documentation.   It relies on three components : Integration Runtime : microservice that runs outside of ThingWorx and has to be deployed separately, it uses Web Socket to communicate with the ThingWorx platform (similar to EMS). Integration Subsystem : available by default since 7.4 (not extension needed) Integration Connector : SAPODataConnector available by default in 8.0 (not extension needed)   ThingWorx can use OAuth to access SAP, but in this blog I will just use basic authentication.   SAP Netweaver Gateway Demo system registration   1. Create an account on the Gateway Demo system (credentials to be used on the connector are sent by email) 2. Verify that the account has access to the basic OData sample service : https://sapes4.sapdevcenter.com/sap/opu/odata/IWBEP/GWSAMPLE_BASIC/   Integration Runtime microservice setup   1. Follow WindchillSwaggerConnector hands-on (7.4) - Integration Runtime microservice setup Note: Only one Integration Runtime instance is required for all your Integration Connectors (Multiple instances are supported for High Availability and scale).   SAPODataConnector setup   Use the New Composer UI (some setting, such as API maps, are not available in the ThingWorx legacy composer)     1. Create a DataShape that is used to map the attributes being retrieved from SAP SAPObjectDS : Id (STRING), Name (STRING), Price (NUMBER) 2. Create a Thing named TestSAPConnector that uses SAPODataConnector as thing template 3. Setup the SAP Netweaver Gateway connection under TestSAPConnector > Configuration Generic Connector Connection Settings Authentication Type = fixed HTTP Connector Connection Settings Username = <SAP Gateway user> Password = < SAP Gateway pwd> Base URL : https://sapes4.sapdevcenter.com/sap Relative URL : /opu/odata/IWBEP/GWSAMPLE_BASIC/ Connection URL : /opu/odata/IWBEP/GWSAMPLE_BASIC/$metadata 4. Create the API maps and service under TestSAPConnector > API Maps (New Composer only) Mapping ID : sap EndPoint : getProductSet Select DataShape : SAPObjectDS (created at step 1) and map the following attributes : Name <- Name Id <- ProductID Price <- Price Pick "Create a Service from this mapping"     Testing our Connector   Test the TestSAPConnector::getProductSet service (keep all the input parameters blank)

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

This blog post has been written in collaboration with nexiles GmbH, a PTC Software Partner   The Edge Micro Server (EMS) and the LUA Scripting Resource (LSR) allow for an easy connection of sensors and / or data to the ThingWorx Platform.   Connections are usually established through the HTTP protocol and a REST API which sends unencrypted data and user specific credentials or ThingWorx application keys. This could be fine for a non-production environment. However in a more secure environment or in production, encryption and authentication should be used wherever and whenever possible to ensure the safety and integrity of the data.       In this scenario a user, client machine or remote device can utilize the LUA endpoints via the REST APIs endpoints. For this an authentication mechanism with credentials is required to only allow authenticated sessions. Invokation of services etc. are all protected and encrypted via HTTPS. A default HTTP connection would transfer the credentials as clear text which is most likely not desired.   The LSR then communicates via HTTPS to the EMS.   The EMS communicates to the ThingWorx platform via the AlwaysOn protocol using an encrypted websocket on the platform side.   Prerequisite   ThingWorx is already fully configured for HTTPS. See Trust & Encryption Theory and Hands On for more information and examples   Securing the EMS   EMS to ThingWorx connection   The config.json holds information on the complete EMS configuration. To add a trusted and secure connection to the ThingWorx platform, the servers, connection type and certificates have to be adjusted.   Check the config.json.complete for more information and individual settings.   As an example the following configuration could be a rough outline.   Switch the websocket server port to 443 in ws_servers Declare the connection to the websocket as SSL / TLS in wc_connection Declare the certificate used by the ThingWorx platform in certificates Validate the certificate In case you're using a self-signed certificate, allow using it - otherwise just say "false" If not using a self-signed certificate, but a certificate based on a chain of trust, point to the full chain of trust in the cert_chain parameter I used the client certifcate in X509 (PEM) formatted .cer file I used the client certificate's private key as PKCS #8 (PEM) and encrypted it with the super-secure password "changeme" (no really, change it!)   With this the EMS can connect securely to the ThingWorx platform websocket.   EMS as HTTP(S) server   To secure incoming connections to the EMS, it first of all needs to act as a HTTP server which is then configured to use a custom certificate.   In config.json add the http_server section Define the host and port as well and set SSL to true The full path of the certificate (.cer file) must be provided   With this the EMS can receive client requests from the LSR through a secure interface, protecting the (meta) data sent from the LSR to the EMS.   For my tests I'm using a self-signed certificate - created in the Keystore Explorer and exported as X509 (PEM) formatted .cer file. The private key is not required for this part.   Authentication   To further secure the connection to the EMS acting as HTTP(S) server, it's recommended to use user and password for authentication.   With this, only connections are accepted, that have the configured credentials in the HTTP header.   config.json   {      "ws_servers": [ { "host": "supersecretems.ptc.com", "port": 443 } ],        "appKey": "<#appKey>",        "http_server":  {           "host": "localhost",           "port": 8000,           "ssl": true,           "certificate": "C:\\ThingWorx\\ems.cer",           "authenticate": true,           "user": "EMSAdmin",           "password": "EMSAdmin",           "content_read_timeout": 20000      },        "ws_connection": { "encryption": "ssl" },        "certificates": {           "validate": true,           "allow_self_signed": true,           "client_cert": "C:\\ThingWorx\\twx70.cer",           "key_file": "C:\\ThingWorx\\twx70.pkcs8",           "key_passphrase": "changeme"      }   }   Securing the LSR   LSR to EMS connection   All connections going from the LSR to the EMS are defined in the config.lua with the rap_ parameters.   To setup a secure connection to the EMS, we need to provide the server as defined in the config.json in the http_server section (e.g. the default localhost:8000). Define the usage of SSL / TLS as well as the certificate file.   Client to LSR connection   All connection going to the LSR from any client are defined in the config_lua witht the script_resource_ parameters.   To ensure that all requests are done via authenticated users, setup a userid and password. Configure the usage of SSL / TLS to encrypt the connection between clients and the LSR. A custom certificate is not necessarily required - the LSR provideds its own custom certificate by default.   Now opening https://localhost:8001 (default port for the LSR) in a browser will open an encrypted channel forcing authentication via the credentials defined above.   Of course this needs to be considered for other calls implementing e.g. a GET request to the LSR. This GET request also needs to provide the credentials in its header.   Authentication   It's recommended to also configure the LSR for using a credential based authentication mechanism.   When setting up the LSR to only accept incoming requests with credentials in the header, the script_resource_userid and script_resource_password can be used for authentication.   When connecting to an EMS using authentication, the rap_userid and rap_password can be used to authenticate with the credentials configured in the config.json   config.lua   The following configuration can be posted anywhere in config.lua - best place would be just below the log_level configuration.   scripts.rap_host = "localhost" scripts.rap_port = 8000 scripts.rap_ssl = true scripts.rap_deny_selfsigned = false scripts.rap_cert_file = "C:\ThingWorx\ems.cer" scripts.rap_server_authenticate = true scripts.rap_userid = "EMSAdmin" scripts.rap_password = "EMSAdmin" scripts.script_resource_userid = "admin" scripts.script_resource_password = "admin" scripts.script_resource_ssl = true   EMS specific configuration: rap LSR specific configuration: script_resource   Other considerations   When configuring the EMS and LSR for authentication and encrypted traffic, the configuration files hold information that not everyone should have access to.   Therefore the config.json and config.lua must be also protected from an Operating System point of view. Permissions should only be granted to the (process) user that is calling the EMS / LSR. Ensure that no one else can read / access the properties and certificates to avoid password-snooping on an OS level.   It's best to grant restricted access to the whole microserver directory, so that only privileged users can gain access.   You're next...   This blog should have given some insight on what's required and how it's configured to achieve a more secure and safer EMS / LSR integration in a real-life production environment. Of course it always depends on the actual implementation, but use these steps as a guideline to secure and protect your (Internet of) Things!

Error: Failed to load SQL Modules into database Cluster. This error is usually seen during initializing the database cluster phase (in the setup as shown below). To resolve this issue, follow below steps: Create a PostgreSQL data folder before you start the installation (c:\postgres-data) and give full control for the user. Select the newly created data directory during the setup. After the successful installation, you can follow the remaining procedure for configuring it with ThingWorx from the respective installation document.

This is a note/reminder in cross-reference to https://support.ptc.com/appserver/cs/view/solution.jsp?n=CS267248&lang=en_US Java 9 is expected to be released by Oracle September 21 2017 and is not currently supported for ThingWorx, refer to ThingWorx System Requirement guides for support details: ThingWorx 8 ThingWorx 7 ThingWorx 6

Learning is a wide domain and thus, the field of machine learning has branched into several sub fields dealing with different types of learning tasks. Supervised vs Unsupervised Learning Since learning involves an interaction between the learner and the environment, we can divide tasks according to the nature of the interaction. Consider the task of detecting the hand written numbers among the lots of digital numbers vs task of anomaly detection. For the hand-written numbers detection task, we consider a setting in which the learner receives a set of training numbers, labeled as ‘Hand-Written’ and ‘Digital’. On the basis of such training, the learner should figure out a rule for labeling a newly arriving number. In contrast, for the task of anomaly detection, all the learner gets, as a training is a large set of numbers, without any labels on it, and the learner’s task is to detect ‘unusual’ numbers. Consider learning as a process of ‘using the experience to gain expertise’. Supervised learning describes a scenario in which the ‘experience’, a training example, consist significant information (labels Hand-Written or Digital) that is missing in the future arriving numbers, to which the learned experience is to be applied. Here, the acquired expertise is aimed at predicting the missing information for the validation data. However, in unsupervised learning, there is no difference between the training data and validation data. The learner processes input data with the goal of coming up with some summary or compressed version of the data. Clustering a data set into subsets of similar objects is a good example of such task. There is also an intermediate learning setting in which, the training set contains more information than the validation set. The learner here is required to predict even more information for the validation set. Consider a game of chess, where a value function describes each setting of a chess board. Now one may want to learn the degree why which White’s position is better than the black’s. The only information available to the learner at the training time is positions that occurred in an actual chess game and who won it. Such learning frameworks are investigated under reinforcement learning. Source: ‘Understanding machine learning: From theory to algorithms’ written by Shai Shalev-Shwartz and Shai Ben-David

Check out this new KCS article which links to all known best practice documents available for ThingWorx. This article will get larger in time as more articles are published related to the Dos and Don'ts of building an IoT application! Do you know when to use timers, and where to implement their subscriptions? How about ensuring info tables are used at the proper time, and data tables at others? Pesky performance issues wherein ThingWorx runs slow for apparently no reason? All of these questions and more are addressed here!

Persistent properties are stored in ThingWorx database while non-persistent properties are stored in memory. This means that the persistent values do not get erased or deleted if the thing restarts or platform restarts. The persistent properties can also be retrieved in the same way as non-persistent properties. To explain better how we can retrieve persistent data, please consider the below example: I took a device group which has multiple devices and defined 2 persistent properties. One is serial number and the other is firmware version number. Now in a mashup builder, the user gives the serial number and the corresponding firmware version will be retrieved. I achieved this by writing services for that thing. Created a Data shape with the name DeviceData and defined two filed definitions. One is Serial number and the other is firmware version. Created a thing template with the name DevGroup. Added a property in the thing template with the name DeviceData and selected the basetype as info table. Also selected the previously created data shape (Device Data) in data shape field. And made this property as persistent data by selecting Is Persistent. Saved the property. Created two devices with the names Device1 and Device2. Both the devices use the above template. Now for each device set the property values by clicking the set button in properties link. These values will be persistent, meaning they do not change even after refresh or when you restart ThingWorx. You can even set these properties at run time by just creating a service. Created GetFirmversion service which retrieves the firm version of given service number. Created mashup as shown below: . Once you select Device1, enter the serial number in the numeric entry field and click query button, the firmware version of the given serial number is displayed along with the data of device1. If we enter a wrong number, no data will be displayed. You can also set an error message instead of displaying empty values. Similar case when we select the device2 data. This is one way to retrieve persistent data. You can also obtain the same in many ways.

This video will provide you with a brief introduction to the New Composer interface, which has been made available in the 7.4 and later releases of the ThingWorx Platform.  For complete details on what functionality is available within this next generation composer interface, and to also see what lies ahead on our road map, please refer to the following post in the ThingWorx Community: NG Composer feature availability

With the new licensing introduction, it could get confusing at first on how to obtain and apply, especially with more than one app in place. This is an example on how to apply both foundation and manufacturing license when installing Thingworx 8. 1) Install Manufacturing App 8.0 and needed components (ex: Kepware) per  the guide with manufacturing app license - manufacturing app widget can now be accessed. 2) Accessing /Thingworx reports a licensing issue 3) Download Thingworx license from the license portal. 4) Rename the manufacturing app license.bin to <name>.bin and put Thingworx license.bin in the ThingworxPlatform folder. 5) Restart Thingworx service 6) Access /Thingworx and accept license agreement 7) Change license.bin back to the original manufacturing app license.bin (step 4) 😎 Restart Thingworx server 9) Both manufacturing app and foundation functions are available.

New Generation Composer is available from ThingWorx 7.4 and later. Each subsequent release of ThingWorx will contain additional New Composer features/functionalities. This video is focused on the layout change and new features implemented from ThingWorx 7.4.     How to enable the new Composer? 1. In the top right-hand corner, click on the User Menu and select the Preferences option                Figure 1 2. Click the check box for Turn on New Composer Features. 3. Click Done. A New Composer link is added to the menu bar at the top of the Composer window.     Figure 2   4. Click the New Composer link to open a new tab for the New Composer view   Figure 3   What's the layout change in New Composer?     Three areas layout   Figure 4     Menu bar on the left (Area 1) Set Project Context to set default project name for new entities Two views: Recent and Browse Recent view will quickly locate the recent access entities Browse is almost the same to the old menu navigation bar Could be sizable or hidden, and the main idea here is to increase screen real-estate to allow bigger view/edit area Main area for listing and feeding entities in the middle (Area 2) It provides you a wider area to edit entities (author services, mashup builder, etc.) An extra area on the right for preview, properties/events editing, etc. (Area 3) It gave you an easier and handy way to get a glance of an entity’s basic information   Layout change in an entity’s editing page When you create a new Thing, you will find all the facets (general information, properties, services, events, subscriptions) of the Thing are listed in a dropdown list Figure 5       By doing so it will save more area for the feeding   Properties and Alerts Properties and Alerts are now listed separately (in two different Tabs) Figure 6 Figure 7  Properties and Alert are now edited on the right area of the page (See Figure 4 Area 3 Services and Subscription A bigger editor area Events Events are edited on right area of the page (See Figure 4 Area 3)   What's the main function/features change in New Composer   Industrial Connections The Industrial Connections entity allows you to connect with and configure industrial things in ThingWorx. With the “Discover” feature, you could easily bind the Industrial device’s (e.g., Kepware) Tags to a ThingWorx Entity Figure 8 From ThingWorx 8.0.0, Anomaly Alert type is supported An anomaly alert is only useful if you have configured Anomaly Detection to monitor a stream of data Anomaly metrics settings are allowed to be configured in the Alert edit page Figure 9 Subscriptions You could now manually remove a subscription permanently from the system in New Composer which is impossible in old Composer Services New Composer provided assistant scripting tools like static code analysis, String search or replace, etc Figure 10   How could I switch back to the Old Composer when editing an entity? It is so easy! As long as you have opened an ThingWorx Entity, you will notice there is a button “Edit in Composer”; it will lead you back to the old Composer, and all the editing that have been saved will be logged in the old Composer.     Video demonstration for the New Composer is also available now. Feel free to review from: New Composer Video

Welcome to the ThingWorx Manufacturing Apps Community! The ThingWorx Manufacturing Apps are easy to deploy, pre-configured role-based starter apps that are built on PTC’s industry-leading IoT platform, ThingWorx. These Apps provide manufacturers with real-time visibility into operational information, improved decision making, accelerated time to value, and unmatched flexibility to drive factory performance.   This Community page is open to all users-- including licensed ThingWorx users, Express (“freemium”) users, or anyone interested in trying the Apps. Tech Support community advocates serve users on this site, and are here to answer your questions about downloading, installing, and configuring the ThingWorx Manufacturing Apps.     A. Sign up: ThingWorx Manufacturing Apps Community: PTC account credentials are needed to participate in the ThingWorx Community. If you have not yet registered a PTC eSupport account, start with the Basic Account Creation page.   Manufacturing Apps Web portal: Register a login for the ThingWorx Manufacturing Apps web portal, where you can download the free trial and navigate to the additional resources discussed below.     B. Download: Choose a download/packaging option to get started.   i. Express/Freemium Installer (best for users who are new to ThingWorx): If you want to quickly install ThingWorx Manufacturing Apps (including ThingWorx) use the following installer: Download the Express/Freemium Installer   ii. 30-day Developer Kit trial: To experience the capabilities of the ThingWorx Platform with the Manufacturing Apps and create your own Apps: Download the 30-day Developer Kit trial   iii. Import as a ThingWorx Extension (for users with a Manufacturing Apps entitlement-- including ThingWorx commercial customers, PTC employees, and PTC Partners): ThingWorx Manufacturing apps can be imported as ThingWorx extensions into an existing ThingWorx Platform install (v8.1.0). To locate the download, open the PTC Software Download Page and expand the following folders:   ThingWorx Platform | Release 8.x | ThingWorx Manufacturing Apps Extension | Most Recent Datacode     C. Learn After downloading the installer or extensions, begin with Installation and Configuration.   Follow the steps laid out in the ThingWorx Manufacturing Apps Setup and Configuration Guide 8.2   Find helpful getting-started guides and videos available within the 'Get Started' section of the ThingWorx Manufacturing Apps Portal.     D. Customize Once you have successfully downloaded, installed, and configured the Manufacturing Apps, begin to explore the deeper potential of the Apps and the ThingWorx Platform.   Follow along with the discussion and steps contained in the ThingWorx Manufacturing Apps and Service Apps Customization Guide  8.2   Also contained within the the 'Get Started' page of the ThingWorx Manufacturing Apps Portal, find the "Evolve and Expand" section, featuring: -Custom Plant Layout application -Custom Asset Advisor application -Global Plant View application -Thingworx Manufacturing Apps Technical Lab with Sigma Tile (Raspberry Pi application) -Configuring the Apps with demo data set and simulator -Additional Advanced Documentation     E. Get help / give feedback / interact Use the ThingWorx Manufacturing Apps Community page as a resource to find documentation, peruse past forum threads, or post a question to start a discussion! For advanced troubleshooting, licensed users are encouraged to submit support tickets to the PTC My eSupport portal.

I've been working with the 7.x and 8.x versions of Thingworx over the last several months doing integrations. So I have a few development instances I've been working with. I'd like to go over some of the issues I've encountered and provide some potential best practices around how you work with Thingworx in development mode and transition to production. Typically, I'll create an instance and develop the integration using the Administrator user which is the only user created as you start up Thingworx instances. Lately, I've been having trouble with a lot of authentication failures as I build. Problem number 1: The new User Lockout feature. Around 7.2 a new User Lockout feature was added to Thingworx to help prevent brute-force cracking of passwords. You now are allowed only so many authentication failures in a given period of time before the user is automatically put in lock mode for a number of minutes. Unfortunately, (but realistically in a more secure manner), a lockout appears as more authentication failures. In reality, it is because the user you have just successfully authenticated to has been automatically locked. I came very close to wiping out an entire instance because I just couldn't get signed in. Then I remembered the lockout, so I worked on something else for a while and then tried to get back into the server and I was successful because the lock timeout had expired. To see the settings in your system, look at the User Management Subsystem configuration page. The Account Lockout Settings default to 5 failures in a 5 minute period that will result in a 15 minute lockout. One note is that setting the lockout to 0 doesn't disable it, it permanently locks out the account. It will have to be reset by a member of the administrators group. The screenshot below shows Problem number 2: AppKeys There is a new setting in the PlatformSubsystem that by default prevents the use of AppKeys in a URL. This setting is present because it is more secure. If you use an appKey as a query parameter in a URL, the appKey will be logged as clear text in your web browser's access log. This is a security risk - an AppKey, especially one not using a whitelist setting might make it possible for someone to gain access to your system by managing to see the access log for your system (maybe via some log analysis tool you feed your logs to). You can disable this setting, but it is not recommended for production - you may have to for a while because you may have code that uses this technique that must be updated before you can enforce the policy. You should deal with this in your production systems as soon as practical. See the graphic below on where this setting shows up. Problem number 3: REST API testing ​As a Thingworx developer, you're probably aware of tools like Curl, Postman and even the Web Browser that can let you exercise a REST API as you develop your code so you can validate your functionality. The REST guidelines specify that you should use the GET method to retrieve data, PUT to create data, POST to update data, etc. The issue is that it is easiest to test an API call if you can execute it from a web browser. However, the web browser always uses the GET method to make a request. This means that PUT and POST (along with other methods) will not work from your browser. Thingworx originally interpreted the incoming request and would internally reroute incoming requests to the POST or PUT functionality. This is also insecure because it makes it too easy to execute services from a browser. A setting was added to the PlatformSubsystem allow for a gradual transition to the more secure configuration. Turn this on in developer mode to simplify your testing of REST calls, but you should not leave it on in production mode as it provides a potential attack vector for your server. So I have some recommendations: 1) Set up an additional Administrative user upon installation If you only have one user defined and it gets locked out, you're stuck until the lockout times out. Worse, if for some reason you set the timeout value to 0, you're locked out forever by Thingworx. You're only choice will be to hack the database to unlock the user or to wipe out the instance and start over. I just went through a situation where I did create the second user and forgot to add it to the Administrators group. So I did something else for 20 minutes to make sure the lockout had cleared. Then I added the user to the Administrators group but got distracted and never pressed the Save button so it locked up again. Make sure you have the user created and functional immediately upon installing the instance - don't wait until you're getting locked out by some loop that's not authenticating properly. Even if you were logged in as your Administrator user, the lockout will cause a failure the next time you try to do something in Composer, like turn off the lockout checkbox! 2) Test your REST Calls with Curl or Postman - not the web browser Don't test your code in a loop until you've tested it in isolation to be sure it's not going to fail authentication for some reason (which may include violating the PlatformSubsystem settings above). Don't use the browser to do the testing - it will require disabling the secure settings. Use Curl or even better, Postman or a similar tool to test your REST calls - it will give you better formatted output than Curl. And you can easily put appKey in as a header (where it should be) instead of a parameter on the URL or in the body. 3) Tighten up your appKeys where possible. Since an appKey is effectively a user/password replacement, you should protect them in the same manner - keep them out of log files by not allowing them as URL parameters, and use the whitelist to keep them from being used for other purposes. If you have a server to server connection, whitelist the server who will be making the calls to you. What I'm not sure of is just whether this is really IP addresses only or if you can use a DNS name and it will look up the IP address and insure it is in fact coming from the expected source. Someone else might be able to comment on this. 4) Test with the PlatformSubsystem settings off Make sure you can run your server without the method redirect or appKey as parameter settings in the PlatformSubsystem. Those settings are potential security vulnerabilities. You may find some Thingworx code that requires one or the other of those settings. Please be sure to report this through PTC Tech Support so it can be fixed.

Yes, the ThingWorx Manufacturing apps can be imported as ThingWorx extensions into an existing ThingWorx Platform install (v8.0.1). ThingWorx Manufacturing Apps are imported as a ThingWorx extension for all instances other than the Express and Developer Edition licenses. Note: If you ran the Express installer, you cannot import ThingWorx Manufacturing Apps as a ThingWorx extension. Instructions for importing these are included with the download, or are also available here: Not authorized to view the specified document 3992

There are a few recommended troubleshooting steps to alleviate this: 1. The best practice is to install without an existing Tomcat implementation. Verify whether Tomcat is currently installed on this PC. If so, uninstall Tomcat and run the installer again. 2. Assign a different port for the servlet engine. This can be changed within the server.xml file located here: <Install path>\ThingWorxManufacturingApps\PTC_Servelet_Engine\conf\server.xml 3. If the installer has stopped at approximately 90% complete, and 5 minutes have elapsed, start the ThingWorx Servlet Engine Service manually from this directory in the Windows Explorer: <Install path>\ThingWorxManufacturingApps\PTC_Servlet_Engine\bin\thingworxServerw.exe 4. The Servlet Engine log files can be used for advanced troubleshooting. They are located in this directory by default: <Install path>\ThingWorxManufacturingApps\PTC_Servlet_Engine\logs

Follow these steps to restart the ThingWorx Server, then to verify that all install services are running: 1. Open the ThingWorx Server Properties configuration application. To locate this application in Windows Server edition operating systems, search for "Configure PTC Servelet Engine"; or the application can be launched from the Windows Explorer. The default install directory is: <ThingWorx install path>\ThingWorxManufacturingApps\PTC_Servlet_Engine\bin\thingworxServerw.exe 2. Use the controls in the General tab to Stop and then Start this service. 3. Now open the Windows Services console (services.msc) and verify these four services are installed and running:      a. ThingWatcherResult      b. ThingWatcherTraining      c. Thingworx Server      d. ThingworxPostqresql_Service-PostgreSQL_Server9.4

When installing KEPServerEX, you will be presented with a tree of features to install. Open the pull-down menu next to "Full install" and select "Entire feature will be installed on local hard drive." This will ensure all needed drivers and plug-ins are included. When either a Client application has made a request of a Driver, or a Plug-in becomes activated, then a license check is performed. If a feature is not licensed, a two-hour demo countdown period will begin. For more information on this, see: KEPServerEX V6 Demo Timer

A license is not required to download and install KEPServerEX V6. After finishing the full install, all features of the KEPServerEX Configuration are available for setup and testing, including the ThingWorx Native Interface. When either a Client application makes a request of a Driver, or a Plug-in becomes activated, then a license check is performed. If a feature is not licensed, a two-hour demo countdown period will begin for that feature. There are System tags that can be monitored in KEPServerEX to determine which features are licensed, which are in a time-limited demo countdown period, and which have expired. To reset the countdown timer for an unlicensed feature, the KEPServerEX Runtime service can be stopped/restarted. See the links and steps below for more information. How do I download and install KEPServerEX?​ Monitor licensed, time-limited, and expired features in KEPServerEX:​ 1. Open the KEPServerEX Configuration window 2. The right-most icon in the Configuration icon toolbar is the white "QC" icon. Select this icon to launch a new OPC Quick Client window. The server project should automatically build 3. In the left pane, locate the _System folder 4. Within this folder locate the following three Tags, with the corresponding information displaying in the Value column: Tag (Item ID) Information displayed as a String in the Value column _System._ExpiredFeatures Any unlicensed driver or plug-in that has timed out _System._LicensedFeatures Drivers or plug-ins that are currently licensed for use with this install _System._TimeLimitedFeatures Any unlicensed driver or plug-in that is in demo mode, with the remaining demo timer countdown (in seconds) Note: The ThingWorx Native Interface does not require a KEPServerEX license. Restart the KEPServerEX Runtime service The KEPServerEX Runtime service (server_runtime.exe) runs in the background as a system service. Resetting this service will reset the demo countdown for any unlicensed feature. To reset the Runtime service: 1. Right-click on the Administration tool (the green EX icon in the Systray by the System Clock) 2. Select "Stop Runtime Service. 3. Either the user will be prompted to restart this service, or the same Administration tool menu can be used again to "Start Runtime Service"

Overview Time-series predictive models generated by ThingWorx Analytics Server in Analytics Manager will have additional columns in their dataShape generated by ThingPredictor. These columns are known as “transformation fields” and are used for internal processing but are not necessary for inclusion in the DataShape.  So there is no need to worry about mapping all these additional fields since it will be handled internally by ThingPredictor.  There is one addition step that the user must take which is detailed below. Step to Import: Edit the DataShape generated by ThingPredictor to match the format of the data that was provided during the model training process. In other words, remove all the transformation fields from the DataShape.

The KEPServerEX ThingWorx Native Interface was originally released with KEPServerEX v5.21 to enable connectivity with v6.6 of the ThingWorx Platform. Compatibility with the ThingWorx NextGen Composer (v7.4) was implemented with the release of KEPServerEX v6.1, while still allowing support of older ThingWorx composer versions through the Native Interface "Legacy mode" setting.   When connecting with ThingWorx v7.4 and newer, an Industrial Gateway thing template is configured in the NextGen Composer. The instructions for connecting KEPServerEX v6.1 (and newer) with ThingWorx v7.4 (and newer) can be found in the ThingWorx Help Center here:   KEPServerEX / ThingWorx Industrial Connectivity Connection Example (Expand ThingWorx Model Definition and Composer > Industrial Connections > Industrial Connections Example)     When connecting with versions of ThingWorx that are older than v7.4-- or if the older version of ThingWorx Composer will be used-- it will necessary to download and import the KEPServerEX Extension from the ThingWorx marketplace. The "RemoteKEPServerEXThing" thing template will then be used to allow connection with KEPServerEX. Here is a link to the extension download: ThingWorx IoT Marketplace   To enable Legacy Mode in KEPServerEX (v6.1 or newer, when connecting with versions of ThingWorx that are older than v7.4): 1. Open the KEPServerEX Configuration window 2. In the top-left Project view pane, right-click on "Project" and select "Properties" 3. Select the ThingWorx Property Group 4. Change "Enable" to "Yes"; and change "Legacy Mode" to "Enable"     See the chart below for a version compatibility summary:   KEPServerEX version ThingWorx version v5.21 pre-7.4, using RemoteKEPServerEXThing v6.0 pre-7.4, using RemoteKEPServerEXThing v6.1 or higher w/ Legacy Mode enabled pre-7.4, using RemoteKEPServerEXThing v6.1 or higher w/ Legacy Mode disabled (default) v7.4 or higher, using Industrial Gateway