IoT & Connectivity Tips

ThingWorx 8.5 Sizing Guide Sizing is a very important part of the application design process, answering such questions as: how much hardware is required? What specifications does this hardware need to handle the expected load? And therefore, what is the overall cost of setting up and maintaining the ThingWorx environment? Properly sizing the environment before development begins ensures that there are no unexpected costs or limitations to application functionality later on down the road.   "Hardware sizing is driven by many factors - some more easily calculated than others", as stated in the new ThingWorx 8.5 Sizing Guide. "Measures like data streaming frequency (the data ingestion component) and HTTP request volume (the data visualization component) are easily calculated... However, sizing considerations for the data processing component of the application can depend largely on business use cases and application design." Enterprise-Ready applications have the capacity to handle all aspects of an IoT application, from data ingestion and processing to data visualization, as detailed in the friendly infographic above, which many will recognize from LiveWorx. Inside the ThingWorx 8.5 Sizing Guide,  there are formulas designed to help size the more analytical aspects of the application, as well as descriptions of other factors and how they (conceptually) play a role in sizing.    There are also two application design examples which step the reader through the calculations, the comparisons, and the selections of hardware for each use case. New in this version, these examples have been simulated in the real world to prove that the theory behind these calculations is sound, and to demonstrate the full process of designing, sizing, and testing an application.  One of the examples (shown here) sizes a Connected Product Solution, something which has many, many remote things in the field, each writing to the Platform at a slower rate, for consumption by a large number of general users, who don't access the same mashups many times nor refresh their view very often. The second example is much more complex, modeling an industrial use-case, where there are many different kinds of users each accessing the mashups many times, fewer things, and more variations in the types of properties each thing possesses. These examples are designed to help anyone with any use case step through the sizing of their application properly.   Please check out the new ThingWorx 8.5 Sizing Guide, especially because each version of ThingWorx is different and must be sized accordingly. Comments and questions about the guide are very welcome right here on this thread!

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

Good evening and Happy New Year!   I launched version 2.3.0 of the GitBackup Extension.  The release is available here https://github.com/vrosu/thingworx-gitbackup-extension/releases/tag/V2.3.0   It adds the capability to push commits using User specific Committer Name and Email. This is an optional feature, which allows multiple developers to push commits under their own credentials. The documentation was updated with more details about this.   This release certifies the Extension to work for ThingWorx 8.5.x. (Previous ThingWorx versions have not been tested and the documentation was updated accordingly).    As always, this extension is not a PTC supported product, so in case you have issues with it, please do not open a PTC Tech Support ticket and instead use GitHub's issue system or the PTC Community.   Please feel free to fork and improve it.

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

In this post I show how to use Federation in ThingWorx to execute services on a different ThingWorx platform instance. In the use case below I set up one ThingWorx instance in the Factory and another instance in the Cloud, whereby the latter is executing a service which is actually running on the former.   Please find the document in attachment.   HTH, Alessio Marchetti  

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

The intend of this post. This post is for the user who want to validate that, the ThingWorx Analytics Services related to Confidence Models work successfully. Underneath video walk through the steps to validate the Services via a non-supported PTC Mashup. The intend of this video is uniquely to validate that, Services related to Confidence Models works successfully.  What package files are used in the video? The Mashup entities and dataset used in the video, is attached to this post. Feel free to download the files and test on your machine. Why use Confidence Models? A confidence model is a way of adding confidence interval information to a predictive model. Statistically, for a given prediction, a confidence model provides an interval with upper and lower bounds, within which it is confident, up to a certain level, that the actual value occurs. During predictive scoring, this measure of confidence provides additional information about the accuracy of the prediction. More information about Confidence Models can be found here at PTC Help Center 

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

