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.

• definition of the 4ALLPORTAL ErrorResponse
• original Zalando "Problem" response

ErrorResponse Properties

Property	Deprecated	Open API Description	Type	Usage in the 4ALLPORTAL
type	-	Problem response (Zalando)	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)	string	Short description of a problem ("Error while copying a file").
status	-	Problem response (Zalando)	integer	HTTP error code
detail	-	Problem response (Zalando)	string	Detailed description of a problem used to find the error ("The file ABC could not be copied").
instance	-	Problem response (Zalando)	string	Recently not used
variables	-	Error response 4ALLPORTAL	Map<String, String>	Values for translated error messages
code	yes	Error response 4ALLPORTAL	string	Former 4ALLPORTAL error code (details)
message	yes	Error response 4ALLPORTAL	string	Former 4ALLPORTAL error message (details)
errors	yes	Error response 4ALLPORTAL	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.