Customize error response assertion not generating response varibale

[shobhit saxena]

We are using "Customize Error Response" and then "Raise Error" in our service and raising a 500 error, but in message-completed global policy we are not getting the response object to fetch ${response.http.status}, though SoapUI is getting the HTTP 500 error.

How can we get the response status or http error status that is returned from the service in case of "Raise error" in message-completed policy?

 

While if we use "Return template response to Requestor" in our service , we are getting response object in message-completed policy and hence the value for ${response.http.status} .

[Stephen Hughes]

Good afternoon,

 

I've just tested this in a version 9.3 gateway. I found that with just an audit detail writing to log with the message of "Message completed: ${response.http.status}" and the main policy has a Customize Error Response and a Raise Error that the gateway will record a value of 0 as there were no Routing and the policy just exited out. The 500 error is being produced outside of the policy as the Raise Error exits the policy.

 

Sincerely,

 

Stephen Hughes

Broadcom Support

[shobhit saxena]

Yes, it returns the status 0.

But requirement here is how can we capture the status of 500 in this scenario?

Thanks

Regards,

Shobhit

[Dirk Bleyenberg]

Hi Shobbit

 

If you have any more questions on this let me know by the support case we  have .

 

Regards 

Dirk 

[Roman PENA]

Hi Stephen,

 

Can you please share the final solution?

I am having exactly the same issue described by Shobhit.

We are using API Gateway 9.3.

 

I am not able to get the response object in the message-completed global policy when the error is caused by "Raise Error Assertion".

 

 

Thank you,

Roman

[Stephen Hughes]

Roman,

 

Depending on where the raised error occurs some of the variables may not have been created yet. How does your policy look in respective to the raised error? 

 

Sincerely,

 

Stephen Hughes

Broadcom Support

[Roman PENA]

Hi Stephen,

 

The raised error occurs inside the OTK (OAuth Tool Kit). Is not a policy written by us. The error response built by the OTK looks like this:

{
"error":"invalid_request",
"error_description":"Missing or duplicate parameters"
}

 

*** The raised error occurs inside the OTK service -> "auth/oauth/v2/token"

 

We want to transform the above response to our Corporate standards (something like this):

{
"status": "400",

"error": "Invalid Request"
"message": "Missing or duplicated parameters",
"path": "/auth/oauth/v2/token",
"type": "AUTHENTICATION ERROR",
"timestamp": "2019-04-01T12:49:49.942Z"
}

 

Thank you,

Roman

[Stephen Hughes]

Roman,

 

I've attached an updated version of the auth/oauth/v2/token policy which can be customized to meet the requirements that you sent through. Let me know if this is what you had in mind. 

 

Sincerely,

 

Stephen Hughes

Broadcom Support

Attachment(s)

custom_auth_oauth_v2_token_error_handling.xml.zip   10 KB 1 version

[Roman PENA]

Hi Stephen,

 

Thank you for your response and for the updated version or the assertion. I can achieve the same result just using the "#OTK Fail with error message" fragment as any other regular OTK customization, but that is not what we are looking for. The actual issue is the fact that we can't access to the response message object in the "Customize Error Response" assertion, anytime a policy assertion faults the "Customize Error Response" will be returned, we placed it inside the  Global-Message-Completed policy, all we want is to be able to access the Response and make more detailed  customization based on the response data.

 

Thank you,

Roman

[Stephen Hughes]

Roman,

 

Is this just the OTK error responses or for overall services in general? The updated policy should catch all the areas where error may occur in the OTK token. The Customize Error Response will simply just send back directly without going through the global policy.

 

Sincerely,

 

Stephen Hughes

Broadcom Support

[Roman PENA]

Hi Stephen,

 

Yes, our problem is in general, not only for OTK Error Response. Will try to explain in other words.

 

We have a Customize Error Response assertion in a Global(message completed) policy, the intention is to override the default SOAP error response provided by the Gateway, the problem is that doing that we also override any error response coming from the OTK policies, hence the API consumer does not know what exactly happens.

 

For example, with no "customize Error Response" on the Global (message completed) policy the OTK Token service gives:

HTTP - 400 - Bad Request

{
"error":"invalid_request",
"error_description":"Missing or duplicate parameters"
}

 

Having a "Customize Error Response" assertion in a Global (message completed) policy for the same request the response is:

 

Policy evaluation for service auth/oauth/v2/token [e001cfd0c1c1ffaa18e187b5e72fdd38] resulted in status 600 (Assertion Falsified)

 

What can be done to capture the actual OTK error information?

 

Thank you,

Roman

 

 

[Stephen Hughes]

Roman,

 

The overall SOAP Fault returned can be controlled using Cluster Wide Properties (soapfault.***) to change the format and content-type and such. For strictly the OTK OAuth token endpoint, you would be better off customizing the policy to suit your needs. You already know how to modify the Error Message so simply putting in catch points will allow you to gather the information as it goes through.

 

Sincerely,

 

Stephen Hughes

Broadcom Support

[Roman PENA]

I tried this route, using the Cluster Wide Properties. Looks like is the way to go, I can have a customized error response and it does not override any error coming from OTK.

 

Thank you Stephen

[shobhit saxena]

Just to assist here, if I understand your query correct: 

You want to override the response created from custom error response assertion to send some custom response to the user.

 

Please find attached policies that can help achieve this. It contains one service and a message-completed global policy.

Logic is before the "raise error assertion" store your error code and error message to variables starting with service.<name> , these variables will be available in message completed. 

So you can check if ${response.http.status} is 0, then return the custom error that you intend using the Service.<name> variables.

Attachment(s)

testpolicies.zip   1 KB 1 version

[shobhit saxena]

In above example, from raise error response would have been code 500 : internal server error .

While message-completed policy overwrites it to below response that user receives: 

HTTP/1.1 400 Bad Request
Server: Apache-Coyote/1.1
Connection: close
Content-Type: application/json;charset=UTF-8
Content-Length: 94
Date: Wed, 03 Apr 2019 17:57:56 GMT
Connection: close

{
"status": "400",
"error": "Invalid Request",
"message": "Missing or duplicated parameters"
}

[Roman PENA]

Hi Shobhit,

 

Thank you for sharing the example. We have a different approach, we don't raise errors from the code we write, we structure the code in a way that services will always finish gracefully and giving a response object.

 

Something like this:

- At least one assertion must evaluate to true

   - All must be true

      <policy logic, routing, etc.>

      - Return template Response to Requestor

   - All must be true (Error)

      - build our standard error response

      - Return template Response to Requestor

      - Stop processing

 

As you can see we don't use neither "Raise Error" nor "Customize Error Response" assertions.

 

All I want is to customize the default SOAP error response given by the Gateway but when I do that any error coming from the code that we don't control (e.g. OTK) will be captured and replaced by the "Customize Error Response" on the "Global Message Received" policy. Maybe I should look for a different approach.

 

Thank you,

Roman

[shobhit saxena]

https://communities.ca.com/ideas/235735714-custom-error-response-should-update-responsehttpstatus-responsemainpart-variables

 

This was the idea created out of ticket. 

 

Stephen: do we have any update on this being considered for development ?