How-to guide
Run scripts and remote work with Kiwi Distro
Use kiwi_distro_script and kiwi_distro_invoke to run registered scripts and service methods on remote workers.
Prerequisites
- A Kiwi Distro middleware, with the script or service method you want already registered
- Client credentials for the middleware, and the Kiwi Distro connector entitlement on your licence
Kiwi Flow's engine runs every workflow itself. When one activity needs a specific machine, such as a Windows desktop with SAP GUI, a host with a browser, or any registered worker, it hands only that call to Kiwi Distro. Kiwi Distro decides which worker runs it; Kiwi Flow never needs to know.
The three activities#
| Type | Use it to |
|---|---|
kiwi_distro_connection |
Open a reusable connection to a middleware (OAuth2 client id and secret). Outputs connection |
kiwi_distro_invoke |
Call a method on a Kiwi Distro service (service/method) |
kiwi_distro_script |
Run a registered script and wait for it to finish |
Run a registered script#
kiwi_distro_script submits the run and polls for the result. Kiwi Distro owns script registration, versioning, authorisation and worker matching, and the same activity covers every executor: AutoIT, Playwright, Python, Node, PowerShell, batch, shell and AutoHotkey.
{
"id": "a_enter_order",
"type": "kiwi_distro_script",
"inputs": [
{ "name": "connection", "from": "kiwi_distro_connection_1.output.connection" },
{ "name": "service", "value": "sap-automation" },
{ "name": "script", "value": "enter_order" },
{ "name": "parameters", "value": { "customerId": "{{inputs.customerId}}" } }
],
"outputs": [
{ "name": "sapOrderId", "from": "output.result.sapOrderId" }
],
"next": "a4"
}
Useful inputs: version (pin a specific authorised script version; the latest authorised one is used otherwise), env (extra environment variables), ttlSeconds, and pollTimeoutSeconds (how long to wait for completion; default 900).
Outputs include status, exitCode, result, stdout, stderr, error, durationMs and requestId.
Call a service method#
{
"id": "a_status",
"type": "kiwi_distro_invoke",
"inputs": [
{ "name": "connection", "from": "kiwi_distro_connection_1.output.connection" },
{ "name": "service", "value": "orders" },
{ "name": "method", "value": "getOrderStatus" },
{ "name": "parameters", "value": { "orderId": 42 } }
]
}
target defaults to any (the middleware picks an available worker). Use all to fan out to every registered worker; the per-worker results appear in output.results. filters routes the call only to workers whose tags match every criterion, for example os=Win-11.
Connections#
Create a kiwi_distro_connection node once and let the other Kiwi Distro activities reuse it (the connection picker fills in automatically when exactly one suitable upstream node exists). Pin the middleware's CA with middlewareCaUrl; ignoreSsl is for development only.
Why only single activities go remote#
Dispatching an entire workflow to a remote node would make every step, including ones with no reason to leave the central engine, pay remote-call overhead and inherit its failure modes. Routing only the activities that need a particular machine keeps orchestration simple and cheap.
Expected result
- The remote call runs on a capable worker and its result flows back into the workflow