CODEWITHSUNDEEP
wcf
vallorn
vallorn

Reputation: 75

IClientMessageInspector CorrelationState

I can't find much information on the return value for the BeforeSendRequest method of the IClientMessageInspector interface. All examples I've found always return null. From the description on MSDN, this method's return value is passed back as the correlationState argument once AfterReceiveReply is called. However, MSDN also states that the best practice is to use a GUID for the correlationState.

This statement is somewhat confusing to me as I am interpreting it to mean that I am supposed to use only GUIDs for the correlationState. What I want to do is use the xml content of the request as the state so that if the reply is a fault, I can log both the request and reply. I only want to log the request if the reply is a fault.

Does anyone have any experience with using the correlationState? Can I use it for what I want to use it for? It appears to work in testing but due to the limited amount of information I've found on this, I am worried that there may be some kind of pitfall that I'm not seeing.

Upvotes: 4

Views: 1822

Answers (1)

Or p
Or p

Reputation: 91

The CorrelationState, as it's name, designed to help you to find the correlation between the sent request and the received reply. Therefore, because GUID is a unique identifier, MSDN recommends to use it as the correlation state.

At the BeforeSendRequest and AfterReceiveReply methods you can log both correlation state value and Messages object (using CreateBufferCopy / CreateMessage and other Message class operations) and do the match between sent request and received reply.

Note that in this solution (and any other pure WCF solutions, BTW) you can't log the request only if the reply is fault. It's because there is no place in the WCF pipeline you have both request and reply.

The only chance to do so, as you mentioned, is to use the message (as string or Message object - again, using Message class operations) as the correlation state. This is not necessarily a good idea if your service logic can got success reply and fault reply for the same input (for example if your logic depends on external resources as database or other service).

Upvotes: 6

Related Questions