Configuring a Federation
The configuration process includes steps for two servers. For example, you have Server A and Server B. Server A is a local server and Server B is a remote server. We will use a stream or remote stream as the data Thing (the steps are same for a remote value stream, remote wiki, remote blog, or remote data table).
You have a MachineThing on Server A with 10 data properties. Every 5 seconds, you save the MachineThing properties to a stream. To offload the stream processing (writes and queries), you select to write to a remote stream. To do this, you create a stream on Server B, and then publish that stream to Server A. On Server A, you create a remote stream, which acts as a proxy object to the actual stream running on Server B. When you call, write, or read services on the remote stream, they are relayed and serviced by the stream on Server B over a Web socket connection between the two servers. The specific configuration steps to achieve this setup are detailed in the sections below.
 |
Use the same version of ThingWorx for all federated instances.
|
Configuring Server B
1. To open an existing stream, from Composer, browse and open a stream.
or
To create a new stream, from Composer, browse > , and then click the New button.
a. Select a Stream template, and then click OK.
b. Enter a name and description, select the Published check box, select a Data Shape, and then click Save.
c. Click the browse (
) icon, go to System, and then click Subsystems.
) icon, go to System, and then click Subsystems.2. Click FederationSubsystem, and then in the Configuration area, enter the server name and server description, and then click Add.
The Subscribers window opens.
3. In the Logical Server Name field, enter the name for Server B to publish to (in this case, ServerA), and then select the Enable Publishing check box.
4. In the Server URI field, enter the connection information for Server A.
The format of the Server URI field value is: <protocol>://<serverAddress>:<port>/Thingworx/WS, where:
| | PTC strongly recommends using WSS due to the proxy authentication schemes that are supported. Currently, PTC supports Basic and Digest proxy-authentication schemes. These authentication requests can be intercepted and information can be gathered over an insecure channel. Using WSS provides more security because it prevents intruders from tampering with these requests. |
◦ protocol is ws (Web sockets) or wss (secure Web sockets) (WSS connection is recommended).
◦ serverAddress is the IP or domain name of the server to which you want to publish namespace objects for consumption of their capabilities on the other server.
◦ port is the HTTP/HTTPS port to be used.
A typical server URI might look like the following: wss://www.myaddress.com:443/Thingworx/WS
5. On Server A, create a new Application Key for the access of Server B. On Server B, in the Application Key field, enter and confirm the application key ID created on Server A.
6. In the Publish As User field, select a user, and then click Add.
This selection is based on the user’s visibility permissions.
7. On the FederationSubsystem screen, click Save.
Configuring Server A
1. From Composer, browse > , and then click the New button.
2. Select a RemoteStream template, and then click OK.
3. Enter a name, description, Data Shape, and then add tags, if any.
| | For remote data tables and remote streams, the Data Shape needs to be defined on both servers. |
4. In the Identifier field, enter a Thing Name@Logical Server Name value, and then click Save.
| | The Thing name of the stream and logical server name were already defined for Server B. |
5. In the Services area, click the Execute (
) button to test and use the services on Server A.
) button to test and use the services on Server A.| | The services on Service A are used to read, update, and delete entries from the stream on Server B. |