Custom Generic Logging for WFC WebServices

TGH Word Cloud


WCF stands for Windows Communication Foundation. A communication-oriented set of APIs and a “runtime” inside .NET to make two (or more) systems talk to one another. It basically replaces ASMX (ASP.NET web services), .NET remoting (object remoting) and a few other communication-related API’s and products in the .NET space. It can and should be used any time two systems (apps, machines) need to exchange information, basically. It’s the foundation for all “connected systems”.

Web Services

When building a web services, the main goal we have is to exchange information between two different machines, and normally this two machines would different owners (would it be the same owner he could access info directly in database). In this situation is very useful to keep custom logs of all requests and responses made to endpoints, for several reasons such as: compliance policy, future debugging of some disparities between systems, report generation, etc.

Inside a wcf web service we would have a file with .svc extension, which is going to be an entry point to our services we exposing to someone, let’s call it access layer. Normally our access layer would serve us as a routing layer and then go to the service layer (validation rules, business logic, etc.…) and then to the data layer (database access.).

Logging Services Layer

So in this architecture we can create one more layer between access layer and service layer, which going to be our generic wrapper and will perform a logging of any information that comes in and goes out.

public static class LoggingServices


private readonly Log Logger = LogManager.GetLogger(“LOG”);

/// <summary>

/// Logs the request occurence to a specific method

/// </summary>

/// <typeparam name=”T”>Input Type</typeparam>

/// <typeparam name=”Z”>Output TYpe</typeparam>

/// <param name=”action”>Reference to the method to be executed</param>

/// <param name=”request”>input to be passed to the method</param>

/// <returns>returns the output of typespecified in Z</returns>

public static Z HandleRequest<T, Z>(Func<T, Z> action, T request) {

try {

var ctx = Guid.NewGuid();

var jsonEncodedRequest = JsonConvert.SerializeObject(request);

Logger.InfoFormat(“{0} Calling method {1}”, ctx, action.Method.Name);

Logger.InfoFormat(“{0} I: {1}”, ctx, jsonEncodedRequest);

var response = action(request);

var jsonEncodedResponse = JsonConvert.SerializeObject(response);

Logger.InfoFormat(“{0} I: {1}”, ctx, jsonEncodedRequest);

return response;


catch(Exception e) {

//Log exception here

throw e;




so that way we can create a new class called for example LoggingServices, then inside a class lets create a static method called HandleRequest, which basically will handle our input, log data about the request, execute method we want to execute, and finally after returning an output, it will log some useful data related to the output. Also in case of exception we will make a log of the exception.

Then inside the .svc file we will replace call to our service layer by something like this:

public OutputType GetData(InputType input) {

return LoggingServices.HandleRequest<InputType, OutputType>(MethodWeWantToCall, input);


External Libraries

Two external libraries that we will use here are Newtonsoft.Json and log4net. Log4net will enable us to manage our log files. Since we want to store either input or output, with that values, we need to have a friendly way to do that. Our option here would be a Newtonsoft.Json. With that library we can convert our objects to the Json format, and then to string, and then write that string to the log. So it will become more readable and easy to be interpreted. Also in the future we can use that logs as is to convert them back to c# objects in order to simulate requests, etc.

Main advantages

Let’s see what are the main advantages of that approach, they are: Possibility of handle log of all requests and responses in generic way, without repeating the code. Possibility to customize as we need our logging (in other cases we could use native windows iis logging which is not customizable). And finally, since we storing everything in json format, the logs we storing could be easily used again by the system.

Author Bio

Aaron Jacobson is a web developer working at Technoligent – Development Company. You can contact her in order to hire senior developers to avail the highly Java programming and web service. He has several years of experience in the field of web development.

Leave us a message...