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 organizations 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 banks 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 .NETbased 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 predefined 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 interfacethe

Business Rule Composerthat 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 vocabulariesdomain-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 non-English 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

On the Start menu, point to All Programs, point to Microsoft

BizTalk Server 2010, and then click Business Rule Composer.

7. In the Open Rule Store dialog box, click OK.

8. 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.
9. In the Facts Explorer pane, under LoanProcess, expand Version 1.0
Published.

A vocabulary is a collection of definitions that provide simple-toread aliases for complex message values or fields in a database.
10. 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.
11. 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.
12. Click Update Loan Status.

The Update Loan Status definition is used to update the Status field
of the message.
13. 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.
14. 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, its 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

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.

15. 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.

16. Close Microsoft Internet Explorer.

17. In Policy Explorer, right-click Version 1.0 Deployed, and then click
Test Policy.
18. In the Select Facts dialog box, click
AdvWorks.LoanApproval.LoanApplication, and then click Add
instance.
19. 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.
20. In the Select Facts dialog box, click Test.
21. 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.
22. 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.
23. In Policy Explorer, right-click Version 1.0 Deployed, and then click
Test Policy.
24. In the Select Facts dialog box, click
C:\AllFiles\DemoCode\Module11\Copy of LoanApplication
Approved.xml, and then click the Remove instance button.
25. In the Select Facts dialog box, click
AdvWorks.LoanApproval.LoanApplication, and then click the Add
instance button.
26. 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.
27. In the Select Facts dialog box, click Test.
28. 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.
29. 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.
30. 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 applications 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

Resume the bt10d-demos virtual machine.

In Windows Explorer, navigate to

C:\AllFiles\DemoCode\Module11\AdvWorks, and then double-click
AdvWorks.sln to open the solution.

31. In Solution Explorer, double-click ProcessLoans.odx to open the

orchestration.
32. From the Toolbox, drag a Call Rules shape to the orchestration directly
below the Receive Credit SO shape.
33. 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.
34. 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 messages 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.
35. 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:

Fact Activity. Select this check box when tracking the instance data on
which the policy operates.

36. Condition Evaluation. This check box allows you to track the True/False
result of the conditions in the selected policy.
37. Rule Firings. This check box allows you to track the actions triggered as
a result of the policy.
38. 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.
39. Double click startBtServices.cmd.
40. 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.
41. In the Open Rule Store dialog box, click OK.
42. In the Facts Explorer pane, on the Vocabularies tab, right-click
Vocabularies, and then click Add New Vocabulary.
43. 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.
44. On the Welcome to the Vocabulary Definition Wizard page, click
XML Document Element or Attribute, and then click Next.
45. In the Definition name box, type Primary Income.
46. In the Definition description box, type Amount of principal
income.
47. Click the Browse button, navigate to
C:\AllFiles\LabFiles\Lab11\AdvWorks\LoanApproval\LoanApplica
tion.xsd, and then click Open.
48. In the Select Binding dialog box, expand LoanApp and Income, click
BasicSalary, and then click OK.
49. Click Perform Get operation.
50. In the Display name box, type Monthly Primary Income, and then
click Finish.
51. Under LoanProcessing, right-click Version 1.0 (not saved), and then
click Add New Definition.
52. On the Welcome to the Vocabulary Definition Wizard page, click
XML Document Element or Attribute, and then click Next.
53. In the Definition name box, type Employment (months).

54. In the Definition description box, type Length of employment.

55. Click the Browse button, navigate to
C:\AllFiles\LabFiles\Lab11\AdvWorks\LoanApproval\LoanApplica
tion.xsd, and then click Open.
56. In the Select Binding dialog box, expand LoanApp and
Employment, click TimeInMonths, and then click OK.
57. Click Perform Get operation.
58. In the Display name box, type Months Employed, and then click
Finish.
59. Under LoanProcessing, right-click Version 1.0 (not saved), and then
click Add New Definition.
60. On the Welcome to the Vocabulary Definition Wizard page, click
XML Document Element or Attribute, and then click Next.
61. In the Definition name box, type Loan Amount.
62. In the Definition description box, type Desired loan amount.
63. Click the Browse button, navigate to
C:\AllFiles\LabFiles\Lab11\AdvWorks\LoanApproval\LoanApplica
tion.xsd, and then click Open.
64. In the Select Binding dialog box, expand LoanApp and
LoanConditions, click LoanAmount, and then click OK.
65. Click Perform Get operation.
66. In the Display name box, type Requested Loan Amount, and then
click Finish.
67. Under LoanProcessing, right-click Version 1.0 (not saved), and then
click Add New Definition.
68. On the Welcome to the Vocabulary Definition Wizard page, click
XML Document Element or Attribute, and then click Next.
69. In the Definition name box, type Residency (months).
70. In the Definition description box, type Length at residence.
71. Click the Browse button, navigate to
C:\AllFiles\LabFiles\Lab11\AdvWorks\LoanApproval\LoanApplica
tion.xsd, and then click Open.
72. In the Select Binding dialog box, expand LoanApp and Residency,
click TimeInMonths, and then click OK.
73. Click Perform Get operation.
74. In the Display name box, type Months at Current Residence, and
then click Finish.
75. Under LoanProcessing, right-click Version 1.0 (not saved), and then
click Add New Definition.
76. On the Welcome to the Vocabulary Definition Wizard page, click
XML Document Element or Attribute, and then click Next.

