Getting started

By the end of this page you will have a workflow that calls an HTTP endpoint, run it by hand, read the run it produced, and put it on a schedule. Everything happens in Cockpit. There is nothing to install and no local project.

You need a tenant with Integration Studio enabled and permission to open it. Nothing else: the workflow below uses no credentials.

1. Create the workflow

In Cockpit, go to Integration Studio → Workflows → New. Give it a name you will recognise in a run list — first-workflow is fine.

You land on the canvas. A new workflow is paused: nothing can fire it until you activate it deliberately, which is what you want while you are still building.

2. Add a manual trigger

Add a Manual trigger. It is the start button — you run the workflow from the editor, on demand, and it is the fastest honest test of a whole flow.

There is nothing to configure on it. A workflow may have at most one manual trigger; adding a second is rejected. See Triggers.

3. Add an HTTP Request node

From the palette, place HTTP Request (revenexx:http-request) and wire the trigger to it.

Give the node an id you will want to type later — fetch — because that id is how expressions reach its output: ${{ nodes.fetch.outputs.response }}.

In the node's configuration set the method to GET. Leave the URL for the next step.

4. Wire a value with an expression

Open Variables on the canvas toolbar and declare one:

Now set the HTTP node's URL field to:

${{ vars.endpoint }}

That is the whole point of variables: the same graph can be re-pointed at another host without editing a node. Give every variable a value — an empty one resolves to nothing, silently, and reads like a data problem rather than a configuration one.

5. Save and run it

Save. Saving validates the graph, bumps the workflow's revision, and queues a build that compiles the graph into a runnable bundle. A run is rejected until that build reports ready — see Execution modes.

Then press Run on the canvas. If any node read from the trigger payload you would be asked for a payload first; this one does not, so the run starts straight away. Press Run while the bundle is still building and the request is held until the bundle is ready rather than failing.

A run started this way is a real run. It appears in the run history, it writes whatever the workflow tells it to write, and it consumes the same credentials as a live run. Test against systems you are allowed to write to.

6. Read the run

Open Integration Studio → Runs, or the run from the workflow itself:

• Details — how it ended, when it started and finished, and the result.
• Timeline — one entry per step in run order. Open the fetch step and you see its real input and output. This is where a path that looked right turns out to be one level off.
• Replay — the graph drawn as the run walked it.

Runs covers the rest: cancel, terminate, retry and resume.

7. Make it recur

Add a Schedule trigger alongside the manual one. It carries a five-field cron expression and an IANA timezone:

0 2 * * *   Europe/Berlin

Save, then Activate the workflow. A schedule does not fire when you save it — the first run is the next clock time that matches. Keep the manual trigger: it is how you re-run the job by hand without waiting for the next firing.

Schedule firings are at-least-once, so anything that writes data has to tolerate the same firing arriving twice. See Schedule triggers.

The shortcut: start from a template

If your job is a file-shaped integration, do not build it from an empty canvas. Integration Studio → Templates lists pre-built workflows — a BMECAT catalog import from SFTP, an orders CSV export, a customers CSV import, and more. A template's page shows the steps in run order, the variables you can tune, and a readiness check that counts the credentials and secrets it needs against your tenant. Use template creates a paused copy you rename and adjust.

See Templates, and Import a BMECAT product catalog for one installed end to end.

Troubleshooting

The run was rejected and nothing appears in the run history. The bundle is not ready. A save queues a build, and every path into a run — manual, schedule, webhook, event — is refused while the build status is anything other than ready. Reload the workflows list: the build state does not refresh by itself there, so a finished build keeps reading as pending until you do. A firing that was refused this way lands under Missed runs, where you can replay it.

A caller gets 405 from a webhook trigger. A webhook trigger declares the one HTTP method it accepts, defaulting to POST, and a call using any other method is rejected without starting a run. The method on the trigger and the method being sent do not match; nothing else is wrong. See Webhook triggers.

An expression renders empty. A reference that does not resolve is not an error — it resolves to nothing and the node runs with a gap in its config. Almost always the root is wrong: there are exactly four (vars, nodes.<id>.outputs.<port>, trigger.payload.<path>, in), the port name is required, and ${{ trigger.payload }} on its own does not resolve. Build the expression with the picker in the node's input panel instead of typing the path, then run the single node and read its output. See Expressions.

Where to go next

• Build the workflow — the document, the node catalog, expressions and configuration.
• Start the workflow — the other three trigger types, and who waits for the result.
• Connect the systems — the credential you will need as soon as the workflow touches a real system.
• Run, watch, recover — what to do when a step fails at 03:00.