Modify An Existing BRE Policy and Vocabulary

Use Case:

This was an old project having a vocabulary which was used in multiple policies / multiple version of policies.

The need was to add a new definition to be used in an existing policy. One way to do this was to add a new vocabulary and use it. This option was ruled out because it would have added an additional vocabulary collection thus making it look cumbersome.

 

Reversion the vocabulary and add the new definition in it – this as well was ruled out since the current version of the vocabulary was used in many Policies – implying a need to update the reference of used vocabulary definition in each Policy.

Undeploy all the policies using the vocabulary in question, followed by undeploying the vocabulary. After that, modify the bindings and redeploy vocabulary followed by the policy. This option was not opted out because of the complex nature of the BRE policies using the same vocabulary version. – Ideally speaking this is the option we should pick for any such needs.

 

Having said that there was an unconventional route taken to accomplish the need.

** **

Modify a published Vocabulary

The vocabulary state is stored in nStatus filed under the table – re_vocabulary in – BizTalkRuleEngineDb. For each vocabulary, there is a separate row.

 

It has two states 1 and 0. 1 indicates the Vocabulary is in Published state and 0 indicated it can be modified. Hence the corresponding vocabulary row – the nStatus field was edited to 0, making the vocabulary editable. Subsequent to it the new definitions were added using the Business Rules Composer.

 

https://psrathoud.files.wordpress.com/2017/11/1.png?w=630

 

** **

Modify a published Policy

 

Policies state are stored in re_ruleset table column nStatus. It has three states.

 

0 Saved

1 Published

1 Deployed

 

Notice the Published and Deployed state value are the same. For a policy, it is differentiated by the entry in the table re_deployment_config. For any policy( nRuleSetID value) which is present in re_deployment_config and re_tracking_id table indicates that should be in the deployed state.

 

For example, .we have to modify the Rules PKS_DemoPolicy version 1.0 without incrementing the version. First, we need to get the nRuleSetID from re_ruleset table. This will be used in deleting respective entries in re_deployment_config and re_tracking_id . 

 

https://psrathoud.files.wordpress.com/2017/11/getuidpolicy.png?w=630

 

Once identified go ahead and undeploy the policy PKS_DemoPolicy .

https://psrathoud.files.wordpress.com/2017/11/undeploy.png?w=630

 

Subsequent to that change the nStatus Column using the following query.

 

 update [BizTalkRuleEngineDb].[dbo].[re_ruleset] set nStatus= 0 where nRuleSetID = ‘**Your nRuleSetID’

 

 

Next, delete the entry for your PKS_DemoPolicy  in re_deployment_config

 

Delete from [BizTalkRuleEngineDb].[dbo].[re_deployment_config] where nRuleSetID=’**Your nRuleSetID’

 

Delete the entry from re_tracking_id table 

 

 Delete  FROM [BizTalkRuleEngineDb].[dbo].[re_tracking_id] where nRuleSetID=’**Your nRuleSetID’

 

Once done go back to Business Rule Composer and refresh. The policy state should be editable. Please leave a comment if you have any questions and I will get back as soon as I can.

Disclaimer – The approach taken here is not recommended by Microsoft and please use it at your own discretion.