Flow-to-Flow Replication

Why replicate rather than centralise#

A single central Infohub instance reading every site's historians directly is possible and usually a mistake.

Site instances survive the network. A plant keeps collecting, calculating, and reporting when the link to head office is down. A centralised instance stops collecting for everyone.

Local reporting stays local. Operators get their dashboards from a server in the building, not across a WAN.

Only summaries cross the network. Replicating a few hundred site KPIs is a fraction of the traffic of reading every raw tag centrally.

Sites can differ. Each site's model reflects its own plant, while the replicated subset is standardised for group reporting.

Replicated measures#

At the receiving instance, an incoming measure has the retrieval type Replicated. That is a first-class kind of measure, alongside Retrieved, Aggregated, Calculated, and Manually entered.

A replicated measure holds values it received. The central instance does not recalculate them — it accepts the site's figures, which is what makes site and group reporting agree. The site's daily production and the group report's figure for that site are the same number because they are literally the same number.

The central instance can then aggregate and calculate on top: sum sites into a regional total, compare sites against each other, roll up to a group KPI. Those higher-level measures are ordinary Aggregated and Calculated measures whose inputs happen to be Replicated.

Connection properties#

Identity and mapping#

The receiving instance must work out which of its measures an arriving value belongs to. That is what the Measure Name, Measure ID, and Time Scheme Name properties configure.

This is the single most important decision in setting up replication, and the one most worth writing down.

Measure ID does not travel between instances. An ID is local to a database. Measure 1043 at the site is not measure 1043 centrally. Identifying by ID across instances is a mistake unless you have deliberately arranged for the IDs to correspond, which is fragile.

Measure name is the practical choice, and it makes naming consistency a hard requirement rather than a nicety. If the site calls it Production Daily and the central instance expects Daily Production, replication will not match them.

The consequence is worth planning for: replication works far better when sites are templated. A group that instantiates the same template at every site gets consistent names automatically, and replication mapping becomes trivial. A group where each site was modelled by hand will spend real effort aligning names — and every rename thereafter is a coordinated change across two instances.

Include the Time Scheme Name in the identity where sites might have several calendars, so a daily value on the production calendar is not confused with one on the financial calendar.

Server keys#

The receiving instance issues a server key to each sending instance. This is the same mechanism used by template servers.

Operational implications:

• One key per sending site, so access can be revoked per site.
• Keys expire. Put the expiry dates somewhere your team reads, and rotate ahead of them.
• A rotated key stops replication silently from the sender's point of view. Verify after any rotation by checking that values are arriving at the receiver.

Namespace filtering#

Replicate a deliberately chosen subset, not the whole site model.

A site model may hold tens of thousands of measures. The group needs a few hundred: production, availability, quality, energy, cost. Replicating everything wastes bandwidth, fills the central database, and makes the central model unnavigable.

Use the namespace filter to publish only the part of the tree intended for the group. In practice, many sites create a dedicated folder — Group Reporting — containing exactly the measures replicated upward, which makes the contract explicit and auditable.

Network and hosting#

The consumer runs on the Integration Engine, on a Platform, hosted by Flow Bootstrap. It needs outbound access from the site to the central instance.

For sites behind restrictive networks, the proxy properties exist. And because the traffic is Flow-to-Flow over HTTP, it is generally easier to get approved than exposing a historian.

Enable Use https. This traffic crosses site boundaries and frequently the public internet.

Restatement#

Site values legitimately change — a backfill, a corrected calculation, late-arriving source data. The consumer resends, and the central instance updates the replicated measure.

That is correct and desirable: the group figure follows the site's correction. Two consequences:

Central aggregates recalculate. A corrected site value propagates into the regional and group totals above it, which is exactly what should happen.

A large site backfill produces a large replication burst. Where a site is correcting a long history, expect volume and warn whoever watches the central instance.

Monitoring#

An instance that stops replicating is the failure that matters most, because the central instance keeps reporting the last values it received as though they were current. Stale data presented as current is worse than absent data.

Build a check at the central instance: a measure tracking how recently each site's values arrived, with a limit on it, and a notification when a site goes quiet. This is the single most valuable piece of monitoring in a multi-site deployment.

Diagnosing#

See also#

• Multi-Site Architecture
• What a Data Consumer Is
• Consumer Reference
• Template Servers and Federation