I have a very complicated and big project. There are so many web service calls inside project. All service calls are logged in different tables on database. I need a central log mechanism to avoid all these different log tables.
I think there must be something like Soap Toolkit on client side to catch all service calls. How can I catch the calls and responses to log them to a desired database.?
First of all, it is not a good idea to log to a database. There are several reasons for it, e.g. if, for some reason, there is an exception related to database, it will never get logged.
I would recommend using Log4net from Apache. Here is a good article on how to use log4net in asp.net project. It is a highly efficient and configurable method of logging.
Related
I want to log exception in my project through global.asax file into database but from my presentation layer I won't be able to access the data layer because my presentation layer communcicates with data layer via webservices, so my question is should i create service to log exception to my database.
this is my architecture
Should I create a service to log exception to my database?
No.
If an error occurs in your web service, log it in your web service. Don't propagate that error to the UI and expect the UI to report that error back to the same or another web service.
It's another story if you want to report errors that occur in your UI. You could opt to report such errors through a service, but what if the error is network-related and the log service is unreachable? Rather log as local to the application as you can.
It depends on what you mean by errors in the presentation tier. Errors in the server side code, e.g. WebForms code behind? Or errors in the user's browser? If the latter, you obviously need some network-based service (there are many third party products for collecting errors in browsers by embedding a bit of JavaScript)
As for your server side components, don't think of logging as a mechanism of your data layer just because it writes to a database. Think of it as a cross cutting concern that just happens to be implemented via a database at the moment. I would simply use a standard logging library such as Log4Net or Serilog for this across the layers, not attempt to wrap it in your own abstractions within the data layer.
You also generally don't want to use exactly the same persistence configuration for logging as for data access in general. For instance logging should often be performed to a separate database for operational reasons such as backup policies. Enlisting your log writes in the same transaction management mechanism as your business data access is also a recipe for accidentally rolling back writes to the log when an error occurred, leaving without any knowledge of the error.
Generally, I would inject TraceListeners and adjust trace level through app.config and Web.config. And I understand that IIS will restart the Web app after the Web.config is updated and the last HTTP request is done and new HTTP requests will be pending before the new instance is created. I have been doing this for years no problem.
However, if I deploy the Web app to Azure managed services, or I have many (clustered) instances of the Web app, I am not sure if updating / uploading Web.config to each instance is still a good practice? Is there some alternative/better method to change the trace level for System.Diagnostics.TraceListeners?
And what if I deploy to AWS or alike for clustered services?
You got it right! updating / uploading Web.config to each instance is not bad but could be tedious task,or error prone approach. Rather,
Would recommend to go with Application Insights,an extensible analytics service that monitors your live web application.
Just install a small instrumentation package in your application, and set up an Application Insights resource in the Microsoft Azure portal.
Performance impact would be minimal as,tracking calls are non-blocking, and are batched ; sent in a separate thread.
Telemetry types such as 'Exception traces from both server and client', 'Diagnostic log traces' and many more helps you understand how your app is performing and how it's being used.
Also you can perform Diagnostic search on instances of requests, exceptions, custom events, log traces, page views, dependency and AJAX calls.
For more information do read : Application Insights - introduction
Thanks,
Kasam Shaikh
I have a web service; let's say that this web service does many calculations, it consumes a lot of memory resources. If my web services is call by 2 different clients, then the server will consume twice the resources. is it possible to limit my service to being used by one client, but not by using user authentication?
One idea that I have is to know when the service is being consumed, so if another user wants to use the service, it will receive a message that the service is been used by another user.
I know that one of the major goals of web services is to allow many users, and limiting the concurrent users is not a good idea. I am just curious if it is possible and how to do it, where can i find the documentation so i can learn the process.
If this is a WCF based service you can achieve the desired result by looking at the Instancing and Concurrency options available.
More info here
My current project structure is made to do logging of exceptions and such into the database instead of log files.
In order to log down details, it goes through web services of another project (logToDBService).
So I'm wondering that if by chance the web service fails, I will not be able to log down new message.
To counter this, for those failed logs, I thought of logging it down into csv so it can be uploaded into the database manually.
And for this to handled by the system without configuring additional permission, what I can think of at the moment is to introduce a web service (logToCSVService) directly in the same asp.net application, so when the logging at the logToDBService fails, it execute logToCSVService.
I use log4net. It can handle database, files, email etc.
We've used ELMAH for logging errors to a database and also to an email address as a backup. It works quite well and has a lot of developers supporting it. Check out more about ELMAH here:
http://code.google.com/p/elmah/
I would like to have a Traffic COP or Controller WCF Web Service that doesn't do anything with data but instead gives orders to another WCF Web Service to do so.
Could someone give me an example of how this might be able to be done. It would be preferable that I was not getting into any APM stuff. Instead just an observer who later gets to spin another one way contract to a WCF Web Service when it needs to after it sees that there are no more other WCF Web Services with the same meta data in memory or processing currently.
If this is impossible please say so. Unless you know a small example of how it is done. Maybe a pointer where somebody has already covered the topic?
Thanks apolfj
I don't really understand your question, but maybe this will help:
MSE is a "service virtualization" approach
Stocktrader has a WCF load balancer included in it.
Maybe one of them will fit your needs.
Having a 'traffic cop' service that all traffic goes through before it gets to the actual web service for processing will add extra overhead to your solution. Then you also have issues like once you've logged a call going to a particular web service, how do you find out if the response was successful? Then you hvae to do more logging of some sort and finally return the result to the client. If I understand what you were saying correctly (which I'm not entirely sure I do) you would be looking at something like;
Client -> TrafficCop -> Service1
Client -> TrafficCop -> Service2
OR
Client -> Service1 -> TrafficCop
...depending on where you want the entry point and what you need to do.
I would probably remove the traffic cop web service entirely and implement some API's for your service to implement and have each web service log some information before a service operation is called and after the operation has completed. I'd recommend you take a look at this link; http://msdn.microsoft.com/en-us/magazine/cc163302.aspx which covers behaviours, operation invokers and paramter inspectors.
This way each web service can log information, check access, rules, report errors before and after execution to a database or another TrafficCop web service if you really want. But I'd probably be inclined to just stick all that information in its own database. Thus each web service (depending on what you're doing) may have connections to two databases. One for the web service itself (if that's needed) and one to the TrafficCop / logging database.
At a later date you then may choose to add a website that pulls all the information out of the traffic cop database and allows you to easily browse / search it. It could highlight warnings or other issues your web services logged.
Summary
If all you need to do is logging and related functionality I would consider having each web service log and / or check rules and other things before and / or after a service operation is invoked. At a later date you could consider adding an admin site that surfaces all this information so you can easily keep an eye on how your web services are performing. You may even like to log information like how long it takes to respond to certain requests.
If this is not what you are after I would suggest you add more information and continue to keep your original question up to date.