IoT & Connectivity Tips

As many already know, ThingWorx versions 8.0+ now support both Apache Tomcat versions 8.0.44+ and versions of 8.5.13+. For this reason, many will want to consider using the latest Apache version for their ThingWorx instance, even despite the fact that the installation documentation does not seem to provide examples for the 8.5.x versions. This is because much of the configuration between the two versions remains the same. One may question these similarities when looking at the updated documentation from Apache on configuring SSL Connector ports. It would seem like some of the more traditional elements are now unusable, since they are marked for deprecation (including keystoreFile, keystorePass, and clientAuth). However, for now, these elements are still usable because Tomcat will convert whatever is provided in the Connector tag to the brand new SSLHostConfig tag (used primarily by Tomcat going forward). Apache has noted that these configuration options will continue to be usable throughout the next few major versions of Tomcat. PTC is already working on documentation which helps utilize the new configuration options in the future, but it won't be available for some time. In the meantime, for step-by-step instructions and further reading, see our Knowledgebase Article using self-signed certs (this article uses a CA). Happy developing!

This post is part of the series Forced Root Cause Monitoring via Mashups and Modal Popups To not feel lost or out of context, it's recommended to read the main post first. Required Logic The following logic will help us realizing this particular use case: The trigger property on the AlertThing switches from false to true. The MashupMain will receive dynamic Property updates via the AlertThing.GetProperties service. It will validate the value of the trigger Property and if it's true the MashupMain will show the MashupPopup as a modal popup. A modal popup will be exclusively in the foreground, so the user cannot interact with anything else in the Mashup except the modal popup. In the modal popup the user chooses one of the pre-defined AlertStateDefinitions. When a State is selected, the popup will set the State as a Mashup Parameter, pass this to the MashupMain and the popup close itself. When the MashupPopup is closed, the MashupMain will read the Mashup Parameter The MashupMain will set the selectedReason in the AlertThing to the selected value. It will also reset the trigger property to false. This allows the property to be set to true again to trigger another forced popup. On any value change the AlertThing will store the selectedReason State in a ValueStream to capture historic information on which root causes were selected at which time. The ValueStream information will be displayed as a table in a GridWidget in the MashupMain once the new properties have been set.

Checkout the below video which explores the Creo As A Service (CAAS) feature of the Product Insight extension. This allows to retrieve Creo analysis computation inside ThingWorx through the Analytics Manager framework.  

Recording of the Friday, November 17, 2017 ThingWorx Manufacturing Tips & Tricks Web Session. Agenda: - Overview & Application Demo - Aron Semle - Architecture Overview - Varathan Ranganathan - Q&A

The long-awaited manufacturing solution,  ThingWorx Digital Performance Management (DPM), has arrived! Announced at PTC’s  Manufacturing Live event, DPM provides key use cases around overall equipment effectiveness and real-time performance monitoring, while delivering insights with analytics and automated bottleneck identification tools. DPM gives customers clear insight into where and what to fix to drive efficiencies. Composed of modular building blocks with a foundation on the ThingWorx platform, DPM is easily configurable and customizable for closed-loop problem solving that drives productivity.   Let’s take a deeper look into what DPM is and how you can implement it to ensure your investment in the ThingWorx platform and digital transformation delivers business impact.   Monitor in real-time with Production Dashboard The Production Dashboard allows for automated or manual data entry of reason codes with a simple interface for limited disruption. Rather than providing front-line workers with the typical, difficult to understand, percentage based KPIs, Production Dashboard standardizes all losses, so operators can proactively resolve issues during production. You can configure this dashboard to collect granular data and allow opportunities for continuous improvement in process tracking.     Focus with Bottleneck Analysis Bottleneck analysis automatically identifies bottlenecks across the manufacturing process. Identifying bottlenecks can help you prioritize the highest-impact opportunities in the business process. This saves you having to manually identify and analyze potential issues and frees you up to work on other projects.   Prioritize with Time Loss Waterfall and Analyze with Loss Reason Pareto Monitor and analyze performance with data visualizations that help you pinpoint root causes and suggest improvements. Bring together your siloed data into one system and create a standard for how performance is measured and reported.   Improve with Action Tracker Action Tracker allows you to create continuous improvement actions tied to real production losses, to ensure your actions are having positive impact and return.  Create a digital workspace for teams to collaborate and learn from each other. Plus, you can track the improvements delivered through each individual action, so you can drill down and create transparency of work being done.   Confirm value delivered with Scorecard (Available in Later Versions) With the Scorecard feature, you can leverage a standard scorecard for enterprise wide KPIs to summarize factory health and compare similar factory operations. Use the scorecard to create trending and reporting that can be filtered based on the audience you are presenting data to. The scorecard gives you a consistent view that measures performance across the network and drives visibility and accountability across your business.   How do you plan to leverage DPM or the building blocks that make it up? We’d love to hear your thoughts on the first manufacturing solution from PTC.   Stay connected, Rachel   

