cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

ThingWorx Navigate is now Windchill Navigate Learn More

IoT & Connectivity Tips

Sort by:
  Step 8: Tasks If you are using the built-in Tasker to drive data collection or other types of repetitive or periodic activities, create a function for the task. Task functions are registered with the Tasker and then called at the rate specified after they are registered. The Tasker is a very simple, cooperative multitasker, so these functions should not take long to return and most certainly must not go into an infinite loop. The signature for a task function is found in [C SDK HOME DIR]/src/utils/twTasker.h. The function is passed a DATETIME value with the current time and a void pointer that is passed into the Tasker when the task is registered. After creating this function, it will need to be registered using the twApi_CreateTask function after the connection is created. Below shows an example of creating this function, registering this function, and how this function can be used. #define DATA_COLLECTION_RATE_MSEC 2000 void dataCollectionTask(DATETIME now, void * params) { /* TW_LOG(TW_TRACE,"dataCollectionTask: Executing"); */ properties.TotalFlow = rand()/(RAND_MAX/10.0); properties.Pressure = 18 + rand()/(RAND_MAX/5.0); properties.Location.latitude = properties.Location.latitude + ((double)(rand() - RAND_MAX))/RAND_MAX/5; properties.Location.longitude = properties.Location.longitude + ((double)(rand() - RAND_MAX))/RAND_MAX/5; properties.Temperature = 400 + rand()/(RAND_MAX/40); /* Check for a fault. Only do something if we haven't already */ if (properties.Temperature > properties.TemperatureLimit && properties.FaultStatus == FALSE) { twInfoTable * faultData = 0; char msg[140]; properties.FaultStatus = TRUE; properties.InletValve = TRUE; sprintf(msg,"%s Temperature %2f exceeds threshold of %2f", thingName, properties.Temperature, properties.TemperatureLimit); faultData = twInfoTable_CreateFromString("message", msg, TRUE); twApi_FireEvent(TW_THING, thingName, "SteamSensorFault", faultData, -1, TRUE); twInfoTable_Delete(faultData); } /* Update the properties on the server */ sendPropertyUpdate(); } … twApi_CreateTask(DATA_COLLECTION_RATE_MSEC, dataCollectionTask); … while(1) { char in = 0; #ifndef ENABLE_TASKER DATETIME now = twGetSystemTime(TRUE); twApi_TaskerFunction(now, NULL); twMessageHandler_msgHandlerTask(now, NULL); if (twTimeGreaterThan(now, nextDataCollectionTime)) { dataCollectionTask(now, NULL); nextDataCollectionTime = twAddMilliseconds(now, DATA_COLLECTION_RATE_MSEC); } #else in = getch(); if (in == 'q') break; else printf("\n"); #endif twSleepMsec(5); }   Step 9: File Transfer Example To handle file transfers, a virtual directory is created in the SteamSensor1 entity and in the [C SDK HOME DIR]/examples/FileTransferExample application directory. The source code used for this example is found in [C SDK HOME DIR]/examples/FileTransferExample/src/main.c. Inside of the [C SDK HOME DIR]/examples/FileTransferExample folder, create the folder structure shown below: /transfer/ /transfer/incoming/ /transfer/outgoing/ Inside of the /transfer/outgoing/ directory, create and open a file with the name outgoing.txt. Once the outgoing.txt document is open, add the following text, save, and close the file: Hello. This is a file coming from the client application. Navigate to the [C SDK HOME DIR]/examples/FileTransferExample/src/main.c code and update the lines below with the appropriate information for your IP, port, and the “admin_key” Application Key’s keyId value in the ThingWorx Composer: /* Server Details */ #define TW_HOST "127.0.0.1" #define TW_PORT 80 #define TW_APP_KEY "ce22e9e4-2834-419c-9656-ef9f844c784c" To support file transfers in your client application, you must use the twFileManager_AddVirtualDir function in order to create the virtual directories in the entity with such a capability. It will also define the directories available for file operations. A virtual directory maps a unique name to an absolute path of a directory in the file system. All subdirectories of the specified directory are exposed to the server. You can define multiple virtual directories. The directories do not need to be contiguous.   Staging Directory As an optional, but recommended step, you should set the directory that the application should use for staging when performing file transfers. This can be seen in the line below and should be done before initializing the FileManager. The default directory of the FileManager is most likely owned by root and will require a change to either the location of the staging directory and the ownership of the staging directory, or running the application as a User with the correct permissions. twcfg.file_xfer_staging_dir = "staging"; The example provided uses the TW_SHARE_DIRECTORY macro to create two virtual directories that will act as the root directories in the virtual file system of this application are added. The client is then started as follows with the necessary TW_ADD_FILE_TRANSFER_SHAPE function being called: TW_ADD_FILE_TRANSFER_SHAPE(); TW_SHARE_DIRECTORY("in", "/transfer/incoming/"); TW_SHARE_DIRECTORY("out", "/transfer/outgoing/"); The creations of the payloads used to create the remote directories on the platform have been moved to a helper function below to make the design cleaner: int setupSystemRepo(const char * remoteInPath, const char * remoteOutPath, const char * remoteFile); After our remote directories and files have been setup, it is time to perform the file transfers. Normally, this would mean invoking the Copy service for a Subsystem, but two functions have been created to make this process easier: int twFileManager_GetFile(const char * sourceRepo, const char * sourcePath, const char * sourceFile, const char * targetRepo, const char * targetPath, const char * targetFile, uint32_t timeout, char asynch, char ** tid) int twFileManager_SendFile(const char * sourceRepo, const char * sourcePath, const char * sourceFile, const char * targetRepo, const char * targetPath, const char * targetFile, uint32_t timeout, char asynch, char ** tid) The table below displays an example of the first set of parameters:   Parameter     Example                              Description sourceRepo SystemRepository The name of FileRepository or RemoteThing to transfer the file FROM. sourcePath outgoing The path specifying the location of the source file. sourceFile The name of the source file.   targetRepo SteamSensor1 The name of FileRepository or RemoteThing to transfer the file TO. targetPath incoming The path specifying the destination location of the file. targetFile incoming.txt The name of the file at the target. This name can differ from the sourceName. timeout 15,000 The amount of time (in seconds) to wait for a synchronous transfer to complete before cancelling the transfer. async false If false, the service call will block for timeout seconds or until the transfer completes. tid incoming0123 The unique TID associated with the file.   The C SDK also provides the ability to create a FileCallback function that the FileManager will call that function when any file transfer events occur. You can provide a wildcard filter so that only file transfer Events of files that match the filter call the callback function. In addition, callbacks can be set up as “one-shots” such that the callback is unregistered automatically after it is invoked the first time.   NOTE: An optional file transfer callback is registered in the code and provided. You will see the output from the function as files are sent and received.   After running this application, you will notice a new file in the transfer/incoming folder after refreshing. This is the file that we created in the ThingWorx Composer file system for the SystemRepository Entity and was able to copy from that location to our local project. We have also sent a file to the server’s SystemRepository. The BrowseFileSystem and GetFileListing services can be used to check for the folders and files created. twFileManager_RegisterFileCallback(fileCallbackFunc, NULL, FALSE, NULL);   Step 10: Support Other Platforms All Websocket errors indicate some general issue communicating with the ThingWorx platform. If you experience an issue connecting, refer to the table below for a list of websocket errors, their corresponding codes, and an explanation of the issue.   Code   Message                                                                       Troubleshooting 200 TW_UNKNOWN_WEBSOCKET_ERROR An unknown error occurred on the websocket. 201 TW_ERROR_INITIALIZING_WEBSOCKET An error occurred while initializing the websocket. Check your websocket configuration parameters for validity. 202 TW_TIMEOUT_INITIALIZING_WEBSOCKET A timeout occurred while initializing the websocket. Check the status of the connection to ThingWorx. 203 TW_WEBSOCKET_NOT_CONNECTED The websocket is not connected to ThingWorx. The requested operation cannot be performed. 204 TW_ERROR_PARSING_WEBSOCKET_DATA An error occurred while parsing websocket data. The parser could not break down the data from the websocket. 205 TW_ERROR_READING_FROM_WEBSOCKET An error occurred while reading data from the websocket. Retry the read operation. If necessary, resend the data. 206 TW_WEBSOCKET_FRAME_TOO_LARGE The SDK is attempting to send a websocket frame that is too large. The Maximum Frame Size is set when calling twAPI_Initialize and should always be set to the Message Chunk Size (twcfg.message_chunk_size). 207 TW_INVALID_WEBSOCKET_FRAME_TYPE The type of the frame coming in over the websocket is invalid. 208 TW_WEBSOCKET_MSG_TOO_LARGE The application is attempting to send a message that has been broken up in to chunks that are too large to fit in a frame. You should not see this error. 209 TW_ERROR_WRITING_TO_WEBSOCKET An error occurred while writing to the Web socket. 210 TW_INVALID_ACCEPT_KEY The Accept key sent earlier from ThingWorx is not valid.   Next Steps Congratulations! You've successfully completed the C SDK Tutorial, and learned how to utilize the resources provided in the Edge SDK to create your own application.   This is the last guide in the Connect and Configure Industrial Devices and Systems Learning Path.  If you wish to return to the Learning Path, click the link.   Additional Resources If you have questions, issues, or need additional information, refer to:  Resource Link Community Developer Community Forum Support C Edge SDK Help Center
