BizTalk - Edit and re-publish Policies and Vocabularies
When working with BizTalk's Business Rules Engine (BRE), one of the issues all face is that once published/deployed, vocabularies and policies become immutable. For a project that is in development this can cause lot of pain since there will be unnecessarily too many versions as the vocabularies and policies evolve. While taking this to production we can definitely pick the latest and final versions and deploy them, but to help make development more easy we can do a bit of under the hood work with the BRE database.
Even though I haven't faced any issues in the rules execution by following the approach discussed below, I will strongly discourage using this on Production systems.
Direct editing of BizTalk databases isn't a good practice and if alternatives are available, they should be used. Like in this case, one can use Policy Verificator from Acumen Business. This is a great free tool to have, but you do need a login id on the site to be able to download. A version of Policy Verificator that will work with BizTalk 2006, however, is ccurrently not available.
OK, back to the discussion. To revert a vocabulary from its published status to saved status, so that you can edit it, go to re_vocabulary table in BizTalkRuleEngineDb (this is the default DB name). For the vocabulary in question, alter the value in nStatus column to 0 (saved) from 1 (published). You can now go back to the Business Rules Composer and work with vocabulary like any other and publish it again from the composer when done. You could also republish this by once again setting the nStatus column value to 1, however publishing from Composer is easier.
Unlike vocabulary, policies have three states - 0 (saved), 1 (published) and 1 (deployed). Notice that though the states are three, the value of "1" is used to represent both published and deployed policies. So how do you distinguish the two states? If there is an entry in the re_deployment_config table for the policy (re_deployment_config.nRuleSetID = re_ruleset.nRuleSetID) in question, it is deployed else published. In either state, there will be an entry for the policy in the re_tracking_id table. Incidently, the deployment status is additionally tracked via re_deployment_history, which captures when a policy was deployed and also undeployed.
Armed with this knowledge, it is easy to see that we can once again alter the nStatus column value to 0 in the re_ruleset table to make an already published/deployed policy available for editing via the Composer. However just doing this will result in a primary key violation on the re_tracking_id table when you try to re-publish such a policy via the Composer. You can hence take two approaches
- First undeploy the policy using the Composer. Then change nStatus column value to 0 in the re_ruleset table. Finally delete the matching row (on nRuleSetID) from the re_tracking_id table.
- Change the nStatus column value to 0 in the re_ruleset table. Delete the matching row (on nRuleSetID) from re_tracking_id and re_deployment_config tables.
Having done either of the two steps above, launch the Composer and edit the policy as required and then publish and deploy again from the Composer itself.
There will be some delay before you will start seeing your new policies/vocabularies in action as per the polling interval (default of 60 secs) for the Rules Engine Update Service.