Lifetime of a busines rule policy

These are 3 different states of a policy:

1. Editable - this is the initiate state of a new policy. In this state, you are able to add, remove, edit. You can also "save" the policy for later editing.
2. Published - after a policy has been published, it becomes read-only. In this state, you can remove it, but you cannot move it back to its initiate state (Editable). The policy is not available for execution in this state. This is considered as staging state before deployment.
3. Deployed - this is the state where the policy can actually be used by using the call-rule shape or the policy class. In this state, it cannot be removed. It has to be un-deploy to "Pulished" state before a policy can be removed. Once policy is un-deployed, it will not be available for execution any more.

ContextAdder XMLReceive Pipeline Component (with BRE or XML configuration)

I came across Jon Flander's very useful ContextAdder pipeline component a while ago. I found it to be very useful. In short it's a pipeline component where

"you can place in any stage of either a Receive or Send pipeline, and you can configure it with a collection of Context properties (simple written properties or promoted properties). The component will just blindly put whatever values you configure it with into the context. This is just useful as a generic way to add properties into the Message Context when needed (and it is needed pretty often - at least I need it pretty often)."

Though I love the tool very much, I found a limitation with the tool where the number of context properties can be written/promoted has to be defined at development time ONLY. Having said that, I think it would be great if the number of context properties to be written/promoted can be configurable to any number of context properties at runtime.

In order to do that, base on Jon Flander's sample code, I created 2 Context Adder pipeline components, which base on BRE and XML configuration.

1. BRE Context Adder Pipeline Component: It calls the rule engine in the pipeline, the result of the policy will return the context properties (with namespace, key and value) to be written/promoted in the message context.

sample code and sample MSI could be found here at my hotmail skydrive

2. Context Adder Pipeline Component with XML configuration:

sample code and sample MSI could be found here at my hotmail skydrive

Here is a sample of the configuration XML. As you can see, the number of context properties to be written/promoted is highly configurable. New property could be added/removed anytime during run time.

<tns:ContextAdder xmlns:tns="http://GML.BizTalk.ContextAdder.Schemas" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
 <tns:ContextProperties>
  <tns:ContextProperty>
   <tns:Key>EnableOrchestrationDebug</tns:Key>
   <tns:Namespace>http://GML.BizTalk.PropertySchemas.DebugFlag</tns:Namespace>
   <tns:Value>true</tns:Value>
   <tns:PromteProperty>true</tns:PromteProperty>
  </tns:ContextProperty>
  <tns:ContextProperty>
   <tns:Key>EnableAllDebug</tns:Key>
   <tns:Namespace>http://GML.BizTalk.PropertySchemas.DebugFlag</tns:Namespace>
   <tns:Value>true</tns:Value>
   <tns:PromteProperty>true</tns:PromteProperty>
  </tns:ContextProperty>
  <tns:ContextProperty>
   <tns:Key>EnablePipelineDebug</tns:Key>
   <tns:Namespace>http://GML.BizTalk.PropertySchemas.DebugFlag</tns:Namespace>
   <tns:Value>true</tns:Value>
   <tns:PromteProperty>true</tns:PromteProperty>
  </tns:ContextProperty>
 </tns:ContextProperties>
</tns:ContextAdder>