One of the signature features of the Axeda Platform is our alarm notification, signalling and auditing capabilities.   Our dashboard offers a simplified view into assets that are in an alarm state, and provides interaction between devices and operators.  For some customers the dashboard may be too extensive for their application needs.  The Axeda Platform from versions 6.6 onward provide a number of ways of interacting with Alarms to allow you to present this data to remote clients (Android, iOS, etc.) or to build extended business logic around alarm processing. If one were to create a remote management application for Android, for example, there are the REST APIs available to interact with Assets and Alarms.  For aggregate operations where network traffic and round-trip time can be a concern, we have our Scripto API also available that allows you to use the Custom Object functionality to deliver information on many different aggregating criteria, and allow developers to get the data needed to build the applications to solve their business requirements. Shown below is a REST API call you might make to retrieve all alarms between a certain time and date. POST:   https://INSTANCENAME/services/v2/rest/alarm/find <v2:AlarmCriteria xmlns:v2="http://www.axeda.com/services/v2" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">    <v2:date xsi:type="v2:BetweenDateQuery">     <v2:start>2015-01-01T00:00:00.000Z</v2:start>     <v2:end>2015-01-31T23:59:59.000Z</v2:end>   </v2:date>   <v2:states/> </v2:AlarmCriteria>   In a custom object, this would like like the following: import static com.axeda.sdk.v2.dsl.Bridges.* import com.axeda.services.v2.* import com.axeda.sdk.v2.exception.* def q = new com.axeda.services.v2.BetweenDateQuery() q.start = new Date() q.end = new Date() ac = new AlarmCriteria(date:q) aresults = alarmBridge.find(ac)   Using the same API endpoint, here's how you would retrieve data by severity: <v2:AlarmCriteria xmlns:v2="http://www.axeda.com/services/v2" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">    <v2:severity xsi:type="v2:GreaterThanEqualToNumericQuery">     <v2:value>900</v2:value>   </v2:severity>   <v2:states/> </v2:AlarmCriteria>   Or in a custom object: import static com.axeda.sdk.v2.dsl.Bridges.* import com.axeda.services.v2.* import com.axeda.sdk.v2.exception.*   def q = new com.axeda.services.v2.GreaterThanEqualToNumericQuery() q.value = 900 ac = new AlarmCriteria(severity:q) aresults = alarmBridge.find(ac)   Currently the Query Types do not map properly in JSON objects - use XML to perform these types of queries via the REST APIs. References: Axeda v2 API/Services Developer's Reference Guide 6.6 Axeda Platform Web Services Developer Reference v2 REST 6.6 Axeda v2 API/Services Developer's Reference Guide 6.8 Axeda Platform Web Services Developer Reference v2 REST 6.8

Background: Firewall-Friendly Agents can be configured for server certificate authentication in the Axeda Builder project or via the Axeda Deployment Utility. When server certificate authentication is configured, the Agent will compare the certificate chain sent by the Platform to a local copy of the CA certificate chain stored in the SSLCACert.pem file in the Agent’s home directory. The certificate validation compares three things: Does the name of the Platform certificate match the name in the request? Does the CA certificate match the CA certificate that signed the Platform certificate? Is the Platform or CA certificate not expired? If the answer to any of these questions is “no”, then connection is refused and the Agent does not communicate further with the Platform. To determine if certificate trouble is an issue, see the Agent log: EKernel.log or xGate.log. Recommendation: For Agent-Platform communications, we recommend always using SSL/HTTPS. If the Agent is not configured to validate the server certificate (via the trusted CA certificate), the system is vulnerable to a number of security attacks, including “man in the middle” attacks. This is critically important from a security perspective. Note: For on-premise customers, if the Platform certificate needs to change, always update the SSLCACert.pem file on all Agents before updating the Platform certificate. (If the certificate is changed on the Platform before it is changed on the Agents, communications from the Agent will stop.) Note: Axeda ODC automatically notifies on-demand customers about any certificate updates and renewals. At this point, though, Axeda ODC certificate updates are not scheduled for several years. Finally, it is recommended that your Axeda Builder project always specify “Validate Server Certificate” and set the encryption level to the strongest level supported by the Web server. Axeda recommends 168 bit encryption, which will use one of the following encryption ciphers: AES256-SHA or DES-CBC3-SHA. Need more information? For information about configuring and managing Agent certificate authentication, see Using SSL with Axeda® Platform Guide.

This demo walks through how Range Count works. The Range Count service calculates the difference between the maximum and minimum value.  Agenda of the demo: 1. Create a demo Thing 2. Add a new property to the Thing 3. Add the property statistical calculation type Range Count to the Thing 4. Validate the statistical calculation service via the added calculation type Range Count 5. Validate the statistical calculation service via the Service QueryTimedValuesForProperty      

