Server-to-Server Collector Functionality

The Server-to-Server Collector works much like the Calculation Collector. The primary difference is that the Server-to-Server Collector stores the result to a destination tag on the destination archiver, where as the Calculation Collector reads and writes to the same archiver.

Collection on a tag-by-tag basis is preferred, according to scheduled poll times or upon data changes. One sample is collected each time the trigger fires. You cannot collect multiple raw samples from a source tag on a single trigger firing.

The Server-to-Server collector requires licensing on the destination machine. It is similar to any other collector. The destination machine will have the Server-to-Server listed in its collector list.

When a time or event based trigger of a destination tag fires:
  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.

If Alarm replication is enabled, all collected alarms are sent to the destination server as they happen. Alarm filtering is not available for the Server-to-Server collector.

The Server-to-Server Collector can perform calculations on multiple input tags as long as the input tags reside on the same source Historian.

The example in the following figure shows that multiple Server-to-Server Collectors can be used in an application to pass data from multiple nodes onto one node and that a server can be a source and a destination at the same time. Each Historian Server (archiver) is forwarding a different set of tags. You can only run one Server-to-Server Collector on each computer.


You can configure bi-directional collection, where each collector collects a different set of tags. The example in the following figure shows bi-directional Server-to-Server collection.
Note: You cannot collect the same tag in both directions. This is not a way to perform bi-directional synchronization of a tag.


The destination tag is fundamentally a different tag than the source tag. To further clarify this fact:
  • When a tag is added via a browse, 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.
  • 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 a property on a destination tag.
  • When the Server-to-Server Collector connects to the Cloud instead of a destination Historian server, you can use Configuring collector and tag properties for adding tag information. Refer to Getting Started Guide for more information.
Note: You cannot configure bi-directional message replication.