Module 11: Integrating Business Rules
Time estimated: 120 minutes
Module objective:
In this module, you will learn how to compose and deploy business rules.
Overview
The Microsoft® BizTalk® Server Business Rule Engine allows business users to work with
developers to create and maintain policies containing business rule sets. These policies can be
quickly updated and immediately applied without the need to recompile and redeploy a BizTalk
assembly. Policies can be called from within a BizTalk orchestration and from other Microsoft
.NET applications. This module provides an overview of the Business Rule Engine and describes
the use of policies, rules, and vocabularies. This module also covers execution of business
policies from BizTalk Server 2010.
Lesson 1: Introduction to Business Rules
Lesson objective:
Describe the concepts and terminology used when working with business rules in BizTalk Server
2010.
Lesson Overview
Because an organization’s business rules can change frequently, BizTalk Server enables you to
create business rules that can be modified quickly and easily to meet changing business needs
and the needs of your customers. In this lesson, you will learn what a business rule is and how
business rules are integrated into a BizTalk application environment. You will also see how
developers, business analysts, and administrators work together in order to create, deploy, and
maintain business rules.
What Are Business Rules?
Describe business rules and explain how they can be used to make business decisions.
Business Rules
Business rules are statements that govern the conduct of business processes. A policy is a
collection of related rules that are evaluated together, for example, a bank’s loan approval
policy might be composed of several different rules that need to be evaluated. The policy is
executed, and each rule is evaluated and possibly applied.
Each rule consists of a condition (an if clause) and a resulting action (a then clause). The
conditions and actions can be quite simple or very complex. The condition is evaluated, and if it
evaluates to True, the specified actions are performed by the rule engine. Unlike in most
programming models, there is no else action. For example, if you want to perform an action on
all purchase orders, but the action varies based on the total order amount, you would need to
create two rules, one for purchase orders with a total of less then $1,000 and one rule for
purchase orders with totals greater than or equal to $1,000. These two rules would make up the
discount policy.
Within a policy, the various rules can have different priorities assigned. These priorities do not
modify the order of evaluation but rather the order that the rules are fired in. That is, if multiple
rules are to be fired (on the agenda), the priority will determine the order that the rules are
applied. In this case, the rule that has the highest assigned priority will be fired.
Example
Consider the following example business rule from the preceding illustration.
A manufacturer has received a purchase order from a customer and needs to fulfill the purchase
order request. In order to process the purchase order, the manufacturer must answer a series of
questions:

Is this purchase order from an existing customer or a new customer? If the customer is
new, the customer must be added to the database. If the customer already exists, the
next step in the business rule can be called.

Is the product being ordered a product that we manufacture? If so, we can continue
processing the purchase order. If not, the purchase order must be declined.

Can we supply the product being requested? If the quantity on hand is less than the
order quantity, we can supply the product. If not, we will either have to decline the
purchase order or send a backorder notice.
Notice in the example that each question can be answered either True or False. These rules
apply basic business logic to find out whether or not a purchase order can be fulfilled.
Business rules can be used to:



Trigger notifications. For example, if a product is low on inventory, a business rule could
trigger a reorder notice for the product.
Automate approvals. You could use a business rule, for example, to route documents
with a total order amount over $10,000 to a manager for approval.
Reroute documents. If a purchase order is from a new customer, you could route the
purchase order to another business process that handles new customers.
Business Rule Engine
Since business rules embedded in applications can change over time, BizTalk Server 2010
provides the Business Rule Engine (BRE) to enable you to create and modify sets of business
rules. These rules can be created graphically using a tool called the Business Rule Composer or
can be written using the Business Rule APIs. Once published, the policy can be called from a
BizTalk orchestration and executed by the Business Rule Engine.
The BRE enables business rule policies to be changed in real time. Any orchestrations that use
(call) the business rules need not be recoded or rebuilt when the business policy changes.
Business rules are versioned together as part of a business policy, and all a business analyst
needs to do when a rule changes is create a new version of a policy and then deploy the policy.
Note: Although typically used in conjunction with BizTalk orchestrations, business rule policies
can be called from any .NET assembly by using the supplied APIs. The focus of this module will
be on using business rules in conjunction with orchestrations. The BizTalk Server 2010
documentation contains more information about calling business rules programmatically,
including an example in the BizTalk SDK.
What Are Rules, Policies, and Vocabularies?
Define common business rule terminology.
Overview
The following sections describe common business rule terminology.
Rule
Business rules are statements that govern the conduct of business processes. Business rules
consist of a condition and one or more consequent actions. Conditions are true/false, otherwise
known as Boolean expressions, that consist of one or more predicates applied to facts. Multiple
conditions can be combined to provide for complex computations. Complex conditions can be
constructed by joining multiple simple conditions using AND, OR, and NOT modifiers. For
example, when evaluating a customer order, you could have a rule such as: If customer exists
AND total order amount > 1000 OR if customer exists AND customer rating = excellent THEN set
discount amount = 10%.
Policy
Policies are logical rule sets. You compose a version of a policy, save it, test it by applying it to
facts, and when you are satisfied with the results, publish it and deploy it to a production
environment. Policies are versioned and deployed, so if a rule changes, you simply create a new
version of the policy, test the policy, and then deploy it. You do not have to recompile or modify
orchestrations or other business processes that are using a particular business policy.
When called from an orchestration, the Business Rule Engine will always execute the latest
version of a policy. Changes made to a business rule policy will be immediate. The next time the
policy is called from an orchestration, the most recently deployed version will be used. After it is
published, a business rule policy is immutable and can be changed only by creating a new
version.
Vocabulary
Vocabularies are user-defined names for the facts used in rule conditions and actions.
Vocabulary definitions render rules easier to read, understand, and share for the various
workers within a particular business domain. For example, the source location for a particular
fact might be a field in a particular record within a database, represented as an SQL query.
Instead of employing the SQL query (an abstract procedural statement, difficult for most people
to memorize or recognize) in the rule, a name meaningful to all the relevant parties in the
development and deployment process can be associated with the query by creating a
vocabulary definition. When you create a new vocabulary definition, you can choose from one
of the following:




