Legacy Support > ThingWorx XMPP Edge MicroServer (EMS) Software > Server Side Configuration of Edge Things
  
Server Side Configuration of Edge Things
The ThingWorx Model is a logical representation of the physical devices, systems, and people that interact with the solution. This same paradigm extends to the edge software components and the related edge devices. There are various terms and components that should be understood to help comprehend the entire connectivity model.
There are actually two software components that are installed remotely to achieve edge thing integration. The Edge Thing component is the software that performs device or data store specific communication. For example, there is a different module to communicate with a Microsoft Access database or an OPC-DA server than the module that may communicate with a specific medical device. There is also a script language available within the Edge Thing software component in order to provide custom logic or interfaces. The Edge Thing communicates bidirectionally with the ThingWorx server through an Edge MicroServer, or EMS. The EMS is the communication conduit, providing a secure communication channel to the server. Sometimes both components together are referred to as the EMS, but they are actually separate software components, and can be deployed together or on separate hardware within a network.
The XMPP EMS is a separate process because it can support more than one Edge Thing. There are three ways to deploy the edge connectivity solution:
1. Embedded — The ThingWorx XMPP Edge MicroServer + Edge Thing software is integrated directly into the device's application software stack.
2. Tethered — ThingWorx XMPP Edge MicroServer resides on a low-cost black-box that connects to the diagnostic and sensor ports on an intelligent device. The Edge Thing software component can reside on the same black-box (for field retrofits) or on the intelligent device.
3. Networked Gateway — ThingWorx XMPP Edge MicroServer resides on a low-cost network server appliance that resides on the same network with one or many intelligent devices. (e.g. For sensor networks or clusters of network capable equipment). The Edge Thing software components can reside on other hardware in the local network.
An Edge Thing in ThingWorx parlance is a device or data source that is remote from the ThingWorx platform and is accessed over the a network (Intranet / Internet / WAN / LAN). That device is represented by a Thing on the server. There are three default Thing Templates you can use to recreating a Channel:
1. Edge — A basic edge data source, such as an OPC-DA server, where you do not need to do file transfer or remote desktop tunneling to the device, but will read and write data points
2. EdgeDatabase — A remote database or similar structured data (e.g. a Relational Database that is remote and therefore may not be suitable to use JDBC access, or Microsoft Access / Microsoft Excel that do not support JDBC but do support ADO.NET) that you read and write data to using SQL or OLE-DB query languages. These also do not support file transfer or remote desktop tunneling.
3. EdgeEnhanced — A remote device or data store that you will read and write data to/from, and you also want to support bi-directional file transfer and/or remote desktop tunneling.
An Edge Thing in ThingWorx language is a device or data source that is remote from the ThingWorx platform and is accessed over a network (Intranet / Internet / WAN / LAN). That device is represented by a Thing on the server. There are three default Thing Templates you can use to recreating a Channel.
Creating a Channel Thing
The first task to complete is to create a Channel Thing on the server. This is the communication conduit to the EMS. There is always one Channel per EMS.
1. In Composer, create a new Channel.
2. Select the appropriate ThingTemplate. It must be the system Channel ThingTemplate or one that you have defined by extending the default system Channel template. The default system template for a Channel is named Channel. Just like any other system template, you should consider creating your own Channel ThingTemplates by extending the system Channel ThingTemplate, and add specific implementation details per your needs.
3. The EMS will use the Channel name as its "identity" (the jid setting in the edge configuration file) when it connects to the server. This establishes the one-to-one relationship between the channel and the EMS.
4. The only other required configuration for the Channel is the Technical User. The Channel Thing, and the associated EMS, will run using the security context of this assigned user.
5. Once the Channel Thing is created, you should be able to connect an EMS to the server. If the Channel properties (isConnected, ConnectionStatus) indicate it is connected, the EMS has successfully established communication to the server.
6. Once the Channel is saved and enabled, you should be able to tell if it is connected to an EMS through its connection status property.
Creating an Edge Thing
1. In Composer, create a new Thing.
2. Select the appropriate ThingTemplate (type Edge, EdgeEnhanced or EdgeDatabase, as appropriate - specific configuration guides follow for each type). It is HIGHLY recommended that you create your own Edge Thing ThingTemplates by extending the system ThingTemplates, and add specific implementation details per your needs.resent the edge thing at the server (you can extend any of these templates to customize them for your needs):
Edge — A basic edge data source, such as an OPC-DA server, where you do not need to do file transfer or remote desktop tunneling to the device, but will read and write data points
EdgeDatabase — A remote database or similar structured data (e.g. a Relational Database that is remote and therefore may not be suitable to use JDBC access, or Microsoft Access / Microsoft Excel that do not support JDBC but do support ADO.NET) that you read and write data to using SQL or OLE-DB query languages. These also do not support file transfer or remote desktop tunneling.
EdgeEnhanced — A remote device or data store that you will read and write data to/from, and you also want to support bi-directional file transfer and/or remote desktop tunneling.