Axeda agents must be configured to communicate with the eMessage Connector in order to communicate with ThingWorx.

An Axeda agent sends an initial registration message that identifies itself based on its model and serial number, either as configured by you, or supplied as part of a migration process from the Axeda Platform. The eMessage Connector uses the model and serial number information to check that a corresponding Axeda entity for the agent asset exists in ThingWorx. If no corresponding entity is found, registration fails. If an entity is found, the asset is authenticated and registration succeeds. Upon confirmation, the asset is registered with ThingWorx. For managed assets, the registration process is used to establish and maintain the list of assets that are managed by an Axeda Gateway agent.

The Axeda agent is configured to contact the eMessage Connector after a configured amount of time passes (for example, 60 seconds), to let the Connector know that it is alive and available. This configured amount of time is referred to as the ping rate for an Axeda agent. Ping messages are used only if an agent has not communicated with the Connector (idle) for longer than the ping rate. Whenever the asset communicates, its time counter is reset. If, for example, the asset sends a change in the value of a property (data item), the time counter is reset. If you need to change the ping rate temporarily (until the Agent next restarts), refer to Setting the Ping Rate.

Data items on Axeda agents represent discrete units of measure (for example, a temperature) and other characteristics of the assets where the agents are running. In ThingWorx, data items are referred to as properties of the Axeda Thing that represents a given asset. Incoming data item messages include the identification information necessary to ensure updating the appropriate Thing. Any issues with locating the entity, with the data quality, and other errors trigger notifications.

In ThingWorx, alarms are represented as properties of Base Type INFOTABLE on the Thing that represents a deployed Axeda asset. Incoming alarm messages include the identification information necessary to ensure that the appropriate Axeda Thing is updated in ThingWorx. These messages also include any data items associated with the alarm (as part of the Agent configuration). These associated data items update the values of their corresponding properties on the Axeda Thing.

In ThingWorx, events are also represented as properties of BaseType INFOTABLE on the Thing that represents a deployed Axeda asset. Incoming event messages include the identification information necessary to ensure that the appropriate Axeda Thing is updated in ThingWorx. They also include the name of the event, the associated message, severity, and timestamp.

You may want to subscribe to the property update event on the assetLogEvents property to be notified that an Axeda agent has sent an event message.

Egress supports actions such as updating data items and transferring files. Data item updates are handled using properties with remote bindings, which can be written to the Axeda agent asset. Any egress property/data item messages for an asset are queued up and sent to the asset when it next contacts the eMessage Connector. Similarly, for file transfers, the Connector contacts the File Transfer Subsystem to determine if any file transfers are pending.

The Axeda eMessage agents poll a platform to initiate communications. If it has a message to send to an eMessage agent, a platform must wait until the next time that the agent contacts the platform before it can send the message. Edge-controlled egress has been added to support this method of communication. You can control certain aspects of the interaction between the eMessage Connector and ThingWorx through configuration parameters for the Connector. Refer to Limiting Edge-Controlled Egress and Concurrent File Transfers

To handle file transfers to and from assets running Axeda agents, the File Transfer Subsystem of the ThingWorx Platform supports queueing of file transfer jobs. If an Agent is not connected and a file transfer is initiated, the file transfer is queued and will execute only when the Agent is connected.

The Copy service of the File Transfer Subsystem can initiate file transfers (uploads and downloads). This service has a property that needs to be set to specify whether a transfer is “queue-able”. The default value of this property is false. For file transfers with Axeda agents, make sure that it is set to true.

In addition, agent-initiated file uploads are also supported. The eMessage Connector provides a configuration property that enables the Connector to request an overall checksum on a file to be uploaded to the ThingWorx Platform. By default, the eMessage agents do not calculate an overall MD5 checksum. Instead, they calculate checksums on chunks.

As of v.1.2.0, the eMessage Connector enforces the maximum size of files to be transferred that is set for the File Transfer Subsystem of the ThingWorx Platform. For information about restricting the maximum size of a file to be transferred, refer to Restricting the Maximum File Size for File Transfers.

For more information about transferring files and using the micro-service, refer to the section, File Transfers. For information about requesting an overall MD5 checksum (property is requireOverallMD5), refer to Configuring Additional Properties for File Transfers.

The eMessage Connector and ThingWorx Platform provide limited support for Axeda agent scripts. You can download scripts to Agent assets, register and unregister scripts, and run scripts. The results of the script execution are provided in an event, to which you can subscribe to view the results. Refer to Running Scripts for details.

As of v.1.1.0, the eMessage Connector supports SCM messages. Users of the SCM module in ThingWorx Utilities can create instruction-based packages that download files, execute a script on the agent device, and restart the agent on the device. Compression is supported for downloading tar.gz files that the agents can extract. You can specify a hard or soft restart of the agent. As with package instructions in Axeda Platform, the Restart instruction must be the last instruction. For more information on using SCM, refer to the ThingWorx Utilitlies Help Center on the PTC Support site.

As of v.1.2.0 of the eMessage Connector, the Connector responds to requests from the Axeda Deployment Utility. Note that the Deployment Utility makes requests by proxying those requests through the agent. It will never directly talk to the eMessage Connector. Instead, it sends the request to the agent, which in turn generates a request to the eMessage Connector.

The eMessage Connector can return only the device information that is supported by the ThingWorx Platform. The ThingWorx Platform does not support the Organization, Location, Region, and System concepts of the Axeda Platform, so the eMessage Connector cannot set or return this information to the Deployment Utility. The Connector can return the ThingName for each device. However, it cannot set the Agent Name because the ThingName cannot be changed on the ThingWorx Platform. If you set this information in the Deployment Utility, the eMessage Connector will ignore the request. If you attempt to retrieve this information, the eMessage Connector returns empty requests.

The eMessage Connector forwards and stores information about the remote interfaces that the Axeda agents send to the ThingWorx Platform upon registration. This information includes the type of remote sessions supported, any related properties (for example, port number), and connection information for a device. The eMessage Connector communicates with Axeda Global Access Servers to manage requests for remote sessions. For information about remote access that applies to all types of agents, refer to Remote Access for Axeda Agent Assets through ThingWorx. For information specific to eMessage Agents and Axeda Global Access Server, refer to Remote Access for Axeda eMessage Agents through ThingWorx.

As of v.1.4.0 of the Axeda Compatibility Package and v.1.3.0 of the eMessage Connector, support for control of remote sessions via Axeda Policy Server is provided. At this time, other activities that Policy Server can control, such as file transfer requests, are not supported by the eMessage Connector. When a ThingWorx user sends a request for a remote session to an Axeda Gateway or Axeda Connector Agent, the Agent checks for a policy file. If it finds the file, the Agent checks whether it is allowed to always perform a remote session, must request permission for the remote session, or can never perform it (denied). If the policy is to ask permission, the Agent sends the request for permission to Policy Server and another message to the platform that it is waiting for permission. Once permission is granted, ,the Agent performs the action and notifies the platform. If permission is denied, the Agent does not perform the action and notifies the platform accordingly.

If the policy is to always allow the action, the Agent performs it. Similarly if the policy is to never allow, the Agent sends a message to the platform that the request was denied by Policy Server.

The changes in the Connector and the ThingWorx Remote Access Extension (RAE) for this support affect how remote sessions are handled. For more information, refer to Using Axeda Policy Server with the eMessage Connector.

Application keys and token authentication are used to secure communications between:

The eMessage Connector functionality has the following limitations: