IoT & Connectivity Tips

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

Get Started with ThingWorx for IoT Guide Part 5   Step 13: Extend Your Model   Modify the application model, enhance your UI, and add features to the house monitoring application to simulate a request as it might come from an end user. For this step, we do not provide explicit instructions, so you can use critical thinking to apply your skills. After completing the previous steps, your Mashup should look like this:   In this part of the lesson, you'll have an opportunity to: Complete an application enhancement in Mashup Builder Compare your work with that of a ThingWorx engineer Import and examine ThingWorx entities provided for download that satisfy the requirements Understand the implications of ThingWorx modeling options   Task Analysis   Add a garage to the previously-created house monitoring web application and include a way to display information about the garage in the UI. You will need to model the garage using Composer and add to the web application UI using Mashup Builder. What useful information could a web application for a garage provide? How could information about a garage be represented in ThingWorx? What is the clearest way to display information about a garage?   Tips and Hints   See below for some tips and hints that will help you think about what to consider when modifying the application in ThingWorx. Modify your current house monitoring application by adding a garage: Extend your model to include information about a garage using Composer. Add a display of the garage information to your web application UI using Mashup Builder.   Best Practices   Keep application development manageable by using ThingWorx features that help organize entities you create.   Modeling   The most important feature of a garage is the status of the door. In addition to its current status, a user might be interested in knowing when the garage door went up or down. Most garages are not heated, so a user may or may not be interested in the garage temperature.   Display   The current status of the garage door should be easily visible. Complete the task in your Composer before moving forward. The Answer Key below reveals how we accomplished this challenge so you can compare your results to that of a ThingWorx engineer.   Answer Key   Confirm you configured your Mashup to meet the enhancement requirements when extending your web application. Use the information below to check your work.   Create New Thing   Creating a new Thing is one way to model the garage door. We explain other methods, including their pros and cons, in the Solution discussion below. Did you create a new Thing using the Building Template? Did you apply a Tag to the new Thing you created?   Review detailed steps for how to Create a Thing in Part 2 of this guide.   Add Property   Any modeling strategy requires the addition of a new Property to your model. We explore options for selecting an appropriate base type for the garage Property in the Solution discussion on the next step. Did you add a Property to represent the garage door? Did you use the Boolean type? Did you check the Logged? check-box to save history of changes?   Review detailed steps for how to Add a Property. in Part 1, Step 3 of this guide.   Add Widget   In order to display the garage door status, you must add a Widget to your Mashup. We used a check-box in our implementation. We introduce alternative display options in the Solution discussion on the next step. Did you add a Widget to your Mashup representing the garage door status? Review detailed steps for how to Create an Application UI in Part 3, Step 8 of this guide.   Add Data Source   If you created a new Thing, you must add a new data source. This step is not required if you added a Property to the existing Thing representing a house. Did you add a data source from the garage door Property of your new Thing? Did you check the Execute on Load check-box? Review detailed steps for how to Add a Data Source to a Mashup in Part 4, Step 10 of this guide.   Bind Data Source to Widget   You must bind the new garage door Property to a Widget in order to affect the visualization. Did you bind the data source to the Widget you added to your Mashup? Review detailed steps for how to Bind a Data Source to a Widget in Part 4, Step 10 of this guide.   Solution   If you want to inspect the entities as configured by a ThingWorx engineer, import this file into your Composer. Download the attached example solution:   FoundationChallengeSolution.xml Import the xml file into, then open MyHouseAndGarage Thing. See below for some options to consider in your application development.   Modeling   There are several ways the garage door property could be added to your existing model. The table below discusses different implementations we considered. We chose to model the status of the garage door as a Property of a new Thing created using the building Template. Modeling Method Pros Cons Add Property to BuildingTemplate The Garage property will be added to existing house Thing All future Things using Building Template will have a garage door property Add Property to existing house Thing House and garage are linked No separate temperature and watts Property for garage Add Property to new Thing created with BuildingTemplate All Building features available No logical link between house and garage   Property Base Type   We chose to represent the status of the door with a simple Boolean Property named 'garageDoorOpen' Thoughtful property naming ensures that the values, true and false, have a clear meaning. Using a Boolean type also makes it easy to bind the value directly to a Widget. The table below explains a few Base Type options. Modeling Method Pros Cons Boolean Easy to bind to Widget Information between open and closed is lost Number Precise door status Direction information is lost String Any number of states can be represented An unexpected String could break UI   Visualization   We chose a simple Check-box Widget to show the garage door status, but there are many other Widgets you could choose depending on how you want to display the data. For example, a more professional implementation might display a custom image for each state.   Logging   We recommended that you check the Logged option, so you can record the history of the garage door status.   Step 14: Next Steps   Congratulations! You've successfully completed the Get Started with ThingWorx for IoT tutorial, and learned how to: Use Composer to create a Thing based on Thing Shapes and Thing Templates Store Property change history in a Value Stream Define application logic using custom defined Services and Subscriptions Create an applicaton UI with Mashup Builder Display data from connected devices Test a sample application The next guide in the Getting Started on the ThingWorx Platform learning path is Data Model Introduction.

Get Started with ThingWorx for IoT Guide Part 4   Step 10: Display Data   Now that you have configured the visual part of your application, you need to bind the Widgets in your Mashup to a data source, and enable your application to display data from your connected devices.   Add Services to Mashup   Click the Data tab in the top-right section of the Mashup Builder. Click on the green + symbol in the Data tab.   Type MyHouse in the Entity textbox. Click MyHouse. In the Filter textbox below Services, type GetPropertyValues. Click the arrow to the right of the GetPropertyValues service to add it.   Select the checkbox under Execute on Load. NOTE: If you check the Execute on Load option, the service will execute when the Mashup starts. 8. In the Filter textbox under Services, type QueryProperty. 9. Add the QueryPropertyHistory service by clicking the arrow to the right of the service name. 10. Click the checkbox under Execute on Load. 11. Click Done. 12. Click Save.   Bind Data to Widgets   We will now connect the Services we added to the Widgets in the Mashup that will display their data.   Gauge   Configure the Gauge to display the current power value. Expand the GetPropertyValues Service as well as the Returned Data and All Data sections. Drag and drop the watts property onto the Gauge Widget.   When the Select Binding Target dialogue box appears, select # Data.   Map   Configure Google Maps to display the location of the home. Expand the GetPropertyValues service as well as the Returned Data section. Drag and drop All Data onto the map widget.   When the Select Binding Target dialogue box appears, select Data. Click on the Google Map Widget on the canvas to display properties that can configured in the lower left panel. Set the LocationField property in the lower left panel by selecting building_lat_lng from the drop-down menu.   Chart   Configure the Chart to display property values changing over time. Expand the QueryPropertyHistory Service as well as the Returned Data section. Drag and drop All Data onto the Line Chart Widget. When the Select Binding Target dialogue box appears, select Data. In the Property panel in the lower left, select All from the Category drop-down. Enter series in Filter Properties text box then enter 1 in NumberOfSeries . Enter field in Filter Properties text box then click XAxisField. Select the timestamp property value from the XAxisField drop-down. Select temperature from the DataField1 drop-down.   Verify Data Bindings   You can see the configuration of data sources bound to widgets displayed in the Connections pane. Click on GetPropertyValues in the data source panel then check the diagram on the bottom of the screen to confirm a data source is bound to the Gauge and Map widget.   Click on the QueryPropertyHistory data source and confirm that the diagram shows the Chart is bound to it. Click Save.   Step 11: Simulate a Data Source   At this point, you have created a Value Stream to store changing property value data and applied it to the BuildingTemplate. This guide does not include connecting edge devices and another guide covers choosing a connectivity method. We will import a pre-made Thing that creates simulated data to represent types of information from a connected home. The imported Thing uses Javascript code saved in a Subscription that updates the power and temperature properties of the MyHouse Thing every time it is triggered by its timer Event.    Import Data Simulation Entities   Download the attached sample:  Things_House_data_simulator.xml. In Composer, click the Import/Export icon at the lower-left of the page. Click Import. Leave all default values and click Browse to select the Things_House_data_simulator.xml file that you just downloaded. Click Open, then Import, and once you see the success message, click Close.   Explore Imported Entities   Navigate to the House_data_simulator Thing by using the search bar at the top of the screen. Click the Subscriptions tab. Click Event.Timer under Name. Select the Subscription Info tab. NOTE: Every 30 seconds, the timer event will trigger this subscription and the Javascript code in the Script panel will run. The running script updates the temperature and watts properties of the MyHouse Thing using logic based on both the temperature property from MyHouse and the isACrunning property of the simulator itself. 5. Expand the Subscription Info menu. The simulator will send data when the Enabled checkbox is checked. 6. Click Done then Save to save any changes.   Verify Data Simulation   Open the MyHouse Thing and click Properties an Alerts tab Click the Refresh button above where the current property values are shown   Notice that the temperature property value changes every 30 seconds when the triggered service runs. The watts property value is 100 when the temperature exceeds 72 to simulate an air conditioner turning on.   Step 12: Test Application   Browse to your Mashup and click View Mashup to launch the application.   NOTE: You may need to enable pop-ups in your browser to see the Mashup.       2. Confirm that data is being displayed in each of the sections.        Test Alert   Open MyHouse Thing Click the Properties and Subscriptions Tab. Find the temperature Property and click on pencil icon in the Value column. Enter the temperature property of 29 in the upper right panel. Click Check mark icon to save value. This will trigger the freezeWarning alert.   Click Refresh to see the value of the message property automatically set.   7. Click the the Monitoring icon on the left, then click ScriptLog to see your message written to the script log.   Click here to view Part 5 of this guide. 