77. In the Definition name box, type Secondary Income.

78. In the Definition description box, type Income from sources other
than primary income.
79. Click the Browse button, navigate to
C:\AllFiles\LabFiles\Lab11\AdvWorks\LoanApproval\LoanApplica
tion.xsd, and then click Open.
80. In the Select Binding dialog box, expand LoanApp and Income, click
OtherIncome, and then click OK.
81. Click Perform Get operation.
82. 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.
83. On the Welcome to the Vocabulary Definition Wizard page, click
XML Document Element or Attribute, and then click Next.
84. In the Definition name box, type Update Loan Status.
85. Click the Browse button, navigate to
C:\AllFiles\LabFiles\Lab11\AdvWorks\LoanApproval\LoanApplica
tion.xsd, and then click Open.
86. In the Select Binding dialog box, expand LoanApp and
LoanConditions, click LoanStatus, and then click OK.
87. Click Perform Set operation, and then click Next.
88. 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.
89. On the Welcome to the Vocabulary Definition Wizard page, click
XML Document Element or Attribute, and then click Next.
90. In the Definition name box, type Set Loan to Income Ratio.
91. Click the Browse button, navigate to
C:\AllFiles\LabFiles\Lab11\AdvWorks\LoanApproval\LoanApplica
tion.xsd, and then click Open.
92. In the Select Binding dialog box, expand LoanApp and
LoanConditions, click LoanToIncome, and then click OK.
93. Click Perform Set operation, and then click Next.

94. 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.
95.
On the Welcome to the Vocabulary Definition Wizard page,
click Constant Value, Range of Values, or Set of Values, and then
click Next.
96.
In the Definition name box, type Month Range, click Set of
Values, and then click Next.
97.

In the Display name box, type Month Range.

98. 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.
99. On the Welcome to the Vocabulary Definition Wizard page, click
Constant Value, Range of Values, or Set of Values, and then click
Next.
100. In the Definition name box, type Status Range, click Set of
Values, and then click Next.
101.

In the Definition type list, click System.String.

102. 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.
103.

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.
104.

Rename the policy LoanApprovalProcess.

Create the Approved Rule

Procedure List
1 Right-click Version 1.0 (not saved), and then click Add New Rule.
105.

Rename the rule Approved.

106. In the IF pane, right-click Conditions, and then click Add logical
AND.
107.

Right-click AND, point to Predicates, and then click GreaterThan.

108.

Right-click argument1, point to Functions, and then click Add.

109. Drag Primary Income from the Facts Explorer pane to value1, and
then drag Secondary Income to value2.
110.

Drag Loan Amount from the Facts Explorer pane to argument2.

111.

Right-click AND, and then click Add logical OR.

112. Right-click OR, point to Predicates, and then click

GreaterThanEqual.
113. Drag Employment (months) from the Facts Explorer pane to
argument1, and then drag Month Range to argument2.
114.

Click Month Range, and then in the drop-down list, click 6.

115. Right-click OR, point to Predicates, and then click

GreaterThanEqual.
116. Drag Residency (months) from the Facts Explorer pane to
argument1, and then drag Month Range to argument2.
117.

Click Month Range, and then in the drop-down list, click 6.

118. Drag Update Loan Status from the Facts Explorer pane to
Actions in the THEN pane.
119. Drag Status Range from the Facts Explorer pane to <empty
string>.
120. 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.
121.

Rename the rule Denied Income.

122. Right-click Conditions, point to Predicates, and then click

