BizTalk: Business Rule Engine: Don't use vocabulary in development

BizTalk: Business Rule Engine:
Don't use vocabulary in development!
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 use vocabulary!
Some Ideas


I won't use the vocabularies now.

Anyway the idea of the vocabulary is wonderful.

In what conditions I'd rather like to use them?


Lets talk.


I'd like the vocabulary be in sync with a policy. That means the changes in a vocabulary should not mean the changes in the policy. Let changes in the policy occur by default.

But the vocabulary is the separate from the policies entity. It can be used by several policies simultaneously.

Lets think about it. One of the solutions is this:

By default a vocabulary is the part of the policy (BTW In the BizTalk it is the part of the policy. When we deploy the policy, we deploy the vocabularies in use with this policy.). In the BR Composer it should be the branch under the Policy node. All operation under Policy: Save, Publish, Deploy, Undeploy should work under (Policy+Vocabulary)ver.xx entity as whole. In this case I don't care about versions of the definitions in the current policy they are always in sync.

 Lets save the current separate vocabularies, but call them "shared vocabulary". If somebody wants to use the shared vocabulary, why don't.

Leonid Ganeline
BizTalk Solution Developer
Print | posted on Monday, October 16, 2006 12:09 PM


# re: BizTalk: Business Rule Engine: Don't use vocabulary in development

left by Acumen Business at 11/30/2006 10:39 AM Gravatar

Not using the vocubulary feature is throwing away some really essential aspects of Rule based systems. That it: defining an enterprise wide terminological component.

I understand the pain with the current implementation of vocabularies in Biztalk.
That is why Acumen Business started to provide tools to update vocabulary references within a policy.

See also the article

I hope this will put you back on the right track.



# re: BizTalk: Business Rule Engine: Don't use vocabulary in development

left by Leonid Ganeline at 11/30/2006 12:39 PM Gravatar

I've tried your tool but sometimes got unpredictable result. Taking in mind that it can be mixed with my errors in the rules it create bad situation. That's why I don't use it. Sure you resolved all issues.

BTW If the Xml and inner format of the Rusiness rules is unpublished by Microsoft there always would be the unsertainty in the result of such tools. What do you think?

# re: BizTalk: Business Rule Engine: Don't use vocabulary in development

left by Charles Young at 12/4/2006 3:46 AM Gravatar
The schema for the BRL is available. It is included as part of your BizTalk installation. You will normally find it at c:\Program Files\Microsoft BizTalk Server 2006\businessruleslanguage.xsd.

I'm caught between the two opinions here. For all the reasons given by Leonid, I try to avoid using vocabularies wherever possible. The Rules Composer is a poor tool for rule development, and the overhead associated with trying to maintain vocabularies and related policies which are both subject to concurrent change is far too high.

On the other hand, vocabularies are a vitally important aspect of bridging the gap between the technical expression of rules using BRL, and the 'real' business rules which define constraints on an organisation. Of course, business terms are, themselves, a form of business rule, and hence vocabularies ought rightly to be seen as a set of constraints on the technical policies created by developers. A root problem is that for so many organisations, there is no maturity in terms of defining and maintaining business rules, and hence rule developers have no clearly-defined business vocabulary to work with. They have to make it up as they go along, and the Rules Composer does not help! However, in environments in which there is a mature approach to identification and management of business rules, there will be well-defined business terms which can be mapped directly to at least some of the technical fact types, predicates, etc. In these environments it is generally worth the pain of using vocabularies. They have real business benefit in terms of traceability, clarity of semantics, etc.

# re: BizTalk: Business Rule Engine: Don't use vocabulary in development

left by Leonid Ganeline at 12/4/2006 8:40 AM Gravatar

Thanks a lot for your comments!

About schemas, I mean they are not "Officially" published. They are accessible but not "fixed". Microsoft can change them anytime without announce. And we cannot safely use this schema without knowledge the relationships between elements and BRE. Yeah we can guess, and Marcos tool is working, but in some cases it creates the different results not like BRE itself.

And I'm absolutely agree about vocabularies: they are the significant part of the Business rules and it is pity I have to avoid them.

# re: BizTalk: Business Rule Engine: Don't use vocabulary in development

left by Acumen Business at 12/4/2006 5:35 PM Gravatar

Thanks for giving the tool a try. Sorry to hear that you sometimes run into trouble. When you mentioned that the Policy Verificator sometimes creates different results, are you refering to functionality that upgrades vocabularies? Could you sent me an example? I probably will be able to solve it rather quickly. I know there is some challenges when vocabularies are using other vocabularies and you try to replace all of them at the same time.

If the difference is about the rule verification, I would be very interested to hear that as well. The rule verification algorithms are indeed independent of the actual inference engine. We try to discover logical errors. And hope that this helps with harvesting the rules and discovering incompleteness. Technical rule execution we try to hide from the Business Rule Writers (they are most of the time not programmers)

We do have a forum and we do our best to resolve issues as quick as possible.

If you are interested we can give you access to the beta release for Biztalk 2006.



# re: BizTalk: Business Rule Engine: Don't use vocabulary in development

left by Leonid Ganeline at 12/4/2006 6:45 PM Gravatar

I've told only about the Vocabulary Upgrader, sorry for inconvenience. The Policy Verificator is completely new for me and I'd like to try it soon.
I agree with Charles, and think that Rule Composer is a skeleton/laboratory appplication.
BTW You need only one step to create a "Policy Crator" on the base of your Verificator! And, please, ecapsulate the Vocabulary to the Rule! (from the users point of view :) )


# re: BizTalk: Business Rule Engine: Don't use vocabulary in development

left by Chinna at 8/10/2011 12:33 AM Gravatar
It is very difficult to update the vocabulory.there is no option to update the has to make new changes of vocabulory and some other issues.
Post A Comment