Microsoft BizTalk Server 2006 R2 Standard, IT Disk Kit, MVL DVD 5 MLF D75-01324 Manuale Utente

Codici prodotto
D75-01324
Pagina di 26
15 
 
The BRE is most useful when a complex set of business rules must be evaluated. Deciding whether to 
grant a loan, for example, might entail working through a large set of rules based on the customer’s 
credit  history, income,  and more. Similarly,  determining whether  to  sell life insurance  to  an  applicant 
depends on 
a number of things, including the applicant’s age, gender, and a myriad of health factors. 
Expressing  all  of these  rules  as  conditional  statements  using,  say,  an  orchestration’s  Decide  shape 
might be possible, but it’s not  simple. For rule-intensive processes like these, the BRE can make a 
developer’s life significantly simpler. 
The BRE can also make changing rules faster and easier. To see why, think about what’s required to 
change  a  business  rule  that’s  implemented  within  an  orchestration.  A  developer must first  open the 
orchestration  in  Visual  Studio,  modify  the  appropriate  shapes  (and  perhaps  any  .NET  objects  they 
invoke), then build and deploy the modified assembly. Doing this also requires stopping and re-starting 
the  BizTalk  application  that  includes  this  orchestration.  If  instead  this  business  rule  is  implemented 
using the BRE, it can be modified without recompiling or restarting anything. All that’s required is using 
the Business Rule Composer to change the desired rule, then redeploying the new set of rules. The 
change will take effect immediately. And while orchestrations are typically created and maintained by 
developers, business rules are readable enough that in some cases they can be modified by business 
analysts without the need to involve more technical people.   
The  creator  of  a  set  of  business  rules  will  typically  begin  by  using  the  Business  Rule  Composer  to 
define  a  vocabulary  for  use  in  specifying  those  rules.  Each  term  in  the vocabulary  provides  a  user-
friendly  name for  some information.  For  example,  a vocabulary might  define terms  such  as  Number 
Shipped or Maximum Quantity of Items or Approval Limit. Each of these terms can be set to a constant 
or  be  mapped  to  a  particular  element  or  attribute  in  some  XML  schema  (and  thus  in  an  incoming 
message) or to the result of a SQL query against some database or even to a value in a .NET object.  
Once a vocabulary has been defined, the Business Rule Composer can be used to create  business 
policies
 that use this vocabulary. Each policy can contain one or more business rules. A rule uses the 
terms defined in some vocabulary together with logical operators such as Greater Than, Less Than, Is 
Equal  To,  and  others  to  define  how  a  business  process  operates.  A  business  rule  can  define  how 
values contained in a received XML document should affect the values created in an XML document 
that’s sent, or how those received values should affect what value is written in a database, or other 
things.  
Imagine,  for  instance,  a  simple vocabulary  that  defines  the  term  Maximum  Allowed  Order  Quantity, 
whose value is set to 100, and the term Quantity Requested, whose value is derived from a specified 
element  in  received  XML  documents  that  correspond  to  the  schema  used  for  placing  orders.  A 
business  analyst  might  create  a  rule  stating  that  if  the  Quantity  Requested  in  an  incoming  order  is 
greater than the Maximum Allowed Order Quantity, the order should be rejected, perhaps resulting in 
an appropriate XML document being sent back to the originator of this order.  
To  execute  a  business  policy,  an  orchestration  uses  a  CallRules  shape.  This  shape  creates  an 
instance of the BRE, specifies which policy to execute, then passes in the information this policy needs, 
such as a received XML document. The BRE can also be invoked programmatically via a .NET-based 
object  model,  which  allows  it  to  be  called  from  applications  that  don’t  use  BizTalk  Server  2006  R2 
(although a BizTalk Server license is always required to use the BRE).  
Both vocabularies  and  business  rules  can  be  much  more  complicated
—and much more powerful—
than the simple examples described here. But the core idea of defining a vocabulary, then defining sets 
of  rules  that  use  that vocabulary is  the  heart  of  the  Business  Rule  Engine.  The  goal is  to  provide  a 
straightforward way for BizTalk Server 2006 R2 users to create and work with the rules that pervade 
business processes.