This content has been marked as final. Show 10 replies
You can't really change these as they are standard. What this is saying is that your request does not conform to your proxy service.
Fix the xml / requst call and you will be right.
test via the debug window in the OSB console.
I dont think I completely understand. I am trying to -generate- an error code via HTTP status code, if there is a validation error within my proxy. I want to send the user back an error. So simply put, I cannot send back -any- type of error from my REST service (my proxy service in the OSB).
Thank you so much.
The issue is if your request is not using the right protocols OSB will never accept it hence rejecting the request with a HTTP-400 Bad Request.
An example is if you have set your message to be any xml and someone posts unstructured XML, or invalid XML. It will be rejected with a HTTP-400.
If the message is XML and is valid but does not conform to your business rules then you can respond back with a custom message.
What type of error do you want to send.
I tried modifying the $outbound (in ./ctx:transport/ctx:response/http:http-response-code), but there's nothing in $outbound when I go to edit it even. I do not even know if this is the right track of how to get the OSB to modify the HTTP status code.I assume you have proxy and in pipeline you are checking the input data and want to set the response of the proxy to 400
In this case you should be setting the $inbound instead of $outbound. Please try setting below variable and see if it works. OSB is not guaranteed to honor some values we set like content length etc. Hopefully setting below variables should work.
$inbound/ctx:transport/ctx:response/tp:response-code (may not be related to your use-case)
$inbound/ctx:transport/ctx:response/http:http-response-code (this is what you might be looking for)
If OSB doesn't honor your values, request to raise a support ticket for this valid enhancement.
Edited by: mneelapu on May 8, 2009 9:23 AM
Edited by: mneelapu on May 8, 2009 9:24 AM
Thanks for that. I tried changing the values for:
in the response pipeline and that didn't do anything. The response from the proxy was still fine, even though I verified the $inbound variable was being changed. Then I tried it in my error handler in the request pipeline. That still didn't work. The response from the proxy to my browser was just fine. I had changed the values to '404' for both cases. How do I go about opening a ticket? It says I need to have purchased the product to get support but I haven't purchased this.
To answer James, all I am simply trying to do is return a 400 http status code error back to the invoker. So let's say he does a GET on http://myurl?q=5 and that doesn't pass validation in my OSB proxy based on my -internal- rules within the proxy. It's a valid request in that it will reach the OSB just fine. Then I want to be able to configure the proxy to return an http status code of 400 back in the response. Do you know of any way to configure the proxy to send back an http status code like 400, 404, 500 so that the invoker will get an error?
Are you using the Validate Action. This will validate against your XSD if it fails it will return a fault, but I can say if it returns a http error.
We are trying to accomplish the exact same task as you. We have a REST request that we are validating and we want to return HTTP-500 or other value to the caller if the request is not valid based on our internal rules. We also tried to modify the inbound error codes as you did and we had no success. Also, according to the ALSB documentation it seems a Reply with Failure action should cause a HTTP-500 to be returned but this doesn't work for me either.
Did you make any progress on making this work or did you submit a support case?
Thanks for any input,
Did this get resolved?
Inserting (if not present) an 'http:http-response-code' element with the desired code into the 'inbound' variable under './ctx:transport/ctx:response' seems to do the trick. Please note I've done this in the response pipeline.
In my particular scenario, the OSB proxy is being used as a proxy to the actual service implementation. The route node simply passes on the request onto a restful service (Java web application deployed on WebLogic) and I am then passing back the returned HTTP status code by inserting '$outbound/ctx:transport/ctx:response/http:http-response-code' as outlined above.
Could you give me a few more details on how you managed to make that work on a real scenario? I'm trying to do it but the http:http-response-code node never appears correctly and the HTTP response code is always 500.