Your first transfer

MFT 1 · 3:50

A transfer copies a supplier's invoices from an FTP server to an archive bucket, with no Camel route to write. It's written as three documents, with its two ends as variables, and published before anything runs.

Download the mp4Recorded on 2026.2

What it covers

Scaffolding a transfer of kind mft, with its source and destination ends
Remotes as variables, with each password or key kept in a separate secret
Variable documents for the remotes supplier-ftp and invoice-archive
Checking with weikio validate, then publishing all three documents with weikio apply
The new transfer in the list from weikio get integrations

Commands in this video

Terminal

$ weikio init supplier-invoices --kind mft
$ weikio validate -f ./finance
$ weikio apply -f ./finance
$ weikio get integrations --kind mft

Transcript

0:02The archive needs a copy of every invoice file a supplier drops into a folder on its FTP server.
0:09This video builds that transfer, then gets it published.
0:16The supplier drops invoice files on an FTP server like this.
0:20Moving files on a schedule makes up much of real integration work.
0:24A job like this needs no route.
0:26You write a transfer as plain documents, from your machine.
0:30The work starts in the finance project's document folder, still empty.
0:35The installation is fresh, so the hub holds nothing yet.
0:39Once deployed, the transfer runs on an agent like dev, online in devtest.
0:44That archive bucket needs every invoice file copied in.
0:48The copying runs on rclone, a common command line tool.
0:56weikio init supplier-invoices scaffolds the transfer,
1:01with the flag setting the kind to mft.
1:04The command leaves a document whose two ends go by the names source and destination.
1:10The source is where the files come from, the destination where they go.
1:15The operation is set to copy.
1:17This document carries its source's server settings inline.
1:21The comment lines underneath name filters, flags, retries and retriesSleep.
1:29Both ends of the transfer are backed by variables.
1:32A remote is a variable whose value is that server's rclone definition,
1:37type, host, user and password written as rclone wants them.
1:43One remote can serve several transfers.
1:45An environment can lay a different server under that name when it needs one.
1:50A remote's password or key never appears in the definition as text.
1:55It lives in a secret,
1:56so the definition stays harmless to hold in Git and easy to review in a pull request.
2:02At run time the agent resolves the two remotes,
2:05unseals their secrets, and copies the files with rclone.
2:12The edit replaces the source's inline server settings with a bare remote name.
2:17The source now names the remote supplier-ftp.
2:21The destination works the same way, through a remote called invoice-archive.
2:26The edit adds two documents of kind variable,
2:29one for each remote, holding the two rclone definitions.
2:33The folder now holds three documents: one transfer, two remotes.
2:39Each definition keeps a placeholder in place of the password or key.
2:43The two secrets get their values later.
2:48Validate runs the checks an apply runs before it builds.
2:52Over the three documents validate finds nothing to fix.
2:56Apply then publishes the three documents to your Weik.io installation.
3:02The remotes are now on the hub as variables of the project.
3:05The apply built the transfer's first version, 0.1.0, as for any integration.
3:12The apply closed by pointing at the deploy.
3:16The list narrows the project's integrations to transfers.
3:23A transfer follows the same model as every integration: a version when applied,
3:29a deployment in each environment that takes it, and a JVM on an agent.
3:34The documents are published, and nothing runs yet.
3:37A deployment starts the transfer once the two secrets have values.

Next in this track

MFT 2 · 3:33 Deploy it, and see a file move