Get Started with ThingWorx for IoT Guide Part 3   Step 7: Create Alerts and Subscriptions   An Event is a custom-defined message published by a Thing, usually when the value of a Property changes. A Subscription listens for a specific Event, then executes Javascript code. In this step, you will create an Alert which is quick way to define both an Event and the logic for when the Event is published.   Create Alert   Create an Alert that will be sent when the temperature property falls below 32 degrees. Click Thing Shapes under the Modeling tab in Composer, then open the ThermostatShape Thing Shape from the list.   Click Properties and Alerts tab.   Click the temperature property. Click the green Edit button if not already in edit mode, then click the + in the Alerts column.   Choose Below from the Alert Type drop down list. Type freezeWarning in the Name field.   Enter 32 in the Limit field. Keep all other default settings in place. NOTE: This will cause the Alert to be sent when the temperature property is at or below 32.        8. Click ✓ button above the new alert panel.       9. Click Save.     Create Subscription   Create a Subscription to this event that uses Javascript to record an entry in the error log and update a status message. Open the MyHouse Thing, then click Subscriptions tab.   Click Edit if not already in edit mode, then click + Add.   Type freezeWarningSubscription in the Name field. After clicking the Inputs tab, click the the Event drop down list, then choose Alert. In the Property field drop down, choose temperature.   Click the Subscription Info tab, then check the Enabled checkbox   Create Subscription Code   Follow the steps below to create code that sets the message property value and writes a Warning message to the ThingWorx log. Enter the following JavaScript in the Script text box to the right to set the message property.                       me.message = "Warning: Below Freezing";                       2. Click the Snippets tab. NOTE: Snippets provide many built-in code samples and functions you can use. 3. Click inside the Script text box and hit the Enter key to place the cursor on a new line. 4. Type warn into the snippets filter text box or scroll down to locate the warn Snippet. 5. Click All, then click the arrow next to warn, and Javascript code will be added to the script window. 6. Add an error message in between the quotation marks.                       logger.warn("The freezeWarning subscription was triggered");                       7. Click Done. 8. Click Save.   Step 8: Create Application UI ThingWorx you can create customized web applications that display and interact with data from multiple sources. These web applications are called Mashups and are created using the Mashup Builder. The Mashup Builder is where you create your web application by dragging and dropping Widgets such as grids, charts, maps, buttons onto a canvas. All of the user interface elements in your application are Widgets. We will build a web application with three Widgets: a map showing your house's location on an interactive map, a gauge displaying the current value of the watts property, and a graph showing the temperature property value trend over time. Build Mashup Start on the Browse, folder icon tab of ThingWorx Composer. Select Mashups in the left-hand navigation, then click + New to create a new Mashup.   For Mashup Type select Responsive.   Click OK. Enter widgetMashup in the Name text field, If Project is not already set, click the + in the Project text box and select the PTCDefaultProject, Click Save. Select the Design tab to display Mashup Builder.   Organize UI On the upper left side of the design workspace, in the Widget panel, be sure the Layout tab is selected, then click Add Bottom to split your UI into two halves.   Click in the bottom half to be sure it is selected before clicking Add Left Click anywhere inside the lower left container, then scroll down in the Layout panel to select Fixed Size Enter 200 in the Width text box that appears, then press Tab key of your computer to record your entry.   Click Save   Step 9: Add Widgets Click the Widgets tab on the top left of the Widget panel, then scroll down until you see the Gauge Widget Drag the Gauge widget onto the lower left area of the canvas on the right. This Widget will show the simulated watts in use.   Select the Gauge object on the canvas, and the bottom left side of the screen will show the Widget properties. Select Bindable from the Catagory dropdown and enter Watts for the Legend property value, and then press tab..   Click and drag the Google Map Widget onto the top area of the canvas. NOTE: The Google Map Widget has been provisioned on PTC CLoud hosted trial servers. If it is not available, download and install the Google Map Extension using the step-by-step guide for using Google Maps with ThingWorx . Click and drag the Line Chart Widget onto the lower right area of the canvas. Click Save

  Create Your Application Guide UI Part 4    Step 6: Apply Services   You now have an idea of what your Mashup will look like, but without Data Services, it won't accomplish anything productive. In the following steps you'll apply Mashup Data Services to the Widgets.   Add Data Services   Click the + button in the top-right in the Data tab.   In the Entity Filter field, search for and select MBQSThing. In the Select Services field, search for and select GetPropertyValues. Check the Execute on Load checkbox for GetPropertyValues. In the Services Filter field, search for and select SetProperties. In this case, you WILL NOT check the box for Mashup Loaded? because we do not want to call this Service upon initial Mashup load. 6. Click Done. Both the GetPropertyValues and SetProperties Services now appears under the Data tab as well. 7. Click Save.   GetPropertyValues   GetPropertyValues has brought all the values of our Thing's Properties into the Mashup. Now let's tie these values to the Widgets. Expand All Data under the GetPropertyValues Service on the right under the Data tab.   Drag-and-drop Gears_Count onto the textfield-gears-count Widget.   On the Select Binding Target pop-up, click Text.   Repeat Steps 2 and 3, binding Pistons_Count to textfield-pistons-count and Wheels_Count to textfield-wheels-count. Drag-and-drop Gears_Count_Manually_Set onto the checkbox-gears-manual Widget.   On the Select Binding Target pop-up, click State.   Repeat Steps 5 and 6, binding Pistons_Count_Manually_Set to checkbox-pistons-manual and Wheels_Count_Manually_Set to checkbox-wheels-manual. Click Save.   SetProperties   We want to tie the Widgets to the SetProperties Service to manually set the inventory counts in case something has gone wrong with our IoT sensors in the warehouse. On the right under the Data tab, minimize the GetPropertyValues Service and expand the SetProperties Service.        2. Click the textfield-gears-count Widget to select it. 3. Click the top-left drop-down of the TextBox to expand the options. 4. Drag-and-drop Text onto SetProperties > Gears_Count. 5. Repeat Steps 2 through 4, binding Text from textfield-pistons-count onto Pistons_Count and textfield-wheels-count onto Wheels_Count. 6. Click the checkbox-gears-manual Widget to select it. 7. Click the top-left drop-down of the Checkbox to expand the options. 8. Drag-and-drop State onto Gears_Count_Manually_Set. 9. Repeat Steps 6 through 8, binding State from both checkbox-pistons-manual to Pistons_Count_Manually_Set and checkbox-wheels-manual to Wheels_Count_Manually_Set. 10. Click the button-manual-set Widget to select it. 11. Click the top-left drop-down of the Button to expand the options. 12. Drag-and-drop the Clicked Event onto SetProperties under the Data tab. NOTE: The previous steps in this section where we bound Widgets to Properties simply defined what-goes-where in terms of storing the values into the ThingWorx Foundation backend.To actually push those values, the SetProperties Service itself must be called. 13. With the SetProperties Service selected, drag-and-drop SetProperties' ServiceInvokeCompleted Event (in the bottom-right Data Properties section) onto the GetPropertyValues Service (in the top-right Data tab). If you don't see ServiceInvokeCompleted, ensure that you have the Data Properties tab selected. This will cause the GUI to update once the new values have been saved to the platform’s backend. 14. Click Save.   Manual Data Retrieval   We want to tie a Button to GetPropertyValues to update the GUI with the backend's ever-changing inventory counts without requiring a page reload. Click button-manual-retrieve to select it. Click the top-left drop-down of this Button Widget to expand the options. Drag-and-drop the Clicked Event onto the GetPropertyValues Service. This will create another way to update the part counts in the GUI, other than reloading the page. 4. Click Save.   Click here to view Part 5 of this guide. 

  Create Your Application Guide UI Part 3    Step 5: Add Widgets to Mashup    At this point, you should have an understanding of how the Widgets in your Mashup relate to the data from devices you've connected via the ThingWorx platform.   Scenario   Now, let's try to imagine a real-world scenario. For this example, assume that you are in a company developing an IoT application utilizing ThingWorx Foundation.   Developer Role Responsibility Edge Developers Utilize the Edge MicroServer, Software Development Kits, or ThingWorx Kepware Server to connect devices and bring data into the platform. Backend Developers Created Things, Thing Templates, and Thing Shapes to store and manipulate the data within ThingWorx Foundation. Frontend Developer Tasked with taking the IoT data and creating an interface with which your users can interact to gain insight from the data. In this scenario, you are the Frontend Developer. The Thing you imported previously represents those Edge and Backend Developers’ work. The data is all there. Specifically, let's assume that this Data Model represents a factory inventory system. You want to quickly build a GUI that is a Minimum Viable Product (MVP) to display the current counts of various products in your warehouse, while also allowing you to manually edit those counts if you receive a report that an IoT scanner in the warehouse has malfunctioned. Since this is a real factory, inventory is constantly increasing and decreasing as manufactured parts are completed or shipping orders are fulfilled. In this lesson, we'll simulate these changes by a 10-second-timer which will increment the counts until a shipping order has been fulfilled (100 total parts), at which point the current inventory count for that part will be reset.   Create the Mashup   Follow the subsequent steps to create an MVP GUI for the example scenario: Click Browse > VISUALIZATION > Mashups > + New. Keep the default of Responsive (with NO Responsive Templates chosen), and click OK in the pop-up window. In the Name field, enter MBQSMashup.   If the Project field is not already set, search for and select PTCDefaultProject.  At the top, click Save. At the top, click Design. On the left, click the Left Arrow to slide-back the navigation pane, leaving more room for the Mashup Builder. At the topleft on the Layout tab, for Positioning, check the radio-button for Static.   Add Labels   Follow the subsequent steps to add Labels that clarify GUI sections of the application. Select the Widgets tab, then drag-and-drop three Label Widgets onto the central Canvas.   With the top Label Widget selected (by clicking on it), change the DisplayName to label-gears-count and hit the Tab key on your keyboard to lock in the modification. NOTE: You can find the DisplayName and all other Widget Properties in the bottom-left of the Mashup Builder. Changing the Widget DisplayNames to recognizable values is highly recommended, as it assists with your logic inspection in the bottom-center Connections window.        3. With the newly-named label-gears-count still selected, type Gears Count in the LabelText field and hit the Tab key.       4. Click on the middle Label; then, in the bottom-left Widget Properties panel, change the DisplayName to label-pistons-count and LabelText to Pistons Count.       5. Similarly, change the bottom Label's DisplayName to label-wheels-count and LabelText to Wheels Count.       6. Click Save.   Add TextBoxes   Follow the subsequent steps to display some information on the various part-counts in our inventory. Drag-and-drop three Text Field Widgets onto the central Canvas.   With the top Text Field Widget selected, change the DisplayName to textfield-gears-count and hit the Tab key.   Change the middle Text Field's DisplayName to textfield-pistons-count, and hit the Tab key. Change the bottom Text Field's DisplayName to textfield-wheels-count, and hit the Tab key. Click Save.   Add Checkboxes   We want to display that inventory counts have been manually set when something went wrong, rather than have someone assume that the information is current and coming from an IoT sensor. This also allows us to flag any sensors that are experiencing issues. Follow the subsequent steps to create checkboxes. Drag-and-drop three Checkbox Widgets onto the central Canvas.   With the top Checkbox Widget selected, change the DisplayName to checkbox-gears-manual and the Label property to Gears Manually Set. Change the middle Checkbox's DisplayName to checkbox-pistons-manual and Label to Pistons Manually Set. Change the bottom Checkbox's DisplayName to checkbox-wheels-manual and Label to Wheels Manually Set.   Click Save.   Add Buttons   After our manual count has been entered, we need to trigger storing it in the backend. We can do this with a Button Widget. In addition, it would be helpful to be able to update the changing counts in the Textboxes without having to reload the entire Mashup. Follow the subsequent steps to add Buttons. Drag-and-drop two Button Widgets onto the central Canvas.   With the top Button Widget selected, change the DisplayName to button-manual-set, the Label to Manually Set Counts, and click-and-drag the right-side of the Button to expand its size.   With the bottom Button Widget selected, change the DisplayName to button-manual-retrieve, the Label to Manually Retrieve Counts, and click-and-drag the right-side of the Button to expand its size.   Click Save.   Resize the Mashup   Follow the subsequent steps to enable the Mashup to fit on a smartphone screen. Click-and-drag your Widgets around the Mashup such that they look roughly like the pictures shown above. Click-and-drag the right-side of the Mashup, pulling it to the left to reduce the horizontal size. Click-and-drag the bottom of the Mashup, pulling it up to reduce the vertical size.   Click Save.         Click here to view Part 4 of this guide.   

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

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

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

