In my TIBCO BW project I have one process which has some activities like mapper, http, jms etc and I have caught activity also. But I want to catch all the errors created by HTTP activity not other activity errors .
Please help me on this .
I can suggest you two solutions.
The first-one consists in catching explicitly the exception from the HTTP activity using an "error" branch
The second-one consists to catch the different exceptions throw by the HTTP activity exceptions (HTTP Client exception, HTTP Server Exception, HTTP Communication Exception)
Related
I have a rest API with POST Method where I am posting and receiving success response as JSON format which works absolutely fine. During the failure I receive
Error details: System.Net.WebException: The remote server returned an unexpected response:
(400) Bad Request The creation failed because the name or email address of the is invalid
Which I see in Application log and send port gets suspended. I need to capture this in the BizTalk Orchestration where I need to send email if I get any error response.
As the Error Response is not in JSON format don't know how it can be handled. Any idea?
Enable Routing for failed messages on the Send Port to stop the suspended messages. You might have to update the filter in the send port that subscribes to ErrorReport.FailureCode Exists to exclude your API send port if you only want to handle these in the Orchestration. If you don't have such a port, you might have to create one, and send the failed messages to a NULL adapter or similar.
Have your Orchestration have an scope with an exception block to catch System Exceptions, in there have Exception = SystemException.ToString(); in an Expression shape where Exception is a System.String Variable, and SystemException is the Exception Object Name you defined in the Catch block.
Have logic in your catch block that decides what sort of exception you got, I use a If shape with Exception.Contains("XXXX") where XXXX is text in the exception, or handle it however you want.
I'm struggling to find any good examples on how to implement error handling with Spring WebFlux.
The use case I want to handle is notifying HTTP clients that a stream has terminated unexpectedly. What I have found it that with the out of the box behaviour, when a stream is terminated, for example by raising a RuntimeException after x items have been processed, is handled too gracefully! The client is flushed all items up until the exception is raised, and then the connection is closed. As far as the client is concerned the request was successful. The following code shows how this has been setup:
public Mono<ServerResponse> getItems(ServerRequest request) {
Counter counter = new Counter(0);
return ServerResponse
.ok()
.contentType(MediaType.APPLICATION_STREAM_JSON)
.body(operations.find(query, Document.class, "myCollection")
.map(it -> {
counter.increment();
if(counter.getCount() > 500) {
throw new RuntimeException("an error has occurred");
}
return it;
}), Document.class);
}
What is the recommended way to handle the error and notify the HTTP client that the stream terminated unexpectedly?
It really depends on how you'd like to communicate that failure to the client. Should the client display some specific error message? Should the client reconnect automatically?
If this is a "business error" that doesn't prevent you from writing to the stream, you could communicate that failure using a specific event type (look at the Server Sent Events spec).
Spring WebFlux supports ServerSentEvent<T>, which allows you to control various fields such as event, id, comment and data (the actual data). Using an Flux::onErrorMap operator, you could write a specific ServerSentEvent that has an "error" event type (look at the ServerSentEvent.builder() for more).
But this is not transparent to the client, as you'd have to subscribe to specific events and change your JavaScript code otherwise you may display error messages as regular messages.
I am looking for an approach to debugging this scenario. I have verified in Fiddler that there is no HTTP response at all. To be clear, as I understand it a controller method should not simply hang, there is no exception. I have verified the lack of response in Fiddler. The method returns a valid object, verified by stepping through the code to the final return statement.
This is different from the original question in that the controller method is hit, and was not before. The reason for this is explained in the original question. ASP.NET Web Api. Controller not hit. No response at all. Approaches to diagnose?
UPDATE
I am now seeing this behaviour, even though the request completes the handler and returns 200
ExtensionlessUrlHandler and "Recursion too deep; the stack overflowed"
1506. -GENERAL_REQUEST_END
BytesSent
6069
BytesReceived
436
HttpStatus
200
HttpSubStatus
0
From near the end
ErrorDescription
Internal Server Error
0 ms
Warning
1170. -MODULE_SET_RESPONSE_ERROR_STATUS
ModuleName
ManagedPipelineHandler
Notification
EXECUTE_REQUEST_HANDLER
HttpStatus
500
HttpReason
Internal Server Error
HttpSubStatus
0
ErrorCode
Recursion too deep; the stack overflowed.
(0x800703e9)
This turned out to be a crashed instance of RabbitMQ in combination with OWin middleware that was trying to use that instance (to log exceptions such as being unable to connect to the MQ instance; or rather attempting to log them by sending them to.. the MQ instance) and was thus swallowing exceptions in a recursive fashion. The stack overflow was caused by re-entering these middleware instances endlessly. The logging middleware was throwing exceptions because it could not log and the exception handling middleware was handling those exceptions by sending them to the logging middleware. Interesting stuff.
In addition to re-booting to cure the crashed and inaccessible RabbitMQ (restarting the service was not enough) the problem was still not resolved (different symptoms as described above) unless the nuget package MassTransit.RabbitMQ 3.3.2 (old version) and the dependencies (including RabbitMQ.Client) which this exact version brings with it, were installed, rather than the latest versions.
I hope this will help someone.
I need some advice on a good exception handling strategy in my webservice.
My web service methods are doing the standard CRUD operations against an Oracle database. Therefore, I have some methods that select data and return a dataset and others that do either an insert/update/ or delete and don't return anything.
Initially, I had all my code in each webservice method in a try-catch-finally catching an Oracle exception. I read some articles on the web that says this is not good and I should only surround something in try-catch if there is a potential for an exception. Now I am thinking that maybe it would be best if I put only my Insert/Update/Delete methods in try-catch-finally blocks.
So my questions are:
Should I put all my methods in try-catch-finally? They all interact with Oracle and could potentially cause an exception. Or should I only do this for the Insert/Update and Delete methods?
I don't really have any requirements on what they want to happen when an exception does occur. I am just going on common sense. I know that they definitely don't want the app to end. I am planning on logging the exception in some manner and re-throwing it to the client. I am doing this when there is an Oracle Exception.
Basically you need to do try-catch on every WebMethod. Since the event won't bubble up, I think there is no other better way.
However, you can use the trick in this post to make your life easier.
The way he does is creating a utility method like this and invoke that method by passing it a delegate to your web method logic.
private T Execute<T>(Func<T> body)
{
//wrap everything in common try/catch
try
{
return body();
}
catch (SoapException)
{
//rethrow any pre-generated SOAP faults
throw;
}
catch (ValidationException ex)
{
//validation error caused by client
ClientError innerError = new ClientError();
//TODO: populate client error as needed
//throw SOAP fault
throw this.GenerateSoapException(
"An error occurred while validating the client request.",
SoapException.ClientFaultCode,
innerError);
}
catch (Exception ex)
{
//everything else is treated as an error caused by server
ServerError innerError = new ServerError();
//TODO: populate server error as needed
//TODO: log error
//throw SOAP fault
throw this.GenerateSoapException(
"An unexpected error occurred on the server.",
SoapException.ServerFaultCode,
innerError);
}
}
I assume you are using ASP.NET WebMethods. My advice is that you always catch exceptions on the service layer, write a log and throw a SoapException. Basically you can try-catch on each service method (WebMethod). If you fail to do so, you would be exposing exception details to the client calling the service and that could be a potential security issue.
I have an ASP.NET Web API web service which throws a SerializationException in certain circumstances. The problem is that I'm unable to trap and log this exception server-side -- the only place it shows up is in the body of the HTTP response to the client.
I registered an ExceptionFilterAttribute as described in Exception Handling in ASP.NET Web API and verified that it works properly when I throw an exception within my controller. Unfortunately the SerializationException is being thrown during the response (after the controller) and appears to be completely swallowed up by ASP.NET. I also tried hooking Application_Error() in Global.asax.cs but it didn't show up there either.
How can I catch SerializationException exceptions during the Web API response?
If, instead of returning an object, you use the ApiController.CreateResponse() method and return a HttpResponseMessage you can then do response.Content.LoadIntoBufferAsync().Wait() and that will force the serialization to happen whilst you are still in the action and therefore can catch the exception.
BTW, Serialization of responses actually happens at the host layers(in HttpControllerHandler, when hosted in IIS and in HttpSelfhostServer, when hosted in SelfHost) which is way below the stack and not immediately after the response is returned from an action.
WebAPI Stack Poster: http://www.asp.net/posters/web-api/ASP.NET-Web-API-Poster-grayscale.pdf
That said, I am not able to come up with a straight forward way to achieve this. This is cumbersome, but may be override the default Xml and Json formatter's WriteToStreamAsync methods and try-catch-log any exceptions?
Alternatively, you can enable Web API Tracing which would log the exceptions happening during serialization. But yeah, if you do not know for the requests which cause the serialization errors, then you might want to enable tracing all the time which i am not sure is something you might want to do.
You can catch all Web API exceptions by registering an implementation of IExceptionHandler.
See Web API Global Error Handling
...there are a number of cases that exception filters can’t handle. For example:
Exceptions thrown from controller constructors.
Exceptions thrown from message handlers.
Exceptions thrown during routing.
Exceptions thrown during response content serialization .
One thing not mentioned in that article is that your IExceptionHandler must be registered, either by GlobalConfiguration.Configuration.Services.Add(...) or via an IoC container configured to be used by DependencyResolver.