BizTalk: Business Rule Engine:
Don’t use vocabulary in development!

 

Why?

 

Because it gives you big headache and so little instead of.

 

Our typical work with the facts in the rules is compounded from the steps:

 

* Changing/Add fact in/to a rule (if fact is in the one of the tabs of Fact Explorer): Without vocabulary we change/add fact in a rule by drag-and-drop it from the Fact Explorer. With vocabulary we drag-and-drop a definition from the Fact Explorer. No difference.

 

* Changing/Add fact in/to a rule (if this fact is not in vocabulary):
Without vocabulary we work as before. With vocabulary we create a new version of our vocabulary (we can not change the old version because it is published (we have to publish the vocabulary otherwise we can not use its facts in the rules)).

 

* Cut the old version of the vocabulary:
In the rules we change all facts from the old version to the facts from the new version. If we have some facts in vocabulary with reference to it from some rule we can not delete the old version of vocabulary with this fact. (I know the free utility for this purpose but don’t recommend it because I had the unpredictable behaviour of the rules after such automatic updates of the facts.)
In the real work it looks like: OK. This rule is near finish. I create a rule set but it use several versions of the one vocabulary and I don’t like it. I want to cut the old versions. (I don’t like to deploy many versions of one vocabulary. It creates absolutely mess.) I have to manualy upgrade the facts, change old version to a new one, then delete old versions of the vocabulary. But… the vocabulary is “near” finish. Oops, I need change one more fact inside (and create one more version). It’s always “near”…
When I work with the rule I can cange and it, change it without creating a new rule version. But with vocabulary it is completely prohibited. I can use vocabulary and test it only after publishing (“freeze and use”).
OK. I’m trying to separate one vocabulary to two. One is the “Stable”, the second is “Mutable”. It can make my life easy. Wow, how interesting. I was thinking the vocabulary helps me to keep in mind less entities, but now I have to create an additional infrastucture…
BTW I don’t understand why we can’t freeze the vocabulary with policy together.

 

One more time.
A new fact: Without vocabulary I drag-drop new fact to the rule.
With vocabulary I have to:
1. create a new version of the vocabulary.
2. add a new fact to it. And it is NOT short way! I do not describe here the odds of this step.
3. Save and Publish (and, maybe, Deploy) new version.
4. drag-drop new fact from vocabulary.

 

Additional work:
1. creating a definition in the vocabulary.
2. changing the old definition in the rules on the new definition from the last version of vocabulary.
3. managing versions of the vocabulary.
4. in deployment: creating, deploying and managing the vocabulary.

 

Pro for Vocabularies:
* short names of facts in the rules. But in the rules we do not see “very long names” (not like “xpath-names” in maps: “/*[local-name()=’EDI’ and namespace-uri()=’http://VPA.EDI.Schemas.EDICanonical’]/*[local-name()=’VesselID’ and namespace-uri()=”]”), we see readable names as “VPA.EDI.Schemas.EDICanonical:EDI/VesselID”. It is very “small pro”.
* readable names and formats for the facts. It is a good Pro for the end users.

 

Conclusion: I can see only one case when a vocabulary worth all this additional headache: If we have very stable rule set in the production and we can give it to the end power users (BTW never seen this mythic user).
In the real development never