Returning Original Response

[Edward Lokiec]

I have a use case where I need to route to two different backends, but I need to return the first response back to the consumer. I know that I can use the Return Template Response to Requester assertion to do that, but I would like to also return the original http response headers as well. Does someone have a suggestion as how best to do that? Thank you. 

[Joseph Fry]

Just have the second "route via" assertion store the response to a different message variable by modifying the response destination field?

[Joseph Fry]

I saw that you messaged me directly, but for some reason the system is not letting me reply.

In order for the gateway to send the default response message, you cannot send any other response back to the client.  If you want the default response to be sent to the client, remove your "return template response" assertion.

[Joseph Fry]

Edward, please reply in the discussion forum rather than to me directly.  For some reason I can not reply to DM's and other people may be able to contribute if they see both sides of the conversation here.

[Edward Lokiec]

Joseph, regarding your comment "In order for the gateway to send the default response message, you cannot send any other response back to the client.  If you want the default response to be sent to the client, remove your "return template response assertion."" When I did remove the return template response assertion, I did not get the desired response from the first HttpRoutingAssertion even though the response destination is set to Default Response. Thank you again for your response.

[Jay MacDonald]

Whatever routing assertion (be that a HTTP routing assertion, or JMS, or template response, or copy request to response) assertion is last used and sets the default response, that message will go back to the client. Without seeing your policy, it sounds like you are clobbering the first response. Make sure there are no template responses after the first route and also that any subsequent rout via HTTP assertions put the response into a message context variable other than the default.

For example:

1:
- Route to A, result to default response
- Route to B, result to default response
--> result from B goes back to client

2:
- Route to A, result to default response
- Route to B, result to context variable
--> result from A goes back to client

3:
- Route to A, result to default response
- Return template response
--> Template goes back to client

Let me know if you have other questions

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

[Edward Lokiec]

Jay, my scenario is the one below (#2) when you say "it sounds like you are clobbering the first response. Make sure there are no template responses after the first route and also that any subsequent rout via HTTP assertions put the response into a message context variable other than the default." I do have other template responses in the policy, but they are only invoked when there is an error conditions which is not the case. When I disable the template response in the policy, I do not get the default response.  Again, thank you for your time.

2:
- Route to A, result to default response
- Route to B, result to context variable called serviceComparatorResponse
--> result from A goes back to client not in my case I get the following response: 

<?xml version="1.0" encoding="UTF-8"?>

<resources>

    <resource>

        <properties>

            <property name="location" value="https://ind-serv-log-v1-dev.apps.gp-1-nonprod.openshift.cignacloud.com/v1/service-logger-api/generic-logger"/>

        </properties>

    </resource>

</resources>

Which is not what is in the serviceComparatorResponse context variable or the default response.

• response = {Message}
• contentType = {String} "text/xml"
• http.allheadervalues = {Object[]} size = 6
• [0] = {String} "Accept:*/*"
• [1] = {String} "Accept-Encoding:gzip, deflate, br"
• [2] = {String} "Content-Type:text/xml;charset=ISO-8859-1"
• [3] = {String} "Date:Wed, 27 Sep 2023 19:46:01 GMT"
• [4] = {String} "Transfer-Encoding:chunked"
• [5] = {String} "X-Request-Id:7cbb4904-5d6e-11ee-87c0-0a58647e06fa"
• mainpart = {String} "valid soap response"

• serviceComparatorResponse = {Message}
• contentType = {String} "text/plain;charset=UTF-8"
• http.allheadervalues = {Object[]} size = 5
• [0] = {String} "content-length:7"
• [1] = {String} "content-type:text/plain;charset=UTF-8"
• [2] = {String} "date:Wed, 27 Sep 2023 19:46:01 GMT"
• [3] = {String} "Set-Cookie:7b79797cf2b655095a6dd671ee4a3842=bd1ad6a9d8d56f8931ced8eab34840e1; path=/; HttpOnly; Secure; SameSite=None; Domain=ind-serv-log-v1-dev.apps.gp-1-nonprod.openshift.cignacloud.com"
• [4] = {String} "x-request-id:7cea2e29-5d6e-11ee-9629-0a58647e2ac8"
• mainpart = {String} "Success"

• serviceComparatorEndpoint = {String} "https://ind-serv-log-v1-dev.apps.gp-1-nonprod.openshift.cignacloud.com/v1/service-logger-api/generic-logger"

[Jay MacDonald]

Where does this response come from?

<?xml version="1.0" encoding="UTF-8"?>
<resources>
    <resource>
        <properties>
            <property name="location" value="https://ind-serv-log-v1-dev.apps.gp-1-nonprod.openshift.cignacloud.com/v1/service-logger-api/generic-logger"/>
        </properties>
    </resource>
</resources>

That is not something the Gateway would typically generate. Have you modified soapfault.template cluster-wide property?

Also, "I do have other template responses in the policy, but they are only invoked when there is an error conditions which is not the case." You should not be using a template response to handle error conditions. You should instead be setting the Customize Error Response assertion and set up the policy to fail. If you use templates the policy still succeeds and may continue executing assertions you don't want to run through. It seems counter intuitive, but that's how the language works (being a boolean based policy language).

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

[Joseph Fry]

Is it possible that the response your getting is your Customized Error Response?  Perhaps you have a logic error in your policy and it's actually failing, and causing your custom error response to be sent, rather than the default response.

The policy debugger may help to identify what is going on here.  Step through and see if the response message ever changes after routing, or if you have any logic errors.

I suspect you will find it's something simple that just isn't obvious.  Often getting a new policy working with just the critical elements, the two routing assertions then slowly adding back the rest will help as well.

[Jay MacDonald]

Often getting a new policy working with just the critical elements, the two routing assertions then slowly adding back the rest will help as well.

That is a great suggestion.

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