Core | Essentials | DAM (4.37)

# Open API ErrorResponse

In the 4ALLPORTAL, Open API errors will be sent with an ErrorResponse object.
From Core Engine version 4.16, the Open API method ErrorResponse is based on Open API response "Problem" (Zalando), which also brings additional parameter variables.

# ErrorResponse Properties

Property Deprecated Open API Description Type Usage in the 4ALLPORTAL
type - Problem response (Zalando) (opens new window) string URL path that uniquely identifies the problem. From this, the frontend can both determine the locale and use it to create a label key needed for the ErrorResponse translations
(details).
title - Problem response (Zalando) (opens new window) string Short description of a problem ("Error while copying a file").
status - Problem response (Zalando) (opens new window) integer HTTP error code
detail - Problem response (Zalando) (opens new window) string Detailed description of a problem used to find the error ("The file ABC could not be copied").
instance - Problem response (Zalando) (opens new window) string Recently not used
variables - Error response 4ALLPORTAL (opens new window) Map<String, String> Values for translated error messages
code yes Error response 4ALLPORTAL (opens new window) string Former 4ALLPORTAL error code
(details)
message yes Error response 4ALLPORTAL (opens new window) string Former 4ALLPORTAL error message
(details)
errors yes Error response 4ALLPORTAL (opens new window) ErrorResponseItem[] Former possibility to return multiple errors
(details)

# Property type

The frontend generates a label key from the type property. The keys are generated according to these rules:

  • all - are replaced by _
  • all / are replaced by -
  • all lowercase are replaced by uppercase
  • an L is put in front of everything

Examples:

Type Resulting label key
/problems/{app_name}/out-of-stock L-PROBLEMS-APP_NAME-OUT_OF_STOCK
/problems/4allportal-dam/out-of-stock L-PROBLEMS-4ALLPORTAL_DAM-OUT_OF_STOCK
/problems/user-deactivated L-PROBLEMS-USER_DEACTIVATED
/problems/connection-error-read-timeout L-PROBLEMS-CONNECTION_ERROR_READ_TIMEOUT

4App name: General errors of 4App Core Engine are allowed to be defined without the 4App name. Errors of all other 4Apps must include the 4App name in their definition.

# ErrorResponse Translation for Frontend

For each ErrorResponse, backend developers must add a translation to be displayed to users in the GUI. Without a translation, only the generated label key is displayed.
To add a translation, you must check the type of an ErrorResponse. According to the rules described above, you need to add the corresponding label key to a .properties file, followed by your translation.

Further Documentation: Label key translation

# Backend Developers

Please consider the following:

  • When you create a new ErrorResponse, make sure you set the type property and define a translation to avoid untranslated label keys.
  • To distinct between a recent and a previous ErrorResponse: A recent ErrorResponse always has the type property. Previous ones either have no type property or set it to null, about:blank or empty.

# Backward Compatibility and Deprecation

For backward compatibility, the Zalando problem response also includes former ErrorResponseItem (including multiple errors) and some former ErrorResponse properties. These elements are for backward compatibility. They are deprecated and will be removed in the future.

Please note: The error handling of customer applications must be converted to the new structure before the deprecated elements are removed.

# No Support for Multiple Errors

Multiple errors are not be supported in the ErrorResponse after the removal of deprecated ErrorResponseItem.

There are two possibilities to handle this:

  • Change the code to only return one error at once.
  • If multiple errors are required, you need to create an Open API endpoint which allows to send multiple errors in the result.

← Sortable Implementation →

Request missing documentation