A Tour of Flow Config

The six views#

The split follows a real separation of concerns. The Model view describes what you measure. The Report view describes how it is presented. The Deployment view describes where it runs. The Toolbox holds things used across all of them. Template and Template Server describe what is reused.

Model view#

The main working area, and a tree:

Model
+-- Folder
    +-- Folder
        +-- Metric
        |   +-- Measure
        |   +-- Measure
        +-- Event Scheme

Folders organise, metrics group the measures that describe one thing, measures hold values, and event schemes provide context. See The Model Tree.

Most of what you do here is create measures and edit their properties. The property grid is where retrieval type, interval, aggregation, connection, tag, unit, format, and calculation expression are all set.

Template view#

Templates are edited here, in a tree that mirrors the Model view. A template metric with its measures is authored as a class, then instantiated into the Model view as many times as needed.

The important habit: author template content directly in the Template view. Building something in the Model view and converting it later is possible but more error-prone than starting in the right place. See Templates: Concepts.

Template Server view#

Where an instance links to a remote template library so that templates authored centrally can be used locally. Relevant to multi-site deployments; ignorable for a single instance. See Template Servers and Federation.

Report view#

Charts and dashboards. The structure is report folders containing charts, and dashboards containing panels that reference charts.

Two things about charts that are easier to learn here than to discover later. A chart is created through a named constructor that fixes its interval permanently, and it then accepts only measures at that interval. And you do not build a chart's internal structure node by node — you drop a measure onto the right component and the chart type builds the sub-structure for you. See How Infohub Charts Work.

Deployment view#

Where configuration becomes a running system: Platforms, and on each Platform the connections, engines, servers, integration engines, message engines, notification servers, and consumers.

This is also where deployment happens. Configuration you save in the Model view is inert until deployed. See Deploying Configuration.

The Deployment view also hosts the Monitor — the live activity view showing what the engines are doing: work backlogs, pending measure event periods, and faulted items. When something looks stuck, the Monitor is where you establish whether Infohub is behind or actually broken, before changing anything. See Monitoring Infohub and Its Health.

Toolbox view#

Shared building blocks, defined once and used across the model:

• Custom functions — reusable C# for calculations
• Enumerations — named value sets for event attributes and states, with colours
• Limits — threshold definitions applied to measures
• Time schemes — the calendars that define your periods, and the shift schemes within them

Anything used in more than one place belongs here rather than being duplicated.

Working habits worth adopting early#

Save often, deploy deliberately. Saving is cheap and local. Deploying activates change on a running system. They are separate actions for good reason.

Name things for the reader, not the builder. A measure name appears in charts, limits, notifications, and exports for years. Steam Flow Hourly outlives SF_H_01.

Use the Toolbox instead of repeating yourself. A third copy of the same limit or expression is a signal that it belongs in the Toolbox.

Build the aggregation chain before the charts. Charts bind to measures at specific intervals; building charts first means rework.

Everything here is scriptable#

Flow Config's entire surface is available from the command line — it is the same executable driven by options. That is what makes model building repeatable and reviewable, and it is how the demo and QA models are built.

"Flow Config.exe" --host <server> --database <db> --create --name "My Plant"

For large or repetitive models, scripting is usually faster and always more auditable than clicking. See Automation & the Config CLI.

Multiple people in one model#

Flow Config edits the database directly, so several people can work on one model at once. Infohub uses locks to prevent conflicting edits to the same entity, but the practical advice is organisational rather than technical:

• Agree who owns which area of the tree before starting.
• Avoid simultaneous work on the same template, since a template edit affects every instance.
• Coordinate deployment. One person deploying while another is mid-change is how half-finished configuration goes live.

See also#

• The Model Tree
• Deploying Configuration
• Templates: Concepts
• Getting Started with the Config CLI