Build3 min read

Build without the backend: mocking service tasks

Give a service task a pretend response, delay and failure rate, so you can run the whole process before the real system or worker exists.

In short

01
A mocked task finishes on its own — no worker needed.
02
Return one fixed response, or pick randomly from several.
03
Simulate slow and failing systems with a delay and a failure rate.

Process design usually gets blocked on integration: the payment API is not ready, the worker is not written. Mock mode removes the wait. You describe what the task should return, and the engine plays that part.

The four settings

Setting	What it does	Example
Mock response	Variables the task writes back when it succeeds	{"status": "OK"}
Response variants	Several responses; one is picked at random each run	[{"approved": true}, {"approved": false}]
Failure rate	Chance from 0 to 1 that the task fails	0.1 (fails one time in ten)
Delay	Pretend latency in milliseconds	200

Set them on the service task in Studio's properties panel. In the BPMN file they are stored as attributes on the task:

<bpmn:serviceTask id="charge-card"
    orkovia:jobType="charge-card"
    orkovia:mockResponse='{"status": "OK"}'
    orkovia:mockFailureRate="0.1"
    orkovia:mockDelayMillis="200"/>

How a mocked task behaves

Setting any mock field switches the task to mock mode. It takes priority over the job type.
The task completes straight away and no job is created, so no worker has to be running.
A mocked failure behaves like a real one: the instance fails and an incident is raised, so you can practise recovery too.
A task with no mock settings behaves exactly as before.

Where it helps

Early design

Run the full process end to end on day one, then replace mocks with real workers one by one.

Demos

Show a process without connecting to live systems.

Testing unhappy paths

Use a failure rate and response variants to exercise error handling and both sides of a gateway.

Remove mock settings before going live. A mocked task never calls the real system.

See it on your own process

Book a walkthrough with the Orkovia team.

Request a Demo

Keep reading

Build5 min read

Writing your first job worker

A worker is your code that does the work behind a service task. Here is the loop it runs, in Node.js, Python and Java.

Read article

Build4 min read

Calling external systems with connectors

Call REST, GraphQL and SOAP services or send email straight from a service task — configured, not coded.

Read article

Operate4 min read

Recovering a failed process

When a step fails, the instance stops and an incident is raised. Here are the ways to get it moving again.

Read article