What a Data Consumer Is

Why publish at all#

Infohub already has dashboards and reports, so it is worth being clear about why you would send data elsewhere.

Corporate reporting. A group data warehouse or BI platform that consolidates several plants and several systems. Infohub contributes its calculated, contextualised numbers rather than the site's raw tags.

Multi-site consolidation. Each plant runs its own Infohub instance and replicates upward to a central one, which then reports across the group. See Multi-Site Architecture.

Feeding other applications. A maintenance system that wants runtime hours, a planning system that wants actual output, a customer portal that wants quality results.

Long-term archive. A data lake retaining more history than the Infohub database is sized for.

The common thread: Infohub's value is the calculated, calendar-aligned, contextualised numbers. Publishing those is far more useful to a downstream system than giving it access to the raw historian, because the hard work of aggregation and context has already been done and everyone consumes the same figures.

The direction matters#

Several connectors exist in both directions with similar names, and confusing them wastes time.

If you are trying to read from a system, you want a data source. If you are trying to write to one, you want a consumer.

The Integration Engine runs consumers#

Consumers are executed by the Integration Engine, a service object hosted by Flow Bootstrap on a Platform — alongside the Data Engine, Flow Server, and Message Engine.

That means the usual rules apply:

• The Integration Engine must be deployed, and so must each consumer. A configured-but-undeployed consumer sends nothing, without error.
• It runs as the Bootstrap service account, which matters for integrated security to a SQL target or a write to a network share.
• It can be placed on whichever Platform has network access to the destination.

See Infohub Architecture at a Glance and Deploying Configuration.

What gets sent#

A consumer sends the measures you attach to it, at the time schemes you specify. You are not publishing the whole model by default — you choose.

That choice deserves thought. The temptation is to send everything, on the grounds that the downstream system might want it. The cost is volume, transfer time, storage at the destination, and a much harder conversation later when someone asks what any of it means.

Send what has a consumer, in both senses of the word: measures somebody downstream has asked for and can explain.

Tags need a raw-values consumer#

A Tag interval measure holds raw timestamped values rather than interval summaries, so publishing one needs a consumer with the Raw values capability. Only two of the thirteen consumers have it; the Consumer Capability Matrix names them. Flow Config refuses to attach any other consumer to a tag, and so does the CLI. Every consumer can be attached to an aggregated, calculated or manual measure.

The send cycle and watermarks#

A consumer sends new and changed values rather than resending everything each pass. It tracks how far it has got, and picks up from there.

Two consequences worth understanding.

Recalculation causes resends. If a historical value changes in Infohub — a backfill, a corrected calculation, a late-arriving source value — the consumer will send it again. The destination therefore needs to handle a value it has already seen. For a SQL target that means an upsert rather than an insert, or a primary key that lets the same period be overwritten.

Backfilling generates a large send. Correcting a year of history produces a year of resends. Where the destination is metered or rate-limited, that is worth anticipating rather than discovering.

Identifying a measure at the destination#

The destination needs to know which measure a value belongs to, and how that identity is expressed is a configuration decision.

Consumers typically offer a choice of what to send as the identifier — a measure name, a measure ID, a time scheme name, or a combination.

The trade-off is real:

Measure ID is stable across renames but meaningless to anyone reading the destination, and it is not portable between Infohub instances.

Measure name is readable and meaningful, but changes when someone renames a measure — and a rename in Infohub is normally a safe, encouraged operation.

Whichever you choose, agree it with the destination's owner and write it down. The most common integration failure a year later is that nobody remembers whether the key is a name or an ID, and a rename has silently created what looks like a new series.

Namespace filtering#

Consumers commonly support a filter over which part of the model is published. This is how one instance publishes only its production area to a corporate warehouse while keeping utilities local.

Use it deliberately rather than sending everything and filtering downstream — filtering at source saves transfer, storage, and the downstream conversation about what to ignore.

Before you configure one#

Five questions to settle first. Getting these agreed prevents most integration rework.

1. What does the destination want? Specific measures, at specific intervals. Not "everything".
2. How will it identify a measure? Name, ID, or a mapping. Written down.
3. How does it handle restatement? Infohub will resend corrected values.
4. What happens when it is unavailable? Does Infohub retry, and for how long?
5. Who owns it? When it breaks in eight months, who is called?

That last one is not a technical question and it is the one most often unanswered. An integration with no owner degrades silently.

Monitoring#

An integration that fails quietly is worse than one that fails loudly, because the downstream system keeps reporting stale data as though it were current.

Practical monitoring:

• Check the consumer's deployment state as part of routine checks — Faulted or Different both mean it is not doing what you think.
• Ask the destination's owner to alert on staleness at their end. They will notice absent data before you will.
• Where the destination is critical, build a measure in Infohub tracking the last successful send and put a limit on it.

Diagnosing#

See also#

• Consumer Reference
• Consumer Placeholder Reference
• When Integration Fails
• Flow-to-Flow Replication