#Call a system with a service task

A service task calls one action of a connected system over HTTP or GraphQL, retries it when it fails, and files the response under its element id for the next steps.

#What happens when the process reaches it

flowchart LR
  A["Service task starts"] --> B["Work out the values<br/>of path, query and body"]
  B --> C["Call the action"]
  C -- "2xx" --> D["Response under the<br/>task's element id"] --> N["Next step"]
  C -- "any other answer,<br/>or no answer" --> R{"Retries left?"}
  R -- "yes: wait, then<br/>double the wait" --> C
  R -- "no" --> F{"Error boundary<br/>event on the task?"}
  F -- "yes" --> X["Continue on the<br/>boundary path"]
  F -- "no" --> Y["The instance fails"]

The call runs in the background: the process waits at the task until the system has answered or the task has given up.

#Configure a service task

Select the task and open Connection settings in the properties panel:

Once an action is picked, the groups it needs appear below:

• Path and Query — the action's parameters. Required ones are marked.
• Headers — extra request headers, for HTTP actions only. A header you set here wins over the adapter's default headers and its authentication.
• Request body — the fields of the request.
• Response body — read-only: the shape of the answer, which is what later steps can pick from. "No response body schema available" means the action does not describe one.

Every value can be fixed text, a variable picked with +, or an expression with ƒ. See Work with process data.

Which systems, adapters and actions exist is set up under Systems — see Systems and adapters and Environments and credentials.

#When a call fails

How often and how patiently a call is repeated is a setting of the action, not of the task: on the action's page under Behaviour, Wiederholungsversuche (retry attempts, default 3, at most 10) and Delay (ms) (default 5000).

• The first retry waits the delay, and each further one waits twice as long — 5 s, 10 s, 20 s — but never more than 5 minutes.
• Three retries mean four calls in total.
• How long Chester waits for one answer is the adapter's Timeout, 30 seconds unless set; it cannot be set below 10 seconds.

These fail at once, without a retry: a value whose expression cannot be worked out, an HTTP action without a base URL, and a configuration that is incomplete in the deployment.

When the last attempt fails, an error boundary event on the task takes over if there is one. Otherwise the whole instance fails, and it can be retried from monitoring. The error message is in the instance's history, not in the process data — a later step cannot read it.

#What the task hands on

Under the task's element id the next steps find:

• HTTP: the response body, after the action's transformations — see Schemas and transformations. The status code and the response headers are not kept.
• GraphQL: the data of the answer.
• An answer that is not an object, such as a plain text, arrives as body. An empty answer adds nothing.
• A file in the answer, or a very large value, is stored as a file and handed on as a reference to it.
• A multi-instance task hands on one result per item, as a list.

See Work with process data.

#What a service task cannot do

• ⚠️ Tell a client error from a server error. Every answer outside 2xx is retried, a 404 or 400 as well as a 503.
• ⚠️ Switch retries off. A value of 0 for Wiederholungsversuche is treated as the default, 3; a Delay (ms) of 0 as 5000.
• ⚠️ Guarantee a single call. If the system answers after the timeout, it may already have done the work when the retry calls it again. Only let a service task call an action that tolerates being repeated, or keep the retries low for actions that create things.
• ⚠️ Catch a particular error. An error boundary event catches every failure of the task; there is no filter by code.
• ⚠️ Keep a list per item. If a multi-instance item's answer is itself a list, it is handed on as an object keyed 0, 1, 2… instead.
• ❌ Call an agent. A service task calls a system. To run an agent, use a call activity — see Process elements.
• ❌ Use an email or an LLM adapter. They have no actions to pick. Email goes through a send task.

⚠️ The label Wiederholungsversuche is German whatever the language of the screen.

#What validation checks

• A system, an adapter and an action must be selected.
• Without an Environment the task gets a warning — and an error if the adapter has no base URL of its own, because then no host is known.
• An environment or credentials that belong to a different system are an error. An inactive environment stops the deployment.
• Required path and query parameters and required body fields must be filled in, and references must point to steps that exist.

The messages are shown in German. See Check that a process can run.