Is it possible to get the actual response from the server when using catch web request error node?
We are catching the web request error, but it will be handy also to catch the actual response from the service, because catch web request node allows to map the response to the object in Appfarm.
When catching the exception from a web request error in a Catch Exception action node you could map the appropriate properties in the response body to object properties or some app variables using the Result Mapping in the action node. See this article for more information.
As an example I’ve tried to make a call to the Norwegian Brønnøysundregisteret with an invalid input making the action node fail. The caught exception looks like this:
{
"tidsstempel": 1688104607309,
"status": 400,
"feilmelding": "Feilaktig forespørsel",
"sti": "/enhetsregisteret/api/enheter",
"antallFeil": 1,
"valideringsfeil": [
{
"feilmelding": "'' er ikke et støttet parameter",
"parametere": [
"organisasjonsnummer"
],
"feilaktigVerdi": "[]"
}
],
"code": 17003,
"httpStatusCode": 400,
"message": "The request was made and the server responded with a status code that falls out of the range of 2xx",
"name": "WebRequestException",
"body": {
"tidsstempel": 1688104607309,
"status": 400,
"feilmelding": "Feilaktig forespørsel",
"sti": "/enhetsregisteret/api/enheter",
"antallFeil": 1,
"valideringsfeil": [
{
"feilmelding": "'' er ikke et støttet parameter",
"parametere": [
"organisasjonsnummer"
],
"feilaktigVerdi": "[]"
}
]
}
}
The result mapping depends on how the response in your caught exception actually looks like. In this example we extract the status and feilmelding in the action node and store them in app variables (but could easily be a runtime object instead based on your needs). You could also access child properties in the response by using the dot-notation, for example extracting the validation error of the response in this case.
Thank you, Eirik!
I presume it will only work if the server replies with the response in JSON? I have experienced that if server responds in plain text, the response is not populated in body:
"body": {
"message": "Request failed with status code 400",
"name": "Error",
"stack": "Error: Request failed with status code 400\n at createError (/usr/src/app/node_modules/axios/lib/core/createError.js:16:15)\n at settle (/usr/src/app/node_modules/axios/lib/core/settle.js:17:12)\n at RedirectableRequest.handleResponse (/usr/src/app/node_modules/axios/lib/adapters/http.js:211:9)\n at RedirectableRequest.emit (events.js:314:20)\n at RedirectableRequest._processResponse (/usr/src/app/node_modules/follow-redirects/index.js:269:10)\n at ClientRequest.RedirectableRequest._onNativeResponse (/usr/src/app/node_modules/follow-redirects/index.js:50:10)\n at Object.onceWrapper (events.js:421:26)\n at ClientRequest.emit (events.js:314:20)\n at HTTPParser.parserOnIncomingClient (_http_client.js:601:27)\n at HTTPParser.parserOnHeadersComplete (_http_common.js:122:17)",
"config": {
"url": "########",
"method": "post",
"data": "################",
"headers": {
"Accept": "application/json, text/plain, */*",
"Content-Type": "application/json; charset=utf-8",
"Authorization": "Basic ########",
"User-Agent": "axios/0.19.0",
"Content-Length": 758
},
"transformRequest": [
null
],
"transformResponse": [
null
],
"timeout": 30000,
"responseType": "stream",
"xsrfCookieName": "XSRF-TOKEN",
"xsrfHeaderName": "X-XSRF-TOKEN",
"maxContentLength": null
}
@Eirik there is a message that the Catch Exception node was triggered and i’ve posted in a previous message everything that i get. But there is no actual response message from the server. As you can see, body is not populated with any additional parameters, just standard message / name …
I presume that is because the response from server is not in JSON, it is just a plain text. Still will be great to have ‘plaintext’ or similar parameter in the body which will include the response from the server.
In this particular case it seems like you do not get any actual response from the server, since you are getting a 400 Bad Request with a stack error indicating that you have crashed the service (before it is able to give you a response at all).
"stack": "Error: Request failed with status code 400\n at createError (/usr/src/app/node_modules/axios/lib/core/createError.js:16:15)\n at settle (/usr/src/app/node_modules/axios/lib/core/settle.js:17:12)\n at RedirectableRequest.handleResponse (/usr/src/app/node_modules/axios/lib/adapters/http.js:211:9)\n at RedirectableRequest.emit (events.js:314:20)\n at RedirectableRequest._processResponse (/usr/src/app/node_modules/follow-redirects/index.js:269:10)\n at ClientRequest.RedirectableRequest._onNativeResponse (/usr/src/app/node_modules/follow-redirects/index.js:50:10)\n at Object.onceWrapper (events.js:421:26)\n at ClientRequest.emit (events.js:314:20)\n at HTTPParser.parserOnIncomingClient (_http_client.js:601:27)\n at HTTPParser.parserOnHeadersComplete (_http_common.js:122:17)",
Do you see the actual response from the request in the network log in your browser and that the exception caught in Create is missing some information compared to this?
One could argue that the service you are calling should be able to handle this more gracefully. But, since you are the one sending the request you should be able to add some checks on your side to ensure that the request meets the requirements of the service to avoid this particular behaviour?
In most cases this would be the preferred approach instead of catching stack traces from other services.