A constant value, a range of values, or a set of values
A .NET class or class member
An XML document element or attribute
A database table or column
Creating the necessary vocabulary for business rules makes reading, comprehending, and
updating the business rules much easier than without using vocabularies. In addition to the
vocabularies you can create, the Business Rule Composer uses predefined vocabularies for the
predicates and functions used in the rule evaluations and actions.
Rule Store
The rule store is a repository for business policies and vocabularies. Policies and vocabularies are
deployed to the rule store. The rule store is by default the Business Rule Database
(BizTalkRuleEngineDb). This database is created when configuring business rules for the BizTalk
group. Additionally, policies and vocabularies can be exported to an XML file to simplify
modification and deployment between test and production environments.
How Rules and Facts Work
Define business rules, actions, and facts.
Business Rules
A business rule consists of a condition and one or more resulting actions. As mentioned before,
business rules are If/Then conditions, and there is no Else clause. Each business rule either
returns True or False.
Conditions
A condition is a True/False (Boolean) expression that consists of one or more predicates applied
to facts. Predicates can be combined with the logical connectives AND, OR, and NOT to form a
logical expression that is potentially quite large but that will always evaluate to either True or
False.
Actions
An action is the functional consequence of condition evaluation. If a rule condition is met, a
corresponding action or actions are initiated. Actions are represented in the Business Rule
Framework as Microsoft .NET–based objects or as set operations on XML documents or
database tables. For example, if a business rule that checks whether or not a customer is
preferred returns true, you could then call a method of a .NET class to execute code in the class.
You could also update elements or attributes in an XML schema document, or you could update
data in a Microsoft SQL Server™ database. You can execute more than one action within the
THEN clause.
Facts
Facts are the data that rules use to make decisions. Facts can be derived from multiple data
sources and must be fed into the rule engine through pre-defined vocabularies, XML schemas,
.NET classes, or database row sets. Many facts are instance facts that will be different for each
firing of the rules. For example, the customer name and account number fields in a PO message
are instance facts. Other facts may be long term. For example, interest rates usually change
infrequently and do not need to be looked up each time a rule is fired. Long-term facts are
determined once and then held in the cache until refreshed, whereas instance facts are
determined for each rule execution. A fact can be configured as a long-term fact by setting the
Fact Retriever property for each version of the policy in the properties window for the version
of the policy. A fact retriever object must be created to be able to fetch the facts from a
persistent storage and present them to the policy object.
For More InformationFor more information on creating a long-term fact, refer to the BizTalk
Server 2010 documentation “Creating a Fact Retriever” and “Short-Term Facts vs. Long-Term
Facts.”
Business Rule Execution
Define business rules, actions, and facts.
Business Rule Execution
The Business Rule Engine uses a three-stage algorithm for policy execution. The stages are as
follows:
Match. In the match stage, facts are matched against the predicates that use the fact type
(object references maintained in the rule engine's working memory) using the predicates
defined in the rule conditions. For the sake of efficiency, pattern matching occurs over all the
rules in the policy, and conditions that are shared across rules are matched only once. Partial
condition matches may be stored in working memory to expedite subsequent pattern-matching
operations. The output of the pattern-matching phase consists of updates to the rule engine
agenda.
Conflict resolution. In the conflict resolution stage, the rules that are candidates for execution
are examined to determine the next set of rule actions to execute based on a predetermined
resolution scheme. All candidate rules found during the matching stage are added to the rule
engine's agenda.
The default conflict resolution scheme is based on rule priorities within a policy. The priority is a
configurable property of a rule in the Business Rule Composer. The larger the number, the
higher the priority; therefore if multiple rules are triggered, the higher-priority actions are
executed first.
Action. In the action stage, the actions in the resolved rule are executed. Note that rule actions
can assert new facts into the rule engine, which causes the cycle to continue. This is also known
as forward chaining. It is important to note that the algorithm never preempts the currently
executing rule. All actions for the rule that is currently firing will be executed before the match
phase is repeated. However, other rules on the agenda will not be fired before the match phase
begins again. The match phase may cause those rules on the agenda to be removed from the
agenda before they ever fire.
Business Rules Orchestration Scenarios
Describe scenarios for integrating business rules within an orchestration.
Common Orchestration Scenarios
Instead of having to code and recode constantly changing business policies and logic within your
complex business processes, you can incorporate a call to the Business Rule Engine and thus
allow information workers to update the rules as needed.
Overview
You can integrate business rules into your orchestrations to support a variety of scenarios:



You can use rules to determine whether another business process needs to be
executed. For example, after successfully placing a customer order, you might want to
call a second orchestration that handles the shipping of orders.
You can use rules to evaluate business logic and to determine when a business process
requires a variable delay. For example, you might set up a loop to check on the status of
an item to see if the item is in stock. After initially checking the stock of an item that is
not available, the rule delay would be one minute. The next time, the rule would wait
five minutes before executing, the following time, the rule would wait 30 minutes
before executing, and so on.
You can use rules to determine the execution path for a business process, basing the
determination on the results of the rule execution. For example, if the customer
submitting the purchase order does not exist in the database, you could route the
document to another business process to add the customer to the database before
continuing to process the purchase order.
Identifying Business Rule Personas
Identify job roles and responsibilities for managing business rules.
Overview
The Business Rules Framework incorporates a graphical user interface—the Business Rule
Composer—that developers, information workers, and administrators can all use in various
ways to develop and apply both rules and policies.
Developers can:

Create the orchestrations from which the business rules will be called, and they define
the action to be taken when a decision is returned to the orchestration. As long as the
decision path within the orchestration does not change, the orchestration will not need
to be redeployed.

Create the initial business rule policies and create vocabularies to make it easier for
information workers to edit and understand business rule policies.
Information workers can:

Design, test, and manage business policies. Changes made to a BRE policy will be
executed from an orchestration without having to recompile and redeploy the BizTalk
assembly. The BRE always calls the latest deployed version of the policy.
Administrators can:



Secure business rule policies. By default, when a new policy or vocabulary is created in
the rule store, only the user who created it and the rule engine administrator have both
read/execute and modify/delete access. The rule engine administrator can configure
which users have the access level, or rights, to perform different operations (processes
operate under user credentials).
Deploy business rule policies from one physical environment to another. Deploying
business rules to other physical environments is accomplished by using the Rules Engine
Deployment Wizard and is covered later in this module. Rules can also be exported and
imported using Microsoft Windows® Installer (MSI) packages.
Monitor the results of executed business rules by using the BizTalk Administration
Console. This tool allows auditing of the rules-based decision made within each
orchestration instance.
Lesson 2: Integrating Business Rules
Lesson objective:
Compose, publish, and deploy business rules.
Overview
BizTalk provides several tools for developing and deploying business rules and for applying them
to business processes. In this lesson, you will learn how to integrate a business rule policy into
an orchestration and how to use the Business Rule Composer to create easy-to-understand
vocabularies and policies. These policies can then be versioned and deployed before being
called from an orchestration. You can also track business rules to find out the true or false
outcome of a rule.
Steps for Integrating Business Rules
Describe the steps required to integrate business rules within an orchestration.
Integrating Business Rules
When developing rule-based applications, you must complete the following steps:
1. Identify the business logic that you would like to represent with rules in your
application. The term business logic can refer to a wide variety of decision processes, for
example, “Purchase orders for more than five hundred dollars must be approved by a
manager.”
2. Identify the data sources for your rule elements. Optionally, you can also define and
publish vocabularies—domain-specific nomenclatures that represent underlying
bindings.
3. Create rules either from your vocabulary definitions or directly from data bindings; using
these rules, compose a policy that will represent your business logic.
Optionally, you may choose to create a fact retriever and associate it with a policy to
employ long-term facts. This step is used only if you want to employ a long-term
fact, as discussed earlier in this module.
4. Test and debug the policy by using sample facts. (You can create a PolicyTester object in
your application. Testing a policy before integrating it in an orchestration allows you to
ensure that the policy is working correctly before testing it from an orchestration.
Troubleshooting a policy is much easier if you will test the policy before integrating it
with an orchestration. For more information on creating a PolicyTester object to test a
business policy, refer to the BizTalk Server 2010 documentation “Testing Policies” and
“Creating a Fact Creator.”)
5. Publish and deploy the policy version to the rule store. After a policy version is
published, it is immutable but still not available for other applications to use the policy.
Deploying the policy version makes the policy available to other applications.
6. Call the policy from a BizTalk orchestration.
a. Instantiate and build the short-term fact list in the hosting application.
b. Instantiate a policy version in your hosting application, and then execute it by
using your short-term fact list. If you are using a PolicyTester object, replace it
with a Policy object in your application. Policy objects are used when executing
long-term facts instead of short-term facts.
c. Add the call rules shape to the orchestration and provide the parameters used
by the BRE.
d. Monitor and track rule execution as needed. Business rule policy tracking is
configured by using the BizTalk Server 2010 Administration Console and is
covered later in this module.
Composing Business Rules
Use the Business Rule Composer to define business rules.
Business Rule Composer
The Business Rule Composer is a graphical user interface that allows you to create business rule
policies, which contain one or more business rules. These rules can evaluate facts to determine
if specific actions should be performed. To assist in humanizing these rules, vocabularies can be
created that provide a user-friendly alias to the terms and conditions. Multiple versions of the
policies and vocabularies can be created, tested, published, and deployed using the Business
Rule Composer to make management of these artifacts easier.
Create Business Rule Policy
A policy is a collection of rules. Each rule is a conditional comparison of facts, which if the
comparison evaluates to True causes the actions defined in the rule to be executed. Rules are
constructed in the Rule Composer pane by adding predicates and facts (which may be direct
facts or may be based upon vocabularies) and defining actions. AND, OR, and NOT operators can
be added to conditions to provide for complex comparisons.
Facts and actions are added by dragging them onto the Rule Composer design surface. Actions
will modify nodes in the document specified. This is one notable exception to the immutability
of messages in BizTalk orchestrations because the actions can update or even add new nodes
and/or nodelists to the provided message(s). The Business Rule Engine (BRE) makes changes to
the messages that it passes in the call to the engine. For this reason, you may want to create a
specific message that is sent to the engine rather than having the BRE change the original
document.
In the earlier example, the “give the customer a 10 % discount” action will update the Discount
Amount node in the AdventureWorks.Orders.CustomerOrder message.
Additional actions (such as asserting and retracting facts) can be added by right-clicking the
Actions node and then clicking the appropriate action.
Testing, Publishing, and Deploying a Policy
When a version of a policy is defined to the satisfaction of the business analyst, the policy
should be tested prior to publishing it. The act of publishing the policy to the Rule Store makes
the policy available to the BRE. By default, the BRE uses a SQL Server database as the Rule Store.
However, rules can be exported to an XML-based Rule Store as well. Once published, policy
versions are immutable and cannot be changed without creating a new version. Remember that
rules must also be deployed before they can be used by other applications.
In order for the policy to be called from a BizTalk application, the policy must be deployed.
BizTalk will always use the most recently deployed policy version when the policy is called by an
application, whereas when called from a .NET assembly, a specific policy version is specified.
Create a Business Rule Vocabulary
Previously we introduced a rule that said:
If the Shopping Cart contains more than $1000 worth of items, then give the customer a 10
percent discount.
As written, this rule is easy to understand. The rule is a Boolean comparison (greater than)
between two variables: the shopping cart and a value of 1000. The action to be performed is to
apply a 10 percent discount to the total order. The problem is that computers do not think in
these terms. In computer terms, this looks like:
If
Company.Namespace.ShoppingCart.PurchaseAmount > Qualifying Amount
as System.Decimal
Then
Company.Namespace.Customer.DiscountAmount =
Company.Namespace.ShoppingCart.PurchaseAmount * .1
We create vocabularies to make an obscure concept more human.
Although rules can be created and used without the use of vocabularies, creating vocabularies
makes the creation and maintenance of rules much easier. Vocabularies abstract difficult
concepts by defining an alias to be associated with schema nodes, database fields, or .NET
classes. With correctly defined vocabularies, policies can be maintained by (if not initially
created) by information workers.
Two vocabularies, Predicates and Functions (which are used in the creation of all rules), are built
into the Business Rule Composer. It is possible to extend these vocabularies as needed. For
example, the phrase “The Shopping Cart contains more than $ 1000 worth of items” is actually a
greater than comparison: (ShoppingCart > 1000). The built-in Greater Than function in the
functions vocabulary could have an additional vocabulary term defined that represents this
relationship. This may make it easier for information workers to understand the relationship.
Publishing Business Rule Vocabularies
Similar to policies, vocabularies must be published before they can be incorporated into a policy;
however, there is no option to deploy. If the vocabulary used in a policy changes, it will be
necessary to update the policy to use the newly published vocabulary.
Foreign Language Support
Although the examples here are using the English language, vocabularies can be written in
various languages, making data defined in databases and schemas more accessible to nonEnglish speakers.
Demonstration: Using the Business Rule Composer
Learn to examine and test a deployed business rule policy.
Note: In order to be able to fully explain the vocabularies and rules used in this demonstration,
you will need to complete the lab at the end of this module.
To Examine Existing Business Rules
1. On the Start menu, point to All Programs, point to Microsoft BizTalk Server 2010, and
then click Business Rule Composer.
2. In the Open Rule Store dialog box, click OK.
3. In Microsoft Business Rule Composer, in the Policy Explorer pane, expand
LoanAppApproval, Version 1.0 – Deployed, and Version 1.1 – Deployed.
The two policy versions have identical rules, except that Version 1.0 is in readable
English because it uses vocabularies. Version 1.1 does not use vocabularies, and it is
more difficult to understand the contextual sense of what each rule is doing.
4. In the Facts Explorer pane, under LoanProcess, expand Version 1.0 – Published.
A vocabulary is a collection of definitions that provide simple-to-read aliases for
complex message values or fields in a database.
5. Click Base Income.
The Current Order Total definition refers to the BasicSalary field of the message
when it is received into the Business Rule Engine (BRE). This value is from the
LoanApplication schema, which you can see by examining the Schema and XPath
properties in the Properties dialog box.
6. Click Month Range.
The Month Range definition contains a set of predetermined values; these values are
3, 6, 9, 12, 18, and 24. When used as part of a rule, these values are displayed as a
drop-down list.
7. Click Update Loan Status.
The Update Loan Status definition is used to update the Status field of the message.
8. In Policy Explorer, under Version 1.1 – Deployed, click Approved.
The Conditions pane shows that this rule is applied when BasicSalary + OtherIncome
is greater than the LoanAmount, and Employment/TimeInMonths is greater than or
equal to 6, or the Residency/TimeInMonths is greater than or equal to 6. The Actions
pane shows that the LoanStatus field will be assigned a value of Approved.
9. In Policy Explorer, under Version 1.0 – Deployed, click Approved.
Although this rule performs the same action as the Approved rule is version 1.1, it’s
much more readable. The rule is applied when Monthly Base Income + Monthly
Secondary Income is greater than Requested Loan Amount, and Months Employed is
greater than or equal to 6, or Months in Current Home is greater than or equal to 6.
Examine both versions of the other three rules and determine what each rule does.
To Test the Business Rule Policy
1. In Windows Explorer, navigate to C:\AllFiles\DemoCode\Module11, and open
LoanApplication - Approved.xml.
Notice that LoanStatus is blank and that the sum of BasicSalary and OtherIncome is
greater than LoanAmount, and both TimeInMonths fields are greater than 6. This
message will be Approved.
2. In Windows Explorer, navigate to C:\AllFiles\DemoCode\Module11, and open
LoanApplication - Denied.xml.
Notice that LoanStatus is blank, that the sum of BasicSalary and OtherIncome is less
than LoanAmount, and both TimeInMonths fields are less than 6. This message will
be Denied.
3. Close Microsoft Internet Explorer®.
4. In Policy Explorer, right-click Version 1.0 – Deployed, and then click Test Policy.
5. In the Select Facts dialog box, click AdvWorks.LoanApproval.LoanApplication, and then
click Add instance.
6. In the Open dialog box, navigate to C:\AllFiles\DemoCode\Module11, click
LoanApplication – Approved - Copy.xml, and then click Open.
Be sure to keep a copy of the original message because the Business Rule Engine will
alter the test message.
7. In the Select Facts dialog box, click Test.
8. In the Output pane, notice that are two RULE FIRED events, one for the Loan to Salary
Ratio rule, and one for the Approved rule.
9. In Windows Explorer, navigate to and open
C:\AllFiles\DemoCode\Module11\LoanApplication – Approved - Copy.xml, and notice
that the LoanStatus field now reads Approved, and the LoanToIncome field now reads
0.555.
10. In Policy Explorer, right-click Version 1.0 – Deployed, and then click Test Policy.
11. In the Select Facts dialog box, click C:\AllFiles\DemoCode\Module11\Copy of
LoanApplication – Approved.xml, and then click the Remove instance button.
12. In the Select Facts dialog box, click AdvWorks.LoanApproval.LoanApplication, and then
click the Add instance button.
13. In the Open dialog box, navigate to C:\AllFiles\DemoCode\Module11, select Copy of
LoanApplication – Denied.xml, and then click Open.
You are using the copy of the original message because the Business Rule Engine will
alter the test message.
14. In the Select Facts dialog box, click Test.
15. In the Output pane, notice that are three RULE FIRED events, one for the Loan to Salary
Ratio rule, one for the Denied Income rule, and one for the Denied Residency or
Employment rule.
16. In Windows Explorer, navigate to and open C:\AllFiles\DemoCode\Module11\Copy of
LoanApplication – Denied.xml, and notice that the LoanStatus field now reads Denied,
and the LoanToIncome field now reads 1.2.
17. Pause the bt10d-demos virtual machine.
Deploying Business Rules
Deploy policies.
Overview
After a policy is published, it must be deployed before it can be used by external processes. The
shortcut menu in the Business Rules Composer has an option to deploy the policy. The Rule
Engine Deployment Wizard, found on the BizTalk program menu, can be used to export and
import business rule policies to and from a Business Rule Language (BRL) file and to publish
policies to the SQL rule store. You can use this wizard in development, staging, and production
environments.
BizTalk Server provides the ability to import, export, deploy and undeploy policies and
vocabularies in the Business Rules database by using the BizTalk Server Administration Console.
This assumes, however, that the policies and vocabularies are exported and imported as part of
a BizTalk application’s MSI package.
You may also export and import policies and vocabularies as XML files by using the Rule Engine
Deployment Wizard.
The Rule Engine Deployment Wizard allows you to:

Export a version of a policy or a vocabulary from an SQL rule store into a file rule store.
This creates an XML file that contains the configuration information for the policy or



vocabulary being exported. This XML file can then be copied to another computer to be
imported at a later date.
Import a version of a policy or vocabulary from a file rule store into an SQL rule store.
Deploy a version of a policy and publish a vocabulary from an SQL rule store to a
production SQL rule store so that the policy can be run within a rule-based application.
Deploying a rule makes the rule available to other business processes.
Undeploy a version of a policy and remove a vocabulary from an SQL rule store to make
the policy unavailable for use by a rule-based application. Undeploying a version of a
policy does not remove the policy from the database. The policy is still saved in the
Rules Engine database, but it cannot be used by other applications. Use this if you want
to revert to a previous version of the policy.
Integrating Business Rules into an Orchestration
Integrate business rules into an orchestration.
Integrating Business Rules
You can incorporate business rules within your BizTalk orchestrations by performing the
following tasks:

Adding a call rules shape inside the orchestration and setting the Configure Policy
property to specify the business rule you are calling. You specify only the name of the
business policy you will be calling and not the version number of the policy. The most
current version of the policy will always be used when calling from an orchestration.

In many cases, you will want to define a separate Message variable and add a message
construct shape to the orchestration. This will allow you to construct a message that
contains only the values that will be needed by the BRE. Also, since the BRE call can
modify the submitted message, you may want to submit a copy rather then the original
message. Use the Orchestration View window to create a message variable that maps to
the message type of the message you will be sending to the BRE.

Using a decision shape (or other shape) to process the response from the Business Rule
Engine. Other shapes at this step that could be used instead include the Delay shape and
the Call Orchestration shape, depending on what you want to do after receiving the
results of the business policy.
Demonstration: Integrating Business Rules into an Orchestration
Learn to configure the call rules orchestration shape.
Add a Call Rules Shape
1. Resume the bt10d-demos virtual machine.
2. In Windows Explorer, navigate to C:\AllFiles\DemoCode\Module11\AdvWorks, and
then double-click AdvWorks.sln to open the solution.
3. In Solution Explorer, double-click ProcessLoans.odx to open the orchestration.
4. From the Toolbox, drag a Call Rules shape to the orchestration directly below the
Receive Credit SO shape.
5. In the CallRules_1 Properties window, in the Name box, type Call Loan Approval Policy,
and then click the ellipsis (…) button next to the Configure Policy box.
6. Choose LoanAppApproval from the Select the business policy you wish to call list, set
the Parameter Name to msgLoanApp, and then click OK.
This orchestration will now pass the msgLoanApp message to the Business Rule
Engine, relying on it to executethe LoanAppApproval policy, and update the
message’s LoanStatus field.
The Call Rules orchestration shape always instructs the Business Rule Engine to
process the message with the latest version of the LoanAppApproval policy that has
been deployed.
7. Close all open windows, and shut down the bt10d-demos virtual machine.
Tracking Business Rules Policy Execution
Track business rule execution.
Tracking Policy Execution
You can monitor business rule activities and track the overall progress of an orchestration that
uses the Business Rules Framework by using the BizTalk Server 2010 Administration Console.
You can view a list of the deployed business rule policies, and you can view and change the
current tracking configuration for any currently deployed policies.
To set tracking options for a policy, select the application associated with the rule, and then click
Policies. All polices that are associated with this application (and all versions of these policies)
are displayed. If the policy that you want to manage is not displayed, right-click Policies to add
the policy to the application.
Tracking Options
To configure tracking properties for a policy, right-click the policy to access its properties and to
configure tracking. There are four options for tracking business rules from the BizTalk Server
Administration Console:
1. Fact Activity. Select this check box when tracking the instance data on which the policy
operates.
2. Condition Evaluation. This check box allows you to track the True/False result of the
conditions in the selected policy.
3. Rule Firings. This check box allows you to track the actions triggered as a result of the
policy.
4. Agenda Updates. Select this check box when you want to track updates to the agenda,
which contains a list of actions that evaluated to True and a list of rules that fired.
Once you have turned on tracking for your business policies, execute your queries as normal in
the BizTalk Server Administration Console. You should see a link to access the business rule
execution for each message that was processed by the Business Rule Engine. You can then see
the True/False values of policies that were executed in the BRE along with the If/Else condition
that was evaluated.
Polices that have been added to an application can be managed with the rest of the application.
This includes the ability to undeploy policies and to include the policies when the MSI is
exported. Undeployed policies will still be visible within the application. In this way, policies can
be managed by undeploying and redeploying the application as necessary.
Lab: Integrating Business Rules
Time estimated: 60 minutes
Scenario
The Microsoft Business Rule Engine (BRE) enables you to apply declarative rules based on
messages from BizTalk orchestrations. Using the BRE enables you to separate the
implementation of the business process (orchestration) from business decisions that are likely to
change over time. Vocabularies are a collection of easy-to-read definitions for the facts used by
the BRE. When vocabularies are used to create rules, the rules can easily be updated and
maintained by business analysts who have little or no understanding of the BizTalk
implementation. In this lab, you will create a vocabulary with several definitions. You will then
create a rule policy by using the vocabulary you created. Finally, you will integrate the Business
Rule Engine policy into an orchestration.
Start the Virtual Machine
Procedure List
1. If the Server Manager window is not already open, click on the Server Manager icon
located in the task bar next to the Start button.
2. Expand Roles, Hyper-V, Hyper-V Manager. The last node to appear displays the
machine name. Click on it to see the list of virtual machines available.
3. Double-click the virtual machine bt10d-11 to open a Virtual Machine Connection
window.
4. Click on the Action menu in the Virtual Machine Connection window and choose Start.
5. Once the virtual machine starts, press CTRL+ALT+END.
6. Log on using the user name Administrator and the password pass@word1.
7. At the Windows Activation prompt, click Ask Me Later, then click OK.
Ensure that the BizTalk Services are started
Procedure List
1. In Windows Explorer, navigate to C:\AllFiles.
2. Double click startBtServices.cmd.
3. When prompted, press any key to close the command-line window.
Exercise 1: Creating a Business Rule Engine Vocabulary
Overview
The Business Rule Engine (BRE) makes decisions based on facts derived from .NET classes, XML
schemas, and SQL databases. The sources of these facts can be difficult for humans to read and
understand. Vocabulary definitions are human-friendly aliases for the facts used by the BRE. In
this exercise, in order to simplify the creation of business rules, you will create a vocabulary that
contains several definitions.
Create a New Business Rule Vocabulary
Procedure List
1. On the Start menu, click All Programs, click Microsoft BizTalk Server 2010, and then
click Business Rule Composer.
2. In the Open Rule Store dialog box, click OK.
3. In the Facts Explorer pane, on the Vocabularies tab, right-click Vocabularies, and then
click Add New Vocabulary.
4. Rename the new vocabulary to LoanProcessing.
Vocabularies contain reusable mappings between user-friendly text and the
underlying data sources used in a rule definition.
Create New “Get” Operation Definitions
Procedure List
1. Under LoanProcessing, right-click Version 1.0 (not saved), and then click Add New
Definition.
2. On the Welcome to the Vocabulary Definition Wizard page, click XML Document
Element or Attribute, and then click Next.
3. In the Definition name box, type Primary Income.
4. In the Definition description box, type Amount of principal income.
5. Click the Browse button, navigate to
C:\AllFiles\LabFiles\Lab11\AdvWorks\LoanApproval\LoanApplication.xsd, and then
click Open.
6. In the Select Binding dialog box, expand LoanApp and Income, click BasicSalary, and
then click OK.
7. Click Perform “Get” operation.
8. In the Display name box, type Monthly Primary Income, and then click Finish.
9. Under LoanProcessing, right-click Version 1.0 (not saved), and then click Add New
Definition.
10. On the Welcome to the Vocabulary Definition Wizard page, click XML Document
Element or Attribute, and then click Next.
11. In the Definition name box, type Employment (months).
12. In the Definition description box, type Length of employment.
13. Click the Browse button, navigate to
C:\AllFiles\LabFiles\Lab11\AdvWorks\LoanApproval\LoanApplication.xsd, and then
click Open.
14. In the Select Binding dialog box, expand LoanApp and Employment, click
TimeInMonths, and then click OK.
15. Click Perform “Get” operation.
16. In the Display name box, type Months Employed, and then click Finish.
17. Under LoanProcessing, right-click Version 1.0 (not saved), and then click Add New
Definition.
18. On the Welcome to the Vocabulary Definition Wizard page, click XML Document
Element or Attribute, and then click Next.
19. In the Definition name box, type Loan Amount.
20. In the Definition description box, type Desired loan amount.
21. Click the Browse button, navigate to
C:\AllFiles\LabFiles\Lab11\AdvWorks\LoanApproval\LoanApplication.xsd, and then
click Open.
22. In the Select Binding dialog box, expand LoanApp and LoanConditions, click
LoanAmount, and then click OK.
23. Click Perform “Get” operation.
24. In the Display name box, type Requested Loan Amount, and then click Finish.
25. Under LoanProcessing, right-click Version 1.0 (not saved), and then click Add New
Definition.
26. On the Welcome to the Vocabulary Definition Wizard page, click XML Document
Element or Attribute, and then click Next.
27. In the Definition name box, type Residency (months).
28. In the Definition description box, type Length at residence.
29. Click the Browse button, navigate to
C:\AllFiles\LabFiles\Lab11\AdvWorks\LoanApproval\LoanApplication.xsd, and then
click Open.
30. In the Select Binding dialog box, expand LoanApp and Residency, click TimeInMonths,
and then click OK.
31. Click Perform “Get” operation.
32. In the Display name box, type Months at Current Residence, and then click Finish.
33. Under LoanProcessing, right-click Version 1.0 (not saved), and then click Add New
Definition.
34. On the Welcome to the Vocabulary Definition Wizard page, click XML Document
Element or Attribute, and then click Next.
35. In the Definition name box, type Secondary Income.
36. In the Definition description box, type Income from sources other than primary
income.
37. Click the Browse button, navigate to
C:\AllFiles\LabFiles\Lab11\AdvWorks\LoanApproval\LoanApplication.xsd, and then
click Open.
38. In the Select Binding dialog box, expand LoanApp and Income, click OtherIncome, and
then click OK.
39. Click Perform “Get” operation.
40. In the Display name box, type Monthly Secondary Income, and then click Finish.
Create the Update Loan Status “Set” Operation Definition
Procedure List
1. Under LoanProcessing, right-click Version 1.0 (not saved), and then click Add New
Definition.
2. On the Welcome to the Vocabulary Definition Wizard page, click XML Document
Element or Attribute, and then click Next.
3. In the Definition name box, type Update Loan Status.
4. Click the Browse button, navigate to
C:\AllFiles\LabFiles\Lab11\AdvWorks\LoanApproval\LoanApplication.xsd, and then
click Open.
5. In the Select Binding dialog box, expand LoanApp and LoanConditions, click LoanStatus,
and then click OK.
6. Click Perform “Set” operation, and then click Next.
7. In the Display format string box, type Update the Loan Status for this loan to {0}, and
then click Finish.
Create the Set Loan to Income Ratio “Set” Operation Definition
Procedure List
1. Under LoanProcessing, right-click Version 1.0 (not saved), and then click Add New
Definition.
2. On the Welcome to the Vocabulary Definition Wizard page, click XML Document
Element or Attribute, and then click Next.
3. In the Definition name box, type Set Loan to Income Ratio.
4. Click the Browse button, navigate to
C:\AllFiles\LabFiles\Lab11\AdvWorks\LoanApproval\LoanApplication.xsd, and then
click Open.
5. In the Select Binding dialog box, expand LoanApp and LoanConditions, click
LoanToIncome, and then click OK.
6. Click Perform “Set” operation, and then click Next.
7. In the Display format string box, type The loan to income ratio for this loan is: {0}, and
then click Finish.
Create the Month Range Definition
Procedure List
1. Under LoanProcessing, right-click Version 1.0 (not saved), and then click Add New
Definition.
2. On the Welcome to the Vocabulary Definition Wizard page, click Constant Value,
Range of Values, or Set of Values, and then click Next.
3. In the Definition name box, type Month Range, click Set of Values, and then click Next.
4. In the Display name box, type Month Range.
5. Add the following values by typing each in the Use constant value box, and then clicking
Add after each entry: 3, 6, 9, 12, 18, 24. Click Finish.
Create the Status Range Definition
Procedure List
1. Under LoanProcessing, right-click Version 1.0 (not saved), and then click Add New
Definition.
2. On the Welcome to the Vocabulary Definition Wizard page, click Constant Value,
Range of Values, or Set of Values, and then click Next.
3. In the Definition name box, type Status Range, click Set of Values, and then click Next.
4. In the Definition type list, click System.String.
5. Add the following values by typing each in the Use constant value box, and then clicking
Add after each entry: Approved, Denied, and Pending. Click Finish.
Publish the LoanProcessing Vocabulary
Procedure List
1. In the Facts Explorer pane, under the LoanProcessing vocabulary, right-click Version 1.0
(not saved), and then click Save.
Saving the vocabulary saves the definitions to the Business Rule Engine Database,
making them immutable, but the vocabularies are not available for use until
published.
2. Right-click Version 1.0, and then click Publish.
Exercise 2: Composing a Business Rule Policy
Overview
A business rule policy is a collection of rules that are analyzed to make a decision. In this
exercise, you will use vocabulary definitions to create four business rules. These rules evaluate a
loan application and either approve the loan or mark it for manual consideration.
Create a New Policy
Procedure List
1. In Policy Explorer, right-click Policies, and then click Add New Policy.
2. Rename the policy LoanApprovalProcess.
Create the Approved Rule
Procedure List
1. Right-click Version 1.0 (not saved), and then click Add New Rule.
2. Rename the rule Approved.
3. In the IF pane, right-click Conditions, and then click Add logical AND.
4. Right-click AND, point to Predicates, and then click GreaterThan.
5. Right-click argument1, point to Functions, and then click Add.
6. Drag Primary Income from the Facts Explorer pane to value1, and then drag Secondary
Income to value2.
7. Drag Loan Amount from the Facts Explorer pane to argument2.
8. Right-click AND, and then click Add logical OR.
9. Right-click OR, point to Predicates, and then click GreaterThanEqual.
10. Drag Employment (months) from the Facts Explorer pane to argument1, and then drag
Month Range to argument2.
11. Click Month Range, and then in the drop-down list, click 6.
12. Right-click OR, point to Predicates, and then click GreaterThanEqual.
13. Drag Residency (months) from the Facts Explorer pane to argument1, and then drag
Month Range to argument2.
14. Click Month Range, and then in the drop-down list, click 6.
15. Drag Update Loan Status from the Facts Explorer pane to Actions in the THEN pane.
16. Drag Status Range from the Facts Explorer pane to <empty string>.
17. Click Status Range, and then in the drop-down list, click Approved.
Create the Denied Income Rule
Procedure List
1. Right-click Version 1.0 (not saved), and then click Add New Rule.
2. Rename the rule Denied Income.
3. Right-click Conditions, point to Predicates, and then click LessThanEqual.
4. Right-click argument1, point to Functions, and then click Add.
5. Drag Primary Income from the Facts Explorer pane to value1, and then drag Secondary
Income to value2.
6. Drag Loan Amount from the Facts Explorer pane to argument2.
7. Drag Update Loan Status from the Facts Explorer pane to Actions in the THEN pane.
8. Drag Status Range from the Facts Explorer pane to <empty string>.
9. Click Status Range, and then in the drop-down list, click Pending.
Create the Denied Residency and Employment Rule
Procedure List
1. Right-click Version 1.0 (not saved), and then click Add New Rule.
2. Rename the rule Denied Residency and Employment.
3. Right-click Conditions, and then click Add logical AND.
4. Right-click AND, point to Predicates, and then click LessThan.
5. Drag Employment (months) from the Facts Explorer pane to argument1, and then drag
Month Range to argument2.
6. Click Month Range, and then in the drop-down list, click 6.
7. Right-click AND, point to Predicates, and then click LessThan.
8. Drag Residency (months) from the Facts Explorer pane to argument1, and then drag
Month Range to argument2.
9. Click Month Range, and then in the drop-down list, click 6.
10. Drag Update Loan Status from the Facts Explorer pane to Actions in the THEN pane.
11. Drag Status Range from the Facts Explorer pane to <empty string>.
12. Click Status Range, and then in the drop-down list, click Pending.
Create the Loan to Salary Ratio Rule
Procedure List
1. Right-click Version 1.0 (not saved), and then click Add New Rule.
2. Rename the rule Loan to Salary Ratio.
3. Right-click Conditions, point to Predicates, and then click GreaterThan.
4. Drag Loan Amount from the Facts Explorer pane to argument1, click argument2, and
then type 100.
5. Drag Set Loan to Income Ratio to Actions in the THEN pane.
6. Right-click 0, point to Functions, and then click Divide.
7. Right-click value1, point to Functions, and then click Add.
8. Drag Primary Income to value1, and then drag Secondary Income to value2 (inside the
add function).
9. Drag Loan Amount to value2.
Deploy and Test the LoanApprovalProcess Policy
Procedure List
1. Under LoanApprovalProcess, right-click Version 1.0 (not saved), and then click Publish.
2. Right-click Version 1.0 - Published, and then click Deploy.
3. In Windows Explorer, navigate to C:\AllFiles\LabFiles\Lab11, and then open BREDenied.xml.
Notice that the loan amount is greater than the income amount, and that the time
at residence and the time at employer are both three months. This loan will be
denied by the policy you created.
4. In Windows Explorer, open BRE-Approved.xml.
Notice that the total income amount is greater than the loan amount, and that the
time at residence and at employer are both greater than six months. This loan will be
approved by the policy you created.
5. Close Internet Explorer.
6. In Windows Explorer, copy BRE-Denied.xml and BRE-Approved.xml to the Lab11 folder
to create duplicates to use for testing purposes.
Copies of the messages are important because the Business Rule Engine will
permanently change the message.
7. In the Microsoft Business Rule Composer, right-click Version 1.0 – Deployed, and then
click Test Policy.
8. In the Select Facts dialog box, click AdvWorks.LoanApproval.LoanApplication, and then
click Add instance.
9. In the Open dialog box, navigate to C:\AllFiles\LabFiles\Lab11, click BRE-Approved Copy.xml, and then click Open.
10. In the Select Facts dialog box, click Test.
11. In the Microsoft Business Rule Composer, right-click Version 1.0 – Deployed, and then
click Test Policy.
12. In the Select Facts dialog box, click C:\\AllFiles\LabFiles\Lab11\Copy of BREApproved.xml, and then click Remove instance.
13. Click AdvWorks.LoanApproval.LoanApplication, and then click Add instance.
14. In the Open dialog box, navigate to C:\AllFiles\LabFiles\Lab11, click BRE-Denied Copy.xml, and then click Open.
15. In the Select Facts dialog box, click Test.
16. In Windows Explorer, open BRE-Approved - Copy.xml.
Notice that the loan status is now Approved and that the loan to income ratio has
been calculated.
17. In Windows Explorer, open BRE-Denied - Copy.xml.
Notice that the loan status is now Pending, and that the loan-to-income ratio has
been calculated.
18. Close Internet Explorer.
19. Close the Business Rule Composer.
Exercise 3: Integrating a Business Rule Policy into an Orchestration
Overview
BizTalk orchestrations use the Call Rules shape to invoke business rule policies. In this exercise,
you will create a new orchestration that is called by the ProcessOrder_Credit orchestration. This
orchestration calls the LoanApprovalProcess policy and has steps for the manual processing of
the loans that are not approved by the Business Rule Engine. You will then deploy and test the
application.
Create the ApproveLoan Orchestration
Procedure List
1. In Windows Explorer, navigate to C:\AllFiles\LabFiles\Lab11\AdvWorks, and then
double-click AdvWorks.sln to open the solution.
2. In Solution Explorer, right-click the LoanApproval project, point to Add, and then click
New Item.
3. In the Add New Item dialog box, click Orchestration Files, in the Name box, type
ApproveLoan.odx, and then click Add.
4. Right-click the ApproveLoan orchestration design surface, click Properties Window, and
in the Properties window, in the Type Modifier list, click Public.
Create Orchestration Parameters
Procedure List
1. In Orchestration View, right-click Orchestration Parameters, and then click New
Message Parameter.
2. In the Message_1 Properties window, in the Identifier box, type parSalesOrder, in the
Message Type list, expand Schemas, and then click <Select from referenced assembly>.
3. In the Select Artifact Type dialog box, in the left pane, click AdvWorks.Messaging, in the
right pane, click SalesOrder, and then click OK.
4. In Orchestration View, right-click Orchestration Parameters, and then click New
Message Parameter.
5. In the Message_1 Properties window, in the Identifier box, type parFinalLoan, in the
Direction list, click Out, in the Message Type list expand Schemas, and then click
AdvWorks.LoanApproval.FinalLoanDocument.
Create Messages
Procedure List
1. In Orchestration View, right-click Messages, and then click New Message.
2. In the Message_1 Properties window, in the Identifier box, type msgInterimLoan, in the
Message Type list, expand Schemas, and then click
AdvWorks.LoanApproval.FinalLoanDocument.
3. In Orchestration View, right-click Messages, and then click New Message.
4. In the Message_1 Properties window, in the Identifier box, type msgLoanApp, in the
Message Type list, expand Schemas, and then click
AdvWorks.LoanApproval.LoanApplication.
Create a Correlation Type
Procedure List
1. In Orchestration View, expand Types, right-click Correlation Types, and then click New
Correlation Type.
2. In the Correlation Properties dialog box, in the left pane, expand
AdvWorks.LoanApproval.PropertySchema, click Amount, click Add, click Customer,
click Add, and then click OK.
3. In the CorrelationType_1 Properties window, in the Identifier box, type
ManualApprovalCorrType.
Create a Correlation Set
Procedure List
1. In Orchestration View, right-click Correlation Sets, and then click New Correlation Set.
2. In the Correlation_1 Properties window, in the Identifier box, type
ManualApprovalCorrSet, and then in the Correlation Type list, click
AdvWorks.LoanApproval.ManualApprovalCorrType.
Add a Transform Shape
Procedure List
1. Right-click Drop a shape from the toolbox here, point to Insert Shape, and then click
Transform.
2. Configure the construct message and transform shapes with the properties shown in the
following table.
Construct Message Shape
Property
Value
Name
Construct msgLoanApp
Messages Constructed
msgLoanApp
Transform Shape
Property
Value
Name
Map to LoanApp
Map Name (Existing Map)
AdvWorks.LoanApproval.SalesOrder_To_LoanApp
Map Source
parSalesOrder
Map Destination
msgLoanApp
Add a Call Rules Shape
Procedure List
1. Drag a Call Rules shape from the Toolbox to the orchestration, directly below the
construct message shape.
2. In the Properties window, in the Name box, type Call Loan Approval Process, and then
click the ellipsis (…) button in the Configure Policy box.
3. In the Select the business policy you wish to call list, click LoanApprovalProcess, set the
Parameter Name to msgLoanApp, and then click OK.
Add a Decide Shape
Procedure List
1. Right-click the arrow below the call rules shape, point to Insert Shape, and then click
Decide.
2. In the Properties window, in the Name box, type Is the Loan Pre-Approved?, and then
click the Rule_1 branch.
3. In the Properties window, in the Name box, type Approved, and then click the ellipsis
(…) button in the Expression box.
4. In the BizTalk Expression Editor window, type the following expression, and then click
OK.
msgLoanApp.LoanConditions.LoanStatus==“Approved”
Add Shapes to the Approved Branch of the Decide Shape
Procedure List
1. Drag a Transform shape from the Toolbox to the Approved branch of the decide shape.
2. Drag a Message Assignment shape from the Toolbox to directly below the transform
shape inside the construct message shape.
3. Configure the shapes as shown in the following table.
Construct Message Shape
Property
Value
Name
Construct parFinalLoan
Message Constructed
parFinalLoan
Transform Shape
Property
Value
Name
Map to FinalLoan
Map Name (Existing Map)
AdvWorks.LoanApproval.SalesOrder_To_FinalLoan
Map Source
parSalesOrder
Map Destination
parFinalLoan
Message Assignment Shape
Property
Value
Name
Add Loan Properties
4. In the message assignment shape Properties window, in the Expression box, click the
click the ellipsis (…) button, type the following expression (four separate lines) in the
BizTalk Expression Editor window, and then click OK.
parFinalLoan.Loan.Amount = msgLoanApp.LoanConditions.LoanAmount;
parFinalLoan.Loan.LoanToIncomeRatio =
msgLoanApp.LoanConditions.LoanToIncome;
parFinalLoan.Loan.Status = msgLoanApp.LoanConditions.LoanStatus;
parFinalLoan.Loan.Term = msgLoanApp.LoanConditions.Term;
Add Shapes to the Else Branch of the Decide Shape
Procedure List
1. Right-click the Construct parFinalLoan construct shape, and then click Copy.
2. Below the Else branch of the decide shape, right-click Drop a shape from the toolbox
here, and then click Paste.
3. Change the configuration to the Construct Message, Transform, and Message
Assignment shapes to represent the following table.
Construct Message Shape
Property
Value
Name
Construct msgInterimLoan
Message Constructed
msgInterimLoan
Transform Shape
Property
Value
Name
Map to FinalLoan
Map Name (Existing Map)
AdvWorks.LoanApproval.SalesOrder_To_FinalLoan
Map Source
parSalesOrder
Map Destination
msgInterimLoan
Message Assignment Shape
Property
Value
Name
Add Loan Properties
4. Change the Expression in the Add Loan Properties shape below the Else branch to the
following expression (four lines).
msgInterimLoan.Loan.Amount=msgLoanApp.LoanConditions.LoanAmount;
msgInterimLoan.Loan.LoanToIncomeRatio =
msgLoanApp.LoanConditions.LoanToIncome;
msgInterimLoan.Loan.Status=msgLoanApp.LoanConditions.LoanStatus;
msgInterimLoan.Loan.Term=msgLoanApp.LoanConditions.Term;
5. Right-click below the construct message shape in the Else branch, point to Insert Shape,
and then click Send.
6. Right-click below the send shape in the Else branch, point to Insert Shape, and then click
Receive.
7. Configure the Send and Receive shapes as shown in the following table.
Send Shape
Property
Value
Initializing Correlation
Set
ManualApprovalCorrSet
Message
msgInterimLoan
Name
SharePoint Processing
Receive Shape
Property
Value
Following Correlation Set
ManualApprovalCorrSet
Message
parFinalLoan
Name
SharePoint Processing
Add Orchestration Ports
Procedure List
1. Right-click the right Port Surface, and then click New Configured Port.
2. Configure the port as shown in the following table.
Property
Value
Name
SharePointReq
Port Type Name (new Port Type)
SharePointType
Direction
Send
Binding
Specify later
3. Right-click the right Port Surface, and then click New Configured Port.
4. Configure the port as shown in the following table.
Property
Value
Name
SharePointResp
Port Type Name (existing Port Type)
SharePointType
Direction
Receive
Binding
Specify later
5. Connect the Send shape to the SharePointReq port, and then connect the Receive
shape to the SharePointResp port.
6. In Solution Explorer, right-click the AdvWorks solution, and then click Build Solution.
Configure the ProcessOrder_Credit Orchestration to call the ApproveLoan
Orchestration
Procedure List
1. In Solution Explorer, under Processes, double-click ProcessOrder_Credit.odx to open
the orchestration.
2. In the Process_Order orchestration, delete the Construct msgFinalLoan construct shape
(including the Map to Loan Final transform shape).
3. Right-click the arrow below the Receive Credit SO receive shape, point to Insert Shape,
and then click Call Orchestration.
4. In the Properties window, in the Name box, type Approve Loan, and then in the Called
Orchestration list, click <Select from a referenced assembly>.
5. In the Select Artifact Type dialog box, in the left pane, expand
AdvWorks.LoanApproval, in the right pane, click ApproveLoan, and then click OK.
6. In the Call Orchestration Properties window, click the ellipsis (…) button in the
Parameters box.
The parameters are automatically configured for you.
7. Click OK.
Add a Decide Shape
Procedure List
1. Right-click the arrow below the Approve Loan call orchestration shape, point to Insert
Shape, and then click Decide.
2. Rename the decide shape to Is Loan Approved?, and then click the Rule_1 branch.
3. In the Properties window, in the Name box, type Approved, and then click the ellipsis
(…) button in the Expression box.
4. In the BizTalk Expression Editor window, type the following expression, and then click
OK.
msgFinalLoan.Loan.Status=="Approved"
5. Drag a Send shape from the Toolbox to the Else branch of the Is Loan Approved? decide
shape.
6. In the Properties window, in the Name box, type Loan Denial, and then in the Message
list, click msgSalesOrder.
7. Drag the Loan approved so several things need to be done group shape to the
Approved branch of the Is Loan Approved? decide shape.
Configure a Send Port
Procedure List
1. Right-click the right Port Surface, and then click New Configured Port.
2. Configure the port as shown in the following table.
Property
Value
Name
LoanDenial
Port Type Name (new Port Type)
LoanDenialType
Direction
Send
Binding
Specify later
3. Connect the Loan Denial send shape to the LoanDenial send port.
4. In Windows Explorer, navigate to C:\AllFiles\LabFiles\Lab11, and then open
ProcessOrder_Credit.png.
Your ProcessOrder_Credit orchestration should look similar to the one shown in this
picture.
5. Close ProcessOrder_Credit.png.
Build and Deploy the Solution
Procedure List
1. In Solution Explorer, right-click the AdvWorks solution, and then click Build Solution.
2. In Solution Explorer, right-click the AdvWorks solution, and then click Deploy Solution.
Configure Port Bindings
Procedure List
1. On the Start menu, click All Programs, click Microsoft BizTalk Server 2010, and then
click BizTalk Server Administration.
2. In the BizTalk Administration Console, expand BizTalk Server Administration, BizTalk
Group, Applications, and Adventure Works.
3. Right-click Adventure Works, and then click Configure.
4. In the Configure Application dialog box, click ApproveLoan.
None of the ports are bound.
5. In the Configure Application dialog box, click ProcessOrder_Credit.
The new LoanDenial port is not bound.
6. Click OK.
7. Right-click the Adventure Works application, point to Import, and then click Bindings.
8. In the Import Bindings dialog box, navigate to C:\AllFiles\LabFiles\Lab11, and then
double-click Lab11Bindings.xml.
Test the Application
Procedure List
1. To extend the expiration period of the Microsoft Office installation on this virtual
machine, in Windows Explorer, navigate to C:\AllFiles and double-click extend.cmd.
2. In the BizTalk Server Administration Console, right-click the Adventure Works
application, and then click Start.
3. In the Start ‘Adventure Works’ Application dialog box, click Start.
4. In Windows Explorer, navigate to C:\AllFiles\LabFiles\Lab11, and then open
CredSalesOrder-Approved1.xml.
All loans greater than or equal to 1000 are sent to Woodgrove Bank, all other loans
will be handled by the Adventure Works financial department. This order meets all of
the conditions to be approved by the business rule policy. The number of months at
residence and months employed are both greater than 6, and the total amount of
monthly income is greater than the total amount of the order.
5. Close Microsoft InfoPath.
6. Copy CredSalesOrder-Approved1.xml to the SalesOrderIN folder.
7. Open the OUT folder.
There are three messages: the notification that goes to Woodgrove Bank, the
completed message, and the restock message.
8. Delete the three messages.
9. In Windows Explorer, navigate to C:\AllFiles\LabFiles\Lab11, and then open
CredSalesOrder-Internal1.xml.
This order meets all of the conditions to be approved by the business rule policy. The
number of months at residence and months employed are both greater than 6, and
the total amount of monthly income is greater than the total amount of the order.
However, it will be processed differently from the first order; this one will not be sent
to Woodgrove Bank. Instead, it will be handled by the Adventure Works financial
department.
10. Close InfoPath.
11. Copy CredSalesOrder-Internal1.xml to the SalesOrderIN folder.
12. Open the OUT folder.
Notice the completed message and the restock message.
13. Delete the two messages.
14. In Windows Explorer, navigate to C:\AllFiles\LabFiles\Lab11, and then open
CredSalesOrder-Denied1.xml.
This order does not meet the residency and employment conditions. The order will
not be approved and will require manual processing in order to approve or deny the
loan.
15. Close InfoPath.
16. Copy CredSalesOrder-Denied1.xmlto the SalesOrderIN folder.
17. Open the OUT folder.
18. There are no new messages.
19. In Internet Explorer, navigate to http://localhost/LoanApplications, and then open the
message in InfoPath.
20. In the Status list of the loan application, click Approved, and then close the form, saving
your changes.
21. Refresh the page, and notice that the message has been picked up for processing.
22. In Windows Explorer, navigate to C:\AllFiles\LabFiles\Lab11\OUT, and notice the three
messages.
23. In Windows Explorer, navigate to C:\AllFiles\LabFiles\Lab11, and then copy
CredSalesOrder-Denied1.xml to the SalesOrderIn folder.
24. In Internet Explorer, navigate to
http://localhost/LoanApplications/Forms/AllItems.aspx, and then open the message in
InfoPath.
25. In the Status list of the loan application, click Denied, and then close the form, saving
your changes.
26. Refresh the page, and notice that the message has been picked up for processing.
27. In Windows Explorer, navigate to C:\AllFiles\LabFiles\Lab11\OUT, and notice the denial
message.