Integration of External Systems | Scheer PAS Documentation

A reliable service behaves predictably even when things go wrong: incomplete input, slow or failing dependencies, unexpected external responses. Reliability in Designer comes from validating early, handling errors intentionally, treating external systems defensively, and proving all of it with tests.

This page covers practical best practices for the integration of external systems.

Design Integrations Defensively

Many service failures happen at integration boundaries. External systems are slower to change, harder to control, and often fail in ways your process must absorb safely.

Use clear adapter and API contracts.
Validate request payloads before sending them out.
Prefer idempotent operations that can be called multiple times.
Assume external calls can fail, time out, or return partial data.
Check response structures before using returned values.
Log the outgoing request and incoming response for each external call — this is usually the fastest way to diagnose an integration failure after the fact.
Plan fallback, retry, or manual continuation paths for critical interactions.
The xUML root state machine helps you with handling that, see Error Handling of Root State Machine for more.

Implementing Backend Access into BPMN

The way how you implement backend access into your BPMN has a big effect on how you can handle errors.

Prefer

Implement backend access to dedicated service tasks that only contains this single backend call.
This allows you to use the retry mechanisms of the xUML root state machine. When the backend problem is fixed, you can send a retry message as described on Sending Signals to Persistent State Objects (Docker: Sending Signals to Persistent State Objects (Docker)).

Avoid