View full tip
This video concludes Module 3: Data Profiling of the ThingWorx Analytics Training videos. It shows you a few examples of questions that should be asked of a subject-matter expert (SME) to better understand the information contained in a dataset. Using answers to these questions, you will  use a tool such as Microsoft Excel to modify a given dataset, and prepare it for future exercises in this course.
View full tip
Starting with ThingWorx Manufacturing Apps 8.1, a Connection Info box was added to Controls Advisor that will display the Configuration settings needed in KEPServerEX. In Controls Advisor, select the server instance you are connecting with, then select the Key icon Be sure the information displayed here matches the settings you have in place in your KEPServerEX Project Properties in the ThingWorx property group.    
View full tip
Applicable Releases: ThingWorx Platform 8.0 to 8.5; ThingWorx Navigate 1.5.0 to 8.5.0   Description:   Definition and concepts of Single Sign On (SSO), terminologies, components and architecture, as well as configuration prerequisites and high level steps to configure using PingFederation with Windchill and Navigate and main troubleshooting techniques    
View full tip
  Setup user interfaces and ways to track events   GUIDE CONCEPT   Being able to view your logs is an important part of knowing what is happening in your system. You can't keep things secure if you don't know who is doing what.   These concepts and steps will allow you to focus on development of your application while still allowing the ability to utilize the power of ThingWorx!   We will teach you how to access the system in a way you might not have done much of before.     You'll learn how to   How to design and implement meaningful user interfaces View different logs and search for data NOTE: This guide's content aligns with ThingWorx 9.3. The estimated time to complete this guide is 30 minutes   Step 1: Example and Strategy   If you’d like to skip ahead, download the completed example of the Aerospace and Defense learning path attached: AerospaceEntitiesGuide1.zip. Import the .twx files included.   In an ever-changing world, you are going to need to protect everything that is considered private. In order to do this, you need to be able to track every bit of what is happening in your system. ThingWorx does not provide an out of the box method to log when users open a Mashup window. What if this Mashup contains secure documents? Well, we can work with you on getting that logged and tracked.   Let us start working on securing our system by adding some Mashups that are simple, but we will add complexity around them. Before designing our Mashups, we will set permissions and go from there.      Step 2: Setting Mashup Permissions We will create a Mashup, but the focus will be the security of the Mashup, not the Design and UI itself. Follow the steps below to get started. In the ThingWorx Composer, click the + New at the top of the screen. Select Mashup  in the dropdown. 3, Select Responsive for the layout option. 4. Click Ok.   5. Enter a name for the Mashup Template, such as SecureMashupExample.   6. Click Save then click the Permissions tab. 7. On the Visibility tab, in the Search Organization text box, begin typing and select PTCDefenseDepartment. This allows anyone in the organization to be able to access this Mashup.    8. On the Runtime tab, in the Search Users and User Groups text box, begin typing and select Agency.IT.  9. Set all permissions to Allow (check). This allows a User Group to run services during Runtime of your application. Keep in mind, this gives permissions to all parts of the Mashup (Events, Subscriptions, Services, Parameters). 10. If you would like to be more specific, in the Search Properties, Services, or Events text box, select a service, ie GetHomeMashup. In the text box that appears below for Users and User Groups, select Agency.HumanResources.  11. On the Design Time tab, the Search Users and User Groups text box, begin typing and select Agency.IT.  12. In the Search Users and User Groups text box, begin typing and select Agency.HumanResource. 13. For Agency.IT, set the permissions to allow Read, Update, and Delete. For the Agency.HumanResource User Groups allow Read and deny Update and Delete.   You have just begun the process to securing the application from users looking to view specific secure pages. Next, let's create a simple page and show how we can log who accesses specific pages.      Step 3: Designing Tracked Mashups We will be creating a simple Mashup with the focus of showing how to add logging to a Mashup. Let's start by opening up the Mashup we just created.   Open the SecureMashupExample Mashup and click on the Design tab. Click the Layout panel in the top left and add a Bottom Container. In the Widgets panel, drag and drop a Blog Widget to the top container.   Drag and drop a Web Frame Widget to the bottom container.   Select the Blog Widget in the top container. In the Properties panel, update the Blog property to any existing or new Blog entity (there is a Blog in the provided download).    Select the Web Frame Widget in the bottom container. In the Properties panel, update the URL field to a website you trust. In this case, I'll be using https://www.ptc.com/.   Click Save and View Mashup.   When accessing this Mashup, nothing is logged. We'll be changing that in the next steps with a service that will be called and log who is using the Mashup.   In the ThingWorx Composer, click the + New at the top of the screen.   Select Thing in the dropdown.   In the name field, enter SecureServices and select GenerticThing as the Base Thing Template. Click Save and go to the Services and Alerts tab. Click the New button. Enter LogMashupAccess as the Service name.   Click the Input section and add a required String parameter named MashupName. Click Done and Add.   Add a second String parameter named Username that is required. Click Done.   Enter the below lines of code into the canvas. It will be a simple log statement for tracking. We can add a lot more to this method if we liked. logger.trace(MashupName  +  " accessed by " + Username); Click the green Save and Continue button to save your work.   Add Log Service to Mashup   We'll now need to call this logging service to see whenever a user has logged into our secure page. Of course, this is a simplified example and much more could be done here. Go back to the SecureMashupExample Mashup. In the Data panel, click the + button to add a service. Search for our new SecureServices Entity, then add the LogMashupAccess service. Ensure the Execute on Load checkbox is checked.  Click Done. Select the LogMashupAccess service. In the Data Properties panel in the lower right. In the MashupName text box, enter SecureMashupExample.   Select the User panel in the top right. Drag and drop the name field to the Username parameter. 9. Click Save.   You now have a Mashup that will log the UI being opened and the user accessing that UI whenever it is opened. Click View Mashup and go to the ScriptLog in order to test. You filter will need to be set to All or at least Trace to see the log statement.   In the next section we'll see how we can test this and do a bit more.     Step 4: Viewing and Filtering Logs   Data logging and filtering is one of your most powerful tools not only in the ThingWorx environment, but in developing solutions. The next section of this learning path will go in depth about what each of these items in a Monitoring screen does. It will also cover tricks to help your search. For now, let's look at how we can view logs and filter them to find what we need.   No.  Item Usage  1  Search Bar  Search the log for key words and phrases. 2  Filter Button  Provides a list of options to fine tune your search. This menu is very powerful. 3  Log Configurations  Select what level of logging you'd like to see. 4  Date Range  A date range filter to help limit or set your specific date options. 5  Max Row Count  The max number of rows to search for and return. The search will continue until this number is met or your other search filters have been met (ie, date range). 6   Apply/Reset Buttons  Apply the changes for your date range and max account or reset these values to their defaults. 7  Refresh/Auto Refresh Buttons Allow the log to continue based on your filters (if any) without you having to refresh. You can also refresh it on your own. 8  Log Header and List  The logs that were found based on your filters or settings. 9  Selected Log View  After selecting a log item in the list, it will be shown here.   The are some tricks to finding what you want and need faster. We dive into that in the next guide in this learning path.     Step 5: Next Steps Congratulations! You've successfully completed the Tracking Activities and Stats guide, and learned how to use the ThingWorx Platform to help track what is happening in your application.   If you wish to return to the learning path, click Utilizing ThingWorx to Secure Your Aerospace and Defense Systems   Learn More We recommend the following resources to continue your learning experience: Capability Guide Build Design Your Data Model Manage Data Model Implementation Guide Additional Resources If you have questions, issues, or need additional information, refer to: Resource Link Community Developer Community Forum Support REST API Help Center  