Background: Axeda Agents can be configured with standard drivers to collect event-driven data, which is then sent to the Platform. Axeda provides many standard event-driven data (EDD) drivers for use with the Axeda Agent (as explained in Axeda® Agents EDD Toolkit Reference (PDF)). All EDD  drivers are configured by an xml file and enabled in Axeda Builder, through the Agent Data Items configuration. You can configure an EDD driver to send important information from your process to the Agent, including data items, events and alarms. The manner in which you configure your drivers will affect the ability for your project to operate efficiently. Recommendation: Use drivers to reduce the amount of data sent to the platform. Instead of sending data items to the Platform, which then generates an event or alarm, it is possible to use the drivers to scan for specific data points or conditions and send an event or alarm. Before you can configure your agents, you first need to determine how often you will need your agent to send data to the Enterprise server. Two example workflows and recommendations: If you want to monitor a data item every second or two, configure the Agent to do the monitoring If you want to trend information once per day, perform that logic at the Enterprise Server. These examples may address your actual use case or your needs may fall somewhere in between. Ultimately, you want to consider that time scale (how often you want to monitor or trend data) and resulting data volume should drive how your system handles data. More data is available at the Agent, and at a higher frequency, then that needed at the Platform. Processing at the Agent ensures that only the important results are communicated to the Platform, leading to a “cleaner” experience for the Platform. Using this guidance as a best practice will help reduce network traffic for your customers as well as ensure the best experience for Enterprise users using server data in their dashboards, reports, and custom applications. Need more information? For information about the standard EDD Drivers, see the Axeda® Agents: EDD Drivers Reference (PDF).

Background: The frequency with which an Agent checks its connection to the Axeda Cloud Server is called the Agent “ping rate” (also known as heartbeat). (For Axeda IDM Agents, ping rate is referred to as “poll rate”; the meaning is the same.) Pings are a very important aspect of Firewall-Friendly communication. All communication between the Agent and the Cloud Server is initiated by the Agent. In addition to indicating the Agent is still active, the Ping also gives the Cloud Server an opportunity to send commands back to the Agent on the Ping acknowledgement. The ping rate effectively defines how long users must wait before they can deliver a command or request to an Agent. Typical commands may include setting a data item, starting an Access Session, or running a script. The place where Ping rate is most noticeable to system users is when requesting a remote session. When a session request has been submitted by the user, the Cloud Server waits for the next Agent ping in order to send down the command to begin the session process. A longer ping rate means the remote session takes longer to get started. (Note that the same is true of any command initiated from the Axeda Cloud Server.) Ping traffic comprises the majority of inbound traffic to the Cloud Server. The higher the ping rate, the more resources are consumed on the Server and the greater the requirements for network bandwidth for the customer. Unnecessarily high ping rates will result in an increase in network traffic on your customer's network. By default, the ping rate for Firewall-Friendly Agents is 60 seconds, or every 1 minute. The Agent ping rate is set using Axeda Builder when configuring the project. The ping rate can also be set via an action from the Axeda Cloud Server. When set via an action, the new ping rate is in effect until the next Agent restart (at which time the Agent will go back to the default ping rate set in the project). The Axeda Cloud Server also uses Agent ping rate to determine when assets are missing. One of the model settings is to define how many missed pings (or missed pings and time) will cause a device to be marked as missing. The default setting for new models is to mark assets as missing after they’ve missed 3 consecutive pings. Recommendations: Make sure that your Agents’ ping rates are set to reasonable frequencies. The ping rate should be set based on use case and not necessarily volume. The recommended practice is to make sure the ping rate is never set less than 60 seconds. Where possible the ping rate should be set to 2 minutes or higher. In the end, it is often user expectations around starting Access sessions that drives the ping rate value. If only occasional user access is required, one recommendation is to dynamically adjust the ping rate when conditions require expedited communication with the Cloud Server. One use case is to expedite a remote session when a device is in alarm condition or when an end user needs assistance. In this case you would temporarily increase the ping rate. This can be done using an action from the Cloud Server, by downloading a software package ping rate update, or by Agent extension using the SDK. (For information about using the Agent SDK, see the Axeda® Platform Extending Axeda® Agents PDF.) You can configure alerts to indicate if an asset is missing. Axeda recommends that you configure the alert to a reasonable time given your resources and the expense of tracking every missing asset. A reasonable missing alert for your organization may be 1-2 days, meaning the Server generates the missing asset alert only after the asset has been missing for one or two days, based on its ping rate, and an asset should be marked as missing only after 15 missed pings or 30 minutes (whichever is less). The most common cause of a missing asset is not an issue with the device but rather the loss of Internet connectivity. Note: Any communication from an Agent also serves the function of a Ping. E.g., if the ping rate is set to 30 minutes and the device is sending a data value every 5 minutes, the effective Ping rate is 5 minutes. Need more information? For information about specifying Agent ping rate, see the online help in Axeda® Builder (Enterprise Server Settings). If setting the ping rate from Platform actions or verifying Agent ping rates, see the online help of the Axeda® Connected Management Applications.

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