This post is part of the series Forced Root Cause Monitoring via Mashups and Modal Popups To not feel lost or out of context, it's recommended to read the main post first. Testing the Mashups Open the rcp_MashupMain in a new browser window For this test I find it easier to have the rcp_AlertThing and the Mashup in two windows side-by-side to each other The Mashup should be completely empty right now Nothing in the historic table (Grid) The Selected Reason is blank The Checkbox is false In the rcp_AlertThing switch the trigger to false The following will now happen The new value will be automatically pushed to Mashup The checkbox will switch to true The validator now throws the TRUE Event, as the condition is met and the trigger is indeed true The TRUE Event will invoke the Navigation Widget's Navigate service and the modal popup will be opened The user now only has the option to select one of the three states offered by the Radio Button selector, everything else will be greyed out After choosing any option, the SelectionChanged Event will be fired and trigger setting the selectedState as well as closing the popup The PopupClosed Event in our MashupMain will then be fired and populate the selectedState parameter into the textbox (just for display) and will also call the SetProperties service on our Thing, updating the selectedReason with the selectedState parameter value Once the property is set and persisted into the ValueStream via the SetProperties' ServiceInvokeCompleted Event, we clear the trigger (back to false) and update the Grid with the new data In the AlertThing, refresh the properties to actually see the trigger false and the selectedReason to whatever the user selected Note: When there is a trigger state and the trigger is set to true the popup will always be shown, even if the user refreshes the UI or the browser window. This is to avoid cheating the system by not entering a root cause for the current issue. As the popup is purely depending on the trigger flag, only clearing the flag can unblock this state. The current logic does not consider to close the popup when the flag is cleared - this could however be implemented using the Validator's FALSE Event and adding additional logic

When we do connections to JDBC connected databases, as much as possible we want to leverage the Database Server side capabilities to do the querying, aggregating and everything else for us. So if we need to do filtering or math add it to the query statement so it is done server side, by the Database server not the Thingworx runtime server. Besides that there is much more that can be done, since databases are powerful (all the good stuff like joins, union, distinct, generated and calculated fields and what not) The more we can do Database server side the better it is for the Thingworx runtime performance. Now everyone hopefully knows the [[  ]] parameter substitution. So we can easily build an SQL service that has several input parameters, it will look like: Select * from table where item1=[[par1]] AND item2 =[[par2]] etc. But we can take this up a notch with the super powerful yet super dangerous <<   >> Now we can do a service that just says <<sqlQuery>> and use another service to build something like: select * from table where item1 in “val1,val2,val3” etc. If you can avoid it, only use [[  ]] but if needed there always is <<   >> but you must make sure that you properly secure that service with the system user and validate the service that invokes this service, since <<  >> is vulnerable to SQL Injection