View full tip
Composer Enhancement: -Improved workflow support NG Composer challenging to navigate -> Usability challenges with editing and viewing data Feature: -Tab style editing support -Horizontal tabs -New Grids with Resizing -Resizing in Entity Grids -Schedule Editor Problem: Need modernization of platform visualization toolset -> -New Webcomponent widgets -Responsive layout now GA -Theming now GA -Key messaging -New ability to build responsive modern web applications   Theming and Theme editor -Centralized style management -Easily apply to all Mashups of an applications -Bindable, can be changed dynamically -Set Colors Typography, Lines, Borders, States -Set globally or by group of elements (buttons, grids, inputs) -Mashup Preview can be set   New Widgets in 8.5 -Breadcrumb -Dynamic panel -Icon -Image -List Shuttle -Property Display -Slider -Value Display -Advanced Grid now part of platform Functions: -Confirmation -Event Router -Logout  -Navigation -Status Message   Responsive Layout -New responsive layout editor, based on Flex -Content lays out according to rules, adapts to the screen size and settings -Static and size range support   Migration When you open a mashup containing legacy widgets for which there are web component replacements available OR You open a mashup containing legacy layouts, a banner appears at the top of the design page Clicking Yes will migrate to new widgets and new flex layout -Bindings in the mashup are retained -Recommended to review widgets sizes   Layout Migration -Static layous are migrated to a responsive flex container Q: There is still no Right mouse click support?  A: We don't have a right click context menu yet, but we're looking into what can be included based on the context for a future release. Q: With flex containers, is it still possible to create a mashup with two columns, one covering 1/3 of the screen, the other 2/3 of the screen, when the size of the screen is not known upfront? A: Correct - you can set container rules to grow and shrink (in your case, set one container to use 1/3rd and the other 2/3rd) Q: Do we have the cut/paste function in the responsive containers so we're able to move content around? A: Yes, now you can move the whole container too! You can either use the cut/ copy/ paste from the toolbar, or use keyboard shortcuts (shift for cut/ move and alt for copy). Q: The old layout widget allowed setting column size as percentage, rather than absolute size. How can that be done in containers? A: With containers, it uses the standard flex-grow and flex-shrink css properties. We have Grow Ratio and Shrink Ratio properties available, and you can set the values there. Q: How are we addressing the expand/collapse functions we used to have in the headers/footers/righ&left side bar? A: Each container  will have an option to Expand/ Collapse. Based on where the container is located (left/ right or top/ bottom), it will expand accordingly - so left/ right sidebar or header/ footer. Q: Does it show which widgets are undergoing the changes from legacy to new? A: The legacy widgets are grouped in the 'Legacy' widget category, and are indicated with an icon noting it's a legacy widget. Q: What about migrating from widget from extension (ie advanced grid) ? Those will be replaced also? A: Correct - when you move to 8.5, you won't have to import the extension any longer. If you have any Mashups with the Advanced Grid in place, it'll pick it up. Q: Can we add CSS to the themes? A: Yes, you can add. The Custom CSS tab is available for Themes specifically too. Q: Bindings of containers won't be saved - does that mean that if we use contained mashup with mashup parameters, all bindings will be lost? A: The bindings within the container should not change; the Mashup parameters will be exposed so that you can bind in/ out. The bindings should be retained - when you migrate from the old layout to the new, any bindings you have should not be lost/ broken.
View full tip
    Step 5: Verify Connectivity    The EMS is now attempting to talk to the ThingWorx platform.   However, ThingWorx does not have detailed information about the Edge device that is attempting to connect to it, so it will show up in the Unbound category.   Open ThingWorx Composer.     On the left, click Monitoring.     Click STATUS > Remote Things.     Click Unbound.     Confirm that you see the EdgeThing listed in the Unbound section. NOTE: The name EdgeThing comes from the config.lua script. EdgeThing is simply the name that is in that script, hence the name that you see in ThingWorx. To change the name of the device, you could stop both wsems.exe and luaScriptResource.exe, edit config.lua to use a different Thing name other than EdgeThing, and then restart both of the WSEMS programs. At that point, the Thing showing up in Remote Things -> Unbound would be whatever name you changed to in config.lua.   Create a Remote Thing   Now that the EMS is communicating with Foundation, let's create a Remote Thing to which Foundation can tie said connection.   In ThingWorx Composer, click Browse > MODELING > Things, + New.     In the Name field, enter EdgeThing. Note that the name must match the spelling and capitalization of the Thing's name that you entered in the EMS's config.lua for it to auto-connect.  If Project is not already set, search for and select PTCDefaultProject. In the Base Thing Template field, search for and select RemoteThingWithTunnelsAndFileTransfer.   At the top, Click Save. Note the status-indication pop-up indicating that EdgeThing is now connected.   Use Services to Explore EMS Files   Now that your Remote Thing is Saved and Connected, we can use some of the built-in Services to explore the EMS folders and files which we previously created for testing purposes.   At the top of EdgeThing, click Services.   Under the Execute column, click the Play Symbol for BrowseDirectory.   In the top-left path field, type / and click the bottom-right Execute button. Note the other and tw folders which we previously created for testing.     In the top-left path field, type /tw and click the bottom-right Execute button. Note the tw_test_01.txt file which we previously created for testing.     As the tw_test_01.txt file (and its parent folder) were items which we custom-created for this guide, you should now be 100% convinced that connectivity between Foundation and the EMS is dynamically working.   If so desired, you could explore into other folders (or even add additional files to these folders), run the BrowseDirectory Service again, and confirm that Foundation is now aware of the EMS and actively communicating.     Step 6: Next Steps   Congratulation! You've completed the Install the Edge MicroServer (EMS) guide.   In this guide, you learned how to:   Install the EMS Configure the EMS Connect the EMS to ThingWorx Foundation   The next guide in the Medical Device Service learning path is Setup a Raspberry Pi as an IoT Device.    The next guide in the Vehicle Predictive Pre-Failure Detection with ThingWorx Platform learning path is Use the EMS to Create an Engine Simulator.   Learn More   We recommend the following resources to continue your learning experience:   Capability Guide Connect Connect Industrial Devices and Systems   Additional Resources   If you have questions, issues, or need additional information, refer to the:   Resource Link Community Developer Community Forum
