Overview of the Server-to-Server Collector

The Historian Server-to-Server collector allows you to collect data and messages from a source Historian server to a destination Historian server, a Predix Time Series instance, an Azure IoT HUb instance, or an MQTT endpoint such as AWS IoT Core. The Server-to-Server collector includes many of the features of the Calculation collector. The primary difference is that the Server-to-Server collector stores the result in a destination tag on the destination server, whereas the Calculation collector reads and writes to the same server.

The Server-to-Server collector can also run as a stand-alone component where both the source and destination Historian databases are on remote machines.

When a time-based or an event-based trigger of a destination tag occurs:
  1. The calculation formula for the destination tag is executed.

    This typically involves fetching data from one or more tags on the source server.

  2. A raw sample or calculation error is determined.

    You can use conditional logic in your calculation formula to determine if a sample should be sent to the destination.

  3. The raw sample is delivered to the destination server, utilizing store and forward when necessary.

Message replication, if enabled, is event-based. Messages and alerts are sent to the destination server as they happen.

The destination tag is fundamentally a different tag than the source tag. Therefore:
  • When a tag is added by browsing, only certain tag properties are copied from the source tag to the destination tag. Consider what properties are necessary for your application and configure them manually. For information on which properties are copied, refer to Tag Properties that are Copied.
  • If you change a tag property on the source tag (EGU Limits, descriptions, and so on), the property does not automatically change on the destination tag. You can manually change the properties of a destination tag.

Data Flow in Multiple Server-to-Server Collectors

The following image shows that you can use multiple Server-to-Server collectors in an application to pass data from multiple nodes to one node and that a server can be a source and a destination at the same time. Each Historian server is forwarding a different set of tags.

Data Flow in Bi-directional Server-to-Server Collectors

You can configure bi-directional data collection, where each collector collects a different set of tags. The following figure shows bi-directional server-to-server data collection.
Note: You cannot collect the same tag in both directions. This is not a way to perform bi-directional synchronization of a tag.
Features
Feature Capability
Browse Source for Tags Yes
Browse Source for Tag Attributes Yes
Polled Collection No
Minimum Poll Interval No
Unsolicited Collection Yes
Timestamp Resolution Yes - 100 milliseconds
Data Compression Yes
Accept Device Timestamps Yes
Floating Data Point Yes
Integer Data Yes
String Data Yes
Binary Data No
Allows VB scripting No
Python Expression Tags No

Licensing

When the destination server is Proficy Historian, the Server-to-Server collector requires licensing on the destination machine. This means that the destination Historian server must be licensed for the Historian Enterprise edition, have the Enterprise Collectors option licensed, or be a Historian Edge server. It is similar to any other collector. The destination machine will have the Server-to-Server listed in its collector list.

Interface Name

Historian uses the following naming convention for the Server-to-Server collector interface name:
<source Historian server>_To_<destination Historian server>
Best Practices
  • We recommend that you install the Server-to-Server collector on the source Historian machine. When you do so, the collector can preserve the collected data (store and forward) even if the collector and the destination server become disconnected.
  • Collection on a tag-by-tag basis is preferred, according to scheduled poll times or upon data changes. One sample is collected for each trigger.
  • The Server-to-Server collector can perform calculations on multiple input tags as long as the input tags are on the same source Historian.
  • Use polled triggers to perform scheduled data transformations like daily or hourly averages. Use unsolicited triggers to replicate data in real time, as it changes.
  • Use event-based triggers to replicate data throughout the day. The samples can be held ingoing an outgoing store and forward buffer when necessary. You cannot schedule batch replication of raw samples. For example, you cannot, at the end of the day, send all raw samples for tags to the destination.
  • All input source tags for the calculations must originate from the source archiver. For instance, you cannot directly add a tag from server1 plus a tag from server2 and place the result on server2. You could, however, collect tags from server1 to server2, and then use the Calculation collector or the Server-to-Server collector to accomplish this. This requires two Server-to-Server collectors, one running on each machine. You could also use the Historian OLE DB provider.
Limitations
  • If you enable alarm replication, the alarm data is sent to the destination server. However, alarm filtering is not available in the Server-to-Server collector.
  • You cannot configure bi-directional message replication.