1

I am creating a WFC Restful service and there is a need to persist a variable that will be persist per user, is there a way I can achieve this without having to pass the variable to all my calls?

I am using trying to log the process of the user throughout the process, weather their request has failed or succeed, IP address, when they requested the action, failure time, etc. Please note I am new to WCF, thanks in advance.

mahlatse
  • 1,322
  • 12
  • 24
  • I'm sure you can, but you shouldn't - see [If REST applications are supposed to be stateless, how do you manage sessions?](http://stackoverflow.com/questions/3105296/if-rest-applications-are-supposed-to-be-stateless-how-do-you-manage-sessions) – stuartd Apr 13 '16 at 13:45
  • Are you looking for an identification for a single request or for multiple related requests? If it's the former then that's still "stateless" - you're just correlating activities performed within that request. – Scott Hannen Apr 13 '16 at 13:48
  • I am looking for a single request, the call will come with a clientID and I would like to carry that value throughout that call without having to make it a dependency for every method call that will be accessed. – mahlatse Apr 13 '16 at 14:06

2 Answers2

0

I recently worked on this (except it wasn't RESTFUL). You could transmit information through HTTP headers and extract that information on the service-side. See http://trycatch.me/adding-custom-message-headers-to-a-wcf-service-using-inspectors-behaviors/

Wicher Visser
  • 1,513
  • 12
  • 21
  • my issue is not getting the value, I have a few layers in my application, so I would like a value that I can access through the layers that will be unique to that specific call. – mahlatse Apr 13 '16 at 14:04
  • Do you have access to OperationContext.Current? – Wicher Visser Apr 13 '16 at 15:19
0

For the client ID itself I can suggest two places to put it. One is OperationContext.Current.IncomingMessageProperties. Another is CorrelationManager.StartLogicalOperation which allows you to define a logical operation - that could be the service request, beginning to end - or multiple operations - and retrieve a unique ID for each operation.

I would lean toward the latter because it's part of System.Diagnostics and can prevent dependencies on System.ServiceModel. (The name CorrelationManager even describes what you're trying to do.)

In either case I would look at interception. That's the ideal way to read the value (wherever you store it) without having to pollute the individual methods with knowledge of logging and client IDs. (I saw from your message that you're trying to avoid that direct dependency on client IDs.)

Here's some documentation on adding Windsor to your WCF service. (At some point I'll add some end-to-end documentation on my blog.) Then, when you're using Windsor to instantiate your services, you can also use it to instantiate the dependencies and put interceptors around them that will perform your logging before or after those dependencies do their work. Within those interceptors you can access or modify that stack of logical operations.

I'm not doing Windsor justice by throwing out a few links. I'd like to flesh it out with some blog posts. But I recommend looking into it. It's beneficial for lots of reasons - interception just one. It helps with the way we compose services and dependencies.

Update - I added a blog post - how to add Windsor to a WCF service in five minutes.

Scott Hannen
  • 27,588
  • 3
  • 45
  • 62
  • I updated this to reference a blog post I did last night that shows how to quickly and easily add Windsor to a WCF service. That, in turn, gives you some interception tools to work with. At a future point I'll do some documentation on interceptors, but the link to Windsor's documentation in the answer will get you started. – Scott Hannen Apr 14 '16 at 20:26