Your first transfer

MFT 1 · 3:51

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:35Your Weik.io installation is fresh, so it holds nothing yet.
0:40Once deployed, the transfer runs on an agent like dev, online in devtest.
0:45That archive bucket needs every invoice file copied in.
0:49The copying runs on rclone, a common command line tool.
0:57weikio init supplier-invoices scaffolds the transfer,
1:02with the flag setting the kind to mft.
1:05The command leaves a document whose two ends go by the names source and destination.
1:11The source is where the files come from, the destination where they go.
1:15The operation is set to copy.
1:18This document carries its source's server settings inline.
1:21The comment lines underneath name filters, flags, retries and retriesSleep.
1:30Both ends of the transfer are backed by variables.
1:33A remote is a variable whose value is that server's rclone definition,
1:38type, host, user and password written as rclone wants them.
1:44One remote can serve several transfers.
1:46An environment can lay a different server under that name when it needs one.
1:51A remote's password or key never appears in the definition as text.
1:55It lives in a secret,
1:57so the definition stays harmless to hold in Git and easy to review in a pull request.
2:03At run time the agent resolves the two remotes,
2:06unseals their secrets, and copies the files with rclone.
2:13The edit replaces the source's inline server settings with a bare remote name.
2:18The source now names the remote supplier-ftp.
2:21The destination works the same way, through a remote called invoice-archive.
2:27The edit adds two documents of kind variable,
2:30one for each remote, holding the two rclone definitions.
2:34The folder now holds three documents: one transfer, two remotes.
2:40Each definition keeps a placeholder in place of the password or key.
2:44The two secrets get their values later.
2:49Validate runs the checks an apply runs before it builds.
2:53Over the three documents validate finds nothing to fix.
2:57Apply then publishes the three documents to your Weik.io installation.
3:02The remotes are now in Weik.io as variables of the project.
3:07The apply built the transfer's first version, 0.1.0, as for any integration.
3:14The apply closed by pointing at the deploy.
3:17The list narrows the project's integrations to transfers.
3:25A transfer follows the same model as every integration: a version when applied,
3:31a deployment in each environment that takes it, and a JVM on an agent.
3:36The documents are published, and nothing runs yet.
3:39A 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