Data Model Implementation Guide Part 3   Step 7: Unique Components Thing Templates   All of the shared component groups have been created. The next stage is creating the unique component group of ThingTemplates. Each of the below sections will cover one ThingTemplate, how the final property configuration should look, and any other aspects that should be added. The breakdown for the unique component group ThingTemplates is as follows:   Robotic Arm Properties   The properties for the RoboticArm ThingTemplate are as follows: Name Base Type Aspects Data Change Type TimeSincePickup NUMBER, Min Value: 0 Persistent and Logged ALWAYS Axis1 String Persistent and Logged VALUE Axis2 String Persistent and Logged VALUE Axis3 String Persistent and Logged VALUE ClampPressure NUMBER, Min Value: 0 Persistent and Logged ALWAYS ClampStatus String Persistent and Logged ALWAYS   Your properties should match the below configurations.   Pneumatic Gate Properties   The properties for the PneumaticGate ThingTemplate are as follows: Name Base Type Aspects Data Change Type GateStatus String Persistent and Logged ALWAYS   Your properties should match the below configurations.   Conveyor Belt Properties   The properties for the ConveyorBelt ThingTemplate are as follows: Name Base Type Aspects Data Change Type BeltSpeed INTEGER, Min Value: 0 Persistent and Logged ALWAYS BeltTemp INTEGER, Min Value: 0 Persistent and Logged ALWAYS BeltRPM INTEGER, Min Value: 0 Persistent and Logged ALWAYS   Your properties should match the below configurations.   Quality Control Camera   Properties   The properties for the QualityControlCamera ThingTemplate are as follows: Name Base Type Aspects Data Change Type QualityReading INTEGER, Min Value: 0 Persistent and Logged ALWAYS QualitySettings String Persistent and Logged ALWAYS CurrentImage IMAGE Persistent and Logged ALWAYS   Your properties should match the below configurations.   Event   Create a new Event named BadQuality. Select AlertStatus as the Data Shape. Your Event should match the below configurations:     Step 8: Data Tables and Data Shapes   For the Data Model we created, an individual DataTable would be best utilized for each products, production orders, and maintenance requests. Utilizing DataTables will allow us to store and track all of these items within our application. In order to have DataTables, we will need DataShapes to create the schema that each DataTable will follow. This database creation aspect can be considered a part of the Data Model design or a part of the Database Design. Nevertheless, the question of whether to create DataTables is based on the question of needed real time information or needed static information. Products, production orders, and maintenance requests can be considered static data. Tracking the location of a moving truck can be considered a need for real time data. This scenario calls for using DataTables, but a real time application will often have places where Streams and ValueStreams are utilized (DataShapes will also be needed for Streams and ValueStreams). NOTE: The DataShapes (schemas) shown below are for a simplified example. There are different ways you can create your database setup based on your own needs and wants. DataTable Name DataShape Purpose MaintenanceRequestDataTable MaintenanceRequest Store information about all maintenanced requests created ProductDataTable ProductDataShape Store information about the product line ProductionOrderDataTable ProductionOrderDataShape Store all information about production orders that have been placed   Maintenance Requests DataShape   The maintenance requests DataShape needs to be trackable (unique) and contain helpful information to complete the request. The DataShape fields are as follows: Name Base Type Additional Info Primary Key ID String NONE YES Title String NONE NO Request String NONE NO CompletionDate DATETIME NONE NO   Unless you’ve decided to change things around, your DataShape fields should match the below configurations.   Products DataShape   The product DataShape needs to be trackable (unique) and contain information about the product. The DataShape fields are as follows: Name Base Type Additional Info Primary Key ProductId String NONE YES Product String NONE NO Description String NONE NO Cost NUMBER Minimum: 0 NO   Unless you’ve decided to change things around, your DataShape fields should match the below configurations.   Production Order DataShape   The production order DataShape needs to be trackable (unique), contain information that would allow the operator and manager to know where it is in production, and information to help make decisions. The DataShape fields are as follows: Name Base Type Additional Info Primary Key OrderId String NONE YES Product InfoTable: DataShape: ProductDataShape NONE NO ProductionStage String NONE NO OrderDate DATETIME NONE NO DueDate DATETIME NONE NO   Unless you’ve decided to change things around, your DataShape fields should match the below configurations.     Step 9: SystemConnections Implementation   We have created the ThingTemplates and ThingShapes that will be utilized within our Data Model for creating instances (Things). Before we finish the build out of our Data Model, let's create the Services that will be necessary for the MaintenanceSystem and ProductionOrderSystem Things.    This guide will not cover the JavaScript and business logic aspect of creating an application. When complete with the below sections, see the Summary page for how to create that level of definition.       Maintenance System   This is the system managed by the maintenance user and geared towards their needs.   Properties   The properties for the MaintenanceSystem Thing are as follows:     Name Base Type Aspects Data Change Type  MaintEngineerCredentials  PASSWORD  Persistent  VALUE    Your properties should match the below configurations.         Services    The Services for the MaintenanceSystem Thing are as follows:    Service Name  Parameters  Output Base Type Purpose   GetAllMaintenanceRequests  NONE  InfoTable: MaintenanceRequest  Get all of the maintenance requests filed for the maintenance user.  GetFilteredMaintenanceRequests  String: TitleFilter  InfoTable: MaintenanceRequest  Get a filtered version of all maintenance requests filed for the maintenance user.  UpdateMaintenanceRequests  String: RequestTitle  NOTHING  Update a maintenance request already in the system.    Use the same method for creating Services that were provided in earlier sections. Your Services list should match the below configurations.     Production Order System   This is the system utilized by the operator and product manager users and geared towards their needs.   Services   The Services for the ProductionOrderSystem Thing are as follows:      Service Name  Parameters Output Base Type   AssignProductionOrders String: Operator, String: ProductOrder  NOTHING   CreateProductionOrders  String: OrderNumber, String: Product, DATETIME: DueDate  NOTHING  DeleteProductionOrders  String: ProductOrder  NOTHING  GetFilteredProductionOrders  String: ProductOrder  InfoTable: ProductionOrder  GetProductionLineList  NONE  InfoTable: ProductDataShape  GetUnfilteredProductionOrders  NONE  InfoTable: ProductionOrder  MarkSelfOperator  NONE  BOOLEAN  UpdateProductionOrdersOP  String: ProductOrder, String: UpdatedInformation  NOTHING  UpdateProductionOrdersPM  String: ProductOrder, String: UpdatedInformation  NOTHING   Use the same method for creating Services that were provided in earlier sections. Your Services list should match the below configurations.       Challenge Yourself     Complete the implementation of the Data Model shown below by creating the Thing instances of the ThingTemplates we have created. When finish, add more to the Data Model. Some ideas are below.         Ideas for what can be added to this Data Model: #  Idea  1 Add users and permissions   2  Add Mashups to view maintenance requests, products, and production orders  3  Add business logic to the Data Model   Step 10: Next Steps     Congratulations! You've successfully completed the Data Model Implementation Guide. This guide has given you the basic tools to: Create Things, Thing Templates, and Thing Shapes Add Events and Subscriptions   The next guide in the Design and Implement Data Models to Enable Predictive Analytics learning path is Create Custom Business Logic.  

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

