views:

590

answers:

3

I've got some WCF services (hosted in IIS 6) which use the Enterprise Library (4.0) Validation Application Block. If a client submits a message which fails validation (i.e. gets thrown back in a ValidationFault exception), I'd quite like to be able to log the message XML somewhere (using code, no IIS logs). All the validation happens before the service implementation code kicks in.

I'm sure it's possible to set up some class to get run before the service implementation (presumably this is how the Validation Application Block works), but I can't remember how, or work out exactly what to search for.

Is it possible to create a class and associated configuration that will give me access to either the whole SOAP request message, or at least the message body?

A: 

You could log the whole WCF Message:

http://msdn.microsoft.com/en-us/library/ms730064.aspx

Or you could combine it with Enterprise Library Logging Application Block.

Shiraz Bhaiji
Unfortunately, we have our own internal logging API, and I'd like to use that. I really don't want to bloat the solution out with more EntLib stuff, I just need some way of hooking into WCF and getting the message, before (or maybe after) the validation happens.
Graham Clark
Maybe I'll check the EntLib source code...
Graham Clark
+1  A: 

Take a look at using the Policy Injection Application Block...

I'm currently developing an application in which I intercept (using PIAB) all requests incoming to the server and based on the type of request I apply different validation behavior using the VAB.

Here's an article about integrating PIAB with WCF:

http://msdn.microsoft.com/en-us/magazine/cc136759.aspx

You can create different inteception mechanisms such as attributes applied to exposed operations.

MattK
A: 

I found a blog post which seems to do what I want - you create a class that implements IDispatchMessageInspector. In the AfterReceiveRequest method, you have access to the whole incoming message, so can log away. This occurs after authentication, so you also have access to the user name - handy for logging. You can create supporting classes that let you assign this behaviour to services via attributes and/or configuration.

IDispatchMessageInspector also gives you a BeforeSendReply method, so you could log (or alter) your response message.

Now when customers attempt to literally hand-craft SOAP request messages (not even using some kind of DOM object) to our services, we have easy-to-access proof that they are sending rubbish!

Graham Clark