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 where to validate and how to handle errors.
Implement Validation Early and Consistently
Validation should not be treated as a final checkpoint. Robust services validate at the boundaries and before critical actions, and rely on Designer's built-in validation capabilities like form validation before reaching for custom checks.
|
Validation Area |
Best Practice |
Why It Matters |
|---|---|---|
|
Input data |
Check mandatory fields, data types, allowed values, and structural completeness at service entry. |
This prevents invalid service requests, and propagating invalid data through the process. |
|
Business rules |
Validate domain conditions (like stock level, authorizations, …) before approvals, calculations, or integrations. |
This reduces incorrect business outcomes and need for rework. |
|
External responses |
Verify returned status, payload completeness, and expected identifiers. |
This protects the process from downstream inconsistencies. |
|
User input |
Combine form-level validation with backend validation. |
The client layer handles fast feedback and catches the honest mistakes early. The server layer enforces that the data is valid, safe, and consistent. |
Rule of thumb: Validate as close as possible to where data enters or changes, and fail with clear messages when assumptions are not met.
Handle Errors Intentionally
Robust services do not just catch errors. They classify them, respond appropriately, and make them diagnosable.
Differentiate Error Types
|
Business errors |
rule violations, missing approvals, invalid statuses, duplicate requests |
|---|---|
|
Technical errors |
unavailable systems, timeouts, transport issues, malformed external responses |
|
Data quality errors |
missing fields, inconsistent identifiers, invalid formats |
Error-handling Practices
-
Handle expected exceptions explicitly instead of relying on generic failure behavior, e.g. catch exceptions thrown by adapter calls and re-throw them after your own error handling (see also Throwing a User-defined error).
-
Return clear, actionable error information. This makes error handling easier for the client. Say what happened and why, provide information on how to fix the problem, or what to do next (see also the error message examples below).
-
Log context that helps diagnosis, such as business keys, correlation identifiers, and affected step names (see also the log message examples below).
-
When an exception occurs, log a reference to the process (e.g. its process ID) so the failure can be traced back to the run that caused it.
-
For synchronous processing with no persisted process instance, generate a UUID as a correlation identifier and log it, so the request can still be traced end to end.
-
A good error message explains what failed, where it failed, and what should happen next.
Avoid exposing sensitive internal details in user-facing error messages.
Error Message Examples
Prefer in UI
-
Unable to connect to SAP system
-
Your changes were saved, but we could not send the order to SAP due to technical issues.
-
Please try again. If the issue persists, contact customer support.
Avoid in UI
-
Oops, an error occurred
-
The SAP system is not responding, so we cannot write your data.
-
Try again later.
Prefer in Logs
|
level
|
|
|
type
|
|
|
code |
|
|
description
|
|
Avoid in Logs
|
level
|
|
|
type
|
|
|
code |
|
|
description |
|
Related Content
Related Pages:
Related Documentation: