This is cache of http://www.pluralsight.com/community/blogs/keith/archive/2008/02/14/50250.aspx. Cache is the snapshot of article that we took when we index feed.
To see original page click here.
We are not affiliated with the authors of this article and not responsible for its content.
Workflow Services Context
2008-02-14 20:35:00 by keith-brown in Security Briefs
 

The cool new wsHttpContextBinding and friends silently manage a workflow instance id for you under the covers. The first time you make a request through one of these bindings, a workflow is created, and the instance id is sent back to the client via a SOAP header. It's then stored in the channel and sent back with every subsequent request so that further requests can be routed back to the same workflow instance.

That's all well and good, but what if you want to contact an *existing* workflow? You'll need to communicate the workflow instance id to the channel manually. This is possible by querying the channel's context. You'll need to add a reference to System.WorkflowServices (if you've not already got one). Once you do that, you can use this code to get the InstanceId guid from the channel:

This code was tested with Visual Studio 2008 RTM.

// note if you're using a code-generated proxy, you'll need to use channel.InnerChannel
IContextManager contextManager =((IChannel)channel).GetProperty();
IDictionary ctx = contextManager.GetContext();

// read the instance ID from the context...
Guid instanceId = new Guid(ctx["instanceId"]);

// or, maybe you need to update the context of a new channel...
ctx["instanceId"] = instanceId.ToString();

// ...and set it back on the channel (or a new channel)
contextManager.SetContext(ctx);

Hope this helps - I'm recording this mainly for my own recall :)

 
 
 
 
 
 
TOP SEARCH
Expand / MinimizeClose Widget
  •  
RECENT SEARCH
Expand / Minimize
  •  
RELATED VIDEO
Expand / Minimize
SecurityRatty FAQ
Sergey Zarubin, 31yo
CISSP, CCSP
Moscow, Russia