Applicable Releases: ThingWorx Platform 7.0 to 8.4   Description:   A practical example of how to build a data model in ThingWorx following a pre-defined design Following topics are covered: Review existing Design Plan Build all required entities in ThingWorx Composer Test the model and review scalability and reusability         The session was recorded using the old ThingWorx Composer, but the concepts are still applicable Related Success Service - Principles of Thingworx Modeling Related Service - Design your Thingworx Model

  ThingWorx Dev Portal users,    As you may have heard in prior communication, the ThingWorx Dev Portal  Developer Portal | Developer Portal : ThingWorx is being retired.         All ThingWorx Dev Portal content will remain accessible until September 28, 2022. Your favorite and the most useful ThingWorx Dev Portal content will be copied into the PTC Community  in our IoT Tips board.  The Community Team is in the process of making changes to all our “Community Tips” boards.        Subscribe and watch for an official announcement on our Community Announcements board about the change. The Community Tips Board changes go into effect on September 1st.  You can preview the ThingWorx Developer Portal content being migrated here.   Please let us know if you have any questions. 

  Hi everyone,   This week, Anthony Moffa returns to Ask Kaya in a different form from his original appearance explaining the benefits of Thing Presence in ThingWorx. As much as we enjoy reading Anthony in print, you can now hear from the man himself in the “Moffa Monitoring Minute!”   Listen to Episode 04 of “ThingWorx on Air” as he explains what Asset Advisor is and how you can use it to remotely monitor assets, shorten service cycles, and improve visibility of your device fleet.   Want to learn even more about Asset Advisor? Check out this video or read through our website!   Reach out with any questions and just Ask Kaya!   Stay connected, Kaya

This video begins Module 9: Anomaly Detection of the ThingWorx Analytics Training videos. It describes how Thingwatcher can be set up to monitor values streaming from connected assets, and send an alert if its behavior deviates from its 'normal' behavior.

Often times to set up our environment securely, we will assign Entity Type permissions, which is much easier then to remember to assign it to every single ThingShape, ThingTemplate, Thing etc. However did you know that these security settings only export when doing an Export to ThingworxStorage? So you either must maintain a list of these settings and re-apply them when starting on a new environment or: 1. Set up your Groups (and Users although hopefully all permissions you set up are assigned to Groups as a Best Practice) 2. Set up your Entity Type Permissions 3. Create an Export using Export to ThingworxStorage and export everything Now you have an import ready any time you need to deploy Thingworx anew. NOTE: Obviously this means you need to maintain that export any time changes are made to those permissions, unfortunately that also means another export of ALL which can be less desirable, since it can include Test objects unfinished items etc. As such one may have to maintain some local instance to keep a clean Import/Export.

…to ENTERPRISE Increase company profit and revenue along with customer value Achieve sustainable competitive advantage …to SERVICE ORGANIZATION Understand your equipment performance and condition through remote monitoring Improve first-time fix rates by incorporating connected product data Reduce onsite service visits Increase service profitability …to CUSTOMER Improve product and service outcomes Increase equipment uptime Increased customer satisfaction 20% Improvement in equipment uptime 15-25% Reduction in onsite service visits 5-20% Improvement on first time fix rate