The RabbitMQ Management plugin provides a web-based interface into the inner workings of the messaging bus behind ThingWorx Flow. It is installed by the Flow installers but is an HTTP service by default and is a totally different web server than the NGINX used to front-end ThingWorx Flow. This will describe how to integrate it into the NGINX on your ThingWorx Flow server. This is necessitated by some recent browser behavior changes that make it very hard to get to the http port once you've used an https service on the same machine from the same browser.   First - let's find the user name and password for the RabbitMQ Management plugin. On a Linux server, the file /etc/rabbitmq/definitions.json will hold the name and password for the plugin's UI:         "users": [{                 "name": "flowuser",                 "password": "1780edc6b8628ace2ace72465cdc7b048c88",                 "tags": "administrator"         }],   On a Windows server, the definitions.json file can be found under [flow install location]\modules\RabbitMQ.   Of course, access to these directories should be limited.   Second - let's integrate the plugin into NGINX The best way to integrate the plugin into Flow is to let NGINX reverse proxy to the other http server running the UI for the plugin, which is exactly what happens for Thingworx itself. That way, only NGINX has to be configured for https and no other ports need to be opened to allow access to the plugin.   You need to find the file vhost-flow.conf on your system. On Linux, this will be /etc/nginx/conf.d/vhost-flow.conf. On Windows, it will be at C:\Program Files\nginx-[version]\conf\conf.d\vhost-flow.conf by default. Add the following fragment after the last location xxx {…} segment in the file:       # deal with the rabbitMQ admin tool     location ~* /rabbitmq/api/(.*?)/(.*) {         proxy_pass http://127.0.0.1:15672/api/$1/%2F/$2?$query_string;         proxy_buffering                    off;         proxy_set_header Host              $http_host;         proxy_set_header X-Real-IP         $remote_addr;         proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;         proxy_set_header X-Forwarded-Proto $scheme;     }       location /rabbitmq {         rewrite ^/rabbitmq$ /rabbitmq/ permanent;      }       location ~* /rabbitmq/(.*) {         rewrite ^/rabbitmq/(.*)$ /$1 break;         proxy_pass http://127.0.0.1:15672;         proxy_buffering                    off;         proxy_set_header Host              $http_host;         proxy_set_header X-Real-IP         $remote_addr;         proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;         proxy_set_header X-Forwarded-Proto $scheme;     }   This makes the request for /rabbitmq get pushed over to the web server at port 15672 on the Flow server.   Test the updated config file with (nginx may not exist in your normal path): nginx -t   Restart the NGINX service: Linux (one of these will work depending upon your Linux version): systemctl restart nginx service nginx restart Windows: Net stop ThingWorxOrchestrationNginx Net start ThingWorxOrchestrationNginx -or- use the Services app to restart the service   Thanks to https://groups.google.com/forum/#!topic/rabbitmq-users/l_IxtiXeZC8 for the needed config changes.   You can now use https://yourserver/rabbitmq to get to the login page for the management plugin. Login with the user and password from the definitions.json file on your system and you can now monitor the behavior of your RabbitMQ environment.

