Getting response message when Route via HTTPS assertion fails

[Ozgur Anil Demir]

Hello,

I have a question about routing assertion.
When the route via HTTPS assertion fails, am I be able to see the response message from the service that I routed?

I've tried select "Never fail as long as target returns an answer" , in that way Layer7 sends an empty message.
I've also tried to reach it from ${audit.details.last.fullText} variable. But this is not include the response message too.

The only message that I reach is "Downstream service returned status (400). This is considered a failure case."  

How can we get the response message's body/mainpart?

Thanks for help

[Jay MacDonald]

If a response has been returned from the downstream server it should be available in ${response.mainpart}. The "Never fail as long as target returns an answer" setting just means the logic is handled a certain way in policy. You should also have access to ${httpRouting.reasonCode} to provide the HTTP status if you need that. In the event that the route failed and did not return a response, the reasonCode will be a negative value - see https://techdocs.broadcom.com/us/en/ca-enterprise-software/layer7-api-management/api-gateway/10-1/reference/troubleshoot-the-gateway/http-routing-response-codes.html

Cheers!

JayMac

------------------------------
Jay MacDonald - Adoption Architect - Broadcom API Management (Layer 7)
------------------------------

[Ozgur Anil Demir]

Hello Jay, Mesut,

Thanks for your answers, let me describe the problem with more details.

(Mesut I tried your suggestion before. After the routing assertion, in the response message the mainpart seems null. Gateway does not read the response message somehow)

The problem only occurs when the httpRouting.reasonCode >= 400 .

I've just published 2 more service to test.

• First one routes the request to the second and returns response with ${response.mainpart} 

• Second one just returns response;

 

 

Then I started debugger on both service and sent request to the first one. As you see below there is no response message;

And by the way, the second service sent response message;

When I changed the the response status to 200 on second service it works OK,

 
Thanks again.

[Ben Urbanski]

Hello, Ozgur. Are you sure your backend service even returns a response body for a 400 error? You should try sending a request that will receive a 400 error directly to your backend service with a different client (e.g. curl, Postman, etc.) to be sure. Otherwise, there are no known reasons why the response would not be available to you in policy and the debugger per Jay's and Mesut's comments, and you should open a support case.

------------------------------
Ben Urbanski
Product Manager, API Gateway
Layer7 API Management
------------------------------

[Mesut Yalcin]

Hi Ozgur, 

I have seen cases where a variable is not visible in the debug window when it is not used explicitly. In your examples you have demonstrated both situations, which is perfect. Could you please try to set a context variable in both cases after routing assertion as tmp = ${response.mainpart} and debug again? 
Or you can add the response variable to watch by typing "response" and pressing the "add" button. 




------------------------------
Regards,
Mesut Yalcin - Senior Solution Engineer
Apiida AG - https://www.apiida.com
------------------------------

[Ozgur Anil Demir]

Hello Mesut, 

Yes, I got the response message after I set it as a context variable on my test environment.

But still cannot get the remote service's response message. I realized that error messages' (HTTP status >=400)  content type is application/problem+json.

After that, I changed my response message's content type as application/problem+json on my test environment. Then I cannot get the ${response.mainpart}. 

I think the problem is related with the content type, do you have any idea about this issue?


Regards,

Özgür Anıl Demir

[Jay MacDonald]

The Gateway does not recognise application/problem+json as a text type of message. Add it to contentType.otherTextualTypes cluster-wide property and see if that fixes the issue.

Cheers!

JayMac

------------------------------
Jay MacDonald - Adoption Architect - Broadcom API Management (Layer 7)
------------------------------

[Ozgur Anil Demir]

Hello,

Thank you Jay, it fixed the issue.

Thanks for all answers.

Regards

Özgür Anıl Demir

[Mesut Yalcin]

Hi Ozgur, 

Try to add the response variable during the debug as shown below. Or create a temporary variable and assign ${response.mainpart} after the routing assertion.



------------------------------
Regards,
Mesut Yalcin - Senior Solution Engineer
Apiida AG - https://www.apiida.com
------------------------------