Build a Predictive Analytics Model Guide Part 2   Step 5: Profiles   The Profiles section of ThingWorx Analytics looks for combinations of data which are highly correlated with your desired goal. On the left, click ANALYTICS BUILDER > Profiles. Click New....The New Profile pop-up will open. NOTE: Notice the Text Data Only section which is new in ThingWorx 9.3.         3. In the Profile Name field, enter vibration_profile. 4. In the Dataset field, select vibration_dataset. 5. Leave the Goal field set to the default of low_grease. 6. Leave the Filter field set to the default of all_data. 7. Leave the Excluded Fields from Profile field set to the default of empty. 8. Click Submit. 9. After ~30 seconds, the Signal State will change to COMPLETED. The results will be displayed at the bottom.                 The results show several Profiles (combinations of data) that appear to be statistically significant. Only the first few Profiles, however, have a significant percentage of the total number of records. The later Profiles can largely be ignored. Of those first Profiles, both Frequency Bands from Sensor 1 and Sensor 2 appear. But in combination with the result from Signals (where Sensor 1 was always more important), this could possibly indicate that Sensor 1 is still the most important overall. In other words, since Sensor 1 is statistically significant both by itself and in combination (but Sensor 2 is only significant in combation with Sensor 1), then Sensor 2 may not be necessary.     Step 6: Create Model   Models are primarily used by Analytics Manager (which is beyond the scope of this guide), but they can still be used to measure the accuracy of predictions. When Models are calculated, they inherently withhold a certain amount of data. The prediction model is then run against the withheld data. This provides a form of "accuracy measure", which we'll use to determine whether Sensor 2 is necessary to the detection of a low grease condition by creating two different Models. The first Model (which you will create below) will contain all the data, while the second Model (in the next step) will exclude Sensor 2. On the left, click ANALYTICS BUILDER > Models.   Click New….The New Predictive Model pop-up will open.   3. In the Model Name field, enter vibration_model. 4. In the Dataset field, select vibration_dataset. 5. Leave the Goal field set to the default of low_grease. 6. Leave the Filter field set to the default of all_data.         7. Leave the Excluded Fields from Model section at its default of empty.       8. Click Submit. 9. After ~60 seconds, the Model Status will change to COMPLETED.   View Model   Now that the prediction model is COMPLETED, you can view the results. Select the model that was created in the previous step, i.e. vibration_model. Click View… to open the Model Information page.   Review the visualization of the validation results. Note that your results may differ slightly from the picture, as the automatically-withheld "test" portion of the dataset is randomly chosen. Click on the ? icon to the right of the chart for details on the information displayed.   The desired outcome is for the model to have a relatively high level of accuracy. The True Positive Rate shown on the Receiver Operating Characteristic (ROC) chart are much higher than the False Positives. The curve is relatively high and to the left, which indicates a high accuracy level. You may also click on the Confusion Matrix tab in the top-left, which will show you the number of True Positive and True Negatives in comparison to False Positives and False Negatives.     Note that the number of correct predictions is much higher than the number of incorrect predictions.     As such, we now know that our Sensors have a relatively good chance at predicting an impending failure by detecting low grease conditions before they cause catastrophic engine failure.     Step 7: Refine Model   We will now try comparing this first Model that includes both Sensors to a simpler Model using only Sensor 1. We do this because we suspect that Sensor 2 may not be necessary to achieve our goal. On the left, click ANALYTICS BUILDER > Models.   Click New…. In the Model Name field, enter vibration_model_s1_only. In the Dataset field, select vibration_dataset. Leave the Goal field set to the default of low_grease. Leave the Filter field set to the default of all_data.   On the right beside Excluded Fields from Model, click the Excluded Fields button. The Fields To Be Excluded From Job pop-up will open. 8. Click s2_fb1 to select the first Sensor 2 Frequency Band. 9. Select the rest of the Frequency Bands through s2_fb5 to choose all of the Sensor 2 frequencies. 10. While all the s2 values are selected, click the green "right arrow", i.e. the > button in the middle. 11. At the bottom-left, click Save. The Fields To Be Excluded From Job pop-up will close.           12. Click Submit. 13. After ~60 seconds, the Model State will change to COMPLETED. 14. With vibration_model_s1_only selected, click View....   The ROC chart is comparable to the original model (including Sensor 2). Likewise, the Confusion Matrix (on the other tab) indicates a good ratio of correct predictions versus incorrect predictions.     NOTE: These Models may vary slightly from your own final scores, as what data is used for the prediction versus for evaluation is random. ThingWorx Analytics's Models have indicated that you are likely to receive roughly the same accuracy of predicting a low-grease condition whether you use one sensor or two! If we can get an accurate early-warning of the low grease condition with just one sensor, it then becomes a business decision as to whether the extra cost of Sensor 2 is necessary.   Step 8: Next Steps   Congratulations! You've successfully completed the Build a Predictive Analytics Model guide, and learned how to:   Load an IoT dataset Generate machine learning predictions Evaluate the analytics output to gain insight    This is the last guide in the Getting Started on the ThingWorx Platform learning path.   This is the last guide in the Monitor Factory Supplies and Consumables learning path.   The next guide in the Design and Implement Data Models to Enable Predictive Analytics learning path is Operationalize an Analytics Model.     Additional Resources   If you have questions, issues, or need additional information, refer to:   Resource Link Support Analytics Builder Help Center    