In the last while I've seen a few things which got me thinking about how value is created or unlocked from connected data.  Multiple components are required to create, send, store and manage the data created by edge devices, doing these things enables value to be unlocked, but what does it take to unlock the value? It was this ​article which first got me interested in considering this question.  In particular it was a section near the bottom of the article where the author describes a number of creative business use cases for car manufacturers which could be enabled by connected data.  If this author could come up with several creative and potentially valuable use case examples for one industry I started to wonder what other sorts of use cases could exist in other industries?  Could there be a series of use of use cases which a little variation be applied to different industries? The second article which further sparked my interest in where the value originates from, is this one​ on using a cryptocurrency with IOT.  While the idea of using a blockchain like technology with IOT is intriguing, it was the second image in the article (below) which resonated with me on value.  This image is a graphical representation of the connection between the key components of a connected system and it makes it clear that each component has a critical role to play and the whole system and missing anyone of the parts and the system doesn't function.  This image make it clear that it's the "Analyze" phase which drives the action to do something, and it's taking an action which is the reason the systems reason for existing.    Which brings me to the third and final article describing Industry 4.0.  Like the other two articles, it wasn't the main point of the article I found most interesting, rather it was the image below, and in particular the side bar 'Value Creation through' which brought me back to the question of where value comes from.  The idea that in a manufacturing setting, value can be created through product or process innovations as well as through new business models is intriguing.  I think a fourth idea missing from this list, is one were network effects from getting more and more proprietary data creating a compounding effect, like with Facebook or LinkedIn.  If there are at least four modes of value creation, maybe there others? While these articles caused me to ask some questions, none of them really answered the question of where the value is unlocked. To answer the question I decided to restate the question to be "how is value unlocked from data" making the assumption the value is derived from the data.  This question is a little easier to address.  The best visual representation of the answer I've seen is the data value road map (below) from the Creating a Data-Driven Organization book which was released a couple of years ago.  While I think the author is probably missing at least two boxes above 'optimization' ("new business models" and "data driven network effects") I think the graphic does a good job communicating that as the value created from data increases, the complexity of the analytic task also increases; suggesting the value is unlocked by the analytics.  For me, the value from a system of connected devices is unlocked from the "analysis" phase as seen in the first image. But in order to perform the "analysis" I think requires two things.  First asking the right high value questions of the data (product managers/beginning with the end in mind/use cases) and then using the right set of technologies to address those questions which in many instances means Artificial Intelligence of some sort.  Interestingly although artificial intelligence is required for many high value use cases, both parts of the analysis require distinctly human skills (the right use cases & controlling the technology) to create externalized intelligence and generate value. Creating a Data-Driven Organization: Practical Advice from the Trenches 1, Carl Anderson, eBook - Amazon.com

I got this excellent question and I thought it worthwhile to put my answer here as well.   There are two ways to segregate information between clients. By default we use a ‘software’ approach to segregation by using Organizations. This allows you to designate a Client to an Organization/Organizational nodes and give those nodes ‘visibility’ to specific entities within the software. This will mean that ‘through software logic’ users can only see what they’ve been given visibility to see. This mainly applies to all the client’s equipment (Thingworx Things). They can only see their own equipment. This would also apply to a specific set of their data which is ValueStream data because that can only be retrieved from the perspective of a Thingworx Thing   Blog/Wiki/DataTable/Streams can store data across clients and do not utilize visibility on a row basis, in this case appropriate queries would need to be created to allow retrieval for only a specific client. In this case we use a construct for security that utilizes what we call the ‘system user’ and wrapper routines that work of the CurrentUser context, this allows you to create enforced validated queries against the data that will allow a user to only retrieve their specific data.   In regards to the data itself, if you need to, you can provide actual ‘physical’ segregation by using multiple persistence provider and mapping Blog/Wiki/DataTable/Streams/ValueStreams to different persistence providers. Persistence providers are basically additional database schemas (in one and the same database or different database) of the Thingworx data storage schema, allowing you to completely separate the location of where data is stored between clients. Note that just creating unique Blog/Wiki/DataTable/Streams/ValueStreams per client and using visibility is still only a logical / software way of providing segregation because the data will be stored in one and the same database schema also known as the Thingworx data persistence provider.

This article https://support.ptc.com/appserver/cs/view/solution.jsp?n=CS264270 and the blog post provide information on the technical changes in Thingworx 8.0, New Technical Changes in ThingWorx 8.0.0 Here are some common questions and answers in regards to the change. Is there any way that one could lose access to the Appkey keystore? (restore a backup, etc) Yes, it is possible to  lose the key store. If one for some reason simply deletes it or renames it, the existing application keys would no longer be able to be decrypted - thus unusable. Is there a way to back up the appkey store and any necessary secrets such that it can be recovered then? Yes, but this would be handled at the file system, not inside of ThingWorx. We do have some best practices documented for managing the keystore. For developers who configure Edge applications and Connectors to connect to the platform, where do they copy the app key from? Are they copyring the encrypted version of the app key? They would do the same as before. We are not encrypting the app key in the UI, only on disk. Is there any way to get a summary of appkeys that are being used via URL? We do have some requirements for highlighting "repeat offenders". In 8.0, one can query the logs to find those app keys. We don't log the app key id, only the app key name.

This Groovy script is called from an ExpressionRule of type Alarm. For example, in an Expression rule IF: Alarm.severity > 500 THEN: ExecuteCustomObject("SMSMe", "[numberToSMS]")    calls the script "SMSMe" with the parameter phoneNumber.  The ExecuteCustomObject provides a way to call from this simple two-line business rule into a modern programming environment with access to the complete Platform SDK, as well as all the features of the Groovy language.  In Groovy, it's straightforward to use the built-in httpclient library to POST an HTTP request to Twilio to send an SMS to the specified cellphone number. Groovy Scripts The groovy script named SMSMe is executed by the Expression Rule above and connects to the Twilio Server passing in a list of parameters. When you register with Twilio, you will be given an ACCOUNT SID (apiID) and an AUTH TOKEN (apiPass). These two strings need to be in the Groovy Script below: String apiID = 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX'  String apiPass = 'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA'     Parameters Variable Name      Display Name phoneNumber      phoneNumber import org.apache.commons.httpclient.Credentials import org.apache.commons.httpclient.HostConfiguration import org.apache.commons.httpclient.HttpClient import org.apache.commons.httpclient.UsernamePasswordCredentials import org.apache.commons.httpclient.auth.AuthScope import org.apache.commons.httpclient.methods.GetMethod import org.apache.commons.httpclient.methods.PostMethod import org.apache.commons.httpclient.NameValuePair //logger.info "Calling ${parameters.phoneNumber}" String twilioHost = 'api.twilio.com' String apiID = 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX' String aipPass = 'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA' HostConfiguration hc = new HostConfiguration() hc.setHost(twilioHost, 443, "https") def url = "/2008-08-01/Accounts/$apiID/SMS/Messages" def client = new HttpClient() Credentials defaultcreds = new UsernamePasswordCredentials(apiID, aipPass) client.getState().setCredentials(null, null, defaultcreds) PostMethod post = new PostMethod(url); post.addParameter 'IfMachine', 'Continue' post.addParameter 'Method', 'POST' post.addParameter 'From', '[YourNumber]' post.addParameter 'To', parameters.phoneNumber post.addParameter 'Body', 'This is an SMS from Axeda' client.executeMethod(hc, post); //logger.info message = "Status:" + post.getStatusText() //logger.info post.getResponseBodyAsString() post.releaseConnection();   

What is Meltdown and Spectre? Windows KB Page Blog on Altaro containing  some performance tests with pre/post-patch machines https://www.altaro.com/hyper-v/meltdown-spectre-hyperv-performance/ For any further information about PTC’s reaction to the Meltdown&Spectre, please reference this link:  https://www.ptc.com/en/support/article?n=CS277711