Background: In very rare situations, it is possible that the Firewall-Friendly Agent process may stop running. If the Agent is not running, no machine monitoring or communication with the Cloud Server is possible. Recommendation: WatchDog is a little known yet very helpful feature available with Firewall-Friendly Agents. This program lets you monitor whether an Agent is running; if it’s not running, WatchDog can restart that Agent if needed. If the Agent process fails, WatchDog can bring it back up! WatchDog can also be configured to watch other processes. You can configure WatchDog to run as a service (for Windows) or daemon (for Linux). You will register the Watchdog to run as a service.  The Watchdog configuration file will specify the process(es) to be monitored and what to do when one exits. The options are to attempt to restart the process or to restart the system. Note: Watchdog detects only if a watched process exits. It will not detect or report on processes that may be “hanging”. Need more information? For information about configuring and using WatchDog, see the Agent User’s Guide for your Agent: either Axeda® Platform Axeda® Gateway User’s Guide (PDF) or Axeda® Platform Axeda® Connector User’s Guide (PDF).

Having trouble remembering how to get into Flow? How about make /Flow the URL?   Since the Flow environment uses NGINX to front-end the various components that make up Flow, there is a very sophisticated set of rewrites and proxy_pass directives in the NGINX configuration. All you have to do is add another 'location' fragment to the vhost-flow.conf file that will push /Flow over to /Thingworx/Composer/apps/flow:       location /Flow {       rewrite ^/Flow$ $proxy_scheme://$server_host/Thingworx/Composer/apps/flow permanent;     }   On Linux, the file should be at /etc/nginx/conf.d/vhost-flow.conf   On Windows, the file should be at c:\Program Files\nginx-[version]\conf\conf.d\vhost-flow.conf   Test the updated config file with (nginx may not exist in your normal path): nginx -t   Restart the NGINX service: Linux (one of these will work depending upon your Linux version): systemctl restart nginx service nginx restart Windows: Net stop ThingWorxOrchestrationNginx Net start ThingWorxOrchestrationNginx -or- use the Services app to restart the service   From this point forward https://yourserver/Flow will take you to ThingWorx Flow's home page.

Background: Customer machines create files containing data, configuration, log data, etc. These files may contain critical information for service technicians about the asset and its data. How can you make sure you get this important information to the Cloud as soon as it’s available? Use File Watcher, a standard tool available with Firewall-Friendly Agents. You can configure File Watcher to monitor a directory or file specification and automatically upload the file(s) to the Axeda Cloud. By monitoring selected directories and files on the device, the File Watcher determines which files have changed or appeared and then upload those files to the Axeda Cloud Server. Sometimes the size of the file being written or copied into the file watch target is large enough that it takes time to complete. Without taking the right precautions, the file upload may try to start before the file creation process is completed. Recommendations: To ensure that large files don’t cause problems, we recommend using a “move” or “rename” operation instead of a file copy operation to place your file into a watched directory. Unlike a “copy” operation, using autonomous operations like move or rename will ensure that the Agent doesn’t detect a file is in the midst of growing and prematurely begin to upload that operation. In situations when it isn’t possible to use the autonomous “move” or “rename” operations, you can implement a delay. Setting a delay in the File Watcher configuration will prevent the Agent from sending files to the Axeda CloudServer before those files have transferred completely to the watched file directory. Finally, use file compression wisely. You need to balance the benefits from compressing files before sending with the potential adverse impact that compression will have on the Agent. Compressing very large files BEFORE sending to the Platform will affect the Agent; however, compressing smaller files can be beneficial. If the Agent’s computer is of lower power, the CPU may have to work overtime to compress huge files or to send huge uncompressed files. As a general rule, compressing files before sending is recommended. However, depending on your Agent and network setup, it may prove more beneficial to stream uncompressed files rather than compress first and then send. Need more information? For information about configuring and using file watchers, see the Axeda® Builder User’s Guide (PDF) or the online help in Axeda Builder.

Hello Navigate Community -     In case you haven't heard, Navigate 8.5 was released last Thursday, 9/26 and is now available for download! This release includes a lot of exciting functionality:   1. Improvements to View Apps -  Updated ThingView 3D Viewing Component - which is now documented & supported for use in custom mashups;  Support for distributed vaults;  Display of security labels & values. 2. BETA release of the first Reusable Components for rapid application development  3. First Navigate Contribute App for review & approval of Windchill Change Requests Want to learn more? Read on!   Introducing change can result in higher costs if not fully considered.  That’s why collaboration is a necessity across people and processes from the initial state of product ideation through to manufacturing, device connectivity and field service.  There is a need to not just access product and enterprise data easily, but to participate in strategic product lifecycle processes in order to avoid unintended consequences.   ThingWorx Navigate 8.5 introduces the first App in the Contribute Series. This App allows key stakeholders to be directly involved in the change process by enabling them to voice their opinions. The first of the Contribute apps for Change Management stitches all these voices together within the digital thread.   Inter-operable with Windchill 11.2 and Windchill 11.1 M020 CPS06, this change management app provides a list of open approval tasks and access to full details of the Change Request, along with attachments and affected items.   Configurable by role, this latest Navigate App enables a broad set of users inside and outside of engineering to fully participate in a digital change management workflow. Cross-functional users who review their task list, via “My Tasks”, are best able to complete changes online. These users can then assess change impacts at time of review, resulting in improved quality by eliminating the need to manually capture input and avoiding errors.   Role-based tailoring facilitates faster, clearer decision making and higher quality changes.  Better participation in the change management process adds the value of faster time to market. This Contribute app is the first to be built from reusable components, thus lowering costs and improving efficiency.   The Thingworx Navigate Contribute app for Change Management enables the wider spread of input to realize the best possible design since products are no longer designed in a silo.   If you have any questions about Navigate or want to connect with an account rep, reach out to me at elarkin@ptc.com.

   Who’s ready for exciting new functionality like smoother integration with Azure, rapid deployment capabilities, flexible KPIs and so much more?   Good news! Yesterday, we released ThingWorx 8.5—equipped with features like a new Azure connector for ThingWorx Flow, new software content management (SCM) capabilities with the Azure IoT Hub Connector, streamlined deployments with Solution Central, flexible KPI calculations with our PTC manufacturing and service apps—just to name a few. Check out the 8.5 release notes to discover all the highlights and goodness of our latest release and hear our CTO of IoT, Joe Biron (who you may recognize from previous Ask Kaya posts) and one of our product experience specialists, Sebastian Bergner, highlight new functionality and share demos in this exciting webcast (please note that we've had a little snafu with the link and the recording should be available later this week).   Play around with our new features by downloading ThingWorx 8.5, and let the good times roll.   Let us know what you think in the comments below and be on the lookout for future Ask Kaya posts highlighting new 8.5 functionality.   Stay connected, Kaya

ThingWorx Foundation Flow Enable customers using Azure to take advantage of Azure services Access hundreds of Azure system connectors by invoking Azure Logic Apps from within ThingWorx Flow Execute Azure functions to leverage Azure dynamic, serverless scaling and pay just for processing power needed Access Azure Cognitive AI services for image recognition, text to voice/voice to text, OCR and more Easily integrate with homegrown and commercial solutions based on SQL databases where explicit APIs or REST services are not exposed Automatically trigger business process flows by subscribing to Windchill object class and instance events Provide visibility to mature PLM content (such as when a part is released) to downstream manufacturing and supply chain roles and systems Easily add new actions by extending functionality from existing connectors to create new actions to facilitate common tasks Inherit or copy functionality from existing actions and change only what is necessary to support new custom action Azure Connector SQL Database Connector Windchill Event Trigger Custom Action Improvements Platform Composer: Horizontal tab navigation is back!  Also new Scheduler editor. Security: TLS 1.2 support by default, new services for handling expired device connections New support for InFlux 1.7 and MSSQL 2017 * New* Solution Central Package, publish and upload your app with version info and metadata to your tenancy of Solution Central in the PTC cloud Identify missing dependencies via automatic dependency management to ensure your application is packaged with everything required for it to run on the target environments Garner enterprise-wide visibility of your ThingWorx apps deployed across the enterprise via a cloud portal showcasing your company’s available apps, their versions and target environments to foster a holistic view of your entire IIoT footprint across all of your servers, sites and use cases Solution Central is a brand-new cloud-based service to help enterprises package, store, deploy and manage their ThingWorx apps Accelerate your application deployment Initially targeted at developers and admins in its first release, Solution Central enables you to: Mashup Builder 9 new widgets, 5 new functions. Theme Editor with swappable Mashup Preview Responsive Layout enhancements including new settings for fixed and range sizes New Builder for custom screen sizes, new Widget and Style editors, Canvas Zoom Migration utility available for legacy applications to help move to latest features Security 3 new built-in services for WebSocket Communications Subsystem: QueryEndpointSessions, GetBoundThingsForEndpoint, and CloseEndpointSessions Provide greater awareness of Things bound to the platform Allow for mass termination of connections, if necessary Can be configured to automatically disconnect devices with expired authentication methods Encrypting data-in-motion (using TLS 1.2) is a best practice for securely using ThingWorx For previous versions, the installer defaulted to not configuring TLS; ThingWorx 8.5 and later installers will default to configuring TLS ThingWorx will still allow customers to decline to do so, if desired Device connection monitoring & security TLS by default when using installer   ThingWorx Analytics Confidence Model Training and Scoring (ThingWorx Analytics APIs) Deepens functionality by enabling training and scoring of confidence models to provide information about the uncertainty in a prediction to facilitate human and automated decision making Range Property Transform and Descriptive Service Improves ease of implementation of data transformations required for common statistical process control visualizations Architecture Simplification Improves cost of ownership by reducing the number of microservices required by Analytics Server to reduce deployment complexity Simplified installation process enables system administrators to integrate ThingWorx Analytics Server with either (or both) ThingWorx Foundation 8.5 and FactoryTalk Analytics DataFlowML 3.0.   ThingWorx Manufacturing and Service Apps & Operator Advisor Manufacturing common layer extension - now bundling all apps as one extension (Operator Advisor, Asset Advisor, Production KPIs, Controls Advisor) Operator Advisor user interface for work instruction delivery Shift and Crew data model & user interface Enhancements to Operator Advisor MPMLink connector Flexible KPI calculations Multiple context support for assets   ThingWorx Navigate New Change Management App, first in the Contribute series, allows a user to participate in change request reviews delivered through a task list called “My Tasks” BETA Release of intelligent, reusable components that will dramatically increase the speed of custom App development Improvements to existing View Apps Updated, re-usable 3D viewing component (ThingView widget) Support for Windchill Distributed Vaults Display of Security Labels & Values   ThingWorx Azure IOT Hub Connector Seamless compatibility of Azure devices with ThingWorx accelerators like Asset Advisor and custom applications developed using Mashup Builder. Ability to update software and firmware remotely using ready-built Software Content Management via “ThingWorx Azure Software Content Management” Module on Azure IoT Edge. Quick installation and configuration of ThingWorx Azure IoT Hub Connector, Azure IoT Hub and Azure IoT Edge SCM module.   Documentation ThingWorx Platform ThingWorx Platform 8.5 Release Notes ThingWorx Platform Help Center ThingWorx 8.5 Platform Reference Documents ThingWorx Connection Services Help Center   ThingWorx Azure IoT Hub Connector ThingWorx Azure IoT Hub Connector Help Center   ThingWorx Analytics ThingWorx Platform Analytics 8.5.0 Release Notes Analytics Server 8.5.1 Release Notes ThingWorx Analytics Help Center   ThingWorx Manufacturing & Service Apps and ThingWorx Operator Advisor ThingWorx Apps Help Center ThingWorx Operator Advisor Help Center   ThingWorx Navigate ThingWorx Navigate 8.5 Release Notes Installing ThingWorx Navigate 8.5 Upgrading to ThingWorx Navigate 8.5 ThingWorx Navigate 8.5 Tasks and Tailoring Customizing ThingWorx Navigate 8.5 PTC Windchill Extension Guide 1.12.x ThingWorx Navigate 8.5 Product Compatibility Matrix ThingWorx Navigate 8.5 Upgrade Support Matrix ThingWorx Navigate Help Center     Additional Information Helpcenter ThingWorx eSupport Portal ThingWorx Developer Portal PTC Marketplace The National Instruments Connector can be found on PTC Marketplace