Template Servers and Federation
Publish templates from one instance and consume them at many — how the link, the tokens, and the derive operation work.
Templates solve reuse within an instance. A template server extends that across instances: one Infohub instance publishes a library of templates, and other instances consume them while keeping a link back to the source.
This is how an organisation running Infohub at eight plants can maintain one definition of "how we model a compressor" centrally, and roll improvements out to all eight.
When you need it#
Federation earns its complexity when:
- Several Infohub instances should model the same equipment the same way
- Modelling expertise is concentrated centrally and rolled out to sites
- Group reporting depends on sites being genuinely comparable
- A standard is maintained over years and needs to keep reaching the sites
If you have one instance, you do not need this — ordinary templates are enough. If you have several instances but each is modelled independently, importing and exporting a file once is simpler.
The distinguishing question: will this content be maintained centrally and updated repeatedly? If yes, federation. If it is a one-time transfer, export a file.
How the link works#
An ordinary template instance records the ID of a template in the same database. A federated instance records something different: which template server it came from, and the template's identity on that server.
That distinction matters in practice. Because the remote template's identity is not a local database reference, resolving it means talking to the remote server. Federation therefore depends on connectivity and authentication in a way local templating does not.
Central instance Site instance
----------------- -------------
Template library
Compressor template ------------> Derived local template
(published) derive |
| instantiate
v
Compressor A, B, C
(local instances)
Note the two steps. A site does not instantiate a remote template directly. It derives a local template from the remote one, and then instantiates that local template as normal. The derived template keeps the federated link; the instances beneath it are ordinary local instances of the local template.
Identity, keys, and tokens#
Federation is authenticated, and three pieces of information are involved.
Instance ID. Every Infohub instance has a unique identifier. It is how a template server knows which instance is asking.
Server key. A credential the template server issues, held by the consuming instance and stored encrypted. It identifies the consumer to the publisher.
Token. A short-lived token, obtained using the server key, that authorises the actual requests.
Bootstrap is the component that brokers this. It listens on port 4501, and instances register with it so they can be discovered and authenticated. Federation between two servers therefore requires that Bootstrap on each is reachable from the other.
Plan the network before the modelling. Federation needs the consuming instance to reach the publishing instance's Bootstrap. Across plant networks, that usually means a firewall rule and sometimes a proxy. Confirm connectivity first — a federation that cannot connect fails in ways that look like template problems rather than network problems.
Setting up the publisher#
On the instance that will publish templates:
- Build and release the templates that make up the library. As always, an unreleased template is not usable.
- Ensure the instance is registered with Bootstrap so it is reachable.
- Issue a server key for each consuming instance. One key per consumer, not one shared key, so access can be withdrawn per site.
- Record which key went to which instance.
Keep the library deliberately curated. A template server that publishes everything anyone ever built is not a standard, it is a junk drawer. Publish the templates you are prepared to support.
Setting up a consumer#
On each consuming instance:
- In the Template Server view, create a template server entry pointing at the publisher — its address, the server key it was issued, and a proxy if the network needs one.
- Test the connection.
- Browse the remote library.
- Derive the templates you want into local templates.
- Release the derived templates locally.
- Instantiate them into the model as normal.
Steps 4 and 5 are both required. Deriving brings the definition across; releasing makes the local copy instantiable.
Verify after every derive#
A derive brings a structure across a network boundary, resolving remote identities into local ones. It is worth confirming the result rather than assuming it.
After deriving, check the local template before releasing it:
- Every expected metric is present
- Every expected measure is present under each metric
- Calculation expressions arrived, with their dependencies
- Attribute references are intact in tags, queries, and expressions
- Limits and enumerations the template relies on exist locally
Check the measure count in particular. A derived template that arrives with its metrics but missing some measures will instantiate quite happily and produce instances with holes in them — and the holes are only obvious once you go looking for values that never appear. Compare the derived template against the published one before releasing it. Two minutes here saves a confusing afternoon later.
Server keys expire#
A server key carries an expiry. Treat that as an operational commitment: put the expiry dates in whatever calendar your team actually reads, and rotate keys before they lapse rather than after.
Verify explicitly that federation still works after any key rotation, by deriving or refreshing one template. Do not assume that because nothing has broken visibly, authentication is still valid — a federated link that is not exercised for months can be non-functional long before anyone notices.
Updating a federated template#
The full path of a change, from central author to site instance:
- Central: edit the template, release it.
- Site: refresh or re-derive the local template from the server.
- Site: release the updated local template.
- Site: update the local instances.
- Site: verify a sample, then deploy.
Five steps, two of which are easy to forget — releasing the local template after refreshing it, and updating the instances afterwards. A change that stops at step 2 has reached the site's template library and none of its equipment.
Because sites control steps 2 to 5, central authors cannot force a change out. This is deliberate — a site is responsible for its own live reporting — but it means rollout is a coordination exercise, not a push button. Agree who does what, and how you confirm a rollout is complete across all sites.
Doing it from the CLI#
The federation surface is scriptable, which matters because these steps recur per site:
# on the publisher: register the instance so it is reachable
"Flow Config.exe" ... --register-with-bootstrap
# on the publisher: issue a token for a consumer
"Flow Config.exe" ... --create-server-token ...
# on the consumer: create the link to the publisher
"Flow Config.exe" ... --create-template-server --name "Group Library" ...
The server key and any proxy password are stored encrypted when created this way. See Templates and Federation from the CLI.
Operating it well#
One key per consumer. Shared credentials cannot be revoked selectively.
Version the library, not just the templates. Record which template versions constitute a supported release of the standard, so a site can say which release it is on.
Roll out in waves. One pilot site, verify, then the rest. A template change that breaks reporting at eight sites simultaneously is a bad day.
Keep a register of which site is on which version. Without it, "have all the sites got the new compressor model?" is unanswerable.
Do not federate everything. Federate the equipment patterns that genuinely should be identical. Site-specific modelling belongs to the site, and forcing it through a central library slows everyone down.
Diagnosing federation problems#
| Symptom | Usual cause |
|---|---|
| Cannot connect to the template server | Network path to the publisher's Bootstrap, or proxy settings |
| Authentication fails | Server key expired, revoked, or issued for a different instance |
| Remote library is empty | Templates on the publisher were never released |
| Derived template is missing measures | Verify against the published template before releasing — see above |
| Derived template will not instantiate | Local derived template not released |
| Central change never reached the equipment | Local template not refreshed, not re-released, or instances not updated |
| Worked for months, now fails | Server key expiry |