LessThanEqual.
123.

Right-click argument1, point to Functions, and then click Add.

124. Drag Primary Income from the Facts Explorer pane to value1, and
then drag Secondary Income to value2.
125.

Drag Loan Amount from the Facts Explorer pane to argument2.

126. Drag Update Loan Status from the Facts Explorer pane to
Actions in the THEN pane.
127. Drag Status Range from the Facts Explorer pane to <empty
string>.
128.

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.
129.

Rename the rule Denied Residency and Employment.

130.

Right-click Conditions, and then click Add logical AND.

131.

Right-click AND, point to Predicates, and then click LessThan.

132. Drag Employment (months) from the Facts Explorer pane to

argument1, and then drag Month Range to argument2.
133.

Click Month Range, and then in the drop-down list, click 6.

134.

Right-click AND, point to Predicates, and then click LessThan.

135. Drag Residency (months) from the Facts Explorer pane to

argument1, and then drag Month Range to argument2.
136.

Click Month Range, and then in the drop-down list, click 6.

137. Drag Update Loan Status from the Facts Explorer pane to
Actions in the THEN pane.
138. Drag Status Range from the Facts Explorer pane to <empty
string>.
139.

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.
140.

Rename the rule Loan to Salary Ratio.

141. Right-click Conditions, point to Predicates, and then click

GreaterThan.

142. Drag Loan Amount from the Facts Explorer pane to argument1,
click argument2, and then type 100.
143.

Drag Set Loan to Income Ratio to Actions in the THEN pane.

144.

Right-click 0, point to Functions, and then click Divide.

145.

Right-click value1, point to Functions, and then click Add.

146. Drag Primary Income to value1, and then drag Secondary

Income to value2 (inside the add function).
147.

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.
148.

Right-click Version 1.0 - Published, and then click Deploy.

149. In Windows Explorer, navigate to C:\AllFiles\LabFiles\Lab11, and

then open BRE-Denied.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.
150.

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.

151.

Close Internet Explorer.

152. In Windows Explorer, copy BRE-Denied.xml and BREApproved.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.
153. In the Microsoft Business Rule Composer, right-click Version 1.0
Deployed, and then click Test Policy.
154. In the Select Facts dialog box, click
AdvWorks.LoanApproval.LoanApplication, and then click Add
instance.
155. In the Open dialog box, navigate to C:\AllFiles\LabFiles\Lab11,
click BRE-Approved - Copy.xml, and then click Open.
156.

In the Select Facts dialog box, click Test.

157. In the Microsoft Business Rule Composer, right-click Version 1.0

Deployed, and then click Test Policy.

158. In the Select Facts dialog box, click

C:\\AllFiles\LabFiles\Lab11\Copy of BRE-Approved.xml, and then
click Remove instance.
159. Click AdvWorks.LoanApproval.LoanApplication, and then click
Add instance.
160. In the Open dialog box, navigate to C:\AllFiles\LabFiles\Lab11,
click BRE-Denied - Copy.xml, and then click Open.
161.

In the Select Facts dialog box, click Test.

162.

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.

163.

In Windows Explorer, open BRE-Denied - Copy.xml.

Notice that the loan status is now Pending, and that the loan-toincome ratio has been calculated.

164.

Close Internet Explorer.

165.

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.
166. In Solution Explorer, right-click the LoanApproval project, point to
Add, and then click New Item.
167. In the Add New Item dialog box, click Orchestration Files, in the
Name box, type ApproveLoan.odx, and then click Add.
168. 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.
169. 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>.
170. In the Select Artifact Type dialog box, in the left pane, click
AdvWorks.Messaging, in the right pane, click SalesOrder, and then
click OK.
171. In Orchestration View, right-click Orchestration Parameters, and
then click New Message Parameter.
172. 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.

173. 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.
174. In Orchestration View, right-click Messages, and then click New
Message.
175. 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.
176. 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.
177. 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.
178. 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.
179. 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.
180. In the Properties window, in the Name box, type Call Loan
Approval Process, and then click the ellipsis () button in the
Configure Policy box.
181. 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.
182. In the Properties window, in the Name box, type Is the Loan PreApproved?, and then click the Rule_1 branch.
183. In the Properties window, in the Name box, type Approved, and
then click the ellipsis () button in the Expression box.
184. 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.

185.

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_Fi
nalLoan

Map Source

parSalesOrder

Map Destination

parFinalLoan
Message Assignment Shape

Property

Value

Name