Create Your Application Guide UI Part 2    Step 4: Bind Data to Widgets   Mashup Data Services allow you to access IoT data so you can push data to the platform's backend as well as pull data into the Mashup itself. In the table below, we describe some common Mashup Data Services that enable that functionality: Service Name Description GetProperties Pulls in a particular Thing's Properties, as well as the associated current values contained within those Properties. GetProperties has an option to automatically update the Mashup whenever a Property value changes. GetPropertyValues Pulls in a particular Thing's Properties and their associated current values. However, it does so in an All Data grouping, opening the possibility of assigning all Properties to the same Widget. This can be helpful with some Widgets, such as the List Widget. SetProperties Pushes a value from some Widget (Checkbox, TextBox, etc.) into the Property of a Thing. NOTE: Using a combination of a "Get" and "Set" Mashup Service establishes a bidirectional communication between the Mashup and the backend IoT data storage.   Import an Entity   In order to focus on the Mashup Builder in this lesson, we have created a Thing for you to download and import. This Thing has predefined Properties and associated Values which will simplify the demonstration of binding data to Widgets in subsequent steps. Download and unzip the attached MBQS_Entities.zip file. In the bottom-left, click the "up/down arrows" for Import/Export, then Import.   In the Import pop-up window, click Browse.   In the OS's pop-up, navigate-to, select, and open the MBQS_Entities.twx file you downloaded earlier.   Click Import.   Click Close.   Retrieve Data   You now have a Thing called MBQSThing from which you can retrieve data. To demonstrate this, we'll use the GetPropertyValues Service. At the top-right of Mashup Builder, click the Data tab.   Click the + symbol.   In the Add Data pop-up window's Entity filter field, type mbqs.   Select the MBQSThing.   In the Services Filter field, type getprop.   Click the right arrow to select GetPropertyValues. The GetPropertyValues Service for MBQSThing has now been added to the Selected Services section on the right side of the Add Data pop-up window. Check the box for Execute on Load under Selected Services. Checking this box causes the GetPropertyValues Service to execute as soon as the Mashup is loaded. 8. Click Done.        9. At the top, click Save. Note how the GetPropertyValues Service now appears in the top-right under the Data tab.   View Data Connections   In the top-left of the Mashup Builder, click the Explorer tab, select the Mashup itself, and you can see the connections between the Mashup and the Data sources.   Mashup Builder Section Description Data Previously empty, now has a reference to the GetPropertyValues Service of the MBQSThing. GetPropertyValues On the Data tab, click GetPropertyValues. The Connections window in the bottom-center will update. Bindings Shows the logical flow of the Mashup. In this instance, it shows how GetPropertyValues is called from the Event triggered by the Mashup being Loaded in a web browser. This means that all Properties of the MBQSThing will be available to the Mashup as soon as your UI is opened.   Bind Widget to Property   Follow the steps below to place a Widget in the Mashup and bind the Property named Gauge_Value (of MBQSThing) to it. On the left-side of the Mashup Builder, select the Widgets tab. In the Filter Widgets search box, type gauge. Drag-and-drop a Gauge Widget onto the central Canvas area.   On the right-side, expand GetPropertyValues > Returned Data > All Data. There is a clear left arrow pointing away from the Gauge_Value Property. This indicates that this Property is to be used to set the value on something else. If the arrow had been pointing towards the Gauge_Value Property, that would indicate that it was ready to accept an external value. The clear status of the arrow indicates that it has not yet been tied to anything.        5. Drag-and-drop MBQSThing > GetPropertyValues > Returned Data > All Data > Gauge_Value onto the Gauge Widget in the central Canvas area.          6. On the Select Binding Target pop-up, select Data.       7. At the top, click Save.       8. Click View Mashup. You must enable pop-ups in order to view the Mashup in a new tab.   In your new Mashup, notice that the Gauge has been set to the Gauge_Value default value of 25. In a real-world scenario, you would likely utilize an IoT sensor that would report back to the Thing storing the value. When the Mashup loads, that value would be set to the real-world sensor data value. In the next few steps, you will build a GUI using several different Widgets and Services.   Click here to view Part 3 of this guide.  