View full tip
This video continues Module 6: Predictive Models & Model Validation of the ThingWorx Analytics Training videos. It describes the remaining machine learning algorithms used by ThingWorx Analytics to build predictive models that weren't covered in Part 1. In addition, this video describes the different kinds of ensembles you can build that utilize multiple algorithms. 
View full tip
    Select the right database to use with your ThingWorx installation.   Guide Concept   When you develop an application with ThingWorx, you must save the configuration data that defines the data model and the user interface. You also need to store the dynamic data that is generated by devices at runtime (such as temperature or location).   ThingWorx uses the term Persistence Provider to refer to any type of service that saves application data, usually it is a database.   When your application moves into production you must choose and configure a Persistence Provider that meets your requirements.     You'll learn how to   Pros and cons of different databases that can be used as persistence providers for ThingWorx The database best suited to certain applications Where to find detailed information about the Persistence Providers   NOTE: The estimated time to complete this guide is 30 minutes       Step 1: Persistence Provider Options   There are many factors that will influence your decision for which Persistence Provider to use with your ThingWorx instance. On this page we compare and contrast different methods and provide examples for where each one is a natural fit.    Persistence Provider             Typical Use H2 Bundled with ThingWorx server for proof-of-concept trials PostgreSQL Standard production database for use up to 15,000 Property writes per second InfluxDB High volume data ingestion (>25,000 property writes per second) into one database Microsoft SQL Server SQL database available from Microsoft in a dozen different editions Azure SQL Server SQL database managed by Microsoft in Azure   When ThingWorx is installed with default configurations, it uses the embedded H2 database as its Persistence Provider. This configuration is suitable for evaluations and proof-of-concept applications with a limited number of Things. Before an application is used in production, you must provision a more capable persistence provider. The available options for Persistence Provider are summarized below.   H2   Pros                            Cons                     Typical Use Case                                DBA Skills       Required Cost No Database set-up required Not for use in production Start testing ThingWorx with no additional configuration None No additional cost   H2 is an open source, full-featured relational database that is embedded in the ThingWorx Foundation server. No additional database set-up is required before developing a proof-of-concept application with ThingWorx. Using H2 should provide satisfactory performance for applications with less than 1000 Things.   WARNING: Due to the inability to back-up and recover the database, H2 should never be used in production.   PostgreSQL    Pros                    Cons                        Typical Use Case                     DBA Skills               Required Cost Widely used database Requires some configuration Workhorse database appropriate for many applications Basic SQL skills No additional cost   PostgreSQL is the default choice for ThingWorx cloud hosting servers. It complies with many database standards and is open source with no extra license fee required. It can be configured for high availability to minimize the chance of down-time or data loss. It has been tested up to 15,000 property writes per second and depending on other factors may give satisfactory performance up to 25,000 writes per second.   Learn more about using PostgreSQL:   Using PostgreSQL as the Persistence Provider ThingWorx PostgreSQL Administrator's Guide   InfluxDB   Pros                      Cons                            Typical Use Case            DBA Skills Required           License Cost Handle high volume data ingestion InfluxDB is not supported as a Property provider Application requiring >25,000 Property writes/second Professional services likely required Multi-node requires license fee   If your system intensively deals with time series data and your implementation heavily depends on Value Streams or Streams for persistence/retrieval of data, we recommend using InfluxDB as the Persistence Provider in ThingWorx. InfluxDB is a high-performance data store written specifically for time series data and is a good choice when high volume data ingestion of more than 25,000 property writes per second must be saved into one database.   Learn more about InfluxDB:   Using InfluxDB as the Persistence Provider   Microsoft SQL Server   Pros                     Cons                       Typical Use Case                    DBA Skills                      Required Cost Available in multiple editions Only runs on Windows Data stored in Microsoft SQL Server Configure settings License fee required   More than a dozen different versions of Microsoft SQL Server are used by customers for workloads ranging from small single-machine applications to large enterprise applications. Connecting ThingWorx to an existing Microsoft SQL Server can make that data readily available to use in ThingWorx Mashups.   Learn more about using Microsoft SQL Server:   Using Microsoft SQL Server as the Persistence Provider Getting Started with MS SQL and ThingWorx   Azure SQL Server   Pros                                    Cons                        Typical Use Case              DBA Skills         Required Cost Cloud deployment and scaling No on-premise option Data stored in Microsoft SQL Server Configure settings Subscription required   Fully managed database service operated and updated by Microsoft Learn more about using Microsoft SQL Server:   Using Azure SQL Database as the Persistence Provider   Step 2: Next Steps   Congratulations! You've successfully completed the Compare Persistence Providers guide. At this point, you can make an educated decision regarding which Persistence Provider is best suited for your ThingWorx application development environment.   Learn More   We recommend the following resources to continue your learning experience:    Capability    Guide Connect ThingWorx Application Development Reference Build Get Started with ThingWorx for IoT Experience Create Your Application UI   Additional Resources   If you have questions, issues, or need additional information, refer to:   Resource        Link Community Developer Community Forum Support Microsoft SQL Technical Support Support Persistence Provider Help Center
