WCF Data Services Processing Pipeline

First I must confess. Even though I like OData and WCF Data Services, in the last couple of months I didn’t have the chance to work or use them. This is why when .NET 4 was shipped, I didn’t notice a new and interesting extension point in the framework – the processing pipeline. In the last MIX11, I got a little introduction to that extension point in Mike Flasko’s session. In this post, I’ll explain the WCF Data Services' server side processing pipeline.

WCF Data Services Processing Pipeline

In the past, I wrote about the Interceptions mechanism that is built inside WCF Data Services. One of the advantages of using that mechanism is the ability to wire up business logic such as custom validations, access policy logic, or whatever you like to insert in the queries/change sets pipeline. The problem starts when you need a generic behavior for all the entity set interceptions. In the first release of WCF Data Services, there were no extension points to use that would help implement generic things. But now, in .NET4, you can use the processing pipeline in order to do that. The new DataServiceProcessingPipeline is a class that is being used as a property of the DataService class (which every data service inherits from). It exposes four events that you can hook to:

• ProcessingRequest – The event occurs before a request to the data service is processed.
• ProcessingChangeset – The event occurs before a change set request to the data service is processed.
• ProcessedRequest – The event occurs after a request to the data service has been processed.
• ProcessedChangeset – The event occurs after a change set request to the data service has been processed.

These events enable the developer to write code that is performed during the process of WCF Data Services pipeline before and after things happen.

Using the WCF Data Services Processing Pipeline

Here is a simple example of how to use the processing pipeline events to write to the output window that the events were called:

public class SchoolDataService : DataService<SchoolEntities>
{
  public SchoolDataService()
  {
    ProcessingPipeline.ProcessedChangeset += 
      new EventHandler<EventArgs>(ProcessingPipeline_ProcessedChangeset);
    ProcessingPipeline.ProcessedRequest += 
      new EventHandler<DataServiceProcessingPipelineEventArgs>(
      ProcessingPipeline_ProcessedRequest);
    ProcessingPipeline.ProcessingChangeset += 
      new EventHandler<EventArgs>(ProcessingPipeline_ProcessingChangeset);
    ProcessingPipeline.ProcessingRequest += 
      new EventHandler<DataServiceProcessingPipelineEventArgs>(
      ProcessingPipeline_ProcessingRequest);
  }
 
  void ProcessingPipeline_ProcessingRequest(object sender, 
                          DataServiceProcessingPipelineEventArgs e)
  {
    Debug.Write("Processing Request was called");
  }
 
  void ProcessingPipeline_ProcessingChangeset(object sender, EventArgs e)
  {
    Debug.Write("Processing Change Set was called");
  }
 
  void ProcessingPipeline_ProcessedRequest(object sender, 
                          DataServiceProcessingPipelineEventArgs e)
  {
    Debug.Write("Processed Request was called");
  }
 
  void ProcessingPipeline_ProcessedChangeset(object sender, EventArgs e)
  {
    Debug.Write("Processed Change Set was called");
  }
  
  public static void InitializeService(DataServiceConfiguration config)
  {                
    config.SetEntitySetAccessRule("*", EntitySetRights.AllRead);      
    config.DataServiceBehavior.MaxProtocolVersion = DataServiceProtocolVersion.V2;      
  }
}

As you can see in the service constructor, I wire up all the events. This is a simple sample but as I wrote, you can put in the event handler logic that performs generic behaviors such as security policies, validations, and etc.

Summary

In .NET 4, there is a new feature inside WCF Data Services that enables to wire up events into the service’s processing pipeline. This is very helpful in scenarios such as business logic that you want to impose on the service execution behavior.