Configure Permissions Guide Part 1   Overview   This project will introduce you to permissions inside of the ThingWorx platform. Permissions are used to control usage during development, runtime, and experience. Following the steps in this guide, you will be able to create Users, User Groups, Application Keys, and Organizations and tie them together. We will teach you how to create functional permission schemes in the ThingWorx platform to create a secure application and development environment.   NOTE: This guide's content aligns with ThingWorx 9.3. The estimated time to complete ALL 2 parts of this guide is 30 minutes.    Step 1: Completed Example   Download and unzip the completed files attached to this tutorial: PermissionsEntities.zip.   In this tutorial, we walk through security concepts within ThingWorx. Utilize this file to see a finished example and return to it as a reference if you become stuck creating your own fully flushed out application.   Keep in mind, this download uses the exact names for entities used in this tutorial. If you would like to import this example and also create entities on your own, change the names of the entities you create.   Step 2: Common Terms   It is important to understand the terminology before creating Users, Groups, and Permissions: Term Definition Entity Generic name for any of the customizable building blocks inside the ThingWorx Platform User An Entity dedicated to identifying a person or device accessing the platform User Group An Entity that defines role-based permissions for Users in bulk Tags and Projects Mechanisms used to group Entities together by marking them as similar or related Composer The ThingWorx GUI tool for building your solution Resource A collection of Services which are not stateful (i.e. they do not have Properties, Events, etc.); they can be found in Composer under the System category Organization Hierarchical structures that allow you to assign visibility to Entities in the ThingWorx Model     Step 3: Users   Users represent an individual person or connected system. They contain information such as a username, email, and password (Standard Credentials) as well as peripheral information such as Name of the actual person/system/device it was created for. Users can be created, updated, and deleted just like every other Entity.   Create User   In the ThingWorx Composer, click the + New at the top of the screen. Select User in the dropdown. Name the User default_user and add a password. Set the Project field (ie, PTCDefaultProject) and click Save. User-Related Services   There are a few Services available through a resource called EntityServices, that allow you to interact with user entities programmatically.   Once a user has been created, you can interact with it through some built-in Services:     Default Users   There are two key users built into every instance of ThingWorx when initially created.   Administrator: When setting up your platform, you'll use the Administrator user first, because it is the user that will allow you to set up new users and assign them to Administrator or other roles.   NOTE: It is extremely important to reset the Administrator password after your first login. Leaving the default password could allow the system to be compromised in the future.   System User: The System User is created to allow service chaining on a given Thing when a user may not have direct permissions for every part of the chain. It exists so that access to given Services can be granted based on some previous logic instead of direct overarching permissions. For example: if the user is within the building, then trigger a Service, otherwise do not trigger the Service.     Step 4: User Groups   In many IoT solutions there will be a large scale of Users using the system. Because of this it doesn’t make sense to manually set the permissions of every User added to the system. This is why we created User Groups. User Groups provide a role-based approach to permissions and exist to give similar Users the same permissions across multiple Entities on the platform. User groups set permissions exactly the same way as Users do (see next section), but you can simply add a User to a User Group in order to set permissions at scale. For example: Creating a User group such as "Solution Architects" would allow you to do something like set all permissions for design time but limit permissions for run time. Similarly you could create a user group called "Solution Users" who have no design time permissions and specific run time permissions.   Create Group and Add Users   In the ThingWorx Composer, click the + New at the top of the screen. Select User Group in the dropdown. Name your group ExampleGroup. Set the Project field (ie, PTCDefaultProject) and click Save. Click Members to view current members in the group. Filter and select the user you want to add in the Available Members section. Click the arrow on their row or drag the User to the Members section. Click Save. NOTE: Individual user permissions will override group user permissions. In other words, if you initially add a user to a group so they inherit the permissions of the group, you will still be able to customize permissions for an individual user in that group as needed.   User Group Services   There are a few Services available through a resource called EntityServices, that allow you to interact with user group entities programmatically. Service Name Description CreateGroup Creates a new User Group DeleteGroup Deletes a user Group   Once a group has been created you can interact with it through built-in services to add or remove a User. Service Name Description AddMember Adds a User or User Group to this group AssignMembers Adds a list of Users or User Groups to this group DeleteMember Removes a User or User Group from the members of this group     Default User Groups   The platform has a few User Groups included in the platform by default. These are used to set up common roles that are often associated with using the platform and have built in permissions.   Click here to view Part 2 of this guide. 

  How to Display Data in Charts Guide Part 2   Step 4: Create Thing   In order for the Mashup to pull data into the display, you first need to create an Entity. In this example, we utilize a Thing with an Info Table Property, as well as a Time Series Property. We’ll use the DataShape we created in the last step to format the Info Table Property. Then, we'll assign the Info Table Property some default values to display in our non-time-series charts.We will change the values of the Time Series Property (which will record them to the Value Stream) for display in our time-series charts.   Info Table Property   From the Browse tab of ThingWorx Composer, click Modeling > Things, + New.   In the Name field, enter DDCThing. If Project is not set, search for and select PTCDefaultProject. In the Base Thing Template field, search for and select GenericThing. In the Value Stream field, search for and select DDCValueStream.   At the top, click Properties and Alerts.   Click + Add. In the Name field, enter InfoTableProperty. Select INFOTABLE from the Base Type drop-down. In the Data Shape field, search for and select DDCDataShape. Check the Persistent checkbox.   First Default Value   Check the box for Has Default Value. A new DDCDataShape button will appear under Has Default Value. 2. Click the new DDCDataShape button under Has Default Value. 3. Click + Add. 4. Enter the following values for each field: Field Value PrimaryKey 1 Label A - 25% Value 25 XAxis 1 Data 5 ASensor 5 BSensor 3 CSensor 1 XValue 1 YValue 5 BubbleValue 7     3. At the bottom-right of the pop-up, click the green Add button to apply the first Default Values.   Second Default Value   Click + Add. Enter the following values for each field: Field Value PrimaryKey 2 Label B - 35% Value 35 XAxis 2 Data 10 ASensor 10 BSensor 6 CSensor 2 XValue 2 YValue 10 BubbleValue 9   3. At the bottom-right of the pop-up, click the green Add button to apply the second Default Values.   Third Default Value   Click + Add. Enter the following values for each field: Field Value PrimaryKey 3 Label C - 40% Value 40 XAxis 3 Data 20 ASensor 15 BSensor 9 CSensor 3 XValue 3 YValue 20 BubbleValue 14     3. At the bottom-right of the pop-up, click the green Add button to apply the third Default Values. 4. At the bottom-right of the pop-up, click the green Save button to close the pop-up.   Time Series Property   At the top-right, click the "Check with a +" button for Done and Add. In the Name field, enter TimeSeriesProperty. Change the Base Type to NUMBER. Check the Persistent checkbox. Checking this box causes the last Value entered into the Property to persist through reboots of the system. Check the Logged box. Checking this box causes all changes to the Property to be logged if you have a Value Stream defined to record the changes. 6. At the top-right, click the "Check" button for Done.   7. At the top, click Save.   If the DDCThing's TimeSeriesProperty changes from this point onward, it will now be recorded in the DDCValueStream. Normally, any changes would come from an Edge IoT sensor of some type, but for the purposes of this guide, we will manually change the value repeatedly to simulate these types of changes.   Set 5   Under TimeSeriesProperty's Value column, click the "pencil" button for Set value of property.   In the slide-out at the top-right, enter 5.   At the top-right, click the "Check" button for Done.   Set 10   Under TimeSeriesProperty's Value column, click the "pencil" button for Set value of property. In the slide-out at the top-right, enter 10.   At the top-right, click the "Check" button for Done.   Set 15   Under TimeSeriesProperty's Value column, click the "pencil" button for Set value of property. In the slide-out at the top-right, enter 15.   At the top-right, click the "Check" button for Done. Set 20   Under TimeSeriesProperty's Value column, click the "pencil" button for Set value of property. In the slide-out at the top-right, enter 20.   At the top-right, click the "Check" button for Done. Set 25   Under TimeSeriesProperty's Value column, click the "pencil" button for Set value of property. In the slide-out at the top-right, enter 25.   At the top-right, click the "Check" button for Done. At the top, click Save.   Step 5: Create Mashup   Before we can bind the data to the various Chart Widgets, we first have to create a Mashup and add the charts to it. From the Browse tab of ThingWorx Composer, click Visualization > Mashups, + New.   Keep the default of Responsive, and click OK.   In the Name field, enter DDCMashup.   If Project is not set, search for and select PTCDefaultProject. At the top, click Save.   At the top, click Design.   Divide the Mashup   On the top-left under the Layout section, click two times on Add Left.   With the left-third selected in the central Canvas window, click Add Bottom.   With the middle-third selected in the central Canvas window, click Add Bottom. With the right-third selected in the central Canvas window, click Add Bottom.   At the top, click Save. Add the Charts   At the top-left, click on the Widgets tab.   Search for pie inside the Filter Widgets field in the top-left. Drag-and-drop a Pie Chart Widget onto the top-left section of the Canvas.   In the top-left, change Category to Legacy, and search for label chart inside the Filter Widgets field in the top-left. Drag-and-drop a Label Chart Widget onto the top-middle section of the Canvas. Note that, even the Label Chart is a Legacy Widget, it will still work. 6. Change Category back to Standard, and search for proportional inside the Filter Widgets field in the top-left. 7. Drag-and-drop a Proportional Chart Widget onto the top-right section of the Canvas. 8. Search for bubble inside the Filter Widgets field in the top-left. 9. Drag-and-drop a Bubble Chart Widget onto the bottom-left section of the Canvas. 10. Search for line inside the Filter Widgets field in the top-left. 11. Drag-and-drop a Line Chart Widget onto the bottom-middle section of the Canvas.   12. Search for event inside the Filter Widgets field in the top-left. 13. Drag-and-drop a Event Chart Widget onto the bottom-right section of the Canvas.   14. Click Save.   Click here to view Part 3 of this guide.   