View full tip
This script finds an existing Expression Rule and applies it to an asset (via asset includes). Parameters: model - model name serial - serial number exprRuleName - name of the Expression Rule import static com.axeda.sdk.v2.dsl.Bridges.* import net.sf.json.JSONObject import com.axeda.drm.sdk.scripto.Request import com.axeda.services.v2.Asset import com.axeda.services.v2.AssetReference import com.axeda.services.v2.AssetCollection import com.axeda.services.v2.AssetCriteria import com.axeda.services.v2.ExpressionRule import com.axeda.services.v2.ExpressionRuleCriteria /* * ApplyExpRuleToAsset.groovy * * Finds an existing Expression Rule and includes an asset into it. * * @param model        -   (REQ):Str model of the asset. * @param serial        -   (REQ):Str serial number of the asset. * @param exprRuleName        -   (REQ):Str name of the Expression Rule. * * @author Sara Streeter <sstreeter@axeda.com> */ def response = [:] def root = [:] try {    AssetCriteria assetCriteria = new AssetCriteria()    assetCriteria.modelNumber = Request.parameters.model    assetCriteria.serialNumber = Request.parameters.serial    def findAssetResult = assetBridge.find(assetCriteria)    def asset = findAssetResult.assets[0]    ExpressionRuleCriteria expressionRuleCriteria = new ExpressionRuleCriteria()    expressionRuleCriteria.name = Request.parameters.exprRuleName    def expressionRuleFindResult = expressionRuleBridge.find(expressionRuleCriteria)    def expressionRule = expressionRuleFindResult.expressionRules[0]   def expAssets =  expressionRule.includedAssets.add(asset)   expressionRuleBridge.update(expressionRule)   response = [        "expressionRule":expressionRule.name,       "includedAsset": asset.serialNumber        ] } catch (Exception e) {      response = [             faultcode: 'Groovy Exception',             faultstring: e.message     ]; } return ["Content-Type": "application/json","Content":JSONObject.fromObject(response).toString(2)]
View full tip
    Step 9: File Transfer    To handle file transfers, create a virtual directory in the FileTransferExample Entity and in the project directory. The source code used for this example is found in com.thingworx.sdk.examples.FileTransferExample.java.   Set Up File Transfer   Right-click the project. Click New. Scroll and select Folder. Enter transfer/incoming into the text box at the bottom. Click Finish. Repeat steps 1 and 2, but create a folder called transfer/outgoing. Right-click the transfer/outgoing folder. Click New. Scroll and select File. Create a file with the name outgoing.txt. Click Finish. Once the outgoing.txt document is open, add the following text, click Save, and close the file: Hello. This is a file coming from the client application. Navigate to the FileTransferExample.java code and update the lines below with the appropriate information for your IP, port, and the admin_key Application Key’skeyId value in Composer: config.setUri("ws://127.0.0.1:80/Thingworx/WS"); config.setAppKey("ce22e9e4-2834-419c-9656-ef9f844c784c"); NOTE: Step 7 is only used for a time constraint of this guide. Best practice is to never use an Application Key for the Administrator. Provide a User with the necessary privileges and add an Application Key to that User.   FileTransferExampleHelper Methods   To support file transfers in your client application, you must use a FileTransferVirtualThing to enable the functionality and define the directories available for file operations. A virtual directory maps a unique name to an absolute path of a directory in the file system. All subdirectories of the specified directory are exposed to the server. You can define multiple virtual directories. The directories do not need to be contiguous.   The example provided creates the FileTransferVirtualThing with two virtual directories that will act as the root directories in the virtual file system of this application are added. The client is then started as follows:   All of the creations of the payloads have been moved to a helper class (FileTransferExampleHelper.java) to make the design cleaner.   The below table provides insight into some of the helper methods created to separate roles for a cleaner solution.   Method Purpose createSystemRepositoryIncomingPath Create the payload for the call to create the “incoming” directory on the SystemRepository in the ThingWorx Platform. createSystemRepositoryOutgoingPath Create the payload for the call to create the “outgoing” directory on the SystemRepository in the ThingWorx Platform. createTransferIncomingParameters Create the payload for the call to copy a file into the incoming directory on the FileTransferExample Thing in the ThingWorx Platform and the provided client application. createTransferOutgoingParameters Create the payload for the call to copy a file from the outgoing directory in the provided client application to the SystemRepository on the ThingWorx Platform.     Service Parameters   Once the connection is made, the script will call the four services. Here, we instruct the server to move the files from one repository to another.   Parameter Example Description sourceRepo “SystemRepository” The name of a FileRepository or RemoteThingWithFileTransfer Thing to transfer the file from. sourcePath “/outgoing” The path specifying the location in the file repository of the source file. sourceFile “example.txt” The name of the source file. targetRepo FileTransferExample The name of a FileRepository or RemoteThingWithFileTransfer Thing to transfer the file to. targetPath “in” The path specifying the destination location of the file. targetFile “example.txt” The name of the file at the target location. This name can differ from the sourceName parameter. timeout 15000 The amount of time to wait for the synchronous transfer to complete (seconds) before cancelling the transfer. async false If false, the service call will block for the length specified by the “timeout” parameter or until it completes.     After running this application, you will notice a new file in the transfer/incoming folder after refreshing. This is the file that we created in the ThingWorx Composer file system for the SystemRepository Entity and was copied from that location to our local project. We have also sent a file to the server’s SystemRepository. The BrowseFileSystem and GetFileListing Services can be used to check for the folders and files created.       Step 10: Troubleshooting   All Websocket errors indicate some general issue communicating with the ThingWorx platform. If you experience an issue connecting, refer to the table below for a list of websocket errors, their corresponding codes, and an explanation of the issue.   Code Message Troubleshooting 200 TW_UNKNOWN_WEBSOCKET_ERROR An unknown error occurred on the websocket. 201 TW_ERROR_INITIALIZING_WEBSOCKET An error occurred while initializing the websocket. Check your websocket configuration parameters for validity. 202 TW_TIMEOUT_INITIALIZING_WEBSOCKET A timeout occurred while initializing the websocket. Check the status of the connection to ThingWorx. 203 TW_WEBSOCKET_NOT_CONNECTED The websocket is not connected to ThingWorx. The requested operation cannot be performed. 204 TW_ERROR_PARSING_WEBSOCKET_DATA An error occurred while parsing websocket data. The parser could not break down the data from the websocket. 205 TW_ERROR_READING_FROM_WEBSOCKET An error occurred while reading data from the websocket. Retry the read operation. If necessary, resend the data. 206 TW_WEBSOCKET_FRAME_TOO_LARGE The SDK is attempting to send a websocket frame that is too large. The Maximum Frame Size is set when calling twAPI_Initialize and should always be set to the Message Chunk Size (twcfg.message_chunk_size). 207 TW_INVALID_WEBSOCKET_FRAME_TYPE The type of the frame coming in over the websocket is invalid. 208 TW_WEBSOCKET_MSG_TOO_LARGE The application is attempting to send a message that has been broken up in to chunks that are too large to fit in a frame. You should not see this error. 209 TW_ERROR_WRITING_TO_WEBSOCKET An error occurred while writing to the Web socket. 210 TW_INVALID_ACCEPT_KEY The Accept key sent earlier from ThingWorx is not valid.       Step 11: Tunneling Example    To handle file transfers, a virtual directory is created in the TunnelExample Entity and in the project directory. The source code used for this example is in com.thingworx.sdk.examples.TunnelExample.java.   To enable tunneling, create the configurations like other steps, and then either invoke ClientConfigurator.tunnelsEnabled(true), or set the tunnelsEnabled directive in your config file.   Once it connects to the server, this client binds thingName to the matching RemoteThingWithTunnels defined on the ThingWorx Platform. Once bound, the Thing can receive tunnel requests from the Platform, and facilitate tunnels to local applications.     Step 12: Next Steps    Congratulations! You've successfully completed the Java SDK Tutorial, and learned how to utilize the resources provided in the Java SDK create your own application.   The next guide in the Connect and Configure Industrial Devices and Systems learning path is C SDK Tutorial.   Learn More   We recommend the following resources to continue your learning experience:    Capability Guide Build Design Your Data Model Build Implement Services, Events, and Subscriptions   Additional Resources   If you have questions, issues, or need additional information, refer to:   Resource Link Community Developer Community Forum Support Java Edge SDK Help Center    