Improvements in Monitoring and Diagnostics The Outcome of the Diagnostics Forum of Yesterday By Tori Firewind, Principal Cloud Architect Introduction Many moons ago, a forum of dedicated diagnostic enthusiasts gathered together throughout several round-table discussions to produce a list of diagnostic daydreams, groom and refine that list, and then use it to produce realistic, yet awesome diagnostics requirements. Three different organizations, eight teams in total across PTC were involved, and dozens of real-world, customer experiences were considered throughout these conferences. In the end, a large diagnostics feature was designed and passed already prioritized, from the front lines directly into the backlog in the first ever collaborative effort to do Dev Ops as a process at PTC.   The fruits of this labor are now available in the latest version, ThingWorx 9.7! These features include the largely anticipated acceleration-based monitoring, custom persistence provider monitoring, and the ability to turn off metrics as needed, as well as additional open telemetry integrations and capabilities. This article will spotlight some of these new features and direct you to the 9.7 Help Center pages for more information. The Platform is smarter and Dev Ops easier than ever before, with the latest and greatest in monitoring found right here in ThingWorx 9.7.   Acceleration-Based Monitoring This is an extremely cool new feature in ThingWorx where the Platform monitors itself for runaway queues, those which indicate a system malfunction in the event or value stream queues for instance. If the acceleration is high enough for that queue, the Platform will automatically generate stack traces. This ensures the diagnostic data is already on the disc if and when the issue progresses to an outage.   No more do diagnostic SMEs have to sit and wait for a problem to occur again before they start investigating! Now they can download the stack traces that the Platform already stored on the disc.   Of course, it’s really important to get this feature configured right. If thread dumps are taken too often, those associated with the root cause may be purged before a tech can look more closely; only 10 thread dumps at a time are stored on the disc to prevent it growing out of proportion. On the other hand, if it does not take thread dumps often enough or in response to the right kinds of acceleration readings, then the root cause may altogether not be captured.   For this reason, there are several parameters to use to configure this feature, one being the acceleration increase percentage, considered very significant and a potential sign of trouble within the queue. This value is a flat percentage calculated at the time of measurement: queue count / total size of the queue. This number is checked frequently, as configured by another parameter, the acceleration calculation frequency. If the queue size exceeds the queue capacity occupied percentage at the same time the increase percentage is above the threshold, then the Platform records a stack trace on the disc. This ensures the diagnostic data will be present even after a restart, from early on when the problem began.   Another key parameter is the number of acceleration occurrences to wait before turning the thread captures on, which allows for a great specificity of when to collect the diagnostic data. Even if the acceleration is met once, well maybe that means nothing; perhaps it is normal for the queue to accelerate quickly at times. However, let’s say it does it 5 times within 30 seconds or a minute, or maybe the acceleration is elevated for some time, and we are approaching a data loss scenario. A rule based around the first scenario will capture close to the root cause, while the second might serve to collect what events didn’t make it into the queue before the restart.   Once the thread dumps are taken, there is a configurable cool off period in which no new stack traces will be recorded. This can allow the stack traces to be taken repeatedly at set intervals for persistent issues, and also reduces the overall activity of recording stack traces to ensure only the most useful ones remain on the disc.   One of five queues can be monitored in this way: Persistent Property Queue Event Processing Queue Stream Processing Queue Value Stream Processing Queue Connections Pool Processing Queue An example of setting all of these values can be found along with more information in the Help Center.   Custom Persistence Provider Monitoring There is now the capacity to see what the Platform is doing when interacting with your own custom persistence providers, or those used by the various ThingWorx applications like Navigate or DPM. At the monitoring endpoint, all persistence providers will now be listed at /Metrics, tagged by their name and database type:     # HELP thingworx_ThingworxPersistenceProvider_ConnectionPool_BusyConnections Current count of busy connections to the underlying database # TYPE thingworx_ThingworxPersistenceProvider_ConnectionPool_BusyConnections gauge thingworx_ThingworxPersistenceProvider_ConnectionPool_BusyConnections{category="DPMpersistenceProvider.ConnectionPool",databaseType="Microsoft SQL Server",otel_scope_name="com.thingworx",persistenceProviderEntityName="DPMpersistenceProvider",platformid="",prefix="Platform.Core.PersistenceProvider"} 0.0 thingworx_ThingworxPersistenceProvider_ConnectionPool_BusyConnections{category="ThingworxPersistenceProvider.ConnectionPool",databaseType="PostgreSQL",otel_scope_name="com.thingworx",persistenceProviderEntityName="ThingworxPersistenceProvider",platformid="",prefix="Platform.Core.PersistenceProvider"} 0.0     For more information about which parts of the persistence providers are monitored, see the Help Center.   Disable Metrics Now there is the potential to turn off some metrics if they become problematic or threaten to destabilize the entire environment. For example, the Audit Subsystem has a history of causing such issues for many, since the database tables grow very large and counting the rows can begin to take time. Turning these metrics off is now something easily done in the next maintenance window.   Simply add some code to your platform-settings.json file and restart the server, and whatever metrics specified will no longer be captured or appear at the metrics endpoints:     "MetricsSettings": { "DisabledMetricsList": [ "<metrics name 1>", "<metrics name 2>", "<metrics name 3>" ] }     Please note that there are several caveats and a warning to those who would turn off default monitoring features: ensure critical metrics are not unintentionally turned off and remember that this feature is intended for administrators who know the system well and need the ability to fine-tune its monitoring to ensure performance. Read more about this feature and its caveats in the Help Center.   Open Telemetry OpenTelemetry support was introduced in 9.6 and expanded in ThingWorx 9.7 to facilitate the recording of high volume monitoring metrics. It handles large-scale metrics and provides a more robust observability and capability for both diagnostic and predictive analysis. Find the new endpoint at /MetricsHC, with the old metrics still available as before. You can also use this metrics library to create your own custom metrics in a ThingWorx Extension, really expanding the metrics capability of the Platform. More information on how to make use of OpenTelemetry for monitoring can be found in the Help Center.   Conclusion ThingWorx does Dev Ops now better than ever, with features like these coming straight from real-world experiences and going right into the development workflow. Already, 4 additional monitoring features have been thought up and added to the mix, and improvements are coming soon! With more feedback on how to better to Dev Ops in ThingWorx, feel free to reach out.