How to Display Data in Charts Guide Part 1   Overview   This project will introduce various Chart Widgets. Following the steps in this guide, you will learn how to graphically represent multiple data points simultaneously. We will teach you how to utilize the Pie, Label, Proportional, Bubble, Time Series, and Event Charts. NOTE: This guide's content aligns with ThingWorx 9.3. The estimated time to complete ALL 3 parts of this guide is 60 minutes.    Step 1: Introduction   As an IoT application developer, there are times when you want to display multiple data points simultaneously. In this situation, it is often helpful to make use of one of the various Chart Widgets. This guide will discuss the following Chart Widget options: *Old widget = no web component replacement Pie – old widget Label (Legacy) Proportional – old widget Bubble – old widget Line – new web component Event – old widget Before you can display this information in your UI, you need to first configure the ThingWorx system to store those values. For the time-series charts (including both the Line and Event Charts), you need to store information in a time-series friendly manner. In this case, we’ll use a Value Stream to store Property value changes. We’ll use an Info Table (similar to a spreadsheet) to track the values for the non-time-series charts (Pie, Label, Proportional, and Bubble).   Step 2: Create Data Shape   Many data structures in ThingWorx require a Data Shape to format their values. This is true for a Stream, a Data Table, and an Info Table. We'll be using an Info Table in this example. NOTE: Any time you use an Info Table, you must first define a Data Shape. From the Browse tab of ThingWorx Composer, click Modeling > Data Shapes, + New.   In the Name field, enter DDCDataShape.   If Project is not already set, search for and select PTCDefaultProject.  At the top, click Field Definitions.   Click + Add. In the Name field, enter PrimaryKey. Change Base Type to INTEGER. Check the Is Primary Key box. The primary key is used to uniquely identify a row of data. DataShapes used for DataTable configuration must have a primary key. 9. Click the "Check with a +" button for Done and Add. 10. In the Name field, enter Label. 11. Leave Base Type as the default of STRING. 12. Click the "Check with a +" button for Done and Add. 13. Repeatedly add additional fields, each with a Base Type of NUMBER, until all of the following Field Definitions have been entered: Value XAxis Data ASensor BSensor CSensor XValue YValue BubbleValue Note that you'll want to click the "Check" button for Done after entering the last definition. 14. Click Save.    Step 3: Create Value Stream   An easy way to record changes to a Thing Property is via enabling the Logged functionality. However, without a place in which to log the changes, logging the Property does nothing. One way in which to create a storage location for Property changes is a Value Stream. On the ThingWorx Composer Browse tab, click Data Storage > Value Streams, + New.   In the Choose Template pop-up, select ValueStream and click OK.   In the name field, enter DDCValueStream.   If Project is not already set, search for and select PTCDefaultProject.  At the top, click Save.   Click here to view Part 2 of this guide. 

  Create Your Application Guide UI Part 5    Step 7: Test Your GUI   At this point in the lesson, your Mashup now contains: Graphics to represent data Data Logical connections between the graphical elements and the data   Run Application   Execute the following steps to test that your application works as expected. Click the View Mashup button at the top. You may have to disable your pop-up blocker to load the Mashup in a new browser tab.   2. Wait and observe the Mashup for at least 20 seconds, clicking the Manually Retrieve Counts button regularly. NOTE: The values in the Mashup will increase roughly every 10 seconds, after you press the button to manually retrieve them. This happens because the Thing you imported earlier is simulating data and the work already done by the Edge and Backend Developers in this scenario. In this simulation, different production lines are continually producing new inventory, and that information is being fed into ThingWorx Foundation. As the count for each production line reaches 100, the batch is shipped out, and the count resets to 0 for the next iteration. 3. Check the Gears Manually Set Checkbox, change the Gears Count Text Field to read 7, and click the Manually Set Counts button. After 10+ seconds have passed, click the Manually Retrieve Counts button again. NOTE: This simulates a situation where an IoT sensors in the inventory warehouse has failed. Maybe it's over or under-counting inventory. Maybe there's a network issue. Maybe the sensor has simply stopped working entirely. Regardless, the warehouse floor has contacted a user of your GUI, and asked them to manually set the inventory to the correct amount. Performing Step 4 is all that is required to do so. As long as the Gears Manually Set checkbox is active, the inventory does not increase on the 10 second timer. This is to prevent a malfunctioning sensor from providing incorrect data to your GUI. 4. Uncheck the Gears Manually Set Checkbox and click Manually Set Counts. NOTE: The Gears Count starts increasing again after 10 seconds have passed. Remember to click the Manually Retrieve Counts button to see this change. This represents the previously-malfunctioning IoT sensor having been repaired.   Spend some time interacting with your Mashup GUI to get a better sense of its functionality. For the purposes of this exercise, this is a Minimum Viable Product. After testing it and getting feedback from your users, you would likely make further enhancements.   Collect Feedback   When testing your GUI, it is a best practice to collect feedback from users regarding your design, so that you can improve the experience with your application. Example User Feedback Possible Resolution Manually Set Counts button is too easy to accidentally press. Implement a Confirmation pop-up. Manually Retrieve Counts button is not ideal, should automate Remove the manual button and implement auto-update functionality instead. Manually Set Checkboxes have confusing names. Change the text to read Disabled, indicating that the sensor-input is being ignored. User wants to use your GUI on their smartphone and on a desktop computer. Re-implement the GUI using a Responsive (rather than Static) Mashup, so that there isn’t as much dead space on larger-resolution screens. User wants a visual indication of each inventory line amount at which the pallet is shipped out. Instead of using TextBoxes to show the current inventory counts, you could implement them as Gauges, showing a minimum and maximum amount that is easy to see at-a-glance.   Now that we've gotten some feedback, let's implement one such change-request as an example.   Enhance your GUI   Set up GetProperties to automatically update whenever data changes instead of using a button to manually retrieve the data. Close your MVP Mashup browser-tab and return to the Mashup Builder. Click the button-manual-retrieve Widget to select it.   Hit your keyboard's Delete key.   Click Yes in the Remove the selected widgets? pop-up window.   Click the green </> button beside Things_MBQSThing in the top-right Data tab.   6. In the Services Filter field, type getprop. 7. Click the right-arrow beside GetProperties. Be sure to select GetProperties, not GetPropertyValues. 8. Check the Execute on Load checkbox. 9. Click Done. 10. In the Data tab on the top-right, expand the newly-added GetProperties Service. 11. Drag-and-drop Gears_Count onto textbox-gears-count. 12. On the Select Binding Target popup, click Text. 13. On the Confirm Binding Replace pop-up, click Yes. 14. Repeat steps 11-13 for Pistons_Count and Wheels_Count onto their respective TextBox Widgets. 15. Drag-and-drop Gears_Count_Manually_Set onto checkbox-gears-manual. 16. On the Select Binding Target popup, click State. 17. On the Confirm Binding Replace pop-up, click Yes. 18. Repeat steps 15-17 for Pistons_Count_Manually_Set and Wheels_Count_Manually_Set onto their respective Checkboxes. 19. Click the GetProperties Service to select it. 20. In the bottom-right Data Properties section, check the Automatically update values when able box. 21. Click Save. 22. Click View Mashup.   You have now enhanced your MVP Mashup based on user feedback. The Counts in each TextBox will automatically update whenever there is a change in the Property values, as requested. ThingWorx Foundation provides a platform that allows you to quickly create a GUI for your IoT application in an extremely flexible and agile manner. The options to continue to improve your GUI are entirely up to you.   Step 8: Next Steps   Congratulations! You've successfully completed the Create Your Application UI guide, and learned how to: Create new Mashups Choose a Static or Responsive layout Add Widgets to your Mashup Bind data Services to Widgets in your Mashup Create a functional GUI with applied usage of Widgets and Service   The next guide in the Customize UI and Display Options to Deploy Applications learning path is Basic Mashup Widgets.    Learn More   We recommend the following resources to continue your learning experience: Capability Guide Build Data Model Introduction   Additional Resources   If you have questions, issues, or need additional information, refer to: Resource Link Community Developer Community Forum Support Mashup Builder Support Help Center    

