The Deployment View

The shape of the tree#

Deployment objects nest in a fixed hierarchy:

Platform                        a Flow host
+-- Server                      the web client and REST API
+-- Data Engine                 retrieval and calculation
|   +-- Connection              a configured data source
+-- Integration Engine          publishing to consumers
|   +-- Consumer                a configured destination
+-- Message Engine              limits, messages and notifications
    +-- Message Channel
    +-- Notification Server

Template Server                 a federated template source (top level)

Platforms and Template Servers sit at the root. Everything else hangs off a platform. You cannot add a Data Engine without first having a platform to put it on.

Adding components requires administrator#

Every Add command in this view — platform, server, any engine, template server — is available only to a user with administrator rights. A non-administrator sees the tree and its state but cannot extend it. If the Add commands are missing entirely rather than greyed out, check the signed-in user's rights before looking for anything else, as covered in Users, Groups and Access.

What each component does#

For what these components are architecturally, rather than how they are configured, see Infohub Architecture.

Branding the Flow Server#

Double-click the Server node and its properties open, including the ones that decide how the web client looks:

The colours are worth understanding as more than decoration. Because charts can reference the theme's colours rather than hard-coding their own, setting them once here gives every chart on the server a consistent palette — and a palette that matches corporate branding, which is usually what is being asked for when somebody wants Infohub "in our colours".

Doing it the other way round — picking colours per chart — produces a server where forty dashboards nearly agree, and where a brand refresh means editing all forty. See Colour as Information for what colour should be carrying once it is consistent.

Defaults#

Four deployment types can be marked Set as Default: Data Engine, Integration Engine, Message Engine and Platform. The default is what new model content is assigned to when nothing is chosen explicitly.

Servers and Template Servers have no default — there is nothing that gets silently assigned to them.

As in the Toolbox, the command is only enabled on an object that is not already the default. Setting the default Data Engine early matters for the same reason the default time scheme does: everything created afterwards inherits it, and correcting the assignment later is a per-object job.

Deployment state#

Every deployment object carries a state, and Change deployment state is how you deploy or undeploy it. The states and the workflow are the same as for model content — see Deploying Configuration, which covers the state table, the order that works, and the Platform host check.

Two operations specific to this view:

• Configure connection — opens the connection properties for a Connection object, the same property grid described in Connection Property Reference.
• Migrate template server — moves a template server registration, used when a federated template source changes host.

When the host refuses a deployment#

Deploying a Platform registers the instance with the Flow Bootstrap service on that host, which checks that it can reach the instance database before it accepts. When Bootstrap refuses, Flow Config now reports the refusal with Bootstrap's own reason rather than reporting success and leaving the platform undeployed, or showing the older "please install it manually" message with no cause.

The most common refusal is a login failure. An instance on a SQL Server login that was deployed with Windows authentication — the default until a Username and Password are entered — makes Bootstrap's services connect as the service account, which SQL Server rejects. The message says so and points at the fix: open System properties and enter the SQL login as Username and Password, then deploy again. The same check runs when a script registers with --register-with-bootstrap, which exits non-zero with the same text.

Monitoring what is running#

Monitor activity opens live activity for the selected object, and Task opens a running Server in a browser or copies its link. Task is enabled only while the parent Server is actually running, which makes it a quick liveness check in itself.

For health beyond the tree, see Monitoring Infohub Health and Reading Infohub Logs.

System-wide settings#

Instance-level settings live in System properties, not on any single deployment object: the instance name, the bootstrap port of the host, whether daily database backups run, and the hour database maintenance starts.

Those last two are consequential and are covered in full elsewhere — see The Maintenance Window and Backup and Recovery.

Diagnosing#

See also#

• Deploying Configuration
• Infohub Architecture at a Glance
• Running the Data Engine
• Instance Lifecycle Administration