This script will return, in XML format, details of all alarms for a particular asset, identified by serial number. It is designed to be called as a web service, in which case the username parameter will be supplied by the platform from the user authentication information passed in the web service call, and the id parameter will be supplied as an argument to the call. You should define this script as a Custom Object of type Action. You can test this script in the Groovy development environment on the platform by explicitly supplying the username and id parameters (i.e., your email address and "asset1"). import com.axeda.drm.sdk.Context; import com.axeda.drm.sdk.device.DeviceFinder; import com.axeda.drm.sdk.device.Device; import com.axeda.drm.sdk.data.AlarmFinder; import com.axeda.drm.sdk.data.Alarm; import com.axeda.drm.sdk.mobilelocation.MobileLocation; import com.axeda.common.sdk.jdbc.StringQuery; import com.axeda.common.sdk.id.Identifier; import groovy.xml.MarkupBuilder; try {   logger.info "parameters: " + parameters   if (!parameters.id) {     throw new Exception("parameters.id required");   }   // operate in the context of the user calling the service   Context ctx = Context.create(parameters.username);   // setup the finders   DeviceFinder df = new DeviceFinder(ctx);   df.id = new Identifier(Long.parseLong(parameters.id));   // find the device and its data   logger.info "Finding asset"   Device device = df.find();   if (!device) {     throw new Exception("Unable to find asset with id "+ parameters.id);   }   AlarmFinder af = new AlarmFinder(ctx);   af.device = device;   // generate the XML   writer = new StringWriter();   xml = new MarkupBuilder(writer);   xml.Alarms() {     af.findAll().each() { Alarm alarm ->       xml.Alarm('id':alarm.id) {         xml.DataItemName(alarm.dataItemName);         xml.DataItemValue(alarm.dataItemValue);         xml.Date(alarm.date.time);         xml.Description(alarm.description);         xml.MobileLocation() {           MobileLocation ml = alarm.mobileLocation;           if (ml) {             xml.BeginTimeStamp(ml.beginTimeStamp);             xml.EndTimeStamp(ml.endTimeStamp);             xml.Lat(ml.lat);             xml.Lng(ml.lng);             xml.Alt(ml.alt);             xml.IsCurrentLocation(ml.isCurrentLocation());           }         }         xml.Name(alarm.name);         xml.Note(alarm.note);         xml.Severity(alarm.severity);         xml.State(alarm.state);       }     }   }   // return the results   return ['Content-Type': 'text/xml', 'Content': writer.toString()] } catch (Exception ex) {   // return the exception   writer = new StringWriter();   xml = new MarkupBuilder(writer);   xml.error() {     faultcode("ErrorType.Exception");     faultstring(ex.message);   }   return ['Content-Type': 'text/xml', 'Content': writer.toString()] }

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