Add Loan Properties

186. 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.
187. Below the Else branch of the decide shape, right-click Drop a
shape from the toolbox here, and then click Paste.
188. 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_Fi
nalLoan

Map Source

parSalesOrder

Map Destination

msgInterimLoan
Message Assignment Shape

Property

Value

Name

Add Loan Properties

189. 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;

190. Right-click below the construct message shape in the Else branch,
point to Insert Shape, and then click Send.
191. Right-click below the send shape in the Else branch, point to Insert
Shape, and then click Receive.
192. 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.
193.

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

194. Right-click the right Port Surface, and then click New Configured
Port.
195.

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

196. Connect the Send shape to the SharePointReq port, and then
connect the Receive shape to the SharePointResp port.
197. 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

In Solution Explorer, under Processes, double-click

ProcessOrder_Credit.odx to open the orchestration.

198. In the Process_Order orchestration, delete the Construct

msgFinalLoan construct shape (including the Map to Loan Final
transform shape).
199. Right-click the arrow below the Receive Credit SO receive shape,
point to Insert Shape, and then click Call Orchestration.
200. In the Properties window, in the Name box, type Approve Loan,
and then in the Called Orchestration list, click <Select from a
referenced assembly>.
201. In the Select Artifact Type dialog box, in the left pane, expand
AdvWorks.LoanApproval, in the right pane, click ApproveLoan, and
then click OK.
202. In the Call Orchestration Properties window, click the ellipsis ()
button in the Parameters box.

The parameters are automatically configured for you.

203.

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.
204. Rename the decide shape to Is Loan Approved?, and then click
the Rule_1 branch.
205. In the Properties window, in the Name box, type Approved, and
then click the ellipsis () button in the Expression box.
206. In the BizTalk Expression Editor window, type the following
expression, and then click OK.
msgFinalLoan.Loan.Status=="Approved"

207. Drag a Send shape from the Toolbox to the Else branch of the Is
Loan Approved? decide shape.
208. In the Properties window, in the Name box, type Loan Denial, and
then in the Message list, click msgSalesOrder.
209. 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.
210.

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

211. Connect the Loan Denial send shape to the LoanDenial send
port.
212. 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.
213.

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.
214. 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.
215. In the BizTalk Administration Console, expand BizTalk Server
Administration, BizTalk Group, Applications, and Adventure
Works.
216.

Right-click Adventure Works, and then click Configure.

217.

In the Configure Application dialog box, click ApproveLoan.

None of the ports are bound.

218. In the Configure Application dialog box, click

ProcessOrder_Credit.

The new LoanDenial port is not bound.

219.

Click OK.

220. Right-click the Adventure Works application, point to Import, and

then click Bindings.

221. 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.

In the Start Adventure Works Application dialog box, click Start.

222. 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.
223.

Close Microsoft InfoPath.

224. Copy CredSalesOrder-Approved1.xml to the SalesOrderIN

folder.
225.

Open the OUT folder.

There are three messages: the notification that goes to Woodgrove
Bank, the completed message, and the restock message.

226.

Delete the three messages.

227. 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.
228.

Close InfoPath.

229.

Copy CredSalesOrder-Internal1.xml to the SalesOrderIN folder.

230.

Open the OUT folder.

Notice the completed message and the restock message.

231.

Delete the two messages.

232. 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.
233.

Close InfoPath.

234.

Copy CredSalesOrder-Denied1.xmlto the SalesOrderIN folder.

235.

Open the OUT folder.

236.

There are no new messages.

237. In Internet Explorer, navigate to

http://localhost/LoanApplications, and then open the message in
InfoPath.
238. In the Status list of the loan application, click Approved, and then
close the form, saving your changes.
239. Refresh the page, and notice that the message has been picked up
for processing.
240. In Windows Explorer, navigate to C:\AllFiles\LabFiles\Lab11\OUT,
and notice the three messages.
241. In Windows Explorer, navigate to C:\AllFiles\LabFiles\Lab11, and
then copy CredSalesOrder-Denied1.xml to the SalesOrderIn
folder.
242. In Internet Explorer, navigate to
http://localhost/LoanApplications/Forms/AllItems.aspx, and then
open the message in InfoPath.
243. In the Status list of the loan application, click Denied, and then
close the form, saving your changes.
244. Refresh the page, and notice that the message has been picked up
for processing.
245. In Windows Explorer, navigate to C:\AllFiles\LabFiles\Lab11\OUT,
and notice the denial message.