View full tip
This code snippet creates then deletes a data item to illustrate CRUD technique. Parameter:  model_number import com.axeda.drm.sdk.Context import com.axeda.drm.sdk.device.ModelFinder import com.axeda.drm.sdk.device.Model import com.axeda.drm.sdk.device.DeviceFinder import com.axeda.drm.sdk.data.CurrentDataFinder import com.axeda.drm.sdk.device.Device import com.axeda.drm.sdk.data.HistoricalDataFinder import groovy.xml.MarkupBuilder import com.axeda.drm.sdk.device.DataItem import com.axeda.drm.services.device.DataItemType /* * DeleteDataItem.groovy * * Delete a data item. * * @param model_number        -   (REQ):Str name of the model. * * @author Sara Streeter <sstreeter@axeda.com> */ def response = [:] def writer = new StringWriter() def xml = new MarkupBuilder(writer) try { // getUserContext is supported as of release 6.1.5 and higher     final def CONTEXT = Context.getUserContext() // find the model     def modelFinder = new ModelFinder(CONTEXT)     modelFinder.setName(parameters.model_name)     Model model = modelFinder.findOne() // throw exception if no model found     if (!model) {         throw new Exception("No model found for ${parameters.model_name}.")     } // Add a dummy data item DataItem dataitem = new DataItem(CONTEXT, model, DataItemType.STRING, "MyDataItem"); dataitem.store(); // find the data items on the model model.dataItems.each{     logger.info(it.name)     if (it.name=="MyDataItem"){         it.delete()     } } } catch (def ex) {       xml.Response() {     Fault {           Code('Groovy Exception')           Message(ex.getMessage())           StringWriter sw = new StringWriter();           PrintWriter pw = new PrintWriter(sw);           ex.printStackTrace(pw);           Detail(sw.toString())         }       } } return ['Content-Type': 'text/xml', 'Content': writer.toString()]
View full tip
Learn how to create a web application to monitor and control an Allen-Bradley PLC.   GUIDE CONCEPT   This guide will create a ThingWorx Foundation Mashup GUI to monitor and control an Allen-Bradley PLC connected via ThingWorx Kepware Server.   YOU'LL LEARN HOW TO   Create a Mashup Add Widgets Access backend data via Mashup Data Services Tie data to Widgets Create a simple web application that monitors and controls a PLC   NOTE:  The estimated time to complete all parts of this guide is 30 minutes.     Step 1: Learning Path Overview   Assuming you are using this guide as part of the Rockwell Automation Learning Path, then you have now completed each of the following installations:   Connected Components Workbench ThingWorx Kepware Server ThingWorx Foundation (for Windows)   You've also connected an Allen-Bradely PLC to Connected Components Workbench and then to ThingWorx Kepware Server.   You have propagated that information further from ThingWorx Kepware Server into Foundation.   In this final step, we'll create a simple Mashup to visualize the interface from Foundation to ThingWorx Kepware Server to the PLC.   NOTE: Both Rockwell Automation's Connected Components Workbench and ThingWorx Kepware Server are time-limited trials. If significant time has passed while persuing this Learning Path, you may need to reinitialize them. Consult the Troubleshooting step of this guide for more information.       Step 2: New Mashup   A Mashup is a Graphical User Interface (GUI) to interact with your application.   In this step, you will create a new, blank Mashup. You will later populate it with Widgets (graphical elements) and tie those elements to data.   In the top-left of ThingWorx Composer, click the Browse folder icon. Click VISUALIZATION > Mashups.   Click + New.   Select Responsive, then click OK. A new Mashup tab will open.     In the Name field, enter RWLP_Mashup. If Project is not already set, click the + in the Project text box and select the PTCDefaultProject. At the top, click Save.     Step 3: Add Widgets   Widgets are drag-and-drop, stand-alone, graphical elements which you can add to your Mashup to represent certain pieces of backend data.   In this step, you will add a pair of Checkboxes to represent the PLC functionality.   At the top of the RWLP_Mashup tab, click Design. It may take a few moments for the Mashup Builder interface to load.     Click The Widgets tab, then In the Filter field on the left, enter check. Drag-and-drop a Checkbox widget onto the central Canvas area.   Drag-and-drop a second Checkbox onto the Canvas.   At the top, click Save.     Step 4: Add Data    To have the Checkbox Widgets actually interact with the PLC, you need to bind them to the backend data.   To do so, you will make use of a Mashup Data Service from the previously-created PLCcoils Thing. At the top-right, click the Data tab, then click the + symbol.   In the Add Data pop-up window, enter plc in the Entity Filter search box.   Select the PLCcoils Thing. In the Services Filter search box, search for getprop.   Click the right arrow to select GetProperties. Check the box for Execute on Load under Selected Services. This causes the Service to be automatically executed upon the Mashup being loaded. In the Services Filter search box, search for setprop. Click the right arrow to select SetProperties. Note that you should keep Execute on Load un-checked for this Service, as we do NOT want it to automatically execute on Mashup load.     Click Done, then click the > to expand both GetProperties and SetProperties.   At the top, click Save.     Click here to view Part 2 of this guide.
View full tip
The intend of this post. This post is for the user who want to validate that, the ThingWorx Analytics Services related to Confidence Models work successfully. Underneath video walk through the steps to validate the Services via a non-supported PTC Mashup. The intend of this video is uniquely to validate that, Services related to Confidence Models works successfully.  What package files are used in the video? The Mashup entities and dataset used in the video, is attached to this post. Feel free to download the files and test on your machine. Why use Confidence Models? A confidence model is a way of adding confidence interval information to a predictive model. Statistically, for a given prediction, a confidence model provides an interval with upper and lower bounds, within which it is confident, up to a certain level, that the actual value occurs. During predictive scoring, this measure of confidence provides additional information about the accuracy of the prediction. More information about Confidence Models can be found here at PTC Help Center 
View full tip
Hi all,   Here is the recording of the expert session hosted in August 25th. For full-sized viewing, click on the YouTube link in the player controls.
View full tip
Applicable Releases: ThingWorx Platform 7.0 to 8.5   Description:   Introduction to Edge connectivity in Thingworx Foundation: Edge concept and definition Available edge products Why use Edge products What is Edge Microserver and Lua Script Resource What are the SDKs What are connection servers AlwaysOn and HTTP protocols ThingTemplates to connect remote devices     The session was recorded in an old ThingWorx version, but all the concepts are still applicable
View full tip
  Step 7: Delivery Truck Model    In the Delivery Truck application, there are three Delivery Truck Things. Each Thing has a number of Properties based on its location, speed, and its deliveries carried out. In this design, when a delivery is made or the truck is no longer moving, the property values are updated. The DeliveryTruckThing class extends the VirtualThing class and based on the DeliveryTruck Entities in the Composer. After extending VirtualThing, there are a number of steps necessary to get going. For the DeliveryTruckThing and SimpleThing classes, there are a number of methods for creating Properties, Events, Services, and Data Shapes for ease of use.   The constructor for the DeliveryTruckThing takes in the name of the Thing, the description of the Thing, and the ConnectedThingClient instance used to make the connection. It then sends these values to the VirtualThing constructor as shown below.   public DeliveryTruckThing(String name, String description, ConnectedThingClient client) { super(name, description, client); ...   We use the initializeFromAnnotations method to initialize all of the annotations that we will create in this class. This is done as follows and a necessary call for VirtualThings in the constructor:   initializeFromAnnotations();   Create Properties   You can create Properties in two ways. Using annotations is the recommended method, but there are times in which programmatically creating Properties is the best option. For example, constructing dynamic features or allowing inline functionality would call for the coding style of Property creation. The following shows the Properties that correlate to those in the DeliveryTruck Entities in the Composer. To do this within the code, you would use a PropertyDefinition instance as shown in the SimpleThing.java property1 creation.   With Annotation @SuppressWarnings("serial") @ThingworxPropertyDefinitions(properties = { @ThingworxPropertyDefinition(name="Driver", description="The name of the driver", baseType="STRING", aspects={"isReadOnly:false"}), @ThingworxPropertyDefinition(name="DeliveriesLeft", description="The number of deliveries left", baseType="NUMBER", aspects={"isReadOnly:false"}), @ThingworxPropertyDefinition(name="Speed", description="The speed of the truck", baseType="NUMBER", aspects={"isReadOnly:false"}), @ThingworxPropertyDefinition(name="Location", description="The location of the truck", baseType="LOCATION", aspects={"isReadOnly:false"}), @ThingworxPropertyDefinition(name="TotalDeliveries", description="The number of deliveries", baseType="NUMBER", aspects={"isReadOnly:false"}), @ThingworxPropertyDefinition(name="DeliveriesMade", description="The number of deliveries made", baseType="NUMBER", aspects={"isReadOnly:false"}), })   Without Annotation //Create the property definition with name, description, and baseType PropertyDefinition property1 = new PropertyDefinition(property, "Description for Property1", BaseTypes.BOOLEAN); //Create an aspect collection to hold all of the different aspects AspectCollection aspects = new AspectCollection(); //Add the dataChangeType aspect aspects.put(Aspects.ASPECT_DATACHANGETYPE, new StringPrimitive(DataChangeType.NEVER.name())); //Add the dataChangeThreshold aspect aspects.put(Aspects.ASPECT_DATACHANGETHRESHOLD, new NumberPrimitive(0.0)); //Add the cacheTime aspect aspects.put(Aspects.ASPECT_CACHETIME, new IntegerPrimitive(0)); //Add the isPersistent aspect aspects.put(Aspects.ASPECT_ISPERSISTENT, new BooleanPrimitive(false)); //Add the isReadOnly aspect aspects.put(Aspects.ASPECT_ISREADONLY, new BooleanPrimitive(false)); //Add the pushType aspect aspects.put("pushType", new StringPrimitive(DataChangeType.NEVER.name())); //Add the defaultValue aspect aspects.put(Aspects.ASPECT_DEFAULTVALUE, new BooleanPrimitive(true)); //Set the aspects of the property definition property1.setAspects(aspects); //Add the property definition to the Virtual Thing this.defineProperty(property1);   Property values can either be set with defaults using the aspects setting. Nevertheless, setting a default value will affect the Property in the ThingWorx platform after binding. It will not set a local value in the client application. In this example, we make a request to the ThingWorx Composer for the current values of the delivery truck properties using our getter methods:   //Get the current values from the ThingWorx Composer deliveriesMade = getDeliveriesMade(); deliveriesLeft = getDeliveriesLeft(); totalDeliveries = getTotalDeliveries(); driver = getDriver(); speed = getSpeed(); location = getLocation();   Create Event Definitions   As with Properties, Events can be created using annotations or code as shown in SimpleThing.java. Here we create the DeliveryStop event that is in the DeliveryTruck instances.   With Annotation @ThingworxEventDefinitions(events = { @ThingworxEventDefinition(name="DeliveryStop", description="The event of a delivery truck stopping to deliver a package.", dataShape="DeliveryTruckShape", isInvocable=true, isPropertyEvent=false) })   Without Annotation //Create the event definition with name and description EventDefinition event1 = new EventDefinition(event, "Description for Event1"); //Set the event data shape event1.setDataShapeName("SimpleDataShape"); //Set remote access event1.setLocalOnly(false); //Add the event definition to the Virtual Thing this.defineEvent(event1);   Create Remote Services   With remote Services, the implementation is handled by the Java application and can be called either within the application or remotely, by the Composer while a connection is established. The GetTruckReadings Service, a dummy Service used as an example of how to create a remote Service, populates an Info Table and returns that Info Table for whoever would like to use it. You can see how it is possible to define remote Services that can later be bound to Things in the Composer. A Service is defined using @ThingworxServiceDefinition annotation and its result is defined using @ThingworxServiceResult. These annotations take various parameters among including:   Name Description baseType Aspects In the second line, you can see the name of the result being set by the CommonPropertyNames field to keep development consistent with creating Things in the Composer.   With Annotation @ThingworxServiceDefinition(name="GetTruckReadings", description="Get Truck Readings") @ThingworxServiceResult(name=CommonPropertyNames.PROP_RESULT, description="Result", baseType="INFOTABLE", aspects={"dataShape:DeliveryTruckShape"})   Without Annotation //Create the service definition with name and description ServiceDefinition service1 = new ServiceDefinition(service, "Description for Service1"); //Create the input parameter to string parameter 'name' FieldDefinitionCollection fields = new FieldDefinitionCollection(); fields.addFieldDefinition(new FieldDefinition("name", BaseTypes.STRING)); service1.setParameters(fields); //Set remote access service1.setLocalOnly(false); //Set return type service1.setResultType(new FieldDefinition(CommonPropertyNames.PROP_RESULT, BaseTypes.STRING)); //Add the service definition to the Virtual Thing this.defineService(service1); //Service1 Definition public String Service1(String name) throws Exception { String result = "Hello " + name; return result; }     Create Data Shapes   Data Shapes must be created using code as seen in DeliveryTruckThing.java as shown below:   // Data Shape definition that is used by the delivery stop event // The event only has one field, the message FieldDefinitionCollection fields = new FieldDefinitionCollection(); fields.addFieldDefinition(new FieldDefinition(ACTIV_TIME_FIELD, BaseTypes.DATETIME)); fields.addFieldDefinition(new FieldDefinition(DRIVER_NAME_FIELD, BaseTypes.STRING)); fields.addFieldDefinition(new FieldDefinition(TRUCK_NAME_FIELD, BaseTypes.BOOLEAN)); fields.addFieldDefinition(new FieldDefinition(TOTAL_DELIVERIES_FIELD, BaseTypes.NUMBER)); fields.addFieldDefinition(new FieldDefinition(REMAIN_DELIVERIES_FIELD, BaseTypes.NUMBER)); fields.addFieldDefinition(new FieldDefinition(LOCATION_FIELD, BaseTypes.LOCATION)); defineDataShapeDefinition("DeliveryTruckShape", fields);   NOTE: It is possible to create a Data Shape, and then use it in a Service definition within your code as StringIndex property, StringMap Data Shape, and StringMapService Service in SimpleThing.java.     Scan Cycles   To complete the implementation of the VirtualThing class, we recommend you provide an override and implementation to the processScanRequest method. This method provides a universal method for all VirtualThing implementations. This method could be used or a new method could be created for this purpose. The processScanRequest method in VirtualThing.java does not have an implementation of its own. An implementation from DeliveryTruckThing.java can be seen below:   // The processScanRequest is called by the DeliveryTruckClient every scan cycle @Override public void processScanRequest() throws Exception { // Execute the code for this simulation every scan this.scanDevice(); this.updateSubscribedProperties(1000); this.updateSubscribedEvents(1000); }   Bound Properties in Cycle   The scanDevice method in DeliveryTruckThing.java performs a number of tasks from retrieving property values to firing events. To retrieve a property using binding, a request is made to the client using the name of the property. A good programming practice is to handle how these properties are accessed and set. Note that the update method for properties and events must be used after queueing an event or setting a Property value. In the example below, getter and setter methods are used for added control. The getProperty() call is used on the VirtualThing:   public Double getSpeed() { return (Double) getProperty("Speed").getValue().getValue(); } public void setSpeed() throws Exception { setProperty("Speed", this.speed); } public Location getLocation() { return (Location) getProperty("Location").getValue().getValue(); } public void setLocation() throws Exception { setProperty("Location", this.location); }     Step 8: Services and Events   Events and Services can be very useful. Events are a good way to make a Service be asynchronous. You’re able to call a Service, let it return and then your Entity can subscribe to your Event and not keep the original Service function waiting. Events are also a good way to allow the platform to respond to data when it arrives on the edge device without it having to poll the edge device for updates. The DeliveryTruck Entities in the Composer contains a remote Event. You can find a remote Service within the SimpleThing_1 entity.   Fire Event To fire an Event, create a ValueCollection instance, and load it with the necessary fields for the Data Shape of that Event. Then, send the client the request to fire the Event with the collected values, the Event, and information to find the Entity the Event belongs to as shown below in DeliveryTruckThing.java:   // Set the event information of the defined data shape for a truck stop event ValueCollection payload = new ValueCollection(); // Set values to the fields payload.put(LOCATION_FIELD, new LocationPrimitive(location)); payload.put(REMAIN_DELIVERIES_FIELD, new NumberPrimitive(deliveriesLeft)); payload.put(ACTIV_TIME_FIELD, new DatetimePrimitive(DateTime.now())); payload.put(TOTAL_DELIVERIES_FIELD, new NumberPrimitive(totalDeliveries)); payload.put(DRIVER_NAME_FIELD, new StringPrimitive(driver)); payload.put(TRUCK_NAME_FIELD, new StringPrimitive(super.getBindingName())); // This will trigger the 'DeliveryStop' of a remote thing // on the platform. super.queueEvent("DeliveryStop", new DateTime(), payload);   Execute Service   To execute a Service, you must create a ValueCollection instance, and load it with the necessary parameters of the Service. The ValueCollection is created only when Services and Events are not defined by annotations. Afterwards, you would send the client the request to execute the Service with the parameter values, the Service name, the timeout setting in milliseconds for the Service to finish executing, and information to find the Entity the Service belongs to as shown below in SimpleThingClient.java:   public String callService(String name) throws Exception{ ValueCollection payload = new ValueCollection(); payload.put("name", new StringPrimitive("Timothy")); InfoTable table = handleServiceRequest(service, payload); return table.getFirstRow().getStringValue("name"); }   TIP: The code for creating the Service and Event should be in the constructor of the extended VirtualThing (or a method called from the constructor). Also, the Service code examples will work as long as the actual Service is defined. You can see from the examples that the annotation method is much cleaner.     Click here view Part 5 of this guide.
View full tip
Good evening and Happy New Year!   I launched version 2.3.0 of the GitBackup Extension.  The release is available here https://github.com/vrosu/thingworx-gitbackup-extension/releases/tag/V2.3.0   It adds the capability to push commits using User specific Committer Name and Email. This is an optional feature, which allows multiple developers to push commits under their own credentials. The documentation was updated with more details about this.   This release certifies the Extension to work for ThingWorx 8.5.x. (Previous ThingWorx versions have not been tested and the documentation was updated accordingly).    As always, this extension is not a PTC supported product, so in case you have issues with it, please do not open a PTC Tech Support ticket and instead use GitHub's issue system or the PTC Community.   Please feel free to fork and improve it.
View full tip
This video shows the steps to install ThingWorx Analytics Server 8.5.1 as well as the ThingWorx Analytics Extension.  
View full tip
Applicable Releases: ThingWorx Navigate 1.8.0 to 1.9.0     Description:   New improvements of the ThingWorx Navigate Installer with the following agenda: What's new Load Balancer Multiple Windchill Systems Integration Runtime NSSM How to select files to download Installer installation steps Demo Questions         Additional information How to install PTC Navigate
View full tip
  Step 5: Import Extension   Now that we have a valid dataset, we want to export it as a .csv file, which can be imported into ThingWorx Analytics in a future guide to generate an analytical model.   An easy way to do this is with the CSV Parser Extension, which you’ll now import.       1. Download the CSV Parser Extension from our third party provider IQNOX.   Note:  An account is required but the download is free.     2. At the bottom-left, click Import/Export.       3. On the drop-down, click Import.       4. For Import Option, select Extension.       5. Click Browse and navigate to the extension you downloaded above.       6. Click Open.       7. Click Import.       8. Click Close.       9. On the Refresh Composer? pop-up, click Yes.      Step 6: Create File Repository   ThingWorx Foundation uses File Repositories to read and write files from disk (including .csv files created by the CSV Parser Extension).   In this step, we’ll create a File Repository Entity.       1. Return to Browse > All.       2. Click MODELING > Things.       3. Click + New.       4. In the Name field, type ESDS_File_Repository.       5. If Project is not already set, search for and select PTCDefaultProject.       6. In the Base Thing Template field, search for and select FileRepository.      7. At the top, click Save.        Step 7: Create .csv Export Service   We have imported an Extension which gives us tools to manipulate .csv files. We have created a File Repository to which the export can save the file. We'll now make use of some of this new functionality.    We’ll do so by creating a Service which calls built-in functions of the CSV Parser Extension.       1. Return to EdgeThing.       2. Click Services.       3. Click + Add.       4. On the drop-down, select Local (JavaScript).       5. In the Name field, type exportCSVservice.       6. In the blank JavaScript field, copy-and-paste the following code:           var sFile = "vibrationCSVfile.csv"; var paramsCSV = { path: sFile, data: me.infoTableProperty, fileRepository: "ESDS_File_Repository", withHeader: true }; Resources["CSVParserFunctions"].WriteCSVFile(paramsCSV);               7. Click Save and Continue. Note that you should NOT click the top Save button, as that will erase your Service.         Step 8: Export the Engine Data   We now have all the tools in place to export the infoTableProperty as a .csv file to our new File Repository.   All that’s left is to call the appropriate functions.       1. Ensure that you’re still on the Services tab of EdgeThing, and have the exportCSVservice open.       2. At the bottom, click Execute.       3. Return to ESDS_File_Repository.       4. Click Services.       5. Scroll down and find the GetFileListingsWithLinks Service.       6. Click the “Play” icon for Execute service.       7. At the bottom-right, click Execute.       8. On the right, click Thingworx/FileRepositories/ESDS_File_Repository/vibrationCSVfile.csv.     9. The .csv export of the vibration data will now be in your local folder to which your browser saves downloads.       Step 9: Next Steps   Congratulations! You've completed the Engine Simulator Data Storage guide, and learned how to:   Create a Timer Subscribe to a Timer to Trigger a Service Generate Mass Amounts of Test Data Import the CSV Parser Extension Create a File Repository Export the Test Data as a Comma-Seperated Values (.csv) file Download from a File Repository   The next guide in the Vehicle Predictive Pre-Failure Detection with ThingWorx Platform learning path is Build an Engine Analytical Model   Learn More   We recommend the following resources to continue your learning experience:   Capability Guide Analyze Build a Predictive Analytics Model Build Implement Services, Events, and Subscriptions   Additional Resources   If you have questions, issues, or need additional information, refer to:        Resource Link Community Developer Community Forum Support Analytics Builder Help Center
View full tip
Announcements