Create Your Application Guide UI Part 1    Overview   This project will introduce the ThingWorx Mashup Builder. Following the steps in this guide, you will learn how to use this tool to create a Graphical User Interface (GUI) for your IoT Application. We will teach you how to rapidly create and update a Mashup, which is a custom visualization built to display data from devices according to your application's business and technical requirements. NOTE: This guide's content aligns with ThingWorx 9.3. The estimated time to complete ALL 5 parts of this guide is 30 minutes.    Step 1: Create New Mashup   The Mashup Builder is a drag-and-drop environment with a What You See Is What You Get (WYSIWYG) interface. With the Mashup Builder you can quickly and easily create a visualization of your IoT data. In this step, we'll explain various options to customize your application GUI. Click Browse > VISUALIZATION > Mashups.   Click + New. You are now on the New Mashup pop-up window.           Layout Options When creating your UI, you must choose whether you want a Responsive, Static, or Responsive (Advanced) Mashup, depending on the resolutions of the displays you want your application users to utilize when running your application. Mashup Layout Description When to Use Responsive Expands to the resolution of the display in an even more dynamic manner than the Responsive (Legacy) option. Previously-labeled as Responsive (Advanced), this is now the default option with modifications to the Mashup Builder interface versus previous versions. For instance, divisions such as a header or footer are available with the Template options at the bottom of the pop-up. Static (Legacy) Sized to the dimensions that you define. Static Mashups are appropriate when your users have a standard device on which they’ll be utilizing your application, such as a smartphone or tablet. When displayed in a lower resolution you will see scroll bars, in a higher resolution there will be unused space around the Mashup. Responsive (Legacy) Expands to the resolution of the display without leaving any unused space around the Mashup. Responsive Mashups should be utilized when you anticipate that users will interface with your application through various-sized screens. Responsive Mashups should always be tested at various resolutions to ensure optimum display of your IoT data.   Keep the default of Responsive (with NO Responsive Templates chosen), and click OK in the pop-up window. In the Name field, enter appui_mashup.   If the Project is not already set, search for and select PTCDefaultProject.  At the top, click Save.   At the top, click Design. This is the Mashup Builder user interface we will use for the remainder of this guide.              6. On the left, click the "left arrow" Collapse icon to cause the Composer Navigation to slide-out, revealing more room for the Mashup Builder interface.         Step 2: Mashup Builder Sections Now that you've launched the Mashup Builder, you'll need an understanding of the layout and configuration options.     NOTE: Section 1 in the top-left has a drop-down arrow you can click to reveal additional sections if your screen resolution is too small to show all of Widgets, Layout, and Explorer. There is also the Mashups tab in Section 1, but it is not covered in this guide.   Mashup Builder Section Description 1a Widgets Widgets provides a list of every graphical element within the platform. There are a wide variety of selections, from grids to graphs to text boxes to buttons. There is also a Filter Widgets field where you can enter the name of a particular Widget to sort the list. 1b Layout Layout is used to divide your Mashup into logical sub-sections. 1c Explorer Explorer allows you to reach any individual element of a Mashup. This can be helpful when multiple Widgets are overload on top of each other in the central Canvas window, making it difficult to click on them individually. 2 Canvas This is an area into which you can drag-and-drop Widgets to your desired location to build your application UI. You can also drag-and-drop data onto the Widgets in the Canvas. 3a Data Data is fundamental to any Mashup that wants to display ThingWorx IoT data, as it allows you to bind backend-data to particular Widgets. 3b Session Session provides access to Session Parameters, which are similar to global variables that may be used across multiple Mashups, such as cookies or security information for a logged-in User. 3c User User provides access to the User Extensions. User Extensions are the Properties of the logged-in User and can be used on the Client side and/or the Server side. 4a Properties Properties displays the Properties for the selected Mashup or Widget. These Properties allow you to perform a variety of modifications to Widgets, such as setting its exact position. 4b Style Properties Style Properties are a sub-set of Properties dealing with items such as changing color. 5a Bindings As data connections are made to various Widgets, the Bindings window will show these links in an easy-to-understand 'arrow' format. For instance, if a button press causes a Thing’s Service to be called, then you’ll see a connection from the Button Widget’s *Clicked* Event over to the Thing’s Service. 5b Reminders Reminders points out issues with your Mashup, such as unbound but required Properties, which often must be fixed before the Mashup can be saved. 6a Data Properties Data Properties displays properties of the selected data element. This can be helpful, for instance, when you want something to be triggered only when something else has completed. In that scenario, you’d look for the ServiceInvokeCompleted Event in this bottom-right area. 6b Functions Functions provides the ability to write custom business logic within the Mashup itself.   Step 3: Introducing Widgets   The primary way in which you'll create the GUI for your IoT application is with Widgets. Widgets are self-contained graphical elements that you can drag-and-drop onto the central Canvas area. Once placed on the Canvas, you can: Modify Widget layout Resize Widgets Bind Data to Widgets Combining several Widgets together will allow you to quickly and easily create a functional GUI for your IoT application. Widget Name Widget Example Picture Description Button   The Button Widget triggers an Event when it is clicked. Typically, this Event will be used to trigger a Service to either push or pull data from the platform’s backend. Checkbox   The Checkbox Widget provides a simple box which can be either set or not-set. You primarily use a Checkbox when you’re setting or displaying Boolean data. Gauge   The Gauge Widget provides a more “graphically interesting” way to display a numerical value. You can set the minimum and maximum values which a Gauge displays, or style a Gauge so that different areas are different colors. Label   The Label Widget displays a non-user-interactable string within your Mashup. You can use this to create headings or descriptions for parts of your Mashup. Text Field   The Text Field Widget is a small, one-line area into which you can either accept an input string from the User or display a string from the platform’s backend. Combining a few of the basic Widgets described above allows you to create a Mashup for your IoT application. However, without data being supplied to these Widgets from the platform's backend, they're just pretty graphics. In the next section, we will introduce a few of the Mashup Services that enable bidirectional data flow between your GUI and device data.   Click here to view Part 2 of this guide.     

  Basic Mashup Widgets Guide Part 3   Step 5: Gauge   A Gauge is best for displaying a quickly readable approximate value. Select the Widgets tab in the uppper panel of the left dock, then enter gauge inside the Filter field in the top left. Drag-and-drop the Gauge widget onto the bottom-center container. We will now bind the Slider to the Gauge. Click the Slider Widget in the top-right Container. Click the drop-down arrow on the left side of the Slider widget. Click and drag the Value property listed in the Slider drop-down onto the Gauge widget.   Click the # Data property that is available from the Select Binding Target pop-up.   Click Save to save your Mashup. Click View Mashup then adjust the slider to the left to see the changing value shown on the widget. Many properties are available that give control over how the Gauge widget will be displayed. Many properties can be changed both statically when designing the mashup, and dynamically in response to changes in property values.   Bindable Name Type Default Direction Description Data Number None Input Value displayed by gauge indicator MinValue Number 0 Input Value used for lowest gauge display MaxValue Number 100 Input Value used for highest gauge display Legend String None Input Text Shown under Gauge ToolTipField String None Input Text shown when mouse hovers over gauge Visible Boolean True Input Widget is visible if set to true   Static Name Type Default Description DisplayName String None Name used for widget in user-facing interactions Description String None Description used for widget in user-facing interactions MinorTicks Number 4 Number of minor ticks per interval TickLength Number 8 Tick mark length MinorTickLength Number 4 Minor tick length ValueDisplayMode None/Top/Bottom/Inside None Location on gauge where numeric value is shown. LabelDigits Number 3 Number of digits for label display LabelDecimals Number 0 Number of decimals for label display ValueDigits Number 3 Number of digits for value display ValueDecimals Number 0 Number of decimals for value display LegendDisplayMode None/Top/Bottom None Location on gauge where Legend is displayed ReferenceAngle Number 225 Angle that controls the gauge orientation (degrees) Aperture Number 270 Angle that controls the gauge size (degrees) NeedleDiameter Number 10 Diameter of the gauge needle (pixels) CenterDiameter Number 20 Diameter of the gauge center (pixels) GaugeBorder Number 20 Width of the outside gauge border (pixels)     Step 6: Grid Advanced   A Grid Advanced widget is used to display data to a mashup user in a table Select the Widgets tab in the uppper panel of the left dock, then enter grid inside the Filter field in the top-left. Drag-and-drop the Grid Advanced widget onto the top-left container on your Mashup that already has the Button Widget. Add Data Source   Before you can customize the Grid display, you must first bind an Infotable to the Grid's Data property. In this example we will use the QueryImplementingThingsWithData Service to bind a group of Things created with the same Template. We have created a file with sample entities for this exercise. Download the attached demoTractors.xml. Click Import/Export in the lower left of Composer, then select Import   Click From File in the drop down, then Browse. Browse to the demoTractors.xml file and click Open. Click Import, then Close after entities are successfully imported. Click the green + button in the Data tab on the right side of the Mashup Builder window. In the Select Entity panel click Thing Templates from the drop down.   Scroll through the available Thing Templates and select the Connected Tractors Template that was imported. Enter query into the filter text box then click the arrow to the right of QueryImplementingThingsWithData. Click the Execute on Load check box, this option will execute the QueryImplementingThingsWithData Service when the Mashup is loaded.   Click Done. Click the arrow icon to expand QueryImplementingThingsWithDate, and Returned Data. Click and drag All Data onto the Grid widget.   Click Data in the Select Binding Target pop-up.   NOTE: The Grid widget now shows Property names in the column headers.  15. Click the drop down in the upper left of the Grid widget, then click Configure Grid Columns to show the Configure Grid Columns pop-up. 16. Uncheck the check box next to the property names in the left-hand panel that you don't want shown in the Grid. NOTE: You can drag and drop the property names to change the display order. You can customize Column names and formatting by making changes in this window. 17. Click Done when you are satisfied with the column formatting options. 18. Click Save to save your Mashup. 19. Click View Mashup.         In addition to properties that give control over how a Grid widget will be displayed, the scroll position of a Grid can be read in the CurrentScrollTop property and can be set with the ScrollTop property.   Bindable Name Type Default Direction Description Data Infotable None Input The data that is displayed in the Grid EditedTable Infotable None Output The data that is in the Grid after a user edit CurrentScrollTop Number 0 Output How far down (in pixels from the top of the full data list) the Grid is currently scrolled ScrollTop Number 0 Input How far down (in pixels from the top of the full data list) the Grid will be scrolled. Visible boolean true Input Widget is visible if set to true   Static Name Type Default Description DisplayName String None Name used for widget in user facing interactions Description String None Description used for widget in user facing interactions RowFormat StateDefinition None Specify a State Formatter to control display of the data in each grid row AlignHeader Boolean False When enabled, align column headers with their data MultiSelect Boolean False allow multiple items to be selected IsEditable Boolean False Allow grid value editing in Configure Grid Columns pop-up AutoSelectFirstRow Boolean False Automatically select the first row upon initial loading of data. CellTextWrapping Boolean False Enable or disable text wrapping within the grid cells. TabSequence Number 0 Tab sequence index   Widget Events Name Description DoubleClicked Fired when user double clicks on the grid   Step 7: Next Steps   Congratulations on completing the guide!   The next guide in the Customize UI and Display Options to Deploy Applications learning path is Define Your UI Style.    If you have questions, issues, or need additional information, refer to: Resource Link Experience ThingWorx Application Development Reference Community Developer Community Forum Support Button Widget Help Center Support Slider Widget Help Center Support Gauge Widget Help Center Support Advanced Grids (Themable) Help Center    

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

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