Getting started

Register a client and run your first transport, end to end.

This chapter walks through the whole flow once, end to end, so you can see how the building blocks connect. Each step links to the reference chapter with the full detail.

The order is deliberate: a transport references a source connection, a sink connection, and an output format — so those have to exist first, and an on-prem source has to be bound to a registered client. Triggers and alerts are added afterwards to automate and watch the transport.

Before you begin

• You need a BARRY server reachable in your browser, and an account with the Admin role to register clients and change configuration. See Authentication & Roles.
• You need a machine inside your network that can reach the server over HTTPS and can reach the source database. That machine will run the client.

Step 1 — Register a client

Open Clients and create a new client. Give it a name (e.g. the host it will run on) and choose a delivery method:

• Show connection string — you copy the connection string and paste it into the client's configuration on the target machine.
• Generate install command — you receive a one-line command containing a short-lived bootstrap token; an admin runs it on the target machine and the client registers itself.

Install the client on the on-prem machine, apply the connection string or run the install command, and the client appears online in the Clients list. Full detail: Clients.

Step 2 — Create a source connection

Open Connections and create a connection for the system you read from — for example a SQL Server database. For an on-prem system, pick the client that can reach it; enter the host, database, and authentication, and use Test connection to confirm it works. Full detail: Connections.

Step 3 — Create a sink connection

Create another connection for where the data lands — for example Parquet into Azure Data Lake. Enter the storage account, container, base path, and authentication. Full detail: Connections and the Connector Catalogue.

For classic object-store sinks you also create an Output Format that describes the file format, compression, and folder layout. Self-contained sinks (Databricks, Fabric) bundle their own format and need no separate output format. Full detail: Output Formats.

Step 4 — Build a transport

Open Transports and start the wizard. You pick the source connection, browse and select one or more tables, choose the load strategy, the sink connection, and the output format, then review and create. The wizard creates one transport per selected table in a single pass. Full detail: Transports.

Step 5 — Run it and watch

From a transport's detail page, press Run now. The next time the client polls (within a second or two) it picks up the run, reads the source, and ships the data. Watch live throughput on the Monitor page's Live tab, and the per-run detail on its Runs tab. Completed runs and their logs stay in the run history. Full detail: Monitoring.

Step 6 — Automate it

To run the transport automatically, add a Trigger — a schedule, a web request, an inbound message, a file arrival, a chain off another transport, or a data sensor. A transport can carry several triggers and still be run manually. Full detail: Triggers.

What next

• Set up an Alert so a failed or long-running run notifies your team on Teams, Slack, email, or a webhook — see Alerts.
• Tune retention, concurrency, and transport performance — see Runtime Settings & Administration.