I have a very simple webservice which is hosted on IIS, if you call any webmethod this basically throws some exception. There is third party application install in the same system where webservice hosted which intercept webmethod and get all information about unhandled exception (like method name, exceptiontype, stacktrace, code etc). Anyone who needs this exception info can subscribe for the eventobject with third party application. So I wrote event subscription code in IIS process itself.
So flow is like this, test client will call webmethod which basically throws some exception, third party application catches those exception and whoever subscribe for exceptioninfo will get those information in XML format.
Now I want that XML information to be accessed in my test client, is there any way to achieve this? I am not sure if this is feasible also or not as I am new to webservice world and please excuse me if this doesn't make any sense.
I found two solution for this problem,
1) Using HttpModule edit the Http response and add the exception info xml in the response itself.
2) have different exe which will run in background and subscribe for the exception info events using API provided by 3rd Party application. Once the exe receive exception information for any failed transaction, exe will write the same information in some shared storage. In my case I am using Azure Table Storage.
Related
Another person asked my exact question here with no answer: Angular 2 Client Side Errors
I'm wanting a way (avoiding additional third party frameworks if possible) to send my client-side Angular errors to my back end exception logger.
My back end is just a .NET Web API project that's connected to our SQL Server database. My server side errors are currently being logged to the database by calling a stored procedure controller whenever a server error occurs (I used KudVenKat's tutorial to build this: http://csharp-video-tutorials.blogspot.com/2012/12/logging-exception-to-database-part-75.html).
Is there a way to write an Angular service which calls my ErrorLogger API to log my Angular errors to the database?
I figure I may have to tweak my back end logger controller since it's using .NET's System.Exception class, which I'm guessing is only good for detecting server side exceptions, not Angular's. I may need an entirely different logger controller and database table for client side errors only - but I'd like server and client side errors logged to the same table if possible.
Knowing this - is what I'm trying to do even a good approach? If not, can anyone give me a high level description of how I might go about logging these client side errors instead?
Angular provides global error handler service for handling the errors.
We can create our own custom error handler service which extends ErrorHandler .
In the handleError method you can call API and pass the client error to server
You can refer https://angular.io/api/core/ErrorHandler
When an exception occurs during execution of a Web.Api controller method in our system, the request is sent to Application Insights as a failure and we send the exception to Application Insights with telemetry.TrackException(actionExecutedContext.Exception);
Behavior:
request is shown as a failure with URL and some other data in the details
exception is shown under Server exceptions with the stack trace shown in the details.
However, when looking at the details of a failed request (due to a server exception), the Exception part does not show the correlated exception - just the default Learn how to track exceptions for failed requests.
When looking at what is sent to Application Insights inside Visual Studio 2017, I see that the exception and request are correlated (same Operation Id).
But it seams that this gets lost on the way to the detail page.
We use ASP.NET WebApi with OWIN, default Application Insights installation (of nuget packages) and applicationinsights-owinextensions (including the steps described there to setup the OWIN extension).
I think How to link exceptions to requests in Application Insights on Azure? does not apply because the data is shown as correlated in the Visual Studio AppInsights Viewer and when clicking Show telemetry for: this operation inside the details view of the exception inside AppInsights.
Maybe related:
Application Insights shows 2 requests for a failure. The first one shows the HTTP Method (e.g. GET) the second one misses the HTTP Method and has a duration that is slightly longer.
Thanks for hints :-)
As you are using applicationinsights-owinextensions, I checked the code for OperationIdTelemetryInitializer that is used to initialize operation id. I believe the reason you're not seeing telemetry linked correctly on detail blades is that this code is not setting operation.parentId field. To verify whether this is correct you can examine the payload sent to check whether parent.id field is set. The initializer that we are shipping in the officially supported .NET SDK sets operation.id, as well as operation.parentId.
So my recommendation is, once you confirm, that parentId is indeed not set, would be to to either fix the OperationIdTelemetryInitializer used in owin-extensions so it starts setting parentId, or replace it in ApplicationInsights.config with your custom one. The latter approach would make it easy to confirm this theory.
The solution was to remove the Microsoft.ApplicationInsights.Web.OperationCorrelationTelemetryInitializer from the application insights config file.
This initializer gets in the way of the initializer from applicationinsights-owinextensions nuget package.
We've inherited a .asmx web service without source code (my favourite).
We've run tests (calling it from a console app with fiddler attached) both internally and externally and it runs clean every time - as it does for the vast majority of our clients.
However, one user is reporting 5xx type errors. We've tried all the usuals (event viewer and IIS logs) but they're all clean. We can't get it to fail at all.
What further options do we have?
Can the clients replicate the error at will?
The error is most likely data related. Have you tested it with the same data that your client is to produce the error.
The error may also be at the client's end during serialization/deserialization of the call in their auto-generated asmx wrapper.
Has there been a change to the WSDL?
Things like ELMAH are great for logging all unhanded exceptions.
add logging to web config, log everything.
decompile the webservice and find the reason.
How do you capture errors that happen on client side when building RIA apps using Flex and Silverlight? What are the common practices? I have seen some asynch js calls to a web service implemented but would like to know how the community is dealing with it.
First, I use client side logging all of the times.
the way I handle it depends on the entire application.
if I use an AMF gateway then there's a call for an application error, with every error that occurs the server is notified, in the server side a bug is open in BugZilla (this is what we use, you can use any other hook you want).
If I use a web-service based application then there's a web-service call for a client error.
one would say you shouldn't sample the server with every error, I disagree with this comment because an error in the client side is rare, it goes thorough QA before being released to the client so I want to know immediately on every error the client is experiencing.
In Silverlight I like to use a WebClient to log back to a web service somewhere -- you can do this directly in the Silverlight application without calling out to JavaScript.
To catch exceptions that are fired when your code isn't on the stack, you can use the Application.UnhandledException event.
I've used the same approach as Avi Tzurel - you need to know on the server side when an error appeared in the Flex client. If you want to collect more data (all the log messages, warnings) I would use an internal buffer and I will flush it asynchronously.
Anyway, you need to take into consideration if your customers are ok with this approach..maybe you need their agreement before sending the error message to the server.
I basically percolate all errors to the top, and capture them in the unhandled exception. I display a friendly message to the user. However, throughout my application I implement an ILogger interface. This interface can be initialized with various levels and handles any messaging. You can set it up so the user can add an init param to determine whether or not to transmit the errors to a service, and I typically have the logger write the messages with Debug.WriteLine if the debugger is attached to make it very easy to trace issues in debug mode.
In Silverlight you may want to consider the Logging and Exception Handling Application Blocks from the Silverlight Integration Pack for Enterprise Library.
And how to fix it. I'd like to log every thrown exception for maintenance purpose.
This is a known issue in .Net - Application_Error never fires for a web service. Not sure if there's any reason it would be by design, but it just doesn't work.
Jeff Atwood had a post (and follow-up) about this a few years ago, with the following ideas:
Put a try-catch block around each web service method
Use a facade design pattern and include the try-catch in parent objects
Write a custom SOAP extension or HTTPModule
The only one I care for is the first one, even though it seems like a lot of work.
Better: HttpApplication.Error event:
Note:
If your Web application contains XML
Web services, you cannot use the Error
event for global exception handling of
those services. The HTTP handler for
XML Web services consumes any
exception that occurs in an XML Web
service and converts it to a SOAP
fault before the Error being called.
To handle XML Web service exceptions,
build a SOAP extension to process Web
service exceptions in a custom global
exception handler. For more
information, see Handling and Throwing
Exceptions in XML Web Services.
For anyone looking for Microsoft's word on this topic, see here: "Handling and Throwing Exceptions in XML Web Services".
This is the relevant section:
A Web application can be comprised of multiple XML Web services, however the Application_Error event within the Global.asax file cannot be used for global exception handling. The HttpHandler for XML Web services consumes any exception that occurs while an XML Web service is executing and turns it into a SOAP fault prior to the Application_Error event is called.