Let's look at the two different approaches and some guidelines for when they should be used.ĭescriptive services (click for more details) provide a set of ThingWorx services to analyze a data set and perform many common data transformations. This article will provide some guidance on scenarios to use each of these approaches in ThingWorx applications and things to consider with each approach. When choosing between these two approaches it is important to consider the specific use case being implemented along with how the implemented approach will fit into the overall design and architecture of the ThingWorx environment. However, these tools are targeted for handling different scenarios and also differ in utilization of compute resources.
Both of these tools are easy to implement and orchestrate as part of a ThingWorx application. The platform includes two different approaches for the implementation of many common statistical calculations on data for a property: descriptive services and property transforms. There have been a number of questions from customers and partners on when they should use different tools for calculation of descriptive analytics within ThingWorx applications. See EMSGateway Class Documentation for more details. The EMSGateway template, used both normally and ephemerally, will provide some gateway specific services that would otherwise be inaccessible to a normal remote thing. This newly created ephemeral thing will only be accessible through the ThingWorx REST API, and once the EMS unbinds the gateway the ephemeral thing will be deleted If there is a pre-existing Thing on the ThingWorx server, then it must be based off of the EMSGateway template in order for the bind to succeed. To clarify, if no Things exist with the matching Thing Name on the platform, and the EMS is attempting to bind a Gateway, a Thing will be automatically created on the platform to bind with the auto-bound gateway. Gateway: An auto-bound gateway can be bound to the ThingWorx platform ephemerally if there is no Thing present to bind with on the platform. There are many reasons to use this type of auto-bound thing, but the most common is to bind a simple thing that can facilitate file transfer and tunnel services but does not need any custom services, properties, or events that would be provided by custom lua scripts within the LuaScriptResource. RemoteThingWithFileTransfer) on the ThingWorx server in order for the bind to succeed. There must be a corresponding Thing based on the RemoteThing template (or any RemoteThing derived template e.g. Non-Gateway: This type of auto-bound thing can be thought of as a placeholder because the EMS will still require a LuaScriptResource to be bound in order to respond to property/service/event related messages. Using either gateway value, when used with a valid "name" field, will result in the EMS attempting to bind the Thing with the ThingWorx platform, and will allow the EMS to respond to file transfer and tunnel services related to the auto-bound things, but this is around where the similarities end.
When using the Auto-bind section of an EMS configuration it is very important to note the difference between "gateway":true and "gateway":false.
0 kommentar(er)
