Cronica Del Pajaro Que Da Cuerd - Haruki Murakami

Microsoft MCTS BizTalk
Server 2010
Biztalk Developer Courseware
Microsoft Certified Technology Specialist
Version 1.0
www.firebrandtraining.com
Module 0: Introduction
Time estimated: 30 minutes
Provide an overview of the course
Course timing
Approximate timings for this course are included in the following tables.
Day 1
Start End Module
9:00 9:30 Introduction
9:30 11:00 Module 1: Introduction to BizTalk Server 2010
11:00 11:15 Break
11:15 11:45 Lab: Examining a BizTalk Application
11:45 12:45 Module 2: Creating Schemas
12:45 1:45 Lunch

1:45 2:15 Lab: Creating and Configuring BizTalk Schemas
2:15 3:15 Module 3: Creating Maps
3:15 3:30 Break
3:30 4:00 Lab: Creating a BizTalk Map
Module 4: Deploying and Managing BizTalk

4:00 5:00
Applications
Day 2
Start End Module

9:00 9:30 Day 1 review
9:30 10:00 Lab: Deploying and Managing BizTalk Applications
10:00 10:45 Module 5: Routing BizTalk Messages
10:45 11:00 Break
11:00 11:45 Module 5: Routing BizTalk Messages (Continued)
11:45 12:45 Lunch

12:45 1:30 Lab: Routing BizTalk Messages
1:30 2:30 Module 6: Creating Pipelines
2:30 2:45 Break
2:45 3:45 Lab: Creating Pipelines
3:45 5:00 Module 7: Integrating with Adapters

Day 3
Start End Module
9:30 10:15 Lab: Integrating with Adapters
10:15 10:30 Break
10:30 11:30 Module 8: Creating a BizTalk Orchestration
11:30 12:15 Lab: Creating a BizTalk Orchestration
12:15 1:15 Lunch
1:15 2:15 Module 9: Automating Business Processes
2:15 3:15 Lab: Automating Business Processes
3:15 3:30 Break
3:30 4:15 Module 10: Creating Transactional Business Processes
4:15 5:00 Lab: Creating Transactional Business Processes
Day 4
Start End Module
9:30 10:30 Module 11: Business Rules
10:30 10:45 Break
10:45 11:45 Lab: Rules
11:45 12:30 Module 12: BAM
12:30 1:30 Lunch
1:30 2:15 Lab: BAM
2:15 3:15 Module 13: Using WCF Receive Adapters
3:15 3:30 Break
3:30 4:00 Lab: Using WCF Receive Adapters
4:00 5:00 Module 14: Using WCF Send Adapters
Day 5
Start End Module
9:30 10:00 Lab: Using WCF Send Adapters
10:00 10:15 Break
10:15 11:15 Module 15: Implementing Messaging Patterns
11:15 12:00 Lab: Implementing Messaging Patterns
Additional topics (optional):

Module 16: Integrating with the WCF LOB
Adapter Framework
Module 17: WF and WCF Interceptors for BAM
Module 18: Receiving EDI Messages
Module 19: Sending EDI Messages
Facilities
About This Course
Description
This five-day instructor-led course provides students with the knowledge and skills to
integrate internal and external systems and trading partners and to develop business
process integration applications using BizTalk Server 2010.
Audience
This course is intended for developers who are responsible for developing BizTalk Server
2010 e-business solutions.
Individuals who attend this course are expected to have the following prerequisite
knowledge or experience:
 At least two years of experience using Visual Basic, C#, or Java to develop distributed
applications
 Familiarity with systems integration and Web services terminology and concepts
 Familiarity with Visual Studio 2010.
 Working knowledge of XML
Prior experience with of BizTalk Server is not required.
Course Outline
Course outline
This course contains a total of nineteen modules. The last four modules are optional, and
they may be covered as time permits. Each module contains multiple lessons.
Module 1, “Introduction to BizTalk Server 2010,” introduces the core features of BizTalk
Server 2010 and how messaging and orchestration services work. Also, this module provides
a look at what is new in BizTalk Server 2010.
Module 2, “Creating Schemas,” shows how to create and manage XML and flat-file schemas.
Module 3, “Creating Maps,” shows how to create maps and use functoids to perform
mapping operations.
Module 4, “Deploying and Managing BizTalk Application,” shows how to deploy applications
to the BizTalk Server computers that will host the application.
Module 5, “Routing BizTalk Messages,” shows how to filter and route messages to BizTalk
send ports and orchestrations.
Module 6, “Creating Pipelines,” shows how to use the Pipeline Designer to create and
configure send and receive pipelines.
Module 7, “Integrating with Adapters,” shows how to configure adapters to integrate BizTalk
servers with systems, databases, and applications.
Module 8, “Creating a BizTalk Orchestration,” shows how to use BizTalk Orchestration
Designer to create an orchestration.
Course Outline (continued)
Briefly describe each module.
Course outline (continued)

Module 9, “Automating Business Processes,” shows how to use BizTalk Orchestration Shapes
to define business processes.
Module 10, “Creating Transactional Business Processes,” shows how to create
orchestrations that include transaction and exception handling capabilities.
Module 11, “Integrating Business Rules,” shows how to configure business rules and how to
call the Business Rule Engine from within an orchestration.
Module 12, “Enabling Business Activity Monitoring,” shows how to configure and use
Business Activity Monitoring (BAM) to monitor business activity.
Module 13, “Using WCF Receive Adapters,” shows how to configure the WCF receive
adapters, and how to publish orchestrations and schemas as web services.
Module 14, “Using WCF Send Adapters,” shows use the BizTalk WCF Service Consuming
Wizard to import metadata from a web service, and how to use the code generated by the
wizard.
Module 15, “Implementing Messaging Patterns,” shows how to use dynamic binding and
correlation to implement more adaptable orchestrations.
Course Outline - Optional Topics
Briefly describe each optional module.
Course outline - Optional Topics.

These topics are not required. They may be covered as time permits.
Module 16, “Integrating with the WCF LOB Adapter Framework,” shows how to create
custom adapters to enable integration with Line of Business (LOB) systems using WCF
services.
Module 17, “WF and WCF Interceptors for BAM,” shows how to configure BAM Interceptors
to gather tracking data Windows Workflow (WF) and Windows Communication (WCF)
applications.
Module 18, “Receiving EDI Messages,” shows how to configure BizTalk Server 2010 to accept
EDI messages from trading partners, and how to use the new Trading Partner Management
(TPM) features.
Module 19, “Sending EDI Messages,” shows how to configure BizTalk Server 2010 to send
EDI messages to trading partners.
Setup
Explain the classroom setup
Hyper-V configuration
In this course, you will use Microsoft Hyper-V R2 virtual machines to perform the hands-on
practices and labs.
The following table shows the role of each virtual machine used in this course.
Virtual machine Role

bt10d-01.vmc Supports the lab for modules 1 - 3
bt10d-04.vmc Supports the lab for module 4
Course files
There are files associated with the demonstrations, practices, and labs in this course. The
files are located on each student computer, in the folder C:\Microsoft BizTalk Server 2010
Training.
Classroom setup
Each classroom computer will have the same virtual machine configured in the same way.
Each of the labs in this course uses its own virtual machine. There are 14 virtual machines.
Course hardware level

To ensure a satisfactory student experience, Microsoft Learning requires a minimum
equipment configuration for trainer and student computers in all Microsoft Certified Partner
for Learning Solutions (CPLS) classrooms in which Official Microsoft Learning Products are
used. This course requires a hardware level 5 computer, which includes but is not limited to:
2 GB of RAM, 40 GB of free disk space, and a Pentium IV 2.4-gigahertz processor.
Demonstration: Using Hyper-V
Demonstrate how to use Microsoft Hyper-V
Hyper-V demonstration
In this demonstration, your instructor will help familiarize you with the Virtual PC
environment in which you will work to complete the practices and labs in this course. You
will learn:
 How to start Hyper-V.
 How to start a virtual machine.
 How to log on to a virtual machine.
 How to switch between full screen and window modes.
 How to pause a virtual machine
 How to resume a virtual machine
 How to distinguish the virtual machines that are used in the practices for this course.
 How to close Virtual PC.
Keyboard shortcuts
While working in the Hyper-V environment, you might find it helpful to use keyboard
shortcuts. Some useful shortcuts include:
 CTRL-ALT+END to log on to the Virtual Machine.
 CTRL-ALT+BREAK to switch between full-screen and window modes.
For more information about using Hyper-V, see Hyper-V Help.
Module 1: Introduction to BizTalk Server
2010
Time estimated: 120 Minutes
Module objective:
In this module, you will learn how to:
Describe the BizTalk message processing architecture and identify the new features and toolsets
provided in BizTalk Server 2010.
Overview
Microsoft® BizTalk® Server 2010 helps customers efficiently and effectively integrates
systems, employees, and trading partners faster than ever before. BizTalk Server 2010
introduces a host of new performance features and an improved toolset that enables
developers, IT professionals, and business analysts to build, deploy, and analyze complex
application integration and business process automation scenarios.
Lesson 1: What Is BizTalk Server 2010?
Lesson objective:
Describe common BizTalk Server 2010 scenarios, the overall messaging architecture, and the
common job roles and toolsets used with BizTalk.
Overview
BizTalk Server 2010 solves common problems that many businesses encounter with
automating business processes: integrating multiple heterogeneous systems and
communicating with business partners. This section provides an overview of BizTalk Server
2010 and identifies several common BizTalk integration scenarios. It will also provide a
detailed look at how BizTalk works to processes messages.
BizTalk Integration Services and Tools
Describe the services and tools provided in BizTalk Server 2010.
Overview
BizTalk Server 2010 is an efficient business-process management server that provides
powerful messaging and orchestration services and development tools. BizTalk unifies these
services and development tools to provide a smooth design experience for developers
designing a business process as well as a robust environment for deploying and executing
business processes.
BizTalk Tools and Services

The following services and tools are included in BizTalk Server 2010:
 Messaging services. Messaging services transform and route messages to and

between business processes
 Orchestration services. The Orchestration engine is responsible for processing
documents in an automated workflow application.
 Application development tools. BizTalk provides a number of graphical tools that
enable developers to perform such tasks as creating, testing, and deploying
schemas, maps, and orchestrations.
 Business rule engine. The business rule composer and the associated runtime engine
enable dynamic business policies and logic to be integrated within a business
process without the need to recode and redeploy the BizTalk application.
 Message activity tracking. The BizTalk Administration Console is used to monitor
and debug message activity and orchestrations.
 Web services integration. BizTalk enables Web services to be consumed by a
business process (orchestration) or for a business process to be made available as a
WCF service for consumption by client applications.
 Business Activity Monitoring (BAM). BAM is used to monitor real-time or archived
statistical data through end-to-end business processes.
What Problems Does BizTalk Server 2010 Solve?
Describe business and integration problems solved by BizTalk Server
Multiple Applications
Businesses often acquire multiple systems and applications from different vendors to
support their business needs. This results in a variety of applications that run on dedicated
platforms and which were not designed to work together. This is because each application is
usually designed in isolation to fulfill a specific purpose such as inventory, human resources,
or customer relationship management (CRM).
Companies wanting to integrate information from these internal applications discover that
integrating systems can be an expensive and time-consuming task. BizTalk helps to solve
many of the problems associated with integrating systems and managing business
processes.
Common Complaints
Consider the following common integration complaints:
 Disparate applications. “It is too difficult to integrate dissimilar applications within

my company.”
 Programming overruns. “It takes too long to develop integrated applications for my
company’s enterprise resource plan with our existing development tools.”
 Time-consuming deployment. “Deploying a business process to integrate with my
trading partner’s system takes practically as long as developing the process in the
first place.”
 Dissimilar reports. “There is no way to generate integrated, timely reports from my
various applications, because the data is stored in so many places.”
 Modification difficulties. “Once my internal applications are integrated, changing
them is arduous and expensive.”
 Lack of set procedures. “My company does not have a consistent method for
implementing our critical business processes.”
 Limited tracking. “I have no way of extracting usable, real-time data from a running
business process.”
 Changing partners. “If another business offers me a better deal, it is too difficult to
take advantage of it because of all of the IT infrastructure changes that it would
require.”
What Is BizTalk Server 2010 Integration? (Scenario)
Describe a typical BizTalk Server 2010 integration scenario.
BizTalk Integration
BizTalk Server 2010 facilitates integrating internal applications and securely connects with
your business partners over the Internet. Companies need to integrate applications,
systems, and technologies from a variety of sources. To make this easier, BizTalk delivers
integration technology and BizTalk Server 2010 offers with many industry accelerators and
adapters.
Enterprise Application Integration Scenario

In this scenario, an inventory application, perhaps running on a mainframe, determines that
the stock of an item is low and issues a request to order more of that item. The following
steps occur:
1. The request is sent to a BizTalk Server 2010 application
2. The BizTalk application requests a purchase order (PO) from the organization’s
Enterprise Resource Planning (ERP) application.
3. The ERP application, which might be running on a UNIX system, sends back the
requested PO.
4. The BizTalk application informs a fulfillment application, built on the Microsoft .NET
Framework, that the item should be ordered.
In this example, each application communicates by using a different protocol, using message
formats specific to the application. This means that the BizTalk messaging engine must be
able to communicate with each application in its native communication protocol and format
and also convert the messages to the protocol and format required by the other systems.
Notably, no single application manages the complete business process. The BizTalk
application has the capability of coordinating and tracking the status of all of the parts of the
complete business process.
What Is BizTalk Server 2010 Business Process Automation?
Describe a typical BizTalk Server 2010 business process automation scenario.
Business Process Automation

Business process automation enables the coordination of business processes, such as
approving a purchase order, with people and business applications such as enterprise
resource planning (ERP), customer relationship management (CRM), or line of business (LOB)
applications. These processes frequently start as manual tasks that require integration and
input with many different systems and individuals. The process may require days, weeks, or
months to complete.
For example, assume that your company receives purchase orders from several different
trading partners in various formats. Before the purchase order can be processed, it must be
converted to an internal format that is usable by your internal systems. Next, your company
may have specific rules that must be applied to a received purchase order before it can be
fulfilled, such as the availability of the product ordered, the credit worthiness of the
customer, and other criteria that may need to be applied during the life of the transaction.
Also, several status messages may need to be send to and received by the customer that
eventually results in an invoice being sent and payment being received.
BizTalk Server 2010 provides the tools and technologies for automating these business
processes.
BizTalk Orchestration
As a developer, you can implement this type of business process integration by writing your
own application by using C# or Microsoft Visual Basic®. However, creating, maintaining, and
managing complex business processes in conventional programming languages can be
challenging, costly, and time-consuming. BizTalk Server 2010 enables you to create these
business processes graphically. This results in business process automation applications
being developed faster and more cost effectively than building the process directly in a
programming language. It also makes the process easier to understand, explain, and change.
Business Rule Engine

Over time, the rules specified in an orchestration can change. The decisions embedded in a
business process—the business rules—are commonly the most volatile. For example, a
manager’s spending limit might change, or a customer’s maximum order limit might change.
BizTalk Server 2010 includes the Business Rule Engine to enable you to directly create and
modify sets of business rules called policies. These policies are created by using the Business
Rule Composer and then executed directly by the business rule engine.
BizTalk Messaging and Orchestration Services
Explain how BizTalk messaging and orchestration services work to process messages.
Overview
The two main services in BizTalk Server 2010, the messaging engine and the orchestration
engine, form the underlying architecture that enables you to integrate and exchange
messages with the many types of external systems and applications that exist in your
organization and with trading partners.
Messaging Engine
The purpose of BizTalk is to process messages. All communication within BizTalk and
between a BizTalk Server and other systems are based on the exchange of messages. For this
reason, the messaging engine is essential to all BizTalk operations.
The BizTalk messaging engine performs the following tasks:
 Receives inbound messages

 Parses inbound documents to identify their specific formats
 Extracts key identifiers and identifies applicable routing rules
 Delivers documents to their respective destinations including ports or orchestrations
 Tracks documents
Message database
The MessageBox database is a Microsoft SQL Server™ database that is used by BizTalk to
store and route messages to orchestrations and send ports. When a message arrives in the
MessageBox database, the metadata associated with the message is matched and evaluated
to determine the services that subscribe to messages of this type.
Publish-Subscribe Model
BizTalk Server implements a publish-subscribe model for the routing of messages. In the
publish-subscribe model, message providers (publishers) submit messages to a central store
(the MessageBox), where subscribers (send ports and orchestrations) can subscribe to
specific messages. After a message of interest is received by the MessageBox, it is sent to all
subscribers.
For example, when a patient is admitted to a hospital, several processes need to be started,
and various systems need to be updated. These systems might include an ERP application
and other proprietary applications. Each of these systems usually requires a unique message
format. The creation of a new patient admission form generates the initial message that
begins the process. Each of the other systems could subscribe to these messages as separate
tasks in an overall business process.
Using the publish-subscribe model, new systems can be added and old systems updated
without the need to rewrite the integration application.
Animation: BizTalk Message Flow
To show how BizTalk processes messages.
Animation
In this animation, you will see an overview of how the BizTalk messaging and orchestration
runtime components work to process XML and flat-file messages.
BizTalk Job Roles and Tools
Identify common job roles that relate to the design, development, and management of a BizTalk
solution.
BizTalk Job Roles

Because different tasks are performed by different people in an organization, BizTalk
provides a modular toolset that offers the flexibility of a role-based user experience.
Information Workers/Business Analysts

The role of a business analyst is to define the rules and actions that make up a business
process and to define the key performance indicators used to monitor business activity. The
analyst also determines the flow of the business process and determines what information
gets sent to each application.
Business Activity Monitoring (BAM) enables monitoring of events and data produced by
BizTalk applications. Information workers use the BAM Excel Add-in to define the data they
want BAM to collect, and define the way in which the data will be shared. They use BAM
activities to define the data, and they use BAM views to define the data that other users can
see. The Business Activity Monitor (BAM) portal site can be used to monitor business
processes and to view aggregated data.
Information workers may also use the BizTalk Server 2010 Administration Console to
maintain trading partner information.
Developers
Developers use the design provided by the business analyst to create an application that
models the business process. BizTalk developer tools are integrated in Microsoft Visual
Studio® 2010. The developer uses these tools to perform tasks such as defining XML
schemas for the business documents, specifying the relationships between schemas,
creating the orchestrations necessary to implement the business process, and deploying
applications to servers for testing the business processes.
IT Professionals/Administrators
The administrator plays an important role by establishing a secure BizTalk environment,
setting up communications among the parts, deploying the application, and performing
other administrative tasks to manage the BizTalk environment and applications in a
production environment. The administrator role also includes the installation and
configuration of a stable and high-performance SQL server environment.
BizTalk Server 2010 Editions
Identify the differences between BizTalk Server 2010 editions.
Overview
Microsoft BizTalk Server 2010 is available in five editions designed to meet the needs of
organizations of different sizes and needs:
 Enterprise Edition. BizTalk Server 2010 Enterprise Edition is targeted to large
organizations and trading hubs as well as digital marketplaces. Enterprise Edition
offers the complete set of BizTalk Server 2010 features. It supports an unlimited
number of internal applications running on multiple processors, and it supports
clustered deployments. Microsoft also offers a specialized edition of BizTalk Server
2010 named the RFID Enterprise Edition that offers only RFID capability for
integration of remote RFID sensors.
 Standard Edition. BizTalk Server 2010 Standard Edition is designed for small and
medium-sized organizations. It offers the same set of features as BizTalk Server 2010
Enterprise Edition, but the number of internal applications is limited to five. This is a
decrease of 5 internal applications, but there is no longer a limit to the number of
trading partners. Standard Edition will run on 2 CPUs on a single server.
 Branch Edition. BizTalk Server 2010 Branch Edition is a new licensing option. Branch
Edition is designed for intra-enterprise hub and spoke scenarios. You can use Branch
Edition to integrate 1 internal application with a BizTalk Server “hub” that
coordinates/aggregates events across multiple Branch Editions. It is a subset of
BizTalk Server 2010 functionality that includes the technology adapters, RFID, mobile
support and Host Integration Server. Branch Edition does not include the
application adapters, the BizTalk Adapter Pack or any of the BizTalk accelerators.
Branch Edition is limited to 2 CPUs on a single server with a single message box.
 Developer Edition. BizTalk Server 2010 Developer Edition is available as a free
download from the Microsoft web-site. It provides the same set of features as
Enterprise Edition, but it is not licensed for production use. Developers can use this
edition of BizTalk Server 2010 in a development environment for application
development and testing, and for deploying applications to a full production
environment.
Lesson 2: What’s New in BizTalk Server 2010?
Lesson objective:
Identify the new features and improvements for developers and administrators.
Overview
BizTalk Server 2010 builds on the previous version, BizTalk Server 2009, by offering many
improvements, including support for more efficient installations, new developer features
new management features and updated adapters. The administration features include a
new BizTalk Server Settings Dashboard, a new System Center Operations Management Pack
and improved trading partner management.
Installation and Setup
Identify new and improved installation and setup features.
Overview
There are two key improvements in the setup functionality provided by BizTalk Server 2010.
First, BizTalk Server 2010 provides full support for SysPrep which improves administrator
efficiency when scaling out a BizTalk Server Group. The second key improvement is the
clustering support offered by Windows Server 2008 R2, offering improved high-
availability/fail-over support.
Full Support for SysPrep

BizTalk Server 2010 provides full support for SysPrep, making it easier replicate the disk
image of an existing BizTalk Server 2010 installation to new servers, including Hyper-V virtual
machines. Administrators can replicate the images from either a physical hard disk, or a
virtual hard disk, and use SysPrep to change the machine name.
Windows Server 2008 R2 Clustering

BizTalk Server 2010 can take advantage of the improved clustering support offered by
Windows Server 2008 R2. BizTalk Server can now be deployed in multi-site cluster
scenarios, where cluster nodes can reside on separate IP subnets and avoid complicated
virtual LANs (VLANs).
Developer Tool Improvements
Identify new and improved developer tools.
Overview
The BizTalk developer tools have been enhanced in BizTalk Server 2010 from earlier
versions. BizTalk 2010 adds additional improvements to simplify developing BizTalk
solutions.
Mapper Improvements
The BizTalk 2010 Mapper has been improved with a new user interface that eases
development of large transformations and provides new search and predictive matching
functionality. The new BizTalk Mapper also improves productivity by adding cut, copy, paste,
move and undo functions and improved support for documenting maps and readability.
Readability improvements include a new pan feature, and automatic scrolling that brings all
of the relevant links and functoids in to view when a user clicks on schema node.
Developer Tool Improvements
Identify new and improved developer tools.
Integration with AppFabric Workflows

BizTalk Server 2010 introduces a new feature “AppFabric Connect”, which combines features
of BizTalk Server development with .NET application development, enabling developers to:
 Develop custom .NET applications that require connectivity to backend Line of

Business (LOB) systems like SAP, Oracle database, Oracle E-Business Suite, Seibel,
and SQL Server without writing custom code for LOB connectivity.
 Develop XML-based data transformation using the BizTalk Mapper that can be
launched and used right within a .NET project.
AppFabric Connect uses Windows Workflow Foundation (WF) activities to programmatically
access BizTalk’s LOB connectivity and data transformation capabilities. This enables users to
easily create new composite applications using the WF model, which can be deployed,
hosted and managed in Windows Server AppFabric. AppFabric Connect also enables a class
of short running scenarios, such as Web-based queries, that don’t require the
durability/persistence provided by the traditional BizTalk Server message box architecture.
Deployment and Management Improvements
Identify new and improved deployment and management tools.
New BizTalk Server Settings Dashboard

The BizTalk Settings Dashboard in BizTalk Server 2010 is a new feature of the BizTalk
Administration Console that provides convenient access to all of the BizTalk performance
settings. Administrators can use the BizTalk Settings Dashboard to modify settings for the
BizTalk Group, and all the BizTalk Hosts and BizTalk Host Instances in that Group. In previous
versions, administrators had to access the settings in various locations including the
Windows registry, SQL Server databases and configuration files. The BizTalk Settings
Dashboard supports automated settings deployment with scriptable export/import
operations.
New Database Administration Features

SQL Server backup compression is a new feature that is introduced in SQL Server 2008
Enterprise edition. In BizTalk Server 2010, backup compression enables administrators to
create compressed backups of BizTalk Server databases that are business critical and
consume large amounts of disk space. Creating compressed backups is supported only in
SQL Server 2008 Enterprise and later versions.
When administrators run backup compression, custom databases that are a part of BizTalk
backup jobs will also be compressed. Database backups will happen without compression if
backup compression is enabled on databases that belong to non-enterprise editions of SQL
Server.
SQL Server 2008 Transparent data encryption (TDE) performs real-time I/O encryption and
decryption of the data and log files. The encryption uses a database encryption key. TDE
protects data "at rest", meaning the data and log files. It provides the ability to comply with
many laws, regulations, and guidelines established in various industries. This enables
software developers to encrypt data by using AES and 3DES encryption algorithms without
changing existing applications.
TDE does not provide encryption across communication channels. Encryption of the
database file is performed at the page level. The pages in an encrypted database are
encrypted before they are written to disk and decrypted when read into memory. TDE does
not increase the size of the encrypted database.
SQL Server 2008 Transparent data encryption (TDE) performs real-time I/O encryption and
decryption of the data and log files. The encryption uses a database encryption key. TDE
protects data "at rest", meaning the data and log files. It provides the ability to comply with
many laws, regulations,
Deployment and Management Improvements
Identify deployment and management improvements.
New System Center Operations Management Pack

The BizTalk Server 2010 Management Pack for System Center Operations Manager (SCOM)
provides comprehensive discovery and monitoring of BizTalk Server components and
applications.
The BizTalk Server 2010 Management Pack improves the visibility of an environment’s
health status by using color schemes to visually represent the health status of all BizTalk
Server artifacts. A stopped artifact is displayed as red, a started artifact is displayed as
green, and an artifact that has encountered any errors is displayed as yellow. In addition to
indicating highlighting the artifacts with errors, the BizTalk Server 2010 Management Pack
provides improved diagnostic support by including more detailed error information than did
previous versions.
The BizTalk Server 2010 Management Pack offers improved discovery of artifacts across
multiple machines. When SCOM monitors a multiple server environment, monitoring agents
running on the machines discover the same set of artifacts from the configuration database,
resulting in duplicate displays of an artifact in the SCOM console. With BizTalk Server 2010
management pack, the monitoring agents discover the artifacts from a single machine,
avoiding the duplication.
The BizTalk Server 2010 Management Pack also offers improved discovery of relationships
between BizTalk artifacts. It optimizes the discovery of relationships by properly sequencing
the discovery of the artifacts before the discovery of relationships.
Improved Trading Partner Management

Maintaining the information required to manage trading partner relationships can be
difficult when many organizations are involved or when the parties change frequently.
Previous releases of BizTalk provided a functional party management offering that enabled
customers to build solutions that needed party management data, but it did come with a
few challenges around usability and scalability.
BizTalk Server 2010 offers improved trading partner management support to simplify the
integration of business processes with trading partners and manage trading partner
relationships. It offers improved scalability, and it provides a more intuitive user interface
and object model to reflect trading partners, their various businesses, partnerships and
agreements between partners.
The BizTalk Server 2010 trading partner implementation offers better control over user
access by introducing a new Windows role. Business users that are responsible for
maintaining trading partner data can be assigned to the new “BizTalk B2B Operator” role.
The new role allows windows users associated with the role to perform all party
management operations, reducing the burden on the BizTalk administrators to perform all
trading partner management operations.
BizTalk Server 2010 provides a party migration tool that helps upgrade customers to easily
move from previous versions of BizTalk without having to recreate hundreds of parties and
agreements
New and Updated Integration Adapters
Identify new and updated integration adapters.
Overview
BizTalk Server 2010 includes an improved FTP adapter and updated application adapters.
Improved FTP adapter

Previous versions of the BizTalk FTP adapter did not offer support for secure network
connections. The FTP adapter in BizTalk Server 2010 provides support for file transfers from
an FTPS server over Secure Sockets Layer (SSL)/Transport Level Security (TLS). SSL/TLS
ensures data confidentiality through encryption.
In the previous releases of BizTalk Server, the FTP adapter deleted the file after downloading
to avoid downloading the same file during a subsequent polling interval. Due to this design,
the adapter was limited to download files only from FTP locations that provided read-write
access. In BizTalk Server 2010, the FTP adapter supports download of files from read-only
file locations. The adapter now maintains a list of downloaded files in a database. When
downloading a file, the FTP adapter checks the list of files to determine whether or not the
file has been downloaded previously.
The FTP adapter available with the previous releases of BizTalk Server provided atomic file
transfer only for binary mode. In BizTalk Server 2010, the FTP adapter is improved to support
atomic file transfer for ASCII mode as well.
Updated Application Adapters

The BizTalk Server 2010 Adapter Pack provides connectivity to SAP 7, Oracle E-Business Suite
12.1, J.D. Edwards 9.0, SQL Server 2008 R2, Siebel and Oracle Databases. The BizTalk
Adapter Pack can be installed in conjunction with, or separately from, BizTalk Server. It is
included in the Enterprise, Standard and Developer Editions of BizTalk.
The SQL Server Adapter included in the BizTalk Server 2010 Adapter Pack replaces the SQL
Server adapter provided in previous versions of BizTalk.
The specialized BizTalk Adapter Pack Edition is no longer available as a separate product
from BizTalk Server. To purchase the BizTalk Server 2010 Adapter Pack for production use,
you must purchase either the Enterprise or Standard Edition of BizTalk Server 2010.
Upgrading Applications from Previous Versions of BizTalk Server
Describe considerations for upgrading from BizTalk Server 2006 R2 or 2009 to BizTalk Server
2010.
Upgrading to BizTalk Server 2010

BizTalk Server 2010 provides support for upgrades from BizTalk Server 2006 R2 or BizTalk
Server 2010. Customers using older versions of BizTalk Server must first upgrade to either
BizTalk Server 2006 R2 or BizTalk Server 2009 before upgrading to BizTalk Server 2010.
BizTalk Server 2010 includes a Smart Setup feature that automatically scans and installs the
appropriate upgrade when upgrading from BizTalk Server 2006 R2 or BizTalk Server 2009.
Windows and SQL Server must be upgraded before upgrading BizTalk Server. Windows must
be upgraded to Windows Vista SP2, Windows 7, Windows Server 2008 or Windows Server
2008 R2. SQL Server instances that are hosting BizTalk databases must be upgraded to SQL
Server 2008 R2.
Developers must have Visual Studio 2010 installed on their workstations. BizTalk solutions
created in previous versions of Visual Studio will be upgraded automatically when opened in
Visual Studio 2010.
The document “Upgrading to BizTalk Server 2010 from BizTalk Server 2009/2006 R2”
provides detailed instructions for performing an upgrade. It is available on Microsoft’s web
site.
Lesson 3: The BizTalk Server Development Environment
Lesson objective:
Identify system requirements and identify the most common tools used to develop BizTalk
applications.
Overview
The BizTalk Server 2010 development environment includes a number of tools for creating
schemas, designing business processes
System Requirements
Identify hardware and operating system requirements and required prerequisite services.
Operating System Requirements

BizTalk Server 2010 requires Windows Vista with Service Pack 2, Windows 7, Windows
Server 2008 or Windows Server 2008 R2
Although a Windows Vista or Windows 7 installation would be satisfactory for a
development environment, Windows Server 2008 R2 would be the preferred choice for a
production environment.
Hardware Requirements
The minimum hardware requirements for any computer on which you intend to install
BizTalk Server 2010 for application development are as follows:
 A 1-gigahertz (GHz) Intel Pentium–compatible CPU
 2 gigabytes (GB) of random access memory (RAM)
 10 gigabytes (GB) of available hard disk space
Hardware Recommendation (Developer)
For an optimal experience and increased performance when developing BizTalk applications,
it is recommended that you use at least the following hardware:
 A 2-gigahertz (GHz) or higher Pentium–compatible CPU

 3 GB or more of random access memory (RAM)
 60 GB of available hard disk space
If using Hyper-V to host a virtual machine for BizTalk development, make sure that the
physical machine has sufficient resources to allocate the resources described above to the
virtual machine.
Software Requirements
Identify prerequisite and optional services required for a BizTalk development environment.
Visual Studio 2010

Before you install BizTalk Server 2010 Developer Edition, you must first install Visual Studio
2010 with C#. C# is used internally by BizTalk. Any custom components that will be used by
BizTalk, such as helper classes, can be written in any .NET language. It will be necessary to
register these custom components in the Global Assembly Cache (GAC) for BizTalk to access
them.
SQL Server 2008 R2

You must have SQL Server 2008 with Service Pack 1 or SQL Server 2008 R2 installed on the
either on the computer running BizTalk Server, or it must accessible remotely.
Software Required for Optional Features
SQL Server Analysis Services must be installed if you plan on using Business Activity
Monitoring (BAM) or if you want to use the full features of message tracking.
Internet Information Server (IIS) 7.0/7.5 must be installed to use the BAM portal, to use
SharePoint, or to set up HTTP receive locations.
BizTalk Server 2010 is compatible with SharePoint Foundation 2010 or Windows SharePoint
Services 3.0 SP2.
Office Web Components 11 (SP1) must be installed to support the BAM portal.
Project Templates
Identify the Visual Studio project templates used to develop BizTalk applications.
Project Template
The BizTalk Server 2010 installation process adds the BizTalk Projects folder to the New
Project dialog box. The BizTalk Projects folder includes templates for creating the following
types of projects:
 Empty BizTalk Server Project. Use the Empty BizTalk Server Project template when
you want to create a new application that runs on BizTalk Server 2010. This is the
most common BizTalk project type.
 BizTalk Server BPEL Import Project. Use the BizTalk Server Business Process
Execution Language (BPEL) Import Project template to launch the BPEL Import
Wizard. This wizard will guide you through the necessary steps to import BPEL,
WSDL, and XSD files into a BizTalk Project. BPEL will be discussed further in Module
8.
Tools for Developers
Identify the purpose of the most common BizTalk developer tools.
Overview
The BizTalk developer tools are hosted in the Visual Studio 2010 environment and are used
for both messaging and orchestrations.
BizTalk Developer Tools

When the BizTalk Server 2010 developer tools are installed on a computer that has Visual
Studio 2010 installed, several BizTalk project templates are available. When a project is
created using any of these templates, the following BizTalk developer tools become available
as extensions in Visual Studio:
 BizTalk Editor helps you define schemas, which are used to describe the format of
messages that are used within organizations and between trading partners and
which will be processed by BizTalk Server 2010.
 BizTalk Mapper presents source schemas and destination schemas side by side,
making it possible to define transformations between data fields in messages.
 Pipeline Designer is used create custom pipelines that are used to process incoming
and outgoing messages. The pipelines implement such operations as encryption and
decryption, compression, reformatting, and validation.
 Orchestration Designer enables you to create orchestrations that are used to model
business processes. The orchestration designer offers a toolbox of components to
model business processes.
Compiled Artifacts
The BizTalk artifacts (schemas, maps, pipelines, and orchestrations) that you create using the
developer tools just listed are compiled in Visual Studio as one or more assemblies (DLLs)
that can then be deployed to the BizTalk Server for testing or production.
BizTalk Schema Editor
Explain how the BizTalk Editor enables developers to define schemas.
Overview
BizTalk Server 2010 uses XML Schema Definition language (XSD) schemas to define the
structure of all messages it processes. Generally it is possible to work with schemas provided
by third-party editors and schema creation tools. The BizTalk Schema Editor helps you define
schemas, which are used to describe the format of data that is processed within
organizations and between trading partners.
Each unique document type requires a separate schema that defines the records and fields
contained in the document. The XML schema defines:
 The elements, attributes, and data types that appear on the document.
 The ordering of tags in the document.
 Fields that are mandatory or that may occur multiple times in a single document.
BizTalk Mapper
Explain how the BizTalk Mapper enables developers to create maps.
Overview
The BizTalk Mapper tool is used when it is necessary to map the contents of an incoming
message to a message format that can be processed by BizTalk. The BizTalk Mapper presents
the source schema and destination schema side by side, making it possible to define
transformations between the data fields in messages. You create a map when you want to
transform data that you receive or send from one message format to another. Compiling a
map created by the BizTalk Mapper generates an XSLT file for data transformation and
translation.
Example
For example, if you receive a purchase order and want to insert the ShipTo address
information from the purchase order into an invoice, you can create a map that specifies
how the appropriate records and fields from an instance message corresponding to a source
schema should be moved to an instance message corresponding to a destination schema.
BizTalk Pipeline Designer
Explain how the how the Pipeline Designer enables developers to create pipelines.
Pipeline Designer
Pipelines are software components that are used to process messages. Messages can be
processed as they are received or just before they are sent through a send port. The Pipeline
Designer is a graphical tool that you can use to provide additional processing to messages
such as:
 Normalizing data from various formats to XML.
 Denormalizing data from XML to various formats.
 Assembling and disassembling documents.
 Decoding and encoding documents.
 Decrypting end encrypting documents.
 Assigning and verifying digital signatures.
 Custom processing of messages.
BizTalk Orchestration Designer
Explain how the Orchestration Designer enables developers to build orchestrations.
BizTalk Orchestration Designer

BizTalk enables you to build executable business processes by using a design-time tool called
the Orchestration Designer. Rather than expressing the steps in a programming language,
this tool connects a series of shapes in a logical way to define a business process. After you
have completed an orchestration drawing, you compile your BizTalk project into an assembly
that encapsulates an executable orchestration.
BizTalk makes modeling business processes easier than could be performed by building an
integration application in a standard programming language such as C# or Visual Basic. As an
orchestration is being created, the BizTalk toolset writes C# behind the scenes (which is why
C# is required in Visual Studio 2010 regardless of the developer’s preferred language).
BizTalk Administration Console
Describe the tasks that can be performed using the BizTalk Server 2010 Administration Console.
BizTalk Server 2010 Administration Console

The BizTalk Server 2010 Administration Console is a Microsoft Management Console (MMC)
snap-in that can be installed on any computer running Windows Vista with Service Pack 2,
Windows 7, Windows Server 2008 or Windows Server 2008 R2. Similar to the BizTalk
Explorer tool, the Administrative Console enables you to view and manage the configuration
details of your BizTalk system.
Included in these management tasks are:
 Viewing, managing, and configuring the BizTalk Configuration database.

 Viewing installed assemblies.
 Deleting installed assemblies
 Enlisting, starting, stopping, and unenlisting orchestrations (enlisting is the process
of creating a subscription for messages).
 Creating and editing send port groups, send ports, receive ports, and receive
locations.
 Creating and editing trading partner relationships.
 Modifying settings for performance tuning.
The BizTalk Server 2010 Administration Console displays deployed assemblies organized into
BizTalk applications, which makes it easier to manage BizTalk and to export applications to
other servers.
Demo: The Visual Studio Development Environment
Learn how BizTalk Server project tools—including Orchestration Designer, BizTalk Editor, BizTalk
Mapper, and Pipeline Designer—are integrated as a unified development environment within
Visual Studio.
Start the Virtual Machine

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-demos 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, and then click OK.
Open BizTalk Editor
1. In Windows Explorer, navigate to C:\AllFiles\DemoCode\Module1\Demo, and then
double-click Demo.sln.
2. In Solution Explorer, double-click SalesOrder.xsd to open the SalesOrder schema in
the BizTalk Schema Editor.
3. In the left pane, right-click the <Schema> node, and then click Expand Schema
Node.
The entire schema expands.
4. In the left pane, click the CustomerInfo record.
Notice that the XSD for the CustomerInfo record is highlighted.
5. Close the SalesOrder.xsd schema file.
Open BizTalk Mapper

1. In Solution Explorer, double-click SalesOrder_to_Restock.btm to open the map in
the BizTalk Mapper.
The BizTalk Mapper has three sections: the Source Schema, the Mapper Grid,
and the Destination Schema.
2. In the Source Schema, click the OrderTotal element.
This is the same schema that you examined in the previous part of the
demonstration.
3. Click the Functoids tab at the bottom of the Mapper Grid.
It is a good practice to place functoids on a separate page.
4. Click the StoreNumber field beneath the Detail record.
The Mapper will automatically pan to bring the relevant functoids in to view.
5. Point to the Toolbox tab on the left side of the Visual Studio window.
Functoids are dragged from the Toolbox to the Mapper Grid.
6. Close the SalesOrder_to_Restock.btm map file.
Open Pipeline Editor

1. In Solution Explorer, double-click SendEncryptedMessage.btp to open the
SendEncryptedMessage pipeline.
When designing pipelines and orchestrations, the pipeline components and
orchestration shapes are found in the Toolbox. You can drag them from the
Toolbox to the design surface.
3. Close the SendEncryptedMessage.btp pipeline file.
Open Orchestration Designer

1. In Solution Explorer, double-click ProcessOrder_Cash.odx.
The Orchestration Designer has the left and right port surfaces and the design
surface. Orchestration shapes are dragged from the Toolbox to the design
surface. The port surfaces hold orchestration ports that are responsible for
sending and receiving messages to and from the orchestration.
When designing orchestrations, you drag shapes from the Toolbox to the design
surface.
3. Click the Orchestration View tab located below Solution Explorer.
Orchestration View is where you configure orchestration-specific variable, such
as messages used, correlation, and role links.
4. Close all open windows, and shut down the virtual machine.
Lab: Examining a BizTalk Application
Scenario
Adventure Works is a retail sporting goods chain with 10 stores in the Pacific Northwest. The
company headquarters receives daily batches of orders from each retail store. These
batches are processed by a Microsoft BizTalk Server 2010 application.
In this lab, you will examine and test the BizTalk Server application that you will be building
throughout the remainder of this course. This application receives and processes sales
orders. If the application receives an order for a non-cash transaction, the loan application is
automatically approved or denied, based on predetermined business rules. If the credit
application is denied, the loan application is sent to a Microsoft Windows SharePoint
Services site for manual review. If the loan application is denied during the manual review
process, the order is canceled, and the store is notified. If the loan application is approved,
the total loan amount is evaluated to determine who the lender will be. Loans for less than
$1000 are carried by the Adventure Works finance department. Larger loans are managed
by one of two banks, based the customer’s credit rating. For all completed cash or credit
transactions, the inventory system is updated, and a sales order acknowledgement is
generated.
Procedure List
3. Double-click the virtual machine bt10d-01 to open a Virtual Machine Connection
window.
Start.
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: Examining the BizTalk Solution
Overview
BizTalk projects can contain four types of artifacts: schemas, maps, pipelines, and
orchestrations. In this exercise, you will examine the schemas, maps, and orchestrations that
make up the sales order processing application used by Adventure Works.
Start the Adventure Works BizTalk Application
Procedure List
1. On the Start menu, click All Programs, then click Microsoft BizTalk Server 2010, and
then click BizTalk Server Administration.
2. In BizTalk Administration Console, expand BizTalk Server Administration, BizTalk
Group, Applications
3. Right-click on Adventure Works and choose Start, then click on Start in the prompt that
appears.
Open the AdvWorks Solution

Procedure List
1. In Windows Explorer, navigate to C:\AllFiles\LabFiles\Lab1\AdvWorks and open
AdvWorks.sln.
The AdvWorks solution opens in Visual Studio.
Examine the SalesOrder Schema

Procedure List
1. In Solution Explorer, expand the Messaging project, and then double-click
SalesOrder.xsd to open the schema in the BizTalk Editor.
The SalesOrder schema represents the format of sales order messages that BizTalk
processes. These messages are received from various retail stores owned by
Adventure Works.
2. In the left pane, right-click SalesOrder, and then click Expand Schema Node.
3. Click the Detail record.
The Detail record contains information about the sales order, which includes the
store information and the name of the employee who took the order.
4. Click each field under the Detail record to examine the field’s properties.
Notice that the corresponding information in the XSD details pane is highlighted as
you select each field.
5. Click the CustomerInfo record.
The CustomerInfo record contains information about the customer, including
address and employment information.
6. Click the Items record.
The Items record is a repeating record of individual items in the sales order. The
Items record will repeat as many times as necessary to include all unique items in the
order. Also notice that the schema contains a Comment field, an OrderTotal field,
and a TermOfLoan field.
Examine the Restock Schema

Procedure List
1. In Solution Explorer, double-click Restock.xsd.
The Restock schema represents the format of restock messages. The restock
message is sent to the inventory system to automatically restock purchased goods.
2. In the left pane, right-click Restock, and then click Expand Schema Node.
3. Click the OrderID field.
4. Click the Products record.
The Products record is a repeating record and contains the Quantity and ID number
of the product that needs to be restocked.
Examine the SalesOrder_To_Restock Map

Procedure List
1. In Solution Explorer, double-click SalesOrder_To_Restock.btm.
This map is used to transform the data from the SalesOrder message to the Restock
message.
2. In the left pane, click the StoreNumber field beneath the Detail record.
3. Click the red square on the mapping surface.
This is a Concatenate Functoid. It is used to combine the data from the StoreNumber
and OrderNumber fields in the SalesOrder message to create a single OrderID field in
the Restock message.
4. Click the Item field beneath the Items record.
5. Click the purple square on the map surface.
This is a Looping Functoid. It is used to ensure that the Product record on the Restock
message will occur each time the Item field occurs in the SalesOrder message.
Examine the ProcessOrder_Cash Orchestration

Procedure List
1. In Solution Explorer, expand the Processes project, and then double-click
ProcessOrder_Cash.odx.
This is a basic orchestration. A sales order for a cash transaction is received, and two
new messages are constructed and sent. The Restock message is constructed by
using a map, whereas the completed sales order message is created by using an
expression shape.
Examine the ProcessOrder_Credit Orchestration

Procedure List
1. In Solution Explorer, double-click ProcessOrder_Credit.odx.
2. Right-click the orchestration design surface, point to Zoom, and then click 50%.
This orchestration is a little more complex. A sales order for a credit transaction is
received, and another orchestration is called. When calling an orchestration, the
message is passed to the called orchestration. The calling orchestration then waits
for the completed message to be sent back to it before continuing to process the
message.
3. In Solution Explorer, expand the LoanApproval project, and then double-click
ApproveLoan.odx.
This is the orchestration called by the ProcessOrder_Credit orchestration. The
message is transformed into a loan application by using a map, and then the loan
application is sent to the Business Rules Engine to be approved or denied based on a
collection of rules. If the loan application is approved, it travels down the left side of
the decide shape to be transformed again before being sent back to the
ProcessOrder_Credit orchestration. If the loan is not approved, it is transformed and
sent to a SharePoint site for manual approval or denial, and then passed back to the
ProcessOrder_Credit orchestration.
4. Switch back to the ProcessOrder_Credit orchestration.
If the loan application comes back from the Loan Approval orchestration as denied,
the message will travel down the right branch of the Loan Approved decide shape,
and then a message will be sent informing the store that the loan has been denied.
If the loan is approved, the message will travel down the left branch of the Loan
Approval decide shape. Restock and completed sales order messages will be created
similar to the ones created by cash transactions, and the message will be evaluated
again to determine whether the loan will be handled by the Adventure Works
financial department or sent to a bank for financing. If the loan is $1000 or less, it
will travel down the right branch and the LOANS table in the AdvWorks database will
be updated. If the loan is for more than $1000, another evaluation will take place to
determine which bank the loan will be sent to. If the loan-to-income ratio is less than
1.5, the message will be sent to the Woodgrove party. Everything else is sent to the
Northwind party. The orchestration waits for a response from the bank,
acknowledging that the loan application has been accepted.
Exercise 2: Test the BizTalk Application
Overview
BizTalk applications receive, process, and send messages. In this exercise, you will test the sales
order processing application by submitting test messages. You will see how cash and non-cash
(credit) messages are processed, how inventory is updated, how sales order acknowledgments
are generated, and how the loan approval process works.
Submit the CashSalesOrder1.xml Message

Procedure List
1. In Windows Explorer, navigate to and open
C:\AllFiles\LabFiles\Lab1\CashSalesOrder1.xml.
2. Examine the message.
Notice that this order is for 15.99 and has an OrderType of CASH, so it will be
processed through the ProcessOrder_Cash orchestration.
3. Close Microsoft Internet Explorer.
4. In Windows Explorer, copy CashSalesOrder1.xml to the SalesOrderIN folder.
Ensure that you copy the message rather than move it. After the message is
processed, it cannot be recovered.
5. Open the SalesOrderIN folder.
Notice that after a moment, the message you copied to this folder has been
processed and removed.
6. Navigate to the C:\AllFiles\LabFiles\Lab1\OUT folder.
Notice that a Complete{GUID}.xml message and a Restock{GUID}.xml message have
been created and sent to this folder.
7. Double-click Complete{GUID} to view the message in Microsoft Internet Explorer.
Notice that the comment field has been updated to state that the processing of this
order has been completed.
9. Double-click Restock{GUID} to view the message in Microsoft Internet Explorer.
Notice that the message is in the Restock schema format and contains the product
ID and quantity for the order.
11. Delete all of the messages in the OUT folder.
Test the Internal Financing Process

Procedure List
1. In Windows Explorer, navigate to C:\AllFiles\LabFiles\Lab1.
2. Open CredSalesOrder-Internal1.xml.
3. Notice that the CustomerName is Tude Palma, and then close Internet Explorer.
5. Notice that the CustomerName is Roland Hofmann, and then close Internet Explorer.
7. Notice that the CustomerName is Bryan Walton, and then close Internet Explorer.
8. Copy CredSalesOrder-Internal1.xml, CredSalesOrder-Internal2.xml, and
CredSalesOrder-Internal3.xml to the SalesOrderIN folder.
These three sales orders will be financed by the Adventure Works financial
department. When processed, each loan will update the LOANS table in the
AdvWorks database and generate a restock message and a completed order
message.
9. Navigate to the OUT folder and wait until the three Complete{GUID}.xml messages and
the three Restock{GUID}.xml messages appear.
10. On the Start menu, point to All Programs, point to Microsoft SQL Server 2008, and then
click SQL Server Management Studio.
11. In the Connect to Server dialog box, click Connect.
12. In Object Explorer, expand Databases, AdvWorks, Tables, right-click dbo.LOANS, and
select Select Top 1000 Rows.
13. In the query results window, notice the three entries: one entry each for Bryan Walton,
Roland Hofmann, and Tude Palma.
14. Close Microsoft SQL Server Management Studio.
15. In Windows Explorer, delete all the messages in the OUT folder.
Test the External Financing Process

Procedure List
2. Open CredSalesOrder-Northwind.xml, and then notice that the CustomerName is Josh
Pollock.
This order fulfills all requirements to be approved by the business rules engin, and
will be sent to Northwind for financing.
4. Open CredSalesOrder-Woodgrove.xml, and then notice that the CustomerName is
Armando Pinto.
This order fulfills all requirements to be approved by the business rules engine and
will be sent to Woodgrove for financing.
6. Copy CredSalesOrder-Northwind.xml and CredSalesOrder-Woodgrove.xml to the
SalesOrderIN folder.
7. Navigate to C:\AllFiles\LabFiles\Lab1\Woodgrove, open the
WoodgroveNotice{GUID}.xml file that appears, notice that the CustomerName is
Armando Pinto, and then close Microsoft Internet Explorer.
8. Move the WoodgroveNotice{GUID}.xml file from the Woodgrove folder to the BankAck
folder.
The step represents receiving an acknowledgment from the lender verifying that the
loan will be financed. The message is processed and completes the orchestration
instance.
9. Navigate to C:\AllFiles\LabFiles\Lab1\Northwind, open the
NorthwindNotice{GUID}.xml file that appears, notice that the CustomerName is Josh
Pollock, and then close Microsoft Internet Explorer.
10. Move the NorthwindNotice{GUID}.xml file from the Northwind folder to the BankAck
folder.
The step represents receiving an acknowledgment from the lender verifying that the
loan will be financed. The message is processed and completes the orchestration
instance.
11. Delete all the messages in the OUT folder.
12. Open C:\AllFiles\LabFiles\Lab1\CredSalesOrder-Denied-Northwind.xml, and then
notice that the Customer Name is Alex Hankin.
This order does not fulfill the requirements to be approved by the business rules
engine, but it can still be approved manually. If approved manually, it will be sent to
Northwind for financing.
14. Open C:\AllFiles\LabFiles\Lab1\CredSalesOrder-Denied-Woodgrove.xml, and then
notice that the Customer Name is David Barber.
engine, but it can still be approved manually. If approved manually, it will be sent to
Woodgrove for financing.
16. Copy CredSalesOrder-Denied-Northwind.xml and CredSalesOrder-Denied-
Woodgrove.xml to the SalesOrderIN folder.
17. In Internet Explorer, navigate to http://localhost/LoanApplications.
18. Click the first message, and then in the File Download dialog box, click Open. If the
Microsoft Office Activation Wizard window appears, click on its Cancel button.
Take note of the Applicant Name; it is either Alex Hankin or David Barber.
19. In the Status list, choose Approved, and then close the form, saving your changes.
20. In the SharePoint navigation menu in Internet Explorer, click on All Documents and
choose Evaluated from the drop-down list.
The Evaluated view shows applications that have been approved or denied. Notice
that the message you modified has been picked up for processing. This may take up
to one minute to occur, so you may have to refresh your browser.
21. Click on Evaluated in the SharePoint navigation menu and choose All Documents from
the drop-down list. Click the remaining message, and then in the File Download dialog
box, click Open. If the Microsoft Office Activation Wizard window appears, click on its
Cancel button.
22. In the Status list, choose Denied, and then close the form, saving your changes.
23. Refresh the page, and notice that the message has been picked up for processing.
This may take up to one minute to occur.
24. In Windows Explorer, navigate to C:\AllFiles\LabFiles\Lab1\OUT, and then open the
Denied{GUID}.xml message.
This is the denial message for the loan application you manually denied. The
complete and restock messages for the loan you approved are also here.
25. If you approved the loan for David Barber, navigate to
C:\AllFiles\LabFiles\Lab1\Woodgrove; if you approved the loan for Alex Hankin,
navigate to C:\AllFiles\LabFiles\Lab1\Northwind.
26. Open the newest message in the folder, and notice that this is the loan that you
manually approved.
27. Close all open windows.
Module 2: Creating Schemas
Module objective:
Create and test XML and flat file schemas.
Introduction
Microsoft® BizTalk® Server 2010 can receive messages formatted as XML, flat files, or as
Electronic Document Interchange (EDI). Regardless of the format of the incoming message,
the BizTalk orchestration and messaging engine always processes messages in XML format.
This requires that a schema be defined in order to convert the message to XML format that
can be processed by BizTalk. In the case of flat file or EDI messages, XSD (XML Schema
Definition) annotations are used within the schemas to provide the additional information
required by the relevant parsers. This module provides the knowledge and skills necessary
for developers to create XML and flat file schemas.
Lesson 1: Introduction to BizTalk Schemas
Lesson objective:
Describe how BizTalk uses XML and identify the types of XML message types supported by
BizTalk.
Introduction
Creating schema definitions for the messages to be processed by BizTalk is usually the first
step in developing an integration solution. This lesson provides a review of XML terminology
that you may already be familiar with and identifies how BizTalk implements XML standards.
In this lesson, you will learn how BizTalk uses namespaces as well as the various schema
types that can be created for use by BizTalk.
Reviewing XML Terminology
Describe XML terminology as it pertains to BizTalk.
Overview
BizTalk Server was one of the first applications specifically designed to work with data in
XML format. All documents (messages) that will be internally processed by BizTalk must first
be converted to XML. All XML artifacts that are created by BizTalk are fully World Wide Web
Consortium (W3C) compliant. This means that schemas created using other tools can
generally be used by BizTalk and vice versa.
XML Terminology
The following are some of the terms and XML features supported by BizTalk Server 2010:
 Namespace. An XML namespace is a W3C standard for providing uniquely named
elements and attributes in an XML instance. An XML instance may contain element
or attribute names from more than one XML vocabulary. If each vocabulary is given
a namespace, the ambiguity between identically named elements or attributes can
be resolved.
 Element. An XML element is a construct used to organize information in a
hierarchical manner. XML elements can either be simple data types (such as strings,
decimals, and unsigned bytes) as defined in W3C standards, or they may be a
complex type containing other elements and/or attributes. Elements and attributes
are case sensitive; that is, Customer is not the same element name as customer or
CUSTOMER.
 Attribute. An XML attribute is a construct used to associate additional information
contained with an XML element. Unlike elements, attributes cannot be nested.
Attributes can be associated with any of the simple data types, but because they
cannot be nested, they cannot be a complex type.
 In the following example, Customer is an element with a value of Contoso. ID is an
attribute of the Customer element and has a value of 12345.
<Customer ID=”12345”>Contoso</Customer>
 XML Schema Definition Language (XSDL). The XML schema definition language is
used to create schemas that represent the message formats that BizTalk will
process. Schemas define nodes such as required and optional fields, recurring fields,
and order. An instance message can be validated against an XSD to verify that the
format is valid.
 XML Path Language (XPath). A language used for navigating through the hierarchy
of an XML document. For example, XPath can be used to select data in an XML
document that matches a certain criterion or to perform comparisons on retrieved
data.
 Extensible Style Sheet Language Transformation (XSLT). A language definition for
XML data presentation and data transformations. Data presentation refers to how
data is formatted for display purposes in a specific format or style. Data
transformation refers to how data is transformed and exchanged. For example, a
purchase order could be converted from the format submitted by a trading partner
to the format required for your internal processes.
 Document Object Model (DOM). The DOM provides a mechanism for navigating
through a message. When working with XML documents, the DOM is often used to
manipulate and query XML data. In BizTalk, when references are made to the XML
DOM, it is usually presumed that the message is being loaded into memory, which
results in slower processing than would be experienced if the data were simply
being streamed.
 Web Services Description Language (WSDL). An XML format that describes the
capabilities and characteristics of a Web service. BizTalk can both publish and
consume Web services. That will be discussed in module 12.
 Simple Object Access Protocol (SimpleSOAP). Defines a simple way of sending XML
messages across the Internet. SOAP is used in BizTalk Server in conjunction with
Web services.
What Are XML Namespaces?
Explain what an XML namespace is.
Overview
An XML namespace is a W3C standard for providing uniquely named elements and attributes
in XML instances. XML namespaces help the BizTalk parser recognize the proper schema or
schemas as well as the tags that describe the structure of the data inside the schema.
XML Namespaces
XML messages (instances) may contain elements or attributes from more than one XML
vocabulary. If each vocabulary is given a namespace, the ambiguity between identically
named elements or attributes can be resolved. Element names within a namespace must be
unique.
A simple example of ambiguous elements would be to consider an XML instance that
contains references to a customer and an ordered product. Both the customer and product
elements could have a child element ID_number. References to the element ID_number
would therefore be ambiguous. By providing namespace references, the two identically
named but semantically different elements can be differentiated.
A namespace is declared by using the reserved XML attribute xmlns, the value of which must
be a Uniform Resource Identifier (URI). The declaration generally also includes a short prefix
with which elements and attributes can be identified, such as
xmlns:prod="http://adventure-works.com/customerOrderl". A maximum of one namespace
per schema (the default namespace) has no prefix. Any elements that are not associated
with a prefix will be presumed to belong to this namespace.
In the following example, the default namespace is http://adventure-
works.com/salesReport, whereas the products namespace (http://adventure-
works.com/products) has a prefix of prod. Without the namespace reference, the id element
as used in the customer and for the product would be ambiguous.
<salesReport xmlns="http://adventure-works.com/salesReport"
xmlns:prod="http://adventure-works.com/products">
<customer>
<id>Fabrikam</id>
<sales>
<prod:id>widget1004</prod:id>
<prod:unitsSold>100</prod:unitsSold>
<prod:price>35</prod:price>
</sales>
</customer>
</salesReport>
How Does BizTalk Use XML Namespaces?
Explain how BizTalk uses XML namespaces.
Overview
As previously stated, BizTalk Server relies on the use of structured documents for all internal
messaging and orchestration operations. BizTalk uses W3C standard format XSD but extends
these by referencing additional namespaces. This results in schemas that can still be used by
other systems that understand XML and contain the additional parameters required by
BizTalk.
It should be noted that BizTalk can process strictly binary data—for example, .bmp files and
.pdf files through its routing functionality—from one location to another, and, in this case,
an XML schema is not required. This special handling requires the use of a pass-through
pipeline, which will be addressed in Module 5.
BizTalk Namespaces
BizTalk adds the following namespaces to schemas as necessary to facilitate custom
functionality:
 Target Namespace. When creating new schemas by using the BizTalk Editor, a target
namespace is added by default. This namespace is used in conjunction with the root
node name to uniquely identify the schema that relates to an inbound message.
Other operations within BizTalk also rely upon the target namespace.
 Schema Extensions Namespace. When working with flat file and EDI schemas,
BizTalk will add a reference to the namespace shown below. This reference provides
the extensions necessary to define delimiters and positional settings while still
allowing the creation of XSD-compliant schemas that can be used by applications
other than BizTalk.
xmlns:b="http://schemas.microsoft.com/BizTalk/2003
How Does BizTalk Server Determine Which Schema Relates to an Incoming

Message?
When an XML message is received by BizTalk, the default namespace and root node name
are extracted from the message. These values are concatenated
(targetNamespace#rootNodeName) and are referred to as the Message Type. It is
important that the Message Type be unique so that BizTalk can non-ambiguously determine
the correct schema to be applied to the instance.
For non-XML message instances, a property defined in the pipeline will specify the schema
to be applied. Schemas used for flat file processing will have a root node name and a target
namespace and will therefore have a message type. These values should provide for
uniqueness but are not as critical. More information about these properties will be provided
later in this module.
What Is a BizTalk XML Schema?
Describe how BizTalk uses XML and what is defined in BizTalk XML schema.
Overview
XML schemas define the data structure for all XML business documents that you exchange
within and across organizations by using BizTalk. BizTalk also requires schemas in order to
have an XML representation of the flat file messages that it will be processing.
BizTalk Schemas
BizTalk can use schemas provided by trading partners or created by using other third-party
schema creation tools and applications. BizTalk includes tools for creating (or modifying)
schemas, including schemas to be used for flat file processing. Generally speaking, it is a
good idea to get in the habit of creating your schemas by using the BizTalk Editor, which will
be discussed in the next lesson.
A typical XML or flat file document might be a purchase order, an invoice, or any other type
of document representing a business transaction. Each unique document type requires a
separate schema that defines the records and fields contained in that document.
The XML schema defines:
 Elements and attributes, which are the building blocks of a schema.
 Data types that appear in document instances, including simple and complex data
types.
 Simple data types, which are data types that contain data and cannot be nested.
Examples of simple data types include xs:string, xs:int, and xs:long. Elements or
attributes can be simple data types.
 Complex data types. Complex data types can contain both data and nested data. For
example, in the slide for this section, the Item element is a complex type because it
contains other elements. Only elements can be complex data types; an attribute
must be associated with one, and only one, element.
 Namespace declarations and version information.
 The ordering of tags in the document.
 Fields that are mandatory or that may occur multiple times in a single document.
XSD Resources on the Web

For more detailed information, go directly to the XSD specifications and primer maintained
on the W3C Web site.
Supported BizTalk Schema Types
Identify the types of schemas that BizTalk supports.
Schema Types
BizTalk Server 2010 can natively process messages in XML flat file and EDI message formats.
BizTalk is extensible, and custom message types can be created in addition to those
supported out of the box.
XML Schema
An XML schema defines the structure of XML messages. XML messages are arranged in a
hierarchical format that is defined by the schema. Messages are identified and validated
against their associated schema.
Flat File Schema

A flat file schema defines the structure of messages that use a flat file format. Flat files can
be either delimited or positional. Because XSD does not natively support the flat file
structure, BizTalk uses the annotation capabilities of XSD to store this extra information
within the XSD schema. BizTalk defines a rich set of specific annotation tags that can be used
to store all of the required additional information.
EDI Schema
BizTalk supports the creation and use of schemas that represent various EDI document
formats such as EDIFACT and X12. An EDI message is a variation of a text message and does
not use typical delimiters such as carriage returns and linefeeds. As with flat file schemas,
BizTalk uses the annotation capabilities of XSD to store the extra information related to the
format of the EDI messages.
EDI messages are beyond the scope of this course. Refer to the BizTalk help files for
additional information on EDI schemas and their uses.
Flat File Structures
Identify the types and characteristics of flat file messages that can be processed by BizTalk.
Flat Files
BizTalk Server is designed to make it easy to create schemas for positional flat files,
delimited flat files, and files that combine positional and delimited records. At the root level,
most flat files are delimited with a carriage return (for example UNIX files), a linefeed, or,
more frequently, both. For this reason, even files that contain mostly positional data will be
defined as delimited at the root.
Delimited Files
A delimited file contains one or more fields separated by a delimiter character. This
character is frequently a comma (,) or pipe symbol (|) but could be any character. BizTalk
Editor does not read delimiters as part of the data. However, if the delimiter character might
appear within the instance as valid data, the data can be formatted so that what would
otherwise be a delimiter character is treated as valid data.
In the following example, the record contains four fields that are delimited with commas.
The fields are first name, last name, address, and a comment. The comment contains a
comma that would normally be interpreted as a delimiter. With the comment enclosed in
quotes (“”) the embedded comma is treated as part of the data.
John, Smith, 123 Main St, “BizTalk, Learning BizTalk Server 2010” ¶«
Positional Flat Files

A positional flat file is made up of records that have a common end-of-record terminator
(delimiter), for example, a carriage return, and fields that have a fixed length. The structure
of an incoming file must be represented in the records and fields of the schema so that the
positional nature of the incoming file is preserved. Therefore, before defining the structure
of a flat file message, you must obtain a layout of the necessary records and fields, and you
must obtain a sample message for testing purposes.
In the following example, the record contains four fields that are positional delimited. The
first name is contained within the first 10 characters, the last name is the next 10 characters,
the address is the following 20 characters, and 35 characters are left for the comment. There
is no need to enclose the comment in quotes because the position within the instance is
used to identify the separation between the fields. The record is terminated with a
combination of a carriage return and linefeed. Spaces in the example were replaced by dots
to make them more distinguishable.
John……Smith…..123.Main.St………Learning BizTalk Server 2010…….¶«
Lesson 2: Creating XML and Flat File Schemas
Lesson objective:
Create an XML schema by using the BizTalk Editor and create a flat file schema by using the Flat
File Schema Wizard.
Overview
In this lesson, students will learn how to use the BizTalk Editor and the Flat File Schema
Wizard to create BizTalk schemas. Students will also learn how to import existing schemas
and how to validate a schema and generate a schema instance.
Methods for Creating BizTalk XML Schemas
Identify the methods and tools available for creating XML and flat file schemas.
Schema Creation Methods

There are several ways in which you can create XML schemas in BizTalk Server 2010, and all
will produce valid XSD schemas.
 Generating a schema from an instance message. You can generate an XML schema
that corresponds to a particular instance message as long as that instance message
consists of well-formed XML.
 Migrating an older XML-Data Reduced (XDR) schema to an XSD schema. You can
generate an XML schema for BizTalk Server 2010 from a schema that was developed
by using a previous version of BizTalk Server, which stored schemas in XDR format.
There is also an option to import from Document Type Definitions (DTDs).
 Creating a schema from scratch. You may use this method to create schemas for
messages for which no instances exist (possibly for internal use), or when the other
tools do not provide the necessary functionality. This would be a way of creating
schemas for XML, flat file, or EDI message types.
 Creating a schema from scratch in conjunction with other schemas. When creating
complex schemas in the real world, you are more likely to build them by modifying
existing schemas by using the XSD language processes of importing, including, and
redefining schemas created previously.
 Modify existing schemas. Regardless of the original source of any schema, the
BizTalk Schema Editor can be used to modify any valid XSD schemas.
 Flat File Schema Wizard. The Flat File Schema Wizard is new to BizTalk Server 2010
and makes the creation of flat file schemas easier than ever before.
Generating Schemas
Generate a schema from an instance, an XDR schema, and a DTD file.
Overview
You can use the Generate Schemas dialog box to generate an XSD schema from one of the
following sources:
 A well-formed XML instance message
 A valid XDR schema
 A valid DTD
In each of these cases, you would begin by adding a new generated item to the project (right
click the project, click Add, and then click New Generated Item) and then browsing to locate
the appropriate source file. A new schema with the same name as the source file is created
in the current solution. This schema can be renamed and, if necessary, edited using the
BizTalk Editor.
Generate a Schema from an XML Instance

You may frequently be provided with an instance of an XML message for which no schema is
available. Because BizTalk always requires a schema for messages to be processed, it will be
necessary to generate a schema.
Generate Schemas from XDR Schemas and DTD Files

XDR was an early Microsoft standard for creating schemas. BizTalk Server 2000 and BizTalk
Server 2002 used XDR to create schemas. XSD replaced XDR as the BizTalk schema type
starting with BizTalk Server 2004.
DTD was the first method used for validating documents, but it was not XML based and has
since been replaced by XSD. Although DTD was never a standard supported by BizTalk, you
may need to generate schemas that can validate messages generated using DTD. This will
produce a valid XSD to be used to validate instances that were created based on a DTD.
Installing the Schema Generators for XML and DTD

In the case of generating a schema from an XML instance or from a DTD file, it is necessary
to install the schema generator before the first use. This is done by executing the
appropriate script located at C:\Program Files (x86)\Microsoft BizTalk Server
2010\SDK\Utilities\Schema Generator. The script to install the schema generator for well-
formed XML messages is named InstallWFX.vbs. The script for generating a schema from a
DTD is named InstallDTD.vbs. After one of these scripts has been executed, the appropriate
generator is added in Microsoft Visual Studio 2010.
Creating a Schema by Using the BizTalk Editor
Create a schema by using the BizTalk Editor.
BizTalk Editor
The BizTalk Editor automatically starts when you add a new schema to a BizTalk project or
open an existing schema in the project. You can use the BizTalk Editor to construct and
modify schemas without the need to learn all of the intricacies of XSD syntax. The schema
tree view is where you actively construct your schema. The XSD view is a read-only view that
represents the XSD syntax for the schema you are creating. When creating or viewing flat file
schemas, this view has an additional page named Flat File that shows the delimiters and
positional spacing in use.
BizTalk creates (and uses) fully W3C-compliant schemas. More information about elements,
attributes, data types, and schema design is available through many online resources,
including MSDN®.
Node Types
The following menu choices are available when inserting nodes into a schema tree:
 Field Element. Represents items of information that are simple in nature, such as
strings and numbers. You must use a record if the field has children or is repeated.
 Field Attribute. Represents items of information that are simple in nature, such as
strings and numbers.
 Child Record. A record is a container object (it cannot directly contain data) that
represents a collection of information. Records have the record icon associated with
them but are implemented as complex data type elements in the schema. A record
node can include element or attribute nodes based on simple data types such as
strings and numbers or can provide nesting of other complex data types (sequence
group or choice group).
 Sequence Group. Contains other nodes that must appear in an instance message in
the same order in which they appear within the Sequence Group node.
Auto-Refresh
When working with large schemas, auto-refresh might cause undesirable delays. In such
cases, you can disable automatic (continuous) refresh by clicking the link at the bottom of
the window. You can then click the refresh link as needed to refresh the XSD view.
Using Multiple Schemas
Create and combine schemas by using an existing schema structure.
Overview
When your schemas become large and complex, or when schemas that represent different
types of instance messages have some sections in common, it can be useful to include
smaller schemas as building blocks in the larger ones. For example, you might have several
message types, each of which must contain a shipping address. You can define the structure
of a shipping address in a single smaller schema and then include that schema within the
other, larger schemas that define Order, Invoice, and Shipping Notice messages. If this
format changes, there is a single place to update rather than having to update it at each
occurrence.
Methods for Combining

XSD provides the import, include, and redefine mechanisms for using multiple schemas
together. To be able to use schemas in this way, a target namespace must be specified for
the schema that will be imported. All three of these mechanisms are supported by BizTalk
Editor and are described here:
 Import. Importing a schema provides a mechanism for using types defined in other
namespaces. An imported schema must have a Target Namespace that is different
from the importing schema, and no type modification is allowed to the imported
schema. This means that the imported schema cannot be modified in any way once
it has been imported. Use the import option to import a schema.
 Include. Including a schema provides a mechanism for using types defined in the
same namespace as the including schema. The namespace of the included schema
can be empty, and, as in importing a schema, no type modification is allowed. Use
the include option to include a schema.
 Redefine. Redefining a schema is similar to including a schema in that it provides a
mechanism for using types defined in the same namespace as the including schema
or for a namespace that is empty. However, you can use types defined in the
redefined schema as is, derive new types from them, or specify modifications to
them. Use the redefine option to redefine a schema.
Testing a Schema
Test and validate a schema and generate a sample instance message.
Overview
After you have constructed or added a schema into your BizTalk project, you can perform
several operations to make sure the newly created schema can correctly validate data.
Regardless of the format of the messages they represent, all schemas can be tested using
these methods. You can also generate sample instance documents, which are helpful for
comparing against provided instances.
Testing a Schema
There are three tests that can be performed on any schema to validate that it is a well-
formed XSD and that it can be used to validate message instances. All of these tests can be
configured in the Microsoft .NET properties of the schema (accessed by right-clicking the
schema in Solution Explorer and then clicking Properties). To perform any of these tests,
right-click the schema in Solution Explorer, and then click the appropriate menu command.
The tests are as follows:
 Validate Instance. This test is extremely useful when you have an XML or flat file
document with data that you would like to make sure is valid against a schema. In
many cases, you may find that one instance may validate while another will not, for
example, if the schema was generated with a message that had a single product
instance but you need to validate messages that also have multiple products.
 Validate Schema. Schemas generated within BizTalk will always be valid XSD
because BizTalk enforces such rules as the schema is created; however, schemas
provided by others may not adhere to W3C standards as strictly. This step ensures
that the XSD has valid syntax. This step is most often necessary when adding an
existing schema into a project that was not built by the BizTalk Schema Editor.
 Generate Instance. You can use this option to generate a sample instance message.
The sample instance message that is generated contains the element and attribute
structure specified by the schema and generates data type–specific sample data.
You can populate this generated instance with realistic data to use in the validate
instance process specified earlier or provide it to partners as a sample of the
messages your processes may output.
You might find it useful to add a folder named Messages inside the BizTalk project into which
the generated instances and test messages can be saved. In this way, the test messages are
always accessible for future testing and schema modification.
Demonstration: Creating and Testing a Schema
In this demonstration, you will see how to create a new BizTalk schema by using BizTalk Editor.
You will then see how to generate an instance of the schema and test the schema against a
sample message.
Create a Schema
1. If it is not already started, start the bt10d-demos virtual machine.
2. In Microsoft Windows Explorer, navigate to C:\AllFiles\Democode\Module2\Demo,
and then double-click Demo.sln.
3. In Solution Explorer, right-click the Messaging project, point to Add, and then click
New Item.
4. In the Add New Item dialog box, in the center pane, click Schema.
5. Change the Name to PurchaseOrder.xsd, and then click Add.
6. In the left pane of BizTalk Editor, right-click the Root node, and then click Rename.
7. Rename the node to PO.
The Root node should always be renamed.
8. Right-click PO, point to Insert Schema Node, and then click Child Record.
9. Name the record Customer.
11. Name the record Address.
13. Name the record Items.
14. Right-click Customer, point to Insert Schema Node, and then click Child Field
Attribute.
15. Name the attribute FirstName.
Attribute.
17. Name the attribute LastName.
Attribute.
19. Name the attribute EmailAddress.
Attribute.
21. Name the attribute PhoneNumber.
22. Right-click Address, point to Insert Schema Node, and then click Child Field
Element.
23. Name the element Street.
Element.
25. Name the element City.
Element.
27. Name the element State.
Element.
29. Name the element Zip.
30. Right-click Items, point to Insert Schema Node, and then click Child Record.
31. Name the record Item.
32. Right-click Item, point to Insert Schema Node, and then click Child Field Attribute.
33. Name the attribute SKU.
34. Right-click Item, point to Insert Schema Node, and then click Child Field Attribute.
35. Name the attribute Description.
36. Click the Item record.
37. In the Properties window, scroll to the bottom of the list, set the Max Occurs
property to *, and then set the Min Occurs property to 1.
Setting the Min Occurs and Max Occurs properties as shown will make this a
required node within the message (it must occur at least once but can repeat
infinitely).
Generate an Instance
1. In Solution Explorer, right-click PurchaseOrder.xsd, and then click Properties.
2. In the Properties window, click Output Instance Filename, and then click the ellipsis
button (…).
3. In the Select Output File dialog box, navigate to C:\AllFiles\DemoCode\Module2, in
the File name box, type PurchaseOrder-Gen, and then click Save.
4. In Solution Explorer, right-click PurchaseOrder.xsd, and then click Generate
Instance.
5. In Windows Explorer, navigate to C:\AllFiles\DemoCode\Module2, and then open
PurchaseOrder-Gen.xml.
Notice that each node has been populated with sample data.
Test the Schema

1. In Solution Explorer, right-click PurchaseOrder.xsd, and then click Properties.
2. In the Properties window, click Input Instance Filename, and then click the ellipsis
button (…).
3. In the Select Input File dialog box, navigate to C:\AllFiles\Democode\Module2, click
Message1.xml, and then click Open.
This message represents a sample message from another system.
4. In Solution Explorer, right-click PurchaseOrder.xsd, and then click Validate Instance.
5. In the Output window, notice the message that reads Component invocation
succeeded, and then click the
file:///C:\AllFiles\DemoCode\Module2\Message1.xml link while holding CTRL.
The message is displayed.
6. Pause the bt10d-demos virtual machine.
Using the Flat File Schema Wizard
Create a schema by using the Flat File Schema Wizard.
Overview
The BizTalk Server toolset includes parsers and serializers for transforming data between EDI
or flat file formats and XML format. BizTalk Server 2010 solves the problem of creating
schemas for flat files by introducing a new tool called the Flat File Schema Wizard.
Using the Flat File Schema Wizard

The Flat File Schema Wizard provides a series of steps that allow you to quickly generate an
XSD for even quite complex flat file messages. Once this base XSD has been created, it can
then be opened by using either the BizTalk Schema Editor or another schema design tool
and edited further if necessary.
To launch the Flat File Schema Wizard, add a new item to an existing BizTalk project, and
choose the Flat File Schema Wizard option. In the BizTalk Flat File Schema Wizard dialog box,
browse to the flat file that you want to use as a source.
As you progress through the wizard, each record is identified, and then within these records,
each element or attribute is identified by name and data type. Each item that is identified as
a record or repeating record will cause the wizard to loop back through the process until all
nodes are identified.
Demonstration: Creating and Testing a Flat File Schema
In this demonstration, you will see how to create a flat file schema from a sample message by
using the Flat File Schema Wizard. You will then see how to test a flat file schema.
Create a Flat File Schema

1. Resume the bt10d-demos virtual machine.
2. If the Visual Studio solution is not already open, in Windows Explorer, navigate to
C:\AllFiles\Democode\Module2\Demo, and then double-click Demo.sln.
3. In the center pane, click Flat File Schema Wizard, in the Name box, replace the
existing text with PurchaseOrderFF.xsd, and then click Add.
4. On the Welcome page of the Flat File Schema Wizard, click Next.
5. On the Flat File Schema Information page, click Browse.
6. In the Select a Flat File Document dialog box, browse to and click
C:\AllFiles\Democode\Module2\PurchaseOrderFF.txt, and then click Open.
7. On the Flat File Schema Information page, in the Record name box, replace the
existing text with Order, and then click Next.
8. On the Select Document Data page, ensure that the entire message is selected, and
then click Next.
9. On the Select Record Format page, ensure that By delimiter symbol is selected, and
then click Next.
10. On the Delimited Record page, ensure that the Child delimiter is set to {CR}{LF},
select the Record has a tag identifier check box, in the Tag box, type PO, and then
click Next.
11. On the Child Elements page, set the Element Name and Element Type for each of
the elements in the following table, and then click Next.
Element Name Element Type
PODetail Record
Address Record
Items Record
12. On the Schema View page, ensure that PODetail is selected, and then click Next.
13. On the Select Document Data page, click Next.
then click Next.
15. On the Delimited Record page, in the Child delimiter list, click the comma (,) symbol,
and then click Next.
16. On the Child Elements page, set the Element Name, Element Type and Data Type
for each of the elements in the following table, and then click Next.
Element Name Element Type Data Type
OrderNumber Field attribute string
CustomerName Field attribute string
OrderDate Field attribute date
17. On the Schema View page, ensure that Address is selected, and then click Next.
19. On the Select Record Format page, click By relative positions, and then click Next.
20. On the Positional Record page, click the position to the left of each of the elements.
You should have an arrow in each of the following positions: 0 (default), 24, 39, 41.
21. Click Next.
Street Field element
City Field element
State Field element
Postal Field element
23. On the Schema View page, ensure that Items is selected, and then click Next.
then click Next.
26. On the Delimited Record page, using the drop-down list, change the Child Delimiter
to the comma (,) symbol, and then click the Record has a tag identifier check box.
27. In the Tag box, type Items, and then click Next.
28. In the error dialog box, click OK.
The Flat File Schema Wizard parses the message to verify that the tag identifier
is valid and case-sensitive. Because “Items” is not found within the record, an
error is displayed.
29. In the Tag box, type ITEMS, and then click Next.
Item Repeating Record
Items_Child2 Ignore
31. On the Schema View page, ensure that Item is selected, and then click Next.
then click Next.
34. On the Delimited Record page, using the drop-down list, change the Child Delimiter
to the pipe (|) symbol, and then click the Record has a tag identifier check box.
35. In the Tag box, type ITEM, and then click Next.
36. On the Child Elements page, set the Element Types for each of the Elements in the
following table, and then click Next.
ISBN Field element
Description Field element
Qty Field element
Price Field element
37. Click Finish.
Test the Flat File Schema

1. In Solution Explorer, right-click PurchaseOrderFF.xsd, and then click Properties.
In the PurchaseOrderFF.xsd properties window, notice that the Input Instance
Filename property is the same file that was used to create the schema by using
the Flat File Schema Wizard.
2. In Solution Explorer, right-click PurchaseOrderFF.xsd, and then click Validate
Instance.
3. In the Output window, hold the CTRL key, and then click the Validate Instance
succeeded for schema PurchaseOrderFF.xsd, file: link.
The sample message appears in the center pane.
4. In the Output window, hold the CTRL key, and then click the Validation generated
XML output link.
The flat file message is displayed in an XML format. Notice the repeating Item
nodes.
5. On the File menu, click Save All.
6. Close the Visual Studio solution and all other open windows.
7. Shut down the bt10d-demos virtual machine.
Building a BizTalk Project
Build a schema project into an assembly.
Overview
A BizTalk project can contain artifacts of many different kinds including schemas, maps,
orchestrations, and pipelines. Before using these artifacts in the messaging and
orchestration engines, the project needs to be built into an assembly.
Building a BizTalk Project

Building the project creates a dynamic-link library (DLL) with the same name as the project.
The DLL is created in the projectName\bin\Deployment folder. For example, if the EAICBR
solution contains a project named EAISchemas, the resulting assembly would be named
\EAISchemas\bin\Deployment\EAISchemas.dll.
If there are any build errors or warning messages, the Task List window will list these errors
and warnings, and double-clicking a task will show you the location of the error or warning.
Make sure that you test all schemas in the project with known document instance(s) before
compiling and deploying the project.
Lab: Creating and Configuring BizTalk Schemas
Scenario
Each type of message processed by a BizTalk server application requires an XML schema that
defines the structure of the message. In this lab, you will create a BizTalk Server project that
will contain your schemas. Adventure Works has defined an internal sales order message
format for which you will create a schema. Next you will use the Flat File Schema Wizard to
create a schema that represents the format of the sales orders submitted by the Adventure
Works stores. Finally, you will generate a schema from a sample loan application message.
Procedure List
window.
Start.
Exercise 1: Creating a New BizTalk Project
Overview
A BizTalk Server project contains BizTalk Server artifacts. In this exercise, you will create a
new Microsoft Visual Studio® 2010 solution and a new project that uses the BizTalk Server
Project template. This project will contain the schemas that you will create in the following
exercises.
Create a Blank Solution
Procedure List
1. On the Start menu, click All Programs, click Microsoft Visual Studio 2010, and then click
Microsoft Visual Studio 2010.
2. On the File menu, point to New, and then click Project.
3. In the New Project dialog box, in the Installed Templates pane, click BizTalk Projects,
click the Empty BizTalk Server Project icon, and then create a new project using the
information in the following table.
Property Value
Name Messaging
Location C:\AllFiles\LabFiles\Lab2
Create directory for solution <checked>
Solution Name AdvWorks
4. Click OK to create and open the new project.

Exercise 2: Creating an XML Schema
Overview
You can define an XML schema by manually defining each node, or by importing or including
other schemas. In this exercise, you will define schema nodes for the Adventure Works sales
order message and import nodes from an existing schema that contains customer information.
Create the SalesOrder Schema

Procedure List
1. In Solution Explorer, right-click the Messaging project, point to Add, and then click New
Folder.
2. Rename the folder Messages.
3. In Solution Explorer, right-click the Messages folder, point to Add, and then click
Existing Item.
4. In the Add Existing Item dialog box, navigate to C:\AllFiles\LabFiles\Lab2, and then
double-click SalesOrder1.xml.
This is a sample message of the schema that you will build in this exercise.
5. In Solution Explorer, double-click SalesOrder1.xml to open the message.
Examine the structure of the message.
Item.
7. In the Add New Item dialog box, in the Categories pane, then click the Schema icon.
8. In the Name box, type SalesOrder.xsd to name the schema.
9. Click Add to open the blank schema in BizTalk Editor.
The schema tree (left pane) and XSD view (right pane) appear in BizTalk Editor. Also,
the new schema (SalesOrder.xsd) is added to Solution Explorer.
Define the SalesOrder Schema Structure

Procedure List
1. In the Schema tree (left pane), right-click the Root node, click Rename, and then
rename the node to SalesOrder.
The Root node should always be renamed with a meaningful name that represents
the type of document described by the schema. When possible, use a root node
name that is unique throughout the enterprise.
2. Right-click the SalesOrder (root) node, point to Insert Schema Node, and then click
Child Record.
3. Rename the record to Detail.
4. Repeat steps 2 and 3 to create two more records and name them Record and Items.
5. Right-click the Detail node, point to Insert Schema Node, and then click Child Field
Attribute.
6. Rename the attribute to StoreNumber.
7. Repeat steps 5 and 6 to create four more attributes under the Detail record and name
them as follows: Employee, OrderNumber, OrderType, and OrderDate.
8. Right-click the Items node, point to Insert Schema Node, and then click Child Record.
9. Rename the record to Item.
10. Right-click the Item node, point to Insert Schema Node, and then click Child Field
Attribute.
11. Rename the attribute to Qty.
12. Repeat steps 10 and 11 to create three more attributes under the Item record and name
them as follows: SKU, Price, and ExtendedPrice.
13. Right-click the SalesOrder node, point to Insert Schema Node, and then click Child Field
Element.
14. Rename the element to Comment.
15. Repeat steps 13 and 14 to create two more elements under the Items record and name
them OrderTotal and TermOfLoan.
Import the Customer Information from another Schema

Procedure List
Existing Item.
2. In the Add Existing Item dialog box, browse to and add
C:\AllFiles\LabFiles\Lab2\CustomerInfo.xsd.
You may have noticed that the sample message contains a CustomerInfo record with
several fields; the CustomerInfo schema contains all these fields.
3. In BizTalk Editor, click the <Schema> node of the SalesOrder schema.
4. In the Properties window, click the Imports property, and then click the ellipsis (…)
button.
5. In the Imports dialog box, verify that XSD Import is selected from the list, and then click
Add.
6. In the BizTalk Type Picker dialog box, expand Messaging, expand Schemas, click
Messaging.CustomerInfo, and then click OK twice.
7. In the SalesOrder schema, click the Record node.
8. In the Properties window, click the Data Structure Type property, and then in the list,
click ns0:CustomerInfo (Reference).
Validate the Schema

Procedure List
1. In Solution Explorer, right-click SalesOrder.xsd, and then click Validate Schema.
You can use the Validate Schema command to determine whether a schema
contains any internal inconsistencies or has other issues that might prevent it from
being used effectively for processing instance messages. All schemas created by
using the BizTalk Schema Editor will always be valid, but this is a good way to verify
that the schemas you receive from other sources are recognizable to BizTalk.
Generate a Sample Instance

Procedure List
1. In Solution Explorer, click SalesOrder.xsd.
2. In the Properties window, in the Output Instance Filename box, type
C:\AllFiles\LabFiles\Lab2\SalesOrder-Gen.xml.
3. In Solution Explore, right-click SalesOrder.xsd, and then click Generate Instance.
A sample instance message is saved in C:\AllFiles\LabFiles\Lab2, and a link to the
XML instance is shown in the Output window. Hold the CTRL key, and click the link to
open the resulting XML file.
Validate the Sample Instance Message

Procedure List
1. Click SalesOrder.xsd, and in the Properties window, in the Input Instance Filename box,
type C:\AllFiles\LabFiles\Lab2\SalesOrder1.xml
2. Right-click SalesOrder.xsd, and then click Validate Instance.
The results of the instance validation are displayed in the output window. This step
validates the schema against an actual XML file.
Exercise 3: Creating a Flat File Schema
Overview
BizTalk Server can also process messages in positional or delimited formats (flat files). In this
exercise, you will use the Flat File Schema Wizard to create a schema that defines the structure
of flat file messages sent from the Adventure Works stores.
Create the SalesOrder_FF schema

Procedure List
C:\AllFiles\LabFiles\Lab2\SalesOrder_FF_Sample.txt.
2. Examine the structure of the file, and then close Notepad.
Item.
4. In the Add New Item dialog box, click Flat File Schema Wizard (notice that this is
different than the Flat File Schema item).
5. In the Name box, type SalesOrder_FF.xsd, and then click Add.
6. On the Welcome to the BizTalk Flat File Schema Wizard page, click Next.
7. On the Flat File Schema Information page, in the Instance file box, browse to or type
8. In the Record name box, type SalesOrder, and then click Next.
9. On the Select Document Data page, ensure that the entire contents of the document
are selected, and then click Next.
10. On the Select Record Format page, verify that By delimiter symbol is selected, and then
click Next.
11. On the Delimited Record page, ensure that the Child Delimiter is set to {CR}{LF}, and
then click Next.
12. On the Child Elements page, change the Element Names and Element Types as follows:
OrderDetail Record
CustomerInfo Record
Products Record
Comment Field element
13. Click Next.
Define the OrderDetail Record Structure

Procedure List
1. On the Schema View page, ensure that the OrderDetail record is selected, and then click
Next.
2. On the Select Document Data page, ensure that the first line of content is selected
(excluding the ¶« characters), and then click Next.
click Next.
4. On the Delimited Record page, set the Child Delimiter to , (comma), and then click Next.
StoreNumber Field Attribute
OrderNumber Field Attribute
Cash_Cred Field Attribute
EmployeeName Field Attribute
TotalOrder Field Attribute
6. Click Next.
Define the CustomerInfo Record Structure

Procedure List
1. On the Schema View page, ensure that the CustomerInfo record is selected, and then
click Next.
2. On the Select Document Data page, ensure that the second line (name and address) is
selected (excluding the ¶« characters), and then click Next.
3. On the Select Record Format page, select By relative positions, and then click Next.
4. On the Positional Record page, click the hash mark on the ruler at positions 5, 30, 34,
59, 69 and 71, and then click Next. If you accidently click an incorrect position, click it
again to remove the position marker.
ID Field Element
CustomerName Field Element
MonthsAtResidence Field Element
Address Field Element
Town Field Element
State Field Element
ZipCode Field Element
6. Click Next.
Define the Products Record
Procedure List
1. On the Schema View page, ensure that the Products record is selected, and then click
Next.
2. On the Select Document Data page, ensure that the third line (products) is selected
click Next.
4. On the Delimited Record page, set the Child Delimiter to , (comma).
5. Check the Record has a tag identifier check box, in the Tag box, type PRODUCTS, and
then click Next.
6. On the Child Elements page, in the first row, change the Element Name to Product, and
change the Element Type to Repeating record. In the second row, change the Element
Type to Ignore, and then click Next.
Define the Product Record

Procedure List
1. On the Schema View page, ensure that Product is selected, and then click Next.
2. On the Select Document Data page, ensure the first Product record is selected
(“PRODUCT|1|75…|200.00”), excluding all commas, and then click Next.
3. On the Select Record Format page, click By delimiter symbol, and then click Next.
4. Set the Child delimiter to | (pipe), check the Record has a tag identifier box, enter
PRODUCT in the Tag field, and then click Next.
Quantity Field Attribute
ItemNumber Field Attribute
PriceEach Field Attribute
6. Click Next.
7. Click Finish.

Procedure List
1. In Solution Explorer, click SalesOrder_FF.xsd, then select the Input Instance Filename
field in the Properties window. Notice that the file is the same as the sample instance
used to generate the schema with the Flat File Schema Wizard.
2. Right-click SalesOrder_FF.xsd, and then click Validate Instance.
validates the schema against sample a flat file.
3. In the Output window, hold CTRL and click the link to the right of Validation generated
XML output to view the XML representation of the flat file instance.
Exercise 4: Generating a Schema from an XML Message Instance
Overview
BizTalk can generate a schema based on an existing XML message instance. In this exercise, you
will generate a schema based on a sample loan application message.
Install the Well-Formed XML Schema Generator

Procedure List
1. In Windows Explorer, navigate to C:\Program Files (x86)\Microsoft BizTalk Server
2010\SDK\Utilities\Schema Generator, and then double-click InstallWFX.vbs.
A command window will appear briefly as the VB script is executed.
Create the LoanApp Schema

Procedure List
1. In Windows Explorer, browse to and open
C:\AllFiles\LabFiles\Lab2\LoanApp_Sample.xml.
This is a sample of the message that is evaluated against a set of business rules to
automatically approve or deny a loan application.
2. Close Internet Explorer.
3. In Solution Explorer, right-click the Messaging project, point to Add, and then click Add
Generated Items.
4. In the Add Generated Items dialog box, in the Categories pane, click the Generate
Schemas icon, then click Add.
5. In the Generate Schemas dialog box, in the Document type list, click Well-Formed XML,
in the Input file box, browse to C:\AllFiles\LabFiles\Lab2\LoanApp_Sample.xml, click
Open, and then click OK.
6. In Solution Explorer, verify that a LoanApp_Sample schema, which represents the
sample message, has been created.
7. Rename LoanApp_Sample.xsd to LoanApp.xsd.
8. Click LoanApp.xsd, and then in the Properties window, type LoanApp in the Type Name
box.
9. Save and Close the AdvWorks solution.
Module 3: Creating Maps
Module objective:
Create a BizTalk map and configure functoids to manipulate data within a map.
Overview
Using the Microsoft BizTalk Mapper, you define the relationship between an input and an
output schema using links and functoids. A link defines a direct data copy of a record or field.
Links may directly connect to items in the other schema, or they may form connections to
functoids. Functoids perform more complex data manipulations. This module discusses the
role played by Microsoft BizTalk maps in the BizTalk Server architecture and how to work
with maps and functoids.
Lesson 1: Creating a BizTalk Map
Lesson objective:
Create basic and complex BizTalk maps and validate a map.
Lesson Overview
When building enterprise application–integration solutions, it is usually necessary to convert
between different message types. This could be done by simply converting all of the data
from a trading partner’s format for a purchase order to your company’s internal messaging
format. In other cases, only some of the information from an incoming message may be
required. For example, the information from an incoming purchase order may be used to
create a related invoice. Maps can be applied during run time by the BizTalk messaging
engine, or, as you will see in later modules, within an orchestration.
In this lesson, students will learn how maps are used by BizTalk and how to use the BizTalk
Mapper to create a map. Students will also learn how to use shortcuts to simplify the map
creation process.
What Is a BizTalk Map?
Describe the purpose of a map and explain the difference between transformation and
translation.
Terminology
 Map. You create a map when you want to transform or translate data between
message formats.
 BizTalk Mapper. A visual tool, hosted within Microsoft Visual Studio®, for
constructing BizTalk maps, which define data transformations.
 Data transformation. The process of converting an XML document that conforms to
one schema into an XML document that conforms to another schema. A
transformation can simply change the formatting applied to the data, but more
often, data transformation results in some kind of structural change to the
document. For example, a system that automates purchase order processing will
typically transform purchase order records into one or more invoices.
 BizTalk map. A file that defines the correspondence between the records and fields
in one schema and the records and fields in another schema. BizTalk maps are
implemented in XML Extensible Stylesheet Language Transformations (XSLT).
 Extensible Stylesheet Language Transformations (XSLT). An industry-standard
specification defined by the World Wide Web Consortium (WC3) for expressing
transformations between two documents. The XSLT generated by BizTalk is fully
W3C compliant.
 Data translation. A special case of data transformation that involves changing the
format of an instance message, typically from non-XML (EDI or flat-file) to XML
format, or vice versa. For example, if your internal processes utilize XML data, but
your trading partner needs to receive messages in a flat-file format, you can perform
the necessary translation before you send such messages to the trading partner.
Data translation can be especially helpful in solving enterprise application
integration problems by rendering a given type of message into alternative formats
required by existing systems.
 Functoid. An executable module that performs a specific calculation or data
manipulation. Functoids provide BizTalk map developers with the ability to create
richer transformations than what is provided by XSLT on its own.
Use Cases
In addition to simple value mapping, the transformation process can include such operations
as:
 Flattening records received in a message that has a hierarchical format to one with a
flatter design.
 Averaging data from multiple input nodes and sending the output to a single field in
the destination message.
 Applying mathematical functions on values in the source message and then writing
the result to the destination message.
 Concatenating multiple elements from the source message into a single field in the
destination message.
 Looking up a value from the source message in a database or an in-memory table
and extracting new values to be written to the destination message.
Creating a Map by Using the BizTalk Mapper
Explain how the BizTalk Mapper works to create maps and how maps are compiled as XSLT files.
Starting the BizTalk Mapper Tool

The BizTalk Mapper tool, which is integrated into Visual Studio 2010, starts automatically
when you either add a new map to a BizTalk project or open an existing map (a .btm file). To
create a map, you must specify the source schema and the destination schema. The source
and destination schemas must either be part of the current BizTalk project or be in a
referenced assembly.
BizTalk Mapper Views

The BizTalk Mapper view consists of three panes within the Visual Studio interface:
 Source schema pane. Displays the schema of incoming instance messages. The links
that define the mapping originate from the source schema tree view, passing
through the map zone and ultimately to the destination schema tree view.
 Map grid view pane. Shows the links and functoids that control how data in a source
instance message is transformed to the destination schema. You work actively in this
view to construct your map. The map grid can have multiple pages, which can also
be named. This is helpful as maps become more complex.
 Destination schema pane. Provides a tree view of an instance message as it will look
after being processed by a BizTalk Server destination schema.
Mapper Improvements
With the release of Microsoft BizTalk Server 2010, the BizTalk Mapper has been improved
with a new user interface that eases development of large. The new BizTalk Mapper
improves productivity by adding cut, copy, paste, move and undo functions and improved
support for search and readability. The new search feature highlights source and destination
schema nodes, and functoids containing text that match the search criteria.
Readability improvements include new pan and zoom features, and automatic panning that
brings all of the relevant links and functoids in to view when a user clicks on schema node.
The new mapper also hides or dims background schema nodes, links and functoids that are
not relevant to the user’s current selection.
Generating XSLT from a Map

Before the map can be used by BizTalk, the project containing the map needs to be built
(compiled) into an assembly. As you develop a map, BizTalk will generate compiler errors if it
encounters any type mismatches between the source and destination schemas. XSLT is
generated from the map when the project is built, and the XSLT code is executed when the
map is applied during run time.
Validation Considerations During Run Time

During run time, because maps do not perform validation on the inbound or outbound
messages, a map could potentially generate an invalid outbound message. For this reason,
source data should be validated against an XSD schema prior to being inserted into any
process that uses maps.
Creating Links
Use the BizTalk Mapper to automate the process of linking nodes within a map.
How to Specify Links

You can specify each individual link between two schemas yourself, or you can allow the
BizTalk Mapper to specify links automatically. When you allow the BizTalk Mapper to
automatically specify links, you must still choose between two options: Link by Name, or
Link by Structure.
BizTalk Mapper Link Types

The BizTalk Mapper supports the following types of linking:
 Simple linking. Use simple linking between individual nodes. To create a simple link,
drag a node from the source schema, and then drop it onto the target node in the
destination schema.
 Structure linking. Use structure linking when the structure of the records being
linked in your source and destination schemas are the same or very similar.
Structure linking can be applied to the entire schemas or just to parts of each. By
performing a structure link from a record in a source to a record in a destination
schema, the subordinate nodes will automatically be linked. To create a structure
link between portions of your source and destination schemas that have matching
structures, hold the SHIFT key while linking the relevant records. After you link the
records, links are automatically created for all of the subordinate records and fields
for which a match is found.
 Name-matching linking. Use name-matching linking when the structure of the
records being linked in your source and destination schemas are somewhat similar
and have matching record and field names, but have more structural exceptions
than would be practicable for structure linking. The new BizTalk 2010 Mapper
employs a new predictive name matching algorithm that creates links between
nodes that have similar names, and are likely matches, even though the names may
not be exact matches.
Any links created by using complex linking are no different from links that are created
manually. They can be deleted and relinked.
Basic and Complex Map Links
Identify the differences between a basic and a complex map.
Overview
The BizTalk Mapper provides a solution for a variety of mapping scenarios, ranging from
simple parent-child tree-type operations to detailed operations that are complex and involve
looping records and hierarchies. Almost all mapping scenarios can fit into one of two
categories: basic mapping and complex mapping.
Basic Mapping
Basic mapping is the most common type of mapping. It involves copying a value from an
element or attribute that occurs once in an input instance message to an element or
attribute that occurs once in an output instance message. In the corresponding source and
destination schemas, the record or field node that corresponds to the element or attribute
and all of its ancestors will be specified such that the element or attribute appears in the
instance messages once and only once.
Complex Mapping
Complex mapping involves records or fields that can occur multiple times for a single
instance of the Record or Field Element node in the schema tree. This type of variable count
mapping is called looping. You create this type of mapping by linking a field in a looping
record in the source schema to a field in a looping record in the destination schema. The
number of corresponding elements in an input instance message will then dictate the
number of elements created in the output instance message. Another type of complex
mapping occurs when a record or element occurs only once in the source schema but must
be mapped to repeating nodes in the destination schema.
Validating, Testing and Debugging a Map
Validate and test a map.
Validating a Map
Before a map is deployed, it should be tested to ensure that the resulting message contains
the desired results. The BizTalk Mapper provides the tools for validating a map and testing a
map with sample data, much as can be done with schemas.
In BizTalk Server 2010, the mapping of small messages occurs in memory. For performance
reasons, by default, mapping (which is a very memory-intensive operation) does not
perform data validation when executed in a pipeline. However, you can create a custom
pipeline and use the XML validator component to perform validation before and after
mapping within the pipeline. A new feature in BizTalk Server 2010 enables the ability to
perform large message mapping, which uses disk cache in addition to memory.
To validate a map, simply right-click the map in Solution Explorer, and then click Validate
Map. The Output pane will display a link with an .xsl extension that displays the actual XSTL
output generated by the map. This can be useful for troubleshooting execution problems
with the map.
Testing a Map
Before you can test a map, you need to specify the type and location of an instance message
to be used for testing. Several properties need to be configured, which are set in the .NET
properties for the map. The .NET properties, as distinguished from the BizTalk properties,
are accessed by right-clicking the map in Solution Explorer, and then clicking Properties.
 Validate TestMap Input. Specifies that the input message should be validated.
 Validate TestMap Output. Specifies that the output message should be validated.
 TestMap Input Instance. This is the message that you will use as the source message
instance for the map. This instance should be validated using the schema validation
steps described in Module 2, “Creating Schemas.”
 TestMap Input. This specifies the format of the test message (XML, Native, or
Generated Instance). Native specifies that Visual Studio must convert the input file
from flat file format to XML before executing the map.
 TestMap Output. This specifies the format of the test message (XML or Native).
 TestMap Output Instance. Specifies the file location for the message to be written
to. If the file exists in the same location, it will be overwritten.
After configuring the test properties, right-click the map in Solution Explorer, and then click
Test Map. A link to the input and output message will be shown.
Demonstration: Creating and Testing a BizTalk Map
Learn how to create a map by using the BizTalk Mapper tool and how to create simple and
automated links. You will then see how to test and validate a map.
Create a BizTalk Map

1. In Microsoft Windows Explorer, navigate to C:\AllFiles\DemoCode\Module3\Demo,
and then double-click Demo.sln.
The following demonstration is not dependent upon completion of the previous
demonstrations. This solution provides artifacts and file paths that differ from
those used in the previous demonstrations.
New Item.
3. In the Add New Item dialog box, in the center pane, click Map, in the Name box,
type PurchaseOrderFF_to_PurchaseOrder.btm, and then click Add.
The map opens in the BizTalk Mapper.
4. Click the Open Source Schema link.
5. In the BizTalk Type Picker dialog box, expand Messaging, expand Schemas, and then
double-click Demo.Messaging.PurchaseOrderFF.
6. Click the Open Destination Schema link.
7. In the BizTalk Type Picker dialog box, expand Messaging, expand Schemas, and then
double-click Demo.Messaging.PurchaseOrder.
8. In the BizTalk Mapper, right-click the <Schema> node of the Source Schema, and
then click Expand Tree Node.
9. In the BizTalk Mapper, right-click the <Schema> node of the Destination Schema,
and then click Expand Tree Node.
10. While holding the SHIFT key, drag and drop the Address node from the Source
Schema to the Address node in the Destination Schema, then click Link by Structure.
The nodes are mapped according to the structure of the nodes.
11. While holding the SHIFT key, drag and drop the Item node from the Source Schema
to the Item node in the Destination Schema, then click Link by Name
Only the nodes with identical names are mapped.
12. Drag the ISBN node from the Source Schema to the SKU node in the Destination
Schema.
Test a BizTalk Map

1. In Windows Explorer, navigate to C:\AllFiles\DemoCode\Module3, and then
double-click Message1.xml.
2. Examine the structure and content of the message. The new map will create
messages similar to this one. Close Microsoft Internet Explorer.
3. In Solution Explorer, right-click PurchaseOrderFF_to_PurchaseOrder.btm, and then
click Properties.
4. In the Properties window, in the TestMap Input list, click Native.
5. In the Properties window, click TestMap Input Instance, and then click the ellipsis
(…) button.
6. In the Select Input File dialog box, navigate to C:\AllFiles\Democode\Module3, click
Message1FF.txt, and then click Open.
8. On the In Solution Explorer, right-click PurchaseOrderFF_to_PurchaseOrder.btm,
and then click Test Map.
9. In the Output window, scroll to the right, and then while holding the CTRL key, click
the link to the right of The output is stored in the following file.
Ignore the warnings and errors you receive. They will be resolved when the map
is completed in the upcoming demonstrations.
10. Examine the message that appears, and then close it.
Lesson 2: Configuring Basic Functoids
Lesson objective:
Create and configure functoids to manipulate data within a map
Lesson Overview
Whereas linking provides for copying values from one message to another, functoids allow
the manipulation of the data contained in the message. There are approximately 70
functoids that provide simple mathematical functions, string manipulation and date and
time insertion, and complex scientific calculations.
Data Manipulation with Functoids
Identify the types of data manipulations that can be performed by a functoid.
About Functoids
A functoid is an executable module that performs a specific calculation or data
manipulation. A functoid can be used graphically when constructing BizTalk Server maps to
provide the basis for richer transformations than what is provided by XSLT on its own.
The BizTalk functoids allow you to extend the functionality of the map to perform a variety
of operations on data as the data is being transformed from the source message to the
destination message.
The most common use of a functoid is to perform numeric calculations, such as summing the
total number of products ordered. Functoids that can have zero or more inbound links can
be chained to provide additional functionality.
Writing Custom Functoids

In addition to using the predefined functoids, you can also write your own functoid as a
script file or a .NET assembly. The BizTalk SDK has examples on how to use both scripting
functoids and how to create custom functoids.
Note: Many functoids require input parameters, so if a parameter is not valid, a default
value will be passed to the functoid in its place. The default value for numeric input
parameters is zero (0), and for all other inputs, the default is blank.
The output of a map validation will result in a link that will show the XSLT code generated by
the map. This will include the manipulations being performed by the functoids.
Using Basic Functoids
Perform data manipulation by using a basic functoid.
Basic Functoids
There are over 70 predefined functoids included with the BizTalk Mapper. These functoids
can perform such operations as calculations including multiplication and division, adding the
current date and time to an output instance message, and concatenating multiple strings
together to form one node in the destination side of the map. The basic functoid categories
for predefined functoids include:
 Conversion. Use the Conversion functoids to perform conversions between numeric
bases, such as from hexadecimal to decimal.
 Cumulative. Use the Cumulative functoids to perform accumulation operations for
values that occur multiple times within an instance message.
 Date and Time. Use the Date and Time functoids to introduce the current date,
time, or both into the message or to add days to a specified date, in output data.
This enables you to insert the processed date (and time) into a message or calculate
an anticipated ship date.
 Logical. Use the Logical functoids either to perform specific logical tests at run time
or determine whether output instance data is created at run time. Returns a string
(True or False).
 Mathematical. Use the Mathematical functoids to perform calculations by using
specific values (arguments) in a specified order or structure.
 Scientific. Use the Scientific functoids to convert a numeric value to a scientific
value. For example, the Cosine functoid takes a value in radians from a field or
record and returns the value of the cosine.
 String. Use the String functoids to manipulate data strings by using string functions.
The String Concatenate functoid combines two or more inputs (nodes, constants, or
other functoids) and builds a string. The String Find functoid finds one text string
within another text string and returns the position of the first character of the found
string.
Adding Functoids to a Map
Use the BizTalk Mapper to add and configure a functoid.
Adding Functoids
To add functoids to a map, drag a functoid from the Toolbox to the map grid, link a node in
the source schema to the functoid, and then link the functoid to a node in the target
schema. You can also chain functoids to provide a more complex result. For example, a
multiplication functoid could obtain the product of Quantity times Price for each instance of
a product in an inbound message and then add the total to a node in a destination message.
Note: Functoid linking works only from left to right. That is, you cannot link from a functoid
back to a source schema node nor to another functoid that is located to the left of the
source functoid; you can link only from the source schema node to the functoid.
Functoid Properties
The properties of each functoid are displayed in the Visual Studio Properties window when
that functoid is selected in the map zone layer. All functoid properties are categorized as
general properties and are listed in the order in which they appear in the Properties window,
regardless of whether they are being displayed alphabetically or by category.
Functoid properties can be categorized as follows:
 Label. The Label property available for links and functoids provides a mechanism for
assigning a descriptive name, which can be extremely useful in map maintenance.
 Input Parameters. The Input Parameters property provides access to the Configure
Functoid dialog box, which provides access to all of the functoid properties,
including inputs, label, comments and a functoid description which explains the
usage of the functoid, and lists required inputs.
 Name, Help, Maximum Input Parameters, and Minimum Input Parameters. These
properties are always read-only and are informational in nature.
Note: For more information, see the Functoid Reference, provided in BizTalk Server 2010
Help.
Using Map Grid Pages
Use map grid pages to manage large and complex maps.
Map Pages
Maps for many types of business documents can require large numbers of links and
functoids, rendering the map grid complex and difficult to understand. For improved
readability, you can create separate map grid pages to isolate logical groupings of mapping
operations into separate pages. You can then view and work with each grouping individually.
You can add new pages, rename pages, delete pages, reorder pages, and move between and
within them. Map execution is non-deterministic with map pages. In other words, the
mapping will not occur in a top-down or bottom-up order. Similarly, functoids on page 1 are
not necessarily executed before the ones on page 2.
Note: All functoids that are connected together must reside on the same page. Also, if you
delete a grid page, you delete all the links and functoids on that page. The new BizTalk 2010
Mapper allows you to cut/copy and paste links and functoids from one map page to another.
Demonstration: Adding Functoids to a Map
Learn how to add a map page and functoids to a map. You will then see how to test the map to
verify that the functoids are behaving properly.
Add a New Page to a Map

2. If it is not open already, in Solution Explorer, double-click
PurchaseOrderFF_to_PurchaseOrder.btm to open the map.
3. Right-click the Page 1 tab at the bottom of the map grid, and then click Rename
Page.
4. Rename the page to Links.
5. Right-click next to the Links tab at the bottom of the map grid, and then click Add
Page.
6. Right-click the Page 1 tab at the bottom of the map grid, and then click Rename
Page.
7. Rename the page to Functoids.
Having multiple map pages helps to keep the map organized.
Add a String Concatenate Functoid

1. From the Toolbox, drag a String Concatenate functoid to the map grid of the
Functoids page.
2. Double-click the String Concatenate functoid on the map grid.
3. In the Configure String Concatenate Functoid dialog box, read the Functoid
description, and then click OK.
4. Connect the LastName node from the Source Schema to the String Concatenate
functoid.
5. Connect the FirstName node from the Source Schema to the String Concatenate
functoid.
6. Double-click the String Concatenate functoid.
7. In the Configure String Concatenate Functoid dialog box, click the Insert new
parameter button (second button from the left).
8. In the parameter, type a comma and then a space (, ).
9. Click OK, then click on the map grid to deselect the String Concatenate functoid.
10. Connect the String Concatenate functoid to the Name node in the Destination
Schema.
Add a Multiplication Functoid

1. From the Toolbox, drag a Multiplication functoid to the map grid.
2. Connect the Price node in the Source Schema to the Multiplication functoid.
3. Connect the Qty node in the Source Schema to the Multiplication functoid.
4. Connect the Multiplication functoid to the ExtendedPrice node in the Destination
Schema.
Add a Cumulative Sum Functoid

1. From the Toolbox, drag a Cumulative Sum functoid to the map grid.
2. Connect the Multiplication functoid to the Cumulative Sum functoid.
3. Connect the Cumulative Sum functoid to the OrderTotal node of the Destination
Schema.
Test the Map

click Test Map.
3. Examine the output message.
Notice that the Customer Name is displayed as Harris, Keith, the ExtendedPrice
for each line item is the product of Price and Quantity, and the OrderTotal is the
cumulative sum of the line items.
Lesson 3: Configuring Advanced Functoids
Lesson objective:
Create and configure advanced functoids for complex mapping operations
Lesson Overview
Advanced functoids allow more complex types of mapping. For example, you can look up
information in a database or you can call a custom .NET component to accomplish business-
specific tasks.
Using Advanced Functoids
Perform data manipulation by using advanced functoids.
Overview
Advanced functoids allow more complex types of mapping. Advanced functoids allow you to:
 Manage looping records. The Index, Iteration, Looping, Record Count, Table
Extractor, and Table Looping functoids are used in various combinations to achieve
appropriate results when the input instance message contains sections that have an
unpredictable number of repeating elements.
 Create conditional mapping. The Value Mapping and Value Mapping (Flattening)
functoids are used to provide conditional mapping from an input instance message
to an output instance message.
 Define arbitrary scripting. The Scripting functoid is used to run arbitrary script or
compiled code when an input instance message is being mapped to an output
instance message.
 Copy entire elements of data. The Mass Copy functoid, which implements the XSLT
<xsl:copy select=”..” /> function, can be used to copy an entire record, including its
subelements, to an arbitrary depth, from an input message to an output message.
Using Looping Functoids
Configure looping and table-driven functoids
Looping Functoids
Looping functoids are used when the input instance message contains sections that have a
number of repeating elements that need to be mapped to the destination message.
There are several functoids that allow you to loop through records:
 Looping functoid. This functoid is used to combine multiple records or fields in the
source schema into a single record in the destination schema. For example, if you
have an unknown number of line items in an inbound message, and you want to set
a grand total in the destination message, you use the looping functoid. There is no
limit to the number of inputs a looping functoid can accept, but only links from the
source schema are allowed as input parameters.
 Index functoid. This functoid enables you to select a specific value or set of values in
a source message to be copied to the destination message. This functoid must have
at least one input parameter that is a link from a record or field in the source
schema. The second and succeeding input parameters specify the record. See Help
for more information.
 Record Count functoid. This functoid is used to count the number of records in the
input instance message. This functoid takes one input parameter that is the link
from a looping record in the source schema. The output of this functoid is the count
of the looping record in the source instance message. For example, you may need to
create a purchase order summary message that has only the total number of unique
items purchased as indicated in the PO details. This functoid would count the
number of line items in the purchase order details and copy the total results to the
purchase order summary destination message.
Table-Driven Functoids
In a map, you can use a table looping functoid in conjunction with one or more table
extractor functoids when you need an input instance structure to produce multiple output
instance structures. For example, if you have a single address in your source schema that
needs to be entered in both the BillTo and ShipTo address along with a node that indicates
the address type in the destination message, you can use the Table Looping and the Table
Extractor functoids to create these records in the destination schema.
 Table Looping functoid. This functoid enables you to create a table of output values
to use in creating the output instance message. The data in the table can consist of
links and constants. This functoid must have at least two input parameters. The first
input parameter configures how many times the table will loop, and the second
input parameter determines how many columns are in the table. Additional
parameters define possible cell values for the table.
 Table Extractor functoid. This functoid is used to output the data associated with a
specified column for each row of the table looping grid of the Table Looping
functoid. This functoid must have two input parameters. The first parameter is an
output link from a Table Looping functoid, and the second parameter is the column
number of the table looping grid from which this functoid is meant to retrieve data.
You must use the Table Extractor functoid in conjunction with the Table Looping
functoid.
Using Database Functoids
Configure database functoids
Functoids of Special Interest in Database Development

Some of the most useful functoids for accessing data in a database include:
 Database Lookup. Performs a database lookup and stores the result in an ActiveX®
Data Objects (ADO) dataset. This functoid might be used for mapping older product
codes to newer product codes. This functoid requires four input parameters: lookup
value (typically a node from the source message), a connection string, a table name,
and a column name in the table to be looked up.
 Value Extractor. Extracts the value from a specified column in an ADO dataset. The
first parameter of the Value Extractor functoid should be the Database Lookup
functoid. For example, if you need to query a database for multiple columns from a
table, you can use value extractor functoids to pull out a single value from the result
set to populate a value in the destination instance message. Multiple value extractor
functoids can be used with a single database lookup functoid.
 Error Return. Captures error information, such as database connection failures, that
occurs during run time. This functoid returns any Open Database Connectivity
(ODBC) errors from a Database Lookup functoid.
 Format Message. Returns a formatted and localized string. For example, if a string
such as Operation %1 failed with the code %2, you could replace the %1 and %2 with
actual string values.
Using a Scripting Functoid
Create and configure a scripting functoid
Overview
The Scripting functoid is used to run arbitrary script or compiled code when an input
instance message is being mapped to an output instance message. The script or compiled
code can be created so that it accepts input parameters from the source instance message,
configured constant values, the output of another functoid, or some combination thereof.
You can call a .NET assembly at run time by using the Scripting functoid. For example, if you
need to calculate the tax for an invoice, you can create a .NET assembly by using Visual
Studio and then calling a method in the assembly to calculate the tax. This can be very useful
when you are performing calculations multiple times on multiple systems and want to
minimize the amount of code to write.
BizTalk Server 2010 supports the following languages and technologies for the Scripting
functoid:
 Microsoft Visual Basic®
 C#
 JScript
 Extensible Stylesheet Language Transformations (XSLT) and XSLT Call Templates.
Occasionally it may be easier or more manageable to write your own XSLT to map multiple
nodes or to perform complex computations. For example, a couple lines of well-written XSLT
may replace several functoids.
Any external assemblies called by the Scripting functoid must be located in the global
assembly cache (GAC) of the BizTalk server. By placing the assembly in the GAC, support for
multiple versions of the assembly is provided.
Demonstration: Configuring Advanced Functoids
Learn how to use the looping functoid in a map.
Add a Looping Functoid

2. If the PurchaseOrderFF_to_PurchaseOrder.btm map is not already open, open it in
Solution Explorer.
3. From the Toolbox, drag a Looping functoid to the map grid of the Functoids page.
4. Double-click the Looping functoid on the map grid.
5. In the Configure Looping Functoid dialog box, read the Functoid description, and
then click OK.
6. Connect the Item node from the Source Schema to the Looping functoid.
7. Connect the Looping functoid to the Item node of the Destination Schema.
8. From the Toolbox, drag a Greater Than functoid to the map grid of the Functoids
page.
9. Connect the Qty node from the Source Schema to the Greater Than functoid.
10. Double-click the Greater Than functoid. In the Configure Greater Than Functoid
dialog box, double-click the Condition2 row, enter the value 0, and then click OK.
11. Click anywhere on the map grid to deselect the Greater Than functoid.
12. Connect the Greater Than functoid to the Item node of the Destination Schema.
With this loop condition in place, the map will only copy Items that have a Qty
value greater than zero.
Test the Map

click Test Map.
3. Notice that the map copied only the Item records from the input message that had
Qty greater than zero.
4. On the File menu click Save All, and then close the Visual Studio solution and all
other open windows.
Lab: Creating a BizTalk Map
Scenario
Maps are typically used to convert messages from one format to another. In this lab, you will
create a map that is used to transform data from the flat file format generated by the
Adventure Works stores to the internal sales order format used by the sales order
application. You will configure the map with several functoids to manipulate and modify the
message data. You will also configure the map to retrieve information from a Microsoft® SQL
Server™ database and insert it into the destination message.
Procedure List
window.
Start.
Exercise 1: Creating a Map
Overview
A BizTalk map is used to convert message data between XML formats. In this exercise, you
will use the BizTalk Mapper to create a map that transforms data from the SalesOrder_FF
schema to the SalesOrder schema format. This map will contain links that associate the data
fields between these two schemas.
Open an Existing Solution

Procedure List
1. On the Start menu, click All Programs, click Microsoft Visual Studio 2010, and then
click Microsoft Visual Studio 2010.
2. In Visual Studio, on the File menu, point to Open, and then click Project/Solution.
3. In the Open Project dialog box, browse to C:\AllFiles\LabFiles\Lab3\AdvWorks, click
AdvWorks.sln, and then click Open.
The existing project opens in Solution Explorer.
Create a New BizTalk Map

Procedure List
New Item.
2. In the Add New Item dialog box, click the Map icon.
3. In the Name box, type SalesOrder_FF_to_SalesOrder_XML.btm to name the map.
Notice the naming convention of the map. It is a good idea to incorporate the
source and destination schemas when naming a map.
4. Click Add to start the BizTalk Mapper.
Selecting the Map template causes the BizTalk Mapper to start after the map is
added to the project.
5. In the BizTalk Mapper, click the Open Source Schema, expand Messaging, then
Schemas, select AdvWorks.Messaging.SalesOrder_FF, and then click OK.
6. In the BizTalk Mapper, click the Open Destination Schema, expand Messaging, then
Schemas, select AdvWorks.Messaging.SalesOrder, and then click OK
Link Nodes Manually Between Schemas

Procedure List
1. Below the map grid, right-click the Page 1 tab (at the bottom of the map), and then
click Rename Page.
Renaming the map page makes map management easier. It does not affect the
XSLT in any way.
3. In the Source Schema, right-click Schema, and then click Expand Tree Node.
4. In the Destination Schema, right-click Schema, and then click Expand Tree Node.
5. Using only the pairings in the following table, click and drag a link from each source
field from the Source Schema across the Map grid to the associated destination field
in the Destination Schema.
Source Field Destination Field
StoreNumber StoreNumber
OrderNumber OrderNumber
Employee Employee
Link Nodes Automatically by Node Name

Procedure List
1. In the Source Schema, click the CustomerInfo node, and then while holding the
SHIFT key, click and drag a link from the CustomerInfo node to the CustomerInfo
node in the destination schema. Choose Link by Name in the menu that appears
when you release the mouse button.
Notice how fields with the same name were automatically mapped. You will have
to manually map fields from the source schema that do not have matching
names in the destination schema.
2. In the Source Schema, click the CustomerInfo node, and then while holding the
SHIFT key, drag a link from the CustomerInfo node to the Residence node in the
Destination Schema. Choose Link by Name in the menu that appears when you
release the mouse button.
Notice that the Address, Town, Region, and ZipCode fields are not automatically
mapped to the Residence node. Because the names of these fields do not match
in the source and destination schemas, you will have to map these manually.
3. Using the pairings in the following table, click and drag a link from each source field
from the Source Schema across the Map grid to the associated destination field in
the Destination Schema.
Use the Residence record on the Destination Schema for the mappings to Street,
City, State, and PostalCode. The BillingAddress record mappings will be made in
a later exercise.
Address Street (Residence)
Town City (Residence)
Region State (Residence)
ZipCode PostalCode (Residence)
Employer Employer
MonthsEmployed MonthsEmployed
PrimaryIncome Primary
OtherIncome Other
Link Nodes Automatically by Structure

Procedure List
1. In the Source Schema, click the Product node, and then while holding the SHIFT key,
drag a link from the Product node to the Item node in the Destination Schema.
Choose Link by Structure in the menu that appears when you release the mouse
button.
Notice how nodes with the same node structure were automatically mapped.
The nodes that haven’t yet been mapped will be mapped in later exercises.
2. In the Source Schema, drag a link from the Comment node to the Comment node in
Validate the Map

Procedure List
1. In Solution Explorer, right-click SalesOrder_FF_to_SalesOrder_XML.btm, and then
click Validate Map.
The results of the map validation are displayed in the Output window. Notice
that there are several warnings on the Error List stating that there are required
fields that are missing values. These validation warnings will be resolved with the
additional mappings made in a later exercise.
Test the Map

Procedure List
1. Right-click SalesOrder_FF_to_SalesOrder_XML.btm, and then click Properties.
2. In the SalesOrder_FF_to_SalesOrder_XML.btm properties window, configure the
following properties:
Property Value
TestMap Input Instance C:\AllFiles\LabFiles\Lab3\SalesOrder_FF_Sample.txt
TestMap Input Native
3. Right-click SalesOrder_FF_to_SalesOrder_XML.btm, and then click Test Map.

The errors displayed in the Error List window are expected since the mapping
process isn’t complete. If you do not see the Error List window, click on the View
menu and click Error List.
4. In the Output window, while holding the CTRL key, click the link to the XML instance
to open the resulting XML file (bottom right link following “The output is stored in
the following file:”).
Information from the sample instance has been mapped from the SalesOrder_FF
message type to the SalesOrder message type.
5. Close the XML output message.
Exercise 2: Adding Basic Functoids to a Map
Overview
In addition to copying data between message nodes, maps can contain functoids that
perform data manipulation. In this exercise, you will add functoids to the map to manipulate
data from a source message to a destination message.
Create a New Map Page

Procedure List
1. Below the Map grid, right-click the Links tab (at the bottom of the map), and then
click Add Page.
2. Rename Page 2 to Functoids.
Convert a String to Uppercase

Procedure List
1. If the Toolbox is not already docked on the left side, on the View menu, click
Toolbox.
2. From the String Functoids section of the Toolbox drag, the Uppercase functoid on to
the Map grid.
To move the functoid to a different position on the map grid, click the functoid to
select it (it will be highlighted with a blue box), then drag and drop it to the new
position. Click anywhere else in the mapper to unselect the functoid.
3. In the Source Schema, click the Cash_Cred field, and then drag a link to the
Uppercase functoid in the Map grid.
4. In the Map grid, click the Uppercase functoid, and then drag a link to OrderType
node in the Destination Schema.
The functoid must not be selected (i.e. it must not be highlighted with a blue box)
when dragging it to create a new link.
Specify the Current Date for the Order

Procedure List
1. From the Date/Time Functoids section of the Toolbox, drag the Date functoid on to
the Map grid.
2. In the Destination Schema, click the OrderDate field, and then drag a link to the
Date functoid in the Map grid.
Multiply Two Fields from the Source Schema to a Single Field in the Destination
Schema
Procedure List
1. From the Mathematical Functoids section of the Toolbox, drag the Multiplication
functoid on to the Map grid.
2. From the Cumulative Functoids section of the Toolbox, drag the Cumulative Sum
Because functoids must link left to right, you must drag the Cumulative Sum
functoid to the right of the Multiplication functoid.
3. In the Source Schema, click the Quantity field, and then drag a link to the
Multiplication functoid in the Map grid.
4. In the Source Schema, click the PriceEach field, and then drag a link to the
5. In the Map grid, click the Multiplication functoid, and then drag a link to the
ExtendedPrice node in the Destination Schema.
Cumulative Sum functoid.
7. In the Map grid, click the Cumulative Sum functoid, and then drag a link to the
Order Total node in the Destination Schema.
Specify a Constant Value for the Loan Term

Procedure List
1. From the String Functoids section of the Toolbox, drag the String Concatenate on to
the Map grid.
2. In the Map grid, click the String Concatenate functoid, and then drag a link to the
TermOfLoan node in the Destination Schema.
3. In the Map grid, double-click the String Concatenate functoid.
4. In the Configure String Concatenate Functoid dialog box, click “Edit the selected
constant input” (the button with the pencil icon), and enter 6 as the value.
5. Click OK.
Exercise 3: Adding Database Functoids to a Map
Overview
It is often necessary to insert data into a message from an outside data source, such as a SQL
Server database. In this exercise, you will use functoids to retrieve information from a SQL
database and insert it in the destination message.
Create Links to the Database Lookup and Value Extractor Functoids

Procedure List
1. Drag the Uppercase functoid from the Toolbox to the Map grid.
2. In the Source Schema, click the ID field, and then drag a link to the Uppercase
functoid in the Map grid.
3. From the Database Functoids section of the Toolbox, drag the Database Lookup
Because functoids must link left to right, you must drag the Database Lookup
functoid to the right of the Uppercase functoid.
4. Drag a link between the Uppercase functoid and the Database Lookup functoid.
5. Right-click the link between the Uppercase and Database Lookup functoids, and
then in the Properties window, in the Label box, type CustomerID.
6. Drag four Value Extractor functoids, and then line them up vertically to the right of
the Database Lookup functoid.
7. Drag a link between the Database lookup functoid and each of the Value Extractor
functoids (four separate links).
8. Drag a link between the first Value Extractor functoid to the Street field under the
Billing Address record.
9. Drag a link between the second Value Extractor functoid to the City field under the
10. Drag a link between the third Value Extractor functoid to the State field under the
11. Drag a link between the fourth Value Extractor functoid to the PostalCode field
under the Billing Address record.
Configure the Database Lookup and Value Extractor Functoids

Procedure List
1. Double-click the Database Lookup functoid.
2. In the Configure Database Lookup Functoid dialog box, notice that Input[0] is the link
from the Uppercase functoid. Double-click on each of the following Input
Parameters, and enter the following values:
Input Parameter Value
Input[1] Provider=SQLOLEDB.1;Integrated Security=SSPI;Persist Security Info=False; Initial
Catalog=AdvWorks;Data Source=(local)
Input[2] CUSTOMER
Input[3] CUSTID
The first parameter is the SQL connection string to access the AdvWorks
database. The Second parameter specifies the database table you’re looking up.
The third parameter specifies the column in the table you’re looking up.
3. Click OK.
4. Double-click each Value Extractor functoid, notice that Input[0] is the link from the
Database Lookup functoid, then set the appropriate value for Input[1], as shown in
the table below:
Functoid Value for Input[0]
First Value Extractor Functoid ADDRESS
Second Value Extractor Functoid CITY
Third Value Extractor Functoid REGION
Fourth Value Extractor Functoid ZIP
Each one of these parameters specifies the column from the database from
which the data will be mapped. These functoids will look up the CUSTID field in
the source schema in the AdvWorks database. If the CUSTID exists, the
associated values in the ADDRESS, CITY, REGION, and ZIP columns will be
mapped to the Street, City, State, and PostalCode fields in the destination
schema.
Validate and Test the Map

Procedure List
1. In Solution Explorer, right-click SalesOrder_FF_to_SalesOrder_XML.btm, and then
click Validate Map.
The results of the map validation are displayed in the Output window. Notice, in
the Error List window, the validation errors you received earlier are no longer
returned.
A link to the XML instance is shown in the Output window.
3. In the Output window, while pressing the CTRL key, click the link to open the output
XML file (bottom right link).
4. Examine and then close the order.
The Street, City, State, and PostalCode fields are retrieved from the database and
inserted in the destination message.
Module 4: Deploying and Managing BizTalk
Applications
Module objective:
In this module, you will learn:
How Microsoft BizTalk Server applications are deployed, and how to use the tools provided by
BizTalk Server to manage the applications after deployment.
Overview
Microsoft BizTalk Server 2010 includes features that simplify the management and
deployment of BizTalk applications. BizTalk provides an application container for the items in
a business solution. The items that can be grouped as an application include orchestrations,
schemas, maps, pipelines, and Microsoft .NET assemblies. You can manage, modify, deploy,
and install all of the items in an application as a single entity.
Lesson 1: Deploying a BizTalk Application
Lesson objective:
Describe how BizTalk deployment works, and the steps required to deploy a BizTalk application.
Lesson Overview
This lesson provides an overview of BizTalk application deployment and the steps required
to deploy a BizTalk assembly.
A BizTalk Server assembly contains BizTalk artifacts, such as schemas, maps, and pipelines,
which are used for processing and transforming messages through BizTalk Server. For these
artifacts to be available to other processes and components of BizTalk Server, the BizTalk
Server assembly must be deployed first.
Deploying and managing BizTalk artifacts, such as schemas, maps, and orchestrations, can
become cumbersome as the number of artifacts and assemblies increase. To address the
management and deployment issues of large scale integrations, BizTalk Server 2010
supports the concept of a BizTalk application. BizTalk applications allow developers and
administrators to manage, package, and deploy multiple BizTalk artifacts to other physical
environments much more easily.
How Deployment Works
Describe the process of deploying a Microsoft BizTalk Server assembly.
Deploying BizTalk Assemblies

After you have used Microsoft Visual Studio® to compile your BizTalk project into an
assembly, you can use Visual Studio to deploy the assembly as well. Deploying a BizTalk
assembly involves two steps:
1. Installing the assembly (a DLL) into the global assembly cache (GAC)
2. Registering the assembly in the BizTalk Management database
Any assemblies containing BizTalk artifacts must be registered in the BizTalk Management
database, because BizTalk Server needs efficient access to the details each artifact at run
time. When a purchase order message arrives at a receive location, for example, BizTalk
needs to perform a look-up to determine which assembly holds the schema for the purchase
order message type.
Because BizTalk assemblies need to be deployed to the GAC, they will also need to be
assigned a strong name. Assigning a strong name to an assembly will be covered later in this
module.
Non-BizTalk Assemblies
Any assemblies in the BizTalk solution that do not contain BizTalk artifacts need to be
installed only in the GAC. A non-BizTalk assembly might contain items such as HTML files,
XML files, forms, Microsoft .NET helper classes, or ASPX pages.
What Is a BizTalk Application?
Define the BizTalk Server application concept.
Overview
In BizTalk Server 2010, an application is a logical grouping of all the compiled BizTalk artifacts
(schemas, maps, pipelines, and orchestrations), messaging components (receive ports,
receive locations, and send ports), and other related items, such as business rule policies
that comprise an integrated business process.
The BizTalk Server administration and monitoring tools take advantage of this concept,
allowing IT administrators to work more efficiently by managing and configuring BizTalk
solutions at the application level, rather than being required to work at the individual
artifact level.
A BizTalk application does not define which Windows process hosts its artifacts or .DLLs, it is
simply a logical grouping of artifacts and .DLLs that are deployed and operate together at
run-time. The BizTalk Administration Console, for example, allows you to start and stop all
of the artifacts within a given application by simply commanding the BizTalk application to
start and stop, rather than always requiring you to start and stop each artifact individually.
As the number of complex applications increases, they can be individually managed in a
simple and intuitive manner.
Default Application
When BizTalk Server 2010 is configured following installation, a default application named
“BizTalk Application 1” is automatically created. You can change or rename the default
application.
Artifacts are automatically added to the default application in the following situations:
 When you deploy an assembly from Microsoft Visual Studio® 2010 into BizTalk
Server without specifying an application name.
 When you use BTSTask to add an artifact to an application without specifying an
application name.
Application Deployment Steps
Describe the steps required to create and configure a BizTalk application.
BizTalk Project Deployment Properties

After the BizTalk solution has been designed and built, you must configure specific
properties in order to treat the solution as a separate BizTalk application. The application
deployment steps include:
 Configuring a strong-name assembly key for each project in the Visual Studio
Solution. All assemblies used by a BizTalk application must be assigned a strong-
name key, even if they do not contain BizTalk artifacts.
 Setting the application deployment properties for each project, including the
Redeploy option and the Application Name property.
 Building the Visual Studio Solution that contains the application’s BizTalk projects
and any other application-related assembly projects.
 Using the Deploy command in Microsoft Visual Studio to build the BizTalk assembly
for the project and deploy it into a BizTalk application. Alternatively, you can use the
Deploy command at the solution level to build and deploy all of the assemblies in
the solution. You can also use the BTSTask command to deploy the application from
a command line.
Note: a single assembly with the same version number cannot be deployed
twice. Consequently, you might have to un-deploy one or more assemblies
before proceeding. The Visual Studio Redeploy option is designed to automate
this step.
 Configuring the application in BizTalk Administration Console, including configuring
receive and send ports, host and port bindings for orchestrations, and defining
message filters.
 Starting the ports, then enlisting and starting the orchestrations.
After testing the application and making the necessary changes, you can use the Deploy
command in Visual Studio to rebuild and redeploy the final assembly into the BizTalk
Configuration database. This will work only if the Redeploy option is set to true for every
BizTalk project in the Solution.
If multiple computers running Microsoft BizTalk Server share a BizTalk Configuration
database, then the assembly needs to be installed to the GAC of each computer that will
hosting the application.
Note: Creating receive locations and send ports and working with orchestrations will be
covered in more detail in Module 5: “Routing BizTalk Messages.”
How BizTalk Uses Strong Names
Explain the importance of using assemblies with strong names.
Introduction
Each assembly in your project must have a strong name to deploy successfully. A strong
name consists of the assembly’s identity (text name, version number, and culture
information if available), plus a public key and digital signature. When you sign an assembly
with a strong name, you ensure that the name is globally unique. Referencing a strong-
name-signed assembly gives you certain benefits, such as versioning and naming protection,
and strong-name-signed assemblies can reference only other strong-named assemblies.
Strong names satisfy the following requirements:
 Uniqueness. Strong names guarantee name uniqueness by relying on unique key
pairs. No one can generate the same assembly name that you generate because any
assembly name generated by using one private key has a different name than any
assembly generated by using another private key.
 Versioning. Strong names protect the version lineage of an assembly. A strong name
can ensure that no one can produce a subsequent version of your assembly. Users
can be sure that the assembly version that they are loading originates from the same
publisher that created the original version of the built application.
 Integrity. Strong names provide a strong integrity check. Passing the Microsoft .NET
Framework security checks guarantees that the contents of the assembly have not
been changed since it was built. However, strong names do not imply the level of
trust provided by a digital signature and supporting certificate.
Configuring BizTalk Deployment Properties
Configure the application properties for the application’s projects.
Deployment Properties
When you are ready to deploy your application, you set deployment properties for the
Visual Studio project. Some of the properties are optional depending on how you plan to
deploy the application.
 Server. This is the name of the Microsoft SQL Server™ instance that hosts the BizTalk
Management database on the local computer. In a single-computer installation, this
is usually the name of the local computer.
 Configuration Database. This is the name of the BizTalk Configuration database for
the BizTalk group to which you will be deploying your assembly, for example,
BizTalkMgmtDb.
 Application Name. This is the name of the BizTalk application to which you will
deploy the assemblies in this project. If the application already exists, the assemblies
will be added to it when you deploy the project. If the application does not exist, the
application will be created in the BizTalk management database specified earlier. If
this field is blank, the assemblies will be deployed to the default BizTalk application
in the current group, “BizTalk Application 1,” by default. Names that include spaces
must be enclosed by double quotation marks (“”).
 Redeploy. (True or False) Setting this option to True (the default) enables you to
redeploy the BizTalk assemblies without changing the version number.
 Install to Global Assembly Cache. (True or False) Setting this option to True (the
default) installs the assemblies to the Global Assembly Cache (GAC) on the computer
specified in the Server property. Set this property to False only if you plan to use
other tools for this installation, such as gacutil.
BizTalk Application Deployment Tools
Describe the three BizTalk deployment options.
Introduction
You can use any of several methods to deploy a BizTalk Server assembly to the BizTalk
management database. These methods include tools for use by developers and IT
professionals.
Visual Studio
Using Visual Studio, you can deploy or redeploy the assemblies in your BizTalk projects. This
method is most useful to developers when deploying an application to a test environment.
From within Visual Studio 2010, you can either deploy each assembly in your solution
separately or deploy all assemblies in a solution at the same time by deploying the entire
solution. The redeploy option allows you to deploy a new assembly with the same name and
strong name key without un-deploying the original assembly.
Command-Line Deployment Tool

In a production environment that includes multiple computers running BizTalk Server, an
assembly needs to be deployed to the BizTalk Configuration database only once. However,
each computer running BizTalk Server that uses the assembly must have that assembly
registered in the GAC. An administrator can do this by using the BTSTask command-line tool.
BTSTask can also be used to import and export a binding file to simplify deployment. A
binding file contains all of the configuration information required to start a BizTalk
application.
BizTalk Administration Console
The BizTalk Administration Console enables you to manage the BizTalk Configuration
database. The console can be used to create, configure, and start ports; bind orchestrations;
and add or remove assemblies from the application. The BizTalk Administration Console also
provides the ability to export BizTalk applications into a Microsoft Windows Installer (MSI)
package for deployment to other computers. This increases the efficiency of migrating a
BizTalk application through development, testing and production environments. It also
eases scale-out of a BizTalk group when an application’s artifacts need to be installed on the
new servers.
Demo: Deploying the Adventure Works Application
In this demonstration, you will see how to assign a strong name and application name to a
project. You will then see how to build and deploy the project.
Assign a Strong Name Key to an Assembly

1. In Windows Explorer, navigate to C:\AllFiles\DemoCode\Module4\AdvWorks, and
then double-click AdvWorks.sln to open the Visual Studio solution.
2. In Solution Explorer, right-click the Messaging project, and then click Properties.
3. In the Messaging project properties window, click the Signing tab.
4. Check the Sign the assembly check box, then select <Browse…> from the Choose a
strong name key file drop-down list.
5. Browse to C:\AllFiles\DemoCode\Common, and then double-click Demos.snk.
Configure the Application Deployment Property

1. In the Messaging project properties window, click the Deployment tab.
2. In the Application Name field, type AdventureWorks.
The deployment and signing properties have already been configured for the
Processes project.
Build the Solution

1. In Solution Explorer, right-click the AdvWorks solution, and then click Build Solution.
2. Verify in the Output window that the build completed successfully.
3. In Windows Explorer, navigate to
C:\AllFiles\DemoCode\Module4\AdvWorks\Messaging\bin\Deployment.
4. Notice the AdvWorks.Messaging.dll file.
This is one of the BizTalk assemblies that will be deployed to the BizTalk
Configuration database and installed in the global assembly cache.
5. Close Windows Explorer.
Deploy the Solution

1. In Solution Explorer, right-click the AdvWorks solution, and then click Deploy
Solution.
When a BizTalk solution is deployed using Visual Studio, the build process is
automatically initiated. If the assembly is up to date, it is not replaced.
2. In the Output window, verify that the project deployment succeeded.
View the Application in the BizTalk Server Administration Console

1. Start the BizTalk Server Administration Console.
2. In the BizTalk Server Administration Console, expand BizTalk Server Administration,
BizTalk Group, Applications, and AdventureWorks, and then click Resources.
Notice that the Messaging, and Processes assemblies are deployed to the
AdventureWorks application. If the BizTalk Server Administration Console was
already running, you must refresh Applications.
3. Pause the bt10d-demo virtual machine.
Lesson 2: Managing BizTalk Applications
Lesson objective:
Describe the application management tools available to BizTalk developers.
Lesson Overview
After an application is deployed to the BizTalk Server runtime environment, developers and
administrators will need to manage and maintain the application. BizTalk Server provides a
number of management features that are available through the BizTalk Administration
Console, and also through a command-line tool named BTSTask.exe.
Managing Apps with the BizTalk Administration Console
Describe the application management features provided by the BizTalk Administration Console.
The BizTalk Administration Console

The BizTalk Server Administration Console is a Microsoft Management Console (MMC) that
you can use to manage and monitor BizTalk Server, and that you can use to deploy and
manage your BizTalk Server applications.
The console tree in the left pane consists of folders and subfolders that represent different
types of artifacts that you can manage. The right pane displays details of a selected artifact.
You can perform the following application deployment and management tasks using the
BizTalk Server Administration console:
Applications
• Import and export applications and binding files
• Configure applications
• Start and stop applications
• Add resources to applications
Orchestrations
• Bind orchestrations to send and receive ports and host, or remove these bindings
from the orchestration.
• Enlist and unenlist orchestrations.
• Start or stop orchestrations.
Send ports and Send port groups
• Create and configure send ports and send port groups .
• Enlist and unlist send ports and send port groups .
• Start and stop send ports and send port groups .
Receive Ports and Receive Locations

• Create and configure receive ports and receive locations
• Enable and disable receive locations
• Delete a receive port
Policies
• Import and export Business Rule Engine policies
• Assign a policies applications, and remove a policies from applications
• Publish, deploy and un-deploy a policies
Schemas
• View the schemas for an application
• Remove schemas from an Application
Maps
• View the maps for an Application
• Remove maps from an Application
Pipelines
• View the pipelines for an application
Resources
Resources are any application files that should be included when an application is migrated
to another server. Resources can be scripts, BizTalk assemblies, pre- and post-processing
deployment scripts, .NET assemblies, COM components, certificates, ad-hoc files, BAM
definitions, binding files and virtual directories. The BizTalk Administration Console provides
features to perform the following tasks.
• Add and remove resources
• Modify deployment information of a resource
• Move a resource to another application
Exporting and Importing a Binding File
Use binding files to export and import binding files.
What Is a Binding File?

A binding file is an XML file that contains configuration information for each BizTalk
orchestration, pipeline, map, or schema in a BizTalk assembly, application, or group. The
binding file describes each host, send port, send port group, receive port, receive location,
and party that has been configured, along with all of its settings. However, any password
information is removed and will have to be reentered to import the application. You can
generate binding files and then apply the bindings they contain to an assembly, application,
or group to avoid needing to manually configure bindings in different deployment
environments.
Moving from One Environment to Another

You can use binding files to make it easier to move an application from one deployment
environment to another, such as from a development environment to a test environment.
This is because bindings between logical orchestration ports and physical ports often must
be reconfigured for different deployment environments. But by using binding files, you can
avoid manual configuration steps.
One way you can do this is to create a library of bindings from which to select when
deploying the application into a new environment. For example, you can create a binding file
for your test environment and another one for your production environment and then add
them both to the application. When you import the application into the test environment,
you can select an option to apply the test bindings. Likewise, when you import the
application into the production environment, you can select an option to apply the
production bindings. This avoids the need to reconfigure bindings manually for different
environments. Another way is to import bindings that you have created for the current
environment after importing the application into it. This automatically applies the bindings.
Exporting Bindings
You can export bindings for a BizTalk group, assembly, or application to an XML file. A
binding file contains information about hosts, send ports, send port groups, receive ports,
receive locations, parties and their associations with BizTalk assembly orchestrations,
pipelines, maps, and schemas. Binding files are usually specific to a particular version of an
assembly, so be careful if a version of an assembly has been updated. You may need to
update the binding file with the new version, or you may need to create a new binding file,
depending on what has changed since the version has been updated. You can then import
the bindings from the XML file into another group or application. Importing bindings
overwrites any existing bindings in the group or application. You can also add bindings to an
application.
Migrating Applications Using MSI Packages
Explain how applications are deployed by using Microsoft Windows Installer (MSI) packages.
Introduction
BizTalk Server allows entire solutions to be packaged, using the Microsoft Windows Installer
technology, into MSI package files.
MSI Packages
The MSI package contains all of the binaries and configuration information (bindings)
needed to install the application on another system. After it is installed, the MSI package
creates entries in the Add or Remove Programs list on the computer running BizTalk Server.
This allows administrators to manage BizTalk applications in the same way as other
applications running on the computer. Using an MSI package to install a BizTalk Server
application is beneficial for developers because they can control what is included and
deployed with the MSI package, and developers can easily hand off MSI packages to
administrators. MSI packages provide administrators with a GUI interface or the ability to
install in “quiet mode.” Because the application is then registered in the Add or Remove
programs list, if an application needs to be removed, it can be done easily by an
administrator.
Exporting a BizTalk application generates a Windows Installer (MSI) file that contains the
application and some or all of its artifacts. When you export an application, you can select
which of its artifacts to export. The default option is to select all of the application’s artifacts,
but you can select a subset of them. You can later import the MSI file into another BizTalk
group to add the artifacts to an existing application in the new group, update the artifacts in
an existing application, or create a new application in the group that contains the artifacts
being imported.
You can import BizTalk applications, bindings, and policies into a BizTalk group. Exporting an
application creates an MSI file that you can then use to import the application’s artifacts into
an application in a different BizTalk group. If the application that you specify for the import
does not already exist in the group, the application is created. In addition, the application’s
artifacts are registered and their data stored in the BizTalk databases of the group.
Since the application’s assemblies must be installed in the GAC on any BizTalk server that
will host the application, you must run the MSI on each server in the BizTalk group to
complete the import.
Managing Applications from a Command Prompt
Manage applications from the command prompt.
Using BTSTask
The BizTalk Server command-line tool, BTSTask.exe, supports the application deployment
and management features of BizTalk Server. It enables you to perform many of the same
tasks that you can perform by using the BizTalk Server Administration Console. Using
BTSTask.exe, you can:
 Add a BizTalk application to the BizTalk Configuration database.
 Add an artifact, such as an orchestration or a schema, to an application.
 Export an application to an MSI file, allowing you to then deploy the application to
another physical computer.
 Export binding information to a file, thus saving current binding information for
exporting to another physical computer.
 Import an application from an MSI file.
 Import binding information from a file, such as from a previously created XML
binding file.
 List the artifacts included in an application, such as the schemas, maps, and
orchestrations included in a specific application.
 List all applications in the BizTalk Configuration database for the BizTalk group.
 List the resources in an MSI file, such as binding files, BizTalk artifacts, and
messaging components such as receive and send ports.
 List all of the artifact types supported by BizTalk Server.
 Remove an application from the BizTalk Configuration database and the BizTalk
Server Administration Console.
 Remove an artifact from an application, such as a schema or a map.
 Remove an application from the specified computer.
Managing Project Versioning
Manage different versions of assemblies
Project Versioning
With prior versions of BizTalk, the process of versioning a BizTalk Server application was
cumbersome. Because an assembly cannot be changed after it has been deployed to the
BizTalk Configuration database or to the GAC, you must be careful when deciding which
BizTalk artifacts must reside in each assembly. If you put each artifact in its own assembly,
management can become difficult because you may end up with dozens or even hundreds
of different assemblies. However, if you put too many artifacts into a single assembly and
then need to change just one artifact, such as a map or an orchestration, you will have to
redeploy and reversion the entire assembly even though only one or two artifacts have been
changed.
A good guideline to use when versioning BizTalk assemblies is to group BizTalk artifacts
together that will be versioned together. For example, if you have a map that depends on a
certain schema that might change over time, group the schema and the map together in the
same assembly. If an orchestration also depends on this map, consider putting the
orchestration in the same assembly as well.
Since BizTalk Server determines which schema a message is an instance of using the
combination of the root node name and target namespace of the schema and message, you
cannot have multiple schema versions deployed that have identical root node names and
target namespaces. For this reason, you will have to change the target namespace of each
schema deployed.
Some other things to consider when versioning assemblies:
 Verify that an existing version of the assembly is not already deployed. If there is an
existing version, compare its version number with the version number of the new
assembly. If the numbers are identical, the deploy operation will fail. If the version
numbers are different, the assembly will deploy. The two deployed assemblies will
be recognized as separate entities.
 Apply the binding file (if specified in the command) to the ports in the deployed
orchestrations, and then install the assembly in the GAC on the local computer.
Binding files contain the assembly name, version, public key token, and the assembly
culture, so if a version of an assembly changes, you may need to change the binding
file to reflect the new version. Or you can always create a new binding file by using
the BizTalk Server Administration Console that will reflect the newest version
information.
 Before you remove a BizTalk assembly from the management database, you must
ensure that any orchestrations used in the assembly are not enlisted to receive data.
If any orchestration is enlisted, the removal will fail. Using the BTSTask command-
line tool with the RemoveResource option will remove the assembly from the
BizTalk Management database and, optionally, from the GAC on the local computer.
Demonstration: Managing the Adventure Works Application
Learn to use a binding file, export an application, and how to use BTSTask to remove an
application.
Import a Binding File Using the BizTalk Administration Console

1. Resume the bt10d-demo virtual machine
BizTalk Group, Applications, and AdventureWorks, and then click Send Ports.
Notice that there are no send ports. The application is also void of receive ports
and receive locations.
3. Right-click AdventureWorks, point to Import, and then click Bindings.
4. In the Import Bindings dialog box, navigate to C:\AllFiles\DemoCode\Module4, and
then open AdventureWorks.Bindings.xml.
Notice that there are now send ports, receive locations, and receive ports in the
AdventureWorks application.
Start the Application
1. Right-click AdventureWorks, then click Start
2. Click Options.
Notice the options for choosing which parts of the application should be started.
3. Click Start.
Notice that the orchestration and send ports are started, and the receive location
is enabled.
Stop the Application

1. Right-click AdventureWorks, then click Stop.
Notice the options for choosing which parts of the application should be stopped.
2. Click the Full Stop radio button, and then click Stop.
Notice that the orchestration and send ports are stopped, and the receive
location is disabled.
Export the Application to an MSI Package

1. In the BizTalk Server Administration Console, right-click AdventureWorks, point to
Export, and then click MSI file.
2. On the Welcome page of the Export MSI File Wizard – AdventureWorks, click Next.
3. Examine the information contained on the Select Resources page, and then click
Next.
4. On the Specify IIS Hosts page, click Next.
5. Examine the information contained on the Dependencies page, and then click Next.
6. On the Destination page, in the Destination application name box, type
AdventureWorks, and then click the ellipsis (…) button.
7. In the Export MSI File dialog box, navigate to C:\AllFiles\DemoCode\Module4, in
the File name box, type AdventureWorks, and then click Save.
8. Click Export.
9. Examine the information contained in the Results section on the Summary page,
and then click Finish.
Remove the Application by Using a Command Prompt

1. On the Start menu, click Run.
2. In the Run dialog box, type cmd, and then click OK or press ENTER.
3. In the command prompt window, type BTSTask /?, and then press ENTER.
Notice that this is the list of BTSTask commands that can be used from the
command prompt.
4. In the command prompt window, type BTSTask ListApps, and then press ENTER.
Notice the applications listed.
5. In the command prompt window, type BTSTask RemoveApp -ApplicationName:
“AdventureWorks”, and then press ENTER.
Notice that the AdventureWorks application is not listed.
BizTalk Hosts and Host Instances
Understand the concepts behind the BizTalk Server hosting model.
BizTalk Server Hosting Model

BizTalk Server provides scalability and reliability through hosts. Hosts provide a logical
container for BizTalk execution. Host instances are concrete instances of a host
configuration. Orchestrations and adapters can be configured to run in specific hosts.
A BizTalk host is a logical definition of a hosting process. Host configuration settings define
security properties (e.g. Windows groups, certificate), and they determine whether or not
tracking services may execute.
There are two types of BizTalk hosts:
• In-Process – The host represents instances of a Windows Service
• Isolated – The host represents some other type of process (e.g. IIS)
A BizTalk host instance is a physical instance of a host on a specific server. A host instance
must run as a member of the Windows group for the host. Only one instance of a given host
may execute per server.
BizTalk Hosts and Host Instances
Understand the concepts behind the BizTalk Server hosting model.
BizTalk Server Hosting Model
Orchestration and Adapter Management

You can use hosts to isolate adapters onto their own servers. Distributing adapters across
multiple servers allows you to scale sending and receiving functionality. You may also use
hosts to isolate long running or processor intensive orchestrations. Assigning multiple host
instances to a host provides failover across several servers in the group. Send adapters
running in multiple host instances balance automatically across instances. Balancing receive
adapters depends on the transport.
Listening adapters (e.g. HTTP, WCF) simply use existing load balancing hardware and
software as normal. Be sure, however, to host these adapters on all servers in the load
balancer pool. Pull adapters require locking semantics to avoid duplication or corruption.
The FILE adapter is a good example.
Some adapters cannot be load balanced. Windows clustering, however, provides a way to
meet availability requirements. The MSMQ, FTP, and POP3 adapters commonly need to be
hosted on a Windows cluster. The MSMQ adapter may be clustered with an MSMQ service
cluster (local tx reads only). The POP3 adapter does not need to be hosted on a Windows
cluster if the POP3 server allows multiple concurrent connections.
Hosts act as security boundary

A BizTalk host serves as a container for certificate configuration. The certificates configured
within a host can be used to identify the sender of an inbound message. The certificates can
also be used to sign or encrypt outbound messages.
Trusted vs. Untrusted Hosts:
A BizTalk Host must be configured as trusted in order to write a sender’s identification
information to a message’s context. If the message will be routed through components
running in other hosts, the subsequent hosts must be configured as trusted to see the
sender’s identification information.
Lab: Deploying and Managing BizTalk Applications
Time estimate: 30 Minutes
Scenario
All assemblies used by BizTalk Server applications (including non-BizTalk .NET assemblies)
must be in the Global Assembly Cache (GAC) of the computer(s) running BizTalk Server.
Additionally, all BizTalk assemblies must be registered in the BizTalk configuration database.
In this lab, you will prepare a BizTalk assembly to be deployed by assigning a strong name
key an application’s projects. You will then deploy the assembly, and use the BizTalk Server
Administration Console to import a binding file to complete the configuration. You will then
export the new, configured application to an MSI file. You will move all of the application’s
resources to a new application, export it with BTSTask.exe, and then delete the application
from the BizTalk Server Configuration database.
Procedure List
window.
Start.

Procedure List
2. Double click on startBtServices.cmd.
Exercise 1: Assign a Strong Name Key to an Assembly
Overview
All BizTalk Server assemblies must be signed with a strong name key before being deployed.
In this exercise, you will create the strong name key that will be used to sign your
assemblies, and then assign the strong name key to the Messaging project.
Assign a Strong Name Key to the Messaging Project

Procedure List
1. In Windows Explorer, navigate to and open the solution
C:\AllFiles\LabFiles\Lab4\AdvWorks\AdvWorks.sln.
3. In the Signing tab of the Messaging project properties window, scroll down to the
bottom, and check the Sign the assembly check box.
4. From the Choose a strong name key file drop-down list, choose <Browse…>,
navigate to C:\AllFiles\LabFiles\ Common\AdvWorks.snk, then click Open.
5. Close the Messaging project properties window.
6. Repeat steps 2 through 5 for the Processes project.
Exercise 2: Configuring the Application Deployment Property
Overview
Applications provide a means to group ports, business rule policies, and BizTalk assemblies
with their contained artifacts, and non-BizTalk artifacts for easy administration. Each BizTalk
project can be configured to deploy to a specific application. In this exercise, you will
configure the application deployment property for two BizTalk projects.
Configure Each Project to Deploy to the AdvWorks Application

Procedure List
1. In Solution Explorer, right-click Messaging, and then click Properties.
2. In the Messaging property pages window, click the Deployment tab, and in the
Application Name box, type AdventureWorks
3. Repeat steps 2 and 3 for the Processes project.
5. On the Window menu, click Close All Documents.
Solution.
Visual Studio understands project dependencies and will automatically build and
deploy any projects in the same solution that the Processes project depends on.
Exercise 3: Building and Deploying a BizTalk Application
Overview
Building a BizTalk Server 2010 project compiles a .NET assembly. After the assembly is
compiled, it must be deployed to the GAC of the computer(s) running BizTalk Server, and it
must be registered with the BizTalk configuration database. In this exercise, you will build
and deploy a BizTalk Server 2010 application.
Build and Deploy the Application

Procedure List
1. In Solution Explorer, right-click the AdvWorks solution, then click Build Solution.
C:\AllFiles\LabFiles\Lab4\AdvWorks\Messaging\bin\Deployment.
Notice that AdvWorks.Messaging.dll has been created.
Solution.
Notice in the status bar (bottom left) that the Deploy succeeded.
Exercise 4: Managing Ports by Using Binding Files
Overview
Port and orchestration configuration can be managed by using binding files. Binding files
contain information about the relationship between orchestration and logical ports. Binding
files also include all the physical port settings, such as pipelines, adapter configuration, map,
and filters. In this exercise, you will create and manage ports by importing a binding file.
Import a Binding File

Procedure List
1. On the Start menu, point to All Programs, point to Microsoft BizTalk Server 2010,
and then click BizTalk Server Administration.
Notice that there are no send ports, receive ports, or receive locations in the
application.
4. In the Import Binding dialog box, navigate to C:\AllFiles\LabFiles\Lab4, and then
open 4-Lab-Bindingd.xml.
5. In the BizTalk Server Administration Console, under the AdventureWorks
application, click Send Ports, then Receive Ports, and then Receive Locations.
Notice that send ports, receive ports, and receive locations have been added to
the application.
Exercise 5: Managing Applications by Using MSI Packages
Overview
BizTalk MSI packages can contain all of the BizTalk and non-BizTalk assemblies, business rule
policies, associated Web services, and configuration information for an application. In this
exercise, you will create an MSI package for the AdvWorks application. To test the MSI
package, you will delete the AdvWorks application, and then recreate it by importing the
MSI package you created.
Export an Application to an MSI

Procedure List
2. On the Welcome page of the Export MSI File Wizard, click Next.
3. Examine the information on the Select Resources page, and then click Next.
4. On the Specify IIS Hosts page click Next.
5. Examine the information on the Dependencies page, and then click Next.
7. In the Export MSI File dialog box, navigate to C:\AllFiles\LabFiles\Lab4, in the File
name box, type AdventureWorks, and then click Save.
8. On the Destination page, click Export.
9. Examine the information contained in the Results section on the Summary page,
Delete the Application

Procedure List
1. In the BizTalk Server Administration Console, right-click AdventureWorks, click
Delete, and then in the Confirm delete application dialog box, click Yes.
Import an Application from an MSI

Procedure List
1. In the BizTalk Server Administration Console, right-click Applications, point to
Import, and then click MSI file.
2. On the Welcome to the Import Wizard page, click the ellipsis (…) button.
3. Navigate to C:\AllFiles\LabFiles\Lab4, click AdventureWorks.msi, and then click
Open.
4. On the Welcome to the Import Wizard page, click Next.
5. Examine the information on the Application Settings page, and then click Next.
6. On the Application Target Environment Settings page, click Next.
7. Examine the information on the Import Summary page, and then click Import.
8. On the Results page, select the Run the Application Installation Wizard to install
the application on the local computer check box, and then click Finish.
Having this check box selected will start the MSI Installation, which installs the
assemblies contained in the MSI file to the Global Assembly Cache (GAC).
9. On the Select Installation Folder page, click Next.
10. On the Welcome to the Adventure Works Setup Wizard page, click Next.
11. On the Confirm Installation page, click Next.
12. Examine the information on the AdventureWorks Information page, and then click
Next.
13. On the Installation Complete page, click Close.
14. In the BizTalk Server Administration Console, expand AdventureWorks, and then
click Send Ports, Receive Ports and Receive Locations.
Notice that the send ports, receive locations, and receive ports from the
AdvWorks application are in the AdventureWorks application.
15. Click Resources to verify that the resources were imported.
16. Click Orchestrations to verify that the orchestrations were imported.
17. On the Start menu, click Control Panel, and then click Uninstall a program
Notice that the AdventureWorks application appears in the Currently installed
programs list. Removing the application from Add or Remove Programs will
uninstall it from the GAC, but the application will remain in the Configuration
database.
18. Close the Programs and Features window.
Exercise 6: Moving Resources and Ports Between Applications
Overview
Application artifacts (ports, assemblies, policies, etc.) can be moved between applications.
All dependent artifacts will be moved together. In this exercise, you will create a new BizTalk
application, and then move resources and ports to the new application.
Create a New Application

Procedure List
1. In the BizTalk Server Administration Console, right-click Applications, point to New,
and then click Application.
2. In the Application Properties dialog box, in the Name box, type
ExtremeAdventureWorks, and then click OK.
Move Resources and Artifacts Between Applications

Procedure List
1. In the BizTalk Server Administration Console, in the AdventureWorks application,
click Resources.
2. Right-click AdvWorks.Processes, and then click Move To Application.
3. In the Move to Application dialog box, in the Destination application list, click
ExtremeAdventureWorks.
Notice that the send and receive ports that are bound to the ProcessOrder_Cash
orchestration will automatically be moved with it.
4. Examine the information in the Moving Artifacts list, using the scroll bar if
necessary, and then click OK.
5. Right-click AdvWorks.Messaging, and then click Move To Application.
Notice that Resources is now empty.
7. In the BizTalk Server Administration Console, expand ExtremeAdventureWorks, and
then click Resources.
Notice that the AdvWorks.Messaging and AdvWorks.Processes resources have
been moved.
8. Under ExtremeAdventureWorks, click Send Ports.
Notice that the snd_AdvWorks_RestockFILE and
snd_AdvWorks_OrderCompleteFILE send ports have been moved.
Exercise 7: Managing Applications by Using BTSTask
Overview
BTSTask.exe is a command line utility that can be used to create, delete, and manage
applications. In this exercise, you will use BTSTask.exe to view deployed assemblies, create
an MSI package, and delete an application.
View Deployed Applications

Procedure List
Notice that this is the list of BTSTask.exe commands that can be used from the
command prompt.
Export an Application to an MSI Package

Procedure List
1. In the command prompt window, type the following command (all on one line), and
then press ENTER.
BTSTask ExportApp -ApplicationName:“ExtremeAdventureWorks”

-Package:“C:\AllFiles\LabFiles\Lab4\ExtAdvWorks.msi”

Notice that the ExtAdvWorks.msi file now appears in the Lab4 folder.
Delete an Application
Procedure List
3. In the command prompt window, type the following command, and then press
ENTER.
BTSTask RemoveApp -ApplicationName:“ExtremeAdventureWorks”
Notice that the ExtremeAdventureWorks application has been removed.
Module 5: Routing BizTalk Messages
Module objective:
In this module, you will learn the purpose and scope of the Microsoft BizTalk Server publish and
subscribe messaging models and how to configure BizTalk message routing.
Overview
Microsoft BizTalk Server provides a mechanism for routing, processing, and sending
messages between business processes. Content-based routing (CBR) is a method of routing
messages based on the context and/or content of an incoming message. BizTalk provides
two methods of monitoring and tracking message activity, which enables developers,
administrators, and business users to diagnose messaging problems. This module shows you
how to enable message routing and use BizTalk tools to monitor live and archived message
activity.
Lesson 1: Introduction to Message Routing
Lesson objective:
Explain how BizTalk Server 2010 routes and processes messages.
Overview
The BizTalk messaging system consists of components such as receive locations, receive and
send ports, pipelines, and the MessageBox database. The component that is responsible for
the actual message routing process is referred to as the messaging engine. This lesson
provides an overview of how the BizTalk messaging engine works to process messages and
how message routing is enabled.
The Publish and Subscribe Architecture
Describe the publish and subscribe routing model used by BizTalk Server for routing and
processing documents.
The Publish and Subscribe Architecture

BizTalk Server uses a publish and subscribe (or pub/sub) messaging model. The pub/sub
model is highly scalable at both the database and processing levels. This pub/sub routing
mechanism can manage large volumes of messages and large individual messages, and can
interact with a wide variety of back-end systems. This design also makes adding and
changing subscribing components on-the-fly extremely easy.
Publication
Publication is the process by which messages are placed in the MessageBox database. The
principal publishing component in BizTalk Server is the receive port, which receives and
processes messages into the database. Orchestrations also publish messages as they are
sent from the orchestration to the MessageBox database for further routing. Properties
defining which messages will be routed can be promoted as the message is being processed
through receive pipelines and can also be specified in the business process (orchestration)
itself. Each of these processes will be detailed in upcoming modules.
Subscriptions
Subscriptions are criteria on which message routing is determined. Orchestrations, send
ports, and send port groups can each subscribe to messages. Each subscription allows the
subscriber to initiate or continue the processing of a message. Subscriptions are managed by
the MessageBox database.
When a message meets the specifications of a subscription, the message is passed from the
MessageBox database to the subscriber. If multiple subscribers exist for a given message,
each gets a copy of the message.
The preceding illustration outlines the steps in the publish/subscribe model, as follows:
1. Subscriptions are created for each subscriber (send port, send port group, or
orchestration) by configuring a filter expression. For example, this expression could
be for all purchase order messages with totals over $10,000.
2. A message is received, processed, and published to the BizTalk MessageBox
database. Messages can be received through a variety of different adapters,
including File, FTP, and HTTP.
3. Subscriptions, which are maintained by the MessageBox database, are evaluated to
determine which subscriber(s) should receive a copy of the message.
4. Each subscriber will receive a copy of the message (with a unique message ID). The
message stays in the MessageBox database until all subscribers have received and
successfully processed the message.
At each stage in the processing, data necessary for tracking messages is written to a
separate database (the tracking database), where it resides until deleted by administrative
action.
What Is the MessageBox Database?
Explain the purpose of the MessageBox database and how message subscriptions work.
MessageBox Database
The MessageBox database stores messages and message properties, and it maintains
message subscriptions. The messaging engine delivers the messages from the database to
subscribers. The MessageBox databases also store the queues and state tables for each
BizTalk host.
Messages are immutable once they arrive at the MessageBox database, but beforehand,
messages can be manipulated in a variety of ways, including validating the message against a
known schema, promoting specific nodes to be used in message routing, decrypting a
message, or transforming a message by using a BizTalk map. Each of these processes is
addressed in other modules in this course.
Adding MessageBox Databases

MessageBox databases are the basis of work-item load balancing across multiple servers
that perform cooperative processing. With all of the messages and processes that the
MessageBox database is responsible for, it can rapidly become a bottleneck in a BizTalk
environment. To increase the number of messages that your system can process, you may
need to create additional MessageBox databases. With the Enterprise edition of BizTalk
Server 2010, you can use the BizTalk Administration Console to create multiple MessageBox
databases.
When multiple MessageBox databases are in use within a BizTalk Server Group, the master
MessageBox (the first one created) acts only as a router and routes all new messages to the
other message boxes for processing. A degradation of performance can occur when there
are only two MessageBox databases because the messages are still being processed by only
one database since the master database performs only the routing of messages. Therefore,
it is highly recommended that when using multiple MessageBox databases you have at least
three MessageBox databases.
A single computer running Microsoft SQL Server™ can host several BizTalk Server
MessageBox databases before the server becomes overloaded. Determine the performance
impact of the computer running SQL Server when implementing multiple MessageBox
databases. You can designate local and remote databases as MessageBox databases. Verify
that the SQL Server Agent is running on all computers running SQL Server before adding a
new MessageBox database so that database maintenance tasks are performed.
Note: Refer to the “How to Add a New MessageBox Database” and “Creating a Highly
Available BizTalk Server Environment” topics in the Microsoft BizTalk Server 2010
documentation for more information about adding MessageBox databases.
Disabling New Message Publication

As noted, several separate MessageBox databases can receive and store (publish) messages
at any time. If it is necessary to delete or move a MessageBox database, you should first
disable new message publication. Also, if you have multiple MessageBox databases, the
master database may experience an improvement in performance if new message
publication is disabled on the master MessageBox database. Disabling new message
publication does not affect existing messages because any existing messages stay in the
original MessageBox databases. You can use either the BizTalk Administration Console or
Microsoft Windows Management Instrumentation (WMI) to disable new message
publication.
Deleting MessageBox Databases

Situations may arise in which you want to delete a MessageBox database from a BizTalk
group. For example, you might want to delete a MessageBox used for a series of tests now
concluded. You can use either the BizTalk Administration console or WMI to delete a
MessageBox database. Deleting a MessageBox database from a BizTalk Group does not
actually remove the database from SQL Server. To remove the MessageBox database
completely and permanently, you must remove it by using SQL Server Enterprise Manager
after it is removed from the BizTalk Group.
What Is Message Routing?
Describe the concept of message routing.
Message Routing
A typical BizTalk Server business process involves receiving, processing, and sending
messages. At times, you may receive messages (such as partner-to-partner correspondence)
that do not require intensive processing in an orchestration, and that could therefore
benefit from a simpler solution. The BizTalk content-based message routing model provides
great flexibility in the way that messages are handled. For example, two incoming messages
of the same type can be processed differently based on a customer name or a total order
amount.
Scenario
One common scenario that requires message routing is when a receive port is configured to
receive a single message type, as in the case of a purchase order (PO). Assume that you have
created a send port to an ERP system and that you have configured a map that needs to
receive a copy of all POs. You can configure the filter on the send port to process all
messages received through the specified receive port. Additional send ports and filter
expressions could be added to route messages based on other properties.
Examples
The preceding illustration shows three send ports, each with a different filter for content-
based routing. All PO messages in which the CustomerName field contains Contoso are to be
routed to send port A. All messages with the Price field greater than 1000 are routed to send
port B. All messages with a quantity greater then 500 and in which the Price is less then
1000 (which may represent an error condition) are routed to send port C. A message is
routed to all send ports for which it meets the filter criteria. Therefore, if a PO is received
from Contoso, in which the Price is over 1000, a copy of the message is routed to both send
ports A and B but not send port C.
What Is a Port?
Describe how BizTalk Server uses receive ports and locations to receive messages and how it
uses send ports to send messages.
Ports
Ports specify how messages are sent and received inside BizTalk Server, as well as between
BizTalk Server and external processes. Each port has a direction, a transport type, and a
binding, which together determine the direction of communication (one-way or two-way),
the pattern of communication (one-way or request-response), the location to or from which
the message is sent or received, and how the communication takes place. A port’s binding
may refer to the physical location of a read or write, the pipeline used for message
processing, or an orchestration.
A port must be associated with:
 A Universal Resource Identifier (URI—a physical location).
 A transport (examples are File, HTTP, and BizTalk Message Queuing).
A port may be associated with:
 A send pipeline, to prepare a message for sending. For example, pipelines can be used
for assembling, encrypting, compressing, or performing some other action on a
message.
 A receive pipeline, to prepare a received message for processing. For example, receive
pipelines can be used for disassembling, decrypting, or decompressing a message.
 A map, to transform messages from one type to another.
Note: Pipelines are covered in greater detail in Module 6, “Creating Pipelines.”
BizTalk Message Flow
Describe how messages are processed through BizTalk messaging components.
Overview
The two main functions of BizTalk Server 2010—BizTalk Orchestration and BizTalk
Messaging—form the underlying architecture that enables you to integrate and exchange
messages with the many types of external systems and applications that exist in your
organization and in those of your trading partners.
The BizTalk Messaging engine is responsible for performing the following tasks:
 Receiving inbound documents through receive ports, which may include the use of a
map for message translation or transformation.
 Parsing inbound documents to determine their specific format in a pipeline. Receive
pipelines can also perform data validation to ensure that the message being received is
valid compared with a known schema.
 Extracting key identifiers and identifying applicable routing rules. Filters can be placed
on send ports to route documents based on the contents of a message.
 Delivering documents to their respective destinations. Some of the options available to
route documents include file drops, databases, or other business processes.
 Tracking documents. The BizTalk Group Hub allows developers, IT professionals, and
business analysts to monitor message activity and troubleshoot errors as they arise.
What Is Property Promotion?
Describe how promoted properties work to enable content-based routing.
What is Property Promotion?

In BizTalk Server, promoted properties enable various BizTalk components to access key
items of data contained in a message. Promoting a property makes the data within that
node of the schema accessible to messaging processes. In addition to the properties that
you may choose to promote, various adapters promote contextual properties for routing
purposes. The information about the promoted properties is contained in a specially
formatted XML schema known as a property schema. Properties from a single message can
be promoted to different schemas depending upon your needs.
For example, if you need to route all invoices with a total dollar amount over $500, you
would promote the amount node in the source schema. The amount node would then be
available for use in a filter expression to create subscriptions.
Performing a quick promotion on a schema node promotes the node to the default property
schema defined for the XML schema in question. If a property is quick promoted and no
default schema yet exists, Microsoft Visual Studio® will offer to automatically create the
schema for you. Quick promotion is done by right-clicking the node and then clicking Quick
Promote.
By using the option to view promotions in Visual Studio, you can manage the promoted
properties (including removing the promotion if no longer needed). This view also includes
the ability to distinguish specific nodes. Distinguished fields are used in orchestrations and
will be discussed later in Module 10, “Creating Transactional Business Processes.” Visual
Studio provides a property schema template for creating your own property schemas.
Promoted Properties
Property promotion enables BizTalk messaging services to route messages based on the
context and content of the message. You want to promote properties only when required
for message routing, message correlation (a special form of message routing, which will be
covered in Module 9, “Automating Business Processes”), or property-tracking. Excessive
property promotion can adversely affect BizTalk Server performance.
Demonstration: Promoting a Property
Learn how to promote a schema property by using the Quick Promotion option in the BizTalk
Schema Editor.
Promote Properties
2. In Solution Explorer, double-click PurchaseOrder.xsd to open the schema.
3. Right-click the <Schema> node, and then click Expand Schema Node.
4. Right-click State, point to Promote, and then click Quick Promotion.
5. In the Microsoft Visual Studio dialog box, click OK.
This is a notice that Visual Studio will create a property schema that will contain
this promoted property. In Solution Explorer, notice that the schema named
PropertySchema has been added to the project.
6. PropertySchema.xsd will open in the Schema editor window, and a new Microsoft
Visual Studio dialog box will appear, asking you if you want to reload
PropertySchema.xsd. Click Yes.
Notice that the node you promoted is part of this schema.
7. Right-click Property1, and then click Delete, and then click Yes.
The Property1 node serves no purpose and can be safely deleted.
9. In PurchaseOrder.xsd, right-click OrderTotal, point to Promote, and then click Quick
Promotion.
10. Another Microsoft Visual Studio dialog box will appear, asking you if you want to
reload PropertySchema.xsd. Click Yes.
11. In Solution Explorer, right-click the Messaging project, and then click Deploy.
The next demonstration requires that this project be deployed.
Lesson 2: Configuring Message Routing
Lesson objective:
Configure BizTalk Server message routing.
Overview
BizTalk Server enables you to route messages directly to a send port or to an orchestration
based on the contents of the message. This feature is very powerful because it can increase
flexibility of business processes by eliminating the need to deterministically configure the
flow of messages.
Steps for Enabling Messaging Routing
Identify the steps for enabling the routing of messages in BizTalk.
Enabling Message Routing

To enable message routing, you must perform the following steps.
1. Promote the nodes in the source schema that will be used for content-based routing
of the message.
2. Create and configure both a receive port and a receive location for incoming
messages. Receive ports and receive locations are used to receive messages from
internal applications and from external trading partners.
3. Create and configure any send ports or send port groups that will be used for the
routing of the message.
4. Configure the filter expressions on the send ports or send port groups to create the
message subscriptions used to route messages to subscribers.
5. Enlist and/or start the send ports. Enlisting a send port creates the subscription in
the MessageBox database but will not begin processing messages until it is started.
6. Enable receive locations, which will begin processing messages from the endpoint.
Send ports should (at the least) be enlisted before receive locations are enabled. If messages
are received into the MessageBox and there are no subscriptions, the messages will be
suspended.
Configuring a Receive Port and Receive Location
Configure a receive port and a receive location.
Receive Ports
BizTalk Server uses receive ports to receive messages from internal systems and trading
partners. Receive ports can be configured to use one or more maps for incoming message
transformation. If more than one map is specified, only the map that matches the inbound
message will be applied. You can also configure the port to track message bodies or
properties. Although message body tracking provides more information about each
message, it can adversely affect the performance of BizTalk Server.
Additionally, receive ports can function as either one-way ports or two-way ports. A one-way
port only receives messages, whereas a two-way port, otherwise known as a request-
response port, can both receive and send messages. This module focuses on one-way ports
because they are used more often than two-way ports.
Receive ports and receive locations can be created and configured by using BizTalk Explorer
as shown in the preceding illustration. Both receive ports and receive locations can also be
created and configured by using the BizTalk Administration Console.
Receive Locations
A receive port can have multiple receive locations associated with it. This is useful when you
have messages being received from multiple physical locations, such as from a file folder and
an FTP site, but you want all the messages received through any of the locations to be
processed in the same manner.
Receive locations are configured with a URI, an address from which inbound messages
arrive, a receive handler, and a receive pipeline. The URI is specific to the transport or
adapter type (FILE, FTP, HTTP, Microsoft SharePoint® Services, and others). The receive
handler is the BizTalk host under which the receive location will process messages. The
receive pipeline processes the messages between being picked up and being written to the
MessageBox database. BizTalk pipelines will be covered in more detail in Module 6:
“Creating Pipelines”.
For more information on BizTalk hosts, refer to the BizTalk Server 2010 documentation on
“Managing BizTalk Hosts and Host Instances.”
Receive locations can be in one of three possible states:
 Enabled. When enabled, receive locations process messages.
 Disabled. Disable a receive location if you want to prevent the receive location from
receiving messages or if you want to delete the receive location.
 Suspended. If a service window has been configured for the receive location, the
location will indicate that it is suspended while the service window is inactive.
If an error occurs while a receive location is listening for messages, the receive location will
retry the number of times specified in the Retry Count property spaced at the Retry Interval
(minutes) property. If it continues to fail, the receive location may be disabled (this is a
property of the individual adapter).
Demonstration: Configuring a Receive Port and a File Receive Location
Learn how to create and configure a receive port and a receive location, and how to enable a
receive location by using the BizTalk Server Administration Console.
Create and Configure a Receive Port

2. Start the BizTalk Server Administration Console, and expand BizTalk Server
Administration, BizTalk Group, Applications, and then Demos.
3. Right-click Receive Ports, point to New, and then click One-way Receive Port.
4. In the Receive Port Properties dialog box, in the Name box, type PurchaseOrders,
and then click OK.
Create and Configure a Receive Location

1. In the BizTalk Administration Console, in the left pane, right-click Receive Locations,
point to New, and then click One-way Receive Location.
2. In the Select a Receive Port dialog box, double-click PurchaseOrders.
3. In the Receive Location Properties dialog box, in the Name box, type
PurchaseOrdersFILE.
It is helpful to include the Transport Type in the name of the receive location.
4. In the Type list, click FILE, and then click Configure.
5. In the FILE Transport Properties dialog box, click Browse.
6. Expand Computer, Local Disk (C:), AllFiles, DemoCode, and Messages, and then click
Make New Folder.
7. Rename the new folder IN, and then click OK.
Notice that the file mask is *.xml. This means that all XML files in this folder will
be processed.
8. In the FILE Transport Properties dialog box, click OK.
9. In the Receive Location Properties dialog box, in the Receive pipeline list, click
XMLReceive, and then click OK.
Enable the Receive Location

1. In the BizTalk Administration Console, in the left pane, click Receive Locations.
2. Right-click PurchaseOrdersFILE, and then click Enable.
The receive location is ready to begin processing messages.
Creating and Configuring a Send Port
Configure a send port.
Overview
Send ports are the locations to which BizTalk Server sends messages. A send port can
function as either a one-way port or a two-way port. As specified earlier, one-way ports send
messages, and two-way ports (also known as solicit-response ports) can both receive and
send messages. However, not all adapters support two-way ports. The FILE, MSMQT, and
SMTP adapters are supported only as one-way ports.
There are three general types of send ports:
 Static send ports. These send ports contain a fixed destination address. When you
create a static send port, as in the preceding illustration, you specify the adapter type,
destination address (URI), and pipeline used for the static send port.
 Dynamic send ports. Dynamic send ports do not contain a fixed destination address.
Instead, the destination address is set within the orchestration.
 Direct send ports. In the case of the static and dynamic send ports, the message is
written to the MessageBox database before being processed into the send port. In some
situations, it may be advantageous to have orchestrations communicate directly. In
these cases, direct send ports can be used.
Send ports can be created using either BizTalk Explorer or the BizTalk Administration
Console. Some of the properties you can configure for a send port include:
 Send port name. Since you will likely have many send ports in your application, you
should always assign a descriptive name to a send port to help identify which messages
or processes are associated with a specific send port. For example, POAck_to_Vendor is
a much better name then Port_1. Also, descriptive names can help when moving from
one environment to another.
 Primary and secondary transport. Examples of transport types include FILE, FTP, SQL
Server, and HTTP. Send ports contain both a primary and a secondary transport type so
that if the primary transport is unavailable for some reason, messages can still be sent
using the secondary transport type. For example, your primary transport type may be an
FTP site. However, if the FTP site is unavailable, you can set the secondary transport to
FILE and still successfully process messages through the send port. Later when the FTP
site is back online, you can manually transfer received messages from the file location to
the FTP site.
 Address (URI). The address or URI is the physical location where messages are sent
when processed by a send port. The address is dependent upon the transport type.
 Retry count. The retry count is the number of times BizTalk will try to resend a message
if the transmission fails. The default value is 3, which is satisfactory for many situations,
but the allowed range is 0 through 1000, which allows flexibility in use. For example, you
may not want retries to occur at all when communicating with a Web service, whereas
you may want to try continuously until successful when sending to a SQL database.
 Service window enabled/disabled. You can enable the service window if you want to
configure a port to send only at specified times of the day. By default, the service
window is disabled, meaning that the send port will send messages at any time. If the
service window is enabled, the Start Time and Stop Time properties must be specified.
You can enable the service window, for example, if you want to send messages to a busy
HTTP site only between midnight and 08:00 to prevent network delays during normal
business hours. The messages will actually be delivered to the send port and be queued
in the spool table in the MessageBox database until the appropriate time.
Other properties that must be specified for a send port include the BizTalk host and the send
pipeline. Both of these properties are configured on the Send tab of the Send Port Properties
dialog box. BizTalk hosts and send pipelines are covered in more detail in Module 6:
“Creating Pipelines”.
Configuring Send Port Filters
Configure send port filters.
Filter Expressions
Filter expressions are used to create subscriptions. Subscriptions determine which messages
will be delivered to a specific port. You can use both the promoted properties from the
inbound message schema and the BizTalk global properties to create the filter expressions
on a send port. This is known as content-based routing because the actual contents of the
message are used to determine how the message should be routed. For example, if you
need to route all messages with an order amount over $500 to a specific folder for
managerial approval, you can promote the amount node in the source schema and then
create a filter expression for a send port to subscribe to messages only with an amount
greater than or equal to $500.
Subscribing to Failed Messages

BizTalk Server 2010 provides the ability to create a subscription for failed messages. When
failed message routing is enabled on a receive port, a filter expression on a send port can be
used to send the failed message to an orchestration or some other endpoint, such as a
SharePoint site, to fix the error and resubmit the message. A sample of an error handling
solution is provided in the BizTalk Server 2010 SDK (software development kit).
Using a Send Port Group
Identify the purpose of a send port group and configure a send port group for message routing.
Send Port Group

A send port group is a collection of send ports that you can use to send a message through
multiple send ports by using a single configuration. This is useful when message processing is
complete and a message needs to be sent to multiple destinations.
Send port groups are useful, for example, when you need to send a message from a specific
business process to three different physical locations. For example, you might need to
submit a confirmation message of an invoice that was over $10,000 to an FTP site, an HTTP
directory, and a file drop for auditing purposes. If you create three separate send ports—one
for each transport type—and then create a send port group consisting of these three send
ports, you can create a single filter that will send any messages that meet the filter criteria to
all three physical send ports. The filter for a send port group is configured in the same way
as a filter for a single send port. You can create send port groups by using either BizTalk
Explorer or the BizTalk Administration Console.
Enlisting and Starting a Send Port
Describe the various states of a send port group and enlist and start a send port for message
processing.
Overview
Send ports and send port groups always have a state. The state of the send port determines
whether it accepts messages, processes messages, or does neither. The state of the send
port group can be changed by actions invoked on a send port it contains. You can change the
state of a send port by using either BizTalk Explorer or the BizTalk Administration Console.
Send Port States

Send ports are always in one of three states: Bound, Started, or Stopped.
 Bound. Ports that are fully configured but do not have any subscriptions are in the
bound state. When send ports are in the bound state, they are ready to be enlisted and
started. Fully configured ports are bound to a pipeline, associated with a particular
BizTalk host, and can optionally specify a map.
 Started. When a send port is in the started state, the subscription for this send port or
send port group is active and messages are being delivered and processed.
 Stopped. If a send port has been enlisted or has previously been started and is now
stopped, the send port or send port group will not currently be running. When the send
port or send port group is in this state, all new messages routed to this send port or send
port group are sent to the suspended queue of the send handler. If the port is
subsequently started, any queued messages will be processed. If a port that is stopped is
then disabled, its state will change to Bound, and any messages that have been queued
will be removed from the queue and will not be processed by the port. However, the
message remains in the MessageBox database.
Enlisting
The actions that can be invoked to change the state of a send port are Enlist, Start, Stop, and
Unenlist. When send port groups are first created, they are in the Bound state. To change
the send port group to the Started state, the send port group must be either started or
enlisted and then started because starting a send port implies enlisting. When a send port or
send port group is enlisted, it is associated with a BizTalk Host, and the subscriptions for the
send port or send port group are created in the MessageBox database. However, if a send
port has been enlisted but not started, it is still in the Stopped state. Stopping a send port
moves the send port state to Stopped but does not delete the subscription in the
MessageBox database. Unenlisting a send port changes the send port state to Bound and
deletes the subscription to that send port in the MessageBox database.
A query can be performed through the BizTalk Administration Console hub page for all
subscriptions. A preconfigured query is accessible at C:\Program Files (x86)\Microsoft
BizTalk Server 2010\SDK\Utilities\BTSSubscriptionViewer.btq.
Demonstration: Configuring a Send Port and a Send Port Group
Learn how to create and configure send ports and send port groups, and how to define filters.
Configure a Send Port with a Filter for a Standard BizTalk Property

2. In the BizTalk Server Administration Console, right-click Send Ports, point to New,
and then click Static One-way Send Port.
3. In the Send Port Properties dialog box, in the Name box, type ProcessedOrdersFILE.
6. Expand Computer, Local Disk (C:), AllFiles, DemoCode, click Messages, and then
click Make New Folder.
7. Rename the new folder ProcessedOrders, and then click OK.
8. In the FILE Transport Properties dialog box, in the File name box, type
Order%MessageID%.xml, and then click OK.
9. In the Send Port Properties dialog box, in the Send pipeline list, ensure that
PassThruTransmit is selected.
10. In the left pane of the Send Port Properties window, click Filters.
11. In the Property list, click BTS.ReceivePortName.
12. Verify that the Operator is set to ==.
13. In the Value box, type PurchaseOrders, and then click OK.
This send port will subscribe to all messages received through the
PurchaseOrders receive port.
Create Two Send Ports with No Filters

2. In the Send Port Properties dialog box, rename the port to ToManagerFILE.
4. In the FILE Transport Properties dialog box, in the Destination folder box, type
C:\AllFiles\DemoCode\Messages\OUT\.
ToManager%MessageID%.xml, and then click OK.
PassThruTransmit is selected, and then click OK.
8. In the Send Port Properties dialog box, rename the port to ToAccountingFILE.
10. In the FILE Transport Properties dialog box, in the Destination folder box, type
C:\AllFiles\DemoCode\Messages\OUT\.
ToAccounting%MessageID%.xml, and then click OK.
PassThruTransmit is selected, and then click OK.
Create a Send Port Group

1. In the BizTalk Server Administration Console, right-click Send Port Groups, point to
New, and then click Send Port Group.
2. In the Send Port Group Properties dialog box, rename the send port to
SendForAudit.
3. In the Send ports section, in the Name list, click ToAccountingFILE.
4. On the second line, in the Name list, click ToManagerFILE.
5. In the left pane, click Filters.
6. In the Property list, click Demo.Messaging.PropertySchema.State.
7. Verify that the Operator is set to ==.
8. In the Value box, type WA, and then click OK.
Start the BizTalk Host Instance

1. In the BizTalk Server Administration Console, in the left pane, expand Platform
Settings, and then click Host Instances.
2. Right-click BizTalkServerApplication, and then click Start.
The BizTalk services may not have started automatically if the virtual machine
took too much time to boot up. If you encounter any problems, you can double-
click C:\AllFiles\startBtServices.cmd to ensure that they start.
Start the Demos Application
1. In the BizTalk Server Administration Console, right-click Demos, and then click Start.
2. In the Start ‘Demos’ Application dialog box, click Options.
Examine the Application artifacts and Hosts options.
3. In the Start ‘Demos’ Application dialog box, click Start.
Test the Ports

1. In Windows Explorer, navigate to C:\AllFiles\DemoCode\Messages.
2. Open LargePO-WA.xml and SmallPO-WA.xml and then verify that the State field is
WA.
3. In Windows Explorer, double-click LargePO-OR.xml and SmallPO-OR.xml, and then
verify that the State field is OR.
5. Copy the four XML messages to the IN folder.
Be sure to copy the message to the IN folder. If you move the message, it will be
permanently modified by the BizTalk process.
6. Navigate to the ProcessedOrders folder, and notice the four messages there.
7. Navigate to the OUT folder and then notice that there are four messages: two that
begin with ToManager and two that begin with ToAccounting.
Only the messages with WA in the State field are sent using the send port group.
Lesson 3: Monitoring Orchestrations and Messages
Lesson objective:
Track and monitor BizTalk messaging activity.
Overview
Microsoft BizTalk Server provides tools that can be used to troubleshoot messaging and
orchestration processes. The BizTalk Administration console offers the BizTalk Group Hub
page (the Hub), which can be used for viewing live and completed BizTalk service instances.
Live instances are those that are currently executing, whether in an active, dehydrated, or
suspended state. Dehydrated instances are those whose state information has been
persisted and the resources in use released. These tools provide powerful search and
summary capabilities to assist in identifying the overall health of a BizTalk system.
What Is the BizTalk Group Hub Page?
Describe the capabilities of the BizTalk Group Hub page and use the Hub to monitor and track
live data.
The Group Hub

The BizTalk Server Group Hub provides IT professionals with an overview of the health of a
BizTalk group by displaying live data relating to orchestrations, suspended service instances,
host instances, and adapters. When working in the Hub, you can click any of the links to
execute a query that returns details in a new page. You can also create and save your own
queries. The Hub is divided into three sections that provide an overview of the health of
your BizTalk Server system:
 Configuration Overview. This section, located at the top of the Group Hub page,
indicates the overall health of the BizTalk group by displaying the number and state of
Applications, Host Instances, and Adapter Handlers within the BizTalk Server Group. This
section shows a red light or green light view of the health of these items. When initially
accessed, the Hub displays a collection of links. However, you may need to refresh the
page by pressing F5 before displaying the overall health of the group.
 Work in Progress and Suspended Items. This section displays the summary links for
viewing dehydrated orchestrations, retrying and idle ports, and running, ready,
scheduled, and suspended service instances.
 Grouped Suspended Service Instances. This section, the bottom section of the Hub
page, displays summary links for viewing suspended service instances grouped in various
ways. This grouping assists in managing suspended instances in a batch fashion. For
instance, if several messages are all generating the same error, you will see them here
grouped by the Error Code. Once the error has been resolved, all instances can be
resumed (or terminated) at the same time.
You can also use the Group Hub page to turn on tracking options for a message instance and
view actual message data. You can create run and save custom queries in the Group Hub to
troubleshoot problems with a particular message. Users must have BizTalk Administrative
privileges to configure tracking for BizTalk Server.
Running a Query in the Group Hub
Use the BizTalk Hub page to query and view specific instance details.
Viewing Instance Details

When any link in the Hub is clicked, a new query page is opened with the Query Expression
at the top of the window. This query can be modified to further restrict the results of the
query. The Query Results section displays a count of the instances that match the query,
with a detailed list of the resulting service instances below. Right-clicking any service
instance allows you to perform the following actions related to that instance.
 Service Details. The Service Details option will show the status of the instance, for
example, the instance ID, start time, or any errors that might have occurred. The
Messages page shows all of the messages associated with this instance to date. On the
Messages page, you can double-click any message and proceed to its details, where the
message context and even the message itself can be viewed.
 Show Messages. This initiates a new query that returns the messages associated with
this instance, which is the same list you would see if you navigate through Service
Details.
 Show Instance Subscriptions. If the instance is a message related to an orchestration,
instance subscriptions will be shown with this query.
 Terminate and Suspend Links. Use to suspend or terminate an individual instance.
Right-clicking the summary in the results section allows you to suspend or terminate all
of the related instances at once.
Message Tracking
Using the Tracked Message Event and Tracked Service Instance queries to monitor and track live
and historical data.
Overview
A BizTalk Server messaging system can process thousands of messages in a day.
Administrators, developers, and sometimes even business analysts require the ability to
track messages and to view, monitor, and query the data related to messages being
processed. The BizTalk Hub Tracked Message Event and Tracked Service Instance queries
give users the ability to view the tracking details related to service instances whether these
relate to message routing or orchestrations.
Benefits
Some of the capabilities of the Tracking queries include the ability to:
 Track when a service begins or ends or when a message is sent or received. The Tracking
queries can reveal the start time and the end time for every message processed by
BizTalk Server. The Tracking queries also show the state of any messages processed
through BizTalk Server and the context properties of each of the messages. Message
states include Active, Suspended, Completed, and Terminated.
 Monitor the health of operations, and create reports to analyze the current state of
business processes. Every message goes through a series of contiguous processing steps;
you can access this message flow by querying for messages and then right-clicking the
message you want to track. After you click Message Flow from the context menu, you
can see the processing steps for the message, and you can also see if any errors occurred
while the message was being processed by BizTalk Server.
 Gather information about the state of a running process to be able to implement
appropriate changes to the business process when needed. You can modify which data
you want to track without affecting the rest of the BizTalk environment. Redeployment
of assemblies is not necessary when changing tracking options. Changes to which
properties are tracked is managed through the BizTalk Administration Console.
Monitoring live data also enables you to monitor your system so you can fix problems in
the development or staging environment.
 Make it possible for business users to track message activity when a problem arises at
the business level so that the administrators or developers can investigate the problem
further. A power user may determine that all messages in a particular format are getting
hung up within an orchestration and save the problematic messages to disk to pass this
information on to a developer who can remedy the problem.
 Analyze archived information. The BizTalk hub queries allow the user to access both live
data and archived data. Analyzing archived data enables you to examine trends both in
your business and in your system because you can look as far back as is necessary to
troubleshoot a problem in a particular business process.
 Debug orchestrations. The Orchestration Debugger enables you to track the activity of a
single orchestration instance on a shape-by-shape basis. It displays a rendered view of
the orchestration created in the Orchestration Designer. You access the Orchestration
Debugger through a shortcut menu by right-clicking any service or message instance
associated with an orchestration type. You can switch back and forth between the
Orchestration Debugger and the Message Flow view.
You can configure exactly what information gets tracked, but note that tracking can have a
negative impact on BizTalk message-processing performance. This is because at each data
collection point, information has to be written to the tracking database. Care should be
taken in enabling message tracking for this reason. The effects of tracking should be
anticipated and included in the testing process to identify the overall impact.
Identifying Types of Events and Data That Can Be Tracked
Identify the types of events and data that can be tracked by BizTalk Server.
Event Tracking
BizTalk Server tracks data as events based on tracking filters you have set. You can configure
BizTalk to track events such as:
 The starting or stopping of a service.
 The sending or receiving of messages.
 The beginning or ending of a pipeline.
 The beginning or ending of an orchestration.
 The execution of each shape in an orchestration.
Data Tracking
You can turn on tracking for any information in the message, including promoted properties,
routing information, and partner data. The BizTalk Hub also allows you to see suspended
orchestrations and pipeline information.
The BizTalk Hub can be used to track:
 Promoted properties. This is useful when you have implemented content-based routing
that uses promoted properties, and you want to locate messages that were processed.
After you have turned on tracking for a promoted property in a schema, you can find
messages in which the promoted property is a specific value. For example, if you want to
see only messages that have a Quantity of less than 100, you can query the tracking
database based on the Quantity promoted property. However, only promoted
properties for which you have turned on tracking will show up in the Property drop-
down list. Tracking is configured in the BizTalk Group Hub.
 Routing information. Because the BizTalk Hub allows you to trace the path of a message
as it is routed through BizTalk Server, the BizTalk Hub can be very useful for
troubleshooting errors. The BizTalk Hub can display error codes and routing states for a
message so that you can troubleshoot errors in real time.
 Schema information. The BizTalk Hub allows you to find messages based on the schema
type. This can be useful when you want to see only messages associated with a
particular schema. Also, if you have promoted any properties in the schema that you are
tracking, you can select the specific property you want to track from the Property drop-
down list and narrow your search even further.
Viewing and Tracking Message Activity
Identify the types of events and data that can be tracked by using the BizTalk Hub Tracking
Queries.
Overview
You can view both live and archived data by using various BizTalk Hub queries. You must
have message body tracking turned on in order to save messages after processing of service
instances is complete. Also, make sure the SQL Server Agent service is running on all
MessageBox databases. This makes message bodies available to the BizTalk Group Hub and
WMI, and it enables you to perform cleanup in the MessageBox database. Message body
tracking is configured by using the BizTalk Group Hub page and is covered later in this
module.
Capabilities of the BizTalk Hub

The BizTalk Hub enables you to:
 Track both live and archived data.
 Select schemas to investigate and filter messages. Messages can be filtered based on
dates, the send or receive port that was used, trading partners (if available), and
promoted properties.
 Display and track services such as orchestrations and messaging. The BizTalk Hub
displays the state of each service instance returned from the query. Common service
instance states include completed and terminated.
 View message instances including metadata and message body. If a message did have
problems, you can easily find error messages to help troubleshoot the problem and then
resolve it.
 Debug orchestrations in real time. The ability to debug a running business process in real
time is a powerful feature of the BizTalk Hub that can be used to track the flow of a
message through an orchestration.
Demonstration: Tracking and Viewing Message Activity
Learn how to use the BizTalk Group Hub to track message activity and examine message flow.
Create the Message to Be Tracked

In Windows Explorer, navigate to C:\AllFiles\DemoCode\Messages.
2. Copy LargePO-WA.xml to the IN folder.
Be sure to copy the message to the IN folder. If you move the message, it will be
permanently modified by the BizTalk process.
Use BizTalk Tracking Queries to Track Completed Service Instances

1. In the BizTalk Administration Console, expand the BizTalk Server Administration
node, and then click on BizTalk Group.
The BizTalk Group Hub provides you with the ability to track and view archived
message activity. The Group Hub page should be used to track, debug, and view
running service instances.
2. On the New Query tab, select Tracked service instances from the list, then click Run
Query .
This query displays the most recently completed message instances.
3. Right-click the most recent Microsoft.BizTalk.DefaultPipelines.XMLReceive service
instance, and then click Message Flow.
4. Maximize the Message Flow window.
The top section has information about this service instance, such as the type,
start and end times, and the host used. The bottom section has information
about how the message came in and went out of this service. This is an instance
of the XMLReceive default pipeline; it is associated with the PurchaseOrders port.
When the XMLReceive pipeline finished processing the message, the message
was sent to three different instances of the PassThruTransmit pipeline.
Note: The order in which the message is sent by the send ports is non-
deterministic. This means that the order that the message was sent through the
ports in your instance may be different from the following steps.
5. Click the first Microsoft.BizTalk.DefaultPipelines.PassThruTransmit link under the
PurchaseOrders port.
Notice the name of the port and the URL. They will match one of the three send
ports that you created. The ordering of delivery to the three send ports is not-
deterministic, due to the publish/subscribe architecture.
6. Click the Microsoft.BizTalk.DefaultPipelines.XMLReceive link to go back to the
XMLReceive pipeline instance.
7. Click the second Microsoft.BizTalk.DefaultPipelines.PassThruTransmit link under
the PurchaseOrders port.
Notice the URL and port used by this instance of the pipeline. It will be another
one of the send ports created earlier.
8. Click the Microsoft.BizTalk.DefaultPipelines.XMLReceive link to go back to the
XMLReceive pipeline instance.
9. Click the third Microsoft.BizTalk.DefaultPipelines.PassThruTransmit link under the
PurchaseOrders port.
This will display the name and URL for the third send port.
10. Close all windows and shut down the virtual machine.
Lab: Routing BizTalk Messages
Scenario
The BizTalk messaging engine allows you to route messages based on message context. In
this lab, you will add existing BizTalk artifacts the messaging project. Next, you will promote
properties in an XML schema to be used to selectively route messages. You will then
configure BizTalk messaging ports to receive and route sales order messages, based on
message context. Finally, you will test the port configuration by submitting test messages.
Procedure List
window.
Start.

Procedure List
Exercise 1: Adding an Existing Schema and Map to the Project
Overview
Another BizTalk developer has given you BizTalk artifacts to use in your project. In this
exercise, you will import an existing schema and map into the Messaging project.
Add an Existing Schema and Map to the Project

Procedure List
1. In Windows Explorer, navigate to C:\AllFiles\LabFiles\Lab5\AdvWorks and open the
AdvWorks.sln file.
2. In Solution Explorer, right-click Messaging, point to Add, and then click Existing
Item.
3. In the Add Existing Item – Messaging dialog box, navigate to
C:\AllFiles\LabFiles\Lab5\AdvWorks\Artifacts.
4. While pressing the CTRL key, click LoanApplication.xsd and
SalesOrder_To_LoanApp.btm, and then click Add.
5. In Solution Explorer, double-click the LoanApplication.xsd schema.
6. In the Schema Editor, right-click <Schema>, and then click Expand Schema Node.
Examine the structure of the LoanApplication.
7. Close the LoanApplication.xsd schema window.
8. In Solution Explorer, double-click the SalesOrder_To_LoanApp.btm map.
Examine the mapping of the nodes within the map.
9. Close the SalesOrder_To_LoanApp.btm map.
Exercise 2: Promoting Schema Properties
Overview
Promoting a property makes specific data in a message accessible to the BizTalk messaging
engine so messages can be routed based on their contents. In this exercise, you will promote
several properties in the SalesOrder schema.
Promote Properties
Procedure List
1. In Solution Explorer, double-click SalesOrder.xsd.
3. Under the Detail node, right-click OrderType, point to Promote, and then click Quick
Promotion.
4. In the Microsoft Visual Studio message box, read the message, and then click OK. If
a message box appears asking if you want to reload PropertySchema.xsd, click Yes.
Notice in Solution Explorer that the PropertySchema.xsd artifact has been
created. This is the default schema created to hold promoted properties. Also
notice that the OrderType node now has an icon to indicate that the node has
been promoted.
5. Ensure that PropertySchema.xsd is open in the schema editor. If it is not, double-
click PropertySchema.xsd in Solution Explorer.
Notice that the OrderType node is listed in the PropertySchema schema. The
Property1 node is created by default and can be safely deleted.
6. Right-click Property1, and then click Delete.
7. In the BizTalk Editor dialog box, click Yes to confirm the deletion.
Verify in the status bar that the deployment succeeded.
Exercise 3: Creating a Receive Port and a Receive Location
Overview
You can use the BizTalk Server Administration Console to manage the BizTalk configuration
database. BizTalk Server uses receive ports and receive locations to process inbound
messages. In this exercise, you will create a receive port and receive location by using BizTalk
Explorer.
Create the SalesOrder Receive Port

Procedure List
Group, Applications and BizTalk Application 1
3. Right-click Receive Ports, point to New, and click One-Way Receive Port.
4. In the Receive Port Properties dialog box, type SalesOrder in the Name box, then
click OK.
Create the SalesOrderFILE Receive Location

Procedure List
2. Create a new folder, and name it SalesOrderIN.
3. In the BizTalk Administration Console, click the Receive Ports icon under BizTalk
Application 1, then right-click the SalesOrder receive port, point to New, and click
Receive Location.
4. In the Receive Location Properties dialog box, type SalesOrderFILE in the Name box.
5. Choose FILE from the Type drop-down list, and then click the Configure button.
7. In the Browse For Folder dialog box, navigate to
C:\AllFiles\LabFiles\Lab5\SalesOrderIN, and then click OK twice.
8. In the Receive Pipeline drop-down list, choose XMLReceive, and then click OK to
close the Receive Location Properties dialog box.
Exercise 4: Creating a Send Port for All Orders
Overview
In this exercise, you will create a send port and configure it to subscribe to all messages
received by the SalesOrder receive port.
Create the SalesOrderFILE Send Port

Procedure List
1. In the BizTalk Administration Console, right-click the Send Ports icon under BizTalk
Application 1, point to New, and click Static One-Way Send Port.
2. In the Send Port Properties dialog box, in the Name box, type SalesOrderFILE.
3. Choose FILE from the Type drop-down list, and click the Configure button.
4. In the FILE Transport Properties dialog box, click Browse, browse to
C:\AllFiles\LabFiles\Lab5, create a new folder named AllSalesOrders, and then click
OK.
5. In the File name box, type Processed%MessageID%.xml, and then click OK.
6. In the Send Pipeline list, click PassThruTransmit.
7. In the left pane of the Send Port Properties dialog box, click Filters.
8. In the right pane, click the top box in the Property column, and choose
BTS.ReceivePortName from the drop-down list.
9. In the Value box, type SalesOrder, and then click OK.
Exercise 5: Creating a Send Port for Cash Orders
Overview
Subscriptions can be created based on multiple message properties. In this exercise, you will
create a send port and configure it to subscribe to all messages that have the word CASH in
the OrderType promoted property field, and are received by the SalesOrder port .
Create the CashOrdersFILE Send Port
Procedure List
1. Under BizTalk Application 1, right-click Send Ports, point to New, and then click
Static One-Way Send Port.
2. In the Send Port Properties dialog box, in the Name box type CashOrdersFILE.
C:\AllFiles\LabFiles\Lab5, create a new folder named CashOrders, and then click
OK.
5. In the File name box, type Cash%MessageID%.xml, and then click OK.
6. In the Send pipeline list, click PassThruTransmit.
9. In the Value box, type SalesOrder.
10. On the second line, click AdvWorks.Messaging.PropertySchema.OrderType in the
Property list.
11. In the Value box, type CASH, and then click OK.
Exercise 6: Creating a Send Port for Credit Orders
Overview
You want all credit orders to be sent to a different port than the cash orders. In this exercise,
you will create a send port and configure its filter to subscribe to all messages that contain
the word CRED in the OrderType promoted property field, and are received by the
SalesOrder port.
Create the CreditOrdersFILE Send Port

Procedure List
1. In the BizTalk Server Administration Console, under BizTalk Application 1, right-click
Send Ports, point to New, and then click Static One-Way Send Port.
2. In the Send Port Properties dialog box, in the Name box, type CreditOrdersFILE.
C:\AllFiles\LabFiles\Lab5, create a new folder named CreditOrders, and then click
OK.
5. In the File name box type Credit%MessageID%.xml, and then click OK.
8. Click the top box in the Property column, and in the drop-down list, click
BTS.ReceivePortName.
Property list, and then type CRED in the Value box.
11. In the left pane, click Outbound Maps.
12. In the Map list, click SalesOrder_To_LoanApp, and then click OK.
Exercise 7: Testing the Port Configuration
Overview
Each sales order received through the SalesOrder receive port is sent to two of the three
send ports, based on message context. In this exercise, you will start and enable the newly
created ports and submit messages to test the message routing configuration.

Procedure List
1. In the BizTalk Server Administration Console, right-click the BizTalk Application 1
application, and then click Start.
2. In the Start ‘BizTalk Application 1’ Application dialog box, click Options.
3. Verify that all check boxes are selected, and then click Start.
Test the Port Configuration

Procedure List
2. Double-click CashSalesOrder1.xml, which will open the file in Microsoft Internet
Explorer.
Notice that the OrderType value is CASH.
3. In Windows Explorer, double-click CashSalesOrder2.xml.
4. In Windows Explorer, double-click CredSalesOrder1.xml.
Notice that the OrderType value is CRED.
7. Copy the four XML messages to the SalesOrderIN folder.
It is important that you copy the messages to the SalesOrderIn, rather than
moving them. Once the messages are processed, they can not be recovered for
later testing.
The messages will disappear when BizTalk Server receives them.
9. In Windows Explorer, open the AllSalesOrders folder.
It may take up to one minute for the messages to appear, but eventually, all four
messages will be routed to this folder.
10. In Windows Explorer, open the CashOrders folder.
The two CASH messages have been routed to this folder.
11. In Windows Explorer, open the CreditOrders folder.
The two CRED messages have been routed to this folder.
12. Open one of the Credit{GUID}.xml messages.
Notice that the message is in the LoanApp format because it was processed
through the SalesOrder_To_LoanApp map used by the CreditOrders send port.
Module 6: Creating Pipelines
Module objective:
In this module, you will learn how to create send pipelines and receive pipelines for specific
processing scenarios.
Overview
Pipelines enable the pre-processing of messages as they enter or leave the MessageBox
database. Pipelines can also be called from within an orchestration. Pipelines are used to
provide additional processing to messages, such as encoding and decoding, encrypting and
decrypting, and other processing that might be required to work with messages in Microsoft
BizTalk Server.
BizTalk Server supports the ability to modify pipeline properties on a per-use basis, reducing
the need to modify pipelines frequently, and the ability to call pipeline components from
within an orchestration.
Lesson 1: Introduction to Pipelines
Lesson objective:
Describe both send and receive pipelines and explain how BizTalk Server uses pipelines to
process messages.
Overview
A pipeline in BizTalk Server is a software infrastructure that defines and links together one or
more stages of a business process. Stages define logical work groups, determine which
components can belong to a stage, and specify how the pipeline components in the stage
are run. Pipelines are executed in sequence to complete a specific task, such as encrypting a
document or validating a document against a schema.
What Is a Pipeline?
Describe how pipelines can be used to process messages.
Pipelines
Pipelines are software components that can process messages, either as the messages are
received or just before they are sent out through a send port. A pipeline divides processing
into categories of work called processing stages and specifies the sequence in which each
stage of work is performed. Each stage of a pipeline contains one or more pipeline
components (Microsoft .NET objects or COM objects) that can be configured to work with
the specific requirements of the messaging solution or orchestrated business process.
Processing Stages
Pipeline processing stages can include functions such as decoding or encoding,
disassembling or assembling, and decrypting or encrypting. Processing stages are
implemented in a prescribed order that cannot be modified.
The processing stages for a pipeline depend upon its intended use. BizTalk Server provides
two types of pipelines: receive and send. These two types of pipelines require separate
categories of work, such as the encoding versus the decoding of a message. The pipeline also
governs the process sequence by the use of policy files that specify the order in which each
stage is to be executed. For instance, an incoming message must usually be decoded before
it can be disassembled.
Pipeline Scenarios
Describe receive and send pipeline usage scenarios.
Overview
There are a number of reasons why you may need to implement pipelines in your BizTalk
solution. By using pipelines, it is possible to modify the message in many different ways as it
is being passed into and out of the MessageBox database.
Receive Pipelines
Receive pipelines can be used to process messages as they are received by BizTalk Server.
For example, you can use receive pipelines to decode and/or decrypt messages (by using a
private key) as well as verify the sender of messages as they are being received. This is
important because messages exchanged over the Internet must frequently be encrypted,
and it is necessary to confirm the identity of the sender of the message.
Other tasks that can be performed in receive pipelines include extracting individual
messages from a message interchange and validating messages against a schema to ensure
that they meet the requirements of your processes. Validation can be performed in both a
receive pipeline and a send pipeline.
Send Pipelines
Send pipelines are used to process messages as they are being sent by BizTalk Server. For
example, you can use send pipelines to encrypt messages (using a public key), or digitally
sign outbound messages (using a private key) as proof of who the sender is. Before a
message is sent, you can also use the validate component of a send pipeline to ensure that a
message is valid against a known schema.
Receive Pipeline Stages
Explain how each of the receive pipeline stages works to process messages.
Receive Pipeline Stages

Receive pipelines are associated with receive ports (which are discussed in Module 5,
“Routing BizTalk Messages”). When a port receives a message via an adapter (or is called
from within an orchestration), the message is passed to the pipeline for processing. The
receive pipeline parses the initial message, with each component tentatively processing the
message. The result of the pipeline process will be zero, one, or more messages that will
make their way to the MessageBox and on to various subscribers.
Each of the four stages in a receive pipeline performs a specific function and can contain
only components specified for use in that stage. Each receive pipeline stage can contain up
to 255 components, which will all be executed in order with the exception of the
disassemble stage, in which only one component will execute. The four stages are as follows:
 Decode. This stage is used for components that decode or decrypt messages. For
example, there is a built-in MIME/SMIME decoder pipeline component that can be
used to decode MIME-encoded messages. Custom components for this stage could
include a component to decode a compressed (zipped) file before further
processing.
 Disassemble. Use this stage if you need to parse or disassemble the inbound
message. The components within this stage probe the message to see if the
message format is recognized, and then, if the message format is recognized, one of
the components disassembles the message. Tasks performed in this stage include
conversions of flat-file messages to XML format and splitting of messages. In order
for property promotion to occur, an appropriate (flat-file or XML) disassembler must
be specified in this stage.
 Validate. In this stage, messages are validated against a collection of schemas.
Pipelines process only messages that conform to the schemas specified in this
component, if present. If a message is received by the pipeline whose schema is not
associated with any component in the pipeline, the message is not processed.
Depending on the adapter, the message is either suspended or an error is issued to
the sender. This stage runs once per message created by the Disassemble stage. The
built-in validate component can be used in this stage as well as in other stages.
 Resolve Party. In this stage, the certificate associated with the sender’s security
identifier (SID) is mapped to the corresponding configured BizTalk Server party. If
the message was digitally signed, the component uses the signature to look up a
Microsoft Windows® identity in the BizTalk Server 2010 Configuration database. If
the message carries the authenticated SID of a Windows user, this identity is used. If
neither mechanism succeeds, the sender is assigned a default anonymous identity.
Party resolution is an important feature for managing trading partner relationships.
Not all adapters support party resolution.
Send Pipeline Stages
Explain how each of the send pipeline stages works to process messages.
Send Pipeline Stages

A send pipeline is responsible for processing documents before they are sent to their final
destinations. The send pipeline accepts one message and produces one message for
sending. You can create a new send pipeline, which contains empty stages by default, or you
can use one of the two default send pipelines included in BizTalk Server: the Pass-Through
Send Pipeline or the XML Send Pipeline.
By default, the send pipeline consists of three empty stages:
 Pre-Assemble. This stage is a placeholder for custom components that should

perform some action on the message before the message is serialized. This stage is
run once per message and can contain between 0 and 255 components. All
components in this stage are run.
 Assemble. In this stage, components are responsible for assembling or serializing
the message and converting it to or from XML. This stage accepts either 0 or 1
component, which if present will be executed once for each message. Possible uses
for this stage include converting to a flat-file formatted message and placing an
envelope wrapper around a message.
 Encode. This stage is used for components that encrypt or encode the message, and
it runs once per message. This stage can contain between 0 and 255 components,
and all components in this stage are executed. If message signing is required, for
example, place the MIME/SMIME Encoder component or a custom-encoding
component in this stage. You may create a custom component to generate a
message as a PDF file or to convert a message to compressed Zip format before
sending it.
Pipeline Components
Explain how each of the send pipeline stages works to process messages.
Built-in Pipeline Components

The Visual Studio Toolbox is populated with several standard BizTalk Server components
that you can use to create a pipeline.
The XML Disassembler pipeline component combines XML parsing and disassembling into
one component. Its primary functions are: removing envelopes, disassembling the
interchange, and promoting the content properties from interchange and individual
document levels on to the message context. The XML Assembler component performs the
reverse operations.
The Flat File Disassembler component parses delimited and positional flat file format
messages and converts them into an XML representation. The Flat File Disassembler also
removes the header and trailer structures from the flat file message, and breaks the
interchange within the message into individual documents. It also promotes properties from
the documents and headers. The Flat File Assembler performs the reverse operations.
The MIME/SMIME Decoder component provides MIME decoding functionality for
messages. This pipeline component can be placed into the Decode stage of a receive
pipeline, and it supports 7bit, 8bit, binary, quoted-printable, UUEncode, and base64
decoding. Localized data character set changes will not affect the decoding.
The MIME/SMIME Decoder component can decrypt and sign-validate an incoming message.
Decryption certificates are used from the personal certificate store of the current user under
which the service is running. Sign-validation certificates are used from the Address Book
store of the local computer or from the message itself.
The XML Validator pipeline component can be used in both send and receive pipelines in
any stage except for Disassemble or Assemble. The XML Validator component validates the
message against the specified schema or schemas, and if the message does not conform to
these schemas, the component raises an error and Messaging Engine places the message in
the suspended queue.
The responsibility of the Party Resolution pipeline component is to map the sender
certificate or the sender security identifier (SID) to the corresponding configured BizTalk
Server party.
What Are the Default Pipelines?
Identify each of the default pipelines and describe how they work to process messages.
Default Pipelines
When you create a new application, a reference to the Microsoft.BizTalk.DefaultPipelines
assembly is automatically added to the project. This assembly contains the default pipelines
provided with BizTalk Server. The default pipelines cannot be modified using the Pipeline
Designer.
XML Receive Pipeline

The XML receive pipeline consists of all four stages; however, the decode and validate stages
are empty. The disassemble stage contains the XML Disassembler component, and the
ResolveParty stage runs the Party Resolution component, which resolves the certificated
subject or the source security ID to the party ID.
XML Send Pipelines

The XML send pipeline consists of all three stages, with the assemble stage having an XML
assembler and the other two stages being empty. The assemble stage ensures that the
outbound XML is well-formed.
Pass-Through Receive Pipelines
The Pass-Through receive pipeline contains no components. It is used for simple pass-
through scenarios in which no message processing is required. This pipeline is generally used
when both the source and the destination of the file are known, and the message requires
no validation, decoding, or disassembling. This pipeline is commonly used in conjunction
with the Pass-Through send pipeline. Because this pipeline does not have a disassembler
component, it cannot be used to route messages to orchestrations or to promote properties
from within messages. Property promotion is discussed in detail in Module 5, “Routing
BizTalk Messages.”
Pass-Through pipelines are typically used to process non-message data, such as graphics
files, Microsoft Word and PDF documents, or files that are sent as attachments. The Pass-
Through pipelines treat the message as a blob (raw message data) and simply place the
content directly in the MessageBox database.
Pass-Through Send Pipelines

The Pass-Through Send pipeline contains no components. It is used for simple pass-through
scenarios in which no message processing is necessary. This pipeline is the default pipeline
that is used when you create a new send port. Because there are no components and no
processing takes place, this pipeline is very efficient and should be used whenever practical.
This pipeline is frequently used in conjunction with the Pass-Through receive pipeline when
the message is not being processed by BizTalk but is simply being routed through BizTalk
Server.
Flat-File Pipelines
There are no default flat-file pipelines. Any time flat-file messages need to be processed, it
will be necessary to create a custom pipeline as outlined in the following topics. When any
flat-file message is to be processed through BizTalk Server, the pipeline will have at least one
disassembler in which the document property will identify the flat-file message format that
the disassembler can process. Each flat-file disassembler can specify only one document
schema; therefore, if the pipeline can process multiple flat-file message formats, multiple
disassemblers will be required.
What Are Custom Pipeline Components?
Explain when to use a custom pipeline and describe usage scenarios for custom pipelines.
Custom Pipeline Components

BizTalk Server pipelines allows you to customize the processing of documents received or
sent via the various adapters. Custom pipeline components extend the behavior of the
default pipelines to enable the processing of virtually any data format. Custom pipelines can
be a powerful solution if you support legacy systems that require integration with other
products but do not follow standards. For example, your data may contain carriage returns
in odd places or records that span multiple lines of text.
Examples of when to consider using a custom pipeline include:
 Validations that cannot be expressed in an XML schema.
 Decryption algorithms not supported by BizTalk Server out of the box.
 Checks on signature formats that BizTalk Server does not yet recognize.
 Conversions that might not be possible by using the BizTalk Mapper.
 A custom disassemble algorithm is required to split up your messages.
 Context must be added to a received message to support advanced routing and
correlation scenarios.
 Built-in components can’t process a message, as is the case with converting to or
from a PDF or Zip file format.
Types of Pipeline Components
Explain the different types of pipeline components and how they are used.
Overview
You can create three types of pipeline components: general, assembling, and disassembling.
Each of the three types can additionally implement probing functionality. Each type of
pipeline component has an associated interface that must be implemented for the
component to be plugged into the BizTalk Messaging Engine. In order to develop a general
pipeline component, you must implement the following interfaces:
 IBaseComponent. This interface contains three functions, one each to retrieve the
computer name, description, and version.
 IComponent. This interface contains the single core method for implementing the
pipeline process that allows you to give read and write access to both the message’s
data parts and context.
 IComponentUI. The two methods in this component enable you to validate the
component’s configuration and provide a design-time environment icon.
 IPersistPropertyBag. This interface enables a component to both retrieve and store
configuration information for the component by using a property bag (used to
persistently save properties).
 IProbeMessage. This interface is required for disassembler components. The
pipeline manager will call the disassembler through this interface, allowing the
component to examine a message to determine whether or not it can recognize and
process the message format.
The built-in pipeline components are streaming components which means that they get one
pass at the data as it flows through the pipeline. For performance reasons, and to conserve
memory, you should create streaming pipeline components whenever feasible. Non-
streaming components will consume more memory and can degrade performance.
Implementing a Custom Pipeline Component

To create a custom pipeline component, create a Class Library project in Visual Studio, and
then add a new class to it. Mark the class with the ComponentCategory attribute to indicate
that this class is a pipeline component. This attribute also indicates which stages of
execution are appropriate for this component. Then, you will need to write the code that
implements the interfaces described above. The actual message processing will be
performed in your IComponent.Execute method.
It is possible to modify messages in a pipeline component, but you must handle messages
with care in pipeline components. Keep in mind that messages are generally considered
immutable. You must actually clone the message before you can make any changes to it.
You can promote properties on the original message, however, without being required to
perform the cloning.
When cloning a message, you will need to copy the message, parts, and context. BizTalk
provides a few helper classes to simplify this process. The PipelineUtil class provides
methods for cloning. The PipelineContext class provides other utility methods and
properties.
The PipelineContext is passed to the IComponent.Execute method. It provides details about
component location in the pipeline, and it provides methods to access schemas based on
type or name. It also provides access to the message factory. You can use the message
factory to create new messages, message parts, context and property bags.
PipelineContext also provides handle to current transaction. Your pipeline executes in in the
context of the transaction, and the component’s work is committed as part of persisting to
the message box.
Pipeline components can be deployed in two locations:
• Directory: [BTSINSTALL_DIR]\Pipeline Components
• Global Assembly Cache (GAC)
BTSInstall_Dir is primarily used for development, and this is where Visual Studio will look for
assemblies used in the pipeline designer. A pipeline component must be deployed to the
GAC if it will be used within an orchestration. The recommended practice is to deploy all
custom components to GAC.
Lesson 2: Building a Pipeline
Lesson objective:
Describe and demonstrate how to design and build send and receive pipelines.
Overview
The send and receive pipelines that you create can be a very important part of your BizTalk
deployment. In this lesson you will learn how to use Visual Studio to design and build
pipelines.
Using the Pipeline Designer
Use the Pipeline Designer to create receive pipelines and send pipelines.
Pipeline Designer
The BizTalk Pipeline Designer is a feature in Microsoft Visual Studio® 2010. The Pipeline
Designer provides a graphical representation of a pipeline and enables you to construct or
edit send or receive pipelines for a BizTalk project. You can navigate between pipelines by
clicking the tabs at the top of the design surface. The file extension for both receive pipelines
and send pipelines is .btp.
You create a new pipeline by selecting a pipeline template for a project. Separate templates
are provided for send and receive pipelines. When you name a new pipeline, you should get
in the habit of indicating the primary purpose of the pipeline along with the pipeline
direction (send or receive), for example, SendEncryptedMessages.
Pipeline Stages
You create or modify pipelines by dragging and dropping components to the different
pipeline stages. If there are no components in any one stage, a placeholder indicates that
shapes can be inserted there from the Toolbox. When the first shape is inserted into a stage,
the placeholder text disappears.
The design surface shows the pipeline vertically, running from the start of the pipeline (at
the top) to the end of the pipeline. Note that with the exception of the disassemble stage (in
the receive pipeline), the execution path goes through each stage indicating that each
component in the stage will be executed in order. In the case of the disassemble stage, the
path is represented as a dotted line that extends around the components in the stage,
indicating that the message will be probed and that the first component that matches will be
executed.
Only components that are valid for the type of pipeline that you are creating are displayed.
For example, the assembler components can be used only in send pipelines so that they are
not visible when creating a receive pipeline. Additionally, the design interface will allow you
to add only those components that are valid for a given stage to that stage. For example,
you can add only a disassembler to the disassemble stage.
Securing Data by Using a Pipeline
Configure pipelines to enable the secure processing of messages.
MIME/SMIME Encoder Pipeline Component

BizTalk Server includes the MIME/SMIME Encoder pipeline component. This component is
used to encode messages before they are passed to other business processes outside BizTalk
Server. This is useful, for example, when you require the secure exchange of documents
between external processes and business partners. The MIME/SMIME pipeline component
can be used to either MIME encode, sign, or encrypt outgoing messages with encryption and
signing certificates. It also enables the sending of multi-part messages outside of BizTalk
Server.
Note: All of the possible properties that you can configure for the MIME/SMIME Encoder
pipeline component are listed in the BizTalk Server 2010 documentation under “Configuring
the MIME/SMIME Encode Pipeline Component.”
Configuring Encoding
If an encoding component in the send pipeline is configured to sign messages, and the
BizTalk group that includes the host running the pipeline is not configured with a signing
certificate, the outgoing message will be suspended (with the appropriate error being
displayed) to the suspended queue of the host running the pipeline. If the signing certificate
cannot be found in the personal certificate store of the current user under which the service
is running, the message will be routed to the suspended queue of the host running the
pipeline.
If there is an encoding component in the outbound pipeline configured to encrypt outbound
messages, and the certificate cannot be found in the certificate store, the message will be
suspended to the suspended queue of the host that is running the pipeline.
Also, if you have a request-response port that is receiving signed and encrypted messages,
and you want to perform response encryption on this port, you must add a custom pipeline
component to the pipeline before the MIME/SMIME Encoder pipeline component that must
identify the thumbprint corresponding to the encryption certificate. You will also need to set
the BTS.EncryptionCert property on the message context.
Note: In BizTalk 2010, the MIME/SMIME encoder pipeline component will not have native
64-bit support. This means that this component must be run in a 32-bit emulation mode
process (WOW64), which implies that the host instance in which this encoder component (or
the send pipeline of which it is a part) runs must be running in 32-bit emulation mode. Be
aware of the performance (and other) implications of this restriction for other elements of
BizTalk Server running in this same host instance.
Processing Interchanges by Using a Pipeline
Configure pipelines to enable the processing of message interchanges.
What Is an Interchange?
An interchange is a group of messages that are contained within one larger message.
Depending upon the design of the messaging or orchestration solution, BizTalk Server can
often process many small messages faster than it can process a single large message. For
example, you can think of an interchange as a manila envelope that contains ten individual
paper purchase order (PO) documents. Once you open the envelope, you will want to
process each PO separately. Interchange processing in BizTalk Server is used to extract these
individual messages so that they can be processed separately.
BizTalk Server 2010 supports a feature called recoverable interchange processing.
Standard Interchange Processing

By default, when an interchange arrives at a receive location, the configured pipeline will
break down the interchange into one or more messages. Messages are then individually
validated by the pipeline and then collected within the EPM (End-Point Manager) inside
BizTalk Server. If, at any time, any message within the collection fails, the entire interchange
is suspended. The suspended message will appear as the complete original interchange, not
the separate parts.
Consider a scenario that contains 10 messages, all of which the disassembler successfully
extracts from the interchange:
1. The first five messages propagate through the pipeline and are ready to be
published.
2. The sixth message fails to process at the disassembling stage in the pipeline, which
causes all of the other messages that have already been processed to roll back and
the original interchange message to be suspended as resumable.
3. Nothing is published. The original interchange (in this case, all ten messages) is
suspended because in standard interchange processing, any extracted message that
fails at any point during or after interchange disassembly results in all extracted
messages being discarded and the original interchange being placed on the suspend
queue as resumable. Suspended messages can be viewed by using the BizTalk Group
Hub, and notification of the offending message can be sent by using Microsoft
Systems Center Operations Manager (SCOM). By default, failed messages cannot be
subscribed to by end points such as an orchestration or a send port.
Note: Standard interchange processing is the default for XML receive pipelines in BizTalk
Server 2010.
Recoverable Interchange Processing

Recoverable interchange processing is a feature of BizTalk Server that supports additional
flexibility in how multi-message interchanges are processed. When a new interchange
arrives, and the Recoverable Interchange property is set to true, the message is broken
down into individual messages and passed through the pipeline for disassembly and
validation. Unlike standard interchange processing, messages are individually validated and
individually sent by the EPM to the MessageBox. If any message has an error, it is
individually suspended in the original format. This means that if a message comes in as a flat
file, it will be suspended as a flat file, not parsed as XML.
All messages that pass validation are not affected by any failed messages. Failed messages
will show up as individual suspended messages within the BizTalk Administration console. As
with standard message processing; inbound suspended messages can be resumed if the
suspending error is corrected.
Consider the same example that was used previously with the exception that the
disassembly stage is configured to perform recoverable interchange processing. The result is
that individual extracted messages are all processed, and the original interchange is
discarded. The individual messages are processed as follows:
1. The first five messages propagate through the pipeline and are ready to be
published.
2. The sixth message fails disassembly processing and is suspended.
3. The seventh message and all other messages in the interchange propagate through
pipeline and are ready to be published.
4. After all messages are extracted from the interchange, messages 1, 2, 3, 4, 5, 7, 8, 9,
and 10 are published into the MessageBox, and message 6 is placed on the
suspended queue.
Note: BizTalk Server 2010 supports another feature that is helpful in this case as well: the
feature allows not only the suspension of the failed message, it supports subscription to
these failed messages as well.
Creating Schemas for Interchange Processing
Configure schemas to enable interchange processing of flat files and XML files through a pipeline.
Overview
A message interchange can be a single XML document that contains other messages, or it
may be a collection of flat-file messages contained within a single flat-file message. BizTalk
Server has different requirements for processing flat-file interchanges than for XML
interchanges. As does all flat-file processing, flat-file interchanges require a custom pipeline,
whereas XML interchanges can use the default XML pipeline. Additionally, you can create a
custom XML pipeline to process interchanges.
Flat-File Interchanges
Processing of flat-file messages always requires a custom pipeline containing the flat-file
disassembler. A pipeline for flat-file interchanges requires you to configure a flat-file
disassembler that specifies the schemas that make up the entire interchange message. This
will necessarily include a document schema and may optionally include header and/or trailer
schemas.
The document schema needs to represent the individual messages (which may be one or
more records) to be extracted by the disassembler. The Header schema must define any
records that occur before individual documents in the interchange. The trailer defines any
records in the interchange that appear after the end of the last document message. After
adding the flat-file disassembler component to a custom receive pipeline, set the Document
schema, Header schema, and Trailer schema properties of the flat-file disassembler pipeline
component to schemas you have created that match the header, body, and trailer of the
interchange that will be processed. Each flat-file disassembler must be associated with only
a single message type, so it is necessary to create a separate receive pipeline for each type
of flat file that your BizTalk Server system will be processing.
Once the interchange is processed, each resulting message will be sent on through the
remaining stages (validation and party resolution) individually.
XML Interchanges
Since BizTalk Server comes with a default XML receive pipeline, it is typically not necessary
to create custom pipelines to process XML documents. BizTalk Server evaluates each
received XML message to determine its document type (this is the combination of the
namespace and root node) and then locates any deployed schema that matches the
message instance. In this way, the standard pipeline can be used to process any type of XML
message. If a custom pipeline is defined with a collection of XML schemas specified in the
XML disassembler, that pipeline can be used with only the specified message types. All other
messages will be suspended. This is useful if you want to limit the types of messages
processed through a given pipeline.
When a message that represents an interchange is received, BizTalk Server evaluates the
document type of the message and then locates the appropriate schema (known as the
envelope schema). Envelope schemas have two special BizTalk Server properties that specify
that these messages will be split into individual messages to be processed and saved to the
MessageBox. The first property is the Envelope property, which you will find in the reference
section of the Properties window when the Schema node is selected. The Root node of the
schema has a Body XPath property in the Parse section, which is used only when the schema
is an envelope. This expression should be set to identify the immediate parent node of the
body messages.
For example, assume that you must process the following message, which contains multiple
updates. You want to split up the batch so that each update is processed separately by an
orchestration that can process only a single update at a time.
<Batch Department=“Sales">
<Updates>
<CustomerUpdate CustID=“12345" Address=“123 My Street" />
<CustomerUpdate CustID=“12346" Address=“246 Your Street" />
<CustomerUpdate CustID=“98765" Address=“564 Any Street" />
</Updates>
</Batch>
You must first create a CustomerUpdate.xsd schema. This schema has no special properties
and could in fact be the same schema that you are processing individual updates with
already:
<CustomerUpdate CustID=“12345" Address=“12345 My Street" />
Next, you must create an envelope schema that represents the rest of the message with an
Any Element element in place of the <CustomerUpdate> section. The Body XPath expression
would identify the <Updates> section.
<Batch Department=“Sales">
<Updates>
<ANY Element>
</Updates>
</Batch>
When these two schemas are deployed and an interchange message is received, BizTalk
Server will identify the envelope schema, and when it encounters the Body XPath node, it
will emit one message for each child within that node.
If this same envelope is used to process other types of updates, vendor updates for example,
only the vendor update schema needs to be created. A single update message can now
contain both the vendor and customer updates.
Testing an Envelope Schema
Using BizTalk Server tools to test envelope schemas.
Overview
Pipeline Tools is a set of tools that are used for execution, debugging, and profiling of
pipelines and pipeline components, namely flat-file and XML assembler and disassembler
components. The individual tools are as follows:
 Pipeline.exe. This tool executes a specific send or receive pipeline. It accepts one or
more input documents and their parts, XSD schemas and their related information,
and after a pipeline execution, it produces an output document.
 FFAsm.exe. This tool executes the flat-file assembler component, directly invoking it,
and then it emulates a send pipeline, thereby enabling the user to see how the send
pipeline processes (serializes/assembles) the user’s XML document into a flat-file
document.
 FFDasm.exe. This tool executes the flat-file disassembler component, directly
invoking it, and then emulates a receive pipeline, thereby enabling the user to see
how the receive pipeline processes (parses/disassembles) the user’s flat-file
document into one or more XML documents.
 XMLAsm.exe. This tool executes the XML assembler component, directly invoking it,
and then emulates a send pipeline, thereby enabling the user to see how the send
pipeline processes (serializes/assembles/envelopes) the user’s XML document into
an output XML document.
 XMLDasm.exe. This tool executes the XML disassembler component, directly
invoking it, and then emulates a receive pipeline, thereby enabling the user to see
how the receive pipeline processes (parses/disassembles/un-envelopes) the user’s
XML document into one or more XML documents.
Note: You can find these tools in the <Installation Path>\SDK\Utilities\PipelineTools folder.
Demonstration: Creating and Testing a Pipeline
Learn how to create a receive pipeline and a send pipeline and use the command-line tool to test
a pipeline.
Create a Receive Pipeline

New Item.
3. In the Add New Item dialog box, click Receive Pipeline, rename the pipeline
ReceivePurchaseOrders.btp, and then click Add.
4. Click the Decode stage.
The Decode stage can contain up to 255 individual components, all of which will
be executed in sequence.
5. Drag a MIME/SMIME decoder component from the Toolbox to the Decode stage of
the pipeline.
The MIME/SMIME Decoder component can decrypt and/or sign-validate an
incoming message.
6. Click the MIME/SMIME decoder component.
7. In the Properties window, change the Allow non MIME message property to True.
This property indicates whether to allow non-MIME messages to be passed to
the decoder.
8. Click the Disassemble stage.
The Disassemble stage can contain up to 255 individual components, of which
the first matching component will be the only one executed.
9. Drag an XML disassembler component and a Flat file disassembler component from
the Toolbox to the Disassemble stage of the pipeline.
The XML disassembler component can be used to remove message envelopes,
disassemble interchanges, and promote message content to message context.
The flat file disassembler component is used to parse raw data into one or more
documents and optionally remove headers and/or trailers.
Only one of the components will run in the Disassemble stage. If the XML
disassembler reports that it cannot process the message, the message will be
passed on to the Flat file disassembler.
10. Click the Flat file disassembler pipeline component.
11. In the Properties window, from the Document schemas drop-down list, select
Demo.Messaging.SalesOrder_FF.
This schema represents the message format of the flat file.
12. Click the Validate stage.
The Validate stage can contain up to 255 individual components, all of which will
13. Drag an XML validator component from the Toolbox to the Validate stage of the
pipeline.
Use the XML validator pipeline component to verify the message against the
specified schema or schemas. If the message does not conform to these schemas,
the component raises an error, and the message is placed in the suspended
queue.
14. Click the XML validator component.
15. In the Properties window, click the ellipsis (…) button next to Document schemas.
16. In the Schema Collection Property Editor dialog box, click
Demo.Messaging.SalesOrder_FF, click Add, and then click OK.
The disassembler components do not validate the message during processing.
Add the XML validator component to ensure that the message conforms to the
document schema.
Setting the XML dissassembler’s Validate Document Structure property to true
will only instruct it to check for well-formed XML, it will not enable validation
against a schema.
17. Click the ResolveParty stage.
The ResolveParty stage can contain up to 255 individual components, all of
which will be executed in sequence.
18. Drag a Party resolution component from the Toolbox to the ResolveParty stage of
the pipeline.
The Party Resolution pipeline component maps the sender’s security identifier to
the corresponding BizTalk Server party.
Create a Send Pipeline

New Item.
2. In the Add New Item dialog box, click Send Pipeline, rename the pipeline
SendProcessedOrders.btp, and then click Add.
3. Click the Pre-Assemble stage.
The Pre-Assemble stage can contain up to 255 individual components, all of
which will be executed in sequence. There are no standard pipeline components
for the Pre-Assemble stage. If you require processing in the Pre-Assemble stage,
you will need to create a custom pipeline component to do so.
4. Click the Assemble stage.
The Assemble stage can contain up to 255 individual components, all of which
will be executed in sequence.
5. Drag an XML assembler component from the Toolbox to the Assemble stage of the
pipeline.
The XML assembler component inserts the values of promoted properties in to
the message body. It can also be used to insert processing instructions, and to
create interchange messages.
6. Click the Encode stage.
The Encode stage can contain up to 255 individual components, all of which will
7. Drag a MIME/SMIME encoder component from the Toolbox to the Encode stage of
the pipeline.
The MIME/SMIME encoder component can be used to encode, sign, or encrypt
an outgoing message with encryption and signing certificates.
8. On the File menu, click Save All, and then close the two pipelines.
Execute the Assembly/Disassembly Components with Command-line Tools

1. In Solution Explorer, double-click InterchangeMessage.xml.
Notice that the message has an ItemsList section, which contains sender and
batch number information. The message also has an Items node, which contains
four Item nodes.
2. In Solution Explorer, double-click InterchangeEnvelope.xsd.
Notice that the InterchangeEnvelope schema has an ItemsList record, which
contains the ItemHeader and Items nodes. The Items node contains an Any
Element.
3. In Solution Explorer, double-click InterchangeBody.xsd.
Notice that the InterchangeBody schema contains the Item record, which
represents the individual messages of the interchange.
5. In the Open box, type cmd, and then click OK.
6. In the command prompt window, type path = %path%;”C:\Program Files
(x86)\Microsoft BizTalk Server 2010\SDK\Utilities\PipelineTools”, and then press
ENTER.
7. In the command prompt window, type cd
C:\AllFiles\DemoCode\Module6\Demo\Messaging, and then press ENTER.
8. In the command prompt window, type xmldasm InterchangeMessage.xml -ds
InterchangeBody.xsd -es InterchangeEnvelope.xsd –c, and then press ENTER.
The preceding command uses the xmldasm utility; xmldasm is used to simulate
the use of an XML disassembler component in a pipeline. The parameters used
are: message (InterchangeMessage.xml), -ds (document schema =
InterchangeBody.xsd), -es (envelope schema = InterchangeEnvelope.xsd) and –c
(display results in the console).
9. Four messages representing the four items in the list are displayed.
10. Close the Visual Studio solution and all other open windows.
Lab: Creating Pipelines
Scenario
Pipelines allow you to customize the processing of messages within send or receive ports. In
this lab, you will create and test a custom send pipeline that encrypts communications
between Adventure Works and Woodgrove Bank. Next, you will configure a receive pipeline
that splits a batch of messages (an interchange) to be processed as individual messages.
Finally, you will enable recoverable interchange processing to address issues that arise from
malformed messages within the batch.
Procedure List
window.
Start.
7. At the Windows Activation prompt, click Ask Me Later, then click OK.

Procedure List
Exercise 1: Configure a Send Pipeline to Encrypt Outgoing Messages
Overview
Communicating with trading partners often requires that messages be encrypted. In this
exercise, you will create a custom pipeline that will be used to encrypt messages being
exchanged with Woodgrove Bank. You will then deploy the project with the newly added
pipeline.
Add a New Send Pipeline to the Messaging Project

Procedure List
1. In Windows Explorer, navigate to C:\AllFiles\LabFiles\Lab6\AdvWorks, and then
open the AdvWorks.sln file.
New Item.
3. In the Add New Item – Messaging dialog box, in the left pane, click Pipeline Files,
and then in the center pane, click Send Pipeline.
4. In the Name box, type EncryptionPipeline.btp, and then click Add.
The newly added pipeline opens in the Pipeline Designer.
Add an XML Assembler Pipeline Component to the Pipeline

Procedure List
1. Drag the XML assembler from the Toolbox to the Drop Here box in the Assemble
stage of the pipeline.
Add and Configure a MIME/SMIME Pipeline Component to the Pipeline

Procedure List
1. Drag the MIME/SMIME encoder from the Toolbox to the Drop Here box in the
Encode stage of the pipeline.
2. Right-click the MIME/SMIME encoder, and select Properties.
3. In the MIME/SMIME encoder Properties window, in the Check revocation list box,
click False.
4. In the Enable encryption box, click True.
5. In the Send body part as attachment box, click True.
Deploy the Messaging Project

Procedure List
1. In Solution Explorer, right-click Messaging, and then click Deploy.
Exercise 2: Configure a Send Port with the Encryption Pipeline and
Certificate
Overview
In order to process encrypted messages, a certificate must be installed on the computer
running BizTalk Server that will process the message. In this exercise, you will install the
certificate used to encrypt messages, configure the send port to use the Encryption Pipeline,
and specify the encryption certificate.
Attempt to Assign an Encryption Certificate

Procedure List
3. In the right-pane, double-click CreditOrdersFILE.
4. In the Send Port Properties dialog box, in the Send pipeline list, click
EncryptionPipeline, and then click Apply.
5. In the left pane, click Certificate, and then in the right-pane, click Browse.
Notice that there are no certificates that can be used to encrypt.
6. Click Cancel.
Install the WoodGrove Encryption Certificate

Procedure List
2. In the Run box, type mmc, and then press ENTER.
3. In the Console1 window, on the File menu, click Add/Remove Snap-in.
4. In the Add or Remove Snap-ins dialog box, in the Available snap-ins list, double-
click Certificates.
5. In the Certificates snap-in dialog box, click Computer account, then click Next, and
then click Finish.
6. In the Add or Remove Snap-ins dialog box, click OK.
7. In the Console1 window, expand the Certificates (Local Computer) node.
8. Right-click Other People, point to All Tasks, and then click Import.
9. On the Welcome to the Certificate Import Wizard page of the Certificate Import
Wizard, click Next.
10. On the File to Import page, click Browse.
11. In the Open dialog box, navigate to
C:\AllFiles\LabFiles\Lab6\AdvWorks\WoodGroveCert, click WoodGrove.cer, and
then click Open.
12. On the File to Import page, click Next.
13. On the Certificate Store page, click Next, and then click Finish to close the
Certificate Import Wizard.
14. In the Certificate Import Wizard message box, click OK.
15. In the Console1 window, expand the Other People node, and then click Certificates.
16. In the Issued To column, double-click Woodgrove.
Notice that Microsoft Windows does not have enough information to verify this
certificate.
17. Click the Certification Path tab.
Notice the bottom pane reads: “The issuer of the certificate could not be found.”
This indicates that the issuer is not in the list of trusted certificate authorities.
18. Click OK to close the Certificate window.
Install the WoodGrove Encryption Certificate Chain

Procedure List
1. In the left pane of the Console1 window, click Trusted Root Certification
Authorities.
2. In the right pane, right-click Certificates, point to All Tasks, and then click Import.
3. On the Welcome to the Certificate Import Wizard page, click Next.
C:\AllFiles\LabFiles\Lab6\AdvWorks\WoodGroveCert, click
WoodGroveCACertChain.cer, and then click Open.
6. Click Next twice to accept the default configurations, and then click Finish.
8. In left pane of the Console1 window, expand Trusted Root Certification Authorities,
and then click Certificates.
9. In the right pane, double-click WoodGroveCA to examine the certificate properties.
10. Click OK.
11. In the left pane of the Console1 window, under Other People, click Certificates.
12. Double-click Administrator to examine the certificate properties.
Notice that this certificate is now valid.
14. Close the Console1 window, and then click No when asked to save changes.
Assign the WoodGrove Encryption Certificate to the Send Port

Procedure List
1. In the CreditOrdersFILE - Send Port Properties dialog box, on the Certificate tab,
click Browse.
Notice that the certificate you just installed now appears.
2. Click OK to select the certificate, and then click OK to close the Send Port Properties
window.
Test the Encryption Pipeline

Procedure List
1. In the BizTalk Server Administration Console, right-click AdventureWorks, and then
click Start.
2. In the Start ‘AdventureWorks’ Application dialog box, click Start.
4. Copy CredSalesOrder1.xml and CredSalesOrder2.xml to the SalesOrderIN folder.
5. Open the SalesOrderIN folder to verify that the messages have been processed.
6. In Windows Explorer, navigate to the CreditOrders folder.
7. Right-click one of the XML files, and then click Edit to open the file in Notepad.
Notice that the message has been encrypted.
8. Close Notepad.
9. In Windows Explorer, navigate to the AllOrders folder.
10. Open one of the XML files in Notepad.
Notice that this file is not encrypted.
11. Close Notepad.
12. In Windows Explorer, delete all XML files from the AllOrders and CreditOrders
folders.
Exercise 3: Examine the Interchange Message to Be Disassembled
Overview
An interchange, also known as a message batch, is a single message that contains multiple
nested messages. A pipeline can be used to split an interchange into smaller messages. In
this exercise, you will examine the sample interchange message that the pipeline you create
will split.
Examine the Interchange Message

Procedure List
1. In Windows Explorer, navigate to and open C:\AllFiles\LabFiles\Lab6\
SalesOrder_FF_Interchange.txt in Notepad.
Notice that this interchange contains a cash (Cash) transaction message and two
credit (Cred) transaction messages. Also notice that the first line contains the
batch information. This first line is known as the batch header.
2. Close Notepad.
Exercise 4: Configure a Receive Pipeline to Disassemble a Message
Interchange
Overview
Disassembler components in custom flat file pipelines can be configured to split
interchanges by defining separate header and body schemas. The header schema represents
the introductory portion of a batch. The header typically contains information common to all
messages in the batch. In this exercise, you will import a header schema and create a
pipeline to process the batch of flat file sales order messages submitted by the retail stores.
A second disassembler in the pipeline will allow processing of individual sales orders.
Add the Header Schema to the Messaging Project

Procedure List
Item.
2. Navigate to C:\AllFiles\LabFiles\Lab6\AdvWorks\Artifacts, click BatchHeader.xsd,
and then click Add.
3. In Solution Explorer, double-click BatchHeader.xsd.
4. In the BizTalk Editor, expand Batch, expand BatchDetail, and then click
ManagerName.
Notice the ManagerName and EmailAddress nodes in the schema. These fields
represent the header information for the interchange.
5. Close the BatchHeader.xsd schema. If prompted to save your changes, click Yes.

Procedure List
1. In Solution Explorer, right-click Messaging, point to Add, and then click New Item.
2. In the left pane, click Pipeline Files, in the center pane, click Receive Pipeline, in the
Name box, type ReceiveSalesOrderInterchange.btp, and then click Add.
Add a Flat File Disassembler Pipeline Component to the Pipeline

Procedure List
1. Drag the Flat file disassembler from the Toolbox to the Disassemble stage of the
pipeline.
2. Drag a second Flat file disassembler to the pipeline, below the one you just added.
3. Click the first Flat file disassembler, and then in the Properties window, in the
Document schema box, click AdvWorks.Messaging.SalesOrder_FF.
4. In the Header schema box, click AdvWorks.Messaging.BatchHeader.
5. Click the second Flat file disassembler, and then in the Properties window, in the
Only the first Flat file disassembler component that matches the incoming
message will be used on the message. This means that this pipeline will be able
to process messages in the SalesOrder_FF format, both as single messages and
as part of an interchange.

Procedure List
You may receive warnings regarding the SalesOrder_To_LoanApp map; these
warnings can safely be ignored. Also notice the warning that states: “If any of
the assemblies were previously loaded by a Host Instance, it may be necessary to
restart the Host Instance for changes to take effect.” If the Error List pane is not
visible at the bottom of the screen, click Error List on the View menu.
Exercise 5: Configure a Receive Location to Use the Pipeline
Overview
The pipeline used to process inbound messages is configured on the receive location. In this
exercise, you will create a new receive location that is associated with the existing
SalesOrder port and configure it to use the ReceiveSalesOrderInterchange pipeline. This
configuration will allow receiving and processing of XML orders, flat file orders, or flat file
interchange messages.
Create a New Receive Location for Flat File Message Receipt
Procedure List
BizTalk Group, and Platform Settings, and then click Host Instances.
2. Right-click BizTalkServerApplication, and then click Restart.
The BizTalk host instance associated with an assembly needs to be restarted
whenever the assembly is updated. Otherwise, the old copy of the assembly will
remain in memory.
3. Under Applications, right-click AdventureWorks, and then click Refresh.
4. In the BizTalk Server Administration Console, click AdventureWorks.
5. Right-click Receive Locations, point to New, and then click One-way Receive
Location.
6. In the Select a Receive Port dialog box, select SalesOrder, and then click OK.
FFSalesOrderFILE.
10. Expand C:\AllFiles\LabFiles\Lab6, click SalesOrderIN, and then click OK.
11. In the FILE Transport Properties dialog box, in the File mask box, type *.txt, and
then click OK.
ReceiveSalesOrderInterchange, and then click OK.
13. In BizTalk Server Administration Console, in the left pane click Receive Locations, in
the right pane, right-click FFSalesOrderFILE, and then click Enable.
Exercise 6: Submit Test Messages
Overview
A successfully processed interchange message will result in multiple individual messages. By
default, any invalid interchange messages will be suspended. In this exercise, you will submit
two test messages: an interchange message containing valid data and an interchange
message containing invalid data.
Submit a Valid Interchange Message

Procedure List
2. Copy SalesOrder_FF_Interchange.txt to the SalesOrderIN folder.
Notice that the message has been processed and moved from this folder.
Notice that all three documents from the batch appear in this folder.
5. Double-click any one of the documents.
Notice that the message has been changed to the SalesOrder format.
6. Close Microsoft Internet Explorer®.
8. Right-click the document of your choice, and then click Edit.
Notice that the file is encrypted and the message content cannot be read.
9. Close the document.
10. In Windows Explorer, navigate to the CashOrders folder.
Notice that the CASH order was processed successfully.
11. In Windows Explorer, delete all XML files from the AllOrders, CashOrders, and
CreditOrders folders.
Submit an Invalid Interchange Message

Procedure List
1. In Windows Explorer, navigate to the Lab6 folder, and then open
SalesOrder_FF_InterchangeBADDATA.txt.
Notice that the batch contains a normal Cash message, a normal Cred message,
and a Cred message that contains {BADDATA}.
3. Copy SalesOrder_FF_InterchangeBADDATA.txt to the SalesOrderIN folder.
Notice that the messages do not appear in this folder.
7. In the BizTalk Server Administration Console, right-click BizTalk Group, and then
click Refresh.
8. In the center pane, in the Group Hub tab, Under Suspended Items, click Resumable.
Notice that the Query results pane shows one item that is suspended.
9. In the Preview pane, double-click the suspended SalesOrder message.
10. In the Service Details dialog box, click the Error Information tab.
Notice the error description.
11. Click the Messages tab, and then double-click the suspended message.
12. In the Message Details dialog box, click body.
This dialog box can be used to examine the message body to locate the invalid
information.
13. Close the Message Details dialog box, and then click OK to close the Service Details
dialog box.
14. In the Query results pane, right-click the suspended message, and then click
Terminate Instance.
15. In the Confirm Terminate Operation dialog box, read the message, and then click
Yes.
16. In the BizTalk Server Administration message box, click OK.
Exercise 7: Enable and Test Recoverable Interchange
Overview
Enabling recoverable interchange processing allows the valid messages of an interchange to
be successfully processed, while any bad messages are individually suspended. In this
exercise, you will enable a recoverable interchange for a pipeline, and then test the pipeline
by submitting two messages.
Enable Recoverable Interchange Processing

Procedure List
1. In the BizTalk Server Administration Console, under AdventureWorks, click Receive
Locations, and then double-click FFSalesOrderFILE.
2. In the Receive Location Properties dialog box, next to the Receive pipeline list, click
the ellipsis (…) button.
3. In the Configure Pipeline dialog box, under Disassemble – Component(1), in the
RecoverableInterchangeProcessing list, click True, and then click OK.
4. In the Receive Location Properties dialog box, click OK.
Submit an Interchange Message that contains bad data

Procedure List
Notice that the messages have been processed and moved from this folder.
4. Navigate to the AllOrders folder.
Notice that two messages have been added to this folder.
5. Navigate to the CashOrders folder.
Notice that the Cash message from the batch file has been added to this folder.
6. Navigate to the CreditOrders folder.
Notice that only one Cred message has been added to this folder. The Cred
message that contains bad data has been suspended.
Module 7: Integrating with Adapters
Module objective:
In this module, you will learn how to identify the various adapter types and how to configure
adapters for use in an integration scenario.
Overview
Because Microsoft® BizTalk® Server 2010 must be able to exchange messages with a variety
of other systems and applications, specialized adapters are required. An adapter is a COM or
Microsoft .NET–based software component that provides the functionality required to
interface with different types of applications and sometimes proprietary communications
mechanisms. This module explains how adapters work and shows you how to configure
specific types of adapters that are included with BizTalk Server 2010.
Lesson 1: Introduction to BizTalk Adapters
Lesson objective:
Describe how adapters are used to create integration solutions and how the BizTalk Adapter
Framework can be used to create custom adapters.
Introduction
BizTalk Server 2010 includes a number of adapters that can access common data storage
locations, such as email servers, file servers, web servers and SharePoint servers. BizTalk
Server 2010 also offers a variety of adapters for connecting to third-party applications. This
lesson shows you how to use adapters to connect BizTalk Server to external systems and
applications.
What Is an Adapter?
Explain what adapters are and how they are used.
Adapters
BizTalk adapters are the first and last software components used by BizTalk Server to
exchange messages with disparate applications and systems. An adapter is a software
component that enables messages to be received or sent by BizTalk Server using a specific
delivery mechanism. This mechanism is commonly a recognized standard, such as HTTP, FTP,
or POP3, but it could also be a method of communicating with a proprietary third-party
application, such as a vendor’s Enterprise Resource Planning (ERP) application.
How Adapters Work

The role of an adapter is to enable communications between BizTalk Server and external
systems and trading partners. Users configure adapters by creating send ports and receive
locations that define the properties for given instances of the adapter. Most adapters
support both send and receive operations, whereas other adapters support communication
in only one direction.
A receive adapter works in conjunction with a receive port and a receive pipeline to retrieve
messages from the source location (an endpoint); it saves the messages in the MessageBox
database. Each receive adapter has specific context information about the message
(metadata) that is associated with the protocol that it supports. This metadata can include
information such as the original file name, the time the message was received, and the
sender information. The metadata is saved along with the message data and can be
accessed by send ports, send port groups, and orchestrations when necessary for routing
purposes and to make general processing decisions within an orchestration. For sending
messages, the send port adapter and pipeline work together via the messaging engine to
send the message from the MessageBox database to a specific endpoint.
Sources of Adapters
Describe several sources for BizTalk Server adapters.
Adapter Sources
You can acquire an appropriate BizTalk adapter through four primary sources:
Standard BizTalk Server 2010 adapters. These adapters, also known as native adapters, are
included in the installation of BizTalk Server 2010. The standard adapters include Base EDI,
FILE, FTP, HTTP, WebsSphere MQ, MSMQ, POP3, SMTP, SOAP, SharePoint and WCF
adapters. Multiple instances of each adapter can be configured by adding multiple receive
locations and send ports. The FTP adapter has been improved, adding support for secure
FTP.
BizTalk Server 2010 Adapter Pack. Microsoft makes available additional specialized adapters
for connecting BizTalk Server to a number of proprietary systems. The release of the BizTalk
Server 2010 Adapter Pack includes updated adapters that support the latest versions of JD
Edwards, Oracle eBS, SAP and Siebel. These adapters can be installed individually as
required. A complete list of the BizTalk Server 2010 adapters is available on the Microsoft
web site.
Third-party adapters. Third-party adapters can be purchased by companies who specialize in
developing adapters or from companies that provide adapters to enable integration with
their proprietary applications. Examples of third-party adapters include Lotus Notes, and
CICS. Once the adapter has been installed, you can use the BizTalk Administration console to
configure these adapters. If an adapter is no longer required, it can be removed without the
need to reconfigure the BizTalk application.
Custom adapters. A custom adapter could be required if no adapter exists for a system or
application to integrate with BizTalk Server 2010. Microsoft provides the BizTalk Adapter
Framework documentation and a software development kit (SDK) toolkit for developers to
use for creating custom adapters.
What Is the BizTalk Adapter Framework?
Describe the purpose of the BizTalk Adapter Framework.
Adapter Framework
Microsoft provides the BizTalk Adapter Framework to enable developers to create custom
adapters for interfacing and integrating with a proprietary system or with a system
unsupported by existing adapters. This framework provides a common means of creating
and implementing adapters and includes the specifications for building BizTalk adapters
using open standards based on Web Services. The Adapter Framework consists of a set of
extensible APIs that enable developers to access relevant BizTalk Server services used to
integrate applications and platforms. Once an adapter has been built for BizTalk Server by
using the Adapter Framework, the standard BizTalk administration tools can be used to
manage and configure the adapter. The Adapter Framework is provided as part of the
BizTalk Server 2010 product SDK.
Lesson 2: Configuring a BizTalk Adapter
Lesson objective:
Describe how to configure the three types of BizTalk adapters.
Overview
Configuring a BizTalk Server 2010 adapter involves setting the properties required for the
adapter to communicate among BizTalk Server, external systems and trading partners. In
this lesson, you will learn about the difference between a protocol adapter, a WCF adapter,
and an application adapter, and you will learn how to configure adapters.
Configuring an Adapter
Describe how to configure the FILE adapter.
Adapter Configuration
Each adapter must be configured with specific properties to enable it to function. The
properties differ depending on how the adapter will connect to the intended endpoint. For
example, an FTP adapter has specific settings that are unique to the FTP protocol and the
specific FTP server that it must connect to. This includes properties such as the polling
interval, logon user name, and the password. Obviously, these properties would not be
appropriate for the FILE adapter.
Adapters also have default global properties that can be modified through the BizTalk
Administration console. The global settings are augmented or can be overridden for a
specific adapter that is configured though a receive or send port. Because adapter
configurations contain potentially sensitive information, such as connection strings and
logon credentials for external systems, the configuration information is encrypted and
stored in the Single Sign-On (SSO) database at design time. At run time, the Messaging
Engine retrieves the configuration for the adapter.
You can add instances of an adapter by using the BizTalk Administration console.
File Adapter
The FILE receive adapter reads files from a folder on the local file system or on a network
share. Secure access through the network share can be maintained by setting appropriate
user account permissions and configuring the adapter to use the required user account. The
FILE receive adapter creates a BizTalk Message object so that BizTalk Server can process the
message.
The FILE send adapter transmits messages from the MessageBox database to a specified
destination address. The destination address is defined by a file path and file name using
macros (wildcard characters) related to the message context properties. The FILE send
adapter gets the message content from the body of the BizTalk Message object, and after
the message is processed by the pipeline, the adapter writes the message to a file and then
deletes the message from the MessageBox database. The FILE adapter writes files to the file
system either directly or by using the lazy write-behind cache, which can improve
performance, particularly for large files.
Integrating with Protocol Adapters
Identify and describe BizTalk protocol adapters.
Protocol Adapters
Protocol adapters process messages by using common networking protocols. The protocol
adapters that are included with a BizTalk Server 2010 installation include:
FTP. The FTP adapter enables you to move messages between BizTalk Server and an FTP
server. The FTP receive adapter allows you to pull files from the FTP server on demand by
polling on a configurable schedule. The FTP send adapter sends messages to the configured
FTP site on demand. BizTalk Server 2010 includes an improved FTP adapter that supports
secure FTP, and it can also handle downloading from read-only locations. The new FTP
adapter maintains a list of previously downloaded file names to avoid reading the same file
more than once. The list is stored in the MessageBox database.
HTTP. The BizTalk HTTP adapter provides support for communication with external systems
by using industry-standard HTTP GET and PUT functionality. You can also configure
appropriate proxy settings to support your network configuration. As is the case with most
of the adapters, there are also several new performance counters for the HTTP adapter
available to you in Performance Monitor.
MSMQ. With the BizTalk 2010 adapter for MSMQ, you can send and receive messages to
Microsoft Message Queuing (MSMQ) queues. This adapter works with transactional and
non-transactional, public and private, and local and remote queues. The MSMQ BizTalk
adapter supports large messages (greater than 4 MB) and provides access to other features,
such as messaging over HTTP and multi-cast messaging.
POP3. The POP3 adapter is a built-in adapter that enables BizTalk applications to poll for e-
mail messages and their attachments from a mailbox by using the POP3 protocol. The POP3
adapter can be used to retrieve e-mail messages from Microsoft Exchange, the Windows
Server POP3 Service, or any third-party POP3-compliant system. Configurable properties for
the POP3 adapter include mandatory properties such as the name of the mail server, the
user name and password for the mail server, and the polling interval. All of these settings
are securely stored in the Enterprise Single Sign-On (SSO) database.
SMTP. The Simple Mail Transfer Protocol (SMTP) adapter enables messages to be sent to
other applications by creating an e-mail message and delivering it to a specified e-mail
address. The target e-mail address is a property of the SMTP adapter. By default, the
message text of SMTP messages is plain text, but you can also configure the adapter to use
the contents of an HTML file or a text file as the message body. These features, plus the
ability to send multiple attachments, are new features of the SMTP adapter for BizTalk
Server 2010.
WebSphere MQ. The WebSphere MQ adapter acts as a bridge between BizTalk Server and
an IBM WebSphere MQ messaging system. You can use this adapter to send and receive
messages from local and remote queues, transmission queues, and alias queues. One new
feature of the WebSphere MQ adapter is the ability to perform dynamic receives as part of
solicit-response.
SOAP. The SOAP adapter has been superseded by the WCF adapters. It is still included with
BizTalk Server 2010 in order to maintain backward compatibility. The SOAP adapter actually
consists of two adapters: the SOAP receive adapter and the SOAP send adapter. The SOAP
receive adapter works through the Microsoft ASP.NET runtime via Web services and passes
messages to BizTalk Server through the Isolated Host adapter. The SOAP send adapter is
used to call a Web service from BizTalk Server. This adapter also supports SSO, which is used
for secure access through Web services.
FTP Adapter Improvements in BizTalk Server 2010
Describe the new and enhanced features of the FTP adapter available in BizTalk Server 2010.
Secure File Transfers

The FTP adapter in BizTalk Server 2010 provides support for file transfers from an FTPS
server over Secure Sockets Layer (SSL)/Transport Level Security (TLS). SSL/TLS ensures data
confidentiality through encryption. You must enable the secure mode by configuring SSL-
specific properties provided by the adapter. Because the adapter allows for both reading
and writing data from a secure FTP server, the SSL-specific properties are available when
configuring send handlers/ports and also with receive handlers/locations.
Support for Downloads from Read-only Locations

In the previous releases of BizTalk Server, the FTP adapter deleted the file after downloading
so that the file didn’t download again in the next polling cycle. Due to this design, the
adapter was limited to download files only from FTP locations that provided write access.
In BizTalk Server 2010, the FTP adapter supports download of files from read-only file
locations. The adapter now maintains a list of downloaded files in a database. For the next
download, the list of files on the FTP server is compared to the list of files maintained by the
adapter, and only new files on the server are downloaded. To support scenarios where an
existing file is updated between two downloads, you can configure the adapter to also check
file timestamps
Support for Atomic Transfer in ASCII Mode

The FTP adapter available with the previous releases of BizTalk Server provided atomic file
transfer only for binary mode. In BizTalk Server 2010, the FTP adapter is enhanced to also
support atomic file transfer for ASCII mode. To enable atomic file transfer for ASCII mode,
the adapter uses the Temporary Folder property. This property defines a temporary location
on the FTP server where the file is first moved to. After the file is completely transferred to
the temporary location, the file is then moved to the relevant location on the FTP server.
Here, the assumption is that the file transfer is atomic between the temporary location and
the relevant location on the FTP server.
Demonstration: Configuring a Protocol Adapter
Learn how to create a receive port and a receive location configured with the FTP adapter.
The following demonstration is dependent upon the completion of the

demonstrations contained in Module 5, “Routing BizTalk Messages.” If you have not
already completed the demonstrations in this module, deploy the Messaging project
in the C:\AllFiles\DemoCode\Module7\Demo folder, import the
Demo.Bindings.Complete.xml binding file from C:\AllFiles\DemoCode\Module5, and
then start the Demos application.
Configure the FTP Adapter on a Receive Location

1. Open the BizTalk Server Administration Console, and then expand BizTalk Server
Administration, BizTalk Group, Applications, and then click Demos.
2. Right-click Receive Ports, point to New, and then click One-way Receive Port.
3. In the Receive Port Properties dialog box, in the Name box, type Shipments, and
then in the left pane of the Receive Port Properties dialog box, click Receive
Locations.
4. Click the New button.
5. In the Receive Location Properties dialog box, in the Name box, type ShipmentsFTP,
in the Type list, click FTP, and then click Configure.
Here you are creating a receive location that will use the FTP adapter to pick up
messages for processing by the orchestration.
6. In the FTP Transport Properties dialog box, under the FTP section, in the Folder box,
type ShippedOrders.
7. In the File Mask box, type *.xml.
8. In the Password box, type pass@word1.
9. In the Server box, type BIZTALKDEMO.
10. In the User Name box, type Administrator, and then click OK.
12. In the Receive Port Properties dialog box, click OK.
Integrating with WCF Adapters
Describe how the BizTalk WCF adapters are used to send and receive messages.
Introduction
Windows Communication Foundation (WCF). The BizTalk WCF adapters allow BizTalk Server
to communicate with service-based interfaces of other applications, including database
servers such as SQL Server 2008 and Oracle 11g. The WCF adapters offer a new and more
flexible way to access data. The BizTalk WCF adapters include five physical adapters that
represent the WCF predefined bindings:
 WCF-WSHttp: This adapter provides WS-* standards support over the HTTP
transport.
 WCF-BasicHttp: This adapter provides communicates with ASMX-based Web
services and clients and other services that conform to the WS-I Basic Profile 1.1.
 WCF-NetTcp: This adapter provides WS-* standards support over the TCP transport.
 WCF-NetMsmq: This adapter provides support for queuing by leveraging Microsoft
Message Queuing (MSMQ) as a transport.
 WCF-NetNamedPipe: This adapter provides secure optimization for on-machine
cross-process communication using named pipes.
 WCF-Custom: This adapter allows you to configure a WCF binding and the behavior
information for the receive location and send port, and take advantage of the WCF
extensibility features.
 WCF-CustomIsolated: This adapter allows you to configure a WCF binding and the
behavior information for the receive location running in an isolated host, and take
advantage of the WCF extensibility features over the HTTP transport.
WCF-Custom Adapter
The WCF-Custom adapter replaces the SQL adapter that was included in previous versions of
BizTalk. With the WCF-Custom adapter, BizTalk Server can exchange messages to and from
a Microsoft SQL Server™ 2008 and Oracle 11g databases. You can use the WCF-Custom
adapter to poll data from one or more data tables or stored procedures and retrieve the
data and place it in a BizTalk messaging solution or into an orchestration as one or more
XML messages. You can also use the WCF-Custom adapter to insert, update, or delete data
in SQL Server 2008 and Oracle 11g tables. This adapter can be configured by using the
BizTalk Administration console.
The WCF adapters will be covered in more detail in Module 13 “Using WCF Receive
Adapters” and Module 14 “Using WCF Send Adapters”.
Demonstration: Configuring a WCF Adapter
Learn how to create WCF-Custom metadata that BizTalk uses to communicate with SQL Server.
This metadata is in the form of a schema and special orchestration port types.
Generate WCF-Custom Adapter MetaData

C:\AllFiles\DemoCode\Module7\Demo\Demo.sln.
Add Generated Items.
4. In the Add Generated Items – Messaging dialog box, click Consume Adapter
Service, and then click Add.
You will use the Add Adapter Wizard to generate a schema, an orchestration, a
special port type, and a multi-part message type, all of which can be used to
update a SQL table
5. In the Consume Adapter Service dialog box, in the Select a binding list, click
sqlBinding, then click Configure.
6. In the Configure Adapter dialog box, on the Security tab, in the Client credential
type list, click Windows.
7. On the URI Properties tab, set the Server property to BIZTALKDEMO. Set the
InitialCatalog property to AdvWorks, and then click OK.
8. In the Consume Adapter Service dialog box, click the Connect button.
9. In the Select a category tree, expand Tables and click [dbo].[LOANS].
10. In the Available categories and operations list, click Insert, and then click Add.
11. In the Filename Prefix box, enter gen-.
12. Click OK to close the Consume Adapter Service dialog box.
This process has created a set of schemas defining the message types that
BizTalk can use to communicate with SQL Server 2008 via WCF.
Examine the WCF-Custom Adapter MetaData

1. Notice that three schema files and an XML file were created, and added in Solution
Explorer. The XML file contains send port configuration settings for the WCF-
Custom adapter.
2. In Solution Explorer, double-click gen-TableOperation.dbo.Loans.xsd.
3. In the Schema Editor, right-click <Schema> and then click Expand Schema Node.
This schema defines the XML message format that can be used to insert rows in
to the LOANS table of the AdvWorks database. Notice the elements listed under
the LOANS element. The names and properties of these elements match those of
the columns of the LOANS table.
4. Right-click the Messaging project, then click Deploy.
5. In BizTalk Server Administration Console, expand Platform Settings, and then click
Host Instances.
6. If the BizTalkServerApplication host instance is already running, right-click on it, and
then click Restart. Otherwise, right-click on it and then click Start.
BizTalk Server 2010 Application Adapters
Describe how the Windows SharePoint adapter is used to send and receive messages to and
from a SharePoint site.
Application Adapters
Application adapters allow BizTalk Server to communicate with certain Microsoft
applications or with third-party applications. BizTalk Server 2010 includes new adapters for
the latest versions of the most popular enterprise applications, including Siebel, Oracle eBS,
and JD Edwards. Additionally, you can write your own custom application adapter by using
the BizTalk Adapter Framework.
Integrating with Application Adapters
Describe how the Windows SharePoint adapter is used to send and receive messages to and
from a SharePoint site.
Windows SharePoint Adapter

The Windows SharePoint adapter enables the sending and receiving of documents through
Windows SharePoint libraries. The receive adapter polls SharePoint document library views.
It calls a Web method on the SharePoint server that uses the SharePoint object model to
browse the library, check out the files, and return the file data to the adapter. The adapter
then submits the files to the BizTalk Server MessageBox and calls another Web method to
delete or archive the files from the SharePoint server. In order to filter files in a SharePoint
library, the adapter polls the SharePoint Services library through a SharePoint view.
On the send side, the SharePoint adapter publishes documents to a SharePoint document
library by calling a Web method on the SharePoint server. The adapter specifies several
properties including the SharePoint site, document library or document list, and the file or
list item name.
Demonstration: Integrating with SharePoint
Learn how to configure the Windows SharePoint adapter to send to and receive messages from a
SharePoint form library.
Configure the SharePoint Receive Adapter by Using the BizTalk Server

Administration Console
2. In the BizTalk Server Administration Console, right-click Receive Ports, point to New,
and then click One-way Receive Port.
3. In the Receive Port Properties dialog box, in the Name box, type LoanApplication.
4. Click Receive Locations, and then click New.
LoanApplicationSharePoint.
6. In the Type list, click Windows SharePoint Services, in the Receive pipeline list, click
XMLReceive, and then click Configure.
7. In the Windows SharePoint Services Transport Properties dialog box, in the General
section, configure the properties as they appear in the following table:
Property Setting
SharePoint Site URL http://BIZTALKDEMO
Source Document Library URL LoanApplications

View Name Evaluated
8. Click OK three times.

9. In the BizTalk Server Administration Console, under the Demos application, click
Receive Locations, right-click LoanApplicationSharePoint, and then click Enable.
Configure the SharePoint Send Adapter by Using BizTalk Server Administration

Console
2. In the Send Port Properties dialog box, in the Name box, type
ProcessedLoansSharePoint.
3. In the Type list, click Windows SharePoint Services, and then click Configure.
4. In the Windows SharePoint Services Transport Properties dialog box, in the General
section, configure the properties as they appear in the following table, and then click
OK.
Property Setting
Destination Folder URL ProcessedLoans
Filename Loan%MessageID%.xml
5. In the Send Port Properties dialog box, click Filters.

6. In the Property list, click BTS.ReceivePortName, and then type LoanApplication in
the Value box.
7. Click OK to close the Send Port Properties window.
8. Click Send Ports, then right-click ProcessedLoansSharePoint, and then click Start.

1. In Windows Explorer, navigate to C:\AllFiles, and then double click
startBtServices.cmd.
2. If you have not already extended the expiration date of the Microsoft Office 2010
version installed in this virtual machine, then double click extend.cmd, also in the
C:\AllFiles folder.
Test the Ports

1. In Microsoft Internet Explorer, browse to http://BIZTALKDEMO/LoanApplications
2. Click LoanApp-200000, and click Open in the File Download dialog box, to open the
document in InfoPath.
3. Click Cancel in the Microsoft Office Activation Wizard window.
4. In the Loan Status list, click Approved, and then on the Home menu ribbon click
Submit.
5. In the Microsoft InfoPath message box, click OK.
6. Close Microsoft InfoPath®.
7. In Internet Explorer, continue to refresh your browser until the message disappears.
This may take up to a minute.
8. In Internet Explorer, navigate to http://BIZTALKDEMO/ProcessedLoans, and then
notice the new message that is there.
Lab: Integrating with Adapters
Scenario
BizTalk Server uses adapters to communicate with external systems and processes.
Adventure Works needs to integrate with several systems. Sales orders can now be sent
from stores as HTTP messages in addition to the file receive process already in place. Loan
applications that require approval are sent to a Microsoft Windows SharePoint Services form
library for manual review. All completed sales orders will be sent to an FTP site. In this lab,
you will configure the HTTP adapter, the FTP adapter, and the Windows SharePoint Services
adapter.
Procedure List
window.
Start.
7. At the Windows Activation prompt, click Ask Me Later, then click OK

Procedure List
Exercise 1: Publishing an InfoPath Form to a SharePoint Library
Overview
Microsoft InfoPath is a program used to create graphical templates (based on XML schemas)
that display XML messages in a user-friendly form. InfoPath can also be used to create new
XML messages based on the template. When combined with Windows SharePoint Services,
the two can provide a portal-based solution for managing XML messages. BizTalk Server,
through the use of the Windows SharePoint Services adapter, can exchange messages with
SharePoint form libraries. In this exercise, you will publish an InfoPath form to a SharePoint
form library. You will then examine a sales order message using the InfoPath form. You will
configure the Microsoft Windows SharePoint Services adapter to monitor and update
SharePoint form libraries in a later exercise.
Publish the LoanApplicationForm InfoPath Form to a SharePoint Site

Procedure List
1. In Windows Explorer, navigate to C:\AllFiles\LabFiles\Common, right-click
LoanApplicationForm.xsn, and then click Design. In the Microsoft Office Activation
Wizard window, click Cancel.
This InfoPath form template is based on the LoanApplication schema. When
completed, the resulting message will be a valid loan application.
2. In the Microsoft InfoPath window, on the File menu, click Publish, and then click the
SharePoint Server icon.
3. In the Microsoft InfoPath window, click OK
4. In the Save As dialog box, navigate to C:\AllFiles\LabFiles\Common, click
LoanApplicationForm.xsn, and then click Save.
5. In the Microsoft InfoPath window, click Overwrite.
6. In the Publish Wizard window, in the Enter the location of your SharePoint site box,
type http://BIZTALKDEMO/, and then click Next.
7. Click Form Library, and then click Next.
8. Click Create a new form library, and then click Next.
9. In the Name box, type LoanApplications, and then click Next.
10. Next to the Column Name box, click Add.
11. In the Select a Field or Group dialog box, expand LoanConditions, and click
LoanStatus.
12. In the Column name box, change the value to Status, and then click OK.
The LoanStatus field of this form will now be displayed as the Status column in
the form library.
13. Click Next, and then click Publish.
14. On the Publishing Wizard confirmation page, check the Open this form library check
box, and then click Close.
15. Close InfoPath.
The SharePoint form library you just created opens in Microsoft Internet
Explorer.
16. On the LoanApplications page, click Add document. In the Microsoft Office
Activation Wizard window, click Cancel.
The form has been successfully published.
17. Close InfoPath and Internet Explorer.
Examine a Sales Order That Was Created by Using the SalesOrderForm InfoPath
Form
Procedure List
1. In Windows Explorer, navigate to C:\AllFiles\LabFiles\Lab7, and then double-click
CashSalesOrder1Info.xml. In the Microsoft Office Activation Wizard window, click
Cancel.
Notice that an InfoPath form has also been created for the Sales Orders.
2. Close CashSalesOrder1Info.xml.
Exercise 2: Configuring and Testing the HTTP Receive Adapter
Overview
The BizTalk Server HTTP receive adapter accepts messages that are sent to Internet
Information Services (IIS). The HTTP receive adapter accepts HTTP POST messages that are
sent to a preconfigured IIS virtual directory, and it publishes the messages to the BizTalk
MessageBox. In this exercise, you will configure and test a new receive location that uses
the HTTP receive adapter to process incoming sales order messages.
Create a Virtual Directory in IIS for the HTTP Receive Adapter

Procedure List
1. On the Start menu, click All Programs, click Administrative Tools, and then click
Internet Information Services (IIS) Manager.
2. In the left pane of the Internet Information Services (IIS) Manager window, expand
BIZTALKDEMO, Sites and Default Web Site.
3. Right-click Default Web Site, then click Add Application.
4. In the Alias box, enter AdventureWorks.
5. Click the Select button and in the Select Application Pool dialog box, choose
BTSHttpPool from the list, then click OK.
The user ID assigned to the BTSHttpPool application pool has been granted the
permissions required to publish messages to the MessageBox.
6. Click the ellipsis (…) next to the Physical path box.
7. In the Browse for Folder dialog box, browse to C:\Program Files (x86)\Microsoft
BizTalk Server 2010\HttpReceive, and then click OK twice.
8. In the Internet Information Services (IIS) Manager window, in the center pane, in the
IIS section, double-click the Handler Mappings icon.
9. In the right pane, click Add Script Map.
10. In the Add Script Map dialog box, in the Request path box, enter
BTSHTTPReceive.dll.
11. Click the ellipsis (…) next to the Executable box, then browse to C:\Program Files
(x86)\Microsoft BizTalk Server 2010\HttpReceive\BTSHTTPReceive.dll, and then
click Open.
12. In the Name box type BizTalk HTTP Receive Adapter, and click OK.
13. In the new Add Script Map dialog box that appears, click Yes.
14. Close the Internet Information Services (IIS) Manager window.
IIS will now execute the BizTalk HTTP receive adapter when HTTP POST messages
are sent to http://biztalkdemo/AdventureWorks/BTSHTTPReceive.dll.
Configure an HTTP Receive Location

Procedure List
1. On the Start menu, click All Programs, click Microsoft BizTalk Server 2010, and then
click BizTalk Server Administration.
BizTalk Group, Applications, AdventureWorks, and then click Receive Locations.
3. Right-click Receive Locations, point to New, and then click One-way Receive
Location.
4. In the Select a Receive Port box, click SalesOrder, and then click OK.
SalesOrderHTTP.
6. In the Type list, click HTTP, and then click Configure.
7. In the HTTP Transport Properties dialog box, in the Virtual directory plus ISAPI
extension box, type /AdventureWorks/BTSHTTPReceive.dll, and then click OK.
9. In the BizTalk Server Administration Console, under Receive Locations, right-click
SalesOrderHTTP, and then click Enable.
Start the AllOrdersFILE Send Port

Procedure List
1. In BizTalk Administration Console, under AdventureWorks, click Send Ports.
2. Right click the AllOrdersFILE send port, and then click Start.
Test the HTTP Adapter

Procedure List
Cancel.
2. On the InfoPath Home menu ribbon, click Submit. In the InfoPath Editor Security
Notice window, click Yes.
The InfoPath form for this document is configured to submit the XML message as
an HTTP POST request to
http://biztalkdemo/AdventureWorks/BTSHTTPReceive.dll
3. Click OK.
4. In Windows Explorer, navigate to C:\AllFiles\LabFiles\Lab7\AllOrders.
5. Open the XML document that appears in this folder.
The Cash Sales Order was received and processed successfully.
6. Close InfoPath, and delete any files in C:\AllFiles\LabFiles\Lab7\AllOrders.
Exercise 3: Configuring and Testing the FTP Adapter
Overview
The FTP adapter allows BizTalk Server to interact with local or remote FTP sites. In this
exercise, you will configure a send port to send all completed cash sales orders to an FTP
site.
Reconfigure the CashOrdersFILE Send Port to Use the FTP Adapter

Procedure List
1. In the BizTalk Server Administration Console, under AdventureWorks, click Send
Ports, and then double-click CashOrdersFILE.
2. In the Send Port Properties dialog box, in the Name box, type CashOrdersFTP.
3. In the Type list, click FTP, and then click Configure.
4. In the FTP Transport Properties dialog box, under FTP, in the Folder box, type
CashOrders.
5. In the Password box, click the drop-down arrow, and then type pass@word1.
7. In the Target File Name box, replace the existing text with Cash%MessageID%.xml.
9. In the Send Port Properties dialog box, in the left pane, click Filters.
Notice that this is the filter expression configured in the module 5 lab.
10. In the Send Port Properties dialog box, click OK.
11. Right click the CashOrdersFTP send port and click Start.
Test the CashOrdersFTP Send Port

Procedure List
Cancel.
2. On the InfoPath Home menu ribbon, click Submit, and then click OK.
3. In Windows Explorer, navigate to C:\AllFiles\LabFiles\Lab7\CashOrders.
Notice that the message you just sent does not appear in the CashOrders folder.
4. In Internet Explorer, go to ftp://BIZTALKDEMO/CashOrders.
5. In the Internet Explorer dialog box, in the User name box, enter Administrator. In
the Password box, enter pass@word1.
6. Open the document that appears in the FTP folder.
Notice the blue text at the top of the message. This text is known as InfoPath
processing instructions. This path specifies where the InfoPath form template
that can be used to display this message is found. Because this message is being
opened from an FTP site that does not have access to the path specified, the
message is opened as a regular XML document. These instructions do not affect
BizTalk Server processing.
Exercise 4: Configuring and Testing the SharePoint Adapter
Overview
The SharePoint adapter enables integration between BizTalk Server and Windows
SharePoint form libraries. You can configure the SharePoint adapter receive location to use a
filtered view to determine which messages should be processed. The SharePoint form library
in this lab is used to manually evaluate loan applications. In this exercise, you will create a
SharePoint view, configure a send port and a receive location to use the Windows
SharePoint Services adapter, and then test the configuration.
Configure and Test a SharePoint Send Port

Procedure List
1. In the BizTalk Server Administration Console, click Send Ports, and then double-click
CreditOrdersFILE.
2. In the Send Port Properties dialog box, in the Name box, type
CreditOrdersSharePoint.
4. In the Windows SharePoint Services Transport Properties dialog box, under
General, configure the properties as they appear in the following table, and then
click OK.
Property Setting
Destination Folder URL LoanApplications
Filename CreditOrder%MessageID%.xml
This is the form library that you created in the first exercise of this lab. All credit
orders received will be sent to this form library for manual approval of the loan.
5. In the Send pipeline list, click XMLTransmit, and then click the ellipsis (…) button.
6. In the Configure Pipeline dialog box, in the ProcessingInstructionsOptions box,
type 1.
Setting the ProcessingInstructionsOptions to ”1” will remove all existing InfoPath
processing instructions and then insert the processing instructions you specify in
the XmlAsmProcessingInstructions box.
C:\AllFiles\LabFiles\Lab7\ProcessingInstructions.txt.
8. Copy all of the text that appears in ProcessingInstructions.txt, and then close
Notepad.
These are the processing instructions for the form that you published in the first
exercise.
9. In the Configure Pipeline dialog box, in the XmlAsmProcessingInstructions box,
paste the text you just copied, and then click OK.
This message will no longer open using the processing instructions for the
SalesOrder form. When opened, it will use the InfoPath form that you published
to the SharePoint library.
10. Click OK to close the Send Port Properties dialog box.
11. Right click the CreditOrdersSharePoint send port, and click Start.
Test the CreditOrdersSharePoint Send Port

Procedure List
CreditSalesOrder1Info.xml.
3. In Internet Explorer, browse to http://BIZTALKDEMO/LoanApplications.
4. Click the CreditOrder{GUID} message, and then in the File Download dialog box,
click Open.
Notice that this message is displayed in the LoanApplication format.
5. Close the InfoPath window.
Create a New SharePoint Form Library View

Procedure List
2. In the Browse tab of the main menu, click All Documents, and then click Create
View.
3. In the Choose a view format section, click Standard View.
4. In the View Name box, type Evaluated.
5. Scroll down to the Columns section.
Notice the Status column name. This is the field from the message for which you
created a column in Exercise 1. You are going to create a view using that column.
6. Scroll down to the Filter section, and then click Show items only when the following
is true.
7. Configure the Filter section as seen in the following screen shot.
8. Click OK at the bottom of the page.
9. In the Browse tab, notice that the currently selected view Evaluated.
Notice that the message is not displayed in this view.
10. Click Evaluated, and then click All Documents.
11. Click CreditOrder{GUID}, and then in the File Download dialog box, click Open.
12. In the CreditOrder{GUID}.xml window, in the Loan Status list, click Approved.
13. Close CreditOrder{GUID}.xml, and then click Yes to save your changes.
14. In the Browse tab, click All Documents, then click Evaluated.
Notice that the message appears in the Evaluated view and that the Status
column shows the loan is Approved.
16. In the CreditOrder{GUID}.xml window, in the Loan Status list, click Denied.
18. On the LoanApplications page, click the refresh button.
Notice that the message remains in the Evaluated view and that the LoanStatus
column shows the loan is Denied.
20. In the CreditOrder{GUID}.xml window, in the Loan Status list, click Select.
Notice that the message no longer appears on the Evaluated page.
23. In the Browse tab, click Evaluated, then click All Documents.
Configure and Test a SharePoint Receive Location

Procedure List
2. In the Receive Port Properties dialog box, in the Name box, type LoanApplications.
LoanApplicationsSharePoint.
5. In the Type list, click Windows SharePoint Service. In the Receive pipeline list, click
6. In the Windows SharePoint Services Transport Properties dialog box, under
General, configure the properties as they appear in the following table, and then
click OK.
Property Setting
Polling Interval 15

View Name Evaluated
The SharePoint adapter will process all messages displayed by the view specified.
This receive location will process messages displayed by the Evaluated view.
8. In the BizTalk Server Administration Console, click Send Ports, right-click
CashOrdersFTP, and then click Properties.
10. On the second line of the existing filter expressions, in the Group by list, click Or.
11. Add two filter expressions and configure according to the information in the
following table, and then click OK.
Property Operator Value Group by
BTS.ReceivePortName == LoanApplications And
Messaging.PropertySchema.LoanStatus == Approved And
12. In the BizTalk Server Administration Console, click Receive Locations, right-click
LoanApplicationsSharePoint, and then click Enable.
14. Click CreditOrder{GUID}, and then, in the File Download dialog box, click Open.
17. In Internet Explorer, browse to ftp://localhost/CashOrders.
It may take up to a minute for the message to be processed.
18. Click the new Cash{GUID}.
19. Examine and then close the message
Module 8: Creating a BizTalk Orchestration
Module objective:
In this module, you will learn how BizTalk orchestration services work, how to create a
BizTalk orchestration, and how to use debugging tools to monitor a running orchestration.
Overview
By using Microsoft BizTalk Server, you can orchestrate dynamic business processes both
within and between organizations. By using BizTalk Server, developers, information workers,
and IT professionals can work together to rapidly design, create, and deploy integration
solutions that work across applications, platforms, and organizations.
Lesson 1: Introduction to BizTalk Orchestration
Lesson objective:
Explain how BizTalk processes orchestrations, and identify the steps required to create an
orchestration.
Overview
A business process is a set of actions that, taken together, meet a business need. You can
use the Orchestration Designer to define these actions graphically. Rather than requiring you
to express the various steps in a programming language, this tool makes it possible to create
an orchestration by connecting a series of graphical shapes in a logical way.
Modeling a Business Process
Define the term business process and describe the concept and benefits of business-process
modeling.
What Is a Business Process?

Something to consider when building business processes is that a business process is seldom
a single, monolithic process. Rather, a business process is made up of multiple components
that will grow and change over time with the business. It is a good idea, then, to break up a
business process into stages. This will help later for versioning and for isolating disruptions,
which can happen throughout the business process. One good way to break down a complex
business process is to use general criteria to determine the stages of the business process,
including:
 The logical groupings of steps in the business process.
 The scopes of operations within an orchestration.
 The elements of the process that might need to be versioned at the same time.
A well-designed business process solution enables you to add or remove components from
the process without having to reconstruct the entire application.
Business-Process Modeling
Business-process modeling is a technique that you can use to describe and optimize business
processes in an organization. It provides a set of understandable, repeatable structures for
defining business processes. By using a highly structured approach to process automation,
you can increase throughput, reduce cycle times, improve efficiency, and maximize
customer satisfaction.
Business-process modeling improves the interaction and coordination between people and
systems throughout the organization by automating the flow of each business process, and
it provides tools for managing day-to-day business processes. At any given time, there may
be many instances of a given process. Because every instance follows the same flow and
therefore has an identical structure, you can easily automate process management to derive
answers to important questions, such as:
 What are the bottlenecks?
 What resources are required within the process?
 What commitments are not being met?
 How can processes be optimized?
What Is an Orchestration?
Define BizTalk orchestration and describe how the BizTalk run-time engine processes
orchestrations.
Orchestration Designer
BizTalk Orchestration Designer is a tool that is hosted within Microsoft Visual Studio®. The
Orchestration Designer is used to create visual representations of your business processes.
The actual underlying code that carries out the business process gets built into an
executable module that runs on a BizTalk Server computer.
The Orchestration Designer design environment provides a versatile drawing surface and a
comprehensive set of implementation tools. These tools include shapes (such as Send,
Receive, Transform, and Construct) that you can use to coordinate all of your business-to-
business orchestrations on the screen using a graphical interface. The addition of each shape
generates code that becomes part of the eventual business process.
Orchestrations designed using Visual Studio 2010 are saved with an .odx extension and are
built as part of a Microsoft .NET assembly DLL. This DLL is then deployed into the run-time
environment to be accessible to BizTalk.
BizTalk Orchestration
BizTalk orchestrations provide the services that make it possible for you to design, execute,
and manage business processes. An orchestration represents the underlying logic for
processing messages similar to traditional procedural programming languages. An
orchestration is a graphical rendering of the processing logic, providing many of the normal
programming constructs as well as additional features needed to address requirements such
as long-running transactions, parallel actions and decisions. An orchestration can be viewed
as an event-driven, finite state machine in which the state-transition events are the arrivals
of messages or ticks of the clock.
Run-Time Engine
The BizTalk orchestration run-time engine executes the orchestration by creating individual
instances of the business process. The run-time engine coordinates multiple instances of a
business process, ensuring, for example, that a response message gets routed to the correct
orchestration instance, which it does by using a specialized routing pattern called
correlation. For example, you may create a process involved with hiring new employees. For
each employee, there are a number of messages that need to be sent and tasks that need to
be performed. BizTalk Server can manage several instances of the orchestration for each
new employee and correlate each incoming message to the correct orchestration instance.
How the BizTalk Orchestration Engine Works
Explain how the BizTalk orchestration engine works and describe the concept of dehydration and
rehydration.
Introduction
The BizTalk orchestration engine is a highly optimized service that monitors and executes
orchestrations. The orchestration management tasks the orchestration engine is responsible
for include:
 Creating instances of and executing orchestrations.
 Maintaining the state of a running orchestration instance so that it can be restored
to memory when required.
 Performing optimizations of running orchestrations to maximize scalability,
throughput, and efficient use of resources.
 Providing a reliable shutdown-and-recovery system.
Dehydration and Rehydration

When many business processes are running at the same time, memory and performance can
be compromised. The orchestration engine solves these issues by performing the following
actions on orchestration instances:
Dehydration. Dehydration is the process of saving the current state of an orchestration
instance to disk and then removing that instance from memory. When the run-time engine
determines that an orchestration instance has been idle for a period of time, it may
dehydrate the instance, thereby freeing up the resources that the instance had been using.
By dehydrating orchestration instances, the engine makes it possible for a large number of
business processes to run concurrently on the same computer. Dehydration is the
responsibility of the orchestration engine. However, the developer can control the
dehydration threshold by changing BizTalk Server configuration properties. Dehydration may
take place at any time except during the execution of an atomic transaction.
Note: Atomic transactions will be covered in more detail in Module 10, “Creating
Transactional Business Processes.”
Rehydration. Rehydration is the process of restoring the saved state of an orchestration
instance from disk back to memory. When a message is received, or when a time out
expires, the orchestration engine will automatically rehydrate the orchestration instance
that the message belongs to or for which the expiration has occurred. The engine loads the
saved orchestration instance into memory, restores its state, and runs it from the point
where it left off.
Orchestrating a Business Process
Explain how a BizTalk orchestration could facilitate a business process.
Introduction
BizTalk orchestration is a flexible and powerful capability that provides various services and
tools to enable you to design, automate, and manage business processes. Similar to
traditional procedural programming languages, an orchestration represents the underlying
logic for processing messages.
BizTalk orchestration provides a transactional programming model that includes support for
exception handling and recovery from failed transactions. You can define two types of
transactions when creating an orchestration:
Atomic transaction. Enables a transaction to automatically role back to a previous state in
case the transaction does not successfully complete.
Long running transaction. Can span days, weeks, and longer time durations, contain nested
transactions, and use custom exception handling to recover from error scenarios.
As a result, orchestrations provide you the flexibility to define the course of action in the
event of a business process failure.
Stages of Orchestration Development
Identify and describe each of the steps involved in developing a BizTalk orchestration.
Orchestration Steps
To develop an orchestration, you will typically perform the following basic steps:
1. Define schemas to describe the format of those messages that the orchestration will
process. Because BizTalk Server is message based, all actions that are to be
performed will relate to messages.
2. Define and assign orchestration variables to declare and manage the data that is
used in your running orchestration.
3. Define ports to specify how and where messages are sent and received. Ports are
the mechanism whereby BizTalk communicates with external systems and
processes.
4. Add shapes to represent the various actions that are required to define the business
process. Many shapes require configuration to identify the messages that they will
interact with.
5. Construct new message instances within the orchestration. BizTalk Server provides
transformation and message assignment shapes to create new messages within an
orchestration. Because messages are immutable within BizTalk orchestrations, if a
message must be modified, it is necessary to construct a new instance.
6. Bind the Send and Receive shapes to ports and specify the physical ports that they
will use.
7. Build and deploy the orchestration.
8. Test the orchestration for any errors.
Importing and Exporting BPEL
Define BPEL and explain how BPEL files can be imported into an orchestration or exported from
an orchestration.
What Is BPEL?
Microsoft and IBM, working together with other companies, have created the Business
Process Execution Language (BPEL) as an industry standard to support the interaction of
business processes between heterogeneous systems. A business process defined by using
the BizTalk Orchestration Designer can be exported to BPEL, and similarly, the BizTalk
Orchestration Designer can import processes defined in BPEL. This interactivity makes it easy
to import designs created using other BPEL-compliant tools into BizTalk. BPEL is built entirely
on Web services, whereas BizTalk Server 2010 supports a broader set of services. For
example, BizTalk Server 2010 supports mapping between differing XML schemas, calling
methods in local objects, broad support for transactions, and other features that are not
available in BPEL.
Importing BPEL
You can use the BizTalk Server BPEL Import Wizard to import BPEL, Web Service Description
Language (WSDL), or XML Schema Definition (XSD) language files into a BizTalk project. To
import BPEL into an orchestration, create a new BizTalk project choosing the BizTalk Server
BPEL Import Project template, which starts the BPEL Import Wizard.
Exporting BPEL
If you are exporting to BPEL, the orchestrations can contain only features that are common
between BizTalk Server and BPEL or features that can be translated into BPEL without
affecting behavior. To export BPEL from an orchestration, first modify the orchestration
properties to make the orchestration exportable, right-click the orchestration in Solution
Explorer, and then click Export To BPEL.
Lesson 2: Building an Orchestration
Lesson objective:
Create message variables and types and use the Orchestration Designer to create a basic
orchestration.
Introduction
The BizTalk Orchestration Designer provides a graphical method of designing, deploying, and
maintaining distributed business processes. In this lesson, you will learn how you can use
BizTalk Orchestration Designer to design business processes for managing the logic that is
needed for processing business documents.
What Is the Orchestration Designer?
Explain the functions and capabilities of the Orchestration Designer.
Introduction
BizTalk Orchestration Designer provides a visual drawing surface that you use to represent a
business process. The design surface is a working canvas to which you drag shapes from the
Toolbox. In most cases, you must configure options for each shape that you use when you
build the orchestration.
The Design Surface

The design surface itself is divided into three areas: the Process Area and two Port Surfaces.
The Process Area contains shapes that describe the actual process flow of the orchestration.
It is flanked on both sides by Port Surfaces, which contain only Port and Role Link shapes
that interact with the send and receive shapes in the Process Area.
It makes no difference which port Surface you use for a send or receive port (the left side or
the right side). With two port surfaces to place your new ports on, you can create
orchestrations that have fewer crisscrossing connectors, making your orchestrations easier
to read.
Zoom Support
BizTalk Server 2010 provides the ability to zoom the Orchestration Designer window. You
can zoom by right-clicking a clear area of the Orchestration Designer surface and then
clicking Zoom. You can then select the percentage of magnification that you would like to
apply. Alternatively, you can press the CTRL key while using the scrolling function of your
pointing device to zoom in and out.
Using Message and Data-Handling Shapes
Create and configure message and data-handling shapes for an orchestration.
Message and Data-Handling Shapes

Orchestration Designer provides you with the following shapes to use for processing
messages and data in your orchestrations:
Receive. This shape must be connected to a receive port on one of the port surfaces. You
specify the type of message that will be received and the orchestration port over which it
will be received. Optionally, you can specify a filter expression that tests properties on the
message to determine whether an orchestration should process the message. You can also
configure information that enables the message to be correlated with an existing
orchestration instance. Correlation is covered in Module 9, “Automating Business
Processes.”
Send. This shape must be connected to a send port on one of the port surfaces. You specify
the message to send and the port operation that will send it. If you expect to receive an
indirect response—that is, a response that does not use a request-response port—you must
provide information to correlate the message with its associated orchestration instance.
Orchestration Port. This shape is a logical representation of a port and must be bound to a
physical port to enable the orchestration to communicate outside this orchestration to other
orchestrations or through the MessageBox to the outside world.
Construct Message. Constructs a new instance of a message in your orchestration. The
construct message shape can contain only message assignment or transform shapes. You
specify the messages that you want to construct and then make assignments either to the
message or to its parts. A single construct message shape may contain a combination of
message assignment and transform shapes. Once processing has moved out of the construct
message shape, the constructed messages are immutable.
Message Assignment. Constructs messages by assigning one message to another, by
assigning individual message nodes, or by calling a .NET class to construct the message. The
message assignment shape must be contained within a construct message shape.
Transform. Applies a BizTalk map to create a new message. You specify one or more input
messages, one or more output messages, and an Extensible Stylesheet Language
Transformations (XSLT) map for the transform. The map assigns message parts from the
input messages to message parts in the output messages.
Important: Many Orchestration Designer tasks, including those outlined here, require you to
select various items such as schemas or orchestrations. If these items are not in the current
project, you must add a reference in your project to the assembly that contains the item
that you want to select.
Working with Messages in an Orchestration
Define message variables, ports, correlation sets, and multi-part messages.
Message Variables
Before working with messages in an orchestration, a message variable must be defined using
the Orchestration View in Visual Studio. A message variable represents an instance of an
incoming message to be processed by the orchestration. This is true whether the message
will be received through a port or constructed within the orchestration itself.
In many cases, multiple message variables may need to be defined. For example, if an
orchestration receives a purchase order from which an acknowledgement message and
shipping advice message need to be generated, three different message variables need to be
defined.
Messages Are Immutable

Messages are treated as immutable by the BizTalk messaging and orchestration engines
once they arrive at the MessageBox. If it is necessary to change a message in any way within
an orchestration, it is necessary to create a copy of that message by using the construct
message shape.
Orchestration View
Visual Studio provides the Orchestration View window while you are actively working on an
orchestration. To display the Orchestration View window if it is not already displayed, from
the View menu, click Other Windows. This view allows developers to define variables,
correlation sets, and ports for use in the orchestration. The bottom section displays the
types defined anywhere within the current project or from any referenced project. Types
defined in conjunction with the currently selected orchestration are modifiable, whereas
those defined elsewhere are read-only and unavailable. The Orchestration View window
allows specifying user-defined multi-part message types; however, the simple types upon
which you may want to create messages are not shown in the Types section. This is because
these messages will be based on deployed schemas that have no properties that are
configurable within the orchestration context.
Logical vs. Physical Ports
Describe the differences between physical and logical orchestration ports.
Introduction
BizTalk Server uses two different types of ports: physical ports (used for messaging) and
orchestration or logical ports.
Physical Ports vs. Logical Ports

Physical ports are used to receive and send messages between BizTalk Server and the
outside world. Physical ports are configured and managed by using BizTalk Explorer and the
BizTalk Administration console. They can also be created via scripts by using Microsoft
Windows® Management Instrumentation (WMI). The messaging engine processes messages
received through physical receive ports through pipelines and into the MessageBox
database, whereas physical send ports are configured to deliver messages to external
processes and applications.
Logical ports are used to send and receive messages within the BizTalk Server environment.
Logical ports are configured by using Orchestration Designer, and they appear on the Port
Surface areas. Logical ports can be bound to logical ports in other orchestrations to enable
direct communication or can be bound to physical ports to enable an orchestration to send
and receive messages externally.
Example
The following example shows how messages are passed through BizTalk messaging and
orchestration services.
1. A message is received by a physical receive port through an associated receive
location.
2. The message is passed through the receive location (and any associated pipelines)
and then saved in the MessageBox database.
3. The message is picked up by a subscribing orchestration and then passed to the
logical receive port in the orchestration. This subscription is generated by binding
the logical port to the physical port that received the message.
4. The message is processed by the orchestration, and a resulting message is passed
back to the MessageBox database through the logical send port.
5. A subscribing physical send port picks up the message and then passes it through an
associated pipeline.
6. The message is sent to the target destination.
Creating and Configuring Orchestration Ports
Create and configure orchestration ports.
Introduction
Each orchestration (logical) port added to a BizTalk orchestration must be based on a port
type. Port types and ports are defined within the Orchestration View window in Visual
Studio 2010. Ports and types have properties that must be configured before linking the
ports to send and receive shapes.
Orchestration Port Types

Types have properties for the identifier (which must be unique to the project), a description,
the communication pattern (one-way or two-way), and the modifier (public, private, or
internal), which identifies the accessibility of ports based in this type.
If it is public, it is visible to anyone interacting with the orchestration. If it is private, it is
visible to other orchestrations within the same project and namespace. If it is internal, the
port type is visible only within the project. Because a port type definition includes message
types, the scope of the message type must encompass that of any port type that uses it.
Orchestration Ports
Orchestration ports have Identifier and Description properties, as well as the type with
which they are associated. Additionally, ports identify the direction of communication,
which for one-way ports will be either sending or receiving. For two-way ports, the direction
of the first communication is identified; for instance, a port can receive a request from an
outside process and return a response (request-response), or it may solicit an external
process to perform some action and wait for the receipt of a response (solicit-response).
Orchestration Port Bindings

Finally, ports define the binding, which identifies how the port will communicate with the
outside world. Available binding settings are as follows:
Specify now. When a port’s binding is set for specify now (early-bound), the configuration of
the connection to the physical port will be defined at design time. This will automatically
create a dedicated physical port when the orchestration assembly is deployed. Ports that are
early-bound can be modified after they have been deployed.
Specify later. When a port’s binding is set for specify later (late-bound), physical ports will
need to be manually created and bound before the orchestration can be started. This option
is good if the orchestration will bind to already existing ports and provides for better
reusability between multiple send ports and orchestrations.
Direct. Direct binding allows orchestrations to communicate directly with other
orchestrations without the message passing through the MessageBox database as occurs
with early- and late-bound ports.
Dynamic. Dynamically bound ports are not configured at design time or at run time, but
rather a decision is made within the orchestration that will determine the protocol and
address to be used. Dynamic ports are frequently used for sending e-mail messages at run
time or when communicating with trading partners for which different port configurations
are required. This allows reading an e-mail address from a message within the orchestration
and then specifying this as the destination address.
Not all port configurations are supported by all adapters—for example, two-way ports
cannot be used in conjunction with FILE receive adapters—but rather are used primarily for
communicating with Web services, SQL servers, and other request/response systems.
Creating Orchestration Ports and Port Types

Although it is possible to create ports in the Orchestration View window, it is common to
create them by using the Port Configuration Wizard. Launch the wizard by right-clicking
either (right or left) port surface and then clicking New Configured Port.
Demonstration: Creating an Orchestration
Learn how to create message variables and configure a receive shape, a transform shape, and a
send shape. You will then see how to create logical send and receive shapes.
Before starting this demonstration, delete the existing Demos application in the
BizTalk Server Administration Console. The Demos application might need to be
stopped before it can be deleted.
Create a New Orchestration

2. In Solution Explorer, right-click Messaging, and then click Build.
3. In Solution Explorer, right-click Processes, point to Add, and then click New Item.
4. In the Add New Item dialog box, click BizTalk Orchestration, in the Name box, type
ProcessOrder_Cash.odx, and then click Add.
Create a Message Variable

1. In Orchestration View, right-click Messages, and then click New Message.
2. In the Properties window, in the Identifier box, type msgSalesOrder.
3. In the Message Type list, expand Schemas, and then click <Select from referenced
assembly>.
4. In the Select Artifact Type dialog box, click Demo.Messaging, click SalesOrder, and
then click OK.
6. In the Properties window, in the Identifier box, type msgRestock.
7. In the Message Type list, under Schemas, click <Select from referenced assembly>.
8. In the Select Artifact Type dialog box, click Demo.Messaging, click Restock, and
then click OK.
Add a Receive Shape

1. Drag a Receive shape from the Toolbox to the area below the green circle (Start) in
the orchestration.
2. In the Properties window, in the Name box, type Sales Order, and then set the
Activate property to True.
3. In the Properties window, in the Message list, click msgSalesOrder.
Add a Transform Shape

1. Drag a Transform shape from the Toolbox to below the Sales Order receive shape in
the orchestration.
Notice that when you dropped the Transform shape in the orchestration, the
Construct Message shape was also added.
2. Click the ConstructMessage_1 shape, and then in the Properties window, in the
Name box, type Construct msgRestock.
3. In the Messages Constructed list, click msgRestock.
4. Click the Transform_1 shape, and then in the Properties window, in the Name box,
type Map to Restock.
5. In the Properties window, click Map Name, and then click the ellipsis (…) button.
6. In the Transform Configuration dialog box, click Existing Map, and then in the Fully
Qualified Map Name list, click <Select from referenced assembly>.
7. In the Select Artifact Type dialog box, click Demo.Messaging, click
SalesOrder_to_Restock, and then click OK.
8. In the Transform Configuration dialog box, click Source, and then in the Variable
Name list, click msgSalesOrder.
9. Click Destination, in the Variable Name list, click msgRestock, and then click OK.
Add a Send Shape

1. Right-click the arrow immediately below the Construct msgRestock shape, point to
Insert Shape, and then click Send.
2. In the Properties window, in the Name box, type Restock, and then in the Message
list, click msgRestock.
Add a Logical Receive Port

1. Right-click the left Port Surface, and then click New Configured Port.
2. On the Welcome to the Port Configuration Wizard page of the Port Configuration
Wizard, click Next.
3. On the Port Properties page, in the Name box, type SalesOrder, and then click Next.
4. On the Select a Port Type page, in the Port Type Name box, type SalesOrderType,
5. In the Port direction of communication list, click I’ll always be receiving messages
on this port, and then in the Port binding list, click Specify now.
6. In the URI box, type C:\AllFiles\DemoCode\Module8\SalesOrderIN\*.xml, in the
Transport list, click FILE, and then click Next.
7. On the Completing the Port Configuration Wizard page, click Finish.
8. In the SalesOrder receive port shape, click Operation_1, and then, in the Properties
window, in the Identifier box, type ProcessOrder.
9. In the SalesOrder receive port shape, click Request, and then in the Properties
window, in the Name box, type SalesOrder_XML.
10. Drag the green arrow from SalesOrder receive port to the Sales Order receive
shape.
Add a Logical Send Port

Wizard, click Next.
3. On the Port Properties page, in the Name box, type Restock, and then click Next.
4. On the Select a Port Type page, in the Port Type Name box, type RestockType, and
then click Next.
5. In the Port direction of communication list, click I’ll always be sending messages on
this port, and then on the Port binding list, click Specify now.
6. In the URI box, type
C:\AllFiles\DemoCode\Module8\OUT\Restock%MessageID%.xml, in the Transport
list, click FILE, and then click Next.
7. On the Completing the Port Configuration Wizard page, click Finish.
The port shapes can be repositioned by dragging the shape up or down the Port
Surface.
8. In the Restock send port, click Operation_1, and then in the Properties window, in
the Identifier box, type OutputRestock.
9. In the Restock send port, click Request, and then in the Properties window, in the
Name box, type Restock_XML.
10. Drag the green arrow from Restock send shape to the Restock send port.
Deploy and Configure the Orchestration

2. In Solution Explorer, right-click the Processes project, and then click Deploy.
3. In the BizTalk Server Administration Console, right-click Applications, and then click
Refresh.
4. Right-click AdventureWorks, and then click Configure.
5. In the Host list, click BizTalkServerApplication, and the click OK.
6. Right-click AdventureWorks, and then click Start twice.
Lesson 3: Monitoring Orchestrations
Lesson objective:
Use BizTalk tools to monitor and debug an orchestration.
Introduction
BizTalk Server 2010 provides tools for monitoring business processes at various stages. The
BizTalk Group Hub provides features for reporting, analyzing, and debugging both live and
archived data and messages.
Using the Group Hub to View Orchestrations
Use the Group Hub to monitor and view orchestration processing.
Group Hub
The Group Hub page (the Hub) in the BizTalk Administration console is used to view current
service instances. The Hub displays links arranged in categories such as Work in Progress, or
Suspended, or grouped by other characteristics such as Application, Service Name, or Error
Code. Clicking any link initiates a query that returns all instances presently in the selected
state or condition.
The BizTalk Group Hub also provides features for searching, reporting, analyzing, and
debugging data and messages that are archived in the BizTalk Tracking databases. You can
use the Group Hub to locate an orchestration based on the message that initiated the
orchestration.
Service Instance States

These instances can be in a number of different states depending upon various conditions,
including the load on the server, availability of resources, and the design of the orchestration
that is being processed. The service instance states include:
 Ready to run. A service instance has received an activation message but hasn’t
started yet. When the number of ready-to-run instances continually increases, the
resources to process the workload may be insufficient or unavailable.
 Scheduled. Scheduled is a ready-to-run sub-state in which a service is ready to be
processed but will commence processing only within a specified window of time
(service window). The service window can be specified by the user in the Port
Properties dialog box for the port. Outside that service window, the service is shown
as scheduled.
 Retrying. When a send port instance encounters a failed message transmission,
typically because a resource is unavailable, it periodically tries to resend the
message.
 Dehydrated. The orchestration instance is idle and not in memory. Dehydrated is
essentially the same state as retrying, but it relates to an orchestration instead of to
a message port. A dehydrated orchestration typically is reactivated when it receives
a message.
 Suspended, resumable. The service instance is suspended. You may be able to
resume the service instance by means of an API call or an administrative action.
 Suspended, nonresumable. The service instance is suspended and cannot be
resumed.
 Active. The service instance is currently in memory.
 In breakpoint. The service instance has stopped execution at a preset breakpoint.
You can resume the execution of the service instance through the Orchestration
Debugger or by right-clicking the service instance and then clicking Resume.
Message Instance States

As has been noted, all processing within BizTalk begins with the receipt of a message. A
single service instance can have a number of messages with which it is involved, each of
which will have some state associated with that message. Valid states for messages are:
 Consumed. The message has been processed by a service instance. The service that
processed the instance retains a reference so that it can access the message later.
The message is considered delivered. For example, BizTalk Message Queuing
Adapter MSMQ messages are in the consumed state during batched resending of
messages. MSMQ can be blocked while it waits for an acknowledgement, and the
messages will be flagged as consumed until the acknowledgement arrives, at which
time MSMQ will restart sending messages.
 Delivered (not consumed).The message has been delivered to the engine, is being
processed, and is in memory. It is considered delivered.
 Suspended, resumable. The service instance associated with the message is
suspended and can be resumed.
 Suspended, non-resumable. The service instance associated with the message is
suspended and cannot be resumed.
 Undelivered. There may be no services available to process the message, or there
may be no services running. For example, in an ordered delivery scenario, a message
is undelivered when another message that precedes it is being retried by the
ordered delivery send port.
 Undelivered (retrying).The message is associated with a send port that is attempting
to resend it because the destination resource is unavailable. (See the previous
definition for the “retrying” service instance.)
 Undelivered (scheduled).The message is waiting to be sent by a send port that has a
service window set.
Using the Orchestration Debugger
Use the Orchestration Debugger to track orchestration activity and diagnose problems with
orchestration processing.
The Orchestration Debugger

The Orchestration Debugger enables you to track the activity of a single orchestration
instance on a shape-by-shape basis. The Orchestration Debugger displays a rendered view of
the orchestration that was previously created in Orchestration Designer.
Accessing the Orchestration Debugger

You access the Orchestration Debugger by right-clicking any service or message instance
associated with an orchestration type and then clicking Orchestration Debugger. This can be
done from the Hub. You can switch back and forth between the Orchestration Debugger and
the Message Flow views.
Orchestration Debugger Functions

Using the Orchestration Debugger, you can:
Display a rendered view of the orchestration in which you can replay each processing step
for that particular orchestration.
Set breakpoints before any orchestration shape, and then continue execution. Setting a
breakpoint sets it on the class, not the instance, so each instance will break at this same
point. For this reason, you would not want to set breakpoints on orchestrations in a
production environment, and you will need to clear the breakpoints on the class when no
longer needed.
View specific variables and message data while in debugging mode.
Continue and resume in debug mode, and then terminate the particular orchestration
instance.
Demonstration: Tracking an Orchestration Instance
Learn how to use the BizTalk Group Hub to track message and orchestration activity.
Tracking an Orchestration Instance

2. In Windows Explorer, navigate to C:\AllFiles\DemoCode\Module8, and then copy
CashSalesOrder1Info.xml to the SalesOrderIN folder.
3. In the BizTalk Administration Console, click on BizTalk Group, and then in the center
pane, click on the New Query tab.
4. Select Tracked Service Instances from the Value drop-down list, and click Run
Query.
5. In the Query results, right-click the most recent instance of
Microsoft.BizTalk.DefaultPipelines.XMLReceive, and then click Message Flow.
6. Maximize the Message Flow window.
The top section of the Message Flow window displays helpful troubleshooting
information about this service instance, such as Host, Type, Start Time, and End
Time. The lower section displays the flow of the message instance. This message
was received as an Unparsed Interchange through the specified port (the
randomly generated port name is a result of early binding the orchestration
ports). It was then sent to the Demo.Processes.ProcessOrder_Cash orchestration.
7. Click the Demo.Processes.ProcessOrder_Cash link at the bottom of the page.
Notice that the Type of the service is Orchestration and the State is Completed. In
the lower section, notice that the message was received with the SalesOrder
port, sent using the Restock port.
8. Click the Microsoft.BizTalk.DefaultPipelines.XMLTransmit link in the Restock port
section.
Information about the service instance appears.
9. Click the Demo.Processes.ProcessOrder_Cash link.
10. At the top of the Message Flow window, click the Orchestration Debugger link.
The orchestration debugger shows the orchestration as seen in the design
environment, and the Tracked Events pane shows the start and completion of
each shape as the message passes through the orchestration.
11. Close all windows, and shut down the bt10d-demos virtual machine.
Lab: Creating a BizTalk Orchestration
Scenario
BizTalk messaging can be used for basic message transformation and routing. Processing
that requires decisions or multiple actions generally requires the use of orchestrations. The
IT manager of Adventure Works has asked you to create orchestrations for processing both
cash and credit sales orders. In this lab, you will create the orchestration for processing cash
sales orders. In subsequent labs, you will create the orchestration responsible for processing
credit sales orders.
Procedure List
window.
Start.

Procedure List
2. Double click startBtServices.cmd.
Exercise 1: Import an Existing Schema and Map
Overview
The orchestration you are going to build requires the generation of a restock message and a
map to convert from the SalesOrder format to the Restock format. In this exercise, you will
add the Restock schema and the SalesOrder_To_Restock map to the Messaging project.
Add and Examine Existing Artifacts

Procedure List
open AdvWorks.sln.
Item.
3. In the Add Existing Item dialog box, browse to C:\AllFiles\LabFiles\Lab8\Artifacts.
4. While holding the CTRL key, click both Restock.xsd and SalesOrder_to_Restock.btm,
and then click Add.
Examine the structure of the Restock schema.
6. In Solution Explorer, double-click SalesOrder_to_Restock.btm.
Examine the links in the SalesOrder_to_Restock map.
7. Close the Restock schema and the SalesOrder_to_Restock map.
Exercise 2: Create a New Project and Orchestration
Overview
The Adventure Works business process specifies that restock messages for the inventory
system and a copy of the completed sales order be generated when a cash sales transaction
is completed. In this exercise, you will create an orchestration that processes cash sales
orders sent by the Adventure Works stores.
Create a New Project

Procedure List
1. In Visual Studio, on the File menu, point to Add, and then click New Project.
2. In the Add New Project dialog box, in the left pane, click BizTalk Projects, then in
the center pane click Empty BizTalk Server Project. In the Name box, type
Processes, and then click OK.
4. In Solution Explorer, right-click Processes, and then click Properties.
5. In the Process property pages window, on the Application tab, in the Assembly
Name and Default Namespace boxes, type AdvWorks.Processes.
6. In the Process property pages window, click the Signing tab, and then check the Sign
the assembly check box.
7. Choose <Browse…> from the drop-down list, and navigate to
C:\AllFiles\LabFiles\Common, click AdvWorks.snk, and then click Open.
10. In Solution Explorer, right-click Processes, and then click Add Reference.
Since the Processes project will contain orchestrations that use the schemas in
the Messaging project, you will need a reference to the Messaging project.
11. In the Add Reference dialog box, on the Projects tab, click Messaging, and then click
OK.
Create an Orchestration
Procedure List
2. In the Add New Item dialog box, click Orchestration Files, click BizTalk
Orchestration, in the Name box, type ProcessOrder_Cash.odx, and then click Add.
The ProcessOrder_Cash orchestration opens automatically.
Create Messages
Procedure List
2. In the Message_1 Properties window, in the Identifier box, type msgSalesOrder.
4. In the Select Artifact Type dialog box, in the left pane, click AdvWorks.Messaging, in
the right pane, click SalesOrder, and then click OK.
This is the message variable for the incoming sales order.
6. In the Message_1 Properties window, in the Identifier box, type
msgSalesOrder_Complete.
8. In the Select Artifact Type dialog box, click in the left pane, AdvWorks.Messaging, in
This is the message variable for the completed processing acknowledgement
message.
10. In the Message_1 Properties window, in the Identifier box, type msgRestock.
the right pane, click Restock, and then click OK.
This is the message variable for the restock message sent to the inventory
system.
Add Shapes to the Orchestration

Procedure List
1. Drag a Receive shape from the Toolbox to the area below the green circle (Start) in
the orchestration.
If the Toolbox is not docked on the left side of the window, on the View menu,
click Toolbox.
2. In the Properties window, in the Name box, type Sales Order.
4. Drag a Transform shape from the Toolbox to the area below the Receive shape in
the orchestration.
Name box, type Construct msgRestock.
type Map to Restock.
the right pane, click SalesOrder_to_Restock, and then click OK.
11. In the Transform Configuration dialog box, click Source, and then in the Variable
12. Click Destination, and then in the Variable Name list, click msgRestock, and then
click OK.
13. Drag a Message Assignment shape from the Toolbox to the area beneath the
Construct Message shape in the orchestration.
Notice that when you dropped the Message Assignment shape in the
orchestration, a new Construct Message shape was also added.
Name box, type Construct msgSalesOrder_Complete.
15. In the Messages Constructed list, click msgSalesOrder_Complete.
16. Click the MessageAssignment_1 shape, and then in the Properties window, in the
Name box, type Build Complete SO.
17. In the Build Complete SO Properties window, click Expression, and then click the
ellipsis (…) button.
18. In the BizTalk Expression Editor, in the text box, type the text shown in the text box
in the following screen shot, and then click OK.
20. Configure the Send_1 shape with the properties shown in the following table.
Property Setting
Name Restock
Message msgRestock
21. Right-click the arrow immediately below the Construct msgSalesOrder_Complete

shape, point to Insert Shape, and then click Send.
22. Configure Send_1 with the properties shown in the following table.
Property Setting
Name Complete Sales Order
Message msgSalesOrder_Complete
Exercise 3: Create Orchestration Ports
Overview
Orchestration ports (logical ports) provide the connections between an orchestration’s send
and receive shapes and the BizTalk MessageBox database. In this exercise, you will create a
receive port and two send ports. These ports will be connected to send and receive shapes
in the orchestration.
Create an Orchestration Receive Port

Procedure List
Wizard, click Next.
4. On the Select a Port Type page, in the Port Type Name box, type SalesOrderType,
on this port, and then in the Port binding list, click Specify now.
6. In the URI box, type C:\AllFiles\LabFiles\Lab8\SalesOrderIN\*.xml, in the Transport
7. On the Completing the Port Wizard page, click Finish.
8. In the SalesOrder receive port shape, click Operation_1, and then in the Identifier
box of the Properties window, type ProcessOrder.
9. In the SalesOrder receive port shape, click Request, and then in the Name box of the
Properties window, type SalesOrder_XML.
10. Drag the green arrow from SalesOrder receive port to the Sales Order receive
shape.
Create Orchestration Send Ports

Procedure List
Wizard, click Next.
4. On the Select a Port Type page, in the Port Type Name box, type RestockType, and
then click Next.
6. In the URI box, type C:\AllFiles\LabFiles\Lab8\OUT\Restock%MessageID%.xml, in
the Transport list, click FILE, and then click Next.
Surface.
8. In the Restock send port shape, click Operation_1, and then in the Identifier box of
the Properties window, type SendRestock.
9. In the Restock send port shape, click Request, and then in the Name box of the
Properties window, type Restock_XML.
11. Right-click the right Port Surface, and then click New Configured Port.
Wizard, click Next.
13. On the Port Properties page, in the Name box, type SalesOrder_Complete, and then
click Next.
14. On the Select a Port Type page, click Use an existing Port Type, click
AdvWorks.Processes.SalesOrderType, and then click Next.
this port, and then in the Port binding list, click Specify now.
16. In the URI box, type
C:\AllFiles\LabFiles\Lab8\OUT\CompleteSO%MessageID%.xml, in the Transport
18. Drag the green arrow from Complete Sales Order send shape to the
SalesOrder_Complete send port.
Your orchestration should look like the following figure:
Exercise 4: Build, Deploy, and Test the Solution
Overview
In this exercise, you will deploy and test the ProcessOrder_Cash orchestration. The early
bound orchestration ports that you defined in this lab will cause new messaging ports
(physical ports) to be created and will cause these ports to be bound to the orchestration
ports (logical ports). You will submit a test message to the newly created receive port. The
orchestration will generate two new messages and send them to the file system using the
send ports.
Test the Orchestration

Procedure List
1. In Solution Explorer, right-click Processes, and then click Build.
2. You will receive the following error:
“You must specify at least one already-initialized correlation set for a non-
activation receive that is on a non-self correlating port.”
This is one of the most common errors committed when creating a new
orchestration. The receive shape for the orchestration is not configured as an
activation receive.
3. Click the Sales Order receive shape, and then in the Properties window, in the
Activate list, click True.
5. After the build has completed, right-click Processes, and then click Deploy.
BizTalk Group, Applications, BizTalk Application 1, and then click Resources.
Notice the AdvWorks.Messaging and AdvWorks.Processes resources.
8. Right-click BizTalk Application 1, and then click Start.
9. In the Configure Application message box, read the message, and then click Yes.
The host instance used by the orchestration has not yet been configured. A host
instance must be set before the orchestration, and therefore the application, can
be started.
10. In the Configure Application dialog box, click ProcessOrder_Cash.
Notice that the physical receive port and send ports have been created and
bound to the orchestration. This is because you configured the port bindings
when configuring the orchestration ports. This is known as early binding.
11. In the Host list, click BizTalkServerApplication, and then click OK.
13. In the Start ‘BizTalk Application 1’ Application dialog box, click Options, ensure that
all check boxes are selected, and then click Start.
14. In Windows Explorer, navigate to C:\AllFiles\LabFiles\Lab8, and then copy
15. Navigate to the SalesOrderIN folder.
16. Navigate to the OUT folder.
17. Open CompleteSO{GUID}.xml.
The message is displayed using a Microsoft InfoPath® form.
18. Close InfoPath.
19. In Windows Explorer, open Restock{GUID}.xml.
The message is displayed in XML format.
Module 9: Automating Business Processes
Module objective:
How to build an orchestration to automate a business process
Overview
Orchestration is a flexible, powerful tool for representing your executable business
processes. You can design the message flow, interpret and generate data, call custom code,
and organize it all in an intuitive visual drawing. It is important for you to become familiar
with the various shapes that Microsoft® BizTalk® Orchestration Designer provides to
represent the logical flow of your orchestration. You should also know how to manipulate
data and manage exceptions within an orchestration.
Lesson 1: Controlling the Flow of an Orchestration
Lesson objective:
Use orchestration flow control shapes and create modular orchestrations.
Overview
Orchestration Designer provides a number of shapes that you can use to control the flow of
your orchestration. In this lesson, you will learn how to use and configure the Group and
Scope shapes to organize your orchestration and how to use different shapes to control
parallel processes and conditionally control the flow of messages through the orchestration.
Scope and Group Shapes
Explain how scope shapes and group shapes are used to organize actions in an orchestration.
Scope Shape
A scope acts as a framework for organizing actions. You use it primarily for transactional
execution and for exception handling. You also use a scope when you want to define
variables, messages, and correlation sets that must remain local within the scope and when
you need to use variables and classes that are non-serializable.
A scope contains one or more blocks or other nested scopes. It has a body and can have
appended to it any number of exception-handling blocks. It may also, depending on the
nature of the scope, include an optional compensation block. For more information on
compensation, see Module 10, “Creating Transactional Business Processes”.
Some scopes exist solely for the purpose of exception handling, and these do not require
compensation. In Microsoft .NET terms, a scope is a Try block that can have multiple catch
(exception-handling) blocks. Other scopes are explicitly transactional. Transactional scopes
always have a single compensation block and can include a time-out value. You can write
your own or use the default compensation handler.
The scope shape creates an additional context within the orchestration. The scope can have
its own variables, messages, and correlation sets. The memory used for these will be freed
up when all of the actions within the Scope shape complete.
Synchronized vs. Not Synchronized

You can specify that a scope be either synchronized or not synchronized. By synchronizing a
scope, you ensure that parallel actions in your orchestration do not write to any shared data
accessed by the orchestration and that no actions will write to the shared data while
another action reads that same shared data. Atomic transaction scopes are always
synchronized.
All actions in a synchronized scope are considered synchronized, as are all actions in any of
its exception handlers. Actions in the compensation handler for a transactional scope are not
synchronized.
Group Shape
A Group shape is used to arrange actions in an intuitive and visually manageable way. You
can use the Group shape as a placeholder for functionality yet to be added, or you can use it
to make annotations about what actions take place within it. The name property on the
Group shape can be up to 512 characters long. You can type annotations into the name
property, and when the shape is collapsed, the entire name will be displayed.
Orchestration Flow Control Shapes
Configure orchestration shapes to enable decision logic and event timing within an
orchestration.
Orchestration Flow Control Shapes

The Orchestration Designer provides a number of shapes that you can use to control the
flow of your orchestration. Most of these shapes are configured with one or more
expressions that are defined using the BizTalk Expression Editor.
 Decide. Represents If/Else logic. The Decide shape always has at least two branches:
a branch for the If statement and a branch for the Else statement. You can add
branches for If/Else statements as needed. A rule (written as a Boolean expression)
is defined for each branch of a Decide shape except the Else branch. Rules are
evaluated left to right, and only the first matching rule branch will be executed. If
none of the rule conditions is met, the Else branch will be executed. Each branch can
contain additional orchestration shapes, including other Decide shapes (to create
nested if statements).
 Delay. Controls the timing of the orchestration’s progress. You can set a time-out on
the Delay shape so that your orchestration pauses before resuming execution. You
can use a System.DateTime structure, which will cause your orchestration to pause
until the specified date or time is reached, or you can use a System.TimeSpan
structure, which will cause your orchestration to pause for the length of time
specified.
 Listen. Requires an orchestration to wait for one or more events to occur before
proceeding. The first shape in each branch of a Listen shape must be either a Delay
shape or a Receive shape. The orchestration follows only the first branch that meets
the condition (for example, a delay is reached or a message is received).You can add
as many branches as you like.
Orchestration Flow Control Shapes (continued)
Configure orchestration shapes to enable repeating actions and concurrent processing and to
suspend or terminate an orchestration process.
Orchestration Flow Control Shapes (continued)

You can use the following additional orchestration flow shapes in your orchestration design.
 Loop. Provides a mechanism for repeating actions—including actions in other shapes—
provided that some condition is met. You set the condition in the form of a Boolean
expression by using Expression Editor.
 Parallel Actions. Provides a mechanism to coordinate multiple receive shapes when
messages might arrive in any order. The parallel action shape will wait for all of the receive
shapes to complete before it executes the rest of the orchestration. The parallel action
shape does not support concurrent execution, it executes only one branch at a time. If you
are waiting to receive three messages and do not know or care about the order in which they
arrive, you can place a Receive shape in each of the branches of a Parallel Actions shape.
Whichever branch receives a message first can operate on it, and when the branch
completes the orchestration will wait for the remaining branches to receive and process their
messages. All branches merge at the end of the Parallel Actions shape, and processing does
not continue from that point until all previous actions have been completed.
 Suspend. Pauses a running orchestration instance until an administrator explicitly
intervenes. You configure the condition used to suspend an orchestration by using the
Expression Editor. Typically, the purpose is to reflect an error condition that will require
attention beyond the scope of the orchestration. When an orchestration instance is
suspended, an error is generated. To help the administrator diagnose the situation, you can
specify a message string to accompany the error. All state information for the orchestration
instance is saved and is then reinstated if and when the administrator resumes the
orchestration instance.
 Terminate. Terminates all activities of a running orchestration. You use a Terminate
shape to end the orchestration immediately when an abnormal situation occurs. To
help the administrator diagnose the situation, you can also specify a message string
to accompany the error.
Expression and Exception Shapes
Configure expressions and throw exceptions.
Expression Shape
The Expression shape allows you to enter complex expressions into your orchestration easily
and quickly; however, you cannot use it to enter an arbitrary amount of code. For example,
you can initialize and manipulate the values of your orchestration variables, assign values to
dynamic ports, or make a .NET call to run an external program. You use the Expression Editor
to define the expression.
Throw Exception Shape

You can explicitly throw exceptions in an orchestration by using the Throw Exception shape.
When the throw is performed, the runtime engine will search for the nearest exception
handler that can handle the type of exception being thrown. After a matching exception
handler is found, control is transferred to the first statement of the exception handler. If the
search for matching exception handlers fails, the orchestration halts. Transactions (which
will be discussed in the next module) can help you minimize the impact of such an
occurrence.
Nesting Orchestrations
Configure an orchestration to call or start other orchestrations.
Overview
Two shapes that can be used to make your business processes more understandable and
easier to deploy and test are the Call and Start Orchestration shapes. These two shapes let
you effectively nest orchestrations within other orchestrations whether they are
transactional or not.
Call Orchestration Shape

The Call Orchestration shape is used to invoke another nested orchestration synchronously,
which means that the enclosing orchestration waits for the nested orchestration to finish
before continuing.
You can specify parameters that will be passed to the nested orchestration. Parameters can
be messages, variables, port references, role links, or correlation sets. Parameters can be
defined as one way (in or out), or they can also be passed by reference as with a .NET
method parameter. Passed-in port references, role links, and correlation sets all perform in a
way similar to that of self-addressed envelopes, which means that they supply the nested
orchestration information that it can use to send information back to the enclosing
orchestration.
Start Orchestration Shape

Similar to the Call Orchestration shape, the Start Orchestration shape can be used to nest
other orchestrations; however, this nesting is asynchronous, which means that the flow of
control in the invoking orchestration proceeds beyond the invocation without waiting for
the invoked orchestration to finish its work.
As with the Call Orchestration shape, you can specify parameters that will be passed to the
called orchestration. The Start Orchestration shape can only take in parameters; it cannot
take out or reference parameters.
Lesson 2: Configuring Orchestrations
Lesson objective:
Configure orchestration expressions, message correlation, and exception handling.
Overview
Before you build an orchestration, you may need to designate specific fields as being
distinguished fields so that the data within a message can be referenced within an
orchestration. When building an orchestration, you can create expressions to make
decisions, set delays, make .NET calls, and test while loop conditions. You can also configure
correlation so that incoming messages can be matched with an instance of a currently
running orchestration. Finally, you can use exception handling to specify the actions that
must take place when an error occurs.
Distinguished Fields
Explain the purpose of distinguished fields and the difference between distinguished fields and
promoted properties.
What Are Distinguished Fields?

Distinguished fields are message data of special interest. They are used to make decisions or
to manipulate data in your orchestration. Examples of data manipulation that can be
performed by distinguished fields are accessing and updating instance data.
Using Distinguished Fields

Within an orchestration, the XPath expression relating to any node can be used to read
and/or write values within messages. Promoting a node as a Distinguished field in a schema
provides an easily accessible alias for that node so that lengthy XPath expressions do not
have to be typed repeatedly. Also, distinguished fields provide a performance improvement
over using XPath expressions because the values are pre-fetched as the message is being fed
into the orchestration.
Distinguished fields are limited to unique non-repeating values, and the values are limited to
no more than 255 characters. Once a node has been defined as a distinguished field, simple
dotted notation syntax can be used to reference the node. For example, after promoting the
CompanyName node as a Distinguished field in the PurchaseOrder schema, this node can be
accessed using syntax such as the following to access the value from a message variable
named msgPurchaseOrder:
msgPurchaseOrder.CompanyName
Promoting a Distinguish field is done in the BizTalk Editor in Microsoft Visual Studio® 2010 by
right-clicking the node, pointing to Promote, and then clicking Show Promotions. The
resulting dialog box displays the Schema tree in the left pane and has Distinguished Fields
and Property Fields tabs. On the Distinguished Fields tab, select the node in the schema tree,
and then click Add. The node is added to the Property list with its corresponding XPath
listed.
Distinguished Fields vs. Promoted Properties

We have previously discussed promoted properties, which are used by the messaging engine
in routing and tracking processes. Promoted properties are also used for a special kind of
routing, called correlation, which will be discussed later in this module. Promoted properties
are primarily used for routing purposes but can also be accessed in orchestrations by using a
simplified syntax, such as:
msgSalesOrder(AdvWorks.Messaging.PropertySchema.OrderTotal)
In this example, msgSalesOrder is the name of a message variable defined in this

orchestration for a message based on the SalesOrder type in the AdvWorks.Messaging
project. The OrderTotal node has been promoted to the default property schema in that
project.
As you can see, the distinguished field syntax provides more direct access to a message
node. The overuse of property promotion can have a negative performance effect, whereas
distinguished properties do not incur additional overhead. For optimal performance,
promote only those properties that are required for routing purposes, and distinguish the
node if the data is required within an orchestration.
Demonstration: Configuring Orchestration Flow
Learn how to promote distinguished fields and then use a distinguished field in a decide shape.

demonstrations. This solution provides artifacts and file paths that differ from those
used in the previous demonstrations.
Promote Distinguished Fields

1. In Microsoft Windows Explorer, navigate to
C:\AllFiles\DemoCode\Module9\AdvWorks, and then double-click the
AdvWorks.sln file.
2. In Solution Explorer, in the Messaging project, double-click SalesOrder.xsd to open
the schema.
3. In the SalesOrder schema, right-click <Schema>, and then click Expand Schema
Node.
4. Right-click <Schema>, point to Promote, and then click Show Promotions.
5. In the Promote Properties dialog box, click the Property Fields tab, and notice that
OrderType and CustomerName have already been promoted as Property Fields.
6. Click the Distinguished Fields tab, and then in the schema tree view, click Comment,
and then click Add.
7. Repeat step 6 for OrderTotal and then OrderNumber (under the Detail node), and
then click OK.
Examine a Group Shape

1. In Solution Explorer, in the Processes project, double-click ProcessOrder_Cash.odx.
2. Click the existing Group shape to collapse it, and then click it again to expand it.
Use the Expression Editor

1. Inside the Construct msgSOComplete shape, double-click the Build Complete SO
shape.
2. In the BizTalk Expression Editor window, beneath the existing line of code, enter the
following line of code, and then click OK.
msgSalesOrder_Complete.Comment =
“Processing of this order is now complete.”;
Configure a Decision Shape

1. Right-click the area below the Rcv Sales Order receive shape, point to Insert Shape,
and then click Decide.
2. In the Properties window, in the Name box, type Order Size?
3. In the ProcessOrder_Cash orchestration, click the Rule_1 shape, and then in the
Properties window, in the Name box, type Large.
4. In the Properties window, click Expression, and then click the ellipsis (…) button.
5. In the BizTalk Expression Editor, type the following line of code, and then click OK.
msgSalesOrder.OrderTotal > 2000
6. Right-click the placeholder below the Large branch, point to Insert Shape, and then
click Send.
7. Name the Send shape Snd Approval Request, and in the Message list, click
msgSalesOrder.
Configure a Listen Shape

1. Right-click the area below the Snd Approval Request shape, point to Insert Shape,
and then click Listen.
2. Name the Listen shape Listen for Response.
3. Right-click the first placeholder in the left branch of the Listen shape, point to Insert
Shape, and then click Receive.
4. Name the Receive shape Rcv Order Approval, and in the Message list, click
msgApproved.
5. Right-click the first placeholder in the right branch of the Listen shape, point to
Insert Shape, and then click Delay.
6. Name the Delay shape Wait for Approval, then click the Delay property, and then
click the ellipsis (…) button
7. In the BizTalk Expression Editor window, enter the following line of code, and then
click OK.
new System.TimeSpan(0, 0, 30)
This will cause the orchestration to wait 30 seconds for an approval message.
8. Right-click the placeholder beneath the Delay shape, point to Insert Shape, and then
click Suspend.
9. In the Properties window, name the Suspend shape Timed Out, then click the Error
Message property, and then click the ellipsis (…) button, and enter the following line
of code, and then click OK.
System.String.Format(
“Order# {0} did not receive an approval to proceed.”,
msgSalesOrder.Detail.OrderNumber);
Create a Logical Send Port

Wizard, click Next.
3. On the Port Properties page, in the Name box, type RequestApproval, and then
click Next.
4. On the Select a Port Type page, click Use an existing Port Type, then select
this port, and then click Next.
6. Click Finish.
7. Drag the green arrow from the Snd Approval Request Send shape to the
RequestApproval send port.
Create a Logical Receive Port

Wizard, click Next.
3. On the Port Properties page, in the Name box, type ReceiveApproval, and then click
Next.
4. On the Select a Port Type page, click Create a new Port Type, and name it
ApprovalType, and then click Next.
on this port, and then click Next.
6. Click Finish.
7. Drag the green arrow from the ReceiveApproval receive port to the Rcv Order
Approval receive shape.
8. Close the ProcessOrder_Cash.odx orchestration, saving your changes.
Creating Expressions
Configure expressions by using the Expression Editor.
Using Expressions
The Expression shape enables you to create expressions within an orchestration. Expressions
can be used to add logic and to manipulate and test values. For example, you can initialize
and manipulate the values of your orchestration variables, assign values to dynamic ports
and message context, and make a .NET call to run an external program.
Expressions should not be used to perform high-level orchestration logic, which preferably
would be visible in the orchestration drawing itself. In general, it is easier to understand and
maintain your orchestrations if your Expression shapes contain simple and modular
expressions.
Expression Editor
The BizTalk Expression Editor enables you to create expressions to define the capabilities of
various orchestration shapes. Expressions created within the Expression editor are written
using C# syntax. An expression can span multiple lines, but it must end with single semicolon
(;). You can create expressions to make decisions, set delays, and test while loop conditions.
For more information, see “Shapes that Take Expressions” in BizTalk Help.
Only expressions created for the Expression shape can end in a semicolon; no other
expression can. This is because the expression for other shapes is a single Boolean test (the
equivalent of the contents of a set of parentheses in C#). In addition to the standard .NET
operators, you can also use the exists operator to determine if a value is present in a
message instance.
Using Expression Editor, you can assign values to messages or message parts in the Message
Assignment shape. You can also use Expression Editor to construct complex Boolean
expressions in the Loop and Decide shapes and set the delay in the Delay shape.
IntelliSense
The BizTalk Expression Editor is a standard Visual Studio text editor, which means that it
offers IntelliSense®. The IntelliSense feature will help guide you in creating expressions—for
example, it can display a list of class members for you when you type in a .NET class name
followed by a period (.).
Correlating Messages
Explain how correlation works and configure correlation sets.
What Is Correlation?
Correlation is a special variation on message routing that matches an incoming message to
the appropriate instance of an orchestration. Often, there may be many instances of a given
orchestration running, and although each of the instances will perform the same actions,
they will do so on different data contained in messages. For example, if your orchestration is
designed to issue a purchase order, receive an invoice, and then send a payment, you must
ensure that the invoice message is received by the orchestration instance from which the
corresponding purchase order was sent. (Imagine ordering a single item and receiving an
invoice for 1,000 items, or vice versa, and you can understand the importance of
correlation.) Likewise, if two related messages are meant to be kept together and sent
consecutively, you can use correlation to ensure that they are received in the proper order
by the same instance.
Correlation Sets
Each correlation set is based on a correlation type, which is simply a list of properties. These
properties might be data (found in the message itself) or context properties that describe
system-defined details or transport properties for the message that have no relation to the
data actually being conveyed in the message. In order to use message data for a correlation
type, the nodes must be promoted to make the values accessible to the messaging engine.
You can use a single correlation type in more than one correlation set. If you need to
correlate based on different values for the properties in a correlation type, you must create
a new correlation set, because each correlation set can be initialized only once.
Demonstration: Correlating Messages
Learn how to configure correlation for an orchestration.
Create a Property Field for Correlation

2. Open the PropertySchema.xsd schema.
3. Right-click <Schema>, point to Insert Schema Node, and then click Child Field
Element.
4. Name the element OrderID.
Promote the OrderNumber in the SalesOrder Schema

1. Open the SalesOrder.xsd schema.
3. In the Promote Properties dialog box, click the Property Fields tab.
4. In the schema tree view, click OrderNumber, and then click Add.
5. In the Property column, in the drop-down list, click OrderID, then click OK.
Promote the ReferenceNumber in the OrderApproval Schema

1. Open the OrderApproval.xsd schema.
3. In the Promote Properties dialog box, click the Property Fields tab.
4. In the schema tree view, click ReferenceNumber, and then click Add.
5. In the Property column, in the drop-down list, click OrderID, then click OK.
6. Right-click the Messaging project, then click Build.
Create a Correlation Type

1. In Orchestration View, for the ProcessOrder_Cash.odx orchestration, expand Types,
right-click Correlation Types, and then click New Correlation Type.
2. In the Correlation Properties window, in the left pane, expand
AdvWorks.Messaging.PropertySchema, click OrderID, click Add, and then click OK.
3. In the Correlation Type Properties window, change the Identifier to
ManualApprovalCorrType.
Create a Correlation Set

1. In Orchestration View, right-click Correlation Sets, and then click New Correlation
Set.
2. In the Properties window, in the Identifier box, type ManualApprovalCorrSet, and
then in the Correlation Type list, click
AdvWorks.Processes.ManualApprovalCorrType.
Configure Correlation for the Orchestration

1. Click the Snd Approval Request shape, and then in the Properties window, in the
Initializing Correlation Sets list, click ManualApprovalCorrSet.
2. Click the Rcv Order Approval shape, and then in the Properties window, in the
Following Correlation Sets list, click ManualApprovalCorrSet.
Handling Exceptions
Explain how exceptions are generated and how the BizTalk Exception Handler works.
Exceptions
Exceptions are raised by the orchestration engine when an error occurs in the orchestration.
Microsoft BizTalk Server provides various mechanisms for throwing and handling exceptions.
How Exceptions Are Generated

Exceptions can be generated in an orchestration in any of the following ways:
 When the Throw Exception shape is explicitly used.
 When a time-out in an atomic or long-running transaction occurs.
 When some other transaction failure occurs. (The run-time engine throws a system-
defined message for these exceptions.)
 When calls to external assemblies are made and result in an exception. (Common
language runtime classes that are called can throw exceptions.)
 When a system exception (such as a persistence failure, another. NET or system
exception, or a data-conversion error) is raised.
 When a sibling branch in a surrounding scope halts execution. (A predefined system
exception is thrown.)
 When the receipt of an external message indicates a fault.
Exception Handler
When an exception occurs in a scope, each logical thread of execution in that scope stops.
The run-time engine attempts to locate an exception handler for the appropriate exception
type. If it succeeds in locating an exception handler that matches either the specific
exception type or one of its base types, control passes to that handler, and the exception
code runs.
Each scope shape within an orchestration may have one or more exception handler blocks
appended to it. The relative cost of catching and handling an exception is high, so as with
.NET exception handling, you should reduce the likelihood of exceptions occurring whenever
possible. Don’t use exception handlers to catch common conditions; use a decide shape
instead. For example, it’s always easier to determine if you are going to divide by zero than
to catch a divide-by-zero exception.
Each exception block can contain zero or more orchestration shapes, which act exactly as
they do in an orchestration. As a result, anything that can be done in an orchestration can be
undone with an exception handler. In some situations, you may want to catch an exception
and not do anything as a result. This will prevent the exception from being passed up to the
next scope looking for an exception handler.
The arrangement of exception handlers is important in situations in which multiple
exceptions blocks exist. The first block that can catch the exception will catch it and execute
without evaluating other handlers. Place the most specific exceptions first working toward
more general exceptions, the most general of which is the General Exception.
Note: The process of adding and configuring exception handing for an orchestration is
covered in detail in the Module 10 Lab.
Lab: Automating Business Processes

Scenario
BizTalk orchestrations can be used to automate business decisions and other processes. In
this lab, you will create a new BizTalk orchestration that will process credit sales orders.
Procedure List
window.
Start.

Procedure List
Exercise 1: Examine an Existing Project
Overview
In upcoming labs, you will add functionality to the LoanApproval project that will evaluate
and approve loans. Initially, this project contains several artifacts that are required for this
lab. In this exercise, you will examine the FinalLoanDocument schema and the
SalesOrder_To_FinalLoanDocument map to familiarize yourself with their design.
Examine the LoanApproval Project

Procedure List
1. In Windows Explorer, navigate to C:\AllFiles\LabFiles\Lab9\AdvWorks and then
double-click AdvWorks.sln.
2. In Solution Explorer, double-click FinalLoanDocument.xsd.
3. In the FinalLoanDocument schema, right-click <Schema>, and then click Expand
Schema Node.
Notice the Distinguished Fields of the FinalLoanDocument schema.
5. Click the Property Fields tab.
Notice the Promoted Properties of the FinalLoanDocument schema.
6. Click OK to close the Promote Properties dialog box.
7. Close the FinalLoanDocument schema, and then click Yes to save changes.
8. In Solution Explorer, double-click SalesOrder_To_FinalLoan.btm.
Examine the SalesOrder_To_FinalLoan map.
9. Close the SalesOrder_To_FinalLoan map.
Exercise 2: Promote Distinguished Fields
Overview
Specifying a field in a schema as distinguished enables you to easily access the field from
within an orchestration for decision-making and data-manipulation purposes. In this
exercise, you will distinguish several fields that will be used in the orchestration.
Promote Three Distinguished Fields

Procedure List
1. In Solution Explorer, in the Messaging project, double-click SalesOrder.xsd.
2. In the SalesOrder schema, right-click <Schema>, and then click Expand Schema
Node.
4. In the Promote Properties dialog box, click Comment, and then click Add.
5. Repeat step 4 for OrderTotal and OrderType, and then click OK.
6. On the File menu, click Save All, and then close the SalesOrder schema.
Exercise 3: Create a New Orchestration
Overview
Adventure Works offers two types of financing in their stores. Loans for more than $1,000
are sent to Woodgrove Bank, while loans of $1,000 or less are managed by the Adventure
Works finance department. In this exercise, you will create an orchestration that will process
the credit sales orders and determine the loan type.
Create the ProcessOrder_Credit Orchestration

Procedure List
1. In Solution Explorer, expand Processes, right-click ProcessOrder_Cash.odx, and then
click Copy.
2. Right-click Processes, and then click Paste.
3. Click Copy of ProcessOrder_Cash.odx. In the Properties window, in the File Name
box, type ProcessOrder_Credit.odx, and then press ENTER.
5. In the Properties window, in the Typename box, type ProcessOrder_Credit.
7. In the Message_1 Properties window, in the Identifier box, type msgFinalLoan.
9. In the Select Artifact Type dialog box, in the left pane, click
AdvWorks.LoanApproval, in the right pane, click FinalLoanDocument, and then click
OK.
10. In the ProcessOrder_Credit orchestration, right-click the arrow immediately below
the Sales Order receive shape, point to Insert Shape, and then click Transform.
Name box, type Construct msgFinalLoan.
12. In the Messages Constructed list, click msgFinalLoan.
type Map to Final Loan.
AdvWorks.LoanApproval, in the right pane, click SalesOrder_to_FinalLoan, and
then click OK.
17. In the Transform Configuration window, click Source, and then in the Variable
18. Click Destination. In the Variable Name list, click msgFinalLoan, and then click OK.
19. Right-click the arrow below the Construct msgFinalLoan shape, point to Insert
Shape, and then click Decide.
20. In the Properties window, in the Name box, type Determine Lender.
21. In the ProcessOrder_Credit orchestration, click the Rule_1 shape, and then in the
23. In the BizTalk Expression Editor, in the text box, type
msgFinalLoan.Loan.Amount>1000, and then click OK.
24. Right-click the placeholder below the Large branch, point to Insert Shape, and then
click Send.
Property Setting
Name Notify Bank
Message msgFinalLoan
You will make the necessary changes to the Else branch in a later lab.
Overview
The ports in this orchestration ports are configured as late bound (Specify Later), so they
must be bound to a physical port after the assembly is deployed. Using late binding
separates the design of an orchestration and its implementation. In this exercise, you will
add a new late bound orchestration port and reconfigure the existing ports to use late
binding.
Reconfigure Port Types

Procedure List
1. In Orchestration View, expand Types, Port Types, right-click SalesOrderType, and
then click Delete.
2. Right-click RestockType, and then click Delete.
Since these port types are defined in the ProcessOrder_Cash orchestration, they
cannot be defined in this orchestration, too. You must delete the port types from
this list and then reconfigure the ports to use the existing port types from the
ProcessOrder_Cash orchestration.
3. On the left Port Surface, right-click the SalesOrder port, and then click Configure
Port.
4. On the Welcome to the Port Configuration Wizard page, click Next.
5. On the Port Properties page, click Next.
7. On the Port Binding page, click Next, and then click Finish.
8. Repeat steps 3–7 for the SO_Complete port.
9. Right-click the Restock port, and then click Configure Port.
AdvWorks.Processes.RestockType, and then click Next.
Create a Send Port

Procedure List
Wizard, click Next.
3. On the Port Properties page, in the Name box, type BankNotification, and then click
Next.
4. On the Select a Port Type page, in the Port Type Name box, type BankNotifyType,
7. Drag the green arrow from Notify Bank send shape to the BankNotification send
port.
8. In the BankNotification send port, click Operation_1, and then in the Identifier box
of the Properties window, type NotifyLender.
9. In the BankNotification send port, click Request, and then in the Name box of the
Properties window, type msgFinalLoan.
Create Filter Expressions for Orchestrations

Procedure List
2. In the ProcessOrder_Cash orchestration, click the Sales Order receive shape, in the
Properties window, click Filter Expression, and then click the ellipsis (…) button.
3. In the Property list, click AdvWorks.Messaging.PropertySchema.OrderType, in the
Value box, type “CASH” (include the quotation marks), and then click OK.
4. On the File menu, click Save All, and then close the ProcessOrder_Cash
orchestration.
5. In the ProcessOrder_Credit orchestration, click the Sales Order receive shape, in the
Value box, type “CRED” (include the quotation marks), and then click OK.
7. On the File menu, click Save All, and then close the ProcessOrder_Credit
orchestration.
Exercise 5: Build, Deploy, and Test the BizTalk Application
Overview
When you test the application, you will submit both cash and credit orders. The cash orders
will be processed by the ProcessOrders_Cash orchestration, and the credit orders will be
processed by the ProcessOrders_Credit orchestration. Credit sales orders over $1,000 will
result in a bank notification message that is sent to Woodgrove Bank. In this exercise, you
will deploy and test the application.
Test the Application

Procedure List
2. Right-click Solution ‘AdvWorks’, and then click Project Build Order.
Notice the order in which the projects must be built. The Project Dependencies
dialog box can be used to reorder these builds. If you try to build or deploy the
Processes project, the Messaging and LoanApproval projects will automatically
build and/or deploy.
3. Click OK to close the Project Dependencies dialog box.
4. In Solution Explorer, right-click Processes, and then click Deploy.
5. In the Output window, notice that all three projects were built and deployed.
6. On the Start menu, point to All Programs, then point to Microsoft BizTalk Server
2010, and then click BizTalk Server Administration.
7. In BizTalk Server Administration Console, expand BizTalk Server Administration,
BizTalk Group, Applications, AdventureWorks.
9. In the Configure Application dialog box, click ProcessOrder_Cash, and then
configure the settings using the information in the following table.
Property Settings
Host BizTalkServerApplication
SalesOrder SalesOrder
Restock RestockFILE
SO_Complete CompleteFILE
In the previous lab, this orchestration was configured with “early binding,”
meaning that the physical ports were automatically created and bound to the
logical ports when the assembly was deployed. In this lab, you are using late
binding, so the logical ports must be bound to the physical ports manually.
10. In the Configure Application dialog box, click ProcessOrder_Credit, configure the
settings using the information in the following table, and then click OK.
Property Setting
Restock RestockFILE
BankNotification BankNotifyFILE
Both orchestrations use the SalesOrder receive port. The filter expressions you
configured on the receive shapes in each orchestration will prevent an
orchestration from getting any message it shouldn’t.
11. In the BizTalk Server Administration Console, right-click AdventureWorks, click Start,
and then in the Start ‘AdventureWorks’ Application dialog box, click Start.
12. In Windows Explorer, navigate to C:\AllFiles\LabFiles\Lab9, and then copy all four
XML files to the SalesOrderIN folder.
It may take a moment for the messages to be processed and moved from the
13. Open the OUT folder, and then examine each of the messages.
Notice that the Cash and Restock orders have been processed and that the Credit
order over $1000 has a BankNotify message.
Module 10: Creating Transactional
Business Processes
Module objective:
How to create atomic and long-running business transactions.
Overview
A Microsoft® BizTalk® Server orchestration provides a transactional programming model
that includes support for both atomic and long-running transactions, in addition to support
for nested orchestrations, exception handling, and methods for recovering from failed
transactions.
Lesson 1: Introduction to Transactions
Lesson objective:
Explain how transactions work and how persistence points affect the performance of a BizTalk
orchestration.
Overview
BizTalk orchestration provides a transactional programming model that includes support for
exception handling and recovery from failed transactions. You can create atomic
transactions that automatically roll back their actions if an error occurs or long-running
transactions that can contain other transactions and custom exception handling. This means
that if your business process fails for any reason, you can choose what happens, whether it’s
sending an error notification to a person or system or updating a SQL database.
What Are Transactions?
Describe the types of transactions that BizTalk Server 2010 supports.
Overview
The BizTalk Server orchestration engine manages the state of running processes, applies
business logic, and supports the invocation of complex processes and transaction sets, as
well as the persistence of running and saved business processes. Business processes can be
composed as discrete pieces of work that can consist of:
 Atomic transactions that automatically roll back all changes in case of errors, much
like database transactions.
 Long-running transactions that can span days, weeks, and longer time durations;
they contain nested transactions and use custom exception handling to recover
from error scenarios.
Scopes
These transactional mechanisms are managed through Scope shapes in the Orchestration
Designer. A scope contains one or more blocks. It has a body and can optionally have
appended to it any number of exception-handling blocks. It may have an optional
compensation block as well, depending on the nature of the scope. Each Scope shape that is
added adds an additional Context, which has its own Messages, Variables, Segments, and
Class Types.
What Is Instance Persistence?
Describe what a persistence point is and how a persistence point affects performance of a
BizTalk orchestration.
Persistence
The orchestration engine saves the entire state of an orchestration instance at various
points during processing to the BizTalk MessageBox Database. This enables BizTalk to
recover an orchestration from a catastrophic failure or to conserve memory for a business
process that may be waiting hours, weeks, or days for input before processing can continue.
If the orchestration engine needs to rehydrate the orchestration instance, start up from a
controlled shutdown, or recover from an unexpected shutdown, it will run the orchestration
instance from the last persistence point as though nothing else had occurred. For example, if
a message is received, but there is an unexpected shutdown before state can be saved, the
engine will not record that it has received the message, and it will receive it again upon
restarting.
Persistence Points in an Orchestration
Identify persistence points within an orchestration.
Persistence Points
The state of an orchestration includes any Microsoft .NET–based components that may be
used in the orchestration, in addition to all messages and variables. The engine stores state
at the following persistence points:
 End of a transactional scope (atomic or long running).
 Debugging breakpoints.
 The execution of other orchestrations through the Start Orchestration shape.
 A Send shape; except when contained by an atomic transaction, or immediately
followed by the end of the orchestration.
 When an orchestration instance is suspended.
 When the system is shut down in a controlled manner.
 When the engine determines that it will dehydrate the orchestration instance.
 When an orchestration instance completes.
Steps for Setting Up a Transaction
Identify the steps involved in setting up a transaction.
Steps
The steps for setting up a transaction within an orchestration and configuring exception
handling are:
1. Create a scope.
2. Identify the type of transaction that is needed and configure the scope as
transactional; also identify an appropriate value for the transaction timeout.
3. Determine the level at which the transaction will be compensated, if at all.
4. Identify the potential errors that will cause the need for compensation.
5. Add the appropriate exception handlers to scopes.
6. Define the code that will be used to compensate the completed transaction.
Lesson 2: Configuring Transactions
Lesson objective:
Create and configure long-running and atomic transactions.
Overview
An orchestration or scope can be treated as an atomic transaction, a long-running
transaction, or neither. In this lesson, you will learn how to configure long-running and
atomic transactions, how to create modular orchestrations, and how to add compensation
code to your transactions.
Defining an Orchestration as Transactional
Modify the properties of an orchestration to enable transaction processing.
Overview
You can configure your orchestration as a transaction in much the same way that you can
configure a Scope shape as a transaction. An orchestration can be treated as an atomic
transaction, as a long-running transaction, or as neither. The transaction type is specified by
setting the Transaction Type property for the orchestration to Atomic, Long Running, or
None.
You cannot nest a transactional scope within a scope or orchestration that is not
transactional. An enclosing scope or orchestration that is not transactional will not manage
state as is necessary to properly handle the state management of any scopes within it.
Creating a Long-Running Transaction
Configure an orchestration to enable a long-running transaction.
Overview
You use a long-running transaction when the transaction may need to run for an extended
time and you do not need full ACID (Atomicity, Consistency, Isolation, and Durability)
properties—that is, you do not need to guarantee isolation of data from other transactions.
A long-running transaction may include long periods of inactivity, often because it is waiting
for external messages to arrive.
Characteristics
Long-running transactions possess consistency and durability, but not atomicity and
isolation. The data in a long-running transaction is not locked; therefore, other processes or
applications can modify it. The isolation property for state updates is not maintained within
the orchestration because holding locks for a long duration is impractical. A long-running
transaction is considered committed when the last statement in it has been completed.
Long-running transactions can contain both atomic transactions and other long-running
transactions—in fact, they can be nested many levels deep. For example, your long-running
transaction may contain two other long-running transactions, each of which contains atomic
transactions. Nesting is particularly useful if one or more components of an overall
transaction must be atomic but the overall transaction itself must be long running.
Example
Consider the process of receiving and approving a loan application. The application can
arrive at any time, and the various steps in the process of fulfilling the application may take a
considerable time, but you may still want to treat the entire process as one transaction. In
this case, the overall transaction clearly needs to be long running, but any one individual
step (such as acknowledging a deposit) could be atomic.
Creating an Atomic Transaction
Configure an orchestration to enable an atomic transaction.
Overview
Atomic transactions guarantee that any partial updates will be rolled back automatically in
the event of a failure during the transactional update and that the effects of the transaction
will be erased. You can use atomic transactions when you require full ACID properties on the
data, such as when you must isolate the data from other transactions. However, the full
ACID properties are only achieved when making updates or communicating with a system
that is transactional aware. For example, if you are updating a Microsoft SharePoint® site or
sending an e-mail message, an automatic rollback may not be achieved.
Characteristics
An atomic transaction ensures that state changes within the transaction (such as
modifications to variables, messages, and objects) are visible outside the scope of the
atomic transaction only upon commitment of the transaction. The intermediate state
changes are isolated from other parts of an orchestration.
If an atomic transaction contains a Receive shape, a Send shape, or a Start Orchestration
shape (a shape that invokes another orchestration asynchronously), the corresponding
actions will not occur until the transaction has been committed.
Atomic Orchestrations
You can also define an entire orchestration as an atomic transaction when you need to
provide ACID properties for the data within an entire orchestration. See “Defining an
Orchestration as Transactional” earlier in this module.
Creating Modular Business Processes
Configure an orchestration to call or start another orchestration.
Overview
You can use either the Call Orchestration shape or the Start Orchestration shape to invoke
one orchestration from another. You can nest orchestrations many levels deep. For example,
a called orchestration can call a third orchestration, which can call a fourth, and so on.
Call Orchestration Shape

The Call Orchestration shape invokes another orchestration synchronously. In this case, the
calling orchestration waits for the nested orchestration to finish processing before it
continues its work.
Start Orchestration Shape

The Start Orchestration shape functions similarly to the Call Orchestration shape, but it
invokes another orchestration asynchronously—that is, the flow of control in the calling
orchestration proceeds beyond the invocation without waiting for the nested orchestration
to finish processing.
Parameters
In either case, you can specify parameters to be passed to the called orchestration.
Parameters can be messages, variables, or port references. Parameters supply information
to the invoked orchestration, which in turn sends information back to the enclosing
orchestration. Parameters can be specified as in, out, or to be passed by reference on an
Demonstration: Creating Transactions
Learn to create transactional orchestrations and add transactional scopes to orchestrations.

demonstrations. This solution provides artifacts and file paths that differ from those
used in the previous demonstrations.
Set an Orchestration as Transactional

1. In Microsoft Windows Explorer, navigate to
C:\AllFiles\DemoCode\Module10\AdvWorks, and open AdvWorks.sln.
2. In Solution Explorer, in the Processes project, double-click ProcessOrder_Credit.odx
to open the orchestration.
3. Click any of the white space in the orchestration, and then in the
ProcessOrder_Credit Properties window, change the Transaction Type to Atomic.
Notice that several new properties have been added to the orchestration now
that it is a transaction.
4. In the Transaction Identifier box, type ProcessOrder_CreditTrans.
Add a Transactional Scope to an Orchestration

1. In the ProcessOrder_Credit orchestration, right-click the downward-pointing arrow
above the Determine Lender Decide shape, point to Insert Shape, and then click
Scope.
2. In the Scope shape Properties window, configure the properties as shown in the
following table.
Property Value
Name Send Loan to Lender
Transaction Type Long Running
3. In the Properties Window dialog box, click Details.

Notice the error description, which reads as follows: “An Atomic Transaction
cannot contain any other Transactions.”
4. In the Properties Window dialog box, click OK.
5. Click any of the white space in the orchestration, and then in the
ProcessOrder_Credit Properties window, change the Transaction Type to Long
Running.
6. In the Transaction Identifier box, type ProcessOrder_CreditTrans.
7. Click the Send Loan to Lender scope, and then, in the Properties window, change
the Transaction Type to Long Running.
8. In Orchestration Designer, drag the Determine Lender decide shape to a location
inside the Send Loan to Lender scope shape.
Add an Exception Handling Block to a Scope

1. On the left port surface, click the BankNotification send port, then in the
BankNotification Port Properties window, in the Delivery Notification list, select
Transmitted.
The BankNotification send port is now configured to provide a delivery
notification. The orchestration run-time will throw an exception if the physical
send port fails to transmit the message.
2. In Orchestration Designer, right-click the Send Loan to Lender scope shape, and
then click New Exception Handler.
3. In the Catch Exception Shape Properties window, in the Name box, type Catch
DeliveryFailureException, then in the Exception Object Name box, enter Ex, and
then in the Exception Object Type list, click <.NET Exception>.
Microsoft.XLANGs.BaseTypes, then in the right pane, click
DeliveryFailureException, and then click OK.
5. Inside the Catch DeliveryFailureException block, right-click Drop a shape from the
toolbox here, point to Insert Shape, and then click Message Assignment.
6. Name the new Construct Message shape Construct Exception Message, and in the
Messages Constructed list, click msgCancelOrder.
7. Double-click the Message Assignment shape, and in the BizTalk Expression Editor,
enter the following lines of code.
msgCancelOrder = msgSalesOrder;
msgCancelOrder.Comment =
System.String.Format(
“Order canceled. Error: Delivery of loan document failed.
[{0}]”,
ex.Message);
8. Right-click beneath the Message Assignment shape, point to Insert Shape, and then
click Send.
9. In the Send Shape Properties window, change the Name to Cancel Order, and then
in the Message list, click msgCancelOrder.
10. Connect the Send shape to the CancelOrder port.
click Terminate.
12. Double-click the Terminate shape, and in the BizTalk Expression Editor window,
enter the following line of code.
System.String.Format(“Exception caught: {0}”, ex.Message);
This exception block will create a new message to cancel the order, and then it
will terminate the orchestration.
Adding Compensation Code
Add compensation handling to an orchestration.
Overview
You can add compensation code to your orchestration so that if an error occurs during a
long-running transaction, the effects of the transaction will be reversed. When necessary,
the compensation code is called after the transaction has completed its actions. At that
point, the state of the orchestration is known, and the appropriate compensation code can
be applied.
You can also use compensations for atomic transactions. These compensations can be called
only after the atomic transaction commits. You must write code to undo or reverse the path
of the normal execution in the compensation.
Default Compensation
If you do not add your own compensation, the run-time engine performs a default
compensation that invokes the compensations of any nested transactions in the current
transaction. The run-time engine first invokes the compensation of the most recently
completed transaction, and then it works backward until it has compensated all nested
transactions.
Demonstration: Adding Compensation Code
Learn to add exception handling and compensation blocks to a transactional scope.
Add a Compensation Block to a Transaction

2. Right-click the Send Loan to Lender scope shape, and then click New Compensation
Block.
3. In the Compensation Block Properties window, change the Name to Send Order
Compensation
4. Inside the Compensation Block, right-click Drop a shape from the toolbox here,
point to Insert Shape, and then click Message Assignment.
5. Right-click the new Construct Message shape, and name it Construct Exception
Message, and in the Messages Constructed list, click msgCancelOrder.
6. Double-click the Message Assignment shape, and in the BizTalk Expression Editor,
enter the following lines of code.
msgCancelOrder = msgSalesOrder;
msgCancelOrder.Comment =
“Customer cancelled order. Transaction Compensation executed”;
click Send.
8. In the Send Shape Properties window, change the Name to Cancel Order, and then
in the Message list, click msgCancelOrder.
9. Connect the Send shape to the CancelOrder port.
This scenario assumes that additional shapes will eventually be added to follow
after the Send Loan to Lender scope shape.
This compensation block would execute if any of those subsequent shapes threw
an exception. The orchestration’s default exception handler would catch the
exception, and execute the compensation blocks on any of its scope shapes.
This compensation block would create and send a new message to cancel the
order, and then it will return control to the orchestration run-time, allowing
other compensation blocks to execute.
10. Close all open windows, and shut down the bt10d-demos virtual machine.
Lab: Creating Transactional Business Processes
Scenario
Exception handling can be added to scope shapes within orchestrations to specify actions to
be executed in the event that an exception occurs. BizTalk orchestrations can include both
long-running and atomic transactions. Compensation, a feature of transactions, allows for
the reversal of previously completed processes. In this lab, you will configure exception
handling and compensation for the ProcessOrder_Credit orchestration.
Procedure List
window.
Start.

Procedure List
Exercise 1: Adding Exception Handling to an Orchestration
Overview
Various things can cause an exception to occur in an orchestration. Adding exception
handling to an orchestration enables you to specify actions to be performed when an
exception occurs. Exception handling blocks can only be added to scope shapes. In this
exercise, you will add a scope shape to the ProcessOrder_Credit orchestration, and then
configure an exception handler that will send a message when a specific exception is caught.
Add a Scope Shape

Procedure List
open AdvWorks.sln.
2. In Solution Explorer, in the Processes project, double-click ProcessOrder_Credit.odx
to open the orchestration.
above the Determine Lender Decide shape, point to Insert Shape, and then click
Scope.
4. Right-click the Scope_1 shape and click Properties Window
5. In the Scope_1 Properties window, configure the properties as shown in the
following table.
Property Value
Transaction Type None
6. In Orchestration Designer, drag the Determine Lender Decide shape to a location

inside the Send Loan to Lender scope shape.
Add Exception Handling to the Send Loan to Lender Scope

Procedure List
1. In Orchestration Designer, right-click the Send Loan to Lender scope shape, and
2. In the CatchException_1 Properties window, in the Exception Object Type list, click
<.NET Exception>.
Microsoft.XLANGs.BaseTypes, in the right pane, click DeliveryFailureException, and
then click OK.
This exception handler will be initiated when the send port returns a delivery
failure notification to a send shape in the Send Loan to Lender scope.
4. In the CatchException_1 Properties window, in the Name box, type Catch
DeliveryFailure, and then in the Exception Object Name box, type DeliveryFailure.
5. In the Catch DeliveryFailure catch exception shape, right-click Drop a shape from
the toolbox here, point to Insert Shape, and then click Send.
6. In the Send_1 Properties window, in the Name box, type Rescind Notify Bank, and
then in the Message list, click msgFinalLoan.
Add the Rescind Port

Procedure List
2. On the Welcome page of the Port Configuration Wizard, click Next.
3. On the Port Properties page, in the Name box, type Rescind, and then click Next.
4. On the Select a Port Type page, click Use an existing Port Type, in the Available Port
Types box, click AdvWorks.Processes.RescindType, and then click Next.
5. On the Port Binding page, in the Port direction of communication list, click I’ll
always be sending messages on this port, and then click Next.
Notice that the Rescind port has three operations; the RescindType Port Type has
been provided for you. The three operations will be used for the exception
handling and compensation of this orchestration.
7. Connect the Rescind Notify Bank send shape to the BankNotification operation on
the Rescind port.
Add a Throw Exception Shape

Procedure List
1. Right-click the arrow below the Rescind Notify Bank send shape, point to Insert
Shape, and then click Throw Exception.
2. In the ThrowException_1 Properties window, in the Name box, type Rethrow
DeliveryFailure, and then in the Exception Object list, click DeliveryFailure.
Later in this lab, you will configure another exception handler that will catch the
rethrown DeliveryFailure exception.
Configure the BankNotification Port to Throw an Exception

Procedure List
1. On the left Port Surface, click the BankNotification port.
2. In the Port Properties window, in the Delivery Notification list, click Transmitted.
The BankNotification port will now throw the DeliveryFailure exception that the
exception handler is expecting.
Add a Scope Shape

Procedure List
1. Above the Construct msgSOComplete construct message shape, right-click the
arrow, point to Insert Shape, and then click Scope.
following table.
Property Value
Name Completed Sales Order

3. Drag the Construct msgSOComplete and Complete Sales Order shapes to locations
inside the Completed Sales Order scope shape.
Add Exception Handling to the Completed Sales Order Scope

Procedure List
1. In Orchestration Designer, right-click the Completed Sales Order scope shape, and
<.NET Exception>.
then click OK.
This exception handler will be initiated when the send port returns a delivery
failure notification to a send shape in the Completed Sales Order scope.
5. In the Catch DeliveryFailure catch exception shape, right-click Drop a shape from
the toolbox here, point to Insert Shape, and then click Throw Exception.
rethrown DeliveryFailure exception. Notice that this exception handler does not
send a message to the Rescind port. It simply re-throws the exception.
Configure the SO_Complete Port to Throw an Exception

Procedure List
1. On the right Port Surface, click the SO_Complete port.
The SO_Complete port will now throw the DeliveryFailure exception that the
Exercise 2: Adding Compensation to an Orchestration
Overview
Compensation is used to reverse a transaction that has been committed. Compensation
blocks can only be added to transactional scopes. In this exercise, you will create three
transactions; each transaction will have its own compensation block that is configured to
send a rescinding message if an approval message has previously been sent.
Configure the Orchestration and the Send Loan to Lender Scope Shape as a Long-
Running Transaction
Procedure List
1. Click any white space on the ProcessOrder_Credit orchestration, in the Properties
window, in the Transaction Type list, click Long Running, and then in the
Transaction Identifier box, type LR_ProcessOrder_Cred.
2. In the ProcessOrder_Credit orchestration, click the Send Loan to Lender scope
shape, and then configure its properties as shown in the following table.
Property Value
Transaction Identifier LR_LoanToLender
Add Compensation to the Send Loan to Lender Scope Shape

Procedure List
Block.
2. In the Compensation_1 Properties window, in the Name box, type Send Loan Comp.
3. In the Send Loan Comp compensation block, right-click Drop a shape from the
toolbox here, point to Insert Shape, and then click Send.
4. In the Send_1 Properties window, in the Name box, type Rescind Notify Bank, and
then in the Message list, click msgFinalLoan.
5. Connect the Rescind Notify Bank send shape to the BankNotification operation on
the Rescind port.
Alternatively, you could have copied and pasted the Rescind Notify Bank shape
from the exception handler above.
Add a Transactional Scope to the Orchestration

Procedure List
1. Above the Construct msgRestock construct message shape, right-click the arrow,
point to Insert Shape, and then click Scope.
following table.
Property Value
Name Restock Inventory

Transaction Identifier LR_Restock
3. Drag the Construct msgRestock and Restock send shapes to a location inside the
Restock Inventory scope shape.
Add Compensation to the Restock Inventory Transaction

Procedure List
1. Right-click the Restock Inventory scope shape, and then click New Compensation
Block.
2. In the Compensation_1 Properties window, change the Name to Restock Inventory
Comp.
3. In the Restock Inventory Comp compensation block, right-click Drop a shape from
4. In the Send_1 Properties window, in the Name box, type Rescind Restock, and then
in the Message list, click msgRestock.
5. Connect the Rescind Restock send shape to the Restock operation on the Rescind
port.
Add Compensation to the Completed Sales Order Transaction

Procedure List
1. Click the Completed Sales Orders scope shape, and then configure its properties as
shown in the following table.
Property Value
Transaction Identifier LR_CompleteSO
2. Right-click the Completed Sales Orders scope shape, and then click New
Compensation Block.
3. In the Compensation_1 Properties window, change the Name to Complete Sales
Order Comp.
4. In the Complete Sales Orders Comp compensation block, right-click Drop a shape
from the toolbox here, point to Insert Shape, and then click Send.
5. In the Send_1 Properties window, change the Name to Rescind Complete Sales
Order, and then in the Message list, click msgSalesOrderComplete.
6. Connect the Rescind Complete Sales Order send shape to the CompletedSalesOrder
operation on the Rescind port.
Exercise 3: Calling Compensation
Overview
Transactions can be nested to provide a parent/child hierarchy. Parent transactions can call
the compensation for each child transaction from the parent’s exception handler, or as part
of the parent’s compensation. In this exercise, you will first add a long-running transaction
to the orchestration. Next, you will move all the existing shapes, including the transactional
scope shapes, into the parent transaction. Finally, you will add an exception handler to the
parent transaction that will call the compensation of some of the child transactions.

Procedure List
1. In the ProcessOrder_Credit orchestration, right-click the arrow just above the red
stop sign at the bottom of the orchestration, point to Insert Shape, and then click
Scope.
following table.
Property Value
Name Credit Process
Transaction Identifier LR_CreditProcess
3. Double-click the icon at the top of the Send Loan to Lender scope shape to collapse
it.
4. Repeat step 3 to collapse the Restock Inventory scope shape and the Completed
Sales Order scope shape.
5. Drag the Completed Sales Order scope shape inside the Credit Process scope shape.
6. Drag the Restock Inventory inside the Credit Process scope shape, and above the
Completed Sales Order scope shape.
7. Drag the Send Loan to Lender scope shape inside the Credit Process scope shape,
and above the Restock Inventory scope shape.
Initiating Compensation from an Exception Handler

Procedure List
1. Right-click the Credit Process scope shape, and then click New Exception Handler.
General Exception, and then in the Name box type Catch General Exception.
3. In the Catch General Exception exception handler, right-click Drop a shape from the
toolbox here, point to Insert Shape, and then click Compensate.
4. In the Compensate_1 Properties window, change the Name to CompleteSO Comp,
and then in the Compensation list, click LR_CompleteSO.
5. Right-click the line below the CompleteSO Comp shape, point to Insert Shape, and
then click Compensate.
6. In the Compensate_1 Properties window, in the Name box, type Restock Comp, and
then in the Compensation list, click LR_Restock.
Notice that the exception handler for the Credit Process scope does not call the
compensation block of the Send Loan to Lender scope. Consequently, the Send
Loan to Lender compensation code will never be called.
Exercise 4: Testing the Application
Overview
In this exercise, you will test the application. First, you will process messages normally. You
will then reconfigure a port to simulate the loss of connectivity between Woodgrove Bank
and Adventure Works. Finally, you will resubmit the message to test the exception handling
and compensation.
Deploy the Solution

Procedure List
Solution.
Configure and Start the Application

Procedure List
BizTalk Group, Applications, and AdventureWorks.
4. In the Configure Application dialog box, click ProcessOrder_Cash, and then
configure the bindings as shown in the following table.
Property Value
Inbound Logical Ports Receive Ports
Outbound Logical Ports Send Ports/Send Port Groups
Restock RestockFILE

bindings as shown in the following table, and then click OK.
Host Value
Rescind RescindFILE
Restock RestockFILE
6. Right-click AdventureWorks, and then click Start.


Procedure List
2. Open and examine each message.
There are two Cash messages, which will be processed by the ProcessOrder_Cash
orchestration, and there are two Credit messages, which will be processed by the
ProcessOrder_Credit orchestration. The Credit order for over $1,000 will be sent
to Woodgrove Bank, and the other will be financed by Adventure Works.
Notice that the messages disappear when they are picked up for processing by
BizTalk Server.
5. In Windows Explorer, navigate to C:\AllFiles\LabFiles\Lab10\OUT, and then notice
the nine output messages.
Each order has a “Complete” message and a “Restock” message. The credit order
over $1,000 also has a BankNotify message, which will be sent to Woodgrove
Bank.
6. Delete all of the XML files in the OUT folder.
Modify the CompleteFILE Send Port

Procedure List
1. In the BizTalk Server Administration Console, in AdventureWorks, click Send Ports.
2. Double-click the CompleteFILE send port.
3. In the Send Port Properties dialog box, click Configure.
4. In the Destination folder box, type C:\FolderThatDoesNotExist, and then click OK.
The CompleteFILE send port won’t be able to send the completed sales order
message and will cause the exception handling and compensation to be called.
5. In the Send Port Properties dialog box, click Transport Advanced Options, change
the Retry count to 0, and then click OK.
6. Right-click the CompleteFILE send port, and then click Start.
Test the Exception Handling and Compensation

Procedure List
1. In Windows Explorer, navigate to C:\AllFiles\LabFiles\Lab10, and then open
CredSalesOrder1Info.xml.
Notice that this is the Credit order that totals $1,500, and will therefore be sent
to Woodgrove Bank for financing.
2. Copy CredSalesOrder1Info.xml to the SalesOrderIN folder.
Notice that the message disappears when it is picked up for processing by BizTalk
Server.
the output messages.
The BankNotification and Restock messages were sent, but delivery of the
Complete message failed. The delivery failure triggered the Credit Process
exception handler, which attempted to execute compensation for the Restock
Inventory scope and the Completed Sales Order scope. A scope’s compensation
execute only if it has completed successfully earlier in the long-running
transaction. Therefore, only the Restock Inventory compensation block will
execute.
Modify the BankNotifyFILE Send Port

Procedure List
2. Double-click the BankNotifyFILE send port.
The BankNotifyFILE send port won’t be able to send the bank notification
message and will cause the compensation and exception handling to be called.
5. In the Send Port Properties dialog box, click Transport Advanced Options, change
the Retry count to 0, and then click OK.

Procedure List
Notice that this is the Credit order that totals $1,500, and will therefore be sent
to Woodgrove Bank for financing.
Server.
the output messages.
The BankNotification message was unable to send. The delivery failure triggered
the Send Loan to Lender exception handler, which send a message to the Rescind
port, and re-threw the delivery exception. The re-thrown exception was caught
by the Credit Process exception handler, which attempted to call compensation
on the Restock Inventory scope and the Completed Sales Order scope. Since
these scopes had not yet executed, their compensation blocks did not run.
Module 11: Integrating Business Rules
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
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 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

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

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.
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
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.
Procedure List
window.
Start.

Procedure List
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
click Business Rule Composer.
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.
Definition.
11. In the Definition name box, type Employment (months).
12. In the Definition description box, type Length of employment.
then click Open.
14. In the Select Binding dialog box, expand LoanApp and Employment, click
TimeInMonths, and then click OK.
16. In the Display name box, type Months Employed, and then click Finish.
Definition.
19. In the Definition name box, type Loan Amount.
20. In the Definition description box, type Desired loan amount.
then click Open.
22. In the Select Binding dialog box, expand LoanApp and LoanConditions, click
LoanAmount, and then click OK.
24. In the Display name box, type Requested Loan Amount, and then click Finish.
Definition.
27. In the Definition name box, type Residency (months).
28. In the Definition description box, type Length at residence.
then click Open.
30. In the Select Binding dialog box, expand LoanApp and Residency, click
32. In the Display name box, type Months at Current Residence, and then click Finish.
Definition.
35. In the Definition name box, type Secondary Income.
36. In the Definition description box, type Income from sources other than primary
income.
then click Open.
38. In the Select Binding dialog box, expand LoanApp and Income, click OtherIncome,
and then click OK.
40. In the Display name box, type Monthly Secondary Income, and then click Finish.
Create the Update Loan Status “Set” Operation Definition

Procedure List
Definition.
3. In the Definition name box, type Update Loan Status.
then click Open.
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},
Create the Set Loan to Income Ratio “Set” Operation Definition

Procedure List
Definition.
3. In the Definition name box, type Set Loan to Income Ratio.
then click Open.
LoanToIncome, and then click OK.
7. In the Display format string box, type The loan to income ratio for this loan is: {0},
Create the Month Range Definition

Procedure List
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
Definition.
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.
13. Drag Residency (months) from the Facts Explorer pane to argument1, and then drag
Month Range to argument2.
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
2. Rename the rule Denied Income.
3. Right-click Conditions, point to Predicates, and then click LessThanEqual.
5. Drag Primary Income from the Facts Explorer pane to value1, and then drag
Secondary Income to value2.
9. Click Status Range, and then in the drop-down list, click Pending.
Create the Denied Residency and Employment Rule

Procedure List
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.
Create the Loan to Salary Ratio Rule

Procedure List
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 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.
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.
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.
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.
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 BRE-
Approved.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 -
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.
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
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>.
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
2. In the Message_1 Properties window, in the Identifier box, type msgInterimLoan, in
the Message Type list, expand Schemas, and then click
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.

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

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.

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

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.
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 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.
Property Value
Name Construct msgInterimLoan
Message Constructed msgInterimLoan
Transform Shape
Property Value
Map Destination msgInterimLoan
Property Value
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.Loa
nAmount;
msgInterimLoan.Loan.LoanToIncomeRatio =
msgInterimLoan.Loan.Status=msgLoanApp.LoanConditions.LoanStatu
s;
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 ManualApprovalCorrSet
Set
Message msgInterimLoan
Name SharePoint Processing
Receive Shape
Property Value
Following Correlation Set ManualApprovalCorrSet
Message parFinalLoan
Add Orchestration Ports

Procedure List
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
Property Value
Name SharePointResp
Port Type Name (existing Port Type) SharePointType
Direction Receive
5. Connect the Send shape to the SharePointReq port, and then connect the Receive
shape to the SharePointResp port.
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
Property Value
Name LoanDenial
Port Type Name (new Port Type) LoanDenialType
Direction Send
3. Connect the Loan Denial send shape to the LoanDenial send port.
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
Solution.
Configure Port Bindings

Procedure List
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.

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
3. In the Start ‘Adventure Works’ Application dialog box, click Start.
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.
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.
Notice the completed message and the restock message.
13. Delete the two messages.
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.
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.
22. In Windows Explorer, navigate to C:\AllFiles\LabFiles\Lab11\OUT, and notice the
three messages.
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.
27. In Windows Explorer, navigate to C:\AllFiles\LabFiles\Lab11\OUT, and notice the
denial message.
Module 12: Enabling Business Activity
Monitoring
Module objective:
In this module, you will learn how to monitor business activity by using Business Activity
Monitoring (BAM).
Overview
Getting the correct information at the correct time is of critical importance to any business.
Business deals and partnerships are often made or broken solely over questions of
information access. The decisive advantage frequently goes to the business that is armed
with the best information.
The Business Activity Monitoring (BAM) Framework in Microsoft® BizTalk® Server gives you
just such an indispensable advantage. By opening a real-time window into running business
processes, BAM provides business analysts with a direct view of transactions as those
transactions occur—a view that has traditionally been unavailable.
Lesson 1: Introduction to Business Activity Monitoring
Lesson objective:
Explain Business Activity Monitoring and why it can be an important feature of BizTalk Server
solutions.
Gaining Visibility into Business Processes
Describe how BAM is used to gain visibility into running business processes.
Overview
Business Activity Monitoring (BAM) is a tool for monitoring and analyzing data from business
process information sources. The data is presented in a real-time view of business state,
trends, and critical conditions. BAM’s open application programming interface (API) can be
used to gain visibility into data external to BizTalk processes, such as archival data or other
non-BizTalk processes and systems. BAM gives business analysts the data they need when
they need it, enabling them to make better business decisions based on more relevant data.
BAM provides interceptors that can gather data from messages as they are received and
from any point within the business process, such as an orchestration, pipeline, or message
type. BAM also provides auditing capabilities by being able to answer the how and why
behind business decisions.
BAM allows you to determine how your business is performing by answering questions such
as:
1. How long did it take for this process to be approved?
2. How quickly was this order filled after it was received?
3. How many process cycles occurred in the last month? In the last year?
4. How many purchase orders were processed last week?
5. How much is our total revenue this year so far?
By aggregating data, BAM provides an overview of trends experienced in the business while
allowing users to examine individual instances. You can also use BAM to link together
various messages as they travel through the system to create a unified BAM view, which
gives visibility of the entire business process, spanning multiple orchestrations and even
including data external to BizTalk. This visibility is tremendously beneficial for making critical
business decisions.
BizTalk administrators sometimes use BAM to gather and monitor IT operations data in
addition to monitoring business data. Using BAM to monitor IT operations can be
particularly useful when supporting Service Level Agreements.
What Is Business Activity Monitoring (BAM)?
Give a brief introduction of Business Activity Monitoring and the business value that it provides.
Overview
BAM makes it possible for developers, business analysts, and end users, working individually
or collaboratively, to extract the data they need from their business processes.
To gather the necessary business data for business analysts to make decisions regarding
business processes, the business analyst and developer will need to work together to create
one or more BAM activities. BAM activities represent a unit of work in a business, such as
processing a purchase order or a loan application. Activities are used to show the history, or
milestones, and data about a unit of work to the business analysts. BAM activities are
independent of the actual implementation of your BizTalk Server solution. Think of a BAM
activity as a record in a SQL table that you are keeping in synchronization with the actual
unit of work. You can relate multiple BAM activities together as well. An example of relating
activities would be a situation in which a single purchase order contains multiple shipments.
Properly configured BAM activities can allow business users to look at a purchase order and
be able to see shipping information for each item in the purchase order. Developers can use
the BAM API to create BAM activities that span multiple disparate systems. For example, if
one step in a loan process is to execute a Web service or make a call to a mainframe system,
business analysts can include this data in their analysis. BAM activities can also contain
milestones (a date/time measure) throughout the business process that allow business
analysts to see the overall progress of the process and investigate each individual step of the
process.
Key performance indicators (KPIs) allow business analysts to view specific pieces of data in a
business process.
Business analysts can also define views to specify how the activity data will be displayed.
Views can be used to filter the data from BAM. This can be useful if analysts want to see
loans that were processed from a certain state or by a certain loan officer or between two
dates. Filtering allows business analysts to focus only on the data they need to answer
questions on how their business is performing. BAM databases can be shared across BizTalk
Server groups to present an aggregated view of a business process.
Additionally, BAM views can be used to secure and filter information for different audiences.
Who Does What?

 Business analysts use the Microsoft Office Excel® BAM Design Workbook to define the
business requirements for BAM activities and views.
 IT professionals use the BAM Manager to deploy the business requirements into the
BAM databases.
 Developers map the business processes to run-time components by using the Tracking
Profile Editor (TPE) for BizTalk Server.
 Anyone interested in the collected data—developers, IT professionals, business analysts,
and end users—can use the BAM Portal to view, aggregate, search, or create alerts
based on the data collected by BAM.
Business Activity Monitoring Components
Describe the components of the Business Activity Monitoring Framework.
Overview
The Business Activity Monitoring Framework includes interceptors for both pipelines and
orchestrations. These interceptors retrieve specific data as it is being processed and send
the data to the Primary Import database. The other components that BAM utilizes include:
 BizTalk Primary Import database. This database acts as the principal collection point for
real-time data collected by the BAM interceptors. This database contains stored
procedures, tables, triggers, and views that are dynamically generated based on the
BAM Definition Workbook. Data for a specified database is maintained in the Primary
Import tables and is then moved to the archive database.
 BAM activity aggregations and OLAP cubes. The activity aggregations are maintained in
the form of online analytical processing (OLAP) cubes, which are dynamically generated,
along with the necessary Data Transformation Services (DTS) packages and a staging
database for non-real-time data.
 Real-Time Aggregations (RTA). These are special tables, created in the Primary Import
database, that have triggers that are used to maintain the aggregations synchronously
with the incoming events.
 BAM interceptors. The collection of data (message context properties and message data)
from orchestrations and pipelines is implemented as BAM interceptors. These
interceptors monitor the data as it is being processed and collect information that has
been identified as being a KPI. No programming is required to change the BAM tracking.
 Tracking Profile Editor (TPE). Developers use the TPE to define the mapping of
orchestration actions to business milestones and the mapping of XML schema nodes to
the business data items. Because no programming is required to collect or modify this
data, changes to tracking can be made easily at any time.
Lesson 2: Enabling Business Activity Monitoring
Lesson objective:
Explain the steps required to successfully implement Business Activity Monitoring.

Enabling Business Activity Monitoring (Analyst)
Describe the role of the business analyst in enabling Business Activity Monitoring.
Overview
The creation and implementation of BAM to monitor business processes usually involves
several different roles with different skill sets and tools.
Business Analyst Role

The role of the business analyst is to create BAM activity definitions (activities) and to create
the views that will be available to end users to view the business processes. Generally,
Business Analysts do not know, and do not need to know, what the actual orchestration that
defines the business process looks like. They know what information is important to track
and the order in which the process occurs.
Create Activity
Analysts use Microsoft Excel 2010 to create activities that identify in list form the key
performance indicators (KPIs) of the business processes, for example, receiving and
processing a purchase order (PO). These activities will include milestones (a date/time
measure for the receipt of a PO or the sending of an invoice) in addition to data points of
interest, such as the order date, PO number, total, and discounted total amounts. These
data points might be of interest for tracking and auditing purposes.
Enabling Business Activity Monitoring (Administrator)
Describe the role of the system administrator in enabling Business Activity Monitoring.
System Administrator Role

The role of the system administrator in enabling BAM is limited to deploying the workbook
or BAM activity definition file into the production environment by using the BAM
Management tool (BM.exe). When the definition is deployed, the BAM database
infrastructure is generated dynamically based on the activity defined in the workbook.
Example
In the following example, the SalesManagerView workbook is being deployed to create the
database structure based on the activity defined in the workbook.
BM deploy-all -DefinitionFile:SalesManagerView.xls
The BAM Management tool enables administrators to view, add, update and remove BAM
Management data.
Enabling Business Activity Monitoring (Developer)
Describe the role of the developer in enabling Business Activity Monitoring.
Tracking Profile Editor (TPE)

The Tracking Profile Editor (TPE) is a graphical user interface used by developers to create
and modify the tracking profiles that map a specific view of internal business processes and
associated data to a business process that might be represented by one or more
orchestrations.
When you use the TPE to create a tracking profile, you create or load a profile that will
define the relationship between:
1. One or more BizTalk assemblies that have been deployed to the BizTalk
Configuration database; each assembly may contain one or more orchestrations,
pipelines, schemas, and property schemas.
2. The activity, created by the business analyst, that has been deployed to the tracking
database by the use of the BAM Management command-line tool.
If you have multiple BAM activities deployed, you can use the TPE to create links of
continuations between the activities. Linking BAM activities brings together the business
analyst’s view of the process with the real-world implementation of that process as a group
of orchestrations.
The process of creating the mapping involves a drag-and-drop operation in which the
orchestration shape that maps to a particular KPI (a milestone, for example) is dragged from
the right pane to the corresponding KPI in the left pane. Similarly, messages (as represented
by send and receive shapes) can be examined for the data that is of interest (PO number or
order date, for example) and dropped onto the corresponding node in the left pane.
After you have identified all the points in the activity, you will apply the activity. The
collection of data begins immediately after the activity is applied. As long as the activity file
does not change, it is possible to modify how the data is collected and where it is collected
from. For example, if the business process changes and what used to be done in one
orchestration is now done in two, the profile can be updated and the data will now be
collected from the new shapes. This allows for mapping information over extended periods
of time into a single database to provide powerful aggregations.
What Is the BAM Portal?
Explain the purpose and use of the BAM Portal.
BAM Portal
The BAM Portal is a tool in BizTalk Server 2010 that is used to view data collected in the BAM
databases from a business process. When the model is deployed by using the BAM Manager,
the views included in the data collection model are rendered as views for the BAM Portal.
The BAM Portal is a Microsoft ASP.NET application (it does not rely on Windows SharePoint
Foundation). For companies that already have SharePoint sites, Web parts are available to
simplify integration of BAM data into those sites.
The BAM Portal gives you the ability to:
 Access pre-created views of the business data created by the business analyst and work
with PivotTables® in real time. In this way, users can customize the view to their own
preferences.
 Perform activity searches against BAM data to find specific BAM activity. For example,
the preceding slide shows sales manager data for the OrderMgmt application. Queries
can be saved and reused. They can also be the basis for an alert, such as notification
when a purchase order arrives from the specified customer.
 Drill down to see detailed information. This example shows the activity status for the
city of Los Angeles. The Activity Status view shows the dates on which several business
milestones were reached and tracking information (the Activity ID), in addition to the
other data. With this functionality, it is easy to start with aggregated data (all orders
processed) and see the details for orders that make up the totals.
 Configure and share alerts to notify specific users in the event that particular threshold
conditions are met—for example, if the number of unprocessed purchase orders
exceeds 100, send an e-mail message to the sales manager. Once created, alerts can be
subscribed to by other users who are interested in the same information.
 Escalate issues to the systems administrator. A link is provided to send feedback to a
preconfigured e-mail address notifying the recipient of problems that are identified by
portal users.
Demonstration: Monitoring Business Activity
Learn to implement an existing Business Activity Monitoring activity for a BizTalk Server solution.
Install the OrderMgmt Application

1. Start the bt10d-demos virtual machine.
2. In Windows Explorer, navigate to C:\AllFiles, and double-click startBtServices.cmd.
3. In Windows Explorer, navigate to C:\AllFiles\DemoCode\Module12, and double-
click BAMSetup.cmd.
Deploy the BAM View Created by the Business Analyst

2. In the Open box, type cmd, and then press ENTER.
3. In the command prompt window, type cd “\Program Files (x86)\Microsoft BizTalk
Server 2010\Tracking”, and then press ENTER.
then press ENTER.
bm deploy-all
-DefinitionFile:C:\AllFiles\DemoCode\Module12\OrderMgmt.xml
5. When the command completes, close the command prompt window.
Prepare for BAM Data Collection

click Tracking Profile Editor.
2. On the File menu, click Open, and then navigate to and open
C:\AllFiles\DemoCode\Module12\OrderMgmt.btt.
3. In the left pane of the Tracking Profile Editor, expand City, and then click the City
sub-node.
BAM intercepts individual pieces of information during the execution of the
BizTalk processes and writes this information to the Tracking database. The City
is retrieved from the original Purchase Order because it is initially received in the
orchestration.
4. In the left pane, expand approved, and then click FulfillmentDelay.
Notice that the approved milestone in the observation model is linked to the
Fulfillment Delay shape in the BizTalk orchestration.
5. On the Tools menu, click Apply Tracking Profile.
Although the observation model has been deployed, it is necessary to apply the
mappings between the logical model and the actual orchestration.
6. In the Tracking Profile Editor dialog box, click OK.
7. Close the Tracking Profile Editor.
Test BAM Functionality

1. In Windows Explorer, double-click
C:\AllFiles\DemoCode\Module12\Send20POs.bat.
2. In Microsoft Internet Explorer®, browse to http://localhost:8080/BAM.
3. In the My Views task pane, expand Aggregations, and then click Order Progress.
4. In the message box, read the warning, and then click OK.
5. Because SQL Analysis Services caches the BAM data that it receives from BizTalk, it
may take 1 to 2 minutes for the data to appear in the Pivot Table View. Click the red
exclamation point (!) to refresh the view
The Evaluation cells might not always be visible. The orders in Evaluation have
been received, but have not yet been approved or denied.
6. Notice the relationship between the data in the graph and the PivotTable.
7. In Windows Explorer, double-click
C:\AllFiles\DemoCode\Module12\Send20POs.bat.
8. Switch back to Internet Explorer and click the PivotTable toolbar button with the red
exclamation point (!) icon to refresh the data.
9. Expand the Received, Approved, and Evaluation cells to show the status of the
various completed processes.
The Evaluation cells might not always be visible. The orders in Evaluation have
been received but not yet approved or denied.
10. Notice that the counts have increased.
11. In the PivotTable, right-click the cell that contains the total count for Approved, and
then click Show Results.
12. Click any link in the City column.
13. In the My Views task pane, click OrderMgmt.
14. In the Query section, in the Business Data list, click City.
15. In the Value box, type LosAngeles.
16. In the Column Chooser section, select all the data and milestones, and then click
Add (>>).
17. Click Execute Query.
The details for each order in which the City was LosAngeles are displayed.
18. Double-click any row in the Results section, and then notice that the level of detail is
the same as was seen previously.
Lab: Monitoring Business Activity
Scenario
Business Activity Monitoring (BAM) is a tool designed to be used by business analysts for
gathering business data from both archived and running business processes. In this lab, you
will see how to use several new tools, including the Microsoft Excel Business Activity
Monitoring Add-In and the BAM Portal, for analyzing business data that was processed by
BizTalk Server.
Procedure List
window.
Start.

Procedure List
Exercise 1: Define a Business Activity
Overview
A business activity specifies the data from the business process that is captured by BAM.
This data may come from message content, message context, orchestrations, and other
sources. Once the business analyst has finished specifying the data to be gathered, the
business activity is exported to a BAM Definition File. In this exercise, you will use the
Business Activity Monitoring Add-In for Excel to specify the initial data to be collected as
each purchase order is processed by the system.
Define Milestones
Procedure List
1. On the Start menu, click All Programs, click Microsoft Office, and then click
Microsoft Excel 2010. In the Microsoft Office Activation Wizard window, click
Cancel.
2. On the File menu, click Options
3. In the Excel Options window, in the left pane, click Add-Ins.
4. In the right pane, at the bottom, in the Manage list, click Excel Add-ins, then click
Go.
5. In the Add-Ins dialog box, click Browse, and navigate to C:\Program Files
(x86)\Microsoft BizTalk Server 2010\ExcelDir, then click Bam.xla and click OK.
6. In the Add-Ins dialog box, in the Add-Ins available list, ensure that the Business
Activity Monitoring box is checked, and then click OK.
7. In the Excel menu ribbon, on the Add-Ins tab, click BAM, and then click BAM
Activity.
8. In the Business Activity Monitoring Activity Definition dialog box, click New Activity.
9. In the Activity name box, enter OrderMgmt.
10. Click New Item, and in the New Activity Item dialog box, in the Item name box,
enter received, in the Item type list, click Business Milestones then click OK.
This milestone allows a timestamp value to be gathered from the message after
the message is received by the business process.
11. Repeat step 9, substituting in the following values to create the remaining Activity
Items needed to monitor the OrderMgmt business process.
Item Name Item type
denied Business Milestones
approved Business Milestones
acknowledged Business Milestones
City Business Data - Text
State Business Data - Text
Product Business Data - Text
Amount Business Data - Decimal
Later in this lab, you will specify the points in the business process at which each
of these data values will be collected by the BAM infrastructure.
12. Click OK twice.
Exercise 2: Define an Observation Model
The BAM definition that you initialized in the preceding exercise specifies the information to
be collected by BAM. In this exercise, you will create a BAM view. You will design this view
by adding progress dimensions and measures that categorize the data gathered by the BAM
activity. The data in the view is displayed as a Microsoft Office Excel PivotTable.
Create the Order Progress Dimension

Procedure List
1. On the Welcome to the Business Activity Monitoring View Creation page, click
Next.
2. On the BAM View page, click Create a new view, and then click Next.
3. In the View name box, type SalesManager, select the Select all activities check box,
This view will contain data most likely needed by a sales manager for daily,
weekly, or monthly reports. A BAM view can be thought of as similar to a
Microsoft SQL Server view in which you see only the data you need to see.
4. On the New BAM View: View Items page, select the Select all items check box, and
then click Next.
5. On the New BAM View: View Items page, review the aliases listed.
6. Click New Duration.
When a message is received, it is in the evaluation stage. After evaluation, it is
either approved or denied. If approved, two serial processes occur so that an
instance is either in the fulfillment stage or the fulfillment has occurred and a
delivery notification has been received. The sales manager is interested in how
many messages are in each phase, and therefore, this view is created to
summarize this data.
7. In the Duration Name box, type CycleDuration.
8. In the Start business milestone list, click received (OrderMgmt).
9. In the End business milestone list, click acknowledged (OrderMgmt).
10. In the Time resolution list, click Minute, and then click OK.
11. On the New BAM View: View Items page, click Next.
12. On the New BAM View: Aggregation Dimensions and Measures page, click New
Dimension.
13. In the New Dimension dialog box, type OrderProgress as the Dimension Name, in
the Dimension Type list, click Progress Dimension, and then click New Milestone.
14. In the New Progress milestone dialog box, in the Progress milestone box, type
Received, in the Business milestone list, click received (OrderMgmt), and then click
OK.
15. In the New Dimension dialog box, in the Progress milestones and stages section,
click Received, and then click New Stage.
16. In the New Progress Stage dialog box, in the Progress Stage field, type Evaluation,
and then click OK.
17. Click Evaluation, and then click New Milestone.
18. In the New Progress Milestone dialog box, in the Progress milestone box, type
Approved, in the Business milestone list, click approved (OrderMgmt), and then
click OK.
19. Click Approved, and then click New Milestone.
Denied, in the Business milestone list, click denied (OrderMgmt), and then click OK.
click Approved, and then click New Stage.
22. In the New Progress Stage dialog box, in the Progress stage box, type Fulfillment,
and then click OK.
23. Click Fulfillment, and then click New Milestone.
DeliveredAck, in the Business milestone list, click acknowledged (OrderMgmt), and
then click OK.
click Denied, and then click New Stage.
26. In the New Progress Stage dialog box, in the Progress stage box, type Contacting,
and then click OK.
27. Click Contacting, and then click New Milestone.
DeniedAck, in the Business milestone list, click acknowledged (OrderMgmt), and
then click OK.
Screen shot of the completed New Dimension dialog
29. In the New Dimension dialog box, click OK.
Create the Count Measure

Procedure List
Measure.
In the following steps, you will configure the Count aggregation type, which will
count all order activities passing through the system.
2. In the New Measure dialog box, in the Measure name box, type Count.
3. Click Count in the Aggregation Type section, and then click OK.
This will automatically select the OrderMgmt activity as the base data item
because it will be a count of all order activities passing through the system.
Create the AvgCycleDuration Measure

Procedure List
Measure.
2. In the New Measure dialog box, in the Measure name box, type AvgCycleDuration.
3. In the Base data item list, click CycleDuration (OrderMgmt).
4. Click Average, and then click OK.
Create the MyTimeSlice Time Duration

Procedure List
Dimension.
2. In the New Dimension dialog box, in the Dimension name box, type MyTimeSlice, in
the Dimension type list, click Time Dimension, in the Base business milestone list,
click received (OrderMgmt), click Year, month, day, hour, minute, and then click
OK.
Configure the BAM View

Procedure List
1. On the New BAM View: Aggregation Dimensions and Measures page, click Next.
2. On the New BAM View: Summary page, click Next.
3. Click Finish.
An empty PivotTable will appear along with a pre-populated PivotTable field list.
4. From the PivotTable Field list box, drag the OrderProgress field onto the Drop Row
Fields Here box in the PivotTable.
5. Drag the Count measure from the PivotTable Field list box onto the Drop Value
Fields Here box.
6. Double-click the Received cell in the PivotTable to expand it.
You will see three values: Approved, Denied, and Evaluation.
7. Double-click the Approved cell.
You will see two values: DeliveredAck and Fulfillment.
8. Right-click the Approved cell, and then click Pivot Table Options.
9. In the PivotTable Options dialog box, in the Name box, type Order Progress, and
then click OK.
This is the name that will identify this particular aggregation in the BAM Portal
that will be used later.
10. On the Excel menu ribbon, click the Add-Ins tab, and in the Toolbar Commands
section, click the Real Time Aggregation (RTA) button.
11. In the Excel menu ribbon, click BAM, and then click Export XML.
12. In the Export BAM XML dialog box, type OrderMgmt_MyBAMDefinition.xml as the
file name, and then save the file to the desktop.
At this point, you can save the Excel workbook with any name you want to the
desktop before closing Excel.
Exercise 3: Deploy the BAM Observation Model
Overview
Once the business analyst has created the BAM activity and view, an IT professional will
deploy the BAM Observation Model to generate the structure of the BAM databases. In this
exercise, you will deploy the BAM Observation Model by using the BAM command-line tool.
Deploy the BAM Observation Model Created by the Business Analyst

Procedure List
3. In the command prompt window, type cd %BTSInstallPath%\tracking”, and
then press ENTER.
4. In the command prompt window, type bm.exe deploy-all -DefinitionFile:
“C:\AllFiles\LabFiles\Lab12\OrderMgmt_BAMDefinition.xml”, and then press
ENTER.
5. When the command is complete, close the command prompt window.
This task dynamically creates all of the BAM infrastructure needed based on the
observation model that was created in Exercises 1 and 2.
Exercise 4: Map a BAM Activity to the Implementation
Overview
After the BAM activity has been deployed by the IT professional, a developer will link the
BAM activity to the BizTalk implementation. In this exercise, you will use the Tracking Profile
Editor (TPE) to create a tracking profile that maps the BAM activity to a receive port and to
an orchestration. You will then apply the tracking profile.
Select the Target BAM Activity for Which to Create a Tracking Profile
Procedure List
2. In the left pane, click Click here to import a BAM Activity Definition.
3. In the Import BAM Activity Definition dialog box, in the bottom pane, click
OrderMgmt, verify that Retrieve the current tracking settings for this activity
definition check box is cleared, and then click OK.
Map the Received Milestone

Procedure List
1. In the Tracking Profile Editor, in the top-right corner, click Select Event Source, and
then click Select Messaging Property.
2. In the right pane, expand Schema and MessageProperties.
Here you are mapping the Received milestone defined by the business analyst to
an actual step in the business process.
3. Drag the PortEndTime node to the received node in the left pane.
4. In the left pane, right-click PortEndTime, and then click Set Port Mappings.
5. In the Select Ports dialog box, click OrderMgmt_RcvPO, click the > button to map
the port, and then click OK.
The port mapping part of this step is necessary because the same order might
pass through multiple receive ports. The port mapping specifies the port from
which the information will be collected.
Map the City Payload Item

Procedure List
1. Click Select Event Source, and then click Select Messaging Payload.
2. In the Select Event Source Parent Assembly dialog box, under Assembly name, click
TheImplementationOfOrderMgmt, and then click Next.
3. In the Select Schema dialog box, under Schema Name, click
OrderMgmt.PurchaseOrder, and then click OK.
4. In the right pane, expand Schema, PurchaseOrder, Header, and ShipTo.
Now you will map the City item to actual values from the physical
OrderMgmt_RcvPO port configured in the BizTalk Server Administration Console.
5. Drag the City schema item under ShipTo from the right pane to the City item in the
left pane.
6. Right-click City in the left pane (where you just dropped it), and then click Set Port
Mappings.
Map Additional BAM Milestones

In the following steps, you will add BAM milestones to the actual orchestration. You will be
able to query BAM for information about messages that were denied and acknowledged.
Every order will either be denied or acknowledged, but cannot be both.
Procedure List
1. Click Select Event Source, and then click Select Orchestration Schedule.
Multiple orchestrations could exist in the OrderMgmt assembly, so in these steps,
you must associate the correct orchestration with the business analyst’s BAM
views.
3. In the Select Orchestration dialog box, under Orchestration Name, click
OrderMgmt.OrderMgmtProcess, and then click OK.
1. Drag the FulfillmentDelay shape from the orchestration to the approved milestone
in the left pane.
2. Drag the RejectionDelay shape to the denied milestone in the left pane.
Any order received will reach only one of these milestones because they are
mutually exclusive outcomes of a presumed order evaluation—an order is either
approved or denied.
3. Drag the SendPOAck shape to the acknowledged milestone in the left pane.
Map the Remaining BAM Activity Items

In the following steps, you will associate specific fields from the PurchaseOrder schema to
fields in BAM.
Procedure List
1. Right-click the ReceivePO shape, and then click Message Payload Schema.
3. Expand Item and Summary.
4. Drag the State schema item (under ShipTo) to the State data item in the left pane.
5. Drag the Product schema item (under Item) to the Product data item in the left
pane.
6. Drag the Amount schema item (under Summary) onto the Amount data item in the
left pane.
Create a Continuation
A BAM continuation is analogous to a correlation set in an orchestration. Continuations are
sets of unique values that allow the BAM infrastructure to identify all messages that belong
to the same instance of a BAM activity. In this lab, you must define a continuation to
indicate that the messages accepted by the receive port belong to the same activity as those
that are processed by the orchestration.
Procedure List
1. In the left pane of the Tracking Profile Editor, right-click OrderMgmt, and then click
New Continuation.
2. Set the name of the new continuation to OrderMgmtContinuation.
3. In the Tracking Profile Editor, in the top-right corner, click Select Event Source, and
then click Select Messaging Property.
5. From the right pane, drag the InterchangeID node to the new
OrderMgmtContinuation node in the left pane.
6. In the left pane, right-click InterchangeID, and then click Set Port Mappings.
This step instructs the BAM infrastructure to initialize the continuation with the
value of the message’s interchange ID. The interchange ID is a GUID that
identifies this message and any of its descendants.
New ContinuationID.
9. Set the name of the new continuation ID to OrderMgmtContinuation.
The name of the continuation ID must match the name of the original
continuation.
13. Right-click the ReceivePO shape, and then click Message Property Schema.
14. In the right pane, expand MessageProperties, and then drag the InterchangeID
node to the new continuation ID node that you just created.
The ReceivePO shape will report the message’s interchange ID to the BAM
infrastructure, allowing BAM to associate this message with the correct BAM
activity.
Deploy the Tracking Profile

Once you have deployed the Tracking Profile to the BAM run-time environment, the BAM
infrastructure will start collecting data from messages that pass through the business
process.
Procedure List
1. On the File menu, click Save.
2. In the left pane, click Desktop, in the File name box enter OrderMgmt.btt, and then
click Save.
3. In the Tracking Profile Editor, on the Tools menu, click Apply Tracking Profile.
4. In the Tracking Profile Editor message box, click OK.
5. Close the Tracking Profile Editor window.
Exercise 5: Use the BAM Portal to Test the BAM Implementation
The BAM portal provides users with a Web interface to view the data collected by BAM. In
this exercise, you will submit messages, and then use the BAM portal to view the
information collected by BAM about the processing of each purchase order.
Generate Initial Inbound Flow of Purchase Orders

Procedure List
1. In the BizTalk Server Administration Console, start the OrderMgmt application.
2. In Windows Explorer, double-click the file
C:\AllFiles\LabFiles\Lab12\Messages\Send20POs.bat.
The batch file used here generates 20 test orders so that you will have some data
to analyze in this exercise.
Launch the BAM Portal and View Order Progress Data Aggregation
Procedure List
1. In Internet Explorer, navigate to http://localhost:8080/BAM.
2. In the My Views navigation pane, expand the Sales Manager view.
3. Click the plus sign (+) to expand the function named Aggregations, and then click
Order Progress.
4. In the Microsoft Office 2003 Web Components message box, click OK.
If you do not see any data in the Pivot Table View, click the button with the red
exclamation point (!) icon in the PivotTable tool bar to refresh the view. Because
of SQL Server / OLAP caching, it might take up to one minute for the data to
appear.
5. Click the plus signs (+) to expand cells in the PivotTable until Evaluation is shown
with a corresponding Total amount.
Generate Another Inbound Flow of Purchase Orders

Procedure List
6. Double-click the file C:\AllFiles\LabFiles\Lab12\ Messages\Send20POs.bat to create
and submit 20 new purchase orders.
Review the Detailed Status Information

Procedure List
1. Expand the Column Chooser section, select all remaining items in the Available Data
and Milestones pane, and then click the >> button to move them to the Items to
Show pane.
2. Collapse the Column Chooser section, and then click the Execute Query button at
the top right of the page to run the query again.
The user might want to modify the query itself. Specifically, if the number of
items presented by this Show Results action is too large, it might be necessary to
use some refinement criteria to limit the list to something workable. For
example, of the orders piling up in this processing stage, you might care only
about those that have been in that stage for more than a certain number of
hours. You can refine the query by expanding the Query section of this page and
modifying the set of query clauses.
Module 13: Using WCF Receive Adapters
Module objective:
In this module, you will learn how to configure BizTalk Server 2010 receive locations to receive
messages via the Windows Communication Foundation (WCF) receive adapters.
Introduction
Web services provide industry-standard mechanisms for conducting e-business by
communicating across disparate systems. Microsoft BizTalk Server 2010 includes a number
of receive adapters that support integration with web services by making use of the
Windows Communication Foundation (WCF).
WCF provides support for a wide array of the current web service standards. This support
enables developers to both consume a web service as part of a business process and to
publish a business process as a web service that can be consumed by external applications.
In this module, you will learn how to configure BizTalk receive locations that accept
messages via the BizTalk WCF receive adapters, and to publish BizTalk orchestrations and
schemas as WCF web services.
Lesson 1: Introduction to WCF Receive Adapters
Lesson objective:
Describe how the WCF Receive Adapters work in BizTalk Server 2010
Introduction
This lesson provides an overview of Windows Communication Foundation (WCF) and the
capabilities that it provides for interacting with web services. This lesson then focuses on
the Microsoft BizTalk Server 2010 WCF receive adapters, providing examples for usage, and
followed by a discussion of the architecture on which the WCF receive adapters are based.
Windows Communication Foundation (WCF)
Provide an overview of Windows Communication Foundation (WCF)
Introduction
Windows Communication Foundation (WCF) is a framework for building service-oriented
applications. WCF is included in the .NET Framework, and it provides a basis for writing code
to communicate across components, applications, and systems. A service is a piece of code
that clients interact with through messages. Services are passive -- they wait for incoming
messages to arrive before starting any work. A client requests a service to perform work by
sending a message to it.
Services expose one or more endpoints where messages can be sent. An endpoint consists
of an address, a binding, and a contract. The address specifies where to send messages. The
binding describes the transport details required. And the contract describes what the
messages contain. Clients need to know all of this information before they can access a
service.
Services typically offer descriptions of their capabilities and their requirements by using Web
Services Description Language (WSDL). Clients can use the service description to generate
code within their environment capable of sending and receiving the proper messages.
WCF 4.0 Web Service Standards Support
Explain the features and benefits of using Windows Communication Foundation (WCF).
Introduction
Windows Communication Foundation (WCF) supports a wide array of the web service
standards that have been defined since the SOAP specification was first published. WCF
enables you to develop secure, interoperable web services based on open industry-standard
specifications. In addition to supporting the fundamental standards, such as XML, SOAP and
WSDL, WCF includes support for standards covering end-to-end message level security,
content-based routing, and web service policies.
WS-* Specification Support in WCF

Following the publication of the SOAP specification, the W3C and a number of industry
organizations have continued to pursue the goal of achieving broad-based interoperability
between IT systems. As a result, the W3C, OASIS.org, WS-I.org, and ad-hoc industry groups
have published a series of specifications, known as “WS-*”, that build on the fundamental
standards of web services. WCF 4.0 offers built-in support the following web service
standards:
WS-Addressing allows a secured message to be sent over any transport and to also be easily
routed.
WS-AtomicTransaction defines an interoperable transaction protocol. It enables you to flow
distributed transactions by using web service messages, and coordinate transactions
between heterogeneous infrastructures.
WS-Coordination defines a framework that enables existing transaction processing,
workflow, and other systems for coordination to hide their proprietary protocols and to
operate in a heterogeneous environment.
WS-MetadataExchange defines how metadata associated with a web service endpoint can
be represented and how metadata can be retrieved from a Web service endpoint.
WS-Policy defines an XML syntax that can be used to define policy assertions, which describe
constraints and requirements of a web service beyond those listed in a WSDL document.
WS-ReliableMessaging defines a transport-independent protocol that allows messages to be
delivered reliably between distributed applications.
WS-Security describes how to secure Web services at the message level instead of at the
protocol level or the wire level.
WS-SecureConversation defines extensions that build on WS-Security for establishing and
sharing security contexts required for secure communication.
WS-SecurityPolicy describes the policy assertions for use with WS-Policy that apply to WS-
Security, WS-Trust, and WS-SecureConversation.
WS-Trust defines extensions that build on WS-Security to request and issue security tokens
and to manage trust relationships.
WS-I Profiles
The Web Service Interoperability Organization (WS-I) has published guidelines, sample
applications and testing tools to help developers implement web service standards to
achieve the best possible levels of interoperability.
A WS-I Profile consists of a set of guidelines, sample applications and testing tools that
address a fixed set of web service specifications.
WCF 4.0 provides built-in support for the following WS-I profiles.
 WS-I Basic Profile, Datatypes – XML Schema 1.0 base and complex data types
 WS-I Basic Profile 1.1 – SOAP 1.1, WSDL 1.1
 WS-I Basic Profile 1.2 – SOAP 1.1, WS-Addressing 1.0
 WS-I Basic Profile 2.0 – SOAP 1.2, WS-Addressing 1.0, MTOM
 WS-I Basic Secure Profile 1.1 – WS-Security 1.1
There are asome dditional profiles under development in WS-I working groups that WCF 4.0
does not yet support, including:
Reliable message exchange – WS-ReliableMessaging 1.1
Reliable, secure message exchange – WS-ReliableMessaging 1.1, WS-SecureConversation 1.3
WCF Receive Adapter Scenarios
Describe some common scenarios for using a WCF receive adapter.
Introduction
With the WCF adapters built-in to Microsoft BizTalk Server 2010, developers can expose
WCF Web Services to external systems and benefit from the rich integration support offered
by WCF. Developers can make use of the WCF native support for the major web service
specifications, rather than resort to writing custom code.
Some common integration scenarios in which a developer might want to publish a WCF web
service include:
 To enable a BizTalk application to receive messages from an external trading

partner’s supply chain system over the internet, making use of digital signatures to
ensure that the message has not been tampered with.
 To enable a BizTalk application receive messages from an ERP system, such as SAP,
Oracle eBusiness Suite, or Siebel eBusiness Applications.
 To enable a BizTalk application receive messages from a SQL Server or Oracle
database, with full support for transactions across disparate systems.
Scenario for Publishing a BizTalk WCF Service
Describe a scenario for publishing a BizTalk orchestration as a WCF service.
Introduction
If your organization requires a specific business process to be accessible via the Web to
trading partners, customers, or other applications, you can publish an orchestration or a
message schema as a web service. You can do this by running the BizTalk WCF Service
Publishing Wizard.
When publishing an orchestration as a web service, each public receive port is presented as
a .svc file, which is handled by the Windows Communication Foundation (WCF) framework
on a computer running Internet Information Services (IIS) Manager. The web service is
called using the SOAP protocol. The data is sent to and from the web service as XML.
WCF Receive Adapter Architecture
Explain the architecture of a WCF receive adapter
Introduction
The BizTalk WCF receive adapters create WCF endpoints to listen for messages. When a
message arrives at the endpoint, the WCF adapter receives the message and publishes it to
the MessageBox.
BizTalk Server 2010 provides a number of different WCF adapters to meet the requirements
of various messaging and transport protocols. The WCF adapters share a common
architecture and base implementation. Each WCF adapter, however, requires a different set
of configuration data as dictated by its transport, encoding and WS-* protocol support.
When a WCF receive adapter starts running, it creates a BizTalk Service Host, which
dynamically builds the WCF runtime components that are required to accept and process
messages. When a message arrives, the WCF receive adapter passes it through a series of
WCF channel components. A channel consists of one transport component, one message
encoder, and zero or more protocol components.
The transport component is responsible for reading in the raw bytes of the message. The
encoder component is responsible for converting the raw bytes in to a WCF message. The
protocol components are responsible for processing any WS-* protocols that are configured
on the adapter.
When the WCF channel components have completed processing, and if they have not
rejected the message for security reasons, the message will be passed to the receive
location’s pipeline. At this point, the pipeline will process the message in the same manner
as it would if the message were received by any other of the built-in BizTalk adapters.
Lesson 2: Configuring a WCF Receive Adapter
Lesson objective:
Learn how to configure a WCF receive adapter
Introduction
To create a receive location that presents a WCF service to external systems, you must
determine which WCF adapter best meets the application requirements, and then configure
the WCF adapter and BizTalk pipeline in the BizTalk Administration Console.
Steps for Configuring a WCF Receive Adapter
Identify the steps required to consume a Web service from an orchestration.
Introduction
To configure a WCF receive adapter, you must:
1. Select a WCF receive adapter that best meets the receive location’s message
transport, encoding and WS-* protocol requirements -- each of the WCF adapters is
preconfigured with a set of WCF channel components.
2. Specify an endpoint address at which the WCF service will be hosted.
3. Set the configuration properties for the WCF adapter. Any of the preconfigured
WCF adapters will display a set of properties, reflecting the properties of the
channel components that it contains.
Types of WCF Adapters
Describe the types of BizTalk WCF adapters, and explain how each one can be used
Introduction
With the wide range of possibilities presented by the BizTalk WCF adapter architecture and
the WCF framework, it could become a rather time consuming task to determine which
features are required for a given receive location, and to build a corresponding WCF binding
each time.
For ease of configuration, BizTalk Server 2010 provides a collection of WCF adapters that are
preconfigured with WCF bindings:
The WCF-WSHttp adapter provides the WS-* standards support over the HTTP transport.
The WCF-WSHttp adapter implements WS-Transaction for the transactional interactions
between external applications and the MessageBox database, and WS-Security for message
security and authentication. The transport is HTTP or HTTPS, and message encoding is a Text
or Message Transmission Optimization Mechanism (MTOM) encoding.
The WCF-BasicHttp adapter communicates with ASMX-based Web services and clients and
other services that conform to the WS-I Basic Profile 1.1. The transport is HTTP or HTTPS,
and message encoding is a text encoding.
The WCF-NetTcp adapter provides the WS-* standards support over the TCP transport. The
WCF-NetTcp adapter provides efficient communication in a WCF-to-WCF environment. The
adapter implements WS-Transaction for the transactional interactions between external
applications and the MessageBox database, and WS-Security for message security and
authentication. The transport is TCP, and message encoding is binary encoding.
The WCF-NetMsmq adapter provides support for queuing by leveraging Microsoft Message
Queuing (MSMQ) as a transport and enables support for loosely coupled applications, failure
isolation, load leveling, and disconnected operations.
The WCF-NetNamedPipe adapter provides secure optimization for on-machine cross-
process communication. The WCF-NetNamedPipe adapter uses transport security for
transfer security, named pipes for message delivery, and binary message encoding.
Custom WCF Adapters

In order to retain the flexibility offered by WCF, BizTalk Server 2010 provides two generic
WCF adapters that can be configured to meet requirements that differ from the previously
listed WCF adapters.
The WCF-Custom adapter enables the use of WCF extensibility features. It contains no
preconfigured channel components. The adapter allows you to select and configure a WCF
binding and the behavior information for the receive location and send port.
The WCF-CustomIsolated adapter enables the use of WCF extensibility features over the
HTTP transport. It contains no preconfigured channel components. The adapter allows you
to select and configure a WCF binding and the behavior information for the receive location
running in an isolated host.
WCF Adapter Hosting

Any WCF receive adapter that communicates over the HTTP protocol is hosted in an Internet
Information Services (IIS) application pool. A WCF receive adapter that communicates over a
protocol other than HTTP is hosted in a BizTalk service process.
Selecting Message Content
Learn how to select the message content that the adapter will publish to the MessageBox.
Introduction
The WCF receive adapters offer the option to configure how much of the content of an
inbound SOAP message should be published to the message box. As was the case with the
SOAP adapter, the default behavior of a WCF receive adapter is to publish only the message
body, and to discard the SOAP envelope.
By configuring a WCF receive adapter to publish the entire SOAP message, including the
envelope and headers, it is possible for other components within BizTalk to receive the
message with any encryption and digital signatures intact. When selecting this option, you
must configure the receive location with a pipeline that does not include the XML
disassemble component pipeline, otherwise the SOAP body will automatically be extracted
during pipeline processing, and published to the message box.
If your application requires only a subset of the SOAP message body, you can choose the
Path option and provide an XPath statement to select a specific node to be published to the
message box. This is particularly useful when external systems send large messages, and the
receiving application requires only a small subset of the data.
Specifying the Format of a Selected Node
Learn how to specify the format of a content node that has been selected with XPath.
Introduction
When the Path option is selected, the WCF receive adapter requires a second configuration
property that specifies the type of encoding of the selected node.
It will decode the XML node as specified by the configured encoding type, and publish the
resulting decoded message data to the MessageBox.
Configuring Two-way Receive Ports
Learn how to specify the format of an outbound response message.
Introduction
In a two way receive location, the WCF receive adapters provide two options for populating
the body of the SOAP response message. The WCF receive adapters default to the Body
option, which instructs the adapter to insert the body of the BizTalk message into the SOAP
body, which is the same behavior as the original SOAP receive adapter.
The WCF receive adapters also offer a Template option, which provides the ability to wrap
the body of the outbound BizTalk message in custom XML, and then insert the customized
XML in to the outbound SOAP body.
When you choose the Template option, you must provide an XML template that includes a
bts-msg-body element. The location of the bts-msg-body element indicates the position at
which the BizTalk message body should be inserted.
Demonstration: Creating a net.tcp Receive Location
Learn to configure a receive location with the WCF-NetTcp adapter
Set Up the Demos.Northwind Application

1. In Windows Explorer, navigate to the C:\AllFiles\DemoCode\Module13 folder, and
double-click Setup.cmd.
2. Verify that the set-up completed successfully, and then close the window.
Configure the WCF-NetTcp Adapter

1. In the BizTalk Administration Console, expand BizTalk Server Administration,
BizTalk Group, Applications and Demos.Northwind.
2. Create a new One-way Receive Location, and in the Select a Receive Port dialog box,
click Northwind_ReceiveOrders, and then click OK.
3. In the Name box, enter Northwind_ReceiveOrders_TCP.
4. In the Type list, select WCF-NetTcp, and then click Configure.
5. In the WCF-NetTcp Transport Properties dialog box, on the General tab, in the
Address box, enter net.tcp://localhost/OrderService.
6. Click on the Binding tab.
The configuration settings shown on this page apply specifically to the WCF-
NetTcp binding. Each type of WCF adapter displays a different set of
configuration options.
7. Click on the Security tab, and then click on the Security mode list.
If the Transport option is chosen, the WCF-NetTcp adapter expects security
credentials to be passed at the TCP connection level. If the Message option is
chosen, the WCF-NetTcp adapter expects to find security credentials embedded
within the message.
8. In the Security mode list, ensure that Transport is selected, and then click the
Messages tab.
9. Check the Suspend request message on failure box, and check the Include
exception detail in faults box.
These options are useful when diagnosing errors, but since they require
additional information to be stored in the MessageBox for each message, so they
should not be left enabled any longer than necessary.
10. Click OK twice.
11. Right-click the Demos.Northwind application, and click Start twice.
Submit a Message with WCF

1. Open the C:\AllFiles\DemoFiles\Module13\SubmitOrder\SubmitOrder.sln, and
double-click on the Program.cs file.
This is a console application that uses a user-specified WCF binding to submit a
message to a service. It reads the message body from a file that is provided by
the user, then creates a WCF proxy object, and calls the service.
This application does not require a WCF service reference, because it uses a
generic contract that allows it to submit any type of message to a service.
2. In Windows Explorer, navigate to C:\AllFiles\DemoFiles\Module13, and double-click
OrderExternal.xml
This is the document that will be sent as the body of the SOAP message to the
new WCF net.tcp receive location.
3. Close the Internet Explorer window.
4. To submit the message, double-click SubmitOrder_WCF-NetTcp.cmd
The submitOrder.cmd file calls the submitOrder.exe console application to send
OrderExternal.xml using the WCF-NetTcp binding.
5. When the submitOrder application states that the message has been sent, then in
Windows Explorer, navigate to C:\AllFiles\DemoCode\Northwind\Ports\Audit, and
verify that a new message has been created.
Lesson 3: Using the WCF Service Publishing Wizard
Lesson objective:
Use the WCF Service Publishing Wizard to publish orchestrations and schemas as web services.
Introduction
You can publish a BizTalk orchestration or schema as a WCF web service. BizTalk WCF web
service consists of a .svc file, a web.config file, and metadata files. To publish your Web
service, you can use the BizTalk Web Services Publishing Wizard.
Steps for Publishing a WCF Service
Identify the steps required to publish an orchestration as a Web service.
Introduction
When you publish an orchestration as a WCF Web service, you expose the orchestration’s
receive ports as web services. This enables external business processes to access the
orchestration from any type of service-enabled client.
To publish an orchestration, you must:
1. Compile the BizTalk Server project that contains the orchestration, and install the
assembly in the GAC. Any orchestrations that are to be published as web services
must contain at least one public logical port for receiving messages into the business
process.
2. Create and configure both the receive port and the receive location in the BizTalk
Administration Console.
3. Create the WCF service and configuration files by running the Web Services
Publishing Wizard. By default, it will store all the files that are created by the wizard
in the C:\InetPub\WWWRoot directory. You will want to check the permissions on
this folder to ensure that this project is secure.
4. Associate the web service with the desired application pool. When a web service is
published, it is associated with the default application pool, which generally does
not have access to the BizTalk MessageBox.
Prerequisites
The server to which you will be publishing your WCF web services must have both Internet
Information Services (IIS) and the .NET 4.0 framework installed.
Configuring an Orchestration for Publishing
Configure receive ports in an orchestration to be published.
Configure receive ports

Before you can publish an orchestration as a Web service, you must ensure that you have at
least one logical receive port configured as a public port. Normally, logical ports are created
with the internal scope. However, any orchestrations that are published as a web service
must have a way to accept data from outside the project, and this is why at least one public
receive logical port is necessary. If there are no public logical receive ports in your
orchestration, the wizard will not find a port to expose as a web service, and you will not be
able to publish your orchestration.
Running the WCF Service Publishing Wizard
Lesson objective:
Use the WCF Service Publishing Wizard to publish an orchestration as a web service.
WCF Service Publishing Wizard

The WCF Services Publishing Wizard can be used to create a WCF service that exposes public
receive ports from one or more orchestrations as SOAP-callable web services. The wizard
examines the orchestration assembly, and creates a WCF service that defines the message
types, locations, protocols, and data type definitions that are to be exposed to external
systems.
The WCF Services Publishing wizard allows you to either create individual WCF web services
for each orchestration port, or to define a single WCF web service with multiple service
operations, encompassing all of the ports of the orchestration. In the former case, the
wizard creates one WCF .svc file for each port.
In the latter case, the wizard creates one WCF .svc file per orchestration. Each operation in
the orchestration’s logical ports will become a WCF service operation, and it will have the
same name as the logical port operation. Consequently, you will need to ensure that the
logical port operations are assigned meaningful names in the Orchestration Designer.
Demonstration: Publishing a WCF Service
Learn to publish an orchestration with the BizTalk WCF Service Publishing Wizard
Configure an Orchestration for Publication

2. In Windows Explorer, navigate C:\AllFiles\DemoCode\Module13\NorthWind, and
then open NorthWind.sln.
3. In the Orchestrations project, open the RouteOrder.odx orchestration.
This is the orchestration that will be published as a WCF service. In the previous
demo, all order messages were simply routed to the audit department. In this
demo, the RouteOrder orchestration will route messages to the billing and
shipping departments also.
4. In Orchestration View, expand Types and Port Types, and right-click
OrderReceivePortType, and then click Properties Window.
Notice that the Type Modifier for this port type is Internal. The WCF Service
Publishing Wizard, however, will detect only Public port types.
5. In the Type Modifier list, click Public.
6. In Solution Explorer, right-click the Northwind solution, and then click Deploy
Solution.
Run the WCF Service Publishing Wizard

click BizTalk WCF Service Publishing Wizard.
While the BizTalk Web Services Publishing Wizard is still available, it is not
intended to be used for new application development. For this demo, be sure
that you select the BizTalk WCF Service Publishing Wizard.
2. On the Welcome to the BizTalk WCF Service Publishing Wizard page, click Next.
3. On the WCF Service Type page, from the Adapter name (Transport type) list, select
WCF-BasicHttp.
4. Check the Enable metadata endpoint box, and check the Create BizTalk receive
locations in the following application box.
5. From the BizTalk application name list, select Demos.Northwind, and then click
Next.
6. On the Create WCF Service page, click Publish BizTalk orchestrations as WCF
service, and click Next.
7. Browse to
C:\AllFiles\DemoCode\Module13\Northwind\Orchestrations\bin\Debug, click
Demos.Northwind.Orchestrations.dll, then click Open, and then click Next.
Notice that the OrderReceivePort is selected to be published as part of a web
service that is named after the orchestration.
8. On the Orchestrations and Ports page, click Next.
9. On the WCF Service Properties page, in the Target namespace of WCF service box,
replace the text with http://northwind.com/orders, and then click Next.
10. On the WCF Service Location page, in the Location box, replace the text with
http://localhost:8080/NorthwindOrders, check the Allow anonymous access to
WCF service box, and then click Next.
11. On the WCF Service Summary page, review the information and then click Create.
12. Wait for the code generation process to complete, and then click Finish.
Review the Generated Code

13. In Windows Explorer, navigate to C:\inetpub\wwwroot\NorthwindOrders to open
the folder containing the generated WCF service files.
This folder contains the generated WCF service files. Notice that the service has
an App_Data folder, but it does not have an App_Code folder.
14. Open the App_Data folder.
This folder contains the XML schema definitions that the code generator
extracted from the orchestration.
15. In Windows Explorer, navigate back to the C:\inetpub\wwwroot\NorthwindOrders
folder, right-click on the generated .svc file, point to Open with, and then click
Notice that this service is configured to handle calls using a built-in class named
Microsoft.BizTalk.Adapter.Wcf.Runtime.BasicHttpWebServiceHostFactory. An
instance of this class reads the schema information from the App_Data folder,
and dynamically creates a web service to accept messages that match the given
schemas, and publish the messages to the MessageBox.
Configure and Start the BizTalk Application
1. Start the BizTalk Server Administration Console, expand the Demos.Northwind
application, and then click on Receive Ports.
2. Double-click on the receive port having a name that begins with
WcfReceivePort_NorthwindOrders.
3. In the left panel, click Receive Locations, and double-click on the single receive location
that is listed.
This receive location and its containing receive port were generated by the WCF
Service Publishing Wizard. Notice that the receive location has been configured with
the WCF-BasicHttp binding, and that it is configured with the URL of the generated
WCF service.
4. Click Cancel, and then click Inbound Maps.
5. In the Inbound maps list, select ExternalToInternal, and then click OK.
6. Right-click on the Demos.Northwind application, and then click Configure.
7. Click on the RouteOrder orchestration, and configure the bindings as shown in the
following table:
Property Value
OrderReceivePort WcfReceivePort_..._OrderReceivePort
OrderBillingSendPort Northwind_SendToBilling
OrderAuditSendPort Northwind_SendToAudit
ShippingUSASendPort Northwind_SendToShippingUSA
ShippingInternationalSendPort Northwind_SendToShippingForeign
8. Click OK to close the Configure Application window.

9. Right-click on the Demos.Northwind application, then click Start twice.
At this point, the Demos.Northwind application is running, but the WCF service is not
yet properly configured in IIS to accept messages.
Configure the Generated WCF Service in IIS

1. Start Internet Information Services (IIS) Manager, and expand BIZTALKDEMO, Sites and
Default Web Site.
2. Right-click NorthwindOrders, point to Manage Application, and then click Advanced
Settings.
3. In the Advanced Settings dialog box, click Application Pool, and then click the ellipses
(…).
4. In the Application Pools list, click BTSWSPool, and then click OK twice.
The BTSWSPool application pool has is configured with the BizTalkIsoHost identity,
which has been granted permissions to publish to the MessageBox.
5. Right-click NorthwindOrders, and then click Switch to Content View.
6. Right-click the Demos_Northwind_..._OrderReceivePort.svc file, and then click Browse.
7. Verify that the service documentation page is displayed in Internet Explorer.
8. Click on the link at the top of the page to view the WSDL document.
This WSDL document was generated from the schema files stored in the service’s
App_Data folder.

1. In Windows Explorer, navigate to C:\AllFiles\DemoCode\Module13.
2. To submit the message, double-click submitOrder_WCF-BasicHttp.cmd
The submitOrder.cmd file calls the submitOrder.exe console application to send
OrderExternal.xml using the WCF-BasicHttp binding.
3. When the submitOrder application states that the message has been sent, then in
Windows Explorer, navigate to C:\AllFiles\DemoCode\Northwind\Ports\BillingDept,
and verify that a new message has been created.
Publishing Schemas as WCF Services
Learn to expose an XML schema as a Web service.
Publish a schema
The BizTalk WCF Services Publishing Wizard can also be used to create web services that are
based solely on existing schemas. This option offers greater flexibility, since it allows a schema
to be published as a web service whether or not it is not used in an orchestration. You can
define the web services, service operations, and request-and-response message types by
specifying the schemas that you want published.
Using the wizard, you define the target namespace, specify the names of the services and
service operations, and set the location of the generated web service files. Publishing schemas
as web services allows third-party vendors or trading partners to see how to format messages
before sending them to your organization for further processing.
Lab: Receiving Messages with a WCF Adapter
Overview
This lab will introduce you to the integration between the BizTalk Server messaging components
and Web services. You will use a built-in WCF adapter, which provides integration with Web
services using Windows Communication Foundation.
First, you will generate a Web service from an existing schema definition using the BizTalk WCF
Service Publishing Wizard. Then you will learn how to properly configure a receive port and the
virtual directory containing the generated service endpoint.
Procedure List
window.
4. Click on the Action menu in the Virtual Machine Connection window and choose Start.
7. At the Windows Activation prompt, click “Ask Me Later”, then click “OK”

Procedure List
Exercise 1: Publish a Schema as a Web Service
Overview
In the first part of this lab, you will publish the OrderExternal.xsd schema as a service, which will
make it easier for service-enabled consumers to integrate with the application. Your task now is
to configure a new receive location that accepts messages with the WCF-BasicHttp adapter. You
can accomplish this by generating a WCF service endpoint from OrderExternal.xsd. The rest of
the messaging implementation (e.g., the various send ports) will continue to work the same
way.
Examine the Northwind External Order XML Schema

Procedure List
1. In Windows Explorer, navigate to C:\AllFiles\LabFiles\Lab13\NorthWind, and then
open NorthWind.sln.
This is a new solution that contains three projects – the Maps, Orchestrations and
Schemas projects.
2. In the Schemas project, open the OrderExternal.xsd schema.
This is the schema that will be published as a WCF service.
Start the WCF Service Publishing Wizard

Procedure List
WCF-BasicHttp.
5. From the BizTalk application name list, select Northwind , and then click Next.
6. On the Create WCF Service page, click Publish schemas as WCF service, and click Next.
Specify the Service Details

In this step you will describe the service details, specifically the service contract details, such as
the service name, operation names, message exchange patterns, and what schema types each
request/response message maps to.
Procedure List
1. On the WCF Service page, in the Web service description pane, right-click
BizTalkWcfService, choose Rename web service description, and enter
OrderProcessingServiceDescription.
2. Right-click Service1, click Rename web service, and enter OrderProcessingService.
3. Right-click Operation1, click Delete web method, and then click Yes.
The WCF Publishing Wizard provides a request/response operation by default, but
the OrderProcessing service requires a one-way web method.
4. Right-click OrderProcessingService, point to Add web method and click One-way.
5. Right-click Operation1, click Rename web method, and then enter SubmitOrder.
6. Right-click on Request, and choose Select schema type.
7. In the Request Message Type dialog box, click Browse and navigate to
C:\AllFiles\LabFiles\Lab13\Northwind \Schemas\bin\Debug, click Northwind
.Schemas.dll, and then click Open.
8. In the Available schema types list, click Northwind .Schemas.OrderExternal, then click
OK, and then click Next.
enter http://services.northwind.com/orders, and then click Next.
10. On the WCF Service Location page, in the Location box, enter
http://localhost:8080/OrderProcessingService.
11. Check the Allow anonymous access to WCF service box, and then click Next.
12. On the WCF Service Summary page, review the summary text, click Create, and then
wait for the code-generation process to complete.
13. On the Completing the BizTalk WCF Service Publishing Wizard page, click on the link to
open the folder containing the generated code.
You now have a WCF service that is capable of receiving OrderExternal messages.
The service will submit any messages that it receives to the MessageBox.
14. In Windows Explorer, double-click OrderProcessingService.svc to view the generated
code.
Notice that the file contains only a ServiceHost directive using a custom factory for
BizTalk Services. This factory uses the metadata in the BizTalk management
database and the XML files found in the App_Data directory to generate a runtime
service and respond to metadata requests.
Configure the WCF Service in IIS

Before you can begin using this service to integrate with BizTalk, you must first configure the
directory to run in an IIS Application Pool running under an identity that is a member of the
BizTalk Isolated Host Users group.
Procedure List
1. On the Start menu, click Administrative Tools, and then click Internet Information
Services (IIS) Manager.
2. In the Internet Information Services (IIS) Manager window, in the left pane, expand the
BIZTALKDEMO node, and then click Application Pools.
3. Right-click the Application Pools node, and then click Add Application Pool.
4. In the Add Application Pool dialog box, in the Name box, enter NorthwindWebServices.
5. In the .NET Framework version list, select .NET Framework v4.0.30319, and then click
OK.
6. In the center pane, right-click NorthwindWebServices, and then click Advanced
Settings.
7. In the Advanced Settings dialog box, click Identity, and then click the ellipses (…)
button.
8. Click Custom Account, and then click the Set button.
9. In the User name box, enter BizTalkIsoHost.
10. In the Password and Confirm password boxes, enter pass@word1, and then click OK
three times.
11. Right-click NorthwindWebServices and then click Recycle.
Sites and the Default Web Site nodes.
13. Right-click OrderProcessingService, point to Manage Application, and then click
Advanced Settings.
14. Click Application Pool, and then click on the ellipses (…) button.
15. From the Application pool list, select NorthwindWebServices, and then click OK twice.
At this point, the WCF service is configured to run in an application pool having an
identity that is allowed publish messages to the MessageBox.
Configure the Generated Receive Port

Procedure List
2. Expand BizTalk Server Administration, BizTalk Group, Applications and Northwind .
3. In the BizTalk Server Administration Console window, under the Northwind
application, click Receive Ports.
4. Double-click the WcfReceivePort_OrderProcessingService/OrderProcessingService
receive port.
5. In the Receive Port Properties dialog box, in the left pane, click Inbound Maps, and then
in the Inbound maps list, in the Maps column, select ExternalToInternal.
6. In the left pane, click Receive Locations, then in the right pane, double-click the
WcfService_ OrderProcessingService /OrderProcessingService receive location.
7. In the Receive Location Properties dialog box, verify that the Type is WCF-BasicHttp,
and the Receive handler is BizTalkServerIsolatedHost, and then click Configure.
Notice that the Address (URI) is simply the path to the generated .svc file.
8. Click the Messages tab.
9. Check the Suspend request message on failure box, and the Include exception detail in
faults box.
These settings are especially useful in development environments. In production you
would most likely not want to return exception details in your faults as it provides
more detailed information than you want the client to have. The option to suspend
messages generally comes down to dealing with denial of service (DOS) attacks or
problematic clients that send many faulty messages. Leaving this option unselected
enables you to ignore those messages.
12. Right-click the WcfService_ OrderProcessingService /OrderProcessingService receive
location and click Enable.
13. Verify that the status changes to Enabled.
Test the WCF Service Deployment

You now have an enabled receive location capable of receiving incoming SOAP requests. Before
proceeding, you will test the service to make sure it is configured correctly.
Procedure List
1. On the Start menu, click Run, and enter
http://localhost:8080/OrderProcessingService/OrderProcessingService.svc, and then
click OK.
2. Verify that the BizTalkServiceInstance page is displayed in Internet Explorer.
3. Click on the link near the top of the page to display the WSDL file for the web service.
Exercise 2: Consume and Test the Web Service
Overview
In this exercise, you will use a simple client application to submit orders to the web service
created in Exercise 1.
Update the Web Service Client Application

Procedure List
1. In Windows Explorer, navigate to C:\AllFiles\LabFiles\Lab13\OrderSubmissionApp, and
then open OrderSubmissionApp.sln.
2. In Solution Explorer, expand the Service References folder.
3. Right-click the Orders service reference, and then click Configure Service Reference.
4. Ensure that the value in the Address box is
http://localhost:8080/OrderProcessingService/OrderProcessingService.svc, and click
OK.
Visual Studio will update the service reference by downloading the latest WSDL from
the web service URL.
5. Right-click the OrderSubmissionApp solution, and then click Build Solution.
6. Verify that there were no compilation errors.
Submit Orders to the Web Service with the Client Application

Procedure List
1. Press CTRL + F5 to run the solution without debugging.
2. Enter some sample data as shown below, and then click Submit.
3. Verify that a dialog box appears confirming that the order was submitted successfully.
If you get an error, try running the application in debug mode with a breakpoint on
the catch block to get more detail on the error. Make sure your receive location is
enabled and the host instance are running.
4. In Windows Explorer, navigate to C:\AllFiles\LabFiles\Ports\BillingDept and verify that
a new message has been created.
Module 14: Using WCF Send Adapters
Module objective:
In this module, you will learn how to configure BizTalk Server 2010 send ports to send messages
and call web services using the Windows Communication Foundation (WCF) send adapters.
Introduction
Microsoft BizTalk Server 2010 includes a collection of send adapters that support integration
with web services by making use of the Windows Communication Foundation (WCF).
You can use the BizTalk WCF Service Consuming Wizard to import the metadata for a web
service and generate the schema and binding files that are required to integrate with it.
Lesson 1: Introduction to WCF Send Adapters
Lesson objective:
Describe how the WCF send adapters can be applied to BizTalk Server 2010 applications
Introduction
This lesson then focuses on the Microsoft BizTalk Server 2010 WCF send adapters. It
provides examples for usage, and it includes a discussion of the architecture on which the
WCF send adapters are based.
WCF Send Adapter Scenarios
Describe some common scenarios for using the WCF send adapters.
Overview
With the WCF send adapters built-in to Microsoft BizTalk Server 2010, developers can
consume web services that are exposed by external systems, and they can benefit from the
rich integration support offered by WCF.
Some common integration scenarios in which a developer might want to consume a WCF
web service include:
1. To enable a BizTalk application to send invoice messages to an external trading
partner’s supply chain system over the internet, making use of WS-Security features
such as encryption and digital signatures to ensure that the message has not been
compromised while en-route.
2. To enable a BizTalk application to query a warehouse database, such as Oracle 11g,
to check the availability of stock to meet the requirements of a new purchase order.
3. To enable a BizTalk application to update to an internal SQL Server 2008 database,
and to make a web service call to a vendor server, with full support for ACID
transactions across the disparate systems.
WCF Send Adapter Architecture
Explain the architecture of a WCF send adapter
Overview
A BizTalk WCF send adapter receives messages from the BizTalk MessageBox, communicates
with a service endpoint, and publishes any service response messages back in to the
MessageBox.
BizTalk Server 2010 provides a number of different send WCF adapters to meet the
requirements of various messaging and transport protocols. The WCF send adapter
architecture is somewhat simpler than the receive adapter architecture because it acts as a
WCF client, and therefore it doesn’t have to deal with the issues that arise from WCF
hosting. Each WCF send adapter requires a set of configuration data as dictated by its
transport, encoding and WS-* protocol support.
When a WCF send adapter is activated, it prepares the BizTalk message to be processed by a
WCF channel. A WCF send adapter does not check the format of a message that it is
transmitting. Consequently, you need to ensure that the application’s send ports are
configured with the pipelines and maps that produce the message format required by the
destination service. In lieu of schema type information, the send adapter requires you to
specify the service “action” value that that should accompany the message as it is sent via
the transport.
An important consideration is that the WCF send adapter is only compatible with request-
reply operations even when used on one-way send ports. WCF service operations can return
void but they shouldn’t be marked with IsOneWay=true if you want to call them from a WCF
send port. The only exception is when you’re using NetMsmqBinding, in which case the
service operations must be one-way. This is a common for developers to stumble on when
they first start using the WCF send adapters, but the constraint is by design in order to
support transactional consistency within the message box.
Finally, send ports can be configured to route incoming fault messages (returned by the
service) through traditional message box subscription techniques. This functionality,
however, is disabled by default.
Lesson 2: Consuming a Web Service
Lesson objective:
Learn how to configure a WCF send adapter to call a web service.
Introduction
Consuming WCF services enables you to add existing web services to your business process.
You can aggregate several web services into a single orchestration.
You can begin to configure your application to make a web service call by using the BizTalk
WCF Service Consuming Wizard. The BizTalk WCF Service Consuming Wizard creates the
schema and binding files that are required to call a given web service.
Steps for Consuming a Web Service
Identify the steps required to consume a Web service from an orchestration.
Overview
BizTalk Server 2010 provides tools that simplify the procedure to implement web service
calls in a BizTalk application. You can get started by performing the following four steps:
1. Add Generated Item. In your Microsoft Visual Studio BizTalk project, in Solution
Explorer, right-click your project, click Add, and then click Add Generated Items. In
the Add Generated Items - <Project name> dialog box, in the Templates section,
select Consume WCF Service, and then click Add.
2. Complete the BizTalk WCF Service Consuming Wizard. The BizTalk WCF Service
Consuming Wizard walks you through the process of importing the service’s
metadata, and then it creates the schema and binding files that are required to call
the web service. It also generates an orchestration containing type definitions for
the web service messages and orchestration ports.
3. Build and deploy the project. In most cases, this step will be necessary, since your
application will probably need to map a message to the web service call format. In
the rare cases that this mapping is not necessary, you can skip this step.
4. Import generated binding file. The WCF Service Consuming Wizard creates two
binding files: <ServiceName>.BindingInfo.xml and
<ServiceName>_Custom.BindingInfo.xml. The first file contains the settings required
to configure a send port with the standard binding WCF adapters—for example, the
WCF-NetMsmq and WCF-WSHttp adapters. The second binding file contains the
settings required to configure a send port with the WCF-Custom adapter.
The BizTalk WCF Service Consuming Wizard
Describe the process of completing the BizTalk WCF Service Consuming Wizard
Overview
The BizTalk WCF Service Consuming Wizard simplifies the process of importing web service
metadata and creating the corresponding BizTalk artifacts. You can launch and complete the
BizTalk WCF Service Consuming Wizard by completing the following steps:
1. Add Generated Item. In your Microsoft Visual Studio BizTalk project, in Solution
Explorer, right-click your project, click Add, and then click Add Generated Items. In
the Add Generated Items - <Project name> dialog box, in the Templates section,
select Consume WCF Service, and then click Add.
2. Complete the BizTalk WCF Service Consuming Wizard.
a. On the Welcome to the BizTalk WCF Service Consuming Wizard page, click
Next.
b. On the Metadata source page, select the source of the metadata to import,
i. To download metadata documents from the metadata exchange
endpoint of a running service, select the Metadata Exchange (MEX)
endpoint option. This allows you to create a send port that acts as a
client to the WCF service. To use this option, the service endpoint
must publish service metadata for retrieval using an HTTP/GET or
HTTPS/GET request. The service endpoint must also allow access to
the metadata with anonymous user credentials or user credentials
in the form of a user name and password with the basic
authentication scheme.
ii. For any other metadata documents to import, select the Metadata
Files (WSDL and XSD) option to import metadata from a file system.
c. If you selected the Metadata Exchange (MEX) endpoint option on the
Metadata source page, the Metadata Endpoint page appears. On the
Metadata Endpoint page, specify the URL to the running service that
provides metadata for download through WS-Metadata Exchange or Http-
Get. To get the metadata document from the URL, click Get. If the running
service requires a user credential with the basic authentication scheme, click
Edit to open the BizTalk WCF Service Consuming Wizard dialog box in which
you can supply user name and password to use when accessing running the
service.
d. If you selected the Metadata Files (WSDL and XSD) option on the Metadata
source page, the Metadata Endpoint page appears. On the Metadata
Endpoint page, specify metadata files to import. Click Add to add the
metadata files to import to the Metadata Files view. This opens the Add
metadata files dialog box in which you can search disk locations for
metadata files.
i. In the Add metadata files dialog box, select a complete set of WSDL
and XSD files to use for metadata.
e. On the Import WCF Service Metadata Summary page, review your settings.
You can click Back to make any changes. Then click Import to create the
BizTalk artifacts and types to be used for consuming the WCF service.
f. On the Completing the BizTalk WCF Service Consuming Wizard page, click
Finish. If you want to run this wizard again, select the Run this wizard again
option, and then click Finish.
Demonstration: Consuming a Web Service
Learn to run the BizTalk WCF Service Consuming Wizard
Set up the Demo Application

1. In Windows Explorer, navigate to C:\AllFiles\DemoCode\Module14\, and double-
click Setup.cmd.
2. Verify that the installation completed successfully, and close the command window.
Run the WCF Service Consuming Wizard

1. In Windows Explorer, navigate to C:\AllFiles\DemoCode\Module14\Northwind,
and double-click Northwind.sln.
2. Right-click the Schemas project, then click Add, and then click Add Generated Items.
3. In the Add Generated Items dialog box, click Consume WCF Service, and then click
Add.
4. On the Welcome page of the BizTalk WCF Service Consuming Wizard, click Next.
5. On the Metadata Source page, click Metadata Exchange (MEX) endpoint, then click
Next.
6. On the Metadata Endpoint page, in the Metadata Address (URL) box, enter
http://localhost:8080/FederalShipping/ShippingCharges.svc, and then click Get.
7. Wait for the ShippingCharges Service documentation page to appear, and then click
Next.
8. On the Import WCF Service Metadata Summary page, click Import, and then click
Finish.
9. Notice that the wizard has added five files to the Schemas project: two schema files,
one orchestration, and two binding files.
One of the binding files contains the settings for a send port that is configured to
call the web service with the WCF-BasicHttp adapter. The other binding file
holds configuration settings for a send port configured with the WCF-Custom
adapter. You can import either one.
10. Open the file named ShippingCharges_federal_shipping_com_shipping.xsd.
This schema defines the format of the request message that will be sent to the
web service, and the response message that the web service will return. The
other schema file defines types that are used for XML serialization.
11. Cut and Paste the ShippingCharges.odx file from the Schemas project to the
Orchestrations project.
This file contains the message and port type definitions that can be used to call
the web service from an orchestration.
12. Right-click the Northwind solution, and then click Build Solution.
Create a New Map

1. Right-click the Maps project, point to Add, then click New Item.
2. In the Add New Item dialog box, click Map, then in the Name box, enter
OrderInternalToGetShippingPriceQuote.btm, and then click Add.
3. Click Open Source Schema, and in the BizTalk Type Picker dialog box, expand Maps,
Reference, Schemas and Schemas, then click
Demos.Northwind.Schemas.OrderInternal.
4. Click Open Destination Schema, and in the BizTalk Type Picker dialog box, expand
Maps, Reference, Schemas and Schemas, then click
Demos.Northwind.Schemas.ShippingCharges_federal_shipping_com_shipping,
then click GetShippingPriceQuote, and then click OK.
5. Expand the source and destination schemas, then drag a String Concatenate
functoid from the toolbox to the map grid.
6. Drag a link from the source schema’s CustomerID node to the new functoid, then
drag a link from the source schema’s OrderDate node to the functoid.
7. Drag a link from the functoid to the destination schema’s orderID node.
8. Drag a link from the Country node beneath the source schema’s ShipTo node, and
connect it to the destination schema’s shipToCountry node.
9. Drag a link from the source schema’s OrderTotal node to the destination schema’s
orderAmount node, then close the map.
Deploy the Schemas and Maps

1. Right-click the Maps project, and then click Deploy.
2. In the BizTalk Adminstration Console, expand the Demos.Northwind application,
click Receive Ports, then double-click Northwind_ReceiveOrders_TwoWay.
3. Click Inbound Maps, and in the Map list, click ExternalToInternal.
Import the Generated WCF Send Port Binding
1. In the BizTalk Administration Console, click Send Ports, and notice that the
application does not have any send ports configured.
2. Right-click the Demos.Northwind application, point to Import, then click Bindings,
and then navigate to C:\AllFiles\DemoCode\Module14\Northwind\Shemas and
double-click ShippingCharges.BindingInfo.xml.
The Demos.Northwind application now has a send port that is configured with
the WCF-BasicHttp adapter.
3. Double-click the new send port, then click Configure.
Notice that the adapter is configured with the Endpoint Address taken from the
WSDL document, and that the SOAP Action header mappings are defined.
4. Click Cancel, and then click Outbound Maps.
5. In the Map list, click OrderInternalToGetShippingPriceQuote.
6. Click Filters and in the Property list, select BTS.ReceivePortName.
7. Ensure that the Operator is ==, and in the Value field, enter
Northwind_ReceiveOrders_TwoWay.
8. Click OK.
Test the Web Service Call

1. Right-click the Demos.Northwind application, and click Start twice.
2. In Windows Explorer, navigate to C:\AllFiles\DemoCode\Module14 and double-click
submitOrderGetResponse.cmd.
3. Wait for the call to complete, and verify that the response is a shipping price quote.
BizTalk accepted the order message through the
Northwind_ReceiveOrders_TwoWay receive port, then made the call to the
shipping web service, and returned the response to the receive port.
Lesson 3: Consuming Services from Orchestrations
Lesson objective:
Learn how to set up a web service call in the Orchestration designer.
Introduction
Orchestrations offer the ability to provide error handling and transaction compensation
while they coordinate calls to web services. This lesson will show you how to use the type
definitions created by the BizTalk WCF Service Consuming Wizard to make a web service call
from an orchestration.
Steps for Consuming a Service from an Orchestration
Describe the steps required to implement a web service call in an orchestration.
Overview
After completing the BizTalk WCF Service Consuming Wizard, you will find that an
orchestration and two schema files have been added to your BizTalk project.
The orchestration will be named after the service, following the naming convention of
<ServiceName>Type.odx. There are no shapes in this orchestration. It simply contains a port
type definition, and one or more multipart message type definitions. The recommended
approach for using the type definitions is to avoid modifying the generated orchestration,
and then simply reference the type definitions from other orchestrations in the BizTalk
project.
One schema file will be named after the service following the naming convention of
<ServiceName>Type_biztalk_WCF_<AdapterBindingType>.xsd. This schema defines the
format of the web service request and response messages.
The other schema file will be named following the naming convention of
<ServiceName>Type_schemas_microsoft_com_2003_10_Serialization.xsd. This schema is
exported by DataContractSerializer for the types, elements, and attributes from the
namespace, http://schemas.microsoft.com/2003/10/Serialization/.
Implementing the web service call in the orchestration takes four steps:
1. Create a new configured port in the orchestration. You can use the Orchestration
Designer’s port wizard to create a send port of the wizard-generated port type.
2. Define message variables using new message types. Create one message variable
for the web service request and, if the service will be returning a response, create a
message variable for the response as well. Assign the corresponding generated
multipart message type(s) to the new message variable(s).
3. Construct the web service request message. Use either a Transform shape, or a
Message Assignment shape to construct the web service request message.
4. Connect send and receive shapes to the new port. Drag and drop connections
between the send and receive shapes, and their corresponding operations on the
send port.
Mapping Operations to Actions
Specifying the SOAP Action header
Overview
When you import the generated binding file, it populates the WCF.Action property in the
action mapping format. To see how this property is configured, look at the Action text box
on the General tab in the WCF send port transport properties dialog box in the BizTalk
Administration console.
You can specify the WCF.Action property in two different ways: (1) the single action format
and (2) the action mapping format.
If you set this property in the single action format, for example,
http://contoso.com/Svc/Op1, then the SOAPAction header for outgoing messages is always
set to the value specified in this property.
If you set this property in the action mapping format, the outgoing SOAPAction header is
determined by the outbound message’s BTS.Operation context property. For example, if this
property is set to the XML format shown below, and the BTS.Operation property is set to
Op1, the WCF send adapter uses http://contoso.com/Svc/Op1 for the outgoing SOAPAction
header.
<BtsActionMapping>
<Operation Name="Op1" Action="http://contoso.com/Svc/Op1" />
<Operation Name="Op2" Action="http://contoso.com/Svc/Op2" />
</BtsActionMapping>
Orchestrations set the BTS.Operation property with the operation name of the orchestration
send port. The ports generated by the BizTalk WCF Consuming Wizard have operations with
names that match the Name attributes in the <BtsActionMapping> element, so you do not
have to explicitly set the BTS.Operation property in orchestrations when you send messages
through ports that were generated by the wizard.
Formatting the Request Message
Understand how to specify the format of the body of the outbound SOAP message.
Overview
The WCF send adapters offer two options for constructing the SOAP message from the
outbound BizTalk message. You can choose to use the body of the BizTalk message as the
body of the <soap:Envelope> or you can provide an explicit XML template that specifies
what should go in the <soap:Body>.
Within the custom XML template, you use <bts-msg-body> to indicate where the BizTalk
message body should go. The <bts-msg-body> element also has an “encoding” attribute that
you can use to specify how the BizTalk message body should be encoded in the <soap:Body>
element: “xml”, “base64”, “hex”, or “string”.
The following template will wrap the outbound BizTalk message within an <Invoice>
element:
<Invoice xmlns="http://northwind.com/billing">
<bts-msg-body xmlns="http://www.microsoft.com/schemas/bts2007"
encoding="xml"/>
</Invoice>
Selecting Content from the Response Message
Understand how to specify the content to be extracted from the body of the SOAP response message.
Overview
The WCF send adapters offer the option to configure how much of the content of a response
message should be published to the MessageBox. The send adapter is responsible for
creating the BizTalk message (multi-part) consisting of a message context and a single body
part. You can choose which node from the incoming SOAP envelope to use in the BizTalk
message body.
You can choose to use the entire SOAP envelope, the body of the SOAP envelope, or a
particular element within the SOAP envelope identified by an XPath expression. The default
setting is “Body”, which means the first child of the <soap:Body> element will be used in the
BizTalk message body.
When you select “Envelope”, the entire <soap:Envelope> will be used within the BizTalk
message body, which means the SOAP headers will be found within the BizTalk message
body for future processing. However, if you are using the XmlDisassembler in your receive
pipeline, it will actually strip everything from the SOAP message except for the first child of
the <soap:Body> (similar to the “Body” option), thereby negating the “Envelope” behavior if
that was the selected option. This behavior stems from the fact that the SOAP schema is
registered with BizTalk Server as an “envelope” schema. Hence, you will want to ensure
you’re using the PassThruReceive pipeline when selecting the Envelope option above.
The final option is to specify a node within the <soap:Body> to use within the BizTalk
message body. You provide an XPath expression (in the “Body path expression” text box) to
specify exactly which node to use. The expression is evaluated relative to the <soap:Body>
element, which means an expression of “*” (short for “child:*”) identifies the children of
<soap:Body>. If the expression selects more than one node, only the first selected node will
be used. Also, another important point is that you can’t use XML namespace prefixes in the
XPath expression. Instead, you’ll need to use full XPath expressions that test the local name
and namespace values manually as illustrated in this example:
*/*[local-name()="invoice"]/*[local-name()="CustomerName"]
This XPath expression identifies the <CustomerName> element within <invoice>. Since
BizTalk Server uses an optimized forward-only XPath reader to process these XPath
expressions, you must ensure that your expressions only use forward axes (e.g., child,
descendant, etc). You must avoid any axis that requires reverse navigation (e.g., preceding,
preceding-sibling, ancestor, etc).
The node encoding controls how the node is processed after it has been selected. The
available options include Xml, Base64, Hex, and String. The default is “Xml”, which means
the XML representation of the selected node will be used in the message body. When the
selected node doesn’t contain XML but rather some form of text, you specify what encoding
should be used to extract the text. You can specify “String” if the node contains UTF-8
encoded text, or “Base64” or “Hex” if the node contains either form of encoded binary data.
If the matched node doesn’t have data encoded as specified in the node encoding, an empty
BizTalk message body is created by default. This general functionality is handy when you
only want to publish the binary data found in a particular element to the message box.
Demo: Consuming Services from Orchestrations
Learn to configure a web service call from an orchestration
Create a Port for the Web Service Call

1. Resume the bt10d-demo virtual machine.
2. In Visual Studio, open the RouteOrder.odx orchestration.
3. Right-click on the right port surface, click New Configured Port, and then click Next.
4. In the Name box, enter ShippingChargesPort, then click Next.
5. On the Select a Port Type page, click Use an existing Port Type, and in the Available
Port Types tree, click Demos.Northwind.Schemas.ShippingCharges, then click Next.
6. On the Port Binding page, select I’ll be sending a request and receiving a response,
then click Next, and then click Finish.
Create the Web Service Message Variables

1. In Orchestration view, right-click Messages, then click New Message, and in the
Properties window, in the Identifier box, enter ShippingQuoteRequest.
2. In the Message Type list, expand Multi-part Message Types, and then click
Demos.Northwind.Schemas.ShippingCharges_GetShippingPriceQuote_InputMessa
ge.
3. Right-click Messages, then click New Message, and in the Properties window, in the
Identifier box, enter ShippingQuoteResponse.
4. In the Message Type list, expand Multi-part Message Types, and then click
Demos.Northwind.Schemas.ShippingCharges_GetShippingPriceQuote_OutputMes
sage.
Construct and Send the Web Service Request Message

1. In the “Get Shipping Quote” Group shape, add a Transform shape, followed by a
Send shape, and then add a Receive shape immediately beneath the Send shape.
2. Click the Construct Message shape that automatically encloses the Transform shape,
and in the Properties window, in the Messages Constructed list, click
ShippingQuoteRequest.
3. Double-click the Transform shape, and click Existing Map.
4. In the Fully Qualified Map Name list, click <Select from referenced assembly …>,
and then click OrderInternalToGetShippingPriceQuote, and click OK.
5. Click Source, and in the Variable Name list, click OrderMessage.
6. Click Destination, and in the Variable Name list, click
ShippingQuoteRequest.parameters, then click OK.
7. Click the new Send shape, and in the Properties window, in the Message list, click
ShippingQuoteRequest.
8. Click the new Receive shape, and in the Properties window, in the Message list, click
ShippingQuoteResponse.
9. Connect the new send and receive shapes to the ShippingChargesPort.
Process the Response Message

1. In Solution Explorer, open ShippingCharges_federal_shipping_com_shipping.xsd.
2. Right-click <Schema>, click Promote, then click Show Promotions.
3. In the Promote Properties dialog box, expand the GetShippingQuoteResponse node,
click the Price node, then click Add, and then click OK.
5. In RouteOrder.odx, inside the Construct Billing Message shape, immediately after
the Order to Billing Transform shape, add a Message Assignment shape.
6. Double-click the new Message Assignment shape and enter the following line of
code, and click OK.
BillingMessage.OrderTotal = BillingMessage.OrderTotal +
ShippingQuoteResponse.parameters.GetShippingPriceQuoteResult.Price;
Deploy and Test the Orchestration

1. In Solution Explorer, right-click the Northwind solution, then click Rebuild Solution,
and then click Deploy Solution.
2. In the BizTalk Administration Console, right-click the Demos.Northwind application,
and then click Refresh.
3. Click Send Ports, and then double-click the generated WCF send port.
4. Click Outbound Maps, and then click Remove.
5. Click Filters, then click Delete, and then click OK.
These maps and filters a no longer necessary, since these functions will now be
handled by the orchestration.
6. Right-click the Demos.Northwind application, point to Import and then click
Bindings.
7. Navigate to C:\AllFiles\DemoCode\Module14\Northwind, and double-click
Demos.Northwind.Bindings.2.xml.
8. Right-click the Demos.Northwind application, and click Configure.
9. Click the RouteOrder orchestration, and in the Host list, click
BizTalkServerApplication.
10. Configure the RouteOrder ports by binding the logical ports to the physical ports
with the following mappings:
Logical Port Physical Port
OrderReceivePort Northwind_ReceiveOrders_OneWay
ShippingChargesPort WcfSendPort_ShippingCharges_..._ShippingCharges
ShippingUSASendPort Northwind_SendToShippingUSA
ShippingInternationalSendPort Northwind_SendToShippingForeign
11. Click the ShippingChargesClient orchestration, and in the Host list, click
BizTalkServerApplication, then click OK.
12. Right-click the Demos.Northwind application, and then click Start twice.
13. Drop a copy of the OrderExternal.xml message from
C:\AllFiles\DemoCode\Module14\ in to the
C:\AllFiles\DemoCode\Northwind\Ports\FileIN folder.
14. Open the order message that appears in the
C:\AllFiles\DemoCode\Northwind\Ports\Audit folder, and take note of the
OrderTotal value.
15. Open the billing message that appears in the
C:\AllFiles\DemoCode\Northwind\Ports\BillingDept folder, and verify that shipping
charges have been included in the OrderTotal value.
Lesson 4: WCF Send Adapter Security
Lesson objective:
Understand how to configure WCF send adapter security settings.
Introduction
WCF provides numerous security options that differ across the various bindings, and you can
take things even further via custom bindings. The purpose of this section is not to cover the
details of the various WCF security features, but rather to show how the adapters surface
those configuration settings.
Configuring WCF Send Adapter Security
Understand how to configure transport-specific WCF send adapters.
Overview
WCF provides numerous security options that differ across the various bindings, and you can
take things even further via custom bindings. Since the set of security options vary across
the different WCF bindings, each WCF adapter only provides configuration options that are
consistent with the underlying binding.
Each of the WCF adapter configuration dialog boxes provides a “Security” tab, which
surfaces the security options available for that particular adapter. The main setting you
choose is the WCF security mode, either “None”, “Message”, “Transport”, or
“TransportWithMessageCredential”. Not all WCF adapters support all the different security
modes. For example, the WCF-NetNamedPipe adapter only supports “Transport” or “None”.
Also, the WCF-NetMsmq adapter supports “Transport”, “Message”, or “Both”, which is a full
combination of transport + message security.
When you select message or transport, you must specify the type of client credential to use.
For message security the options include “None”, “Windows”, “Username”, and
“Certificate”. When you choose anything but “Windows”, you must provide a service
certificate allowing clients to authenticate the service. For transport security the client
credential options include “None”, “Basic”, “Digest”, “Ntlm”, “Windows”, and “Certificate”.
With message security, you can also specify the algorithm suite to use for message
encryption and key wrapping. And you can control whether the service credential is
negotiated (as with Kerberos) or provisioned at the client (as with certificates) and whether
a secure session should be established. These settings control whether WS-Trust and WS-
SecureConversation are used within the channel stack.
Most of the WCF receive adapters support SSO – simply select “Use Single Sign-On” to
request an SSO ticket using the client credentials – check the documentation for details on
which configurations do support SSO and which do not. When specifying “User name
credentials” in the send port adapter configuration, you can indicate you want to use SSO for
the outbound credentials.
Configuring WCF-Custom Send Adapter Security
Expose an XML schema as a Web service.
Overview
If you are configuring a WCF-Custom adapter, you have a wider array of options for security
configuration. If you are passing simple credentials, such as name and password, then you
can use the Credentials tab to specify the credential values.
Otherwise, you will need to open the Behavior tab to configure the WCF behaviors that
support the security features required by your application. You will need to ensure that the
BizTalk Host user account has the privileges that might be required by the WCF behavior,
such as privileges to access a certificate store.
Lab: Calling a Web Service from an Orchestration
Overview
The purpose of this lab is to introduce you to the integration between the BizTalk Server
messaging components and Web services. You’ll use a built-in WCF adapter, which provides
integration with Web services using Windows Communication Foundation.
First, you will add a service reference to generate the necessary artifacts for consuming a
web service using the WCF adapters. Next you’ll walk through the process of consuming a
web service from within an orchestration.
Procedure List
window.
Start.

Procedure List
Exercise 1: Setup a Web Service Call in the Orchestration Designer
Overview
In the first part of this lab, you will modify an orchestration to call a web service that returns the
credit rating for a given customer. You will set up a two-way send port in the orchestration to
the customer ID to the web service, and receive the response.
Review the CustomerService Web Service

Procedure List
1. In Internet Explorer, browse to http://localhost:8080/Northwind/CustomerCredit.svc
2. Verify that the CustomerCredit Service documentation page appears.
3. Click on the link at the top of the page to view the WSDL document. Notice that the
service has a single operation named GetCustomerRating.
The GetCustomerRating operation is designed to check the credit status for a
particular customer. The orchestration will use the returned information to make a
decision about whether to approve the order.
Add a Service Reference to the Orchestrations Project

Procedure List
1. In Windows Explorer, navigate to C:\AllFiles\LabFiles\Lab14\Northwind, and then open
Northwind.sln.
2. Double-click RouteOrder.odx in the Orchestrations project.
3. In Solution Explorer, right-click on the Orchestrations project, click Add, and then click
4. In the dialog that appears, select Consume WCF Service and click Add.
5. In the Consume WCF Service wizard, click Next until you can enter the URL for the
service.
6. In the URL box, enter http://localhost:8080/Northwind/CustomerCredit.svc
7. Click Get to retrieve the service description.
8. Click Next, and then click Import.
This downloads the service's WSDL definition and generates the corresponding
orchestration type definitions in the CustomerCredit.odx file
Add the Web Service Messages to the Orchestration

Procedure List
1. Make sure RouteOrder.odx is still visible in the Orchestration Designer, click on the
Orchestration View tab, and then expand the Types node.
You should see CustomerCredit in the list of port types. This port type models the
request/response message pair needed to invoke the service. Notice that it contains
a single operation named GetCustomerRating
2. Expand the Multi-part Message Types node.
Notice it contains two new message types, one for the GetCustomerRating request
message and another for the corresponding response
3. Right-click on the Messages folder (in Orchestration View), and select New Message.
4. In the Properties window, in the Identifier box, enter GetCustomerRatingRequest.
5. In the Message Type list, expand the Multi-part Message Types node and then click
Northwind.Orchestrations.CustomerService_GetCustomerRating_InputMessage
7. In the Properties window, in the Identifier box, enter GetCustomerRatingResponse.
OrderProcessing.Orchestrations.CustomerService_GetCustomerRating_OutputMessage
Add the Web Service Send Port to the Orchestration

Procedure List
1. Right-click on the right-side port surface.
2. Click New Configured Port, and in the Port Configuration Wizard, click Next.
3. On the Port Properties page, in the Name box, enter CheckCustomerCredit, and click
Next.
Port Types tree, click Northwind.Orchestrations.CustomerCredit.
5. Select I'll be sending a request and receiving a response for the direction of
communication and click Next.
6. Click Finish.
You should now see a Port on the port surface that models the interaction with
CustomerCredit.svc. Notice that the port type provided all of the operations from the
service, driven by the metadata you consumed with the wizard.
Add Orchestration Shapes to Call the Web Service

Procedure List
1. Place a Group shape just under the initial Receive shape.
2. In the Properties window, in the Name box, type Call CheckCustomerCredit.
3. Place a Construct Message shape within the Group shape.
4. In the Properties window, in the Name box, type Construct
GetCustomerRatingRequest.
5. In the Messages Constructed list, click GetCustomerRatingRequest.
6. Place a Message Transform shape within the Construct Message shape, and name it
CopyCustomerID.
7. Double-click on the CopyCustomerID shape to open the map configuration.
8. Rename the map to
Northwind.Orchestrations.MapOrderToGetCustomerRatingRequest.
9. Configure the Source message to be the OrderMessage.
10. Configure the Destination message to be GetCustomerRatingRequest.parameters.
11. Click OK, and when the map opens, drag a link from the source CustomerID node to the
destination CustomerID node, and close the map.
12. Place a Send shape within the Group under the Construct Message shape.
13. Name the new Send shape SendGetCustomerRatingRequest.
14. Set its Message to GetCustomerRatingRequest.
15. Place a Receive shape within the Group, under the Send shape.
16. Name the Receive shape ReceiveGetCustomerRatingResponse.
You're going to use the Send/Receive shapes to invoke the service by sending the
required messages to the Port
17. Drag a connection from the Send shape to the port’s Request connector.
18. Drag a connection from the Receive shape to the port’s Response connector.
19. Your orchestration should look like the following screenshot:
Promote Distinguished Fields in the Web Service Response Schema
After calling the Web service, the orchestration can inspect the information in the response
message to determine whether to approve the order for this particular customer.
Procedure List
1. In Solution Explorer, double-click on
CustomerCredit_northwind_com_fbts_customers.xsd.
2. Right-click on GetCustomerRatingResponse, and click Promote, then click Show
Promotions.
3. In Promote Properties dialog box, in the left pane, expand GetCustomerRatingResponse
and GetCustomerRatingResult.
4. Click Rating, and then click Add.
5. Click CreditLimit, and then click Add.
6. Press OK to accept the promotions, and on the File menu, click Save All.
Now the orchestration will have access to these fields (via the
GetCustomerRatingResponse message).
Add Shapes to Handle the Credit Decision

Procedure List
1. In Solution Explorer, double-click RouteOrder.odx.
2. Place a Decide shape just under the new Group and in the Properties window, in the
Name box, enter If customer has sufficient credit.
3. Rename Rule_1 to Rule_CheckCustomerCredit.
4. Double-click on Rule_CheckCustomerCredit to open the BizTalk Expression Editor. Then
enter the following expression:
GetCustomerRatingResponse.parameters.GetCustomerRatingResult.Rating > 2.5
5. Click OK to accept the expression.

When this expression evaluates to true, the left branch of the decision is followed.
Otherwise the right branch is followed.
6. Drag all of the remaining shapes in the orchestration into the left branch.
Normal processing will only occur when the customer has sufficient credit.
When the customer doesn't have sufficient credit, we need to send the
OrderMessage to a "Rejected" queue for human processing (we'll just use a folder on
the file system).
Add a Port to Handle Rejected Orders

Procedure List
1. Right-click on the right-side port surface and select New Configured Port.
3. On the Port Properties page, in the Name box, enter RejectedPort.
4. Click Create a new Port Type and in the Port Type Name box, enter PortType_Rejected,
then click Next.
5. Choose I'll always be sending messages on this port and leave Specify later for the
binding, then click Next.
6. Press Finish to create the new port.
7. Place a Send shape within the decision shape's Else branch.
8. In the Send shape’s Properties window, in the Name box, enter SendRejectedOrder.
9. In the Message list, click OrderMessage.
10. Connect the Send shape to the RejectedPort Request connector.
11. At this point, your orchestration should look like this screenshot:
Procedure List
1. In Solution Explorer, right-click on the Northwind solution and click Build Solution.
2. Verify that the build completes successfully.
3. Right-click on the Northwind solution and click Deploy Solution.
4. Verify that the deployment succeeds.
Exercise 2: Configure the Orchestration and Send Ports
Overview
In this exercise, you will configure the Northwind application using the BizTalk Administration
console. The first binding file that you will import does not include the bindings for the new
WCF ports. The second binding file that you import will configure the WCF send port required
for the web service call. Finally, you will bind the orchestration to its ports to complete the
configuration.

Procedure List
1. Open the BizTalk Administration Console and navigate to the Northwind application.
2. Right-click the Northwind application, point to Import, and click Bindings.
3. Navigate to C:\AllFiles\LabFiles\Lab14\Northwind, click Northwind.Bindings.xml, and
then click Open.
4. Validate that five send ports and one receive location are created.
Import the Configuration for the WCF Send Port

Procedure List
1. In the BizTalk Administration Console, right-click the Northwind application, point to
Import, and click Bindings.
2. Navigate to C:\AllFiles\LabFiles\Lab14\Northwind\Orchestrations, click
CustomerCredit.BindingInfo.xml, and then click Open.
This binding file contains information that was gathered when you added a service
reference. It can be used to configure the send port so that it properly
communicates with the listening service.
Configure the Orchestration Bindings

Procedure List
1. Within the Northwind application, select the Orchestrations folder.
2. Double-click on Northwind.RouteOrder, and select the Bindings tab.
3. Bind the logical CheckCustomerCreditPort to the physical
WcfSendPort_CustomerCredit_BasicHttpBinding_CustomerCredit port that was
created by the import.
4. Bind the logical RejectedPort to the physical Northwind_SendToRejected port.
All of the other ports should already be bound to their physical counter parts.
5. Click OK to accept the bindings.
6. Double-click the Northwind.Orchestrations.CustomerCredit orchestration.
7. Select the Bindings tab.
8. Select BizTalkServerApplication for the host.
9. Click OK to close the dialog.
Exercise 3: Test the Orchestration
Overview
In this exercise, you will submit a message to the orchestration that will initiate a call to the
CustomerCredit web service.
Send a Message to the Orchestration

Procedure List
1. In the BizTalk Administration Console, right-click on Northwind and click Start, and in
the Start ‘Northwind’ Application prompt, click Start.
2. Verify that the application starts successfully.
3. In Windows Explorer, copy C:\AllFiles\LabFiles\Lab14\OrderExternal.xml to the
C:\AllFiles\LabFiles\Ports\OrderIN folder, and click paste several times to generate
multiple copies of the order.
CheckCustomerService returns a random rating for each customer between 0-5. Our
rule rejects orders when the rating isn't greater than 2.5. Verify that some of the
orders are approved and some rejected. Approved orders will get inserted into the
Northwind database orders table, while rejected orders should show up in the
c:\ports\rejected folder.
4. You have successfully invoked a WCF service from within a BizTalk orchestration.
In production solutions, you will want to put the service interactions within Scope
shapes so you can handle SOAP faults and deal with them appropriately.
Module 15: Implementing Messaging
Patterns
Module objective:
In this module, you will learn how to make use of additional features of BizTalk
orchestrations to implement commonly used messaging patterns.
Module Overview
By gaining a deeper understanding of the features of BizTalk orchestration ports, you can
design and implement more flexible messaging patterns to meet the needs of a wider array
of business scenarios.
This module examines the different styles of bindings that can be applied to orchestration
ports. It also revisits correlation, focusing on special cases called convoy messaging patterns
that arise when an orchestration is designed to receive multiple related messages.
Lesson 1: Creating Adaptable Orchestration Ports
Lesson objective:
Applying dynamic binding to orchestration ports opens new design possibilities.
Lesson Overview
BizTalk server offers five different types of port bindings that you can specify in the BizTalk
Orchestration Designer. Each style of binding offers a unique set of benefits.
Previous modules have covered the Specify Now and Specify Later binding types. This lesson
focuses on the additional types: Dynamic, Direct and Role Links.
Dynamic Binding allows you to set send port configuration settings at runtime. It
accommodates scenarios in which the destination URL for a message is not known at design
time.
Direct Binding provides a means for orchestration ports to define custom subscriptions,
opening up the possibility of communicating between orchestrations without requiring
physical ports to pass the messages between them.
Role Links provide a way to maintain sets of physical send and receive ports that are
assigned to trading partners. Role links enable reuse of common orchestrations, making it
easier to accommodate a growing number of trading partner systems.
Configuring Port Properties at Runtime
Send port configuration settings are specified at runtime.
Overview
Dynamic port binding is fairly straightforward. In this case, the orchestration is bound to a
minimally configured physical send port. At runtime, the orchestration passes configuration
settings as context properties of each outbound message. The settings are applied to the
physical send port configuration immediately before the message is transmitted.
The orchestration relies on application code to determine the send port configuration
settings. The URL and settings might come from different sources, which could include a
business rule, a database query, or it might even come within the content of an inbound
message (e.g. a confirmation might be sent to an email address that which is provided in a
purchase order message).
Communicating between Orchestrations
The three direct binding types each offer different benefits.
Overview
Applying direct binding to orchestration ports opens up possibilities that are not available
with the other types of binding. Direct binding allows you to send messages to other
orchestrations, while retaining the option of sending messages to physical send ports.
With direct binding you can design extensibility in to your BizTalk applications. By designing
your applications to maintain loose coupling between systems, you can minimize the impact
required to integrate with future systems.
BizTalk offers three styles of direct binding. MessageBox, Self-Correlating, and Shared Ports.
MessageBox. Binding an orchestration port directly to the MessageBox offers the most
flexibility amongst all of the binding styles. Directly binding to the MessageBox provides
both publishers and subscribers with complete control over their interactions with a
message’s context properties. Consequently, rather than having to deal with fixed
subscription patterns, BizTalk application designers can work at a higher level of abstraction
and increase the potential for loose coupling and greater maintainability.
Self-Correlating Ports. Direct binding with a self-correlating port imposes constraints that
are not present when binding directly to the MessageBox, but this approach can be easier to
work with, since some of the subscription details are handled by the BizTalk runtime. In this
case, one orchestration passes a port object to a second orchestration which uses the port
to send messages back to the first orchestration.
Shared Ports. The third direct binding option, shared ports, impose further constraints, but
they offer a convenient method to implement communication between orchestrations. In
this case, you configure the shared port in the port settings in the Orchestration Designer,
and the compiler and BizTalk runtime handle the subscription details.
Direct Binding with the Message Box
Direct binding to the MessageBox is the most powerful option. Use it carefully.
Overview
Direct binding with the MessageBox provides unobstructed access to BizTalk’s publish-
subscribe architecture. MessageBox direct bound ports enable an orchestration to drop
messages directly into the MessageBox database without an explicit recipient, and to
subscribe to messages that meet certain criteria rather than only messages that come from
a particular sender. BizTalk application designers can take advantage of this binding style to
create more flexible and reusable systems.
Promoting the right properties, and setting up the filters is the hardest part of working with
this style of binding. There can be any number of subscribers for any published message,
and if there are no subscribers interested in the message at the time that it is the BizTalk
runtime will throw an exception in the orchestration. Any orchestration that includes send
ports bound directly to the MessageBox should implement an exception handler to account
for that possibility.
Caveat
Also, think carefully about subscription filters when binding a port directly to the
MessageBox, it can be easy to accidentally create a subscription filter that recursively
creates orchestration instances.
An orchestration, for example, might publish a message that matches its own subscription
filter. If such an orchestration receives a PurchaseOrder and later publishes a copy of the
PurchaseOrder directly to the MessageBox, then a new instance of the same orchestration,
along with all of the other PurchaseOrder message subscribers, will be activated to process
the new copy of the message. The cycle will repeat until BizTalk runs out of resources to
process the unintended orchestration instances.
Direct Binding with Self Correlation
Direct binding with self-correlation off-loads some of the correlation details to the BizTalk
runtime.
Overview
Using direct binding with self-correlating ports is not as flexible as binding to the
MessageBox, but it makes it easier to get the subscriptions right. The BizTalk runtime
handles more of the subscription details in this case.
You set up a self-correlating port by using the Orchestration Designer to configure one
orchestration to start another orchestration, passing a port as a parameter. The second
orchestration can use the port to send messages back to the first orchestration.
Other than passing the port as a parameter in the start shape, self-correlating ports hide
most of the details of the direct binding. The BizTalk runtime handles the message
correlation behind the scenes with a custom correlation token that is generated by the
orchestration engine.
In the event that the second orchestration implements a commonly used business process,
such as a credit card authorization, the option remains open for other orchestrations to
make use of it by starting new instances, and passing ports of their own. The only
stipulation is that the port being passed must match the parameter’s type definition.
Direct Binding with Shared Ports
Direct binding with shared ports hides most of the correlation details.
Overview
Direct binding with shared ports fully encapsulates the details of the underlying message
correlation. imposes further constraints beyond those of self-correlation. This binding style
imposes further constraints beyond those of self-correlation. All of the direct binding details
are established up-front when a shared port is defined in the Orchestration Designer. When
defining a shared port, you need to specify the intended sending orchestration, or the
intended receiving orchestration of a message that is to be passed through the MessageBox.
Assigning Ports to Trading Partners
Role Links offer the ability to share a common business process amongst different trading
partners.
Overview
When working with multiple trading partners, you probably will not be able to use the same
physical send port to communicate with the entire group. You could, of course, use dynamic
ports to configure URLs and other details, but that approach would most likely pose
maintenance issues as the number of trading partners grows.
Role links allow you separate the concerns of trading partner management and business
process design. Using this approach, an orchestration has placeholders known as role links,
that represent send and receive ports used to communicate with trading partners.
At runtime, the orchestration specifies which trading partner it wants to communicate with,
and the trading partner management system takes care of the rest. The orchestration
provides an identifier, known as an alias, in a message’s context, and the trading partner
management system performs a look-up to determine the trading partner, and the
corresponding physical send port.
With role links in place, business analysts can manage trading partners, and developers can
focus on developing a common implementation of the business process.
Parties. Parties are all the entities outside of BizTalk Server that interact with an
orchestration. All of the partners that your organization deals with are considered parties,
and your organization may have several thousand partners. The BizTalk Administration
Console has a user interface that can be used to manage parties.
Roles and party enlistment. Parties interact with orchestrations through roles. During
development, you do not need to specify the actual party that the orchestration may
interact with.
An example of a role that an orchestration might use would be a shipper. The shipper would
have one or two parties associated with it. When the orchestration needs to decide which
shipping company to use to ship an item, it can compare the prices of the parties in the
shipper role.
Party enlistment is the mechanism that ties a party to a role. In BizTalk Explorer, you can
enlist a party in a role, and that will enable the orchestration to interact with the party.
In the example shown on the slide above, “SpeedyExpress” is an enrolled party in the
ShipperRole of the Ordering orchestration. At runtime, the orchestration determines which
shipping party should handle this order, and the Trading Partner Management system looks-
up the role link to determine that the message should be sent via the Ship_SpeedyExpress
send port.
Service Link Type. A service link type characterizes the relationship between two services or
orchestrations by defining the part played by each of the services in the relationship and
specifying the port types provided by each role.
Aliases. Aliases refer to the same party by different names. An organization or unit may be
known by its name, by a telephone number, by an e-mail alias, by a signature certificate, or
by a DUNS Number (used in some protocols), depending on who is referring to it and what
protocol pis being used.
BizTalk Server provides the ability to store multiple aliases for a party. Every party is given a
single default alias with a name of Organization, with a qualifier as OrganizationName and
value of the name of the party. This alias is always treated as the default alias. Aliases are
provided as triads of name, qualifier, and value. No two parties in the same BizTalk
Configuration database can have the same qualifier value pair. The alias name is used merely
for convenience.
You define business relationships in the Orchestration Designer using role links that contain
two roles. Each of these roles represents a partner in the business relationship the
orchestration is implementing. For example, you might implement an automated purchasing
relationship in a purchasing role link that contains both a buyer and a seller role. You use the
role link to implement two different orchestrations for both sides of the transaction. For
example, the orchestration representing the buyer process implements the buyer role and
uses the seller role.
Conversely, the orchestration representing the seller process orchestration implements the
seller role and uses the buyer role. After you create these roles, an administrator can easily
package the partner orchestration and associated information in a BizTalk application for
quick deployment on a partner running BizTalk Server 2010.
Choosing Partners for Role Links
Orchestrations can depend on the Trading Partner Management system to handle the details of
communicating with a particular partner.
Overview
An orchestration needs a way to indicate with which trading partner that it needs to
communicate. It can indicate a given trading partner to the Trading Partner Management
runtime by setting a property on a role link. Since trading partners are identified by one or
more aliases, the orchestration simply specifies an alias value, and which type of alias it is
using.
The alias must correspond to a value that a business analysts has entered using the Trading
Partner Management user interface, which is provided by the BizTalk Administration
Console. BizTalk Server 2010 defines the new B2B Operator Windows group that a system
administrator can apply when granting access to users who need to maintain Trading
Partner Management information.
On the receive side, the party resolution pipeline component can use identifiers in an
inbound message to attempt to identify a trading partner that is sending the message to
BizTalk. The receive port accepting the message needs to have authentication enabled, and
therefore the needs host to be configured as “trusted”.
Consumers and Providers

A role link has a SourceParty property, a DestinationParty property, and an initiating role. An
initiating role is the role on which the first communication occurs, and which therefore
initiates the role link by setting the value of the DestinationParty property.
If the initiating role is a consumer for sending messages, you explicitly set the
DestinationParty property (once and only once) in your orchestration. To do so, you set the
value of the DestinationParty in the Expression shape, as in the following example, where
ConfirmOrder is the name of a role link, and PartnerName and OrganizationName are
parameters of a party:
ConfirmOrder(Microsoft.XLANGs.BaseTypes.DestinationParty) = new
Microsoft.XLANGs.BaseTypes.Party("SpeedEx", "OrganizationName");
If the initiating role is a provider for receiving messages, the DestinationParty property is
initialized automatically by the receiver. The DestinationParty is set to the provider itself.
The SourceParty property is read-only, and is supplied by the party resolution pipeline
component based on the security identifier (SID) of the sender or on a certificate associated
with the party. The host running the pipeline component must be marked as Authentication
Trusted. You can get the value of the SourceParty in the Expression shape by using the
following sample code:
PartyName = Buyer_Supplier(Microsoft.XLANGs.BaseTypes.SourceParty);
Dynamic Binding Options
Dynamic binding offers benefits that Specify Now and Specify Later cannot provide.
Overview
To summarize the various dynamic binding options that BizTalk offers:
Dynamic addressing relies on a predetermined subscription, but leaves options open for
configuration of a physical send port.
Direct binding to the MessageBox addresses the creation of subscriptions at a more
abstract level. Binding directly to the MessageBox offers the most flexibility. An
orchestration can decide at runtime which message context properties it wants to set for
each message. This binding style is very powerful, but application designers need to think
carefully about how to ensure that messages are delivered correctly.
Self-correlating ports are more tightly coupled than binding directly to the MessageBox, but
an orchestration can still choose at runtime from amongst a number of different
orchestrations to start. It could starting more than one if necessary. This binding style
makes it easier to ensure that message is delivered correctly.
Shared ports are the least flexible of the direct binding options, but they are also the easiest
to set up. With this binding style, the correlation and subscription details are hidden by the
designer and runtime.
Role Links offer a form of dynamic binding that address the specific use case of managing
subscriptions on the behalf of individual trading partners.
Conclusion
Although a message appears to go directly from one orchestration to another with direct
binding, any message sent through any type of logical port always travels through the
MessageBox database. Moreover, direct bound ports are only logical ports and therefore
direct binding is only a design-time configuration feature. A direct bound port cannot be
bound to a physical port, and you can only change the direct binding configuration at design
time.
One thing to keep in mind with these direct messaging options, as well as using the Start
orchestration shape to asynchronously start an orchestration, is that they all use the
underlying publish and subscribe model. The difference between these options is in the
properties that are used for creating subscriptions and routing, and in the use cases they
help solve.
Demonstration: Configuring Dynamic Ports
Learn to apply dynamic addressing and role links.
Install the Sample Application

1. In Windows Explorer, navigate to C:\AllFiles and double-click startBtServices.cmd.
2. Then, navigate to C:\AllFiles\DemoCode\Module15, and double-click
SetupDynamicPorts.cmd.
3. Verify that the installation completed successfully, then close the command window.
Review the Flow of the OrderProcessing Orchestration

1. In Windows Explorer, navigate to C:\AllFiles\DemoCode\Module15\DynamicPorts
and open DynamicPorts.sln.
2. In Solution Explorer, double-click the OrderProcessing.odx orchestration.
This orchestration will receive an order message and branch based on the
country of the shipping destination. If the shipping destination is within the UK,
then the orchestration creates a shipping message, selects a trading partner to
handle the shipping, and sends the shipping message.
If the shipping destination is outside of the UK, then the orchestration will create
a billing message, and send it to the billing department.
Examine the Dynamic Binding of the Billing Port

1. Within the ConstructBillingMessage shape, double-click the MessageAssignment
shape.
This Message Assignment shape copies the OrderMessage to the BillingMessage,
including all of the message context properties. Then it dynamically configures
the send port by setting message context properties on the BillingMessage.
Notice that the first four message context properties begin with the prefix SMTP.
This shape assumes that the billing message will be sent with the SMTP adapter,
so it initializes a set of properties to configure an email with the billing message
as an attached file. The last three message context properties configure the
details of the attachment.
2. Click Cancel to close the BizTalk Expression Editor.
3. Double-click the SetDynamicAddress Expression shape.
This Expression shape sets the destination URL for the billing message. In this
case, the URL begins with the “mailto” prefix. The BizTalk runtime uses the URL
prefix to determine which adapter it should use to send the message. Had the
URL begun with a different prefix, like “ftp”, the previously configured SMTP
context properties would be ignored.
4. Click Cancel to close the BizTalk Expression Editor.
5. Double-click the BillingPort shape, and in the Port Configuration Wizard, click Next
three times to advance to the Port Binding page.
Notice that this port is configured to send messages, the Port binding is Dynamic,
and the Send pipeline is PassThruTransmit.
6. Click Cancel to close the Port Configuration Wizard.
Examine the Role Link of the Shipping Port

1. In the IsUK branch of the Decide shape, double-click the SelectParty Expression
shape.
Notice that this Expression shape does not set an address. Instead, it simply sets
the DestinationParty property on the ShipperRole role link. The orchestration is
relying on the BizTalk runtime to look up the corresponding physical send port to
send a shipping message to this party. Parties are configured in the BizTalk
Administration Console. Notice that the DestinationParty property is a key-value
pair. In this case, the BizTalk runtime will look for a party with an OrganizationID
of “UP”.
2. Click Cancel, then click the ShipperRole shape.
The Shipper Role Link consists of a provider and a consumer. In this case, the
orchestration is sending out a message first, so it acts as a provider. You can
assign an orchestration send port to a role link by simply dragging and dropping
the send port from the port surface to the role link shape. Notice that the
ShipperPort is now simply specified as a ShippingPortType. The actual port will
be assigned at runtime.
Examine the Role Link Configuration in the BizTalk Administration Console

1. In the BizTalk Administration console, under the Demos.Northwind application, click
on the Role Links icon, and then in the right pane double-click Provider.
Notice the title at the top of the right-hand pane. This is where you will assign
the shipper send ports to their corresponding parties. If you had defined other
role link types in the orchestration, they would be configured separately.
2. Click the Unenlist button twice.
3. Click the Enlist button.
4. In the Enlist Parties dialog box, check the Federal Shipping and United Package
check boxes, and then click OK.
5. In the Provider – Role Link Properties dialog box, click Federal Shipping, and then
click the Bind button.
6. In the Send Port list, select Shipper_FederalShipping, and then click OK.
This list displays the one-way send ports that are associated with the Federal
Shipping party.
7. In the Provider – Role Link Properties dialog box, click United Package, and then click
the Bind button.
8. In the Send Port list, select Shipper_UnitedPackage, and then click OK.
This list displays the one-way send ports that are associated with the United
Package party.
9. Click OK to close the Provider – Role Link Properties dialog box.
10. In the left pane of the BizTalk Administration Console, click Send Ports.
Notice that Shipper_FederalShipping and Shipper_UnitedPackage are simply
standard ports.
11. In the left pane of the BizTalk Adminstration Console, click Parties.
12. Expand the United Package party, and double-click United Package_Profile, then in
the left pane click Identities.
Notice that the United Package party has an alias named OrganizationId, with
the value “UP”. This is the alias that the orchestration used to identify this party.
The Federal Shipping party has an alias named OrganizationId, with the value
“FS”. You can add as many aliases as you need to identify a party. Examples
include a D-U-N-S number, a banking number, an EIN number, or a custom
identifier.
13. Click Cancel.
14. Double-click United Package, then in the left pane of the Party Properties dialog
box, click Send Ports to view the ports that are assigned to the United Package
party.
15. Click Cancel.
Run the Orchestration

1. In Windows Explorer, navigate to C:\AllFiles\DemoCode\Module15\DynamicPorts,
and drop a copy of the ExternalOrder.xml message in
C:\AllFiles\DemoCode\Northwind\Ports\FileIN.
This message represents an order that is to be shipped within the UK.
2. Verify that an XML message appears in the
C:\AllFiles\DemoCode\Northwind\Ports\Shippers\UnitedPackage folder.
3. Drop a copy of the ExternalOrder_NonUK.xml message in to the
C:\AllFiles\DemoCode\Northwind\Ports\ FileIN folder.
4. Verify that an email message appears in the C:\inetpub\mailroot\drop folder.
5. Double-click the .eml file and notice that the billing message is attached.
Lesson 2: Receiving Multiple Related Messages
Lesson objective:
Simple correlation will break down when BizTalk receives multiple related messages
simultaneously.
Lesson Overview
Correlation addresses the issue of handling subscriptions when an orchestration needs to
process messages that are related to one another. Correlation was introduced in Module 9,
Automating Business Processes.
Simple correlation, however, is not sufficient in all cases. It is possible to encounter
situations in which simple correlation breaks down, and the runtime needs to step in and
coordinate at a higher level. This lesson covers these special cases, which are known as
convoys.
How Correlation Works
The BizTalk runtime handles correlation by creating fine-grained subscriptions on the fly.
Overview
Correlation in orchestrations is the mechanism that enables an orchestration to receive
related messages in to the same running instance.
In the case of simple correlation, an orchestration sends out a message and waits for a
corresponding response. Under these circumstances, the BizTalk runtime needs to watch for
a specific message to return back to the orchestration. Here, the BizTalk runtime relies on
the orchestration to provide a set of message context values, known as a correlation set,
that it can use to create a fine-grained subscription to pick up the response message
intended for the orchestration.
When the matching response message arrives, the runtime delivers the message to the
orchestration to continue processing, and the runtime drops the subscription.
Correlation Types and Correlation Sets

A Correlation type in an orchestration defines the set of context properties that will be used
to create a subscription. A correlation set is a variable that holds instance values at runtime.
The orchestration populates the set by initializing the correlation set on a send or receive
shape.
Using correlation sets, the BizTalk orchestration runtime can create the very fine grained
subscriptions to ensure that a message can be routed to the proper instance of an
orchestration.
Orchestration Subscriptions
Activation subscriptions create a new instance of an orchestration. Instance subscriptions direct

messages to an orchestration that is already running.
Overview
In BizTalk Server, there are two main types of subscriptions: activation and instance. An
activation subscription is one specifying that a message that fulfills the subscription should
activate, or create, a new instance of the subscriber when it is received. Examples of things
that create activation subscriptions include send ports with filters or send ports that are
bound to orchestrations, and orchestration receive shapes that have their "Activate"
property set to true.
An instance subscription indicates that messages that fulfill the subscription should be
routed to an already-running instance of the subscriber. Examples of things that create
instance subscriptions are orchestrations with correlated receives and request/response-
style receive ports waiting for a response from BizTalk Server.
Instance subscriptions are created for receive shapes that are following a correlation set,
and they include the specific values that are included in the correlation set when it is
initialized. The subscriber ID includes the orchestration instance ID.
Instance subscriptions come into play when a correlation set is initiated, as this is when
subscriptions are created for all of those ports that follow this correlation set to receive
messages. Because the correlation type defines the properties to be used for correlation, the
orchestration engine can extract these properties from the message being sent or received
by the initiating action. These values are then used to define subscriptions for all of the
remaining actions which follow this correlation set.
Convoy Messaging Patterns
An orchestration needs the BizTalk runtime to provide additional coordination in certain cases.
Overview
Under certain conditions, an orchestration instance might receive a group of correlated
messages all at the same time. In this situation, a race condition might occur, in which one of
the messages in the group must initialize a correlation set in the orchestration instance
before the other messages can be correlated to that orchestration instance. A convoy exists
any time in which the BizTalk runtime must handle multiple related messages that could
cause a race condition within an orchestration instance.
Convoy patterns are correlation use cases that require special handling. In these cases,
simple correlation would break down and route messages incorrectly. When dealing with
convoy patterns, the runtime needs to step in to coordinate at a higher level. The
Orchestration Designer recognizes convoy patterns, and it enforces constraints required by
the BizTalk runtime to handle the convoy messages correctly.
BizTalk handles convoy subscriptions differently than it handles other types of instance
subscriptions to determine if a message should be sent to a new instance, or to a running
instance.
To ensure that all of the correlated messages are received by the same orchestration
instance, BizTalk Server detects the potential for such a race condition and treats these
messages as a convoy. At enlistment, the runtime creates a general subscription and
identifies it as part of a convoy. After filling this subscription, the messaging engine creates a
temporary subscription based on the values in the predefined correlation properties. All
subsequent messages that match the general subscription are evaluated against the
temporary subscriptions, and those that match are routed to an existing orchestration.
There are two main types of convoys: sequential convoys and parallel convoys. The main
difference in the two types of convoys is the order of receipt of the items.
Sequential Convoys are sets of related items that have a predefined order. The items do not
have to be exactly the same, but they are all related to a specific instance of a business
process.
Parallel Convoys enable a business process to wait for a set of messages of different types to
arrive in any order before continuing to process.
“Zombie” Messages
The use of convoys can result in "lost" messages which are known as “zombie” messages.
When a non-activating receive subscription in a running orchestration matches a message in
the MessageBox database, then the BizTalk runtime is obligated to deliver the message to
the orchestration. Because the MessageBox does not know the business logic inside the
orchestration, it simply delivers all of the messages that match the subscription to the
orchestration. If any of these messages are delivered when the orchestration execution flow
has passed all of the corresponding receive shapes, then the messages are suspended,
becoming “zombie” messages.
An example of a situation that creates zombies is a receive inside a loop that iterates 17
times, but 18 messages are delivered that match the receive subscription in the loop. (The
MessageBox does not know that the orchestration logic only handles 17 messages.) The
18th message delivered is not consumed by the orchestration because execution flow has
already exited the loop. The orchestration is completed with discarded messages (zombies),
which are not resumable because the orchestration instance has already completed.
You can manage zombies by using a Windows Management Instrumentation (WMI) script to
query the instances with the "Suspended-NonResumable" state. In addition, the messaging
engine writes an error message, "Completed with discarded messages", to the event log.
Sequential Convoys
Sequential convoys allow an orchestration to receive multiple related messages in series.
Overview
A sequential convoy occurs when multiple, related messages arrive in a series. In this case,
you will need to know at design time, which type of message will arrive first. Subsequent
messages do not need to be of the same time, but they will need to be correlated, and they
are required to arrive through the same receive port.
Since multiple messages could arrive simultaneously, the runtime needs to ensure that it
takes additional precautions to handle the instance subscriptions.
There are two sub-types of sequential convoys: uniform sequential convoys and non-
uniform sequential convoys.
Uniform Sequential Convoy

A uniform sequential convoys consists of an orchestration receiving a series of related
messages that are all of the same type. Uniform sequential convoys are handled with a
single receive port having a single operation that represents a particular message type.
Non-Uniform Sequential Receives

A non-uniform sequential convoys consists of an orchestration receiving a series of related
messages that may be of different types. An orchestration might, for example, receive an
order header, followed by a number of related line item messages. Non-uniform sequential
convoys are handled with a receive port that has multiple operations, with each operation
representing a different message type.
Implementing Sequential Convoys
The sequential convoy pattern is easy to implement in the Orchestration Designer.
Overview
Determining the correct loop condition is a key part of the design of a convoy. When is it
okay to break out of the receive cycle and move on with the processing?
Uniform Sequential Receives

To build a business process to handle this kind of messaging pattern, you place two
successive Receive shapes into the orchestration. These must both receive the same
message type from the same port. If the first Receive shape is the first shape in the
orchestration, you need to set its Activate property to "True. The first Receive shape must
also initialize a correlation set used for the subsequent Receive shape. The second Receive
shape must follow this correlation set. A common implementation of this design pattern is in
a batching scenario. This positions the second Receive shape inside a Loop shape to enable
receipt of many additional messages by the business process.
Non-Uniform Sequential Receives

To implement this message pattern in a business process, position multiple Receive shapes
in order inside the orchestration. If the first Receive shape is the first shape in the
orchestration, you need to set its Activate property to "True. The first Receive shape in the
convoy initializes a correlation set followed by all subsequent Receive shapes. The individual
messages must all originate from the same port and this port must be marked for ordered
delivery. The individual message types are each associated with a separate operation inside
the port.
Parallel Convoys
Parallel convoys support allow an orchestration to receive a fixed number of messages in any
order.
Overview
A parallel convoy occurs any time on orchestration will wait for a known quantity of related
messages that may arrive in any order. The messages may be of different types, and may
arrive through one or more ports.
An example would be a hospital admissions process in which an admissions message, a
medical records message and a room assignment message must arrive before the business
process can proceed.
Implementing Parallel Convoys
The Orchestration Designer makes it easy to implement parallel convoys.
Overview
In order to handle a parallel convoy inside an orchestration, you must use the Parallel Action
shape. Add a Receive shape to each parallel branch in the shape, one for each message that
you must receive. If the Parallel Action shape is the first shape in the orchestration, all of the
Receive shapes inside the Parallel Action shape must have their Activate property to "True.
The incoming messages may be received from different ports and be of different types.
Use a correlation set to relate all the incoming messages together. Each of the Receive
shapes inside the Parallel shape must initialize the correlation set.
Demonstration: Implementing Convoy Patterns
Learn to implement a non-uniform sequential convoy and a parallel convoy.

2. In Windows Explorer, navigate to C:\AllFiles\DemoCode\Module15, and double-
click SetupConvoySamples.cmd.
3. Verify that the installation completed successfully, and that it un-enlisted the
ParallelConvoy orchestration, then close the command window.
Examine a Non-Uniform Sequential Convoy

C:\AllFiles\DemoCode\Module15\ConvoySamples, and then double-click
ConvoySamples.sln.
2. In Solution Explorer, double-click SequentialSample.odx to open the orchestration.
3. Click the Receive_InitialBill Receive shape.
Notice that its Activate property is true. BizTalk will create a new instance of this
orchestration when it receives a new billing message that is not related to any
other billing messages being processed.
4. Click the Send_InitialAudit Send shape.
This Send shape simply sends a message to the AuditPort to allow us to see the
sequence of messages that the orchestration is processing.
5. Click the Loop shape.
The orchestration will loop, listening for billing and shipping messages. If it
receives a billing message, it will send the message to the audit port, and then
listen for another message.
6. Double-click the Done Expression shape.
If the orchestration receives a shipping message, it will send the message to the
audit port, set a flag to end the loop, and the orchestration will complete.
7. Click Cancel, then click the Receive_InitialBill Receive shape.
Notice that this Receive shape initializes SeqCustomerCorrelation.
8. Click the Receive_BillUpdate Receive shape
Notice that this Receive shape follows SeqCustomerCorrelation, and that its
Activate property is false.
9. Click the Receive_Shipping Receive shape
Notice that this Receive shape follows SeqCustomerCorrelation, and that its
Activate property is false.
When BizTalk receives a new message at the Receive_InitialBill shape, it will
create two new instance subscriptions, one to listen for billing messages that
correlate to the initial bill, and another to listen for shipping messages that
correlate to the initial bill.
Run the Sequential Convoy Orchestration

C:\AllFiles\DemoCode\Module15\ConvoySamples\Instances, and copy the
BillingRequest_1.txt file to C:\AllFiles\DemoCode\Northwind\Ports\FileIN.
2. In the BizTalk Administration Console, click on BizTalk Group, and then in the center
pane, click the Group Hub tab.
3. Press the F5 key to refresh the page, and notice that there is one Running service
instance.
4. Click the Running service instances link.
5. In the bottom pane, double-click the highlighted service instance to view the details.
6. Click OK.
7. In Windows Explorer, copy the BillingRequest_2.txt through BillingRequest_4.txt
files to C:\AllFiles\DemoCode\Northwind\Ports\FileIN.
8. Navigate to C:\AllFiles\DemoCode\Northwind\Ports\Audit, and notice that there
are four billing messages so far.
9. In the BizTalk Administration Console, in the center pane, on the Running tab, click
Run Query, and notice that the instance of the SequentialSample orchestration is
still running.
The service instance status will show either Active or Dehydrated. If the
orchestration is Dehydrated, it is still “running”, even though BizTalk has
dropped the orchestration object from memory while it waits for more messages.
10. In Windows Explorer, copy the OrderShipping.xml file from
C:\AllFiles\DemoCode\Module15\ConvoySamples\Instances to
11. Navigate to C:\AllFiles\DemoCode\Northwind\Ports\Audit, and notice the shipping
message appears.
Run Query, and notice that the instance of the SequentialSample orchestration has
completed.
Demonstrate the “Zombie” Message Condition

1. In Windows Explorer, delete all of the messages in the
C:\AllFiles\DemoCode\Northwind\Ports\Audit folder.
C:\AllFiles\DemoCode\Module15\ConvoySamples, and double-click
CopyAllMessages.cmd.
The CopyAllMessages.cmd script copies one billing message to initiate an
instance of the SequentialSample orchestration.
3. Press any key to copy the remaining billing messages and the shipping message.
4. Navigate to C:\AllFiles\DemoCode\Northwind\Ports\Audit, and notice that some
number of messages appear, but not all of the messages were processed.
There is a chance that all of the messages could have made it through the
orchestration. If that happens, restart at step 1.
Run Query, and notice that the instance of the SequentialSample orchestration is
not listed.
6. Click the New Query tab, and in the Search For / Value list, select Suspended
Service Instances, and then click Run Query.
7. Double-click the orchestration in the query result, and then click on the Error
Information tab.
The Error Description is “The instance has completed without consuming all of its
messages. The instance and its unconsumed messages have been suspended”.
In the Messages referenced by the service instance list, you will see billing
messages that had been published to the message box, but were not processed
by the orchestration.
In this case, the orchestration’s instance subscription for billing messages had
existed when these messages were published to the message box, but when they
were to be delivered to the orchestration, the subscription was no longer in
effect because the orchestration had already processed a shipping message, and
had then completed. BizTalk had picked up the shipping message from the file
system at the same time that it had picked up the remaining billing messages.
These unconsumed messages are called “zombie” messages, and they are a
known side effect of convoys. The possibility of zombie messages always exists
when messages are submitted to BizTalk convoy over a transport that does not
support ordered delivery. You can find more information on zombie message in
BizTalk Server help where the condition is well documented.
9. Click OK.
10. Select all of the items in the query result, right-click on the selection and click
Terminate Instances, then click Yes, and then click OK.
11. Click Run Query to verify that the service instances were terminated.
Examine a Parallel Convoy

1. In Visual Studio, in Solution Explorer, double-click ParallelConvoy.odx to open the
orchestration.
Notice that the Receive_Billing shape, and the Receive_Shipping shape are
placed within a Parallel Actions shape. The Parallel Action shape is implemented
specifically to handle parallel convoys.
2. Click the Receive_Billing Receive shape.
Notice that its Activate property is true, and that it initializes
CustomerCorrelationSet.
3. Click the Receive_Shipping Receive shape.
Notice that its Activate property is also set to true, and that it also initializes
CustomerCorrelationSet.
Since either receive shape can activate a new instance of this orchestration,
BizTalk can handle the arrival of these messages in any order.
4. Right-click the Parallel Action shape, then click New Parallel Branch.
5. Notice that it is possible to add additional branches that handle the arrival of
additional types of messages.
6. Right-click the empty parallel branch, and then click Delete.
Run the Orchestration

1. In the BizTalk Administration Console, under the Demos.Northwind application, click
Orchestrations.
2. Right-click the ConvoyOrchestrations.SequentialSample, and then click Unenlist.
3. Right-click the ConvoyOrchestrations.ParallelConvoy, and then click Start.
4. In Windows Explorer, delete all of the messages in the
C:\AllFiles\DemoCode\Northwind\Ports\Audit folder.
C:\AllFiles\DemoCode\Module15\ConvoySamples\Instances, and copy the
BillingRequest_1.txt file to C:\AllFiles\DemoCode\Northwind\Ports\FileIN.
6. Navigate to C:\AllFiles\DemoCode\Northwind\Ports\Audit, and notice the message
was processed.
7. In the BizTalk Administration Console, click BizTalk Group, then in the center pane,
click the Group Hub tab, and then press the F5 key.
8. Click the Running service instances link, and notice that an instance of the
ParallelConvoy orchestration is running.
9. In Windows Explorer, copy the OrderShipping.xml file from
C:\AllFiles\DemoCode\Module15\ConvoySamples\Instances, to
Run Query, and notice that the instance of the ParallelConvoy orchestration has
completed.
11. Repeat steps 4 – 11, but copy the OrderShipping.xml file in step 4, and copy the
BillingRequest_1.txt file in step 9.
Lab: Implementing Dynamic Messaging Patterns
Overview
In this lab you will update the Northwind ordering process to make the orchestration
messaging more dynamic and add support for correlation. You will use role links to provide
partner specific sending and receiving and add dynamic links to support a publish and
subscribe messaging model for you orchestrations. In addition, you will use correlation to
route related messages to an orchestration instance.
Procedure List
window.
Start.

Procedure List
Exercise 1: Use Correlation
Overview
In this part, you will message correlation to the order process. In this case, you will send a
message from the order process to a shipping process, and get a response back for this
particular order by correlating messages on the Order ID.
Examine the Shipping Orchestration

The shipping orchestration handles shipping requests and routes them to an appropriate
shipper.
Procedure List
1. In Windows Explorer, navigate to C:\AllFiles\LabFiles\Lab15\Northwind and open
the Northwind.sln solution in Visual Studio.
2. Open the Shipping.odx and examine the orchestration. This orchestration receives a
shipping request and then sends out a notice before replying with an
acknowledgement.
3. Examine the MessageCreator.cs file in the Utilities project. This class is used by the
shipping orchestration to create the acknowledgement message. It clones an XML
document which contains a valid instance of the acknowledgement message type.
Set Up Schemas for Correlated Messaging

Procedure List
1. Open the MyProperties.xsd schema, and add a property named OrderIdentifier.
2. Save and close the property schema.
3. Open the ShippingRequest.xsd schema, expand the ShipRequest node and right-
click the OrderID attribute and click Promote, then click Show Promotions.
4. Go to the Property Fields tab and add the Northwind.Schemas.MyProperties
schema as a property schema.
5. Set the namespace prefix to prop and then add the OrderID attribute to the
promoted properties. In the Property Fields list, in the Property list, select
prop:OrderIdentifier.
6. Save and close ShippingRequest.xsd.
7. Repeat steps 3-5 above for the ShipmentID field in the ShipAck.xsd schema.
Add Shipping Artifacts to the Ordering Orchestration
Procedure List
1. Add the existing MapOrderToShipRequest.btm file from the
C:\AllFiles\LabFiles\Lab15\Northwind\Artifacts directory to the Maps project.
2. Right-click on the Maps project and click Build.
3. Open the RouteOrder.odx orchestration.
4. In the Orchestration View, right-click the Messages node and add a new message.
5. Use the Properties window set the identifier of the message to
ShipAcknowledgement.
6. Set the Message Type property by clicking Schemas, then click
Northwind.Schemas.ShipAck.
7. Create another message named ShipRequest with a type of
Northwind.Schemas.ShippingRequest.
Add Shapes to Communicate with the Shipping Orchestration

Procedure List
1. Delete the “Shipping Destination?” Decision shape.
2. Delete the ShippingUSASendPort and ShippingInternationalSendPort ports.
3. At the end of the RouteOrder orchestration add a Construct Message shape with a
Transform and a Message Assignment shape inside of it.
4. Follow this by a Send shape and then a Receive shape. Set the properties as shown
in the table below. Review the image that follows the table to see the intended
outcome.
Property Value
Construct shape
Messages constructed ShipRequest
Name Construct ship request
Transform shape
Name MapOrderToShipRequest
Map Northwind.Maps.MapOrderToShipRequest
Note: This map exists in the Northwind.Maps assembly.
Input Message OrderMessage

Output Message ShipRequest
Message Assignment shape
Name AssignOrderID
Expression ShipRequest(Northwind.Schemas.OrderIdentifier) =
System.String.Format("{0:N}",
System.Guid.NewGuid());
Send shape
Name SendShipRequest
Message ShipRequest
Receive shape
Name ReceiveShipAcknowledgement
Message ShipAcknowledgement
5. In the orchestration view window, expand the Types node and right click Correlation
Types, and then click New Correlation Type.
6. In the left pane, expand Northwind.Schemas, click OrderIdentifier then click Add,
and then click OK.
The Northwind.Schemas.OrderIdentifier property is now included in the
correlation type.
7. Set the Identifier property on the correlation type to ShippingCorrelationType.
You have defined a correlation type, which identifies which context properties
will be used to correlate. In the next step, you will define a correlation set which
is a container for specific data, based on this type.
8. Right click the Correlation Sets node to create a new correlation set.
9. Set the identifier property to ShippingCorrelation.
10. Set the correlation type to Northwind.Orchestrations.ShippingCorrelationType
11. On the SendShipRequest shape, set the Initializing Correlation Sets property to
ShippingCorrelation.
12. On the ReceiveShipAcknowledgement shape, set the Following Correlation Sets to
You have configured the two ports to participate in correlation. When a message
is sent from the send port, it will initialize the correlation set with the values
currently in the context properties. The receive shape that follows the
correlation set will now have an instance subscription based on the correlation
set values.
13. Right-click on the right-hand port surface, and click New Configured Port.
14. In the wizard, name the port ShippingPort and create a new port type named
ShippingPortType.
15. In the next wizard pane, indicate that you will be sending messages and accept all
other defaults.
17. In the wizard, name the port ShippingAckPort and create a new port type named
ShippingAckPortType.
18. In the next wizard pane, indicate that you will be receiving messages and accept all
other defaults.
19. Drag the connection points from the send and receive shapes to these new ports as
appropriate.
Construct the Shipping Acknowledgement Message

Procedure List
1. Open the Shipping.odx orchestration, and inside the ConstructAck Construct
Message shape, double-click the Create Ack Message Assignment shape.
2. In the BizTalk Expression Editor window, enter the following line of code, then click
OK.
OrderShipAck = Northwind.Utilities.MessageCreator.CreateShipAck(
OrderShipRequest(Northwind.Schemas.OrderIdentifier));

Procedure List
1. Right-click the Northwind solution, and then click Deploy Solution.
The Northwind.Utilities project was already deployed to the GAC when you ran
the original setup script for this lab.
Configure the Application Ports

Procedure List
1. Open the BizTalk Server Administration Console.
2. Right-click the Northwind application and click Import, then click Bindings.
3. Import the Northwind.Correlated.BindingFile.xml from the
C:\AllFiles\LabFiles\Lab15\Northwind folder.
4. Examine the send and receive ports added to the application and view the
configuration of the adapters. There are several File ports that will be used to send
the messages between the orchestrations.
5. Right-click the Northwind application and choose Configure.
6. Configure the RouteOrder orchestration by binding the logical ports to the physical
ports with the following mappings:
OrderReceivePort Northwind_ReceiveOrders
ShippingAckPort Northwind_ReceiveShipAck
ShippingPort Northwind_ShipRequest
7. Configure the Shipping orchestration by binding the logical ports to the physical
ports with the following mappings, and choosing the BizTalk Server Application as
the host:

ReceiveShippingRequestPort Northwind_ReceiveShipping
ShipperPort Northwind_SendShippingAudit
ShipAckPort Northwind_SendShippingAck
8. Both orchestrations should show green check marks when all of the configuration is
complete.
9. Apply the changes and exit the configuration dialog.
Test the Solution

Procedure List
1. Right-click the Northwind application, and then click Start.
2. Copy the OrderExternal.xml file from the C:\AllFiles\LabFiles\Lab15 directory to the
C:\AllFiles\LabFiles\Ports\OrderIN directory.
3. Open the C:\AllFiles\LabFiles\Ports\Audit directory and validate that the shipping
notice arrives.
4. To view the detailed steps, disable the Northwind_ReceiveShipAck_File and
Northwind_ReceiveShipping_File receive locations.
5. Submit a message, and you should find it waiting in C:\AllFiles\LabFiles\Ports
\shipping\requests.
6. Enable the Northwind_ReceiveShipping_File receive location and then you should
find the acknowledgement in the C:\AllFiles\LabFiles\Ports
\shipping\acknowledgments folder.
7. Enable the Northwind_ReceiveShipAck_File location and the process should
complete.
Exercise 2: Using Role Links for Messaging
Overview
In this part, you will create a role link to identify the shipper role in the business process.
Later, you will define the parties which can play this role for this given process. This will
allow the actual send port to be chosen dynamically based on some data that identifies the
party currently playing that role.
Define a Role Link in the Shipping Orchestration

Procedure List
1. Open the Shipping.odx orchestration
2. Right-click in the right-hand port surface, and click New Role Link, and then click
Next.
3. In the wizard, name the role link ShipperRoleLink and create a new role link type
named ShipperRoleLinkPortType.
4. Specify that the orchestration will be playing the role of consumer indicating that
the orchestration will be consuming the role link by sending the first message.
5. Click Finish.
6. Drag the ShipperPort to the provider space of the role link to indicate the port type
consumed by the orchestration as part of the role.
Notice that instead of ShipperPort the port is now called ShipperPortType. This is
because the role link is our logical entity now, and the port type is just that, a
type.
Set the Destination Party
The orchestration must set the destination party for the role link so the appropriate send
port can be selected.
Procedure List
1. Using the orchestration view, add a new variable named shipperIdentifier of type
string.
2. Drag an Expression shape from the toolbox and add it to the orchestration just
before the SendToChosenShipper shape.
3. Set the name of the Expression shape to DetermineShipper and double-click the
Expression shape to edit the code.
4. Add the following code to the Expression shape which defines the shipper, and then
sets the destination party for the role link:
shipperIdentifier = "Federal Shipping";

ShipperRoleLink(Microsoft.XLANGs.BaseTypes.DestinationParty) =
new Microsoft.XLANGs.BaseTypes.Party(
shipperIdentifier, "OrganizationName");
Note that in this scenario we hard code the shipper name. In a real scenario, you
would use business rules to dynamically determine the shipper. We use the
shipper name, but when defining parties, any custom identifier can be created as
an alias for that party and used to set the destination part. For example, your
internal customer id, or a DUNS number.
5. Your orchestration should look similar to the image below:
6. Build the solution and fix any problems that arise.
7. Right click the solution and choose Deploy Solution.
Exercise 3: Define Parties
Overview
In this part you will define the configuration related to the roles and send ports for the
orchestration. You will create physical send ports for each shipper and then enlist or link
them to the role link you defined in the business process.
Create the Send Ports for the Shippers

Procedure List
1. In Windows Explorer, validate that the folder c:\AllFiles\LabFiles\ports\shippers
exists.
2. Within the folder above, are three folders representing the three shippers: Federal
Shipping, Speedy Express and United Package.
3. Open the BizTalk Server Administration Console and navigate to the Northwind
application node.
4. Add three static one-way send ports to represent three different shippers. The
configuration information is below:
Send Port: Shipper_United

Transport Type FILE
Address c:\AllFiles\LabFiles\Ports\shippers\UnitedPackage
Pipeline passthrough
Send Port: Shipper_Speedy
Transport Type FILE
Address c:\AllFiles\LabFiles\Ports \shippers\SpeedyExpress
Send Port: Shipper_Federal
Transport Type FILE
Address c:\AllFiles\LabFiles\Ports \shippers\ FederalShipping
5. Start all three send ports after they are created.
Define the Shippers and Assign Send Ports

Procedure List
1. Right-click the Parties node and create a new party.
2. Name the party Federal Shipping and then use the send port pane to select the
Shipper_Federal send port.
3. Repeat the above two steps to create parties named Speedy Express and United
Package associated to their respective send ports.
Enroll the Parties in the Orchestration Shipper Role

Procedure List
1. Click the Role Links node in the Northwind application
2. Double-click the Provider item and then click the Enlist button.
3. Check all three shippers and click OK
4. Highlight each party and click the Bind button, then select the appropriate send port
to bind to the NotifyShipper operation.
5. Be sure you have configured all shippers.
Test the Solution

Procedure List
1. Right-click the Northwind application and choose Start to start all send ports and
orchestrations.
c:\AllFiles\LabFiles\Ports\OrderIN\ directory.
3. Test the output by checking the FederalShipping directory to see if the shipping
acknowledgement appears.
Exercise 4: Use Direct Messaging Ports
Overview
In this part you will create a dynamic shared port between the two orchestrations. This will
continue to use a publish and subscribe model of messaging, but will not require that
messages be passed through an external intermediary like the file system used in the first
part of the lab. The messaging will all be done at the message box layer.
Configure a Dynamic Port

In this section, you will change the shipping request and acknowledgment ports to a single
dynamic port
Procedure List
2. Delete the ShippingPort and ShippingpAckPort from the design surface.
3. In the orchestration view, under the Types heading, delete the
ShippingAckPortType and ShippingPortType.
4. Right-click on the right-hand port surface, and click New Configured Port, and then
click Next.
5. In the Name box enter ShippingPort and then click Next.
6. Click Create a new port type, and in the Port Type Name box, enter
ShippingPortType, then click Request-Response, and then click Next.
7. On the port binding page, in the Port direction of communication list, click I’ll be
sending a request and receiving a response, then in the Port binding list, click
Direct.
8. Click the radio button labeled To send messages to other orchestrations, select this
port here and in those orchestrations.
9. From the drop down, choose the Northwind.Orchestrations.RouteOrder.
ShippingPort, then click Next, and then click Finish.
10. In the orchestration view, delete the ShippingCorrelation and
ShippingCorrelationType.
You won’t need these correlation items now that you will be using direct
messaging. The messages will be correlated based on internal correlation values
leveraging the port information and orchestration instance ids.
11. Use the green connection points to hook the SendShipRequest and
ReceiveShipAcknowledgement shapes to the new port.
12. Build the solution and fix any problems.
Update the Shipping Orchestration to Use the Dynamic Port
Procedure List
1. Open the Shipping orchestration
2. Delete the ReceiveShippingRequestPort and ShipAckPort ports from the design
surface.
3. From the orchestration view, delete the ReceiveShippingRequestPortType and
ShipAckPortType
4. Right-click on the left-hand port surface, and click New Configured Port, and then
click Next.
5. In the wizard, name the port RequestShippingReceivePort, and then click Next.
6. For the port type, choose to use the existing
Northwind.Orchestrations.ShippingPortType.
7. In the port binding page of the wizard, specify that you will be receiving and then
sending, and choose Direct for the port binding.
8. Click the radio button labeled To receive messages from other orchestrations,
select this port here and in those orchestrations.
9. From the drop down, choose: Northwind.Orchestrations.RouteOrder. ShippingPort,
10. In the orchestration designer, drag the connection points from the new port to the
receive and send shapes appropriately.
11. Your completed orchestration should look similar to the following:
12. Build your solution and fix any compiler errors.
14. Test by dropping the OrderExternal.xml file into the
15. Check the c:\AllFiles\LabFiles\Ports\Shippers\FederalShipping directory for the
output.
Course Evaluation
Your evaluation of this workshop will help Microsoft understand the quality of your learning
experience.
Please work with your training provider to access the workshop evaluation form.
Microsoft will keep your answers to this survey private and confidential and will use your
responses to improve your future learning experience. Your open and honest feedback is
very valuable.
Module 16: Integrating with the WCF LOB
Adapter Framework (Optional)
Module objective:
This module explains how take advantage of the WCF LOB Adapter SDK to expose Line of
Business (LOB) systems as WCF services.
Module Overview
Today’s applications require business data and logic that is distributed across several
applications or servers. Unfortunately, not all systems provide the same interface to their
data and business logic which ultimately forces developers to figure out how to talk to each
of those systems. Developers have to deal with network protocols, different message
formats, varying security mechanisms, and in many cases custom libraries that rely on
proprietary mechanisms. In the end, it’s common for developers to struggle with learning a
variety of different programming interfaces, communication protocols, and messaging
semantics.
By using the WCF Line of Business (LOB) Adapter SDK to build an adapter, any LOB system
can be exposed as a WCF service and consumed by any WCF client application as if it were a
traditional WCF service found on the network somewhere.
Lesson 1: Introduction to the WCF Line of Business (LOB)
Adapter Framework
Lesson objective:
This lesson explains what the WCF LOB Adapter Framework is, and why you might want to use it.
Lesson Overview
The goals addressed by WCF are very similar to the integration goals of Microsoft BizTalk
Server. Ultimately BizTalk Server is focused on providing an easy-to-manage model for
connecting disparate, heterogeneous systems using a variety of different protocols, message
formats and security mechanisms without requiring much, if any, code.
This lesson introduces the WCF LOB Adapter SDK, and it explains why you might want to use
it.
Why Use the WCF LOB Adapter Framework?
Explain the role that the WCF LOB Adapter Framework plays in enterprise integration scenarios.
Overview
With the WCF adapters in BizTalk Server, you can consume any LOB application that has
been service-enabled. This means that someone has already gone to the effort to expose the
LOB functionality through a service façade that provides WSDL and XSD metadata to simplify
client consumption. Assuming this is the case, you can easily use the built-in WCF adapters
to consume the service-enabled LOB application. If not, you’ll first need to service-enable
the LOB application before you’ll be able to consume it. The process of service-enabling is
becoming a more common task throughout enterprises today.
One of the challenges many organizations run into while service-enabling applications is
figuring out how to effectively expose metadata to the consumer. Some applications expose
such a vast underlying data source, it would be impossible to serve up a single WSDL
definition describing everything it can do (e.g., think about what it would be like to write a
WSDL definition for everything found in your SQL Server databases). In situations like this, it
probably makes more sense to ask the consumer “what data” they’re interested in up front
and generate specialized metadata files for that particular usage.
Because these service-enablement challenges are so common throughout enterprises,
Microsoft decided to introduce the WCF LOB Adapter SDK. The WCF LOB Adapter SDK
provides a simplified and unified model for creating custom BizTalk adapters that can be
used from any WCF client application including, but not limited to, BizTalk Server. The SDK
makes it much easier to provide metadata-driven adapters that can embrace native LOB
protocols and formats when necessary.
What Is the WCF LOB Adapter Framework?
Explain what the WCF LOB Adapter SDK provides
Overview
The WCF LOB Adapter SDK is a set of tools and components for creating adapters based on
the WCF channel programming model. The SDK includes a set of runtime components as
well as design-time tools and interfaces that simplify the process of hosting or consuming
adapters built with the SDK. By using the SDK to build an adapter, any LOB system can be
exposed as a WCF service and consumed by any WCF client application as if it were a
traditional WCF service found on the network somewhere.
Much like the BizTalk adapter programming model that preceded it, the WCF LOB Adapter
SDK provides a programming model that allows developers to focus primarily on the issues
specific to communicating with a given application without having to worry about all the
details of writing WCF components. Instead of programming against the WCF channel
model, developers write their adapters against a simpler set of API’s that focus on
connecting to and interacting with the target system.
An adapter built with the SDK is packaged and exposed to WCF as a binding that can be
configured for a given client or service endpoint. This provides a very simple abstraction for
developers to use when using the adapter.
Outbound Adapter Architecture
To understand how an outbound WCF LOB adapter fits in to an integration scenario.
Overview
When a WCF LOB outbound adapter is hosted in the client process, the client application
creates an instance of a WCF proxy configured to use the adapter binding. The act of
creating the proxy initiates the adapter in the client process. When the adapter is being used
for request/response communications, the client application triggers the adapter logic by
attempting to call an operation on the proxy, thus sending a message through the WCF
binding to the adapter, which then makes the corresponding API calls to the LOB system.
When the WCF LOB outbound adapter is hosted on a server, the adapter code is hosted in IIS
or Windows Process Activation Service (WAS) and is accessed by clients through WCF.
Essentially, the client channel for the adapter is taken and exposed as a WCF service using
standard bindings such as the BasicHttpBinding or WSHttpBinding to make it accessible to
more clients and tools. Using this hosting model, the LOB adapter truly becomes just
another WCF service that client applications can call and interact with. Hosting adapters in
IIS/WAS creates a WCF service endpoint that exposes a set of operations from the LOB
system.
Inbound Adapter Architecture
To understand how an inbound WCF LOB adapter fits in to an integration scenario.
Overview
When an adapter will be used in an inbound capacity, that is, when it will be receiving
messages from an LOB system and delivering them to the client process, the adapter needs
to be hosted in a listening mode. The solution is for the client process to use the ServiceHost
class to create an instance of the generated proxy class and create an endpoint using the
appropriate binding for the LOB System. After the LOB system contacts the client process,
the implementation of the contract will execute in the client process.
Demonstration: Consuming a WCF LOB Adapter Service
Learn to configure common properties of a WCF LOB adapter.
Consume a Custom WCF LOB Adapter Service

1. Open C:\AllFiles\DemoCode\Module16\NorthwindLOBAdapter.sln.
2. Right-click the NorthwindLOBAdapter Solution, and then click Rebuild Solution.
3. Right-click the ClientApplication project, and then click Add Adapter Service
Reference.
4. In the Add Adapter Service Reference dialog box, click Select a binding.
5. Notice the different adapter bindings that are listed.
Since the BizTalk Adapter Pack has been installed on this virtual machine, the list
of bindings includes those for Oracle Databases, Oracle eBusiness Suite, SAP and
SQL Server. The nwBinding is for the custom WCF LOB Adapter that we will
consume in this demonstration.
6. Click nwBinding, and then click Configure.
7. Click the URI properties tab, and in DataDirectory box, type
C:\AllFiles\DemoCode\Module16.
This custom adapter uses the path specified by the DataDirectory property to
locate a pair of XML files that contain lists of current discount and surcharge
codes. The adapter will read data from the XML files to simulate calls to an LOB
system.
8. Click Binding Properties tab, and in the CacheDurationMinutes box, enter 15.
The CacheDurationMinutes is a custom property that is implemented in the
application code for this adapter. The remaining properties in this grid are
implemented by the WCF LOB Adapter Framework.
9. Click OK, and then click Connect.
10. In the Select contract type list, click Service (Inbound operations).
Notice that this adapter does not implement any inbound operations.
11. In the Select contract type list, click Client (Outbound operations).
This adapter only implements outbound capabilities. It can issue calls to the
(simulated) LOB system, but it does not have the capability to handle calls
coming from the LOB system.
12. In the Select a category tree, click Discount listings, and notice that the List
Discounts operation is shown in the Available categories and operations list.
13. In the Select a category tree, click Surcharge listings, and notice that the List
Surcharges operation is shown in the Available categories and operations list.
14. Click the List Surcharges operation and then click Add.
15. In the Select a category tree, click Discount listings, and in the Search in category
box, type list, and then click the Go button (the green icon with an arrow).
Notice that the search did not find any additional metadata for the Discount
listings category.
16. In the Select a category tree, click “/” and then click the Go button.
Clicking on the root node widened the scope of the search to include both the
Discount listings category and the Surcharge listings category. The adapter
searched the metadata of the selected node and all of its child nodes.
17. In the Available categories and options list, click List Discounts and then click Add.
18. Click Advanced options.
Notice the additional options that are available, including asynchronous
methods.
19. Click Cancel.
20. In the Add Adapter Service Reference dialog box click OK.
Test the WCF Client

1. Open the NorthwindLOBAdapterBindingClient.cs file.
Notice that this is simply standard WCF client proxy code.
2. In the Window1.xaml.cs file, uncomment the code inside of the button1_Click and
button2_Click methods.
This code uses the generated WCF proxy class to connect to the Northwind LOB
adapter, retrieve the data and display it in the UI.
3. Right-click the ClientApplication project, and then click Set as Startup Project.
4. Press CTRL+F5 to run the application.
5. In the Northwind LOB Adapter Client App window, click Get discounts, and verify
that it receives and displays a list of discount codes from the LOB adapter.
6. Click Get surcharges, and verify that it receives and displays a list of surcharge codes
from the LOB adapter.
7. Close all windows, and pause the bt10d-demos virtual machine.
Lesson 2: Creating a WCF LOB Adapter
Lesson objective:
To understand how to implement the classes that are required to create a WCF LOB Adapter.
Lesson Overview
For adapter developers the SDK simplifies the job of encapsulating the communication
semantics for a particular LOB system. The goal of the adapter model has always been to
write the adapter once and enable a broad range of processes to interact with the target
system. The main difference now is the use of WCF as the underlying implementation
framework. In addition, the SDK greatly simplifies the process of exposing metadata to client
applications so developers don’t have to understand WSDL very deeply.
When you build LOB adapters with the WCF LOB Adapter SDK, you are actually building a
custom transport channel for WCF. However, the WCF LOB Adapter SDK extends and
abstracts the WCF messaging layer and makes this much easier to accomplish. It provides a
simplified set of interfaces focused on creating connections and handling messages,
shielding you from most of the low-level channel details. This abstraction helps developers
focus primarily on the issues of connecting to the LOB system and translating between WCF
messages and LOB API calls.
You expose your custom adapter (transport channel) like you would any custom transport
channel – by creating custom binding and binding element implementations for others to
use. After the adapter is packaged, any WCF client can create a client proxy using the binding
you’ve provided and invoke operations on it without worrying about the underlying
communication details. However, in order to generate a client proxy that provides an
appropriate contract, the client needs a mechanism to retrieve metadata from the adapter
as well. This is where the WCF LOB Adapter SDK provides an extremely rich model for
exposing metadata from LOB systems without having to manipulate or work with WSDL.
There are three main areas you’ll need to focus on during the implementation process:
metadata support, connection management and message handling.
Adapters expose metadata so that client applications can choose the operations they
require to interact with the LOB system and can build a client proxy that reflects only those
operations. When building the adapter, it’s the responsibility of the developer to implement
the metadata retrieval process.
Adapters can support metadata browsing through a hierarchical representation of the
exposed operations as well as metadata search functionality. Search functionality is
especially important if your LOB system supports a larger number of operations and you
want to make it easier for someone to find the specific operation they need. Finally,
adapters must provide support for metadata resolution which involves handling requests to
resolve type names to metadata describing the types.
As for the runtime components, there are two primary functions developers must
implement in an adapter: connection management and message handling. Connection
management involves being able to create instances of an object that represents a
connection to your LOB system. The connection class is responsible for managing the
opening and closing of connections to the LOB system much like a SQLConnection instance is
responsible for opening and closing connections to a database. The framework provides
most of the supporting connection management infrastructure you’ll need (such as
connection pooling) but it relies on the adapter to manage the LOB-specific connection
object.
Message handlers provide the actual processing of runtime messages and how they
translate to calls in the LOB application. When creating an adapter, the developer chooses
the message exchange patterns that will be supported by the adapter and the appropriate
synchronous/asynchronous interfaces required to support them. Message handlers include
both inbound and outbound handlers
Visual Studio WCF LOB Adapter Project Template
Describe the WCF LOB Adapter Development Wizard.
Overview
The WCF LOB Adapter SDK includes a Visual Studio project template for creating new
adapters. The template uses a wizard to ask you for some basic information about the new
adapter and then it creates the project and classes based on that information.
The wizard starts by collecting information on namespaces and the protocol scheme that will
be used in endpoint addresses. The next step is to specify the message exchange patterns
(MEPs) and the type of metadata support that the adapter will provide.
For metadata you can choose to support browse and/or search and you will have to
implement the resolve. There are a few different message exchange pattern options
including inbound versus outbound and synchronous versus asynchronous.
In the final two steps, the wizard allows you to specify properties that will be available on
the adapter (the binding) and properties needed to implement the connection such as a
server name, port, etc.
After you’ve completed the wizard, the project template generates a number of classes to
support the choices you selected. Some the classes defined in the solution are complete and
ready to use straight-away while others are left to the developer to fill in the
implementation.
Defining a URI
Explain the purpose of the ConnectionUri class.
Overview
The generated project contains three classes related to connection management: a
connection class, a connection factory class and a connection URI class. The connection URI
class requires you to implement Uri parsing logic to move between the typed properties for
your connections and the way those properties are formatted into the Uri string.
Managing Connections
Explain the purpose of the Connection and ConnectionFactory classes.
Overview
The connection factory class has a default implementation that will create connections when
requested by the Adapter SDK runtime – you don’t have to do anything with this one. The
connection class itself is where most of the connection management takes place, and where
you’ll write the LOB-specific connection code.
In the connection class, you’re responsible for managing the opening and closing of
connections to the LOB system. In addition, the connection class has a ClearContext method
that can be implemented to prepare a connection object to be put back in the pool. Finally,
you can implement the IsValid method to return a status indicating whether the open
connection is in a valid state or not.
Reading Adapter Configuration Settings
Explain the purpose of the Adapter class.
Overview
The Adapter class and four binding-related classes are generated to provide the WCF
packaging that makes the adapter easy to use. It provides a binding class, a binding element,
and a binding element extension that make it easy to use the new custom adapter. These
binding classes are preconfigured to expose the adapter properties supplied in the new
project wizard all the way from the configuration up to the adapter class itself.
Creating an Outbound Adapter
Explain the purpose of the OutboundHandler class.
Overview
Message handlers provide the actual processing of runtime messages and how they
translate to calls in the LOB application. When creating an adapter, the developer chooses
the message exchange patterns that will be supported by the adapter and the appropriate
synchronous/asynchronous interfaces required to support them. Message handlers include
both inbound and outbound handlers.
The outbound handler simply has an Execute method on it which receives a WCF message
object and is expected to return a WCF message object. The Execute method is where the
adapter runtime behavior is focused, and it is where the real communication with the LOB
system happens.
Creating an Outbound Adapter
Explain how a client calls an outbound adapter to interact with an LOB system..
Overview
After the outbound adapter is deployed, client applications can make calls to the adapter to
interact with the LOB system. On the client-side, the messages pass through the WCF client
side messaging layer to the adapter, which is loaded in the transport channel.
Instead of invoking a remote WCF service, however, the adapter code interacts directly with
the LOB system and the reply, if any, is returned back through the messaging layer to the
client code.
It is fairly straightforward to write the client-side code to call the OutboundHandler:
1. Create an instance of the adapter’s binding class.
2. Use the binding object to create a WCF channel factory.
3. Use the channel factory object to create a new WCF channel with an endpoint
address.
4. Create a WCF message object.
5. Issue the service call through the channel object
6. Process the response message
In practice, developers simply use the WCF proxy code that is generated by adding an
Adapter Service Reference in Visual Studio.
Creating an Inbound Adapter
Describe how an inbound WCF LOB adapter works.
Overview
When an adapter will be used in an inbound capacity, that is, when it will be receiving
messages and delivering them to the client process, the adapter needs to be hosted in a
listening mode. An inbound adapter is a WCF channel listener. The solution is for the client
process to use the ServiceHost class to create an instance of the generated proxy class and
create an endpoint using the appropriate binding for the LOB System. After the LOB system
contacts the client process, the implementation of the contract will execute in the client
process.
Creating an Inbound Adapter
Explain the purpose of the InboundHandler class..
Overview
For inbound adapters, you must implement four methods of the InboundHandler class,
which will be called by the adapter framework runtime. You must implement StartListener
and StopListener to start and stop whatever specific mechanism the adapter is using to
receive messages.
The other two operations that you must implmement on an inbound handler are
WaitForMessage and TryReceive. The WaitForMessage should listen or poll for an inbound
WCF message from the target LOB system, and it should return true when it detects that a
message is ready to be received. The TryReceive method should attempt to read the
message, which will be passed back to the adapter framework to complete the remainder of
the inbound processing.
Demonstration: Creating a Custom WCF LOB Adapter
Demonstrate how to implement a custom WCF LOB Adapter
Create a new WCF LOB Adapter Project

2. Launch a new instance of Visual Studio 2010.
3. On the File menu, click New, and then click Project.
4. In the New Project dialog box, in the left pane click Visual C#, then in the center
pane click WCF LOB Adapter.
5. In the name box enter DemoAdapter.
6. In the Location box enter C:\AllFiles\DemoCode\Module16\, and then click OK
7. On the Welcome page of the WCF LOB Adapter Development Wizard, click Next.
8. On the Scheme, Namespace and URI page, in the Scheme box enter nw.
9. In the Project namespace box, enter northwind.
If you wanted to change the WCF service namespace, you could check the
Overwrite default service namespace box, and type a value in the Service
namespace box.
10. Click Next.
11. On the Data flows page, check the All box, the Retrieval box, the Browse box and
the Search box, and then click Next.
With these options selected, the wizard will generate code to help you
implement synchronous and asynchronous methods for processing both inbound
and outbound messages. It will also generate code to help you implement
metadata browse and search features which will be covered later in this module.
12. On the Adapter Properties page, in the Property name box, type CacheDurationMin.
13. In the Default value box enter 20, then click Add, and then click Next.
Properties defined on this page apply to the basic capabilities of the adapter.
14. On the Connection Properties page, in the Property name box, enter DataDirectory.
15. In the Data type list, click System.String, and then click Add.
Properties defined on this page are used to configure the connection between
the custom adapter and the LOB system.
16. Click Next.
17. Review the information on the Summary page, and then click Finish.
Examine the Generated Code

1. Notice that the new DemoAdapter project contains a number of C# class files.
Fortunately, if you answered everything correctly in the wizard, then you will
only need to edit a few of these files
2. Open the DemoAdapterBindingElement.cs file, and find the CacheDurationMin
property.
This is the property that you specified in the wizard. Notice that
CacheDurationMin will be read from an XML configuration file, as indicated by
the [ConfigurationProperty] attribute. Its value defaults to 20.
3. Open the DemoAdapterTrace.cs file.
You can use the static Trace property of this class to write diagnostic messages
out to trace listeners that are registered to pick them up.
4. Open the DemoAdapterAsyncOutboundHandler.cs file, and locate the Execute
method.
Notice that the Execute method accepts a WCF message, and it returns a WCF
message.
You can implement the BeginExecute and EndExecute methods to support
asynchronous processing against your LOB system.
5. Close the solution.
Examine Completed Connection and ConnectionUri Classes

1. Open C:\AllFiles\DemoCode\Module16\NorthwindLOBAdapter.sln
2. Open the NorthwindLOBAdapterConnection.cs file, and review the code.
The connection class is responsible for Opening, Closing and Aborting
connections to the LOB, and for reporting the status of the connection. It’s also
the class that will create an instance of the appropriate handler class when the
framework requests one.
3. Open the NorthwindLOBAdapterConnectionUri.cs file, and find the constructor.
Notice that the constructor initializes the URI property, and notice that URI
Property extracts the DataDirectory from the URI value.
Examine a Completed AsyncOutboundHandler Class

1. Open the NorthwindLOBAdapterAsyncOutboundHandler.cs file.
This class is responsible for handling the communicating with the adapter’s LOB
system via a connection object to query, insert, update or delete data.
2. Expand the Execute method.
The Execute method for this adapter uses a switch statement to determine which
operation should be executed, and then it makes the appropriate method call to
retrieve the requested data from the simulated LOB.
3. Expand the CreateDiscountListMessage method.
This method takes a connection from the adapter’s connection factory and uses
it to determine the data directory that is configured for this adapter.
It then opens the Discounts.xml file, and creates a response message containing
the list of discount codes.
Examine the Adapter Deployment

1. Right-click the NorthwindLOBAdapter project, and then click Properties.
2. Click the Signing tab, and notice that this project has been assigned a key.
Adapters must be deployed to the GAC in order to work the WCF LOB Adapter
Framework.
3. In Solution Explorer, double-click MachineConfigEntries.xml.
These entries have been added to the machine.config files in the following
folders
C:\Windows\Microsoft.NET\Framework\v4.0.30319\config
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\config
These entries, however, would need to be inserted in the machine.config files of
any machine that would host this adapter.
Test the Adapter
1. Open NorthwindLOBAdapterAsynOutboundHandler.cs, locate the
CreateSurchargeListMessage method and set a breakpoint on it.
2. Locate the CreateDiscountListMessage method and set a breakpoint on it also.
3. Right-click on the NorthwindLOBAdapter project, and then click
NorthwindLOBAdapter.
4. Press F5 to start the client app in the debugger.
5. In the Northwind LOB Adapter Client App window, click the Get discounts button.
6. When execution stops on the breakpoint on the CreateDiscountListMessage, press
F10 to step through the code, or press F5 to continue execution.
7. In the Northwind LOB Adapter Client App window, click the Get surcharges button.
8. When execution stops on the breakpoint on the CreateSurchargesListMessage,
press F10 to step through the code, or press F5 to continue execution.
9. Close the Northwind LOB Adapter Client App window.
10. In Visual Studio, on the Debug menu, click Stop Debugging.
11. Close all open windows, and pause the bt10d-demos virtual machine.
Publishing Metadata
Explain the benefits of implementing metadata publication in a custom WCF LOB Adapter.
Overview
Adapters can expose metadata so that client applications can choose the operations they
require to interact with the LOB system and can build a client proxy that reflects only those
operations.
The WCF LOB Adapter SDK provides a programming model that makes it possible for adapter
developers to expose custom metadata from the adapter, so when the adapter is being
consumed, a developer can choose which operations are important and only receive
metadata for the chosen operations.
When building the adapter, it’s the responsibility of the developer to implement the
metadata retrieval process. Adapters can support browsing or searching through the
metadata in order to find the operations of interest.
Publishing Metadata
Explain the options available for publishing LOB system metadata with the WCF LOB Adapter
SDK.
Overview
Adapters can support metadata browsing through a hierarchical representation of the
exposed operations as well as metadata search functionality. Search functionality is
especially important if your LOB system supports a larger number of operations and you
want to make it easier for someone to find the specific operation they need. Finally,
adapters must provide support for metadata resolution which involves handling requests to
resolve type names to metadata describing the types.
Metadata support is found in three files including one for browsing support, one for search
support, and a final class for resolving metadata types. The browse and search classes each
have one method to implement returning an array of MetadataRetrievalNode objects
representing the operations that can be performed on the adapter. These nodes are simply
definitions of named items that can be shown to a developer using the adapter – this is
where you’ll need to do your mapping to the LOB system. The metadata resolver is
responsible for resolving metadata identifiers to operation descriptions.
In addition to resolving operation metadata, the resolver class is responsible for handling
generation of metadata for types that will be exposed from the system. For a given
operation, there may complex types that make up the parameters or the return types. These
types must also be resolved and described using the metadata classes so they can be used in
the generation of WSDL and consumed by users.
Demonstration: Implement Metadata Browse and Search
Learn how to implement a metadata browse and search capabilities.
Examine an Implementation of Metadata Browse

2. Open C:\AllFiles\DemoCode\Module16\NorthwindLOBAdapter.sln
3. Open the NorthwindLOBAdapterMetadataBrowseHandler.cs file.
4. Locate the Browse method, and notice the method signature.
The first parameter, NodeId, indicates the node in the tree view that is being
populated (i.e. the node that the user clicked in the Select a category tree in the
Add Adapter Service Reference dialog box). The remaining parameters specify
constrains on the response message.
The Browse method returns an array of MetadataRetrievalNodes, which simply
hold names of LOB service operations and categories. The
MetadataRetrievalNodes are displayed in the Select a category tree, and in the
Available categories and operations list in the Add Adapter Service Reference
dialog box.
5. Open the NorthwindLOBAdapterMetadataResolverHandler.cs file.
6. Locate the ResolveOperationMetadata method, and notice the method signature.
The first parameter, operationId, contains the name of the operation that has
been selected by the client.
This method is responsible for returning an OperationMetadata object
containing the metadata that describes the operation’s parameters , return type
and other details.
Since LOB systems change over time, some adapters are implemented to connect
to their corresponding LOB system to find the latest metadata for an operation
before creating the OperationMetadata object.
Browse the Custom Adapter Metadata

Reference.
2. In the Add Adapter Service Reference dialog box, ensure that nwBinding is selected
in the Select a binding list.
3. Ensure that the Configure a URI box contains C:\AllFiles\DemoCode\Module16
4. Click Connect.
5. Ensure that Client (Outbound operations) is selected in the Select contract type list.
6. In the Select a category tree, click Discount listings, and notice that the List
Discounts operation is shown in the Available categories and operations list.
7. In the Select a category tree, click Surcharge listings, and notice that the List
Surcharges operation is shown in the Available categories and operations list.
8. In the Select a category tree, click “/” and notice that the Available categories and
operations list displays the Discount listings and Surcharge listings categories.
9. Click Cancel.
Examine an implementation of Metadata Search

1. Open the NorthwindLOBAdapterMetadataSearchHandler.cs file.
2. Locate the Search method, and notice the method signature.
The first parameter, nodeId, indicates the node in the tree view that is being
searched (i.e. the node that the user clicked in the Select a category tree in the
Add Adapter Service Reference dialog box). The second parameter contains the
search term, and the remaining parameters specify constrains on the response
message.
The Search method also returns an array of MetadataRetrievalNodes that
match the search criteria. The MetadataRetrievalNodes are used to populate
the Available categories and operations list in the adapter configuration UI.
Search the Custom Adapter Metadata

Reference.
2. In the Add Adapter Service Reference dialog box, ensure that nwBinding is selected
in the Select a binding list.
3. Ensure that the Configure a URI box contains C:\AllFiles\DemoCode\Module16
4. Click Connect.
5. Ensure that Client (Outbound operations) is selected in the Select contract type list.
6. In the Select a category tree, click Discount listings, and in the Search in category
box, type list, and then click the Go button (the green icon with an arrow).
Notice that the search did not find any additional metadata for the Discount
listings category.
7. In the Select a category tree, click “/” and then click the Go button.
Clicking on the root node widened the scope of the search to include both the
Discount listings category and the Surcharge listings category. The adapter
searches the metadata of the selected node and all of its child nodes.
8. Click Cancel.
Lesson 3: The BizTalk Adapter Pack
Lesson objective:
Introduce the BizTalk Adapter Pack, and describe how it can be used.
Lesson Overview
Correlation addresses the issue of handling subscriptions when an orchestration needs to
process messages that are related to one another. Correlation was introduced in Module 9,
Automating Business Processes.
Simple correlation, however, is not sufficient in all cases. It is possible to encounter
situations in which simple correlation breaks down, and the runtime needs to step in and
coordinate at a higher level. This lesson covers these special cases, which are known as
convoys.
What is the BizTalk Adapter Pack?
Describe the BizTalk Adapter Pack
Overview
Microsoft has built and shipped a suite of WCF LOB adapters using the WCF LOB Adapter
SDK. This suite of LOB adapters is referred to as the BizTalk Adapter Pack. The BizTalk
Adapter Pack contains several WCF LOB adapters for some popular LOB systems.
Because of the open architecture of the WCF LOB Adapter framework, these adapters make
it possible to integrate with these LOB systems from any .NET application.
Line of Business Adapters
Describe the WCF LOB adapters that are in the BizTalk Adapter Pack.
Overview
Version 1 of the BizTalk Adapter Pack contains three adapters: Oracle Database, mySAP
Business Suite and Siebel eBusiness Applications.
Version 2 of the BizTalk Adapter Pack added two additional adapters: Oracle E-Business Suite
and SQL Server.
Lab: Applying the WCF LOB Adapter Framework
Overview
In this lab you’ll be using the WCF LOB Adapter SDK to build an “Adapter” which could be
used via a WCF Channel (inside or outside of BizTalk). After completing this lab, you should
understand how to create a WCF LOB Adapter using the WCF LOB Adapter SDK, use a WCF
Adapter and how to create a listener with a WCF Adapter. Using the WCF-Custom adapter,
you could invoke operations on the services from BizTalk as well.
Procedure List
window.
Start.
Exercise 1: Create a WCF LOB Adapter Framework Project
Overview
In this part, you will use a project wizard in Visual Studio to generate adapter code that can
be customized to suit your needs. You will use the wizard to generate connection properties
that you can use in your adapter to customize the runtime behavior.
Create a New Visual Studio Solution

Procedure List
1. Open Visual Studio 2010.
2. On the File menu, select New -> Project.
3. Highlight the Visual C# node in the Installed Templates pane, and find the WCF LOB
Adapter template in the center pane.
4. Specify the Name and Location as follows, then click OK to close the dialog:
Property Value
Name ContosoCustomAdapter
Complete the Wizard

Procedure List
1. The WCF LOB Adapter Wizard will appear, read the introduction and press the Next
button.
2. On the next page, enter the Scheme and Project Namespace as follows and click
Next:
Property Value
Scheme Contoso
Project Namespace Contoso.CustomAdapter
3. On the Data flows page, select the checkboxes only for the synchronous data flows
and Metadata features so your dialog looks like this, and click Next:
This will create a project which allows all the different channel shapes as well as
enabling all metadata functionality.
4. On the Adapter Properties page, add the properties from the following table by
entering the information and clicking the Add button. Click the Next button when
you have completed.
Property Data Type Default Value
Transactional System.Boolean False
ListenerInterval System.Int32 5000
5. On the Connection Properties dialog, add a Connection Property of type

System.String, named UserName. Set the Default Value to "msmith".
6. Click Add, then the Next button.

7. Review the Summary Page, and then click the Finish button to generate the
Adapter.
Build the Solution

Procedure List
1. Right-click on ContosoCustomAdapter in the Solution Explorer and select Build.
2. Confirm a successful build in the Output window.
Exercise 2: Implement an Outbound Handler
Overview
In this part, you will implement the outbound capabilities of the adapter that you created in
Exercise 1.
Implement an Outbound Handler

Procedure List
1. Open the ContosoCustomAdapterConnectionFactory.cs file.
2. Add a private field of type ContosoCustomAdapterConnectionUri named uri.
3. Update the constructor to set the value of this field based on the constructor
parameters.
//stores the connection string
private ContosoCustomAdapterConnectionUri uri;
public ContosoCustomAdapterConnectionFactory(
ConnectionUri connectionUri,
ClientCredentials clientCredentials,
ContosoCustomAdapter adapter)
{
this.clientCredentials = clientCredentials;
this.adapter = adapter;
this.uri = (ContosoCustomAdapterConnectionUri)connectionUri;
}
4. Add a read-only property to the class to expose the uri.
public ContosoCustomAdapterConnectionUri ConnectionUri

{
get
{
return uri;
}
}
5. Open the ContosoCustomAdapterConnection.cs file.

6. Expand the hidden region marked IConnectionMembers.
7. In the Close, IsValid, and Open methods, remove the lines that throw a
NotImplementedException.
8. In the Open method, call Console.WriteLine and print out a string that indicates that
the connection object has been opened, indicating what the ServerName and
UserName properties of the connection are (these are properties on the
ConnectionFactory property of the Connection object).
ContosoCustomAdapterConnectionUri uri = null;
uri = this.ConnectionFactory.ConnectionUri;
Console.WriteLine(
"Connection object opened - ServerName = {0}, UserName = {1}",
uri.Uri.Host,
uri.UserName);
You typically would open the phyiscal connection to your LOB or database in the
Open method of the IConnection object. .
9. In the Close method, call Console.WriteLine and print out a string that indicates that
the connection object has been closed.
uri = this.ConnectionFactory.ConnectionUri as
ContosoCustomAdapterConnectionUri;
Console.WriteLine(
"Connection object closed - ServerName = {0}, UserName = {1}",
uri.Uri.Host,
uri.UserName);
10. In the IsValid method, return true

11. Open the ContosoCustomAdapterConnectionUri.cs file.
12. Add a private field of type UriBuilder named "uriBuilder".
13. Update the constructor which takes a parameter to initialize the UriBuilder you just
defined.
this.uriBuilder = new UriBuilder(uri);
14. Provide the implementation for the Uri property so that you parse the URI to find
the value for the username field:
public override Uri Uri

{
get
{
this.userName = this.uriBuilder.UserName;
return this.uriBuilder.Uri;
}
set
{
this.uriBuilder = new UriBuilder(value);
}
}
Write the Message Handling Code

Procedure List
1. In the adapter project, open the ContosoCustomAdapterOutboundHandler.cs file
and locate the Execute method.
2. Remove the line of code that throws a NotImplementedException.
3. Add code that prints out the body of the incoming Message.
Console.WriteLine("Incoming message {0}",

message.GetReaderAtBodyContents().ReadInnerXml());
4. After that code, add code that creates a new Message, with a MessageVersion of
MessageVersion.None, an action with a blank string, and a body of “A message from
a WCF Adapter”.
Message rm = Message.CreateMessage(
MessageVersion.None,
"",
"A message from a WCF Adapter");
return rm;
In a real implementation, this is where you would process the incoming message,
connect to your LOB application or database, and generate a proper return
message.
5. Build the project and verify that it compiles before moving on to the next Exercise.
Exercise 3: Create an Outbound Client
Overview
In this part, you will create a simple WCF client application to test the adapter that you
Create a New Console Application Project

Procedure List
1. In Solution Explorer, right-click the ContosoCustomAdapter solution, then click Add,
and then click New Project.
2. Select a Visual C# - Console Application as the project template type.
3. Name the project OutBoundClient. The default location should be fine. Click OK.
4. Right-click on the OutBoundClient project, click Properties, then in the Target
framework list, click .NET Framework 4, and then click Yes.
5. Right-click on the OutBoundClient project in the Solution explorer and select “Add
Reference”.
6. Add a reference to the following assemblies (found under the .NET tab), then click
OK:
Assembly Name
System.ServiceModel
System.Runtime.Serialization
Microsoft.ServiceModel.Channels
Reference”.
8. Add a reference to the ContosoCustomAdapter project (found under the Projects
tab). Click OK to close the dialog.
Implement the Program Logic

Procedure List
1. Open the Program.cs file in the OutBoundClient project.
2. Add a using statement for each of the following namespaces:
Namespace
Contoso.CustomAdapter
System.ServiceModel
System.ServiceModel.Channels
3. Inside of the Main method, create an instance of the
ContosoCustomAdapterBinding and set its Transaction property to true.
ContosoCustomAdapterBinding b = new ContosoCustomAdapterBinding();

b.Transactional = true;
4. Use the ConstosoAdapterBinding reference to create an IChannelFactory<> of type

IRequestChannel, and Open the channel factory object.
IChannelFactory<IRequestChannel> rcf =
b.BuildChannelFactory<IRequestChannel>();
rcf.Open();
5. Create a new Message with a MessageVersion of MessageVersion.None, an action

of a blank string, and the body of “Sending message to adapter”).
Message msg = Message.CreateMessage(

"",
"Sending message to adapter");
6. Create a new EndpointAddress object, specifying the URI

"Contoso://alice@contososervername" as the URI to the constructor.
EndpointAddress epa =
new EndpointAddress("contoso://alice@contososervername");
7. Ask the ChannelFactory to create a Channel of the type of IRequestChannel passing

in the EndpointAddress you just created, and open the channel.
IRequestChannel rc = rcf.CreateChannel(epa);
rc.Open();
8. Call IRequestChannel.Request, passing in the Message you just created, use the
return value to initialize a new Message reference, and print out to the console the
string value of this message.
Message rmsg = rc.Request(msg);
Console.WriteLine("Adapter response message: {0}",
rmsg.GetReaderAtBodyContents().ReadInnerXml());
9. Build, and compile. Run once using Ctrl-F5 to verify the output to the console is
correct. Then set breakpoints in the methods you just implemented and run again –
this time using F5, so you can step through the interaction of the client to the
adapter.
Exercise 4: Building an Inbound Handler
Overview
In this part, you will implement the inbound capabilities of the adapter that you created in
Exercise 1.
Setup the Handler

Procedure List
1. In the ContosoCustomAdapter project, open the
ContosoCustomAdapterInboundHandler.cs file.
2. Expand the hidden region named IInboundHandler Members.
3. Remove the lines of code that throw the NotImplementedException in the
StartListener, StopListener, TryReceive, and WaitForMessage methods.
4. Add a using statement for System.Threading and System.ServiceModel.Channels to
the top of the ContosoCustomAdapterInboundHandler.cs file.
5. Add a field named _messages of type Queue<Message> to the
ContosoCustomAdapterInboundHandler class.
Queue<Message> _messages = new Queue<Message>();
6. Inside of the StartListener method, add code that starts a Timer and adds a new
Message to _messages field every time the Timer hits.
int interval =
this.Connection.ConnectionFactory.Adapter.ListenerInterval;
Timer t = new Timer(delegate

{
Console.WriteLine("Timer hit");
lock (_messages)
{
Message msg = Message.CreateMessage(MessageVersion.None,
"Test", "Test");
Console.WriteLine("Got a message");
_messages.Enqueue(msg);
Monitor.PulseAll(_messages);
}
}, null, 0, interval);
Console.WriteLine("Listening");
In a real implementation, this is where you would be connecting to your

LOB/database and looking for new messages to consume. This is your
“listening” functionality. A common implementation would be to use a timer,
but depending on your listening functionality your InboundHandler will be
different depending on what your Adapter is connecting to. In this case there
isn’t any implementation, however in a real implementation this is where you
would stop the listening functionality you started in StartListener. In this case,
the anonymous delegate will stop when the class is disposed.
7. Inside of the WaitForMessage method, add the code below. This is the first method
that will be called by the listening infrastructure. Return true here when there are
messages to process.
lock (_messages)
{
if (_messages.Count > 0)
{
return true;
}
return Monitor.Wait(this._messages,
timeout.TotalMilliseconds >= Int32.MaxValue ?
Int32.MaxValue : (int)timeout.TotalMilliseconds);
}
The purpose of this code is to see if there any messages in the queue (locking the
queue first). It returns true if there are messages to receive. Then it waits the
appropriate Timeout value. It will return true if the Monitor gets the lock on the
_message field within the timeout. The call to Monitor.PulseAll in the timer
delegate will cause this to happen if a message is received (which in this
implementation is a certainty).
8. TryReceive is what will be called repeatedly by the WCF infrastructure over and over
once WaitForMessage returns true.
reply = new ContosoCustomAdapterInboundReply();
Console.WriteLine("TryReceive....");
lock (_messages)
{
if (!this.WaitForMessage(timeout))
{
message = null;
return false;
}
message = _messages.Dequeue();
}
return true;
The InboundReply object is built to be able to encapsulate the creation of the
outgoing WCF message. In this implementation we are using a one-way
contract, so that isn’t necessary. In a real implementation, you’d need to fill out
the InboundReply class’ methods.
9. Build the solution, and make sure it compiles successfully.

Exercise 5: Building an Inbound Listener
Overview
In this part, you will build an application to host your adapter while it listens for incoming
messages. The application is a simple console application which creates an instance of your
adapter and hosts it as a WCF service.
Create the Application

Procedure List
10. In Solution Explorer, right-click the ContosoCustomAdapter solution, then click Add,
and then click New Project.
12. Name the project InboundClient. The default location should be fine. Click OK.
13. Right-click on the InboundClient project, click Properties, then in the Target
1. Right-click on the InboundClient project in the Solution explorer and select “Add
Reference”.
2. Add a reference to the following assemblies (found under the .NET tab):
Assembly Name
System.ServiceModel
Reference”.
4. Add a reference to the ContosoCustomAdapter project (found under the Projects
tab). Click OK.
Namespace
System.ServiceModel
Create a Service Contract
Procedure List
1. Inside of Program.cs (but outside of the Program class) create an interface. Name it
IOneWay. Add the ServiceContract attribute to this interface.
2. Add a method to this interface and name it OneWayMethod. Have it take a single
parameter of type Message and return void. Add the OperationContract attribute
to the OneWayMethod, with Action as a wildcard value (“*”) and IsOneWay equal
to true.
[ServiceContract]
public interface IOneWay
{
[OperationContract(Action="*",IsOneWay=true)]
void OneWayMethod(Message inmsg);
}
3. Inside of Program.cs (but outside of the Program class) create a class. Name it
OneWay. Have the OneWay class implement the IOneWay interface. Inside of the
OneWayMethod write the string value of the Message out to the console.
public class OneWay : IOneWay

{
public void OneWayMethod(Message inmsg)
{
Console.WriteLine("Received a message {0}",
inmsg.GetReaderAtBodyContents().ReadInnerXml());
}
}
4. Inside of the Main method in the Program class, create a ConstosoAdapterBinding

and set the Transactional property to true, and the ListenerInterval to 5000.
ContosoCustomAdapterBinding b = new ContosoCustomAdapterBinding();

b.ListenerInterval = 5000;
5. Create a ServiceHost, pass the OneWay type as the parameter to the ServiceHost
constructor.
ServiceHost sh = new ServiceHost(typeof(OneWay));

6. Call ServiceHost.AddServiceEndpoint, specifying the IOneWay interface as the
contract, the ContosoCustomAdapterBinding as the binding, and
"contoso://alice@contososervername" as the address.
sh.AddServiceEndpoint(
typeof(IOneWay),
b,
"contoso:// alice@contososervername");
7. Call Open on the ServiceHost.
sh.Open();
Test the Solution

Procedure List
1. Write a message to the Console that the Service is up and running, and then add call
to Console.ReadLine to keep the process open.
Console.WriteLine("Service up and running - press enter to exit");

Console.ReadLine();
2. Run once using Ctrl-F5 to verify the output to the console is correct. Then set
breakpoints in the methods you just implemented and run again – this time using F5,
so you can step through the interaction of the client to the adapter. Stop the
command windows when you are satisfied your service is receiving messages.
Module 17: WF and WCF Interceptors for
BAM (Optional)
Module objective:
In this module, you will learn how to configure BAM interceptors for WF and WCF
applications to enable BAM tracking without recompiling your WF or WCF solution.
Module Overview
In BizTalk Server 2010, BAM is a collection of tools, APIs, and services that allow you to
manage aggregations, alerts, and profiles. With BAM you can also instrument automated
processes to send events to monitor relevant business metrics. Together, these provide end-
to-end visibility into a business process.
The WF and WCF BAM interceptors extend the BAM functionality of BizTalk Server into the
Windows Workflow Foundation (WF) the Windows Communication Framework (WCF)
runtimes.
Lesson 1: BAM Interceptor Architecture
Lesson objective:
This lesson will introduce the WF and WCF Interceptors for BAM.
Lesson Overview
This lesson introduces the WF and WCF Interceptors for BAM, and it explains how to
configure the interceptors to perform BAM tracking in WF and WCF applications.
BAM Interceptors for WF and WCF
Describe the purpose of the WF and WCF Interceptors for BAM.
Overview
The WF and WCF BAM interceptors extend the BAM features of BizTalk Server 2010 to the
Windows Workflow Foundation (WF), Windows Communication Framework (WCF) runtimes.
By using the BAM interceptors, you can track your business processes without recompiling
your WF or WCF solution — integration is done through a configuration file.
The BAM Interceptor plumbing automatically detects configuration file changes and it will
apply new configurations to new workflow instances while applying the old configuration to
old (existing) messages. This is completely automatic.
The WCF interceptor can intercept messages to a WCF service before the service call or right
before the return value is sent back. Parameter and message values can be grabbed and
flushed to BAM.
Deployment is performed the BAM management tool (bm.exe). Adding, updating, removing,
and interrogating BAM Interceptor configuration files can all be done with the enhanced
bm.exe tool.
Interceptor Integration
Describe how the WF and WCF Interceptors integrate with the BizTalk BAM Interceptor.
Overview
By using BAM interceptors, the various components that make up a business process can
work together to collect tracking data for an instance of BAM Activity that spans application
boundaries. As an example, a single business process might include a WCF service, a BizTalk
orchestration and a WF workflow.
Using the WCF interceptor, the WCF service can initialize a new instance of the BAM activity
and report the time that it received a message. The WCF service could enable a
continuation to allow other components to report tracking data for the activity instance.
Later in the process, a BizTalk orchestration could report data to BAM, such as an Amount
value, to for the same activity instance. The orchestration could also enable a continuation
to allow other components to report tracking data for the activity instance.
Finally, a WF workflow could complete the business process and use the WF interceptor to
report the end time of the activity instance.
Interceptor Configuration (IC)
Describe how developers can create Interceptor Configurations (ICs) for the WF and WCF
Interceptors.
Overview
The BAM interceptors for Windows Workflow Foundation and Windows Communication
Foundation rely on an interceptor configuration (IC) file to determine what events and data
elements to intercept. The IC file is XML and the structure is defined by a set of interceptor
configuration schemas.
A common configuration schema is reused across the WCF and WF BAM interceptors.
However, given the differences between the WCF and WF programming models, the
common schema needs to be extended to incorporate the specific interception mechanisms
for collecting the BAM data. For instance, developers using the BAM WCF interceptor will,
most likely, extract the data from a SOAP or XML message intercepted at different stages of
the client or dispatcher runtimes. On the other hand, developers using the WF interceptor
will extract the activity data from WF-specific components such as workflow properties or
user data types. Essentially, in order to provide a complete declarative mechanism for
populating a BAM activity model, the WCF and WF interceptors need to extend the common
configuration schema with specific elements of their programming model.
The XML Schemas that describe the structure of an IC file can be found in the <BizTalk Server
2010 Install Folder>\SDK\Samples\BAM\InterceptorXSDs folder. You can leverage these
schemas to get XML IntelliSense® when authoring IC files in Visual Studio 2010 (simply copy
them into <Microsoft Visual Studio 2010 Install Folder>\Xml\Schemas). Unfortunately
Microsoft hasn’t yet provided any additional tooling for working with IC files.
Interceptor Configuration (IC)
Describe the hierarchical structure of an Interceptor Configuration.
Overview
The structure of an IC file maps to the structure of the .NET BAM object model. The
BamActivity element in the IC file maps to the BAM Activity that interceptor will write to.
The IC describes the events that should trigger the interceptor to send tracking data to BAM.
The interceptor uses an event’s filter to determine whether or not it should send the data.
When sending data to BAM, the interceptor will include any correlations, continuations and
updated data, including references, that the IC specifies for the event.
Creating an Interceptor Configuration (IC)
Explain the purpose of the EventSource element.
Overview
The EventSource element provides information about the source of one or more of the
events appearing in the interceptor configuration file. In addition to an event source name,
you need to indicate the technology and a manifest for the source.
The EventSource element has three attributes and may or may not have child elements
depending upon which schemas are included. For example, the WCF schema
WcfInterceptorConfiguration.xsd provides for a child NamespaceMapping element.
Provide an example of IC EventSource definitions for WF and WCF.
Overview
This example contains two EventSource elements, one targeting WF and one targeting WCF.
Explain the purpose of the BamActivity. Element.
Overview
A BamActivity element in an IC maps to an Activity of the same name in a BAM definition
file. A BamActivity element contains one or more OnEvent elements. Any event data that
the interceptor sends to BAM will be written to the BAM Activity specified by the event’s
enclosing BamActivity element.
Explain the purpose of the OnEvent elements in an IC.
Overview
The OnEvent element describes one real event that is mapped to the enclosing BAM activity.
The OnEvent element contains settings that define how the interceptor should handle a
particular event that may occur in a WF or WCF application’s runtime. The Name will be
used to reference this OnEvent definition elsewhere in the IC. The Source refers to an
EventSource that was previously defined in the IC file. The IsBegin and IsEnd attributes
indicate if this event is starting or ending the BAM Activity.
The OnEvent element contains child elements that specify an event filter: CorrelationID,
ContinuationToken, Reference, and Update.
Explain how BAM interceptors use IC Expressions.
Overview
Expression elements are used throughout an IC file. Expressions can serve as OnEvent filter
conditions, or they can be used to extract tracking data from the WF or WCF application.
The extracted data can be used as a correlation ID, as a continuation token or for an update.
Describe how operations work in IC expressions.
Overview
Expressions are made up of Operation elements . The interceptor will evaluate an
operation, and place the result on a stack. It’s possible to use an IC Operation element to
call methods on the WF runtime or the WCF runtime.
The And operation removes the top two items from the stack, performs a Boolean AND of
the two items, and then pushes the result onto the stack.
The Concatenate operation removes the top two items from the stack, concatenates them,
and then pushes the result onto the stack.
The Constant operation pushes a single constant value onto the stack.
The Equals operation removes the top two items from the stack, compares the two items,
and then pushes the result onto the stack.
The IC schemas for WF and WCF define additional operations for interacting with their
respective runtimes.
Explain how to use Reverse Polish Notation (RPN) to create IC expressions.
Overview
Individual expressions are identified in an IC file by the Expression element which contain
one or more Operations arranged as Reverse Polish Notation (RPN), also known as postfix
notation.
In RPN, operands precede the operator, removing the need to use parentheses as
precedence operators. A stack is used to hold values, and all operations either push values
onto the stack, pop (remove) values from the stack, or perform a combination of pushes and
pops to complete an operation.
For example, if you wanted to evaluate the expression
2 * (3 + 4)
Converting this to the equivalent RPN results in
234+*
This would be evaluated as follows:
Input Operation Stack
2 Push 2
3 Push 3, 2
4 Push 4, 3, 2
+ Subtract 7, 2
* Add 14
RPN can support an arbitrary number of operations, including comparison, boolean

operations, and custom operations. Values accumulate on the stack and are pushed and
popped according to individual operations.
You will write two kinds of expressions in the interceptor configuration file: filter expressions
and data expressions. Filter expressions expect the result of the RPN expression to be a
Boolean true or false while data expressions expect a single value on the stack.
Data expressions are used to define a single string data value. A data expression is any
expression that is not enclosed by a Filter element. Data expressions are used by the
OnEvent child elements CorrelationID, ContinuationToken, Reference, and Update.
Provide an example of using RPN in an IC file.
Overview
This example concatenates three strings using an Expression that consists of five Operations
expressed in RPN.
Explain the purpose of the IC Filter element.
Overview
The Filter element contains an Expression that evaluates to true or false and determines if an
event should be processed or ignored. If the expression evaluates to true, the event will be
processed, otherwise it will be skipped.
Explain the purpose of the IC CorrelationId element.
Overview
The CorrelationID element is used to specify a BAM correlation ID for a message. The
CorrelationID element consists of an Expression element that uses one or more Operation
elements to specify the string to use as the correlation ID. CorrelationID expressions may
not use the And or Equals operations.
Explain the purpose of the IC Update element.
Overview
The Update element is used to extract data from an event and import it into the related
BAM activity. To use the Update element, you must provide both a column name and type
and an Expression element containing one or more Operation elements that evaluate to a
single string value. Update expressions may not use the And or Equals operations.
Explain the purpose of the IC Reference element.
Overview
The Reference element can be used to add one or more relationships to a BAM activity. This
is useful when you want to attach a pointer like a primary key, ID, or URL to a related
message. For example, you might store a reference to a Shipment Batch in a Purchase Order
activity.
Reference expressions may not use the And or Equals operations.
Valid Reference Types include BizTalkService, MessageID, Activity, DocumentUrl and
InstanceID.
The Reference element supports both the Data and LongData child elements that contain an
Expression specifying the data to attach to the BAM activity. You can use any combination of
Data and LongData elementsto meet your tracking requirements.
Explain the purpose of the IC CorrelationToken element.
Overview
A ContinuationToken element contains an Expression that evaluates to produce a BAM
continuation ID. ContinuationToken expressions may not use the And or Equals operations.
A continuation ID is used to correlate information across different applications that report
tracking data to the BAM infrastructure. Consider a business process that constructs the
following types of messages:
 Purchase order identified by a purchase order number
 Sales order identified by a sales order number
 Shipping order identified by a shipping order number
In this process, there are three important identifiers: purchase order ID, sales order ID and
shipping order ID. Each of these identifiers signals an important event in the lifetime of the
original order, but they cannot be directly correlated. To track events related to a purchase
order, the information that is common between the messages must be identified to help the
BAM tracking infrastructure accurately correlate the events.
Deploying an Interceptor Configuration
Explain how to deploy an Interceptor Configuration file.
Overview
Every IC must be deployed to the BAM runtime, just like you would deploy a BAM tracking
profile. The BAM management tool, bm.exe, includes commands for managing IC files.
The WF and WCF interceptor components know how to connect to the BAM database to
load the deployed configurations and use the instructions from the IC to perform the BAM
tracking.
Demonstration: Applying an Interceptor Configuration
Demonstrate how to create and deploy an Interceptor Configuration file.

1. In Windows Explorer, navigate to C:\AllFiles\DemoCode\Module17, then double-
click SetupBamApp.cmd, and then verify that the installation completed
successfully.
Add XSD Type Definitions to Intellisense in Visual Studio

1. In Windows Explorer, in C:\AllFiles\DemoCode\Module17 double-click BAM.sln.
2. In Solution Explorer, under Solution Items, open
BlankInterceptorConfiguration.xml.
3. Click anywhere between the opening and closing InterceptorConfiguration tags, and
type <.
Notice that Visual Studio Intellisense does not display a list of valid XML element
names.
4. In Windows Explorer, copy the all of the BAM Interceptor XML schema files from
C:\Program Files (x86)\Microsoft BizTalk Server

2010\SDK\Samples\BAM\InterceptorXSDs\
to
C:\Program Files (x86)\Microsoft Visual Studio 10.0\Xml\Schemas\
5. Now, click anywhere between the opening and closing InterceptorConfiguration

tags, and type <.
Notice that Intellisense now lists EventSource as a valid element.
6. Type in the following lines of code inside of the InterceptorConfiguration tags.
<EventSource Technology=”WF” Name=”BillingWF” Manifest=”” />

<EventSource Technology=”WCF” Name=”ClientProxy” Manifest=”” />
7. Close the BlankInterceptorConfiguration.xml file without saving your changes.
Examine an Interceptor Configuration File

1. In Solution Explorer, in Solution Items, open InterceptorConfig.xml.
2. Locate the EventSource element with Technology=”WF”.
This EventSource is tied to a WF Workflow named

BillingWorkflows.BillingProcess found in the BillingWorkflows assembly.
3. Locate and select the value of the Manifest attribute.
The BAM interceptors will perform a SQL query for the Manifest string, so you
need to be careful to follow the exact format that the BAM runtime will send in
the query. There must be exactly one space after each comma. And, even if the
assembly is not signed, the Manifest must include a value for PublicKeyToken.
Unsigned assemblies simply have a PublicKeyToken value of null.
4. Locate and select the EventSource element with Technology=”WCF”.
This EventSource has child elements that pertain only to the WCF interceptor.
These will elements be covered later in this module.
5. Locate the BamActivity element, and select the Name attribute.
The value of this Name attribute matches the name of the OrderProcessing BAM
activity that originates in the BAM definition that can be found in
c:\AllFiles\DemoCode\Module17\bam_definition.xslx.
6. Locate the OnEvent element with the Name=”OrderProcessing”, and select the
Source attribute.
The value of this Source attribute matches the Name of the first EventSource
element defined in this IC. The OnEvent element contains instructions for events
raised by the component specified in the EventSource.
7. The first child of this OnEvent element is a Filter element. Select the Filter element,
and its enclosed Expression element.
This is the Expression that determines which events will be handled, and which
ones will be ignored. We will examine it in further detail later in this module.
8. Locate the CorrelationID element that immediately follows the Filter element, and
select the Expression within it.
This CorrelationID Expression creates a BAM continuation to match the

continuation received from the orchestration.
9. Locate the Update element that immediately follows the CorrelationID element,
and select the Expression within it.
This Update Expression instructs the interceptor to update the BAM data item
named OrderTotal, which was assigned a data type of “FLOAT” in the BAM
definition.
Deploy the Interceptor Configuration File

1. Open a command prompt and enter the following commands to display the
commands offered by the BAM Management tool:
cd %BTSInstallPath%\Tracking
bm.exe
The BAM Management tool offers a set of commands for managing interceptor
configuration files: deploy-interceptor, get-interceptor, get-interceptorlist and
remove-interceptor.
2. Enter the following command to display a help screen for the deploy-interceptor
command.
bm.exe help -command:deploy-interceptor
3. Enter the following command (all on one line) to deploy the interceptor
configuration file to the BAMPrimaryImport database.
bm.exe deploy-interceptor
–
filename:C:\AllFiles\DemoCode\Module17\InterceptorConfiguration.xml
Now, when the WF and WCF BAM interceptors are configured and loaded in
their respective runtime environments, they can contact the BAMPrimaryImport
database to find their configuration information.
Deploy an Orchestration Tracking Profile

1. In Windows Explorer, in the C:\AllFiles\DemoCode\Module17 directory, double-click
the TrackingProfile.btt file to open it in the Tracking Profile editor.
This is the BAM interceptor configuration for the BizTalk Orchestration.
2. Expand the ShipNotificationSend node, and then click on Send_ShipNotice.
Most of the data collected for this BAM activity will come from the orchestration
or from the BizTalk send and receive ports. The OrderReceived and OrderTotal
data items are the exceptions. Those two fields will come from the WCF
interceptor and the WF interceptor respectively.
3. Click the WCF_ continuation node at the bottom of the tree.
The WCF interceptor will enable this continuation when it receives a new
message. The value of the continuation ID will follow the format
WCF_<OrderNumber>. The BizTalk receive port will follow that continuation.
4. Click the first ReceiveCont_ node.
The BizTalk receive port will enable the ReceiveCont_<OrderNumber>

continuation, which the orchestration will follow. This series of continuations
enables all of the BizTalk components to update the same BAM activity instance
that the WCF interceptor initialized.
5. Click the Orch_ node.
Finally, the orchestration will enable the Orch_<OrderNumber> continuation,

which will be followed by the WF interceptor, which will write the OrderTotal to
BAM.
6. On the Tools menu, click Apply Tracking Profile to deploy the TrackingProfile.btt file
to the BAM runtime environment. In the Tracking Profile Editor warning message
box, click Yes.
The ContinuationID that is mentioned in the warning will be set by a WCF
application that the Tracking Profile Editor is not aware of.
7. In the Tracking Profile Editor confirmation message box, click OK, and then close the
Tracking Profile Editor window.
8. Close all open windows, and pause the bt10d-demos virtual machine.
Lesson 2: Using the WF Interceptor
Lesson objective:
This lesson will explain how to configure the WF BAM Interceptor.
Lesson Overview
The Windows Workflow Foundation interceptor enables you to transparently add BAM
tracking functionality to new and existing WF applications. After the interceptor
configuration has been deployed to the BAM Primary Import database and each instance of
the WF application has been configured to load the BAM WF Interceptor, workflow data will
be written to BAM with no additional code. The WF interceptor provides the following
functionality:
 Plugs into existing WF applications without requiring code changes or recompilation.
 Enables run-time detection and support for changed configuration files. If a new
version of an interceptor configuration file is detected, new workflow instances will
use the new configuration while old workflow instances will complete using the old
configuration.
 Supports transactions. The WF interceptor persists tracked items in a transactionally
consistent way with WF transactions. Tracked items are only persisted when the WF
transaction and the interceptor trasaction complete successfully.
Every time an instance of a WF workflow executes, the BAM WF interceptor will populate
the BAM activity model based on the instructions declared in the IC file.
Introduction to the WF Interceptor
Describe the architecture of the WF interceptor.
Overview
The BAM WF interceptor is based on the WF tracking services framework. This framework is
designed to enable hosts to observe workflow instances during execution by capturing
events that are raised during workflow execution. The framework is based on a pluggable
design pattern that enables hosts to facilitate complex tracking scenarios by including
different tracking services.
At a high level, a tracking service uses two fundamental components: tracking profiles and
tracking channels. Tracking profiles are used by the tracking service as a mechanism to
communicate the events it would like to receive from the runtime. This guarantees that the
tracking service will only be called for specific events instead of the entire event set
produced by a workflow during its execution. The second component used by the tracking
service is the tracking channel. These components are responsible for receiving the tracking
events and data about the execution of a workflow instance.
Describe the additional IC operations that are available for the WF interceptor.
Overview
WF activities are the fundamental building blocks of workflows. A workflow is a set of WF
activities that are organized hierarchically in a tree structure. A WF activity represents an
action in a workflow. It can be a simple action such as a delay, or it can be a composite
activity that consists of several child activities.
The BAM WF interceptor captures different events at the workflow, activity, and user levels.
On each one of those tracking points, we can extract the data from the workflow by using
some of the custom operations provided by the interceptor. For instance, in this case, we
are interested in the Closed event of the TransactionApproved WF activity. When that event
occurs, the interceptor will extract the TransactionID field of the Transaction activity and
map it to the TransactionID activity field. It is important to notice that there are many other
events and functions that can be combined to address diverse BAM WF monitoring
scenarios.
 The GetActivityEvent operation pushes the name of the current activity event onto
the stack.
 The GetActivityName operation pushes the name of the current activity onto the
stack.
 The GetActivityProperty operation pushes the extracted property from the activity
related to the tracking event onto the stack.
 The GetActivityType operation pushes the name of the current activity type onto the
stack.
 The GetContextProperty operation pushes the requested context property onto the
stack.
 The GetUserData operation pushes the current user data onto the stack.
 The GetUserDataType operation pushes the name of the current user data type onto
the stack.
 The GetUserKey operation pushes the current user key onto the stack.
 The GetWorkflowEvent operation pushes the name of the current workflow event
onto the stack.
 The GetWorkflowProperty operation pushes the extracted property from the root
activity of the workflow onto the stack.
Explain the properties that are available through the WF IC GetContextProperty operation.
Overview
The GetContextProperty operation pushes the requested context property onto the stack.
The InstanceId property is often used for continuation or activity definition. The EventTime
property is useful for reporting a milestone value.
Creating a WF Interceptor Configuration
Explain the mapping of IC operations to WF trackpoints.
Overview
The custom operations provided by the BAM WF interceptor can be categorized by the
associated Windows Workflow Foundation track point type:
 Activity
 Workflow
 User
The BAM WF interceptor uses the categories to assign a track point type to each OnEvent. It
bases this assignment on the types of operations it sees in the OnEvent filter and the data
extraction and manipulation sections. For example, if the OnEvent contains an Update
element that uses the GetUserData operation, it is a user track point type because the
activity and workflow events do not support this operation.
Show an example of an IC filter expression using a WF operation.
Overview
This simple example shows a Filter expression that checks to see if the current workflow
event is equal to “Started”. Notice that the Operation element for GetWorkflowEvent has an
XML namespace prefix of bamwf. The bamwf prefix maps to the XML namespace defined in
the XML IC schema for the WF interceptor.
Show a more complex example of an IC filter expression using a WF operation.
Overview
This example shows a Filter Expression that checks if the event has been raised by a custom
WF activity of type “MyActivities.MyActivity”, and if the WF activity’s name is
“trackableAmount”, and if the WF activity’s status is “Closed”.
Explain how to use a WF IC operation to set an IC correlation ID.
Overview
Developers often use the WF Workflow.InstanceId property for correlation since it is unique,
and it is easy to access and track. You can also use other properties of the WF Activity or
Workflow such as a unique order ID or customer number that would uniquely identify the
instance.
Show examples of using WF IC operations to implement an IC update.
Overview
These examples show Update Expressions that extract data to update a BAM data item. The
first example shows an Expression that extracts the value of the WF Activity’s Amount
property, and it uses the value to update the BAM data item named “Amount”.
The second example shows an Update Expression that extracts the timestamp of the event,
which is used to update the BAM data item named “Start”.
Deploying a WF Interceptor Configuration
Explain what is required to configure the WF runtime to load the WF interceptor.
Overview
In order to begin collecting BAM activity data from a WF application, you must install the
BAM interceptor software, and you must configure your application to use the Windows
Workflow Foundation (WF) interceptor tracking service. When configuring the tracking
service, you must provide a polling interval and a connection string for the
BAMPrimaryImport database. The polling interval specifies how frequently the tracking
service should check the BAM database for changes to interceptor configurations.
There are three options for loading the BAM tracking service in your WF application:
 If your WF application already uses WorkflowRuntime to load a WF configuration
section, you can added BAM tracking service information to the existing section.
 If your WF application does not use WorkflowRuntime to load a WF configuration
section, you will have to add code to load a custom section from your application
configuration file. You will have to create the section and add the BAM tracking
service information to it.
 If you prefer to hard-code the configuration, you can use the WF API to
programmatically load the tracking service without a configuration file, or to load
the configuration from a custom source.
Deploying a WF Interceptor Configuration
Show examples of the code required to load the WF interceptor in to the WF runtime.
Overview
These two examples show different ways to enable the BAM tracking service in a WF
application. The first example shows how to start the BAM tracking service
programmatically. The second example shows how to accomplish the same thing by adding
entries to the WF WF application’s configuration file.
Demonstration: Applying the WF BAM Interceptor
Demonstrate how a WF workflow application reports BAM data using the WF interceptor.
Review the Sample Workflow Application

2. In Windows Explorer, in C:\AllFiles\DemoCode\Module17 open BAM.sln.
3. In Solution Explorer, in the BillingWorkflows project , open BillingProcess.cs in
design view.
This is a very simple WF workflow that consists of a single custom WF activity

named ProcessBilling.
4. In the Properties window, click OrderTotalAmount.
The WF interceptor needs to extract and report the value of this property to BAM
when the ProcessBilling WF activity closes.
5. Press F7 to open BillingProcess.cs in code view.

The WF workflow has a property named OrderID. The WF interceptor needs to
extract this value, and use it to follow the continuation that is enabled by the
orchestration.
Examine WF Interceptor Configuration Settings

1. In Solution Explorer, under Solution Items, double-click
InterceptorConfiguration.xml.
2. Locate the EventSource element with Name=”BillingWF”.
This EventSource element is bound to the WF Workflow named

BillingWorkflows.BillingProcess found in the BillingWorkflows assembly. When
the WF interceptor loads in to the WF runtime, and queries the
BAMPrimaryImport for the IC associated with this WF workflow, it will receive
the IC instructions associated with this EventSource element.
3. Locate the OnEvent element with Name=”BillingActivity”.
This OnEvent element is tied to the BillingWF EventSource element described in

step 2, and it provides instructions for the WF BAM interceptor to follow when
the BillingProcess workflow fires an event. The IsBegin and IsEnd attributes are
both “true” since this is the only OnEvent element mapped to the BillingWF
EventSource.
If the IC had included multiple onEvent elements tied to the BillingWF
EventSource, then the first one in the firing sequence would have been marked
with OnBegin=”true”, and the last one in the firing sequence would have been
marked with OnEnd=”true”.
4. Locate the Filter element, and select the Expression within it.
This Filter Expression conforms to RPN and it checks to see if the WF activity that
raises this event is named “ProcessBilling”, and if the WF activity’s status is
“Closed”.
This expression uses the WF IC Operations GetActivityName and GetActivityEvent
to extract data from the WF runtime. The Operations prefixed with “wf” are
defined in the IC schema extensions for WF. Notice the mapping of the prefix to
the WF IC XML namespace in the root element.
This CorrelationID Expression creates a BAM continuation that matches the

continuation received from the orchestration. It consists of the string “Orch_”
concatenated with the value of the OrderID that is extracted from the WF
activity using the GetWorkflowProperty operation.
This Update Expression instructs the WF interceptor to use the WF

GetActivityProperty operation to extract the OrderTotalAmount from the WF
activity. The Update Expression then updates the BAM data item named
OrderTotal, which was assigned a data type of “FLOAT” in the BAM definition
file.
Initializing the BAM Tracking Service in the WF Runtime

1. In Visual Studio, in the BillingApplication project, open the Program.cs file.
This is the program that will load the WF runtime and run the BillingProcess
workflow.
2. Inside the Program.cs file, find the watcher_Created method, and then select the
following lines of code.
XElement billingDoc = XElement.Load(e.FullPath);

orderNumber = (int)billingDoc.Descendants(“OrderIdentifier”).First();
orderTotal = (double)billingDoc.Descendants(“Total”).First();
This code loads the billing.xml file that was sent from BizTalk, and it extracts the
values for orderNumber and orderTotal.
3. Locate and select the following lines of code.
runtime.AddService(new BamTrackingService(
“server=.;database=BamPrimaryImport;Integrated Security=SSPI”,
60000);
This line of code initializes the WF BAM tracking service and adds it to the WF
runtime. It is initialized with a connection string to the BAMPrimaryImport
database, and a polling interval. The polling interval specifies how frequently the
BAM tracking service should query the BAMPrimaryImport database for changes
to the ICs.
To use the BamTrackingService you need to add a reference to the
Microsoft.BizTalk.Bam.Interceptors assembly. You can find it in the
%BTSInstallPath%\Tracking folder.

var wf = runtime.CreateWorkflow(
typeof(BillingWorkflows.BillingProcess),
new Dictionary<string, object>
{
{"OrderID", orderNumber},
{"OrderAmount", orderTotal}
});
wf.Start();
waitHandle.waitOne();
This code starts the BillingProcess workflow, initializing it with the OrderID and
OrderAmount values. The waitHandle.waitOne() line waits for the workflow to
complete.
Test the WF Interceptor Configuration

1. In Windows Explorer, navigate to C:\AllFiles, and double-click startBtServices.cmd.
2. In Solution Explorer, right-click the BillingApplication project, then click Debug, and
then click Start New Instance.
The BillingApplication watches the file system for billing messages produced by
the BizTalk orchestration. When a file arrives, the BillingApplication will pick up
the file, run the BillingProcess workflow, and the WF interceptor will update
BAM.
3. To submit a message, navigate in Windows Explorer to

C:\AllFiles\DemoCode\Module17, and then double-click SubmitOrder.cmd.
This launches a WCF client application that sends an order message to BizTalk.
4. After the order message has been submitted, switch back to the BillingApplication
console window and verify that the workflow completed.
5. In Windows Explorer, in C:\AllFiles\DemoCode\Module17, double-click
SubmitShippingAck.cmd to send a shipping acknowledgement message to the
OrderProcessingReportsViewer.exe to view the BAM tracking data for this order.
The Order Received timestamp was reported by the WCF client, all of the other
timestamps were reported by the orchestration, and the Order Total was
reported by the WF application.
7. Close all open windows, and pause the bt10d-demo virtual machine.
Lesson 3: Using the WCF Interceptor
Lesson objective:
This lesson will explain how to configure the WCF BAM Interceptor.
Lesson Overview
The Windows Communication Foundation interceptor provides BAM tracking functionality
to your WCF applications. After the interceptor configuration has been deployed to the BAM
Primary Import database and the WCF application has been configured to load the BAM
WCF Interceptor, tracking data will be written to BAM with no additional code. The WCF
interceptor provides the following functionality:
 Plugs into existing WCF applications without requiring code changes or
recompilation.
 Tracks messages contained in WCF service calls.
 Tracks information from messages in WCF service calls.
 Participates in transactions flowed from the client or initiated internally for
transacted service calls.
Every time an instance of the configured WCF client or service executes, the BAM WCF
interceptor will populate the BAM activity model based on the instructions declared in the IC
file.
Introduction to the WCF Interceptor
Describe the architecture of the WCF interceptor.
Overview
The BAM WCF interceptor is a flexible technology that allows developers to populate BAM
activity models based on the information exchanged by WCF services and clients. In order to
model the interactions with the BAM model, the BAM WCF interceptor schema extends the
basic interceptor configuration model with WCF-specific elements. Essentially, the
interceptor configuration file models how WCF messages are mapped to BAM activities
throughout the different stages of the client or dispatcher runtimes
The BAM WCF interceptor leverages endpoint behaviors as the extensibility point used to
insert the BAM interception mechanisms into the WCF client and dispatcher runtimes. When
the endpoint behavior is loaded by the client or service host, it plugs in message and
parameter inspector components that interpret the interception configuration file in order
to log the data to the BAMPrimaryImport database.
Introduction to the WCF Interceptor
Describe the additional IC operations that are available for the WCF interceptor.
Overview
The WCF interceptor configuration schema defines a set of operations that can be used to
extract BAM tracking information from a WCF message at runtime.
 The AutoGenerateCorrelationToken operation automatically generates a correlation
token and places it onto the stack. This operation can be used when there is no
correlation token present in the message but you still want to correlate the
information from a request and a reply. It can be used to correlate a particular
request/reply on either the client or the service side.
 The GetContextProperty operation pushes the requested context property onto the
stack.
 The GetEndpointName operation pushes the name of the current interception
endpoint onto the stack. It is important to note that the client and server
applications will return different names for the same endpoint name specified in the
app.config files. For client applications, the endpoint name retrieved by the
GetEndPointName operation is the binding name followed by an underscore and the
contract name. For example, if the Name property on ServiceEndpoint is not set but
the binding is set, the name will be set to <binding>_<contract>. If the name and
binding are not set, the Name property will be set to <contract>. For the service, the
name retrieved is the endpoint name specified in the app.config file.
 The GetOperationName operation pushes the name of the current operation onto
the stack. When using GetOperationName, make sure you compare the operation
name as it is invoked by your application. For example, if you use the name attribute
on a service contract to assign a custom name, the client will have its default proxy
generated with the custom name for the method. However, the server application
will use the actual method names for the corresponding operations and not the one
specified in the name attribute.
 The GetServiceContractCallPoint operation pushes the name of the current service
contract call point onto the stack. A Windows Communication Framework service
can be intercepted at different points in the lifetime of the service contract.
 The XPath operation pushes the value indicated by an XPath statement. In the case
of multiple matches, only the first match is used.
Creating a WCF Interceptor Configuration
Explain the properties that are available through the WCF IC GetContextProperty operation.
Overview
The GetContextProperty operation pushes the requested context property onto the stack.
The SessionId property is often used for continuation or activity definition. The EventTime
property is useful for reporting a milestone value.
The SessionId will be available only when using a session-based WCF binding such as
wsHttpBinding.
Explain the options that are available for the WF IC GetServiceContractCallPoint operation.
Overview
GetServiceContractCallPoint pushes the name of the current service contract call point onto
the stack. An IC Filter expression for the WCF interceptor must always include a condition
that checks the GetServiceContracCallPoint property. The WCF interceptor needs to know
the point in the lifetime of the service contract at which it should collect BAM tracking data.
Show an example of an IC filter expression using a WCF operation.
Overview
This example shows an IC Filter Expression that checks if the WCF service contract call point
is “ServiceRequest”, and if the operation name is “ProcessOrder”. If both conditions are
true, then the WCF interceptor will follow the subsequent IC instructions to extract the
tracking data and set it to BAM.
Deploying a WCF Interceptor Configuration
Explain what is required to configure the WCF runtime to load the WCF interceptor.
Overview
You must install the BAM interceptor software and configure your application to use the
BAM Windows Communication Foundation (WCF) interceptor service before you can begin
collecting BAM activity data.
To enable BAM tracking in your WCF server or client application, you will need to modify the
app.config configuration file to include an additional endpoint behavior and behavior
extension and add a behavior configuration attribute. The formats of the service and client
templates are similar. The behavior implementation injects message and parameter
inspector components into the call execution path so it can track data before and after each
call.
Since the WCF BAM interceptor is an endpoint behavior, you can also enable it within the
WCF adapters when using WCF-Custom or WCF-CustomIsolated. One advantage to using the
WCF interceptor (over the built-in pipeline interceptor) is that it can capture fault messages.
Another potential advantage is consistency throughout your BizTalk Server and WCF
applications.
Deploying a WCF Interceptor Configuration
Show an example of the configuration required to load the WCF interceptor in to the WCF
runtime.
Overview
The WCF BAM interceptor is implemented as a custom endpoint behavior that you configure
on client or service endpoints. In order to configure this behavior, you need to register it
within the <behaviorExtensions> section of <system.serviceModel>.
Demonstration: Applying the WCF BAM Interceptor
Examine a WCF client application that is configured to use the WCF interceptor.
Review a Sample WCF Client Application

2. In Windows Explorer, navigate to C:\AllFiles\DemoCode\Module17 and open
BAM.sln.
3. In Solution Explorer, in the OrderClient project , double-click Program.cs.
This is a very simple WCF client that submits an order message to a BizTalk
receive location that has been exposed as a web service.
Orders.OrderServiceClient proxy =
new OrderClient.Orders.OrderServiceClient();
proxy.Open();
This is code creates and opens a WCF proxy object, which will be used to call the
web service.
Orders.InternalOrder order = null;
XmlSerializer ser = new XmlSerializer(typeof(Orders.InternalOrder));
using (var file = File.OpenRead(args[0]))

{
order = (Orders.InternalOrder)ser.Deserialize(file);
}
This code reads an XML file that is specified in a command-line argument. The
contents of the XML file are deserialized to initialize an Order object.
try
{
proxy.SubmitOrder(order);
}
finally
{
if (proxy.State ==
System.ServiceModel.CommunicationState.Opened)
proxy.Close();
else
proxy.Abort();
}
This code issues the call to the web service to submit the order. If the call returns
successfully, it closes the proxy, allowing any remaining processing to complete.
If not, it aborts the operation, forcing the proxy to close immediately.
Examine WCF Interceptor Configuration Settings

1. In Solution Explorer, under Solution Items, double-click
InterceptorConfiguration.xml.
2. Locate the EventSource element with Name=” ClientProxy”.
This EventSource is bound to the WCF service contract class named

OrderClient.Orders.OrderService. This service contract class was generated in
the OrderClient project by adding a Service Reference to the OrderService web
service.
3. Locate the OnEvent element with Name=”Submit”.

This OnEvent element is tied to the EventSource element described in the
previous step, and it provides instructions for the WCF BAM interceptor to follow
when the WCF proxy in the OrderClient application fires an event.
4. Locate the Filter element, and select the Expression within it.
This Filter Expression checks to see if the WCF service contract call point is
“ClientRequest”, and if the client is calling the web service’s “SubmitOrder”
operation. This expression uses the WCF IC Operations
GetServiceContractCallPoint and GetOperationName to call the WCF runtime.
The Operations prefixed with “wcf” are defined in the IC schema extensions for
WCF. The prefix is mapped to the WCF IC XML namespace in the root element.
Every WCF interceptor Filter Expression must include a condition that checks the
GetServiceContractCallPoint operation. If it is omitted, none of the events fired
by the WCF runtime will ever pass the Filter Expression.
This CorrelationID Expression creates a new BAM Activity ID for the order that
the OrderClient application is sending to BizTalk.
This Update Expression instructs the WCF interceptor to use the WCF
GetContextProperty operation to get the current date and time from the WCF
runtime. The Update Expression then updates the BAM milestone named
OrderReceived.
7. Locate the ContinuationToken element that immediately follows the Update

element, and select the Expression within it.
This ContinuationToken Expression concatenates the string “WCF_” with the

value of the message’s OrderID. The expression uses the WCF XPath operation to
extract the OrderID from the message body.
Since the WCF IC is enabling this continuation in BAM, the BizTalk orchestration
will be able to recalculate the same value, and use it to follow the continuation
to report additional tracking data for this BAM activity.
8. Notice the “ns0” prefix in the XPath expression, then locate EventSource element
described in step 2, and select its child wcf:NamespaceMappings element.
The prefix “ns0” in the XPath expression is mapped to an XML namespace by
using a Namespace element. The Namespace element is defined in the XML
schema for WCF IC extensions.
When the XPath expression is evaluated, this mapping will be passed to the
XPath processor, allowing the processor to correctly interpret the “ns0” prefix.
Configuring BAM Tracking in WCF

1. In Visual Studio, in the OrderClient project, open the app.config file.
2. Inside the app.config file, locate client element, and select the
behaviorConfiguration attribute.
<client>
<endpoint
address="http://localhost:8080/BAMInterceptorDemo/OrderService.svc"
binding="basicHttpBinding"
behaviorConfiguration="bamEndpointBehavior"
contract="Orders.OrderService"
name="BasicHttpBinding_ITwoWayAsyncVoid" />
</client>
This configuration setting is adding new functionality to the base WCF client
proxy used for calls to the web service named OrderService.
3. Locate the behaviors element, and select the behavior element.
<behaviors>
<endpointBehaviors>
<behavior name="bamEndpointBehavior">
<BamEndpointBehaviorExtension
ConnectionString="server=.;database=BAMPrimaryImport;…"
PollingIntervalSec="5000" />
</behavior>
</endpointBehaviors>
</behaviors>
This behavior element name matches the value of the behaviorConfiguration

attribute described in step 2. It contains a BamEndpointBehaviorExtension
element that contains the basic configuration settings for initializing the WCF
interceptor. These settings enable the interceptor to connect to the
BAMPrimaryImport database to read its IC.
Notice the BamEndpointBehavior element. This element is not defined in the
default configuration schema, so it needs to be defined elsewhere.
4. Locate the extensions element, and select the add element.

<extensions>
<behaviorExtensions>
<add name="BamEndpointBehaviorExtension"
type="Microsoft.BizTalk.Bam.Interceptors.Wcf.BamEndpointBehavior,
Microsoft.BizTalk.Bam.Interceptors, Version=3.0.1.0,
Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
</behaviorExtensions>
</extensions>
These configurations settings define the BamEndpointBehaviorExtension element

by associating the element name with a class that knows how to load and parse
the WCF interceptor configuration settings described in step 3.
Test the WCF Interceptor Configuration

1. In Solution Explorer, right-click the BillingApplication project, then click Debug, and
then click Start New Instance.
2. Submit a message by navigating in Windows Explorer to
C:\AllFiles\DemoCode\Module17, and then double-click SubmitOrder.cmd.
This launches the OrderClient application, which loads the WCF interceptor, and
sends an order message to BizTalk. The WCF interceptor will generate a BAM
activity ID, generate a continuation token, and it will update the OrderReceived
milestone, sending all of this tracking data to the BAMPrimaryImport database.
3. Switch to the BillingApplication console window and verify that the workflow has
processed the order.
OrderProcessingReportsViewer.exe to view the BAM tracking data for this order.
At this point, the BAMPrimaryImport database holds only part of the data for
this instance of the OrderProcessing BAM activity. Only the WCF interceptor and
the WF interceptor have reported tracking data so far.
SubmitShippingAck.cmd to send a shipping acknowledgement message to the
6. Switch back to the OrderProcessingReportsViewer window, and click Refresh to
view the BAM tracking data for this order.
Now that the orchestration has reported its milestone dates, the
BAMPrimaryImport database contains all of the tracking data that will be
reported for this BAM activity.
Configuring BAM Tracing for WF and WCF Interceptors
Show an example of the configuration required to enable BAM API tracing.
Overview
If you encounter problems or would like to see diagnostic information while developing a
WF or WCF IC file, you can enable BAM API tracing for the interceptors. To enable end-to-
end tracing of the BAM interceptors, you modify the application’s configuration file—either
web.config for web-hosted applications, or app.config for self-hosted applications.
The WF and WCF Interceptor trace messages are written to the source named "Microsoft
BizTalk Bam Interceptors"
This example shows the .config file entries required to send the WF and WCF IC trace output
to a console window.
Lab: Creating a BAM Interceptor Configuration
Overview
In this lab you will be configuring your applications to push KPIs into BAM using the BizTalk
BAM interceptors. In this lab the application is already created for you, you will only create
and configure the WF, WCF, and Orchestration’s interceptors to track data across a logical
process (spanning more than one physical processes). After completing this lab, you should
understand how to: author an interceptor configuration file; deploy an interceptor
configuration file; configure the BAM interceptor for WF; configure the BAM interceptor for
WCF and use continuations to instrument multiple processes with BAM.
Procedure List
window.
Start.

Procedure List
Exercise 1: Deploying the BAM Activity and View
Overview
In this part, you will deploy the BAM activity using the command line BAM Management
(bm.exe) tool.
Review the Environment and Deploy the Sample Application

Procedure List
1. Open the ContosoOrderingApplication.sln solution in the C:\AllFiles\LabFiles\Lab17
folder.
2. Right-click on Contoso.BizTalk.Orchestration project and select Deploy. This will
deploy the orchestration to an application named BAMIntegration.
3. in the BizTalk Administration Console , right-click the BAMIntegration application
and select Import-> Bindings. Browse to the C:\AllFiles\LabFiles\Lab17 directory
and select BindingFile.xml as the binding file to import. Click the Open button in the
dialog.
4. Right-click the BAMIntegration application in the BizTalk Administration Console
and select Start. This will start the BizTalk orchestration and ports.
5. Open ContosoActivity.xml (under the Solution Files folder in the solution explorer),
which is the BAM Activity and View definition, and InterceptorConfig.xml, which is
the BAM interceptor configuration.
6. The BAM Activity (inside ContosoActivity.xml) is a very basic activity which just
pushes in 4 milestones:
Milestone Description
Start When the process starts; this will be when the WF
Workflow begins processing.
OrchProcessing When the BizTalk Orchestration starts processing.
Processing When the WCF Service begins processing.
Done When the BizTalk Orchestration receives the
response from the WCF Service and ends.
7. Open a command prompt and change the directory by typing:
8. From the command prompt, deploy the BAM Activity by typing the following
command (replacing the lab directory) and hitting enter:
bm.exe deploy-all -DefinitionFile: C:\AllFiles\LabFiles\Lab17\ContosoActivity.xml
You will have to type this command line in by hand. Copying the command from
this document will not work correctly
Exercise 2: Creating the Interceptor Configuration File
Overview
In this part, you will create a single interceptor configuration file for both WF and WCF
components. The WinForms application begins a workflow and sends data to an
orchestration. The orchestration then calls a WCF service.
If you encounter any problems, there is a copy of a the completed IC file in the
C:\AllFiles\LabFiles\Lab17\ContosoActivity.xml folder for reference.
Define the Event Sources

Procedure List
1. In the InterceptorConfig.xml file (back in the solution files), create a BAM
EventSource for the WCF Service Contract:
<bam:EventSource Name="ContosoServices" Technology="WCF"

Manifest="ContosoOrderingService.IContosoOrderingService,
ContosoOrderingService, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=null" >
<bamwcf:NamespaceMappings>
<bamwcf:Namespace Prefix="test"
Uri="http://contoso.com/services/OrderingServiceData"/>
</bamwcf:NamespaceMappings>
</bam:EventSource>
2. Create an EventSource for the WF Workflow. The ContosoOrderingApplication will

spawn a Workflow when an Order is in process. (See the MainForm.cs –
button1_Click event handler.)
<bam:EventSource Name="ContosoWorkflow" Technology="WF"

Manifest="Contoso.Workflow.OrderFlow, Contoso.Workflow,
Version=1.0.0.0, Culture=neutral, PublicKeyToken=null">
</bam:EventSource>
Define a BAM Activity

Procedure List
1. Create a BamActivity element for all the data you’d like to push into the
ContosoOrderingSystem BAM Activity.
<bam:BamActivity Name="ContosoOrderingSystem">
</bam:BamActivity>
2. Inside of the BamActivity element for the interceptor configuration create an

OnEvent element for the WF source
<bam:OnEvent Name="WFStart" IsBegin="true" IsEnd="true"
Source="ContosoWorkflow" >
</bam:OnEvent>
3. Inside of the OnEvent element for the ConstosoWorkflow source which you just
created, create a filter for the Workflow Started event.
<bam:Filter>
<bam:Expression>
<bamwf:Operation Name="GetWorkflowEvent"/>
<bam:Operation Name="Constant">
<bam:Argument>Started</bam:Argument>
</bam:Operation>
<bam:Operation Name="Equals"/>
</bam:Expression>
</bam:Filter>
4. After the filter you just added, still inside of the OnEvent element, create a
CorrelationId element that uses the Workflow.InstanceId as its context property
(use the GetContextProperty operation for InstanceId).
<bam:CorrelationID>
<bam:Expression>
<bamwf:Operation Name="GetContextProperty">
<bamwf:Argument>InstanceId</bamwf:Argument>
</bamwf:Operation>
</bam:Expression>
</bam:CorrelationID>
5. Next you’ll add the Update element, which uses the GetContextProperty to cause a
timestamp to be written to the BAM Activity for the Start milestone.
<bam:Update Type="DATETIME" DataItemName="Start">

<bam:Expression>
<bamwf:Argument>EventTime</bamwf:Argument>
</bamwf:Operation>
</bam:Expression>
</bam:Update>
6. Next, create two Continuation Token elements – one for BizTalk to continue, one
for WCF to continue.
<bam:ContinuationToken>
<bam:Expression>
<bam:Argument>CorrelationId_</bam:Argument>
</bam:Operation>
</bamwf:Operation>
<bam:Operation Name="Concatenate"/>
</bam:Expression>
</bam:ContinuationToken>
<bam:Expression>
<bam:Argument>WCF_</bam:Argument>
</bam:Operation>
</bamwf:Operation>
</bam:Expression>
Define a WCF Event Collection

Procedure List
1. Inside of the BamActivity element for the interceptor configuration, create an
OnEvent element for the WCF source – AFTER the end tag of the OnEvent element
for the WF source.
<bam:OnEvent Name="WCFProcessing" IsBegin="true" IsEnd="true"

Source="ContosoServices">
</bam:OnEvent>
2. Inside of the OnEvent element for the ContosoServices source which you just
created (WCF source), create a filter for when messages are received by the Service
for the ProcessOrder operation.
<bam:Filter>
<bam:Expression>
<bamwcf:Operation Name="GetServiceContractCallPoint"/>
<bam:Argument>ServiceRequest</bam:Argument>
</bam:Operation>
<bam:Operation Name="Equals" />
<bamwcf:Operation Name="GetOperationName"/>
<bam:Argument>ProcessOrder</bam:Argument>
</bam:Operation>
<bam:Operation Name="And" />
</bam:Expression>
</bam:Filter>
3. Next specify the CorrelationId as a concatenation between the string WCF_ and
XPath operation on the message for the OrderId element's value. This will match
what the WF OnEvent has set up for the Correlation. After adding this code, Save
the file.
<bam:CorrelationID>
<bam:Expression>
</bam:Operation>
<bamwcf:Operation Name="XPath">
<bamwcf:Argument>//test:OrderId</bamwcf:Argument>
</bamwcf:Operation>
</bam:Expression>
4. Next, create the Update for the WCF OnEvent - pulling the EventTime from the
GetContextProperty Operation.
<bam:Update DataItemName="Processing" Type="DATETIME">

<bam:Expression>
<bamwcf:Operation Name="GetContextProperty">
<bamwcf:Argument>EventTime</bamwcf:Argument>
</bamwcf:Operation>
</bam:Expression>
</bam:Update>
Exercise 3: Deploy the Interceptor File
Overview
In this part, you will deploy the interceptor file that you created in Exercise 3.

Procedure List
1. Deploy the interceptor file from the command line:
bm.exe deploy-interceptor –
FileName:C:\AllFiles\LabFiles\Lab17\InterceptorConfig.xml
You will need to type this command in manually. Copying the command from this
document to a command line will not work because of formatting issues.
Exercise 4: Configure the Interceptor Runtimes
Overview
In this part, you will add the interceptors into their respective runtimes.

Procedure List
1. In the ContosoOrderApplication project, open the code view of the MainForm.cs
file.
2. In the MainForm_Load method, add code to install the BamTrackingService as a
WorkflowRuntime service for this instance of the WorkflowRuntime. This
configures the interceptor for WF. This application is using WF as part of its internal
logic.
BamTrackingService ts = new
BamTrackingService(
"server=.;database=BAMPrimaryImport;trusted_connection=yes",
5000);
_wr.AddService(ts);
3. In the ContosoOrderingService project – in Program.cs – examine the

BamCodeExtension class (this code is necessary for this version of the interceptors
as there isn’t any built-in way to add this behavior with just code – only
configuration).
4. In the ServiceHost initialization code in the Main method – add this behavior to the
ServiceEndpoint. This will configure the interceptor for WCF.
BamCodeExtension b = new
BamCodeExtension(
5000);
se.Behaviors.Add(b.Create());
Deploy the Orchestration Tracking Profile

Procedure List
5. In Windows Explorer, in the C:\AllFiles\LabFiles\Lab17 directory, double-click the
Contoso_TrackingProfile.btt file. This is the BAM interceptor configuration for the
BizTalk Orchestration.
6. Deploy this configuration by clicking on Tools–> Apply Tracking Profile. You will see
a warning about no corresponding Continuation elsewhere. Just press Yes and
proceed. You will get a confirmation that the profile was successfully applied.
Exercise 5: Test the Configuration
Overview
In this part, you will send messages through the interceptors and view the data that was
collected in BAM.

Procedure List
1. Select Debug –> Start Without Debugging from the Visual Studio Solution you have
open.
2. Send in a few orders by clicking on the Send Order button in the
ContosoOrderingApplication windows forms application and then clicking on the
Commit button to commit the transaction.
3. Open the BAM portal by selecting Start –All Programs – Microsoft BizTalk Server
2010 – BAM Portal Web Site)
4. Click on the Aggregations link under the ContosoView menu item on the left side of
the page.
5. Click Yes on any security dialog boxes that appear.
6. Verify that you can see data in the Pivot Table
7. You may go back to the Windows Application and send in additional orders and then
refresh the Pivot Table.
At this point the BAM data is being populated partially from the Workflow,
BizTalk, and WCF and being correlated using the BAM infrastructure.
Module 18: Receiving EDI Messages
(Optional)
Module objective:
Introduce the EDI capabilities provided by Microsoft BizTalk Server 2010, and demonstrate
how they can be used to receive and process EDI messages from trading partners.
Module Overview
Electronic Data Interchange (EDI) is one of the most prevalent means by which business
entities exchange data electronically. EDI usage entails message syntax and standards
(including ANSI X12 and UN/EDIFACT), messaging protocol, and transports.
BizTalk Server 2010 processes EDI messages using a combination of core BizTalk Server
features and EDI-specific BizTalk Server features. This enables BizTalk Server to perform the
processing that is unique to EDI messaging, while leveraging its core messaging functionality.
This module describes how basic receive-side EDI messaging works and how BizTalk Server
implements it. It also describes how a trading partner agreement definition in BizTalk Server
can be configured to enable receive-side EDI processing.
Lesson 1: Receive Side EDI Architecture
Lesson objective:
To understand how the EDI receive components fit in to the BizTalk Server messaging
architecture.
Lesson Overview
Microsoft BizTalk Server 2010 includes receive and send pipelines that are designed
specifically to parse and serialize EDI messages. This lesson describes the receive-side
architecture of EDI solutions on BizTalk Server.
EDI Solution Highlights
EDI with BizTalk Server 2010

Electronic Data Interchange (EDI) is the single most commonly used means by which
business trading partners exchange data electronically. EDI is largely messaging-oriented.
Documents are implemented as flat files that can include batched transaction sets. Batched
interchanges can contain multiple groups, each of which can contain multiple transaction
sets or messages.
EDI consists of specific data interchange methods agreed upon by standards bodies. The
primary EDI standards are X12 (standardized by ANSI and used primarily in North America)
and EDIFACT (standardized by the United Nations and used primarily outside the U.S.). Other
standards are derived from these, for example, HIPAA from X12 and KEDIFACT in Korea from
EDIFACT. The standards are closely parallel in message structure and acknowledgment
schemes, but have distinct differences.
BizTalk Server 2010 includes native functionality that provides support for EDI. EDI is built
into the product; it is not an add-in, such as an adapter or an accelerator. BizTalk Server
2010 processes EDI messages using receive and send pipelines specific to EDI that can parse
and serialize EDI messages.
Microsoft BizTalk Server 2010 components used for EDI processing include the following:
 The BizTalk EDI Application contains artifacts (including pipelines, orchestrations, and
schemas) that are needed to process EDI documents. The BizTalk EDI Application is
created when you configure the EDI feature in BizTalk Server Configuration.
 The BizTalk EDI Receive Pipeline (EdiReceive pipeline) parses EDI-encoded documents,
splits EDI batches, converts the EDI-encoded documents into XML encoding, performs
EDI and XSD validation, and performs HIPAA X12 sub-document splitting.
 The BizTalk EDI Send Pipeline (EdiSend pipeline) converts XML documents into X12 or
EDIFACT encoding, serializes EDI-encoded documents, and performs EDI and XSD
validation.
 The Trading Partner Management (TPM) user interface enables you to set processing
properties for trading partners engaging in EDI document exchange and AS2 document
transport.
 The batching orchestration batches EDI interchanges and sets context properties for
sending of the batched interchange. The routing orchestration handles the instances in
which messages match multiple batches, creating as many copies of the message as
required.
 The status reporting user interface provides comprehensive status of EDI interchanges
and correlated acknowledgments.
 Design time tools in Visual Studio enable you to generate an instance, validate an
instance, validate a schema, test a map, and validating a map.
 A schema repository includes X12, EDIFACT, HIPAA X12N 4010A XSD, EANCOM, and
control schemas.
 A migration tool (Party Migration Tool) enables you to migrate EDI party data from
BizTalk Server 2006 R2 or BizTalk Server 2009 to BizTalk Server 2010.
Receive Side Architecture
Receive Side Architecture

BizTalk Server 2010 includes the EDI Disassembler, a highly versatile pipeline component
that implements a number of core features required to process inbound EDI messages.
When given a message, the EDI Disassembler inspects the message body, and then it
interacts with the Trading Partner Management (TPM) system, the EDI reporting system and
the BizTalk messaging engine to process the message according to the instructions provided
by the trading partner agreements, the EDI protocols and the message schemas.
Lesson 2: EDI Party Resolution
Lesson objective:
Understand how BizTalk Server 2010 organizes and applies EDI configuration settings required to
process messages sent from trading partners.
Lesson Overview
One of the core value propositions of BizTalk Server 2010 is to empower BizTalk Server
customers to enable business-to-business (B2B) communication with their business
partners. To fulfill such business needs, enterprises need to model, store, and manage
information about:
 Partners and their businesses
 Rules of engagement with the partners – These include details such as which
message encoding protocol to use (EDI standards), which transport protocol to use
(AS2), etc.
While BizTalk Server 2010 continues to provide support for EDI and AS2, it rebuilds the
fundamental concepts around how to manage and store information about partners and
their business. EDI standards, AS2 messaging, and the new concepts put together form the
building blocks of a B2B communication or a Trading Partner Management (TPM) solution.
The Role of Party
A Party is a Trading Partner

Each participating organization in a business relationship is a trading partner. A trading
partner, also referred to as a “trading party” or a “party”, is at the root level and forms the
base for a trading partner solution.
BizTalk Server 2010 Trading Partner Management (TPM)

The BizTalk Server 2010 TPM solution can be used to model and store information of any
trading partner such as send port associations and certificates used to validate the identity
of a party. BizTalk Server makes use of such information for handling messages received and
sent through it. In BizTalk Server 2010, each organization participating in a business
relationship, including the home organization (the local host organization running the
BizTalk Server host), is represented as a trading partner.
Party Profiles
A trading partner has at least one business profile, also called a party profile, which
represents is the business face of an organization. Each business division in an organization
that trades with another business division in another organization is represented as a
business profile in a TPM solution. All the properties that define the B2B messaging
parameters specific to the business division, business unit, or a business system are captured
in its business profile.
Distinguishing between Parties and Party Profiles

For example, assume Fabrikam has two business divisions, “Payment” and “Shipping” and
Contoso has a business division “Invoices”. Considering Fabrikam has implemented BizTalk
Server 2010, it must create:
1. Two business profiles, one each for Payment and Shipping, under the trading
partner, Fabrikam. that
2. One business profile for Invoice under the trading partner, Contoso.
All trading partners that will be exchanging EDI messages using BizTalk Server must agree
upon communication parameters. After creating the Parties and Party Profiles in the BizTalk
Trading Partner Management UI, the organization hosting BizTalk Server must create the
trading partner agreements between the business profiles. As part of the trading partner
agreement, you set the properties for how BizTalk Server will exchange EDI or AS2 messages
with the trading partner’s systems.
Party Management
Managing Parties
Parties represent all of the organizations involved in a business trade. For example, if there
are two business organizations involved in a business trade, you must create a trading
partner for each of them.
Each business division identified within an organization requires a profile within the partner
representing the business division. For example, if an organization has “Purchase” and
“Supplies” business divisions, each of these divisions must be represented as a business
profile in BizTalk Server. Also, you must create the business profiles not just for the partner
representing your organization but also the partner with which you trade.
Each business profile defines the B2B protocol settings that include the message encoding
setting and the message protocol settings. These settings define how the B2B messages are
encoded and transported between two business profiles.
Trading Partner Agreements (TPA) between the business profiles define the encoding
and/or messaging protocols the two business profiles agree to use while exchanging
messages.
Agreements
Trading Partner Agreements

A Trading Partner Agreement (TPA) is an understanding between two business profiles to
use a specific message encoding protocol or a specific transport protocol while exchanging
B2B messages with each other.
Trading partner agreements play a key role in EDI support in BizTalk Server 2010. Most
configuration and administrative functions related to EDI processing in BizTalk Server are
performed by configuring the trading partner agreements between business profiles.
Example
For example, there could be an agreement between the “Shipping” and “Invoice” profiles of
Fabrikam and Contoso respectively to use the X12 encoding for business messages (encoding
agreement) and AS2 transport for exchanging messages (transport agreement). There can be
many such agreements between various business profiles. For example, there can be an
agreement between the “Payments” and “Invoice” profiles to use the EDIFACT message
encoding standard. All such agreements for all the profiles for a pair of trading partners
constitute a Partnership between the two trading partners.
EDI Fallback Settings
EDI Fallback Settings

If BizTalk Server cannot determine the agreement for either an incoming or outgoing
message, it will use the Fallback Agreement to process the incoming interchange or generate
the outgoing interchange.
BizTalk Server will use a fallback agreement only if it cannot determine the agreement for an
interchange. If an agreement has been determined, BizTalk Server will not use a property
value from the fallback agreement for a property that has not been defined for the
agreement between two trading partners.
EDI Party Resolution
EDI Party Resolution

When BizTalk Server receives an EDI message, the EDI receive pipeline performs trading
partner agreement lookup, schema discovery, and authorization processes to determine
how to process the message.
Agreement Resolution
The EDI receive pipeline performs a trading partner agreement resolution by performing a
series of steps to determine whether there is a match between header fields in the message
and properties in the agreement definition. Once BizTalk Server has determined the
agreement, it determines the document schema that applies to the interchange (see below).
It uses the properties associated with the matching agreement and the relevant schema to
validate and process the received message.
To perform agreement resolution, BizTalk Server proceeds as follows:
1. Resolve the agreement by matching the sender qualifier and identifier, and the
receiver qualifier and identifier, in the interchange header with those in the
properties of an agreement.
These four receive-side and send-side properties uniquely identify the trading
partner agreement. Using the four properties gives you more flexibility in receive-
side processing. For example, this method of agreement resolution may enable you
to send acknowledgments to multiple parties without creating multiple send ports.
2. If step 1 does not succeed, resolve the agreement by matching just the sender
qualifier and identifier in the interchange header with those in the properties of an
agreement. Also, because the first step did not succeed, it is safe to assume that
BizTalk Server will be receiving the message.
For X12, these fields are ISA05 and ISA06; for EDIFACT, these fields are UNB2.1 and
UNB2.2.
3. If step 2 does not succeed, use the Fallback Agreement properties.
EDI/X12 Configuration
Configuring Party Profile Settings

After creating the business profiles, which reflect the business divisions within an
organization, an enterprise needs to declare the parameters that define how the
communication between the business profiles takes place. These communication
parameters are defined as protocol settings. Protocol settings define how business
transactions are to be supported for a specific B2B protocol. Each business profile defines
the various settings for processing messages (encoding) or transmitting messages (transport)
for each of the B2B protocols over which the partner can communicate. The communication
parameters for the business profiles are defined under the following two categories:
Encoding Protocol Settings

The encoding protocols govern the structure and content of a B2B message. The encoding
protocol settings for a business profile define the encoding protocol that a business division
uses to send and receive B2B messages. Some examples of encoding protocols are X12,
EDIFACT, HL7, etc. As part of the encoding protocol you can provide various settings like
whether the sending party expects an acknowledgement, whether the messages will be
batched or sent individually, etc. You can always overwrite these settings as part of the
trading partner agreement.
Transport Protocol Settings
The transport protocol governs the transport channel used for sending the messages back
and forth between two partners. Since transport is essentially between two transport end
points, each business profile defines its own “transport end point” configuration and
communicates with a singular “transport end point” of its trading partner’s business profile.
As part of the transport protocol, you can provide various settings like whether the message
should be signed, whether the message should be encrypted, etc. You can always overwrite
these settings as part of the trading partner agreement.
EDI Profile and Agreement Information
Profile Settings
By defining the protocol settings, the business profiles declare the message format and the
transport protocol to be used for sending B2B messages between trading partners.
Example
Drawing on an earlier example, Fabrikam’s “Shipping” business profile can send and receive
messages with X12 encoding format sent over AS2 transport protocol. Similarly, Contoso’s
“Invoice” shipping profile can send and receive messages of both X12 and EDIFACT encoding
format over the AS2 transport protocol.
In this case, the “Shipping” business profile can only send and receive X12 messages. So, any
business profile communicating with “Shipping” business profile will have to adhere to the
properties setting for the “Shipping” business profile. However, in future, if the “Shipping”
business profile starts accepting messages with EDIFACT encoding, it only needs to set the
relevant properties to include EDIFACT support. The partner organization does not need to
create a new business profile for the same shipping division.
Profile Settings vs. Agreement Settings
Defining the protocol settings as part of a business profile is optional. If you don’t specify the
protocol settings as part of the business profile, you can always specify those in an
agreement. If you do not define the protocol settings as part of the business profile,
however, you will need to enter the values as part of each agreement for that business
profile, thereby defeating the scalability model of the new TPM solution. Hence, Microsoft
recommends that you define the protocol settings for each business profile. You can always
override those settings, if required, while creating a trading partner agreement.
Agreement Settings
Agreements are built upon the protocol settings defined for each business profile. You
implement a trading partner agreement between two business profiles by defining
properties for each business profile that will be exchanging messages. You set properties for
each business profile as an interchange receiver and as an interchange sender. To process an
incoming message or generate an outgoing message, BizTalk Server needs to know the
agreement that it resolves to, and the schema that applies to the message. If BizTalk Server
cannot determine the agreement, it will use the properties defined in the TPM interface for
the fallback trading partner agreement.
Inbound Configuration
Configuring Inbound Settings

After BizTalk Server has determined the agreement that resolves to the message, it must
determine the schema that it should use to validate and process the message. It does so
using the properties identified in the Agreement.
To determine the schema, BizTalk Server must first determine the schema namespace. The
EDI Disassembler will either use a default namespace for the standard schemas shipped with
BizTalk Server, or it will determine the namespace to be used for a custom schema.
The Agreement can be configured to specify a custom namespace for a given message. If no
match is found in the Agreement settings, the EDI Disassembler uses the default namespace
from the Agreement.
The EDI disassembler component will also verify that the interchange, group, and
transaction set control numbers are not duplicates, provided that the Agreement
configuration specifies that it should do so.
Demonstration: Configure Party EDI Settings
Demonstrate the steps required to configure a Party, a Profile and an Agreement.
Configure EDI Fallback Settings

2. In the BizTalk Administration tree view, right-click Parties, then click X12 Fallback
Settings.
This dialog box allows you to configure default settings for the X12 protocol. If
BizTalk cannot find a party profile or an agreement to provide configuration
settings for a given X12 interchange, it will apply the settings defined here.
3. Click the X12 Agreement Settings tab, and then click each item in the left pane to
provide a brief overview of the settings that are available for the X12 protocol.
4. Click Cancel to close the X12 Fallback Settings dialog box.
Create a New Party

1. In the BizTalk Administration tree view, right-click Parties, point to New, and then
click Party.
2. In the Party Properties dialog box, in the Name box, type Northwind.
Notice the check box labeled “Local BizTalk processes messages received by the
party or supports sending messages from this party.” This check box specifies
whether or not this BizTalk group is processing messages on behalf of the party
being configured. This box will be unchecked for external trading partners.
Since this BizTalk group will be processing messages on behalf of Northwind, this
box should remain checked.
3. In the left pane click Send ports, and then click Certificate.
As with previous versions, BizTalk allows you to associate Send ports and
Certificates with a party.
4. In the left pane, click General.
Notice that BizTalk Server 2010 does not offer the option to associate business
identifiers with a party. Those associations are now defined at a lower level,
specifically at the party profile level.
BizTalk provides the option to store Additional Properties for a party. These
properties are to be used simply for documentation purposes. BizTalk does not
use any of the Additional Properties in the course of its processing.
5. Click OK.
Configure the Party Profile

1. In the BizTalk Administration tree view, click Parties, and then in the center pane,
expand Northwind.
Notice that profile was automatically created for the Northwind party.
2. Double-click Northwind_Profile, then in the Profile Properties dialog box, in the left
pane click Identities
Notice that you can assign Business Identities at the profile level.
3. Click on the first row under Name, and click Mutually Defined (X12), then in the
Value box, type NORTHWIND.
Notice that the qualifier value is ZZ. Each type of business identity has a unique
qualifier. A D-U-N-S number, for example, has a qualifier value of 01. When a
business identifier is inserted in to a message, the identity value will be
concatenated with the qualifier, which enables EDI processors to distinguish
between the different types of identities that it might encounter.
In this case, the ZZ qualifier will prepended to the business name within our
messages, enabling BizTalk to determine that it should search our collection of
Mutually Defined (X12) identifiers to find the corresponding trading partner.
You can add any number of the various business identifiers that could be used to
identify this party.
4. Click OK.
Create an External Party
1. In the BizTalk Administration tree view, right-click Parties, point to New, and then
click Party.
2. In the name box, type Contoso.
3. Uncheck the check box labeled Local BizTalk processes messages received by the
party or supports sending messages from this party.
This box should be checked only when the BizTalk group will be sending or
receiving messages on behalf of the party that is being configured.
Since Contoso is an external partner, BizTalk will not be sending or receiving
messages on behalf of Contoso, so this option should be cleared.
4. Click OK.
Configure a Profile for the External Party

1. In the BizTalk Administration Console, in the center pane, expand Contoso, and then
double-click Contoso_Profile.
2. In the left pane of the Profile Properties dialog box, click Identities, then in the right
pane, in the Name list, click Mutually Defined (X12).
3. In the value box type CONTOSO.
4. In the upper right corner of The Profile Properties dialog box, click Add protocol
settings, then point to Transport Settings, then point to Encoding Settings, and then
click X12.
Notice that you can configure AS2, X12 or EDIFACT settings for a profile.
5. In the left pane, on the X12_Settings_1 tab, click Common.
You can assign a name to this group of settings. The name will show up in a list
of options when you are configuring agreements for this profile.
6. In the left pane, notice that you can configure both Inbound Settings, and Outbound
Settings.
The terms “Inbound” and “Outbound” should be interpreted from the perspective
of the party being configured. When configuring “Inbound” settings in a profile
of an external trading partner, the settings will apply for messages being sent
from BizTalk to the external trading partner.
When configuring ”Inbound” settings for a profile within your own organization,
the settings will apply to messages being received by BizTalk from external
trading partners.
7. Under Outbound Settings, under Interchange Settings, click Additional Identifiers.
Notice in the right pane, you can additional qualifiers that apply only to the
protocol being configured.
8. In the left pane, click each of the remaining options beneath the Outbound Settings
to provide a brief overview of the range of configuration settings that are available
9. In the left pane, under Inbound Settings, under Interchange Settings, click
Validation.
These options allow you to specify whether or not BizTalk should accept
duplicate messages, and it lets you specify exactly what constitutes a duplicate.
10. In the left pane, click Local Host Settings.
These options are disabled since this is an external trading partner (i.e. the check
box labeled “Local BizTalk processes messages received by the party or supports
sending messages from this party” in the Party properties is unchecked).
11. Click OK.
Configure an Agreement
1. Right-click the Northwind_Profile, point to New, and then click Agreement.
2. In the Name box, enter Contoso-Northwind PO.
3. In the Protocol list click X12.
4. Within the Second Party section, in the Party list click Contoso.
5. In the Protocol Set list for the Second Party, click X12_Settings_1.
The options in this list are filtered by the protocol and party specified in the
previous two steps.
6. In the left pane, click Contact Information and Additional Properties to provide a
brief overview of additional options for describing the Agreement.
Configure the Agreement for Messages Sent from Contoso to Northwind

1. Notice that at the top of the Agreements Properties dialog box, that there are two
additional tabs, Northwind->Contoso, and Contoso->Northwind.
These tabs allow you to define settings for the interchanges based on the
direction of the message flow. This application will be receiving messages.
2. Click the Contoso->Northwind tab.
3. In the left pane, under Interchange Settings, click each of the items to provide an
overview of the settings that are available.
These are the same as the settings as those that were shown in the Fallback
Settings dialog box at the beginning of this demo.
4. In the left pane, under Transaction Set Settings, click Local Host Settings.
Since Northwind will be receiving these messages, the local host settings are
enable.
5. In the Custom Target Namespace grid, in the second row, in the For ST1 column,
double-click the cell, and then in the drop-down list, click 850 - Purchase Order from
the list.
6. In the GS2 column, type CONTOSO.
7. In the Target namespace column, enter
http://schemas.microsoft.com/BizTalk/EDI/X12/2006/Contoso, then click Apply.
Now, when BizTalk receives an EDI 850 message from Contoso, it will use this
custom target namespace to identify the XML schema that it should use when
converting from EDI format to XML format.
Once the EDI message is converted to XML, BizTalk handles the message the
same as it handles any other XML message.
You could take advantage of the standard behavior of mapping within ports by
deploying a map that is specifically designed to handle Contoso 850 purchase
order messages (identified by the custom XML namespace). All other 850
messages would bypass the Contoso map.
8. In the left pane, click Identifiers.
This page shows the X12 identifiers that will be used to identify the two party
profiles that are associated with this agreement.
9. Delete the value CONTOSO from the Value (ISA6) box, and then click Apply.
Clicking Apply triggers a validation process. An error message will display any
required fields that are missing values, or any fields that contain invalid values.
10. Review the information in the Errors window, then click OK.
11. In the Value (ISA6) list, click CONTOSO, and then click OK.
12. In the BizTalk Adminstration Console, in the center pane, right-click Contoso, and
then point to New.
Notice that you can create additional profiles and additional agreements.
13. Click Northwind_Profile, and then click Contoso_Profile.
Notice that the Agreement between these two parties is displayed in the bottom
pane when either party is selected.
14. In the bottom pane, double-click the Contoso-Northwind PO Agreement.
Notice that you can no longer change the parties or the protocol specified by the
agreement, but you can make changes to the lower-level configuration settings.
15. Click Cancel.
While it is obviously beyond the scope of this module to cover all of the EDI
configuration settings that are available in BizTalk, upcoming demonstrations
will revisit some of the more common EDI settings in greater detail.
Lesson 3: EDI Interchange Processing
Lesson objective:
Understand how to apply schemas and pipelines to process inbound EDI messages.
Lesson Overview
When BizTalk Server receives an EDI message, it performs trading partner agreement lookup and
schema discovery, validates the message, sends an acknowledgment (if appropriate), and parses the
EDI batch. BizTalk relies on EDI schemas and pipelines to carry out the processing required to receive
an EDI message.
Schema Resolution for EDI Messages
EDI Schema Resolution

When BizTalk Server receives an EDI message, the EDI receive pipeline performs a trading
partner agreement resolution by performing a series of steps to determine whether there is
a match between header fields in the message and properties in the agreement definition.
Once BizTalk Server has determined the agreement, it determines the document schema
that applies to the interchange. It uses the properties associated with the matching
agreement and the relevant schema to validate and process the received message.
To determine the schema, BizTalk Server must first determine the schema namespace. The
EDI Disassembler will either use a default namespace for the standard schemas shipped with
BizTalk Server, or it will determine the namespace to be used for a custom schema.
The Local Host Settings page of the one-way agreement tab of the Agreement Properties
dialog box enables you to set up a grid of values to determine a custom namespace. If no
match is found in that grid, the EDI Disassembler uses the default namespace in the Target
namespace field marked for the default row.
X12 Schema Discovery
For X12-encoded messages, BizTalk Server determines a custom namespace using the
application sender identifier (GS02) and the transaction set ID (ST01) from the header of the
incoming interchange. It attempts to find a match between these values and the values for
the GS02 and ST01 properties in the Customize target namespace grid in the Local Host
Settings page (under Transaction Set Settings) of the bi-directional agreement tab of the
Agreement Properties dialog box. If it finds a match, it will use the target namespace
identified in the same row of the grid to determine which schema to us to validate and
process the message. If the target namespace is not determined, then the default target
namespace will be used. If no namespace is identified in the Target namespace field marked
for the default row, BizTalk Server will use the target namespace identified in the fallback
agreement properties for X12-encoded messages, which by default is
http://schemas.microsoft.com/BizTalk/Edi/X12/2006.
For X12 interchanges, after the target namespace is discovered, BizTalk Server determines
the schema using the following information:
 The target namespace just discovered
 The version/release in the first five characters of ST03 (if GS07 == X - Accredited
Standards Committee X12). If ST03 is not present/invalid or does not result in the
schema resolution, then the version is determined by the first five characters of
GS08 or of ISA12 (if GS07 != X).
 The DocType in ST01.
The EDI Disassembler concatenates the encoding type, version/release, and DocType to
determine the schema name, for example, "X12_00401_864". It then concatenates the
target namespace with the schema name, for example,
http://schemas.microsoft.com/BizTalk/Edi/X12/2006/X12#X12_00401_864.
EDIFACT Schema Discovery

For EDIFACT-encoded messages, BizTalk Server determines a custom namespace using the
message type (UNH2.1), message version number (UNH2.2), message release number
(UNH2.3), assigned code (UNH2.5), functional group ID (UNG2.1), and application send code
qualifier (UNG2.2) from the header of the incoming interchange. It then attempts to find a
match between these values and the values for the UNH2.1, UNH2.2, UNH2.3, UNH2.5,
UNG2.1, and UNG2.2 properties in the Customize target namespace grid (under Transaction
Set Settings) of the bi-directional agreement tab of the Agreement Properties dialog box. If it
finds a match, it will use the target namespace identified in the same row of the grid to
determine which schema to use to validate and process the message. If the target
namespace is not determined, then the default target namespace will be used. If no
namespace is identified in the Target namespace field marked for the default row, BizTalk
Server will use the target namespace identified in the fallback agreement properties for
EDIFACT-encoded messages, which by default is
http://schemas.microsoft.com/BizTalk/Edi/EDIFACT/2006.
For EDIFACT interchanges, once the target namespace is discovered, BizTalk Server
determines the schema using the following information:
 The target namespace just discovered.
 The message version number in UNH2.2.
 The message release number in UNH2.3.
 The message type in UNH2.1.
 The assigned code in UNH2.5.
The EDI Disassembler concatenates the encoding type, the version, the release, and the
message type to determine the schema name, for example, " EFACT_D94A_CONTEN". It
then concatenates the target namespace with the schema name, for example,
http://schemas.microsoft.com/BizTalk/Edi/Edifact/2006/EFACT#EFACT_D94A_CONTEN.
If UNH2.5 is present in the message, the EDI Disassembler will first attempt to find a
matching schema by using the value of UNH2.5 as part of the schema name, for example
“EFACT_D94A_CONTEN_TEST”. If no matching schema is found, the EDI Disassembler will fall
back to finding the schema without the UNH2.5 value.
EDI Schemas
BizTalk’s EDI Schemas

Microsoft BizTalk Server EDI and AS2 uses the following types of schemas to process
incoming messages and generate outgoing messages:
 Document schemas that define the message body
 Header service schemas that define the message envelope, and acknowledgment
control schemas that define the envelope and body of technical and functional
acknowledgments
 Interchange XML (batch) schemas that define the envelope of a preserved batch.
 A property schema that defines EDI context properties.
Schema Naming Convention

The default schema namespaces are:
 For X12 – http://schemas.microsoft.com/BizTalk/EDI/X12/2006
 For EDIFACT – http://schemas.microsoft.com/BizTalk/EDI/EDIFACT/2006
The naming convention for the X12 and EDIFACT encoding type is
<Encoding>_<Version><Release>_<Doctype>. Examples are the X12_00401_864.xsd schema
for the X12 864 document type (version 004, release 01) and the
EDIFACT_D01C_AUTHOR.xsd schema for the EDIFACT AUTHOR document type (version D01,
release C).
Schema Contents
A document schema starts with the ST transaction set header and ends with the SE
transaction set trailer for an X12-encoded document. It starts with the UNH message header
and ends with the UNT message trailer for an EDIFACT-encoded document. The schema
defines each data element of these headers and trailers.
A document schema then defines each segment within the transaction set/message and the
data elements within those segments. For example, the X12_00401_864.xsd schema defines
the BMG01, BMG02, and BMG03 elements of the BMG segments. The schema specifies the
characteristics of the segment's complex data type, such as the field order, delimiter type,
and namespace. If there are cross-field validation rules for the segment, the schema defines
the rules.
The schema specifies the characteristics of each data element within the segment, such as
the simple data type, minimum occurrences, minimum length, and maximum length.
If there is a loop in the message type, the schema defines the data elements within each
loop, the minimum and maximum occurrences of the loop, and whether the loop is bounded
or unbounded. The schema also defines nesting of a segment, and whether the loop is
explicit or implicit.
EDI Schemas
Deploying an EDI Schema

To create EDI solutions, you must install EDI schema files to deploy with your projects.
Because of the large size of the complete collection of these schemas, the schema files are
included in a self-extracting executable, rather than being installed by default with the
product. You must unzip these files onto your hard drive to make them available for your
projects.
Installing the EDI Schemas

You must install the Developer Tools and SDK component of BizTalk Server in order to have
access to the EDI schema files. If you do not install the Developer Tools and SDK component,
the \XSD_Schema folder will not be created and the MicrosoftEdiXSDTemplates.exe file will
not be available.
The compressed self-extracting executable is called MicrosoftEdiXSDTemplates.exe, and is
included in %BTSInstallPath%\XSD_Schema\EDI. The schema files in this executable include
EANCOM, EDIFACT, HIPAA, and X12 schemas. When you unzip them to your hard drive, they
will be stored in EANCOM, EDIFACT, HIPAA, and X12 folders.
If you upgrade Microsoft BizTalk Server to a later build, the MicrosoftEdiXSDTemplates.exe
file in your installation will be replaced with the MicrosoftEdiXSDTemplates.exe file
associated with the upgrade. If you plan to continue to use the schemas from the old
compressed file, you will no longer have access to the compressed file after the upgrade
unless you back up the old compressed file.
If you upgrade message schemas when you upgrade Microsoft BizTalk Server to a later build,
you may encounter issues using the updated schemas, or you may have to perform
additional updating steps.
EDI Schemas
Customizing an EDI Schema

You can modify an existing EDI schema that is shipped in BizTalk Server. When you and your
trading partners have agreed on modifications to standard schemas, and perhaps changed
the relevant Message Implementation Guideline (MIG) file, you can modify the schemas in
the BizTalk Editor in Visual Studio.
 An EDI schema is identified by its root name and its namespace. You cannot deploy two
schemas in the same BizTalk Group with the same root name and namespace. You
cannot modify the root name of any EDI schema, or add to the root name, because the
root name must contain the version and the document type in a standard naming
convention. As a result, if you want to deploy two schemas in the same BizTalk Group
with the same root name, you must use a different namespace for each one.
 It is not uncommon for a company to deploy in the same BizTalk Group a different
version of the same schema for two or more different trading partners. In this case, the
two schemas would have the same version and the same document type. To deploy
these two schemas, you would have to have different namespaces for each schema.
Common Scenarios
Some examples of the types of changes that you can make to an EDI in Visual Studio include:
To do this Do this
Change an enumeration In the properties for an element, open the

Enumeration Editor and add a value to, or
(such as the list of values in a code list)
delete a value from, the enumeration list.
Change the optionality of a data element Change the Min Occurs property. Change it
to 0 to make the field optional or to 1 to
make it required.
Change the maximum number of times that Change the Max Occurs property.
a data element can appear in the file
Change the number of characters in the data Change the Length property.
element
Change the data type of a data element Change the Base Data Type or Date Type
property.
Add a custom field Insert a child field element schema node and
set its properties.
Add a custom record Insert a child record schema node, set its
properties, and then add child field
elements.
Delete a custom field or record Delete a custom field or a custom record
with its child field elements.
EDI Schemas
EDI Schema Tools

The EDI Schema Editor Extensions enable you to perform design-time operations on EDI
schemas in Visual Studio. The tools are executed from the menu displayed when you right-
click a schema in the Solution Explorer pane. The Extensions also provide an option to
display the EDI schema information in a tabular view.
Validate Instance
This operation validates a single transaction set (without interchange and group headers) or
a complete batched interchange with multiple transaction sets (with interchange and group
headers). To validate an un-batched interchange, you need to remove the interchange and
group headers from the instance.
Generate an Instance
This operation generates either a complete batched interchange or a transaction set without
interchange and group headers. You must specify the separators, identifiers, and other
formatting used to generate the instance.
EDI Pipelines
EDI Pipeline Components

BizTalk Server 2010 provides three EDI pipeline components that can be included in custom
pipelines.
EDI Disassembler: The EDI Disassembler pipeline component performs trading partner
agreement lookup and schema discovery, validates the message, sends an acknowledgment
(if appropriate), and parses the EDI batch.
BatchMarker: The BatchMarker pipeline component prepares an interchange for batching
by promoting the BatchId, ToBeBatched, and ToBeRouted context properties that are
required for processing a batched interchange. How the BatchMarker component sets these
properties depends upon how many trading partner agreements subscribes to the batch
element.
EDI Assembler: The EDI assembler pipeline component performs agreement lookup and
schema discovery, validates the message, sends an acknowledgment (if appropriate), and
serializes the EDI batch.
EDI Pipelines
The EDI Disassembler Component

BizTalk Server performs most processing for received EDI-encoded interchanges in the EDI
Receive Pipeline. This pipeline includes the EDI disassembler pipeline component, which
performs the following processing:
1. Splits multiple interchanges in a single message into separate interchanges (if the
"DetectMID" pipeline property for the receive location is set to True). The EDI
Disassembler does so by searching for an interchange control header (ISA, UNA, or
UNB) even after an interchange control trailer (IEA or UNZ) has been encountered.
2. Validates the envelope.
3. Disassembles the interchange.
4. Processes trigger fields for HIPAA interchanges.
5. Validates EDI and partner-specific properties, as applicable. This includes EDI schema
validation, cross-field validation for X12-encoded messages (if configured), EDI
structural validation, and extended schema validation (if the schema was
customized with a node that has a non-EDI data type).
6. Verifies that the interchange, group, and transaction set control numbers are not
duplicates, if the checks are enabled in the Validation page (under Interchange
Settings) of the bi-directional agreement tab of the Agreement Properties dialog
box. Check the interchange control number against previously received
interchanges. Checks the group control number against other group control
numbers in the interchange. Checks the transaction set control number against
other transaction set control numbers in that group. If a duplicate is discovered, the
status report will indicate that a duplicate record exists.
7. Generates an XML document for each transaction set. On each XML file, promotes
the context property of BTS.MessageType, setting it to the schema name with
namespace.
8. Converts the entire interchange to XML if the Inbound batch processing option
property is set to one of the two Preserve Interchange values. This property can is
set from the Local Host Settings page under Interchange Settings of the bi-
directional agreement tab of the Agreement Properties dialog box. The receive
pipeline promotes the property ReuseEnvelope to identify the interchange as
preserved.
9. Generates a Technical and/or Functional acknowledgment (if configured). This can
include batching the acknowledgments (if configured). Promotes the context
property of BTS.MessageType, setting it equal to the control schema in the
http://schemas.microsoft.com/EDI/<X12 or EDIFACT> namespace (for example,
X12_997_Root for a 997 acknowledgment). Also promotes the
EDI.DestinationPartyName context property, which ensures that the
acknowledgment will be picked up for sending.
10. Performs HIPAA 276/277 (version 5010 only) 834, 835 (version 4010 only) and 837
document splitting, if applicable.
11. Promotes or writes properties to the message context..
EDI Pipelines
Built-in EDI Pipelines

The BizTalk EDI Receive Pipeline (EdiReceive pipeline) parses EDI-encoded documents, splits
EDI batches, converts the EDI-encoded documents into XML encoding, performs EDI and XSD
validation, and performs HIPAA X12 sub-document splitting.
The BizTalk EDI Send Pipeline (EdiSend pipeline) converts XML documents into X12 or
EDIFACT encoding, serializes EDI-encoded documents, and performs EDI and XSD validation.
The BatchControlMessageRecvPipeline processes messages delivered by a SQL adapter that
polls a BizTalk system table for new EDI batching instructions. The
BatchControlMessageRecvPipeline processes the messages with the XML Disassembler
component to produce batch control messages containing instructions for EDI batching
orchestrations to activate or terminate.
EDI Promoted Properties
Automatic EDI Property Promotions

The EDI Disassembler automatically promotes a number of properties that it reads from the
message body. The actual set of properties that it will promote depends on the protocol
that was used. Each of these properties could potentially contain the value of a key
identifier, providing a convenient means for message routing.
X12 EDIFACT
ISA05 Sender Qualifier UNB2.1 Interchange Sender ID
ISA06 Sender ID UNB2.2 Interchange Sender Code
ISA07 Receiver Qualifier UNB2.3 Address for Reverse Route
ISA08 Receiver ID UNB3.1 Interchange Recipient ID
ISA15 Usage Indicator UNB3.2 Interchange Recipient Code
GS01 Group ID UNB11 Usage indicator
GS02 Sender ID UNG1 Functional group ID

GS03 Receiver ID UNG2.1 Application Sender ID
GS07 Responsible Agency UNG3.1 Application recipient ID
GS08 Transaction Set Version UNH2.1 Transaction Set ID
ST01 Transaction Set ID UNH2.2 Message Version
ST03 Transaction Set Version UNH2.3 Message Release Number

Demonstration: Create a Custom EDI Schema
Demonstrate how to add an EDI schema to a BizTalk project, and then customize it and deploy it
to the BizTalk runtime.
Add an EDI Schema to a BizTalk Project

1. Open the following Visual Studio Solution.
C:\AllFiles\DemoCode\Module18\EDIReceiving.sln
2. Right-click the EDIReceiving project, and then click Add, and then click Existing Item,
and add the following schema file.
C:\AllFiles\DemoCode\Module18\X12_00401_850.xsd
This schema defines the structure of an EDI 850 purchase order message.
Notice the size of this schema, it is over 3 MB, and it is only one of many EDI
schemas that are included with BizTalk.
Use the EDI Schema Editor Extension

1. In Solution Explorer, double-click the X12_00401_850.xsd file to open it in the
Schema Editor.
2. In the Properties window, click the Schema Editor Extensions property, then click
the ellipsis (…) next to it.
3. In the Schema Editor Extensions dialog box, notice that the EDI Schema Editor
Extensions are enabled, and then click Cancel.
The EDI Schema Editor adds new properties to particular nodes throughout the
schema.
4. With the <Schema> node selected, in the Properties window, click the CodeList
Database property.
This is one of the properties added by the EDI Schema Editor extensions. You can
provide an .mdb file that contains data for populating lists of codes.
5. At the bottom of the center pane, click the EDI tab.
This presents a more EDI-friendly view of the schema. It is much easier than
using the conventional XSD view and editing values in the Properties window.
6. Scroll to the right, and show the Min Occurs, Max Occurs, Minimum Length,
Maximum Length and Loop fields.
7. Scroll down to find an EDI field that is within a Loop, and then click it.
Notice in the field is automatically selected in the tree view.

This is simple an XML schema with some extra metadata added to it for the
purposes of EDI. You can promote properties, just as you can with any other
BizTalk schema. You can also customize it. You can add data validation rules. In
this case, we will customize the namespace of this schema, since it defines
messages that we will be receiving from Contoso.
Customize and Deploy an EDI Schema

1. In the tree view, click the <Schema> node, then in the Properties window, click the
Target Namespace field, and add Contoso to the end of the namespace string.
2. On the File menu, click Save All, and in the Clean Up Global Data Types dialog box,
leave all of the boxes unchecked, and click OK.
3. Right-click the EDIReceiving project, then click Deploy.
Configure an EDI Receive Location

1. In Windows Explorer, locate and open the following file.
C:\AllFiles\DemoCode\Module18\SamplePO.txt
Notice the second line. It is a GS segment that identifies the sender as Contoso,
and the receiver as Northwind.
Notice the third line. It is an ST segment that identifies this message as an EDI
850 (purchase order) message.
The EDI disassembler component will parse this file to extract the values of these
fields, and use the values to determine the agreement between Contoso and
Northwind that is associated with this message. It will discover that this
message is associated with a custom XML namespace, so it will load the schema
that we just deployed to process this message.
2. In the BizTalk Administration Console, right click the Applications node, and then
click Refresh.
3. Expand the EDIReceiving application.
4. Right-click Receive Ports, point to New, and then click One-way Receive Port, and
name it EDIContosoReceive.
5. In the left pane, click Receive Locations, and in the right pane click New.
6. Name the receive location EDIFILE, then in the Type list, click FILE, and then click
Configure.
7. In the Receive folder box, enter
C:\AllFiles\DemoCode\Northwind\Ports\EDIReceive, and in the File mask box,
enter *.txt.
8. Click Advanced settings, then check the Rename files while reading check box, and
then in the Polling interval box, enter 5000, then click OK twice.
9. In the Receive Location Properties window, click the Receive pipeline list, and
notice that there are no EDI pipelines shown.
All of the build-in EDI components are deployed to the BizTalk EDI Application, so
we need to add a reference to that application in order to use those components
in our EDIReceiving application.
10. Click OK twice.

11. In the BizTalk Administration tree view, click the BizTalk EDI Application, and then
click the Pipelines node beneath it.
These are the built-in EDI pipelines that are deployed when the EDI option is
selected during BizTalk Configuration.
12. Right-click the EDIReceiving application, and then click Properties.

13. In the Application Properties dialog box, click References, and then in the right pane,
click Add.
14. Check the BizTalk EDI Application check box, and then click OK twice.
15. Click Receive Locations, and then double-click EDIFILE.
16. In the Receive pipeline list, click EdiReceive.
17. Click the ellipsis (…) next to the Receive pipeline list
Notice that this pipeline includes the EDI disassembler component. It also
includes the Batch Marker component, but that will be covered in a later demo.
18. Click Cancel, and then click OK.

1. Right-click Send Ports, then point to New, and then click Static One-way Send Port,
and name it EDISend.
2. In the Type list, click FILE, and then click the Configure button.
3. In the Destination folder box, enter
C:\AllFiles\DemoCode\Northwind\Ports\EDISend, and then click OK.
5. In the right pane, click the Property list and notice the various EDI properties that
are available.
6. Click EDI.GS02, and in the Value box, enter CONTOSO.
7. On the second line, in the Property list, click EDI.ST01, and in the Value box, enter
850.
9. Right-click the EDIReceiving application, then click Start.
Notice that you have the option of starting the application that is referenced by
EDIReceiving. If the EDIReceiving application were using any of the built-in EDI
orchestrations, then the BizTalk EDI Application would need to be started. In this
case, the EDIReceiving application is simply using a pipeline, so the BizTalk EDI
Application does not need to be started.
10. Uncheck the BizTalk EDI Application check box, and then click Start.

1. In Windows Explorer, copy the C:\AllFiles\DemoCode\Module18\SamplePO.txt file
to the C:\AllFiles\DemoCode\Northwind\Ports\EDIReceive folder.
2. When BizTalk has finished processing the file, navigate to the
C:\AllFiles\DemoCode\Northwind\Ports\EDISend folder and open the message
that was created.
This is the EDI message converted to its XML format. Notice the custom XML
namespace.
Notice the ST node indicating that this is an 850 message. Scroll through the
message content to see the purchase order contact information, and the items
that are included in the order.
Notice also, that the EDI party information has been extracted from the
message, and that it is no longer contained in the message body. The party
identifiers are stored in message context properties.
Lesson 4: Acknowledgements, Debatching and Reporting
Lesson objective:
To understand how to enable EDI Acknowledgements, De-batching and EDI Reporting.
Lesson Overview
BizTalk Server 2010 also supports EDI Acknowledgements, De-batching and Status Reporting.
Acknowledgements
Acknowledgments indicate the status of EDI message transmission. After BizTalk Server
receives an EDI interchange, it will return one or more acknowledgments to the sender of an
EDI interchange, depending upon which acknowledgments have been enabled.
De-batching
When BizTalk Server receives a batched EDI interchange, it can either split the interchange
into its transaction sets, processing each one separately, or it can preserve the interchange,
processing all transaction sets as a group.
Reporting
EDI status reporting enables operations personnel to track the status of EDI and AS2
transmissions. If enabled, status reports provide comprehensive status of a document
exchange transaction, including an interchange and any acknowledgments correlated to the
interchange.
Acknowledgements
Generating EDI Acknowledgements

Acknowledgments indicate the status of EDI message transmission. After BizTalk Server
receives an EDI interchange, it will return one or more acknowledgments to the sender of an
EDI interchange, depending upon which acknowledgments have been enabled.
Based on the level of validation, EDI message acknowledgments fall into two types:
 A Technical Acknowledgment generated as a result of header validation. The
technical acknowledgment reports the status of the processing of an interchange
header and trailer by the address receiver.
 A Functional Acknowledgment generated as a result of body validation. The
functional acknowledgment reports each error encountered while processing the
received document.
BizTalk Server can return both technical and functional acknowledgments in response to a
single interchange. BizTalk Server returns a single technical acknowledgment for each
interchange. For X12 interchanges, it will return a functional acknowledgment for each
group received. For EDIFACT interchanges, it will return a functional acknowledgment for
each interchange, no matter how many groups that interchange contains.
The EDI receive pipeline will generate an acknowledgment if any of the following conditions
are met:
 A data element in the received interchange prompts the acknowledgment. For X12-
encoded messages, the receive pipeline will generate a technical TA1 ACK if the
ISA14 data element is set to 1. For EDIFACT-encoded messages, the receive pipeline
will generate a technical CONTRL ACK if the UNB9 data element is set to 2, and it will
generate a functional CONTRL ACK if the UNB9 data element is set to 1.
 An agreement property prompts the acknowledgment. For X12 interchanges, these
properties are the TA1 Expected and 997 Expected properties in the
Acknowledgements page of the bi-directional agreement tabs of the Agreement
Properties dialog box. For EDIFACT interchanges, these properties are the Receipt of
message (CONTRL) expected and Acknowledgement (CONTRL) expected in the
Acknowledgements page of the bi-directional agreement tabs of the Agreement
Properties dialog box. When you enable a type of acknowledgment, you can also
indicate whether to batch that type of acknowledgment.
 A global property prompts the acknowledgment when no agreement is determined
for the interchange. These properties are the:
o TA1 Expected and 997 Expected properties in the Acknowledgements page

of the agreement tab of the X12 Fallback Settings dialog box.
o Receipt of message (CONTRL) expected and Acknowledgement (CONTRL)
expected in the Acknowledgements page of the agreement tab of the
EDIFACT Fallback Settings dialog box.
For EDIFACT, the EDI receive pipeline will return two separate CONTRL acknowledgments if
both a technical acknowledgment and a functional acknowledgment are prompted. The
technical CONTRL ACK will include receipt acknowledgment information only. The functional
CONTRL ACK will include both receipt information and functional acknowledgment
information.
Synchronous and Asynchronous Acknowledgments

You can choose to send EDI acknowledgments either synchronously or asynchronously. If
synchronous, BizTalk Server will route the acknowledgment directly to the send pipeline of a
two-way request-response receive port. If asynchronous, BizTalk Server will route the
acknowledgment to the MessageBox, and a send port will subscribe to that message.
To specify that BizTalk Server sends the acknowledgment synchronously, select Route ACK to
send pipeline on request-response receive port in the Local Host Settings page (Receiver’s
Settings section) under Interchange Settings in the bi-directional agreement tab (for both
X12 and EDIFACT agreements). If you clear this property, the send pipeline of the two-way
receive port must be set up to return an EDI interchange.
If a scenario uses a request-response receive port, and both a technical acknowledgment
and a functional acknowledgment are enabled, the technical acknowledgment will be sent
back synchronously, and the functional acknowledgment will be sent back asynchronously.
When receiving an EDIINT/AS2-encoded message over HTTP/HTTPS, if an MDN is sent out in
response to a MIME wrapped EDI payload (on the same socket), then an EDI
acknowledgment will not be sent out synchronously. If in this case the Route ACK to send
pipeline on request-response receive port property is checked, BizTalk Server will ignore the
property.
EDI Debatching
Debatching
When BizTalk Server receives a batched EDI interchange, it can either split the interchange
into its transaction sets, processing each one separately, or it can preserve the interchange,
processing all transaction sets as a group.
You determine batch processing in the Local Host Settings page of the one-way agreement
tabs in the Agreement Properties dialog box for both X12 and EDIFACT agreements. When
you preserve the interchange, you have the choice to suspend either the interchange or the
transaction sets if an error occurs.
Splitting a Batched EDI Interchange

The EDI receive pipeline splits an incoming EDI interchange batch if you have set the inbound
batch processing option agreement property to Split Interchange as Transaction Sets.
When the EDI receive pipeline splits an incoming batched EDI interchange, it creates one
XML file for each EDI transaction set/message. The pipeline promotes the entire interchange
and group headers into the context of each transaction set split from the interchange. It also
promotes certain specific interchange and group headers, such as ISA6, GS1, and GS2, so
that these fields can be used for routing. You can mask the security information in the
header by selecting the Mask security/authorization/password information property.
When BizTalk Server attempts to split an interchange into transaction sets, any error in
certain ISA (ISA1 through ISA13) or UNB header fields will lead to the interchange being
rejected. This is also the case when the interchange control number is a duplicate, if the
check for a duplicate interchange control number is enabled in the agreement or fallback
agreement properties. An error in other interchange header fields (other than ISA1 through
ISA13 for X12 interchange) or in the group header fields would not cause interchange
processing to fail.
If Split Interchange as Transaction Sets - suspend Transaction Sets on Error is selected in
agreement properties, BizTalk Server will suspend the transaction set if an error occurs. If
Split Interchange as Transaction Sets – suspend Interchange on Error is selected, BizTalk
Server will suspend the interchange.
Each XML batch element is routed to the MessageBox, and processed by the send ports or
orchestrations that subscribe to the batch element. The ordering of transaction sets in the
interchange may not be retained after they are processed as split messages. On the receive
side, the messages will be processed in the order that they appear in the interchange, and
they will be placed in the MessageBox in that order, but you would have to use convoys or
ordered delivery send ports to maintain that order on the send side.
EDI SubDocument Splitting
HIPAA SubDocument Splitting

EDI interchanges for HIPAA commonly have multiple child/sub documents within a single
transaction set, as bounded by the ST/SE headers. The EDI receive pipeline supports creation
of separate HIPAA subdocuments from such a transaction set. This is different from non-
HIPAA EDI interchanges, in which a single transaction set is processed as a single message.
SubDocument Splitting Schemas

BizTalk Server supports splitting of the following HIPAA document types through native
schemas:
 HIPAA version 4010 documents: 834 Enrollment, 835 Claim Payment and three
variants of 837 Claim
 HIPAA version 5010 documents: 276/277 Claim Status – Request and Response, 834
Enrollment and three variants of 837 Claim
BizTalk Server provides two versions of schemas for each of these three document types. For
each document type, the schema supporting splitting is identified by the ‘Multiple’ tag in the
file name. The other schema does not support subdocument splitting.
In some scenarios, both splitting and non-splitting schemas may be required. This will be
supported through the use of a custom target namespace for one variant of the schema.
How Subdocument Splitting Is Enabled

The splitting of HIPAA subdocuments is enabled by three annotation entries in the HIPAA
schema. The first two are entries for the schema in the appinfo annotation, which must be
set to yes:
subdocument_break = "yes" Split_Without_Sibling_Data = "Yes"
The third annotation entry is located at the appropriate record levels within the HIPAA
schema. This property must also be set to yes.
subdocument_creation_break = "yes"
A HIPAA interchange will be split into subdocuments only if the subdocument creation break
annotation within the HIPAA schema is set to "yes", and the Inbound batch processing
option party property is set to "Split Interchange as Transaction Sets". If the Inbound batch
processing option party property is set to preserve the interchange, the EDI disassembler
will not split the interchange into subdocuments. In this case, the EDI disassembler will
ignore the annotation. No warning will be raised in the event viewer if this occurs.
How SubDocuments are Processed

The EDI disassembler in the EDI receive pipeline splits the subdocuments. After the receive
pipeline validates the incoming interchange and generates the appropriate
acknowledgments, it routes each separate subdocument to the MessageBox. Each
subdocument is structurally and syntactically valid; however, business level summaries,
transaction set totals, and transaction set control numbers are expected to be out of
synchronization. The send pipeline will overwrite the value of the existing segment count in
SE01 of each subdocument (which came from the original transaction set) to the count of
included segments in the subdocument. The receive pipeline will also reset the transaction
set control numbers in each subdocument so that the subdocument do not have duplicate
control numbers. This ensures that send-side processing will not fail.
If a transaction set fails EDI or extended validation during subdocument splitting, the
individual failing transaction set is suspended.
A send port that subscribes to the subdocuments will pick up each subdocument from
MessageBox, serialize the XML subdocuments, batch them (if enabled), validate them, and
send them. The send pipeline updates the count of segments data element (SE01).
EDI Reporting
EDI Reporting
EDI status reporting enables operations personnel to track the status of EDI and AS2
transmissions. If enabled, status reports provide comprehensive status of a document
exchange transaction, including an interchange and any acknowledgments correlated to the
interchange. These reports provide data on receipt, validation, batching, and
acknowledgment processing of EDI and AS2 messages.
You can use these reports to get the status of pending and unacknowledged interchanges,
complete interchanges, error scenarios, or business scenarios. With these reports, you can
do the following:
 Confirm the receipt of interchanges
 List outgoing interchanges awaiting acknowledgment
 List all rejected interchanges received
 List outgoing interchanges that are reported as rejected or partially accepted.
Data included in the status reports is obtained from interchange control segments, such as
ISA, TA1, GS, UNB, and UNG (with the exception of the Functional ACK status).
Status Reporting UI
EDI and AS2 status reports are available from the BizTalk Server Administration Console.
From the Group Hub page of the BizTalk Group node, you have links to EDI interchange and
correlated acknowledgment status, batch status, and AS2 message and correlated MDN
status. Each of these reports provides a range of status parameters that you can include or
exclude from a query expression, enabling you to build the status report that they need.
In addition to seeing the status of an EDI interchange, you can also view the transaction sets
in an interchange. You do so by enabling the storage of message payloads in the EDI tables
of the tracking (BizTalkDTADb) database. You can view the transaction sets by using the view
details command in the status reporting UI.
You can also store inbound or outbound AS2 messages or MDNs in the non-repudiation
database. You can view the transaction sets or AS2 messages by right-clicking the message in
the status report and selecting the appropriate command.
Demonstration: EDI Reporting and Acknowledgments
Demonstrate how to enable EDI reporting and acknowledgements.
Enable EDI Reporting

1. In the BizTalk Administration Console, right-click Parties, and then click X12 Fallback
Settings.
2. In the X12 Fallback Settings dialog box, check the Activate EDI reporting check box,
and then click OK.
3. In the BizTalk Administration tree view, right-click Parties, and then click EDIFACT
Fallback Settings.
4. In the EDIFACT Fallback Settings dialog box, check the Activate EDI reporting check
box, and then click OK.
5. In the BizTalk Administration tree view, click Parties, then in the center pane,
double-click the Contoso-Northwind PO Agreement.
6. In the Agreement Properties dialog box, in the Common Host Settings section, check
the Turn ON reporting check box.
Enable EDI Acknowledgements
1. Click the Contoso->Northwind tab, and then in the left pane, click
Acknowledgements.
2. Check the 997 Expected check-box.
3. In the left pane click Local Host Settings, then in the right pane, clear the Route ACK
to send pipeline on request-response receive port check box.
This application will send the acknowledgement messages out through a

separate send port.
4. Click the Northwind->Contoso tab.

5. In the left pane, click Send Ports.
6. In the right pane, in the Name list, click <New send port…>
7. In the Specify an application for the send port list, click EDIReceiving, and then click
OK.
8. Name the send port ACK_Port, and in the Type list, click FILE.
9. Click the Configure button, and in the Destination folder box, enter
C:\AllFiles\DemoCode\Northwind\Ports\EDISend.
10. In the File name box, enter ACK_%MessageID%.xml, then click OK.
11. In the left pane, click Filters, and in the right pane, in the Property list, click
EDI.GS03.
12. In the Value box, enter CONTOSO.
13. In the second line, in the Property list, click EDI.ST01, and in the Value box enter
997.
14. Click OK twice.
15. In the BizTalk Administration tree view, right-click Parties, and then click Refresh.
16. In the center pane, double-click Contoso, and in the Party Properties dialog box, in
the left pane, click Send ports.
Notice that the ACK_Port is listed as a send port belonging to the Contoso party.
17. Click Cancel.
Test the Acknowledgements

1. In the BizTalk Administration tree view , click Send Ports, then right-click ACK_Port,
and then click Start.
2. In the BizTalk Administration tree view, expand Platform Settings, then click Host
Instances, then right-click BizTalkServerApplication, and then click Restart.
This will ensure that the BizTalk host instance to picks up the EDI reporting
configuration changes.
3. Delete all files from the C:\AllFiles\DemoCode\Northwind\Ports\EDISend folder.

C:\AllFiles\DemoCode\Northwind\Ports\EDISend folder and notice that there are
both an EDI 850 message and an acknowledgement message.
6. Double-click the ACK_{Guid}.xml file, and notice that it is a 997 message.
This 997 message is formatted as XML, but in the next module, we will use a
send pipeline to convert XML messages to EDI format.
Test the Reporting

1. In the BizTalk Administration Console, click BizTalk Group, and in the center pane,
on the Group Hub tab, scroll down to the EDI Status Reports section.
2. Click EDI Interchange and Correlated ACK Status.
3. In the Query Expression, for the Status field, in the Operator list, click Equals, and in
the Value list, click Accepted.
4. Click Run Query.
Notice that there are no results reported, even though the Interchange Date
Time is set to one day ago.
5. In Windows Explorer, double-click C:\AllFiles\DemoCode\Module18\SamplePO.txt.
Notice in the second line, that the date is set to 20101002. The value of the
Interchange Date Time value is extracted from the EDI message. It does not
necessarily match the date that BizTalk received the message.
6. In the BizTalk Administration Console, in the center pane, in the Interchange Date
Time Value, enter 10/1/2010, and then click Run Query.
Notice that one interchange was found. The report summary includes the Sender
party and the Receiver party, the Direction of the interchange, and the
Interchange Status is Accepted.
7. Double-click on the Interchange record.
Notice that you can see additional information about the interchange.
8. Click Close.
9. Click the Group Hub tab, and under EDI Status Reports, click Interchange
Aggregation Report.
10. Change the Interchange Date Time to 10/1/2010, and then click Run Query.
Notice that the query result includes a Count of interchanges.

12. When BizTalk has finished processing the file, switch back to the BizTalk
Administration Console, and click Run Query.
Notice that the result now reports two interchanges of this type.
Lab: Receiving EDI Messages
Overview
In this lab you will be configuring a BizTalk Application to be able to successfully process
incoming EDI documents. By deploying an EDI Schema and configuring a party, you’ll be able
to use the EDI components to translate EDI messages to XML. After completing this lab, you
should understand how to: deploy EDI Schemas, create Parties, configure Party specific EDI
properties and configure BizTalk Server to process EDI message.
Procedure List
window.
Start.

Procedure List
Exercise 1: Deploying the EDI Schema and configuring BizTalk Server
Overview
In this part, you will deploy an EDI Schema to BizTalk, and then you will configure a receive
port and a send port to handle an EDI message.
Deploy the Schema

Procedure List
1. Open the following solution:
C:\AllFiles\LabFiles\Lab18\Contoso.EDI.Artifacts\Contoso.EDI.Artifacts.sln
2. Right-click on the Contoso.EDI.Artifacts project, point to Add, then click Existing

Item, and then browse to the C:\AllFiles\LabFiles\Lab18 directory. Click
X12_00401_850.xsd, and then click OK.
Normally you would expand the files in %BTSInstallPath%XSD_Schema\EDI
\MicrosoftEdiXSDTemplates.exe to get the EDI schemas you want to use. For
purposes of this lab, we’ve pre-extracted the specific schema file for you (since
extracting the schemas can take quite a while depending on the speed of your
computer).
3. Right-click on the Contoso.EDI.Artifacts project and click “Deploy”.
Configure the application.

Procedure List
1. Open the BizTalk Administration Console (On the Start menu, click All Programs,
then click BizTalk Server 2010, and then click BizTalk Server Administration).
2. Expand BizTalk Server 2010 Administration, BizTalk Group, and Applications.
3. Right-click on the ContosoEDI application and click Properties.
4. Click the References node in the left side of Application Properties dialog, and then
in the right pane, click the Add button.
5. Check the box next to the BizTalk EDI Application. Click OK.
Since all of the BizTalk EDI artifacts are deployed to this application, in order to
use those artifacts (like pipelines) you must add a reference to this application.
6. Press OK to exit the Properties dialog.
Create a Receive Location and Port.
Procedure List
1. In the ContosoEDI application, right-click the Receive Ports node and point to New,
then click One-Way Receive Port.
2. In the Name box, enter PartnerReceivePort.
3. In the left pane, click Receive Locations, then in the right pane, click New.
4. Name the loEcation EDIFileLocation and in the Type list, click FILE.
5. Click Configure, and set the Receive Folder to C:\AllFiles\LabFiles\Ports\EDIReceive
and change the File Mask to *.txt.
6. Click OK once to return to the Receive Location Properties dialog box, and in the
Receive Pipeline list, click EdiReceive, and then click OK twice.
If you don’t see EDIReceive make sure that you’ve created the reference to the
BizTalk EDI Application from this application.
Create a Send Port.

Procedure List
1. In BizTalk Server Administration, right-click on the Send Ports node under the
ContosoEDI application, point to New, and then click Static One-way Send Port.
2. After setting the properties using the table below, click OK to close the dialog.
Name Value
Name EDISend
Transport FILE
Destination Folder C:\AllFiles\LabFiles\Ports\EDISend
(Under Transport – click
the Configure Button)
Send Pipeline PassThroughTransmit

Filters BTS.ReceivePortName== PartnerReceivePort
(Note – this subscription for the Send Port is just
for testing purposes. Note the list of EDI-specific
properties that are available as Filter properties
which might be used in a messaging-only EDI
application with BizTalk)
3. In the BizTalk Administration tree view, right-click the ContosoEDI application, and
then click Start twice.
Exercise 2: Creating the Parties
Overview
In this part, you will create a party to represent the sender of a message that will be received
into BizTalk Server.
Create the Party

Procedure List
1. In the BizTalk Administration tree view, find the Parties node.
2. Right-click Parties, point to New, and then click Party.
3. In the Name box, enter BIGWINESELLER, then click OK
4. Click the Parties node, then expand the BIGWINESELLER party in the center pane
and right-click the BIGWINESELLER_Profile item and click Properties.
5. In the left pane, click Identities.
6. Fill out the X12 related identity properties with the following values:
Name Value
Mutually Defined (X12) SENDERISA
Duns Plus Suffix 0073268795005
7. In the Profile Properties dialog box, in the menu bar click Add protocol settings,
point to Encoding settings, and then click X12.
8. In the X12_Settings_1 panel, navigate to Inbound Settings, then Interchange
Settings, and then Validation.
9. Ensure that the check box next to Interchange control number is cleared.
These settings allow you to control how the EDI messages are processed
including validation, namespaces to use, etc.
10. Click OK to close the Profile Properties dialog box.
11. Find the Contoso850.txt file in the C:\AllFiles\LabFiles\Lab18 directory for this lab.
Open and examine the EDI message (pay special attention to the ISA line).
Notice that the ISA number is the same as that defined in the party properties,
thus providing BizTalk the information it needs to resolve the party
12. Place a copy of that file in C:\AllFiles\LabFiles\Ports\EDIReceive
13. In the C:\AllFiles\LabFiles\Ports\EDISend directory you should find an XML file.
Open it and examine it – it should be the XML representation of the 850.
Whenever you plan on using the EDI capabilities in BizTalk Server for receiving
EDI messages you’ll need to follow the steps of this activity at a minimum.
Module 19: Sending EDI Messages
(Optional)
Module objective:
Introduce the EDI capabilities provided by Microsoft BizTalk Server 2010, and demonstrate
how they can be used to receive and process EDI messages from trading partners.
Module Overview
This module describes how basic send-side EDI messaging works and how BizTalk Server
implements it. It also describes how a trading partner agreement definition in BizTalk Server
can be configured to enable send-side EDI processing.
Lesson 1: Introduction to EDI Sending
Lesson objective:
Understand how to apply the EDI capabilities of BizTalk Server 2010 to send messages to trading
partners.
Lesson Overview
Microsoft BizTalk Server 2010 includes receive and send pipelines that are designed
specifically to parse and serialize EDI messages. This lesson describes the send-side
architecture of EDI solutions on BizTalk Server.
Sending EDI Messages
EDI Sending
When BizTalk Server sends an EDI message, it performs a number of operations, including
agreement lookup and schema discovery; it validates the message, sends an
acknowledgment (if appropriate), and serializes the EDI batch.
As with receiving EDI messages, Microsoft BizTalk Server 2010 provides components for
implementing EDI sending solutions, include the following:
 The BizTalk EDI Send Pipeline (EdiSend pipeline) converts XML documents into X12
or EDIFACT encoding, serializes EDI-encoded documents, and performs EDI and XSD
validation.
 The Trading Partner Management (TPM) user interface enables you to set
processing properties for trading partners engaging in EDI document exchange and
AS2 document transport.
 The batching orchestration batches EDI interchanges and sets context properties for
sending of the batched interchange. The routing orchestration handles the instances
in which messages match multiple batches, creating as many copies of the message
as required.
Send Side Architecture
Send Side Architecture

When BizTalk Server generates and sends an outgoing EDI message, it processes the
message in the EDI Send Pipeline (Microsoft.BizTalk.DefaultPipelines.EDISendPipeline). The
EDI Send Pipeline simply plugs in to the core messaging architecture of BizTalk.
EDI Assembler
EDI Assembler Pipeline Component

BizTalk Server performs most processing of EDI-encoded interchanges to be sent in the EDI
Send Pipeline. This pipeline includes the EDI assembler pipeline component, which performs
the following processing:
 Trading partner agreement lookup and schema determination.
 Serializes the EDI message, converting the XML document into X12- or EDIFACT-
encoded data.
 If the message data contains characters that are also used as X12 separators, the
send pipeline can be configured to replace the characters in the payload with
another character.
 If the EDI message is a batched interchange, the send pipeline picks up the
interchange from the BizTalk MessageBox after the batching orchestration has built
the batch.
 Validates the outgoing message.
 Creates the EDI envelope according to the party properties or EDI envelope
properties specified at runtime.
 Processes acknowledgments received.
Schema and Parsing
Schema Resolution
The EDI send pipeline determines which schema that applies to the message from the
schema name and schema namespace contained in the intermediate XML file for each
transaction set (either as doc type information or in the root node).
For an interchange that has been preserved, the send pipeline uses the doc type information
in the individual transaction sets of the intermediate XML file for the complete interchange.
It uses the control segment schemas for processing the envelope segments.
Determining the Party
Party and Agreement Resolution

The EDI send pipeline performs party and agreement resolution by performing a series of
steps to determine whether there is a match between the outgoing interchange and the
properties of a party and agreement. Once BizTalk Server has determined the party and
agreement, it determines the document schema that applies to the interchange. It uses the
properties associated with the matching agreement and the relevant schema to generate
and validate the outgoing message.
Interchange Properties
Interchange Properties
When the EDI send pipeline builds an outgoing EDI message from an intermediate XML file,
it applies an envelope containing interchange and group headers to the message based upon
the EDI properties established for the receive-side agreement. If the send pipeline was not
able to determine the receiving agreement from the send port, it will use the fallback
agreement to apply the envelope.
If the EdiOverride.OverrideEdiHeader context property is set to true, the EDI send pipeline
will use values specified in the EdiOverride property collection to construct the envelope. If a
value is not present in the collection, the corresponding EDI value in agreement properties
will be used. If a value does not exist in either the EdiOverride collection or the agreement
properties, the properties in the fallback EDI agreement will be used.
If the intermediate XML file has a reserved tag or the ReuseEnvelope context property, the
message is a preserved batch and the envelope application logic will not apply..
Extended Validation
Message Validation
When the EDI send pipeline processes a message to be sent, it performs a series of
validations on the envelope and message data. Some of these processes are always
performed; some are performed only if you enable them. These validations include the
following:
 Schema validation of the transaction-set data elements against the message
schema. This is always performed.
 Cross-field validation on transaction set data elements (X12-encoded messages
only). This is performed if it is enabled in the message schema.
 EDI validation performed on transaction-set data elements. This is performed if
enabled in agreement properties.
 Extended validation performed on transaction-set data elements. This is performed
if enabled in agreement properties.
 Validation of the transaction sets within a single group based on the transaction set
– group mapping, according to X12 standards. This must be enabled.
Demonstration: Create and Send an EDI Message
Demonstrate sending an EDIFACT message using fallback settings and then demonstrate sending
the message using settings configured in an agreement.
Install the EDISending Application

1. In Windows Explorer, navigate to C:\AllFiles\DemoCode\Module19, then double-
click Setup.cmd, and then
2. Verify that the installation completed successfully, and close the console window.
Examine and Deploy the Application Artifacts

1. Open the following Visual Studio Solution.
C:\AllFiles\DemoCode\Module19\Contoso.EDI.EDIFACT\Contoso.EDI.EDIFACT.sln
2. In Solution Explorer, in the Contoso.Schemas.Internal project, double-click the

InternalInvoice.xsd schema.
3. In the Schema Editor, right-click the <Schema> node, and then click Expand Schema
Node.
This schema defines an invoice that is produced by one of Contoso’s line-of-

business systems.
4. In the Contoso.EDI.EDIFACT project, double-click the EFACT_D96A_INVOIC.xsd
schema.
5. In the Schema Editor, right-click the <Schema> node, and then click Expand Schema
Node.
This schema defines an EDIFACT invoice message. BizTalk needs to map the
internal invoice to an EDIFACT invoice, and then send it out.
6. Open the InternalInvoiceToD96A_INVOIC.btm map file.
This map will be configured in a receive port to map the internal invoice to the
EDIFACT format.
Examine the Receive Port Configuration

1. In the BizTalk Administration Console, in the EDISending application, click Receive
Ports, and then double-click InternalReceivePort.
2. In the left pane, click Inbound Maps.
Notice that this receive port has been configured to process messages with the
InternalInvoiceToD96A_INVOIC map.
3. In the left pane, click Receive Locations, and in the right pane, double-click
InternalInvoice_FILE.
This receive location is simply using the XMLReceive pipeline, since the LOB
system that produces the invoice is not passing an EDI message to BizTalk.
4. Click Cancel twice.
Examine the Send Port Configuration

1. In the BizTalk Server Administration tree view, right-click the EDISending application,
and then click Properties.
2. In the Application Properties dialog box, in the left pane, click References.
Notice that this application references the BizTalk EDI Application.
3. Click Cancel.
4. Click Send Ports, and then double-click the Contoso_EDIFACT_FILE send port.
Notice that the Send pipeline is EdiSend. This Send Port will write messages out
to the C:\AllFiles\DemoCode\Northwind\Ports\EdifactSend folder.

This send port is subscribed to the EDIFACT invoice message type, which is the
type of message that is produced by the InternalInvoiceToD96A_INVOIC map in
the receive port.
6. Click Cancel.
7. In the BizTalk Server Administration tree view, click Parties.
Notice that there are no agreements defined. Consequently, BizTalk will use the
fallback settings to process all messages.
Test with Fallback Settings

1. Right-click the EDISending application, then click Start twice.
2. In Windows Explorer, copy the
C:\AllFiles\DemoCode\Module19\InternalInvoice.xml file to the
C:\AllFiles\DemoCode\Northwind\Ports\EdifactSend folder and open the message
that was created.
Notice that this message is populated with generic business identifier

information. It does not contain actual party names. These values originated in
the fallback settings, which BizTalk used, since it could not find an agreement for
this interchange.
4. Delete the message.
Create a New Agreement

1. In the BizTalk Administration tree view, click Parties, then right-click Northwind,
point to New, and then click Agreement.
2. In the Agreement Properties dialog box, in the Protocol list, click EDIFACT.
3. In the Party list, click Contoso.
4. Click the Northwind->Contoso tab, then in the left pane, click Send Ports.
5. In the right pane, in the Name list, click Contoso_EDIFACT_FILE.
6. In the left pane, click Identifiers.
Notice that some of the Identifier settings are pre-configured with information
taken from the party profiles.
7. Click OK to lose the Agreement Properties dialog box.

Test with the Agreement Settings
C:\AllFiles\DemoCode\Northwind\Ports\EdifactSend folder and open the message
that was created.
Notice that the EDIFACT message is now populated with sender and receiver
information taken from the agreement between Northwind and Contoso.

Lesson 2: EDI Batching
Lesson objective:
Understand how to configure BizTalk to batch outbound EDI interchanges.
Lesson Overview
EDI mechanisms usually specify data aggregation schemes (batching). BizTalk Server 2010
provides an orchestration that batches EDI interchanges and sets context properties for
routing the batched interchange, once it is released.
Introduction to EDI Batching
EDI Batching
Microsoft BizTalk Server will batch EDI transaction sets if batching has been enabled for the
agreement associated with the business partner that will be receiving it. The EDI properties
for an agreement enable you to do the following:
 Define multiple outgoing batches
 Define the interchange
 Define the groups in the interchange
 Set the batch release criteria
 Set the batch activation criteria.
EDI Batch Orchestration
EDI Batch Orchestration

The EDI Batching orchestration assembles XML transaction sets into an EDI interchange, and
validates and delivers the interchange according to an agreement's EDI properties.
The batching orchestration is a stateful service that buffers batch elements (transaction sets)
over a period of time, assembles them into an interchange, and then releases the
interchange to the send pipeline based upon the release criteria.
After being activated, an instance of the batching orchestration can start batching messages
of a particular encoding type to a given party. At any one time there can be many instances
of the batching orchestration for each party, one per active batch configuration. A single
instance of the batching orchestration can release multiple batches for a single batch
configuration. After the end criteria are met, the batching orchestration instance will
terminate.
EDI Batching Configuration
Batch Configuration
To define the way that BizTalk Server batches transaction sets into an EDI interchange, you
must create one or more batch configurations for an agreement. All interchanges that
BizTalk Server associates with that agreement, and that meet the filter criteria for a batch,
will be batched and released according to the same release criteria for that batch
configuration.
The document standard for the batch is determined by the agreement properties. For
example, if the agreement is for X12 messages, the document standard for the batches will
be X12.
Batch Configuration Page

Batch configuration consists of a batch name, batch ID, filter definition, group definition,
batch release criteria, and batch activation criteria. All properties and options related to
batches are available on the Batch Configuration page of the one-way agreement tab in the
Agreement Properties dialog box.
Configuring a Batch Filter

A batch is created based upon the batch filter definition applied in the Batch Configuration
page of the one-way agreement tab in the Agreement Properties dialog box. In this filter,
you determine which transaction sets or messages will be batched. You can change the
value of this filter while an instance of the batch orchestration is activated. Changing the
filter does not affect the batch release criteria.
Outgoing batches can include multiple groups, but only one group per transaction type. A
group can contain multiple transaction sets, but each must have the same transaction type.
Multiple batch configurations can share the same batch filter, if a document matches more
than one batch filter it will be routed to all matching batches.
Configuring a Batch Release

Batches will be released according to criteria set in the Batch Configuration page of the one-
way agreement tab in the Agreement Properties dialog box. Batches can be released in any
of the following ways:
 According to a schedule, on an hourly, daily, or weekly basis.
 When a specific number of transaction sets is available for a group.
 When a specific number of transaction sets is available for an interchange.
 When a specific number of characters is available for batch processing.
 When an external trigger is executed by an application external to BizTalk Server.
If you select the Send empty batch signal property on the Batch Schedule dialog box, BizTalk
Server will send an empty batch message when the batch is scheduled to be sent even if no
messages have been received by the batching orchestration.
Batch Control Messages

The batching orchestration is activated, terminated, or overridden by the following control
messages:
 BatchActivation: When the orchestration receives this message, an instance of the
batching orchestration is created and the orchestration is active to receive batch
elements (if it meets the batch activation criteria). This control message is sent by
clicking the Start button of a batch configuration on the Batching Configuration
page.
 BatchTermination: When the orchestration receives this message, it creates a batch
from existing batch elements, publishes the message to the MessageBox, and
terminates. This control message is sent by clicking the Stop button of a batch
configuration on the Batching Configuration page.
 BatchOverride: When the orchestration receives this message, it creates a batch
from existing elements, publishes the message to the MessageBox, and then waits
for messages for the next batch. This control message is sent by clicking the Override
button of a batch configuration on the Batching Configuration page.
BatchMarker
BatchMarker Pipeline Component

The BatchMarkerReceivePipelineComponent in the EDI receive pipeline enables the batching
orchestration to pick up messages to be batched. This pipeline component is applied after
the Disassembler in the EDI Receive Pipeline. The component evaluates the filter criteria set
in the Filter section of the Batching Configuration page of the one-way agreement tab of the
Agreement Properties dialog box, and marks the transaction sets with the following context
properties for processing by the routing and batching orchestrations
 If a single party subscribes to a message to be batched, it promotes ToBeBatched =
True and BatchId is set to the value of the batch ID of the matching batch
configuration. This enables pickup by the batching orchestration.
 If multiple batches subscribe to a message to be batched, it promotes ToBeRouted =
True, and sets the EDI.BatchIds property set to a space-delimited list of batch IDs.
This enables pickup by the routing orchestration.
 If no subscriptions exist, it does not promote a context property. This indicates that
the transaction set is not to be batched.
The pipeline component ignores messages other than XML and messages with the
ReuseEnvelope property (preserved batches). If acknowledgments are not to be batched,
the pipeline component will ignore the ACK message types (CONTRL, TA1, and 997). To
optimize processing of the routing and batching orchestrations, the
BatchMarkerPipelineComponent passes the message through to the MessageBox if the
message context property MessageDestination is set to "SuspendedQueue" by the
disassembler.
If you are using a custom pipeline, rather than the EDIReceive pipeline, you can use the
BatchMarker component in your custom pipeline. If you are not using the EDIReceive
pipeline, and are publishing messages from an orchestration, you will have to promote
ToBeBatched = True and BatchID to the ID of an active batch in one of your components
Subscription for Batched Messages
Subscriptions for Batched Messages

If a send port subscribes to either or both of the properties EDI.ToBeBatched = False and
EDI.DestinationPartyName = %PartyName%, that send port can pick up the batched
interchange. Make sure that a send port's filters are configured such that the send port picks
up only those batched interchanges that it is intended to pick up.
Interchanges dropped by the batching orchestration into the MessageBox have only the
properties EDI.ToBeBatched = False, EDI.DestinationPartyName = %PartyName%, and
EDI.BatchEncodingType = "X12" or "EDIFACT" promoted to the context. All context
properties from the original transaction sets are lost..
Demonstration: Implementing EDI Batching
Demonstrate the steps required to configure an application to use EDI batching.
Promoting a Property for EDI Batching

2. In Visual Studio, in the Contoso.Schemas.Internal project, open the
InternalInvoice.xsd schema.
Notice that the Name element, a child of the Them element, has been promoted.
3. Open PropertySchema.xsd, and click the __Name property.
This is the property that will hold the Name from the InternalInvoice message.
This property provides an identifier that can be used for a batch subscription.
Creating a Pipeline for EDI Batching

1. In Solution Explorer, in the Contoso.EDI.EDIFACT project, open the
InternalEDIReceive.btp pipeline.
Notice that this pipeline contains the XML disassembler component, and the
Batch Marker component. The XML disassembler will promote the __Name
property.
2. Click the Batch Marker component.

3. In the Properties window, click the Ignore EDI Message Encoding property, and
notice that it has been set to True.
Since this is an XML document, the Batch Marker component does not need to be
concerned with EDI encoding.
In spite of that, the Batch Marker component will still find the Agreement and
the Batch information that correspond to this message, and it will mark
messages that should be batched.
Configuring a Receive Port for Batching

1. In the BizTalk Administration Console, under the EDISending application, click
Receive Locations, and then double-click InternalInvoice_FILE.
InternalEDIReceive, then click OK.
This is the custom receive pipeline that includes the Batch Marker component.
Configure an Agreement to Enable Batching

1. In the BizTalk Administration tree view, click Parties, and then double-click the
Agreement for EDIFACT.
2. In the Agreement Properties dialog box, click the Northwind->Contoso tab, and then
in the left pane, click Batch Configuration.
3. In the right pane, click New Batch.
4. In the Batch name box, enter InvoiceBatch.
5. Scroll down to the Filter section, and then click the Filter button.
6. In the Batch Filter dialog box, in the Property list, click
Contoso.Schemas.Internal.PropertySchema.__Name.
7. In the Value box, enter Contoso, then click OK.
This filter will determine which messages will be sent to the batching
orchestration.
8. Scroll down to the Release section.

9. Click the Maximum number of transactions in radio button, then in the drop-down
list immediately beneath it, click Group:, and in the text box, enter 3.
BizTalk will send a batch of invoice messages once it has collected a batch of
three invoices.
10. Click Apply.
11. At the top of the Invoice Batch tab, click Start.
Notice that the status message below the button changes from “Batch is not
activated” to “A control message is waiting to be processed.”
12. Click Refresh.
Notice that the status message changes to “Batching is activated, Batching

orchestration is not instantiated yet.”
13. Click Refresh.
Notice that the status message changes to “Batching is activated”, and the
Orchestration instance ID displays a value.
14. Click OK to close the Agreement Properties dialog box.

15. In the BizTalk Administration tree view, click BizTalk Group, then in the center pane,
click New Query, then in the Value list, click Subscriptions, and then click Run
Query.
Notice that the query results show two instances of BatchingService

subscriptions. One of the subscription Expressions includes a condition for each
of the relevant properties of the Agreement. The other subscription simply
includes a condition for a Batch ID. The Batch ID is produced by the Batch
Marker pipeline component.
Both subscriptions require the ToBeBatched property to be True.
Configuring a Send Port for Batching

1. In the BizTalk Administration tree view, under the EDISending application, click Send
Ports, and then double-click the Contoso_EDIFACT_FILE send port.
3. Click the existing filter condition, and then click Delete.
4. In the Property list, click EDI.ReceiverPartyName, and in the Value box, enter
Contoso.
5. On the second line, in the Property list, click EDI.ToBeBatched, and in the Value box,
enter False, then click OK.
This condition will prevent the send port from sending out messages that are still
queued for batching.

C:\AllFiles\DemoCode\Northwind\Ports\EdifactSend folder and notice that a new
message has not yet appeared.
C:\AllFiles\DemoCode\Northwind\Ports\FileIN folder two more times.
9. When BizTalk has finished processing the files, navigate to the
C:\AllFiles\DemoCode\Northwind\Ports\EdifactSend folder and notice that a new
message has appeared.
10. Open the new message.
This message contains the data from all three messages that were batched.
Lab: Sending EDI Messages
Overview
In this lab you work for Contoso Winery. Your ERP system outputs invoice messages using a
custom XML Schema. You need to turn these custom XML messages into EDI messages to
send to a trading partner. The trading partner is located in Ireland, so the EDI messages
must be EDIFACT. Also the trading partner requests that the invoices be sent in batches of
three (3). In this lab, you will be deploying the artifacts necessary to turn the XML messages
into EDI, and you will configure EDI batching for the trading partner. After completing this
lab, you should understand how to: configure BizTalk Server EDI to send EDI messages, and
configure BizTalk Server EDI to batch outgoing EDI message.
Procedure List
window.
Start.

Procedure List
Overview
In this part, you will deploy the EDI schema needed in your solution, and configure the
BizTalk application which will contain your solution artifacts and configuration.
Deploy the EDI Schema

Procedure List
1. Open the following solution.
C:\AllFiles\LabFiles\Lab19\Contoso.EDI.EDIFACT\ Contoso.EDI. EDIFACT.sln

2. In the solution, examine both projects and examine the files.
computer).
File Purpose
EFACT_D96A_INVOIC.xsd The BizTalk Server Schema for EDIFACT
D96A INVOIC. Necessary for converting EDI
messages to XML or XML messages of this
type to EDI.
InternalEDIReceive.btp A custom Pipeline which will allow
processing of incoming XML messages but
also have the EDI component necessary to
support batching.
InternalInvoiceToD96A_INVOIC.btm The map (XSLT) which will transform the
custom invoice schema into the INVOIC XML
message.
InternalInvoice.xsd The internal XML schema for Invoices from
the ERP system.
PropertySchema.xsd A BizTalk property schema definition for the
name of the party sent from the ERP
system. The value is promoted from
InternalInvoice.xsd.
3. Open the InternalEDIReceive.btp pipeline file in the Contoso.EDI.EDIFACT project.

4. From the Toolbox, drag and drop the XML Disassembler onto the Disassemble stage
of the pipeline.
5. From the Toolbox, drag and drop the Batch Marker Component onto the Resolve
Party stage of the pipeline.
6. Click the Batch Marker Component and in the Properties window, set the Ignore EDI
Message Encoding Type property to True.
7. Right-click on the Contoso.Schemas.Internal project and click Deploy.
8. Right-click on the Contoso.EDI.EDIFACT project and click Deploy.
9. Open the BizTalk Administration Console (on the Start menu, click All Programs,
then click BizTalk Server 2010, and then click BizTalk Server Administration).
10. Expand BizTalk Server Administration, BizTalk Group, and Applications.
11. Right-click on the EDISending application and click Properties.
13. In the right pane click the Add button.
Since all the BizTalk EDI artifacts are deployed to this application, in order to use
those artifacts (like pipelines) you must add a reference to this application.
Create the Receive Port

Procedure List
1. In the EDISending application, right-click the Receive Ports node, point to New, then
click One-Way Receive Port.
2. Name the port ERPReceive, and in the left pane click Inbound Maps.
3. In the Inbound Maps dialog, click on the grid under the Source Document property
to see the list of available maps. Pick InternalInvoice as the source document and
the other values will be filled in automatically
4. Click on the Receive Locations tab, then in the right pane, click the New button and
create the new location using the properties in the table below.
Property Value
Name EDIFileLocation
Transport FILE
Receive Folder C:\AllFiles\LabFiles\Ports\EDIReceive\
(Under Transport – click the
Configure Button)
File Mask (Under Transport – click *.xml
Receive Pipeline (Under General) InternalEDIReceive
5. Click OK to close the Receive Port Properties dialog box.

6. Under the EDISending application, right-click the Send Port node, point to New,
then click Static One-way Send Port. After setting the properties as shown below,
click OK to close the dialog.
Property Value
Name EDISend
Transport FILE
Destination Folder (Under C:\AllFiles\LabFiles\Ports\EDIFACTSend
Transport – click the Configure
Button)
File Name (Under Transport – click %MessageID%.txt
Send Pipeline EdiSend
Filter (under Filters tab) EDI.ReceiverPartyName == Contoso Buyer
And
EDI.ToBeBatched == False
7. Right-click the EDISending application, and then click Start.

8. If prompted, also elect to start the BizTalk EDI Application.
This starts the EDI Batching Orchestrations and the Command Receive location
which provides the batching of messages.
Exercise 2: Create an Agreement
Overview
In this part, you will create an EDI Agreement between two parties, and then configure EDI
batching.
Create the Party to Represent Your Company

Procedure List
1. In the BizTalk Administration tree view, right-click the Parties node, point to New,
then click Party and name the party Contoso Winery.
2. Click OK to create the party.
3. In the BizTalk Administration tree view, click the Parties node.
4. In the center pane, expand Contoso Winery, then right-click the Contoso
Winery_Profile and click Properties.
5. Click the Identities tab on the left navigation pane.
6. In the right pane, in the Name list, click Mutually Defined, and in the Value box,
enter ContosoWinery.
7. Click OK.
Create the Party for the Trading Partner

Procedure List
1. In the BizTalk Administration tree view, right-click on the Parties node, point to
New, then click Party and name the party Contoso Buyer.
3. Right-click the Contoso Buyer_Profile in the Parties and Business pane and click
Properties.
5. In the right pane, in the Name list, click Mutually Defined, and in the Value box,
enter ContosoBuyer.
6. Click OK.
Create an Agreement between the Two Parties

Procedure List
1. Right-click the Contoso Buyer_Profile, point to New, then click Agreement.
2. Change the protocol to EDIFACT and click Contoso Winery for the Second Party.
4. Notice the agreement appears under the selected profile for each party involved in
the agreement.
5. Double-click the agreement (from either party/profile) to edit the batch
configuration.
Configure the Batch Information

Procedure List
1. Click the Contoso Winery -> Contoso Buyer tab.
2. Click on Batch Configuration in the left hand pane.
3. Click the New Batch button.
4. Click on the Filter button (opens another dialog box).
5. Under the Property column, find
Contoso.Schemas.Internal.PropertySchema.__Name.
6. Leave the Operator as ==
7. Set the Value column to Contoso Buyer.
8. The expression at the bottom of the dialog should read :
Contoso.Schemas.Internal.PropertySchema.__Name == Contoso Buyer
9. Press OK to close the Filter dialog.

11. Click the radio button next to Maximum number of transaction sets in
12. On the combo box under this setting, set the value to Group:
13. In the text box next to Group: put the value 3.
14. Under the Activation section, check the Start Immediately check box.
15. Press the Apply button (do NOT press OK as that will close the dialog).
16. Press the Start button at the top of the batch page to start the batch processing
This sends a control message that the EDI application picks up to create a new,
unique instance of the batching orchestration for this agreement. If you wait a
minute, then click the refresh button, you will actually see the unique identifier
for the orchestration instance appear in the dialog.
17. Press OK to close the EDI Properties dialog.
Exercise 3: Test the Application
Overview
In this part, you will send an EDI message via the application that you configured in Exercises
1 and 2.
Test the Solution

Procedure List
1. Open the InternalInvoice.xml file from the C:\AllFiles\LabFiles\Lab19 folder and
review.
2. Copy InternalInvoice.xml and put it into C:\AllFiles\LabFiles\Ports\EDIReceive.
3. Do this two more times after the file is picked up by BizTalk.
4. Examine the C:\AllFiles\LabFiles\Ports\EdifactSend folder.
5. If your batching succeeded you should see a .txt file in this directory. Open and
examine the EDI document to see the batch information.
Whenever you plan on using the EDI capabilities in BizTalk for sending EDI
messages you’ll need to follow the steps of this activity at a minimum.
Lab Exercises
Contents
Lab Exercises.................................................................................................................................... 1
Lab 1 : Examining a BizTalk Application ....................................................................................... 6
Exercise 1: Examining the BizTalk Solution .............................................................................. 8
Exercise 2: Test the BizTalk Application ................................................................................. 11
Lab 2 : Creating and Configuring BizTalk Schemas .................................................................... 15
Exercise 1: Creating a New BizTalk Project ............................................................................ 17
Exercise 2: Creating an XML Schema ..................................................................................... 19
Exercise 3: Creating a Flat File Schema .................................................................................. 22
Exercise 4: Generating a Schema from an XML Message Instance ....................................... 27
Lab 3 : Creating a BizTalk Map ................................................................................................... 28
Exercise 1: Creating a Map .................................................................................................... 30
Exercise 2: Adding Basic Functoids to a Map......................................................................... 34
Exercise 3: Adding Database Functoids to a Map .................................................................. 36
Lab 4 : Deploying and Managing BizTalk Applications .............................................................. 39
Exercise 1: Assign a Strong Name Key to an Assembly .......................................................... 41
Exercise 2: Configuring the Application Deployment Property ............................................. 42
Exercise 3: Building and Deploying a BizTalk Application ...................................................... 43
Exercise 4: Managing Ports by Using Binding Files ................................................................ 44
Exercise 5: Managing Applications by Using MSI Packages ................................................... 45
Exercise 6: Moving Resources and Ports Between Applications ........................................... 47
Exercise 7: Managing Applications by Using BTSTask............................................................ 48
Lab 5 : Routing BizTalk Messages .............................................................................................. 49
Exercise 1: Adding an Existing Schema and Map to the Project ............................................ 51
Exercise 2: Promoting Schema Properties ............................................................................. 52
Exercise 3: Creating a Receive Port and a Receive Location .................................................. 53
Exercise 4: Creating a Send Port for All Orders...................................................................... 54
Exercise 5: Creating a Send Port for Cash Orders .................................................................. 55
Exercise 6: Creating a Send Port for Credit Orders ................................................................ 56
Exercise 7: Testing the Port Configuration ............................................................................ 57
Lab 6 : Creating Pipelines........................................................................................................... 59
Exercise 1: Configure a Send Pipeline to Encrypt Outgoing Messages .................................. 61
Exercise 2: Configure a Send Port with the Encryption Pipeline and Certificate ................... 62
Exercise 3: Examine the Interchange Message to Be Disassembled ..................................... 65
Exercise 4: Configure a Receive Pipeline to Disassemble a Message Interchange ................ 66
Exercise 5: Configure a Receive Location to Use the Pipeline ............................................... 68
Exercise 6: Submit Test Messages ......................................................................................... 69
Exercise 7: Enable and Test Recoverable Interchange .......................................................... 71
Lab 7 : Integrating with Adapters .............................................................................................. 72
Exercise 1: Publishing an InfoPath Form to a SharePoint Library .......................................... 74
Exercise 2: Configuring and Testing the HTTP Receive Adapter ............................................ 76
Exercise 3: Configuring and Testing the FTP Adapter ............................................................ 78
Exercise 4: Configuring and Testing the SharePoint Adapter ................................................ 80
Lab 8 : Creating a BizTalk Orchestration .................................................................................... 85
Exercise 1: Import an Existing Schema and Map ................................................................... 87
Exercise 2: Create a New Project and Orchestration............................................................. 88
Exercise 3: Create Orchestration Ports .................................................................................. 92
Exercise 4: Build, Deploy, and Test the Solution ................................................................... 95
Lab 9 : Automating Business Processes ..................................................................................... 97
Exercise 1: Examine an Existing Project ................................................................................. 99
Exercise 2: Promote Distinguished Fields ............................................................................ 100
Exercise 3: Create a New Orchestration .............................................................................. 101
Exercise 4: Create Orchestration Ports ................................................................................ 103
Exercise 5: Build, Deploy, and Test the BizTalk Application ................................................ 105
Lab 10 : Creating Transactional Business Processes ................................................................ 107
Exercise 1: Adding Exception Handling to an Orchestration ............................................... 109
Exercise 2: Adding Compensation to an Orchestration ....................................................... 112
Exercise 3: Calling Compensation ........................................................................................ 114
Exercise 4: Testing the Application ...................................................................................... 116
Lab 11 : Integrating Business Rules ......................................................................................... 120
Exercise 1: Creating a Business Rule Engine Vocabulary ..................................................... 122
Exercise 2: Composing a Business Rule Policy ..................................................................... 126
Exercise 3: Integrating a Business Rule Policy into an Orchestration .................................. 130
Lab 12 : Monitoring Business Activity...................................................................................... 139
Exercise 1: Define a Business Activity .................................................................................. 141
Exercise 2: Define an Observation Model............................................................................ 143
Exercise 3: Deploy the BAM Observation Model ................................................................. 147
Exercise 4: Map a BAM Activity to the Implementation...................................................... 148
Exercise 5: Use the BAM Portal to Test the BAM Implementation ..................................... 152
Lab 13 : Receiving Messages with a WCF Adapter .................................................................. 154
Exercise 1: Publish a Schema as a Web Service ................................................................... 156
Exercise 2: Consume and Test the Web Service .................................................................. 160
Lab 14 : Calling a Web Service from an Orchestration ............................................................ 162
Exercise 1: Setup a Web Service Call in the Orchestration Designer................................... 164
Exercise 2: Configure the Orchestration and Send Ports..................................................... 171
Exercise 3: Test the Orchestration ....................................................................................... 173
Lab 15 : Implementing Dynamic Messaging Patterns ............................................................. 174
Exercise 1: Use Correlation .................................................................................................. 176
Exercise 2: Using Role Links for Messaging.......................................................................... 183
Exercise 3: Define Parties..................................................................................................... 186
Exercise 4: Use Direct Messaging Ports ............................................................................... 188
Lab 16 : Applying the WCF LOB Adapter Framework ............................................................. 192
Exercise 1: Create a WCF LOB Adapter Framework Project ................................................ 194
Exercise 2: Implement an Outbound Handler ..................................................................... 197
Exercise 3: Create an Outbound Client ................................................................................ 201
Exercise 4: Building an Inbound Handler ............................................................................. 204
Exercise 5: Building an Inbound Listener ............................................................................. 207
Lab 17 : Creating a BAM Interceptor Configuration ............................................................... 211
Exercise 1: Deploying the BAM Activity and View ............................................................... 213
Exercise 2: Creating the Interceptor Configuration File ...................................................... 215
Exercise 3: Deploy the Interceptor File ................................................................................ 220
Exercise 4: Configure the Interceptor Runtimes.................................................................. 221
Exercise 5: Test the Configuration ....................................................................................... 223
Lab 18 : Receiving EDI Messages ............................................................................................. 224
Exercise 1: Deploying the EDI Schema and configuring BizTalk Server ............................... 226
Exercise 2: Creating the Parties ........................................................................................... 229
Lab 19 : Sending EDI Messages ................................................................................................ 231
Exercise 1: Deploying the EDI Schema and configuring BizTalk Server ............................... 233
Exercise 2: Create an Agreement......................................................................................... 236
Exercise 3: Test the Application ........................................................................................... 239
Lab 1 : Examining a BizTalk Application
Scenario
Adventure Works is a retail sporting goods chain with 10 stores in the Pacific Northwest. The
company headquarters receives daily batches of orders from each retail store. These
batches are processed by a Microsoft BizTalk Server 2010 application.
In this lab, you will examine and test the BizTalk Server application that you will be building
throughout the remainder of this course. This application receives and processes sales
orders. If the application receives an order for a non-cash transaction, the loan application is
automatically approved or denied, based on predetermined business rules. If the credit
application is denied, the loan application is sent to a Microsoft Windows SharePoint
Services site for manual review. If the loan application is denied during the manual review
process, the order is canceled, and the store is notified. If the loan application is approved,
the total loan amount is evaluated to determine who the lender will be. Loans for less than
$1000 are carried by the Adventure Works finance department. Larger loans are managed
by one of two banks, based the customer’s credit rating. For all completed cash or credit
transactions, the inventory system is updated, and a sales order acknowledgement is
generated.
Procedure List
window.
Start.

Procedure List
2. Double-click startBtServices.cmd.
Exercise 1: Examining the BizTalk Solution
Overview
BizTalk projects can contain four types of artifacts: schemas, maps, pipelines, and
orchestrations. In this exercise, you will examine the schemas, maps, and orchestrations that
make up the sales order processing application used by Adventure Works.
Start the Adventure Works BizTalk Application

Procedure List
Group, Applications
3. Right-click on Adventure Works and choose Start, then click on Start in the prompt
that appears.
Open the AdvWorks Solution

Procedure List
1. In Windows Explorer, navigate to C:\AllFiles\LabFiles\Lab1\AdvWorks and open
AdvWorks.sln.
Examine the SalesOrder Schema

Procedure List
1. In Solution Explorer, expand the Messaging project, and then double-click
SalesOrder.xsd to open the schema in the BizTalk Editor.
The SalesOrder schema represents the format of sales order messages that
BizTalk processes. These messages are received from various retail stores owned
by Adventure Works.
2. In the left pane, right-click SalesOrder, and then click Expand Schema Node.
3. Click the Detail record.
The Detail record contains information about the sales order, which includes the
store information and the name of the employee who took the order.
4. Click each field under the Detail record to examine the field’s properties.
Notice that the corresponding information in the XSD details pane is highlighted
as you select each field.
5. Click the CustomerInfo record.
The CustomerInfo record contains information about the customer, including
address and employment information.
6. Click the Items record.
The Items record is a repeating record of individual items in the sales order. The
Items record will repeat as many times as necessary to include all unique items in
the order. Also notice that the schema contains a Comment field, an OrderTotal
field, and a TermOfLoan field.
Examine the Restock Schema
Procedure List
The Restock schema represents the format of restock messages. The restock
message is sent to the inventory system to automatically restock purchased
goods.
2. In the left pane, right-click Restock, and then click Expand Schema Node.
3. Click the OrderID field.
4. Click the Products record.
The Products record is a repeating record and contains the Quantity and ID
number of the product that needs to be restocked.
Examine the SalesOrder_To_Restock Map

Procedure List
1. In Solution Explorer, double-click SalesOrder_To_Restock.btm.
This map is used to transform the data from the SalesOrder message to the
Restock message.
2. In the left pane, click the StoreNumber field beneath the Detail record.
3. Click the red square on the mapping surface.
This is a Concatenate Functoid. It is used to combine the data from the
StoreNumber and OrderNumber fields in the SalesOrder message to create a
single OrderID field in the Restock message.
4. Click the Item field beneath the Items record.
5. Click the purple square on the map surface.
This is a Looping Functoid. It is used to ensure that the Product record on the
Restock message will occur each time the Item field occurs in the SalesOrder
message.
Examine the ProcessOrder_Cash Orchestration

Procedure List
1. In Solution Explorer, expand the Processes project, and then double-click
ProcessOrder_Cash.odx.
This is a basic orchestration. A sales order for a cash transaction is received, and
two new messages are constructed and sent. The Restock message is
constructed by using a map, whereas the completed sales order message is
created by using an expression shape.
Examine the ProcessOrder_Credit Orchestration

Procedure List
2. Right-click the orchestration design surface, point to Zoom, and then click 50%.
This orchestration is a little more complex. A sales order for a credit transaction
is received, and another orchestration is called. When calling an orchestration,
the message is passed to the called orchestration. The calling orchestration then
waits for the completed message to be sent back to it before continuing to
process the message.
3. In Solution Explorer, expand the LoanApproval project, and then double-click
ApproveLoan.odx.
This is the orchestration called by the ProcessOrder_Credit orchestration. The
message is transformed into a loan application by using a map, and then the
loan application is sent to the Business Rules Engine to be approved or denied
based on a collection of rules. If the loan application is approved, it travels down
the left side of the decide shape to be transformed again before being sent back
to the ProcessOrder_Credit orchestration. If the loan is not approved, it is
transformed and sent to a SharePoint site for manual approval or denial, and
then passed back to the ProcessOrder_Credit orchestration.
4. Switch back to the ProcessOrder_Credit orchestration.
If the loan application comes back from the Loan Approval orchestration as
denied, the message will travel down the right branch of the Loan Approved
decide shape, and then a message will be sent informing the store that the loan
has been denied. If the loan is approved, the message will travel down the left
branch of the Loan Approval decide shape. Restock and completed sales order
messages will be created similar to the ones created by cash transactions, and
the message will be evaluated again to determine whether the loan will be
handled by the Adventure Works financial department or sent to a bank for
financing. If the loan is $1000 or less, it will travel down the right branch and the
LOANS table in the AdvWorks database will be updated. If the loan is for more
than $1000, another evaluation will take place to determine which bank the loan
will be sent to. If the loan-to-income ratio is less than 1.5, the message will be
sent to the Woodgrove party. Everything else is sent to the Northwind party. The
orchestration waits for a response from the bank, acknowledging that the loan
application has been accepted.
Exercise 2: Test the BizTalk Application
Overview
BizTalk applications receive, process, and send messages. In this exercise, you will test the
sales order processing application by submitting test messages. You will see how cash and
non-cash (credit) messages are processed, how inventory is updated, how sales order
acknowledgments are generated, and how the loan approval process works.
Submit the CashSalesOrder1.xml Message

Procedure List
C:\AllFiles\LabFiles\Lab1\CashSalesOrder1.xml.
2. Examine the message.
Notice that this order is for 15.99 and has an OrderType of CASH, so it will be
processed through the ProcessOrder_Cash orchestration.
4. In Windows Explorer, copy CashSalesOrder1.xml to the SalesOrderIN folder.
Ensure that you copy the message rather than move it. After the message is
processed, it cannot be recovered.
Notice that after a moment, the message you copied to this folder has been
processed and removed.
6. Navigate to the C:\AllFiles\LabFiles\Lab1\OUT folder.
Notice that a Complete{GUID}.xml message and a Restock{GUID}.xml message
have been created and sent to this folder.
7. Double-click Complete{GUID} to view the message in Microsoft Internet Explorer.
Notice that the comment field has been updated to state that the processing of
this order has been completed.
9. Double-click Restock{GUID} to view the message in Microsoft Internet Explorer.
Notice that the message is in the Restock schema format and contains the
product ID and quantity for the order.
11. Delete all of the messages in the OUT folder.
Test the Internal Financing Process

Procedure List
3. Notice that the CustomerName is Tude Palma, and then close Internet Explorer.
5. Notice that the CustomerName is Roland Hofmann, and then close Internet
Explorer.
7. Notice that the CustomerName is Bryan Walton, and then close Internet Explorer.
8. Copy CredSalesOrder-Internal1.xml, CredSalesOrder-Internal2.xml, and
CredSalesOrder-Internal3.xml to the SalesOrderIN folder.
These three sales orders will be financed by the Adventure Works financial
department. When processed, each loan will update the LOANS table in the
AdvWorks database and generate a restock message and a completed order
message.
9. Navigate to the OUT folder and wait until the three Complete{GUID}.xml messages
and the three Restock{GUID}.xml messages appear.
10. On the Start menu, point to All Programs, point to Microsoft SQL Server 2008, and
then click SQL Server Management Studio.
11. In the Connect to Server dialog box, click Connect.
12. In Object Explorer, expand Databases, AdvWorks, Tables, right-click dbo.LOANS,
and select Select Top 1000 Rows.
13. In the query results window, notice the three entries: one entry each for Bryan
Walton, Roland Hofmann, and Tude Palma.
14. Close Microsoft SQL Server Management Studio.
15. In Windows Explorer, delete all the messages in the OUT folder.
Test the External Financing Process

Procedure List
2. Open CredSalesOrder-Northwind.xml, and then notice that the CustomerName is
Josh Pollock.
This order fulfills all requirements to be approved by the business rules engin,
and will be sent to Northwind for financing.
4. Open CredSalesOrder-Woodgrove.xml, and then notice that the CustomerName is
Armando Pinto.
This order fulfills all requirements to be approved by the business rules engine
and will be sent to Woodgrove for financing.
6. Copy CredSalesOrder-Northwind.xml and CredSalesOrder-Woodgrove.xml to the
7. Navigate to C:\AllFiles\LabFiles\Lab1\Woodgrove, open the
WoodgroveNotice{GUID}.xml file that appears, notice that the CustomerName is
Armando Pinto, and then close Microsoft Internet Explorer.
8. Move the WoodgroveNotice{GUID}.xml file from the Woodgrove folder to the
BankAck folder.
The step represents receiving an acknowledgment from the lender verifying that
the loan will be financed. The message is processed and completes the
9. Navigate to C:\AllFiles\LabFiles\Lab1\Northwind, open the
NorthwindNotice{GUID}.xml file that appears, notice that the CustomerName is
Josh Pollock, and then close Microsoft Internet Explorer.
10. Move the NorthwindNotice{GUID}.xml file from the Northwind folder to the
BankAck folder.
The step represents receiving an acknowledgment from the lender verifying that
the loan will be financed. The message is processed and completes the
11. Delete all the messages in the OUT folder.
12. Open C:\AllFiles\LabFiles\Lab1\CredSalesOrder-Denied-Northwind.xml, and then
notice that the Customer Name is Alex Hankin.
engine, but it can still be approved manually. If approved manually, it will be sent
to Northwind for financing.
14. Open C:\AllFiles\LabFiles\Lab1\CredSalesOrder-Denied-Woodgrove.xml, and then
notice that the Customer Name is David Barber.
engine, but it can still be approved manually. If approved manually, it will be sent
to Woodgrove for financing.
16. Copy CredSalesOrder-Denied-Northwind.xml and CredSalesOrder-Denied-
Woodgrove.xml to the SalesOrderIN folder.
17. In Internet Explorer, navigate to http://localhost/LoanApplications.
18. Click the first message, and then in the File Download dialog box, click Open. If the
Microsoft Office Activation Wizard window appears, click on its Cancel button.
19. In the Status list, choose Approved, and then close the form, saving your changes.
20. In the SharePoint navigation menu in Internet Explorer, click on All Documents and
choose Evaluated from the drop-down list.
The Evaluated view shows applications that have been approved or denied.
Notice that the message you modified has been picked up for processing. This
may take up to one minute to occur, so you may have to refresh your browser.
21. Click on Evaluated in the SharePoint navigation menu and choose All Documents
from the drop-down list. Click the remaining message, and then in the File
Download dialog box, click Open. If the Microsoft Office Activation Wizard window
appears, click on its Cancel button.
22. In the Status list, choose Denied, and then close the form, saving your changes.
This may take up to one minute to occur.
24. In Windows Explorer, navigate to C:\AllFiles\LabFiles\Lab1\OUT, and then open the
Denied{GUID}.xml message.
This is the denial message for the loan application you manually denied. The
complete and restock messages for the loan you approved are also here.
25. If you approved the loan for David Barber, navigate to
C:\AllFiles\LabFiles\Lab1\Woodgrove; if you approved the loan for Alex Hankin,
navigate to C:\AllFiles\LabFiles\Lab1\Northwind.
26. Open the newest message in the folder, and notice that this is the loan that you
manually approved.
Lab 2 : Creating and Configuring BizTalk Schemas
Scenario
Each type of message processed by a BizTalk server application requires an XML schema that
defines the structure of the message. In this lab, you will create a BizTalk Server project that
will contain your schemas. Adventure Works has defined an internal sales order message
format for which you will create a schema. Next you will use the Flat File Schema Wizard to
create a schema that represents the format of the sales orders submitted by the Adventure
Works stores. Finally, you will generate a schema from a sample loan application message.
Procedure List
window.
Start.
Exercise 1: Creating a New BizTalk Project
Overview
A BizTalk Server project contains BizTalk Server artifacts. In this exercise, you will create a
new Microsoft Visual Studio® 2010 solution and a new project that uses the BizTalk Server
Project template. This project will contain the schemas that you will create in the following
exercises.
Create a Blank Solution
Procedure List
1. On the Start menu, click All Programs, click Microsoft Visual Studio 2010, and then click
2. On the File menu, point to New, and then click Project.
3. In the New Project dialog box, in the Installed Templates pane, click BizTalk Projects,
click the Empty BizTalk Server Project icon, and then create a new project using the
information in the following table.
Property Value
Name Messaging
Create directory for <checked>
solution
Solution Name AdvWorks
4. Click OK to create and open the new project.

Exercise 2: Creating an XML Schema
Overview
You can define an XML schema by manually defining each node, or by importing or including
other schemas. In this exercise, you will define schema nodes for the Adventure Works sales
order message and import nodes from an existing schema that contains customer information.
Create the SalesOrder Schema

Procedure List
Folder.
2. Rename the folder Messages.
3. In Solution Explorer, right-click the Messages folder, point to Add, and then click
Existing Item.
4. In the Add Existing Item dialog box, navigate to C:\AllFiles\LabFiles\Lab2, and then
double-click SalesOrder1.xml.
This is a sample message of the schema that you will build in this exercise.
5. In Solution Explorer, double-click SalesOrder1.xml to open the message.
Examine the structure of the message.
Item.
7. In the Add New Item dialog box, in the Categories pane, then click the Schema icon.
8. In the Name box, type SalesOrder.xsd to name the schema.
9. Click Add to open the blank schema in BizTalk Editor.
The schema tree (left pane) and XSD view (right pane) appear in BizTalk Editor. Also,
the new schema (SalesOrder.xsd) is added to Solution Explorer.
Define the SalesOrder Schema Structure

Procedure List
1. In the Schema tree (left pane), right-click the Root node, click Rename, and then
rename the node to SalesOrder.
The Root node should always be renamed with a meaningful name that represents
the type of document described by the schema. When possible, use a root node
name that is unique throughout the enterprise.
2. Right-click the SalesOrder (root) node, point to Insert Schema Node, and then click
Child Record.
3. Rename the record to Detail.
4. Repeat steps 2 and 3 to create two more records and name them Record and Items.
5. Right-click the Detail node, point to Insert Schema Node, and then click Child Field
Attribute.
6. Rename the attribute to StoreNumber.
7. Repeat steps 5 and 6 to create four more attributes under the Detail record and name
them as follows: Employee, OrderNumber, OrderType, and OrderDate.
8. Right-click the Items node, point to Insert Schema Node, and then click Child Record.
9. Rename the record to Item.
10. Right-click the Item node, point to Insert Schema Node, and then click Child Field
Attribute.
11. Rename the attribute to Qty.
12. Repeat steps 10 and 11 to create three more attributes under the Item record and name
them as follows: SKU, Price, and ExtendedPrice.
13. Right-click the SalesOrder node, point to Insert Schema Node, and then click Child Field
Element.
14. Rename the element to Comment.
15. Repeat steps 13 and 14 to create two more elements under the Items record and name
them OrderTotal and TermOfLoan.
Import the Customer Information from another Schema

Procedure List
Existing Item.
2. In the Add Existing Item dialog box, browse to and add
C:\AllFiles\LabFiles\Lab2\CustomerInfo.xsd.
You may have noticed that the sample message contains a CustomerInfo record with
several fields; the CustomerInfo schema contains all these fields.
3. In BizTalk Editor, click the <Schema> node of the SalesOrder schema.
4. In the Properties window, click the Imports property, and then click the ellipsis (…)
button.
5. In the Imports dialog box, verify that XSD Import is selected from the list, and then click
Add.
6. In the BizTalk Type Picker dialog box, expand Messaging, expand Schemas, click
Messaging.CustomerInfo, and then click OK twice.
7. In the SalesOrder schema, click the Record node.
8. In the Properties window, click the Data Structure Type property, and then in the list,
click ns0:CustomerInfo (Reference).
Validate the Schema

Procedure List
1. In Solution Explorer, right-click SalesOrder.xsd, and then click Validate Schema.
You can use the Validate Schema command to determine whether a schema
contains any internal inconsistencies or has other issues that might prevent it from
being used effectively for processing instance messages. All schemas created by
using the BizTalk Schema Editor will always be valid, but this is a good way to verify
that the schemas you receive from other sources are recognizable to BizTalk.
Generate a Sample Instance

Procedure List
1. In Solution Explorer, click SalesOrder.xsd.
2. In the Properties window, in the Output Instance Filename box, type
C:\AllFiles\LabFiles\Lab2\SalesOrder-Gen.xml.
3. In Solution Explore, right-click SalesOrder.xsd, and then click Generate Instance.
A sample instance message is saved in C:\AllFiles\LabFiles\Lab2, and a link to the
XML instance is shown in the Output window. Hold the CTRL key, and click the link to
open the resulting XML file.

Procedure List
1. Click SalesOrder.xsd, and in the Properties window, in the Input Instance Filename box,
type C:\AllFiles\LabFiles\Lab2\SalesOrder1.xml
2. Right-click SalesOrder.xsd, and then click Validate Instance.
validates the schema against an actual XML file.
Exercise 3: Creating a Flat File Schema
Overview
BizTalk Server can also process messages in positional or delimited formats (flat files). In this
exercise, you will use the Flat File Schema Wizard to create a schema that defines the structure
of flat file messages sent from the Adventure Works stores.
Create the SalesOrder_FF schema

Procedure List
2. Examine the structure of the file, and then close Notepad.
Item.
4. In the Add New Item dialog box, click Flat File Schema Wizard (notice that this is
different than the Flat File Schema item).
5. In the Name box, type SalesOrder_FF.xsd, and then click Add.
6. On the Welcome to the BizTalk Flat File Schema Wizard page, click Next.
7. On the Flat File Schema Information page, in the Instance file box, browse to or type
8. In the Record name box, type SalesOrder, and then click Next.
9. On the Select Document Data page, ensure that the entire contents of the document
are selected, and then click Next.
click Next.
11. On the Delimited Record page, ensure that the Child Delimiter is set to {CR}{LF}, and
then click Next.

OrderDetail Record
CustomerInfo Record
Products Record
Comment Field element
13. Click Next.

Define the OrderDetail Record Structure
Procedure List
1. On the Schema View page, ensure that the OrderDetail record is selected, and then click
Next.
2. On the Select Document Data page, ensure that the first line of content is selected
click Next.
4. On the Delimited Record page, set the Child Delimiter to , (comma), and then click Next.

StoreNumber Field Attribute
OrderNumber Field Attribute
Cash_Cred Field Attribute
EmployeeName Field Attribute
TotalOrder Field Attribute
6. Click Next.
Define the CustomerInfo Record Structure

Procedure List
1. On the Schema View page, ensure that the CustomerInfo record is selected, and then
click Next.
2. On the Select Document Data page, ensure that the second line (name and address) is
selected (excluding the ¶« characters), and then click Next.
3. On the Select Record Format page, select By relative positions, and then click Next.
4. On the Positional Record page, click the hash mark on the ruler at positions 5, 30, 34,
59, 69 and 71, and then click Next. If you accidently click an incorrect position, click it
again to remove the position marker.

ID Field Element
CustomerName Field Element
MonthsAtResidence Field Element
Address Field Element
Town Field Element
State Field Element
ZipCode Field Element
6. Click Next.
Define the Products Record

Procedure List
1. On the Schema View page, ensure that the Products record is selected, and then click
Next.
2. On the Select Document Data page, ensure that the third line (products) is selected
click Next.
4. On the Delimited Record page, set the Child Delimiter to , (comma).
5. Check the Record has a tag identifier check box, in the Tag box, type PRODUCTS, and
then click Next.
6. On the Child Elements page, in the first row, change the Element Name to Product, and
change the Element Type to Repeating record. In the second row, change the Element
Type to Ignore, and then click Next.
Define the Product Record

Procedure List
1. On the Schema View page, ensure that Product is selected, and then click Next.
2. On the Select Document Data page, ensure the first Product record is selected
(“PRODUCT|1|75…|200.00”), excluding all commas, and then click Next.
3. On the Select Record Format page, click By delimiter symbol, and then click Next.
4. Set the Child delimiter to | (pipe), check the Record has a tag identifier box, enter
PRODUCT in the Tag field, and then click Next.

Quantity Field Attribute
ItemNumber Field Attribute
PriceEach Field Attribute
6. Click Next.
7. Click Finish.
Procedure List
1. In Solution Explorer, click SalesOrder_FF.xsd, then select the Input Instance Filename
field in the Properties window. Notice that the file is the same as the sample instance
used to generate the schema with the Flat File Schema Wizard.
2. Right-click SalesOrder_FF.xsd, and then click Validate Instance.
validates the schema against sample a flat file.
3. In the Output window, hold CTRL and click the link to the right of Validation generated
XML output to view the XML representation of the flat file instance.
Exercise 4: Generating a Schema from an XML Message Instance
Overview
BizTalk can generate a schema based on an existing XML message instance. In this exercise, you
will generate a schema based on a sample loan application message.
Install the Well-Formed XML Schema Generator

Procedure List
1. In Windows Explorer, navigate to C:\Program Files (x86)\Microsoft BizTalk Server
2010\SDK\Utilities\Schema Generator, and then double-click InstallWFX.vbs.
A command window will appear briefly as the VB script is executed.
Create the LoanApp Schema

Procedure List
1. In Windows Explorer, browse to and open
C:\AllFiles\LabFiles\Lab2\LoanApp_Sample.xml.
This is a sample of the message that is evaluated against a set of business rules to
automatically approve or deny a loan application.
3. In Solution Explorer, right-click the Messaging project, point to Add, and then click Add
Generated Items.
4. In the Add Generated Items dialog box, in the Categories pane, click the Generate
Schemas icon, then click Add.
5. In the Generate Schemas dialog box, in the Document type list, click Well-Formed XML,
in the Input file box, browse to C:\AllFiles\LabFiles\Lab2\LoanApp_Sample.xml, click
Open, and then click OK.
6. In Solution Explorer, verify that a LoanApp_Sample schema, which represents the
sample message, has been created.
7. Rename LoanApp_Sample.xsd to LoanApp.xsd.
8. Click LoanApp.xsd, and then in the Properties window, type LoanApp in the Type Name
box.
9. Save and Close the AdvWorks solution.
Lab 3 : Creating a BizTalk Map
Scenario
Maps are typically used to convert messages from one format to another. In this lab, you will
create a map that is used to transform data from the flat file format generated by the Adventure
Works stores to the internal sales order format used by the sales order application. You will
configure the map with several functoids to manipulate and modify the message data. You will
also configure the map to retrieve information from a Microsoft® SQL Server™ database and
insert it into the destination message.
Procedure List
window.
Exercise 1: Creating a Map
Overview
A BizTalk map is used to convert message data between XML formats. In this exercise, you will
use the BizTalk Mapper to create a map that transforms data from the SalesOrder_FF schema to
the SalesOrder schema format. This map will contain links that associate the data fields between
these two schemas.
Open an Existing Solution

Procedure List
1. On the Start menu, click All Programs, click Microsoft Visual Studio 2010, and then
click Microsoft Visual Studio 2010.
2. In Visual Studio, on the File menu, point to Open, and then click Project/Solution.
3. In the Open Project dialog box, browse to C:\AllFiles\LabFiles\Lab3\AdvWorks, click
AdvWorks.sln, and then click Open.
The existing project opens in Solution Explorer.
Create a New BizTalk Map

Procedure List
Item.
2. In the Add New Item dialog box, click the Map icon.
3. In the Name box, type SalesOrder_FF_to_SalesOrder_XML.btm to name the map.
Notice the naming convention of the map. It is a good idea to incorporate the source
and destination schemas when naming a map.
4. Click Add to start the BizTalk Mapper.
Selecting the Map template causes the BizTalk Mapper to start after the map is
added to the project.
5. In the BizTalk Mapper, click the Open Source Schema, expand Messaging, then
Schemas, select AdvWorks.Messaging.SalesOrder_FF, and then click OK.
6. In the BizTalk Mapper, click the Open Destination Schema, expand Messaging, then
Schemas, select AdvWorks.Messaging.SalesOrder, and then click OK
Link Nodes Manually Between Schemas

Procedure List
1. Below the map grid, right-click the Page 1 tab (at the bottom of the map), and then click
Rename Page.
Renaming the map page makes map management easier. It does not affect the XSLT
in any way.
3. In the Source Schema, right-click Schema, and then click Expand Tree Node.
4. In the Destination Schema, right-click Schema, and then click Expand Tree Node.
5. Using only the pairings in the following table, click and drag a link from each source field
from the Source Schema across the Map grid to the associated destination field in the
Destination Schema.
StoreNumber StoreNumber
OrderNumber OrderNumber
Employee Employee
Link Nodes Automatically by Node Name

Procedure List
1. In the Source Schema, click the CustomerInfo node, and then while holding the SHIFT
key, click and drag a link from the CustomerInfo node to the CustomerInfo node in the
destination schema. Choose Link by Name in the menu that appears when you release
the mouse button.
Notice how fields with the same name were automatically mapped. You will have to
manually map fields from the source schema that do not have matching names in
the destination schema.
2. In the Source Schema, click the CustomerInfo node, and then while holding the SHIFT
key, drag a link from the CustomerInfo node to the Residence node in the Destination
Schema. Choose Link by Name in the menu that appears when you release the mouse
button.
Notice that the Address, Town, Region, and ZipCode fields are not automatically
mapped to the Residence node. Because the names of these fields do not match in
the source and destination schemas, you will have to map these manually.
3. Using the pairings in the following table, click and drag a link from each source field
from the Source Schema across the Map grid to the associated destination field in the
Destination Schema.
Use the Residence record on the Destination Schema for the mappings to Street,
City, State, and PostalCode. The BillingAddress record mappings will be made in a
later exercise.

Address Street (Residence)
Town City (Residence)
Region State (Residence)
ZipCode PostalCode (Residence)
Employer Employer
MonthsEmployed MonthsEmployed
PrimaryIncome Primary
OtherIncome Other
Link Nodes Automatically by Structure

Procedure List
1. In the Source Schema, click the Product node, and then while holding the SHIFT key,
drag a link from the Product node to the Item node in the Destination Schema. Choose
Link by Structure in the menu that appears when you release the mouse button.
Notice how nodes with the same node structure were automatically mapped. The
nodes that haven’t yet been mapped will be mapped in later exercises.
2. In the Source Schema, drag a link from the Comment node to the Comment node in the
Destination Schema.
Validate the Map

Procedure List
1. In Solution Explorer, right-click SalesOrder_FF_to_SalesOrder_XML.btm, and then click
Validate Map.
The results of the map validation are displayed in the Output window. Notice that
there are several warnings on the Error List stating that there are required fields that
are missing values. These validation warnings will be resolved with the additional
mappings made in a later exercise.
Test the Map

Procedure List
1. Right-click SalesOrder_FF_to_SalesOrder_XML.btm, and then click Properties.
2. In the SalesOrder_FF_to_SalesOrder_XML.btm properties window, configure the
following properties:
Property Value
TestMap Input
C:\AllFiles\LabFiles\Lab3\SalesOrder_FF_Sample.txt
Instance
TestMap Input Native

The errors displayed in the Error List window are expected since the mapping process
isn’t complete. If you do not see the Error List window, click on the View menu and
click Error List.
4. In the Output window, while holding the CTRL key, click the link to the XML instance to
open the resulting XML file (bottom right link following “The output is stored in the
following file:”).
Information from the sample instance has been mapped from the SalesOrder_FF
message type to the SalesOrder message type.
5. Close the XML output message.
Exercise 2: Adding Basic Functoids to a Map
Overview
In addition to copying data between message nodes, maps can contain functoids that perform
data manipulation. In this exercise, you will add functoids to the map to manipulate data from a
source message to a destination message.
Create a New Map Page

Procedure List
1. Below the Map grid, right-click the Links tab (at the bottom of the map), and then click
Add Page.
2. Rename Page 2 to Functoids.
Convert a String to Uppercase

Procedure List
1. If the Toolbox is not already docked on the left side, on the View menu, click Toolbox.
2. From the String Functoids section of the Toolbox drag, the Uppercase functoid on to the
Map grid.
To move the functoid to a different position on the map grid, click the functoid to
select it (it will be highlighted with a blue box), then drag and drop it to the new
position. Click anywhere else in the mapper to unselect the functoid.
3. In the Source Schema, click the Cash_Cred field, and then drag a link to the Uppercase
4. In the Map grid, click the Uppercase functoid, and then drag a link to OrderType node in
The functoid must not be selected (i.e. it must not be highlighted with a blue box)
when dragging it to create a new link.
Specify the Current Date for the Order

Procedure List
1. From the Date/Time Functoids section of the Toolbox, drag the Date functoid on to the
Map grid.
2. In the Destination Schema, click the OrderDate field, and then drag a link to the Date
Multiply Two Fields from the Source Schema to a Single Field in the
Destination Schema
Procedure List
1. From the Mathematical Functoids section of the Toolbox, drag the Multiplication
2. From the Cumulative Functoids section of the Toolbox, drag the Cumulative Sum
Because functoids must link left to right, you must drag the Cumulative Sum functoid
to the right of the Multiplication functoid.
3. In the Source Schema, click the Quantity field, and then drag a link to the Multiplication
4. In the Source Schema, click the PriceEach field, and then drag a link to the
ExtendedPrice node in the Destination Schema.
Cumulative Sum functoid.
7. In the Map grid, click the Cumulative Sum functoid, and then drag a link to the Order
Total node in the Destination Schema.
Specify a Constant Value for the Loan Term

Procedure List
1. From the String Functoids section of the Toolbox, drag the String Concatenate on to the
Map grid.
2. In the Map grid, click the String Concatenate functoid, and then drag a link to the
TermOfLoan node in the Destination Schema.
3. In the Map grid, double-click the String Concatenate functoid.
4. In the Configure String Concatenate Functoid dialog box, click “Edit the selected
constant input” (the button with the pencil icon), and enter 6 as the value.
5. Click OK.
Exercise 3: Adding Database Functoids to a Map
Overview
It is often necessary to insert data into a message from an outside data source, such as a SQL
Server database. In this exercise, you will use functoids to retrieve information from a SQL
database and insert it in the destination message.
Create Links to the Database Lookup and Value Extractor Functoids

Procedure List
1. Drag the Uppercase functoid from the Toolbox to the Map grid.
2. In the Source Schema, click the ID field, and then drag a link to the Uppercase functoid
in the Map grid.
3. From the Database Functoids section of the Toolbox, drag the Database Lookup
Because functoids must link left to right, you must drag the Database Lookup
functoid to the right of the Uppercase functoid.
4. Drag a link between the Uppercase functoid and the Database Lookup functoid.
5. Right-click the link between the Uppercase and Database Lookup functoids, and then in
the Properties window, in the Label box, type CustomerID.
6. Drag four Value Extractor functoids, and then line them up vertically to the right of the
Database Lookup functoid.
7. Drag a link between the Database lookup functoid and each of the Value Extractor
functoids (four separate links).
8. Drag a link between the first Value Extractor functoid to the Street field under the
9. Drag a link between the second Value Extractor functoid to the City field under the
10. Drag a link between the third Value Extractor functoid to the State field under the
11. Drag a link between the fourth Value Extractor functoid to the PostalCode field under
the Billing Address record.
Configure the Database Lookup and Value Extractor Functoids

Procedure List
1. Double-click the Database Lookup functoid.
2. In the Configure Database Lookup Functoid dialog box, notice that Input[0] is the link
from the Uppercase functoid. Double-click on each of the following Input Parameters,
and enter the following values:
Input Value
Parameter
Input[1] Provider=SQLOLEDB.1;Integrated Security=SSPI;Persist Security
Info=False; Initial Catalog=AdvWorks;Data Source=(local)
Input[2] CUSTOMER
Input[3] CUSTID
The first parameter is the SQL connection string to access the AdvWorks database.
The Second parameter specifies the database table you’re looking up. The third
parameter specifies the column in the table you’re looking up.
3. Click OK.
4. Double-click each Value Extractor functoid, notice that Input[0] is the link from the
Database Lookup functoid, then set the appropriate value for Input[1], as shown in the
table below:
Functoid Value for Input[0]
First Value Extractor Functoid ADDRESS
Second Value Extractor Functoid CITY
Third Value Extractor Functoid REGION
Fourth Value Extractor Functoid ZIP
Each one of these parameters specifies the column from the database from which
the data will be mapped. These functoids will look up the CUSTID field in the source
schema in the AdvWorks database. If the CUSTID exists, the associated values in the
ADDRESS, CITY, REGION, and ZIP columns will be mapped to the Street, City, State,
and PostalCode fields in the destination schema.
Validate and Test the Map

Procedure List
1. In Solution Explorer, right-click SalesOrder_FF_to_SalesOrder_XML.btm, and then click
Validate Map.
The results of the map validation are displayed in the Output window. Notice, in the
Error List window, the validation errors you received earlier are no longer returned.
A link to the XML instance is shown in the Output window.
3. In the Output window, while pressing the CTRL key, click the link to open the output
XML file (bottom right link).
4. Examine and then close the order.
The Street, City, State, and PostalCode fields are retrieved from the database and
inserted in the destination message.
Lab 4 : Deploying and Managing BizTalk Applications
Scenario
All assemblies used by BizTalk Server applications (including non-BizTalk .NET assemblies) must
be in the Global Assembly Cache (GAC) of the computer(s) running BizTalk Server. Additionally,
all BizTalk assemblies must be registered in the BizTalk configuration database. In this lab, you
will prepare a BizTalk assembly to be deployed by assigning a strong name key an application’s
projects. You will then deploy the assembly, and use the BizTalk Server Administration Console
to import a binding file to complete the configuration. You will then export the new, configured
application to an MSI file. You will move all of the application’s resources to a new application,
export it with BTSTask.exe, and then delete the application from the BizTalk Server
Configuration database.
Procedure List
window.

Procedure List
Exercise 1: Assign a Strong Name Key to an Assembly
Overview
All BizTalk Server assemblies must be signed with a strong name key before being deployed. In
this exercise, you will create the strong name key that will be used to sign your assemblies, and
then assign the strong name key to the Messaging project.
Assign a Strong Name Key to the Messaging Project

Procedure List
1. In Windows Explorer, navigate to and open the solution
C:\AllFiles\LabFiles\Lab4\AdvWorks\AdvWorks.sln.
3. In the Signing tab of the Messaging project properties window, scroll down to the
bottom, and check the Sign the assembly check box.
4. From the Choose a strong name key file drop-down list, choose <Browse…>, navigate to
C:\AllFiles\LabFiles\ Common\AdvWorks.snk, then click Open.
5. Close the Messaging project properties window.
6. Repeat steps 2 through 5 for the Processes project.
Exercise 2: Configuring the Application Deployment Property
Overview
Applications provide a means to group ports, business rule policies, and BizTalk assemblies with
their contained artifacts, and non-BizTalk artifacts for easy administration. Each BizTalk project
can be configured to deploy to a specific application. In this exercise, you will configure the
application deployment property for two BizTalk projects.
Configure Each Project to Deploy to the AdvWorks Application

Procedure List
1. In Solution Explorer, right-click Messaging, and then click Properties.
2. In the Messaging property pages window, click the Deployment tab, and in the
Application Name box, type AdventureWorks
3. Repeat steps 2 and 3 for the Processes project.
6. In Solution Explorer, right-click the AdvWorks solution, and then click Deploy Solution.
Visual Studio understands project dependencies and will automatically build and
deploy any projects in the same solution that the Processes project depends on.
Exercise 3: Building and Deploying a BizTalk Application
Overview
Building a BizTalk Server 2010 project compiles a .NET assembly. After the assembly is compiled,
it must be deployed to the GAC of the computer(s) running BizTalk Server, and it must be
registered with the BizTalk configuration database. In this exercise, you will build and deploy a
BizTalk Server 2010 application.

Procedure List
1. In Solution Explorer, right-click the AdvWorks solution, then click Build Solution.
C:\AllFiles\LabFiles\Lab4\AdvWorks\Messaging\bin\Deployment.
Notice that AdvWorks.Messaging.dll has been created.
Notice in the status bar (bottom left) that the Deploy succeeded.
Exercise 4: Managing Ports by Using Binding Files
Overview
Port and orchestration configuration can be managed by using binding files. Binding files contain
information about the relationship between orchestration and logical ports. Binding files also
include all the physical port settings, such as pipelines, adapter configuration, map, and filters.
In this exercise, you will create and manage ports by importing a binding file.

Procedure List
1. On the Start menu, point to All Programs, point to Microsoft BizTalk Server 2010, and
Notice that there are no send ports, receive ports, or receive locations in the
application.
4. In the Import Binding dialog box, navigate to C:\AllFiles\LabFiles\Lab4, and then open
4-Lab-Bindingd.xml.
5. In the BizTalk Server Administration Console, under the AdventureWorks application,
click Send Ports, then Receive Ports, and then Receive Locations.
Notice that send ports, receive ports, and receive locations have been added to the
application.
Exercise 5: Managing Applications by Using MSI Packages
Overview
BizTalk MSI packages can contain all of the BizTalk and non-BizTalk assemblies, business rule
policies, associated Web services, and configuration information for an application. In this
exercise, you will create an MSI package for the AdvWorks application. To test the MSI package,
you will delete the AdvWorks application, and then recreate it by importing the MSI package
you created.
Export an Application to an MSI

Procedure List
2. On the Welcome page of the Export MSI File Wizard, click Next.
3. Examine the information on the Select Resources page, and then click Next.
4. On the Specify IIS Hosts page click Next.
5. Examine the information on the Dependencies page, and then click Next.
7. In the Export MSI File dialog box, navigate to C:\AllFiles\LabFiles\Lab4, in the File name
box, type AdventureWorks, and then click Save.
8. On the Destination page, click Export.
9. Examine the information contained in the Results section on the Summary page, and
then click Finish.
Delete the Application

Procedure List
1. In the BizTalk Server Administration Console, right-click AdventureWorks, click Delete,
and then in the Confirm delete application dialog box, click Yes.
Import an Application from an MSI

Procedure List
1. In the BizTalk Server Administration Console, right-click Applications, point to Import,
and then click MSI file.
2. On the Welcome to the Import Wizard page, click the ellipsis (…) button.
3. Navigate to C:\AllFiles\LabFiles\Lab4, click AdventureWorks.msi, and then click Open.
4. On the Welcome to the Import Wizard page, click Next.
5. Examine the information on the Application Settings page, and then click Next.
6. On the Application Target Environment Settings page, click Next.
7. Examine the information on the Import Summary page, and then click Import.
8. On the Results page, select the Run the Application Installation Wizard to install the
application on the local computer check box, and then click Finish.
Having this check box selected will start the MSI Installation, which installs the
assemblies contained in the MSI file to the Global Assembly Cache (GAC).
9. On the Select Installation Folder page, click Next.
10. On the Welcome to the Adventure Works Setup Wizard page, click Next.
11. On the Confirm Installation page, click Next.
12. Examine the information on the AdventureWorks Information page, and then click
Next.
13. On the Installation Complete page, click Close.
14. In the BizTalk Server Administration Console, expand AdventureWorks, and then click
Send Ports, Receive Ports and Receive Locations.
Notice that the send ports, receive locations, and receive ports from the AdvWorks
application are in the AdventureWorks application.
15. Click Resources to verify that the resources were imported.
16. Click Orchestrations to verify that the orchestrations were imported.
17. On the Start menu, click Control Panel, and then click Uninstall a program
Notice that the AdventureWorks application appears in the Currently installed
programs list. Removing the application from Add or Remove Programs will uninstall
it from the GAC, but the application will remain in the Configuration database.
18. Close the Programs and Features window.
Exercise 6: Moving Resources and Ports Between Applications
Overview
Application artifacts (ports, assemblies, policies, etc.) can be moved between applications. All
dependent artifacts will be moved together. In this exercise, you will create a new BizTalk
application, and then move resources and ports to the new application.
Create a New Application

Procedure List
1. In the BizTalk Server Administration Console, right-click Applications, point to New, and
then click Application.
2. In the Application Properties dialog box, in the Name box, type
Move Resources and Artifacts Between Applications

Procedure List
1. In the BizTalk Server Administration Console, in the AdventureWorks application, click
Resources.
2. Right-click AdvWorks.Processes, and then click Move To Application.
ExtremeAdventureWorks.
Notice that the send and receive ports that are bound to the ProcessOrder_Cash
orchestration will automatically be moved with it.
4. Examine the information in the Moving Artifacts list, using the scroll bar if necessary,
and then click OK.
5. Right-click AdvWorks.Messaging, and then click Move To Application.
Notice that Resources is now empty.
7. In the BizTalk Server Administration Console, expand ExtremeAdventureWorks, and
then click Resources.
Notice that the AdvWorks.Messaging and AdvWorks.Processes resources have been
moved.
8. Under ExtremeAdventureWorks, click Send Ports.
Notice that the snd_AdvWorks_RestockFILE and snd_AdvWorks_OrderCompleteFILE
send ports have been moved.
Exercise 7: Managing Applications by Using BTSTask
Overview
BTSTask.exe is a command line utility that can be used to create, delete, and manage
applications. In this exercise, you will use BTSTask.exe to view deployed assemblies, create an
MSI package, and delete an application.
View Deployed Applications

Procedure List
Notice that this is the list of BTSTask.exe commands that can be used from the
command prompt.
Export an Application to an MSI Package

Procedure List
then press ENTER.
BTSTask ExportApp -ApplicationName:“ExtremeAdventureWorks”

-Package:“C:\AllFiles\LabFiles\Lab4\ExtAdvWorks.msi”

Notice that the ExtAdvWorks.msi file now appears in the Lab4 folder.
Delete an Application
Procedure List
1. In the command prompt window, type the following command, and then press ENTER.
BTSTask RemoveApp -ApplicationName:“ExtremeAdventureWorks”
Notice that the ExtremeAdventureWorks application has been removed.
Lab 5 : Routing BizTalk Messages
Scenario
The BizTalk messaging engine allows you to route messages based on message context. In this
lab, you will add existing BizTalk artifacts the messaging project. Next, you will promote
properties in an XML schema to be used to selectively route messages. You will then configure
BizTalk messaging ports to receive and route sales order messages, based on message context.
Finally, you will test the port configuration by submitting test messages.
Procedure List
window.

Procedure List
Exercise 1: Adding an Existing Schema and Map to the Project
Overview
Another BizTalk developer has given you BizTalk artifacts to use in your project. In this exercise,
you will import an existing schema and map into the Messaging project.
Add an Existing Schema and Map to the Project

Procedure List
1. In Windows Explorer, navigate to C:\AllFiles\LabFiles\Lab5\AdvWorks and open the
AdvWorks.sln file.
2. In Solution Explorer, right-click Messaging, point to Add, and then click Existing Item.
3. In the Add Existing Item – Messaging dialog box, navigate to
C:\AllFiles\LabFiles\Lab5\AdvWorks\Artifacts.
4. While pressing the CTRL key, click LoanApplication.xsd and
SalesOrder_To_LoanApp.btm, and then click Add.
5. In Solution Explorer, double-click the LoanApplication.xsd schema.
Examine the structure of the LoanApplication.
7. Close the LoanApplication.xsd schema window.
8. In Solution Explorer, double-click the SalesOrder_To_LoanApp.btm map.
Examine the mapping of the nodes within the map.
9. Close the SalesOrder_To_LoanApp.btm map.
Exercise 2: Promoting Schema Properties
Overview
Promoting a property makes specific data in a message accessible to the BizTalk messaging
engine so messages can be routed based on their contents. In this exercise, you will promote
several properties in the SalesOrder schema.
Promote Properties
Procedure List
1. In Solution Explorer, double-click SalesOrder.xsd.
3. Under the Detail node, right-click OrderType, point to Promote, and then click Quick
Promotion.
4. In the Microsoft Visual Studio message box, read the message, and then click OK. If a
message box appears asking if you want to reload PropertySchema.xsd, click Yes.
Notice in Solution Explorer that the PropertySchema.xsd artifact has been created.
This is the default schema created to hold promoted properties. Also notice that the
OrderType node now has an icon to indicate that the node has been promoted.
5. Ensure that PropertySchema.xsd is open in the schema editor. If it is not, double-click
PropertySchema.xsd in Solution Explorer.
Notice that the OrderType node is listed in the PropertySchema schema. The
Property1 node is created by default and can be safely deleted.
6. Right-click Property1, and then click Delete.
7. In the BizTalk Editor dialog box, click Yes to confirm the deletion.
Verify in the status bar that the deployment succeeded.
Exercise 3: Creating a Receive Port and a Receive Location
Overview
You can use the BizTalk Server Administration Console to manage the BizTalk configuration
database. BizTalk Server uses receive ports and receive locations to process inbound messages.
In this exercise, you will create a receive port and receive location by using BizTalk Explorer.
Create the SalesOrder Receive Port

Procedure List
Group, Applications and BizTalk Application 1
3. Right-click Receive Ports, point to New, and click One-Way Receive Port.
4. In the Receive Port Properties dialog box, type SalesOrder in the Name box, then click
OK.
Create the SalesOrderFILE Receive Location

Procedure List
2. Create a new folder, and name it SalesOrderIN.
3. In the BizTalk Administration Console, click the Receive Ports icon under BizTalk
Application 1, then right-click the SalesOrder receive port, point to New, and click
Receive Location.
4. In the Receive Location Properties dialog box, type SalesOrderFILE in the Name box.
5. Choose FILE from the Type drop-down list, and then click the Configure button.
7. In the Browse For Folder dialog box, navigate to
C:\AllFiles\LabFiles\Lab5\SalesOrderIN, and then click OK twice.
8. In the Receive Pipeline drop-down list, choose XMLReceive, and then click OK to close
the Receive Location Properties dialog box.
Exercise 4: Creating a Send Port for All Orders
Overview
In this exercise, you will create a send port and configure it to subscribe to all messages received
by the SalesOrder receive port.
Create the SalesOrderFILE Send Port

Procedure List
1. In the BizTalk Administration Console, right-click the Send Ports icon under BizTalk
Application 1, point to New, and click Static One-Way Send Port.
2. In the Send Port Properties dialog box, in the Name box, type SalesOrderFILE.
3. Choose FILE from the Type drop-down list, and click the Configure button.
C:\AllFiles\LabFiles\Lab5, create a new folder named AllSalesOrders, and then click OK.
5. In the File name box, type Processed%MessageID%.xml, and then click OK.
6. In the Send Pipeline list, click PassThruTransmit.
9. In the Value box, type SalesOrder, and then click OK.
Exercise 5: Creating a Send Port for Cash Orders
Overview
Subscriptions can be created based on multiple message properties. In this exercise, you will
create a send port and configure it to subscribe to all messages that have the word CASH in the
OrderType promoted property field, and are received by the SalesOrder port .
Create the CashOrdersFILE Send Port
Procedure List
1. Under BizTalk Application 1, right-click Send Ports, point to New, and then click Static
One-Way Send Port.
2. In the Send Port Properties dialog box, in the Name box type CashOrdersFILE.
C:\AllFiles\LabFiles\Lab5, create a new folder named CashOrders, and then click OK.
5. In the File name box, type Cash%MessageID%.xml, and then click OK.
Property list.
11. In the Value box, type CASH, and then click OK.
Exercise 6: Creating a Send Port for Credit Orders
Overview
You want all credit orders to be sent to a different port than the cash orders. In this exercise,
you will create a send port and configure its filter to subscribe to all messages that contain the
word CRED in the OrderType promoted property field, and are received by the SalesOrder port.
Create the CreditOrdersFILE Send Port

Procedure List
1. In the BizTalk Server Administration Console, under BizTalk Application 1, right-click
Send Ports, point to New, and then click Static One-Way Send Port.
2. In the Send Port Properties dialog box, in the Name box, type CreditOrdersFILE.
C:\AllFiles\LabFiles\Lab5, create a new folder named CreditOrders, and then click OK.
5. In the File name box type Credit%MessageID%.xml, and then click OK.
8. Click the top box in the Property column, and in the drop-down list, click
BTS.ReceivePortName.
Property list, and then type CRED in the Value box.
11. In the left pane, click Outbound Maps.
12. In the Map list, click SalesOrder_To_LoanApp, and then click OK.
Exercise 7: Testing the Port Configuration
Overview
Each sales order received through the SalesOrder receive port is sent to two of the three send
ports, based on message context. In this exercise, you will start and enable the newly created
ports and submit messages to test the message routing configuration.

Procedure List
1. In the BizTalk Server Administration Console, right-click the BizTalk Application 1
2. In the Start ‘BizTalk Application 1’ Application dialog box, click Options.
3. Verify that all check boxes are selected, and then click Start.
Test the Port Configuration

Procedure List
2. Double-click CashSalesOrder1.xml, which will open the file in Microsoft Internet
Explorer.
3. In Windows Explorer, double-click CashSalesOrder2.xml.
It is important that you copy the messages to the SalesOrderIn, rather than moving
them. Once the messages are processed, they can not be recovered for later testing.
The messages will disappear when BizTalk Server receives them.
9. In Windows Explorer, open the AllSalesOrders folder.
It may take up to one minute for the messages to appear, but eventually, all four
messages will be routed to this folder.
10. In Windows Explorer, open the CashOrders folder.
The two CASH messages have been routed to this folder.
11. In Windows Explorer, open the CreditOrders folder.
The two CRED messages have been routed to this folder.
12. Open one of the Credit{GUID}.xml messages.
Notice that the message is in the LoanApp format because it was processed through
the SalesOrder_To_LoanApp map used by the CreditOrders send port.
Lab 6 : Creating Pipelines
Scenario
Pipelines allow you to customize the processing of messages within send or receive ports. In this
lab, you will create and test a custom send pipeline that encrypts communications between
Adventure Works and Woodgrove Bank. Next, you will configure a receive pipeline that splits a
batch of messages (an interchange) to be processed as individual messages. Finally, you will
enable recoverable interchange processing to address issues that arise from malformed
messages within the batch.
Procedure List
window.

Procedure List
Exercise 1: Configure a Send Pipeline to Encrypt Outgoing Messages
Overview
Communicating with trading partners often requires that messages be encrypted. In this
exercise, you will create a custom pipeline that will be used to encrypt messages being
exchanged with Woodgrove Bank. You will then deploy the project with the newly added
pipeline.
Add a New Send Pipeline to the Messaging Project

Procedure List
1. In Windows Explorer, navigate to C:\AllFiles\LabFiles\Lab6\AdvWorks, and then open
the AdvWorks.sln file.
Item.
3. In the Add New Item – Messaging dialog box, in the left pane, click Pipeline Files, and
then in the center pane, click Send Pipeline.
4. In the Name box, type EncryptionPipeline.btp, and then click Add.
The newly added pipeline opens in the Pipeline Designer.
Add an XML Assembler Pipeline Component to the Pipeline

Procedure List
1. Drag the XML assembler from the Toolbox to the Drop Here box in the Assemble stage
of the pipeline.
Add and Configure a MIME/SMIME Pipeline Component to the Pipeline

Procedure List
1. Drag the MIME/SMIME encoder from the Toolbox to the Drop Here box in the Encode
2. Right-click the MIME/SMIME encoder, and select Properties.
3. In the MIME/SMIME encoder Properties window, in the Check revocation list box, click
False.
4. In the Enable encryption box, click True.
5. In the Send body part as attachment box, click True.

Procedure List
1. In Solution Explorer, right-click Messaging, and then click Deploy.
Exercise 2: Configure a Send Port with the Encryption Pipeline and Certificate
Overview
In order to process encrypted messages, a certificate must be installed on the computer running
BizTalk Server that will process the message. In this exercise, you will install the certificate used
to encrypt messages, configure the send port to use the Encryption Pipeline, and specify the
encryption certificate.
Attempt to Assign an Encryption Certificate
Procedure List
3. In the right-pane, double-click CreditOrdersFILE.
4. In the Send Port Properties dialog box, in the Send pipeline list, click
EncryptionPipeline, and then click Apply.
5. In the left pane, click Certificate, and then in the right-pane, click Browse.
Notice that there are no certificates that can be used to encrypt.
6. Click Cancel.
Install the WoodGrove Encryption Certificate

Procedure List
2. In the Run box, type mmc, and then press ENTER.
3. In the Console1 window, on the File menu, click Add/Remove Snap-in.
4. In the Add or Remove Snap-ins dialog box, in the Available snap-ins list, double-click
Certificates.
5. In the Certificates snap-in dialog box, click Computer account, then click Next, and then
click Finish.
6. In the Add or Remove Snap-ins dialog box, click OK.
7. In the Console1 window, expand the Certificates (Local Computer) node.
8. Right-click Other People, point to All Tasks, and then click Import.
9. On the Welcome to the Certificate Import Wizard page of the Certificate Import
Wizard, click Next.
C:\AllFiles\LabFiles\Lab6\AdvWorks\WoodGroveCert, click WoodGrove.cer, and then
click Open.
12. On the File to Import page, click Next.
13. On the Certificate Store page, click Next, and then click Finish to close the Certificate
Import Wizard.
15. In the Console1 window, expand the Other People node, and then click Certificates.
16. In the Issued To column, double-click Woodgrove.
Notice that Microsoft Windows does not have enough information to verify this
certificate.
17. Click the Certification Path tab.
Notice the bottom pane reads: “The issuer of the certificate could not be found.” This
indicates that the issuer is not in the list of trusted certificate authorities.
Install the WoodGrove Encryption Certificate Chain

Procedure List
1. In the left pane of the Console1 window, click Trusted Root Certification Authorities.
2. In the right pane, right-click Certificates, point to All Tasks, and then click Import.
3. On the Welcome to the Certificate Import Wizard page, click Next.
C:\AllFiles\LabFiles\Lab6\AdvWorks\WoodGroveCert, click
WoodGroveCACertChain.cer, and then click Open.
6. Click Next twice to accept the default configurations, and then click Finish.
8. In left pane of the Console1 window, expand Trusted Root Certification Authorities,
and then click Certificates.
9. In the right pane, double-click WoodGroveCA to examine the certificate properties.
10. Click OK.
11. In the left pane of the Console1 window, under Other People, click Certificates.
12. Double-click Administrator to examine the certificate properties.
Notice that this certificate is now valid.
14. Close the Console1 window, and then click No when asked to save changes.
Assign the WoodGrove Encryption Certificate to the Send Port

Procedure List
1. In the CreditOrdersFILE - Send Port Properties dialog box, on the Certificate tab, click
Browse.
Notice that the certificate you just installed now appears.
2. Click OK to select the certificate, and then click OK to close the Send Port Properties
window.
Test the Encryption Pipeline

Procedure List
1. In the BizTalk Server Administration Console, right-click AdventureWorks, and then click
Start.
4. Copy CredSalesOrder1.xml and CredSalesOrder2.xml to the SalesOrderIN folder.
5. Open the SalesOrderIN folder to verify that the messages have been processed.
7. Right-click one of the XML files, and then click Edit to open the file in Notepad.
Notice that the message has been encrypted.
8. Close Notepad.
10. Open one of the XML files in Notepad.
Notice that this file is not encrypted.
11. Close Notepad.
12. In Windows Explorer, delete all XML files from the AllOrders and CreditOrders folders.
Exercise 3: Examine the Interchange Message to Be Disassembled
Overview
An interchange, also known as a message batch, is a single message that contains multiple
nested messages. A pipeline can be used to split an interchange into smaller messages. In this
exercise, you will examine the sample interchange message that the pipeline you create will
split.
Examine the Interchange Message

Procedure List
1. In Windows Explorer, navigate to and open C:\AllFiles\LabFiles\Lab6\
SalesOrder_FF_Interchange.txt in Notepad.
Notice that this interchange contains a cash (Cash) transaction message and two
credit (Cred) transaction messages. Also notice that the first line contains the batch
information. This first line is known as the batch header.
2. Close Notepad.
Exercise 4: Configure a Receive Pipeline to Disassemble a Message
Interchange
Overview
Disassembler components in custom flat file pipelines can be configured to split interchanges by
defining separate header and body schemas. The header schema represents the introductory
portion of a batch. The header typically contains information common to all messages in the
batch. In this exercise, you will import a header schema and create a pipeline to process the
batch of flat file sales order messages submitted by the retail stores. A second disassembler in
the pipeline will allow processing of individual sales orders.
Add the Header Schema to the Messaging Project

Procedure List
2. Navigate to C:\AllFiles\LabFiles\Lab6\AdvWorks\Artifacts, click BatchHeader.xsd, and
then click Add.
3. In Solution Explorer, double-click BatchHeader.xsd.
4. In the BizTalk Editor, expand Batch, expand BatchDetail, and then click ManagerName.
Notice the ManagerName and EmailAddress nodes in the schema. These fields
represent the header information for the interchange.
5. Close the BatchHeader.xsd schema. If prompted to save your changes, click Yes.

Procedure List
1. In Solution Explorer, right-click Messaging, point to Add, and then click New Item.
2. In the left pane, click Pipeline Files, in the center pane, click Receive Pipeline, in the
Name box, type ReceiveSalesOrderInterchange.btp, and then click Add.
Add a Flat File Disassembler Pipeline Component to the Pipeline

Procedure List
1. Drag the Flat file disassembler from the Toolbox to the Disassemble stage of the
pipeline.
2. Drag a second Flat file disassembler to the pipeline, below the one you just added.
3. Click the first Flat file disassembler, and then in the Properties window, in the
4. In the Header schema box, click AdvWorks.Messaging.BatchHeader.
5. Click the second Flat file disassembler, and then in the Properties window, in the
Only the first Flat file disassembler component that matches the incoming message
will be used on the message. This means that this pipeline will be able to process
messages in the SalesOrder_FF format, both as single messages and as part of an
interchange.
Procedure List
You may receive warnings regarding the SalesOrder_To_LoanApp map; these
warnings can safely be ignored. Also notice the warning that states: “If any of the
assemblies were previously loaded by a Host Instance, it may be necessary to restart
the Host Instance for changes to take effect.” If the Error List pane is not visible at
the bottom of the screen, click Error List on the View menu.
Exercise 5: Configure a Receive Location to Use the Pipeline
Overview
The pipeline used to process inbound messages is configured on the receive location. In this
exercise, you will create a new receive location that is associated with the existing SalesOrder
port and configure it to use the ReceiveSalesOrderInterchange pipeline. This configuration will
allow receiving and processing of XML orders, flat file orders, or flat file interchange messages.
Create a New Receive Location for Flat File Message Receipt

Procedure List
BizTalk Group, and Platform Settings, and then click Host Instances.
2. Right-click BizTalkServerApplication, and then click Restart.
The BizTalk host instance associated with an assembly needs to be restarted
whenever the assembly is updated. Otherwise, the old copy of the assembly will
remain in memory.
3. Under Applications, right-click AdventureWorks, and then click Refresh.
4. In the BizTalk Server Administration Console, click AdventureWorks.
5. Right-click Receive Locations, point to New, and then click One-way Receive Location.
6. In the Select a Receive Port dialog box, select SalesOrder, and then click OK.
7. In the Receive Location Properties dialog box, in the Name box, type FFSalesOrderFILE.
10. Expand C:\AllFiles\LabFiles\Lab6, click SalesOrderIN, and then click OK.
11. In the FILE Transport Properties dialog box, in the File mask box, type *.txt, and then
click OK.
ReceiveSalesOrderInterchange, and then click OK.
13. In BizTalk Server Administration Console, in the left pane click Receive Locations, in the
right pane, right-click FFSalesOrderFILE, and then click Enable.
Exercise 6: Submit Test Messages
Overview
A successfully processed interchange message will result in multiple individual messages. By
default, any invalid interchange messages will be suspended. In this exercise, you will submit
two test messages: an interchange message containing valid data and an interchange message
containing invalid data.
Submit a Valid Interchange Message

Procedure List
2. Copy SalesOrder_FF_Interchange.txt to the SalesOrderIN folder.
Notice that all three documents from the batch appear in this folder.
5. Double-click any one of the documents.
Notice that the message has been changed to the SalesOrder format.
8. Right-click the document of your choice, and then click Edit.
Notice that the file is encrypted and the message content cannot be read.
10. In Windows Explorer, navigate to the CashOrders folder.
Notice that the CASH order was processed successfully.
11. In Windows Explorer, delete all XML files from the AllOrders, CashOrders, and
CreditOrders folders.
Submit an Invalid Interchange Message

Procedure List
1. In Windows Explorer, navigate to the Lab6 folder, and then open
SalesOrder_FF_InterchangeBADDATA.txt.
Notice that the batch contains a normal Cash message, a normal Cred message, and
a Cred message that contains {BADDATA}.
7. In the BizTalk Server Administration Console, right-click BizTalk Group, and then click
Refresh.
8. In the center pane, in the Group Hub tab, Under Suspended Items, click Resumable.
Notice that the Query results pane shows one item that is suspended.
9. In the Preview pane, double-click the suspended SalesOrder message.
10. In the Service Details dialog box, click the Error Information tab.
Notice the error description.
11. Click the Messages tab, and then double-click the suspended message.
12. In the Message Details dialog box, click body.
This dialog box can be used to examine the message body to locate the invalid
information.
13. Close the Message Details dialog box, and then click OK to close the Service Details
dialog box.
14. In the Query results pane, right-click the suspended message, and then click Terminate
Instance.
15. In the Confirm Terminate Operation dialog box, read the message, and then click Yes.
16. In the BizTalk Server Administration message box, click OK.
Exercise 7: Enable and Test Recoverable Interchange
Overview
Enabling recoverable interchange processing allows the valid messages of an interchange to be
successfully processed, while any bad messages are individually suspended. In this exercise, you
will enable a recoverable interchange for a pipeline, and then test the pipeline by submitting
two messages.
Enable Recoverable Interchange Processing

Procedure List
1. In the BizTalk Server Administration Console, under AdventureWorks, click Receive
Locations, and then double-click FFSalesOrderFILE.
2. In the Receive Location Properties dialog box, next to the Receive pipeline list, click the
ellipsis (…) button.
3. In the Configure Pipeline dialog box, under Disassemble – Component(1), in the
RecoverableInterchangeProcessing list, click True, and then click OK.
4. In the Receive Location Properties dialog box, click OK.
Submit an Interchange Message that contains bad data

Procedure List
Notice that the messages have been processed and moved from this folder.
4. Navigate to the AllOrders folder.
Notice that two messages have been added to this folder.
5. Navigate to the CashOrders folder.
Notice that the Cash message from the batch file has been added to this folder.
6. Navigate to the CreditOrders folder.
Notice that only one Cred message has been added to this folder. The Cred message
that contains bad data has been suspended.
Lab 7 : Integrating with Adapters
Scenario
BizTalk Server uses adapters to communicate with external systems and processes. Adventure
Works needs to integrate with several systems. Sales orders can now be sent from stores as
HTTP messages in addition to the file receive process already in place. Loan applications that
require approval are sent to a Microsoft Windows SharePoint Services form library for manual
review. All completed sales orders will be sent to an FTP site. In this lab, you will configure the
HTTP adapter, the FTP adapter, and the Windows SharePoint Services adapter.
Procedure List
window.
7. At the Windows Activation prompt, click Ask Me Later, then click OK

Procedure List
Exercise 1: Publishing an InfoPath Form to a SharePoint Library
Overview
Microsoft InfoPath is a program used to create graphical templates (based on XML schemas)
that display XML messages in a user-friendly form. InfoPath can also be used to create new XML
messages based on the template. When combined with Windows SharePoint Services, the two
can provide a portal-based solution for managing XML messages. BizTalk Server, through the use
of the Windows SharePoint Services adapter, can exchange messages with SharePoint form
libraries. In this exercise, you will publish an InfoPath form to a SharePoint form library. You will
then examine a sales order message using the InfoPath form. You will configure the Microsoft
Windows SharePoint Services adapter to monitor and update SharePoint form libraries in a later
exercise.
Publish the LoanApplicationForm InfoPath Form to a SharePoint Site

Procedure List
1. In Windows Explorer, navigate to C:\AllFiles\LabFiles\Common, right-click
LoanApplicationForm.xsn, and then click Design. In the Microsoft Office Activation
This InfoPath form template is based on the LoanApplication schema. When
completed, the resulting message will be a valid loan application.
2. In the Microsoft InfoPath window, on the File menu, click Publish, and then click the
SharePoint Server icon.
3. In the Microsoft InfoPath window, click OK
4. In the Save As dialog box, navigate to C:\AllFiles\LabFiles\Common, click
LoanApplicationForm.xsn, and then click Save.
5. In the Microsoft InfoPath window, click Overwrite.
6. In the Publish Wizard window, in the Enter the location of your SharePoint site box,
type http://BIZTALKDEMO/, and then click Next.
7. Click Form Library, and then click Next.
8. Click Create a new form library, and then click Next.
9. In the Name box, type LoanApplications, and then click Next.
10. Next to the Column Name box, click Add.
11. In the Select a Field or Group dialog box, expand LoanConditions, and click LoanStatus.
12. In the Column name box, change the value to Status, and then click OK.
The LoanStatus field of this form will now be displayed as the Status column in the
form library.
13. Click Next, and then click Publish.
14. On the Publishing Wizard confirmation page, check the Open this form library check
box, and then click Close.
15. Close InfoPath.
The SharePoint form library you just created opens in Microsoft Internet Explorer.
16. On the LoanApplications page, click Add document. In the Microsoft Office Activation
The form has been successfully published.
17. Close InfoPath and Internet Explorer.
Examine a Sales Order That Was Created by Using the SalesOrderForm

InfoPath Form
Procedure List
Cancel.
Notice that an InfoPath form has also been created for the Sales Orders.
2. Close CashSalesOrder1Info.xml.
Exercise 2: Configuring and Testing the HTTP Receive Adapter
Overview
The BizTalk Server HTTP receive adapter accepts messages that are sent to Internet Information
Services (IIS). The HTTP receive adapter accepts HTTP POST messages that are sent to a
preconfigured IIS virtual directory, and it publishes the messages to the BizTalk MessageBox. In
this exercise, you will configure and test a new receive location that uses the HTTP receive
adapter to process incoming sales order messages.
Create a Virtual Directory in IIS for the HTTP Receive Adapter

Procedure List
1. On the Start menu, click All Programs, click Administrative Tools, and then click
Internet Information Services (IIS) Manager.
2. In the left pane of the Internet Information Services (IIS) Manager window, expand
BIZTALKDEMO, Sites and Default Web Site.
3. Right-click Default Web Site, then click Add Application.
4. In the Alias box, enter AdventureWorks.
5. Click the Select button and in the Select Application Pool dialog box, choose
BTSHttpPool from the list, then click OK.
The user ID assigned to the BTSHttpPool application pool has been granted the
permissions required to publish messages to the MessageBox.
6. Click the ellipsis (…) next to the Physical path box.
7. In the Browse for Folder dialog box, browse to C:\Program Files (x86)\Microsoft BizTalk
Server 2010\HttpReceive, and then click OK twice.
8. In the Internet Information Services (IIS) Manager window, in the center pane, in the IIS
section, double-click the Handler Mappings icon.
9. In the right pane, click Add Script Map.
10. In the Add Script Map dialog box, in the Request path box, enter BTSHTTPReceive.dll.
11. Click the ellipsis (…) next to the Executable box, then browse to C:\Program Files
(x86)\Microsoft BizTalk Server 2010\HttpReceive\BTSHTTPReceive.dll, and then click
Open.
12. In the Name box type BizTalk HTTP Receive Adapter, and click OK.
13. In the new Add Script Map dialog box that appears, click Yes.
IIS will now execute the BizTalk HTTP receive adapter when HTTP POST messages are
sent to http://biztalkdemo/AdventureWorks/BTSHTTPReceive.dll.
Configure an HTTP Receive Location

Procedure List
BizTalk Group, Applications, AdventureWorks, and then click Receive Locations.
3. Right-click Receive Locations, point to New, and then click One-way Receive Location.
4. In the Select a Receive Port box, click SalesOrder, and then click OK.
5. In the Receive Location Properties dialog box, in the Name box, type SalesOrderHTTP.
6. In the Type list, click HTTP, and then click Configure.
7. In the HTTP Transport Properties dialog box, in the Virtual directory plus ISAPI
extension box, type /AdventureWorks/BTSHTTPReceive.dll, and then click OK.
9. In the BizTalk Server Administration Console, under Receive Locations, right-click
SalesOrderHTTP, and then click Enable.
Start the AllOrdersFILE Send Port

Procedure List
1. In BizTalk Administration Console, under AdventureWorks, click Send Ports.
2. Right click the AllOrdersFILE send port, and then click Start.
Test the HTTP Adapter

Procedure List
Cancel.
2. On the InfoPath Home menu ribbon, click Submit. In the InfoPath Editor Security Notice
window, click Yes.
The InfoPath form for this document is configured to submit the XML message as an
HTTP POST request to http://biztalkdemo/AdventureWorks/BTSHTTPReceive.dll
3. Click OK.
4. In Windows Explorer, navigate to C:\AllFiles\LabFiles\Lab7\AllOrders.
5. Open the XML document that appears in this folder.
The Cash Sales Order was received and processed successfully.
6. Close InfoPath, and delete any files in C:\AllFiles\LabFiles\Lab7\AllOrders.
Exercise 3: Configuring and Testing the FTP Adapter
Overview
The FTP adapter allows BizTalk Server to interact with local or remote FTP sites. In this exercise,
you will configure a send port to send all completed cash sales orders to an FTP site.
Reconfigure the CashOrdersFILE Send Port to Use the FTP Adapter

Procedure List
1. In the BizTalk Server Administration Console, under AdventureWorks, click Send Ports,
and then double-click CashOrdersFILE.
2. In the Send Port Properties dialog box, in the Name box, type CashOrdersFTP.
3. In the Type list, click FTP, and then click Configure.
4. In the FTP Transport Properties dialog box, under FTP, in the Folder box, type
CashOrders.
5. In the Password box, click the drop-down arrow, and then type pass@word1.
7. In the Target File Name box, replace the existing text with Cash%MessageID%.xml.
Notice that this is the filter expression configured in the module 5 lab.
10. In the Send Port Properties dialog box, click OK.
11. Right click the CashOrdersFTP send port and click Start.
Test the CashOrdersFTP Send Port

Procedure List
Cancel.
3. In Windows Explorer, navigate to C:\AllFiles\LabFiles\Lab7\CashOrders.
Notice that the message you just sent does not appear in the CashOrders folder.
4. In Internet Explorer, go to ftp://BIZTALKDEMO/CashOrders.
5. In the Internet Explorer dialog box, in the User name box, enter Administrator. In the
Password box, enter pass@word1.
6. Open the document that appears in the FTP folder.
Notice the blue text at the top of the message. This text is known as InfoPath
processing instructions. This path specifies where the InfoPath form template that
can be used to display this message is found. Because this message is being opened
from an FTP site that does not have access to the path specified, the message is
opened as a regular XML document. These instructions do not affect BizTalk Server
processing.
Exercise 4: Configuring and Testing the SharePoint Adapter
Overview
The SharePoint adapter enables integration between BizTalk Server and Windows SharePoint
form libraries. You can configure the SharePoint adapter receive location to use a filtered view
to determine which messages should be processed. The SharePoint form library in this lab is
used to manually evaluate loan applications. In this exercise, you will create a SharePoint view,
configure a send port and a receive location to use the Windows SharePoint Services adapter,
and then test the configuration.
Configure and Test a SharePoint Send Port

Procedure List
1. In the BizTalk Server Administration Console, click Send Ports, and then double-click
CreditOrdersFILE.
2. In the Send Port Properties dialog box, in the Name box, type CreditOrdersSharePoint.
4. In the Windows SharePoint Services Transport Properties dialog box, under General,
configure the properties as they appear in the following table, and then click OK.
Property Setting
Destination Folder URL LoanApplications
Filename CreditOrder%MessageID%.xml
This is the form library that you created in the first exercise of this lab. All credit
orders received will be sent to this form library for manual approval of the loan.
5. In the Send pipeline list, click XMLTransmit, and then click the ellipsis (…) button.
6. In the Configure Pipeline dialog box, in the ProcessingInstructionsOptions box,
type 1.
Setting the ProcessingInstructionsOptions to ”1” will remove all existing InfoPath
processing instructions and then insert the processing instructions you specify in the
XmlAsmProcessingInstructions box.
C:\AllFiles\LabFiles\Lab7\ProcessingInstructions.txt.
8. Copy all of the text that appears in ProcessingInstructions.txt, and then close Notepad.
These are the processing instructions for the form that you published in the first
exercise.
9. In the Configure Pipeline dialog box, in the XmlAsmProcessingInstructions box, paste
the text you just copied, and then click OK.
This message will no longer open using the processing instructions for the SalesOrder
form. When opened, it will use the InfoPath form that you published to the
SharePoint library.
11. Right click the CreditOrdersSharePoint send port, and click Start.
Test the CreditOrdersSharePoint Send Port

Procedure List
CreditSalesOrder1Info.xml.
4. Click the CreditOrder{GUID} message, and then in the File Download dialog box, click
Open.
Notice that this message is displayed in the LoanApplication format.
5. Close the InfoPath window.
Create a New SharePoint Form Library View

Procedure List
2. In the Browse tab of the main menu, click All Documents, and then click Create View.
3. In the Choose a view format section, click Standard View.
4. In the View Name box, type Evaluated.
5. Scroll down to the Columns section.
Notice the Status column name. This is the field from the message for which you
created a column in Exercise 1. You are going to create a view using that column.
6. Scroll down to the Filter section, and then click Show items only when the following is
true.
7. Configure the Filter section as seen in the following screen shot.
8. Click OK at the bottom of the page.
9. In the Browse tab, notice that the currently selected view Evaluated.
Notice that the message is not displayed in this view.
10. Click Evaluated, and then click All Documents.
14. In the Browse tab, click All Documents, then click Evaluated.
Notice that the message appears in the Evaluated view and that the Status column
shows the loan is Approved.
16. In the CreditOrder{GUID}.xml window, in the Loan Status list, click Denied.
Notice that the message remains in the Evaluated view and that the LoanStatus
column shows the loan is Denied.
20. In the CreditOrder{GUID}.xml window, in the Loan Status list, click Select.
Notice that the message no longer appears on the Evaluated page.
23. In the Browse tab, click Evaluated, then click All Documents.
Configure and Test a SharePoint Receive Location

Procedure List
2. In the Receive Port Properties dialog box, in the Name box, type LoanApplications.
LoanApplicationsSharePoint.
5. In the Type list, click Windows SharePoint Service. In the Receive pipeline list, click
6. In the Windows SharePoint Services Transport Properties dialog box, under General,
configure the properties as they appear in the following table, and then click OK.
Property Setting
Polling Interval 15
View Name Evaluated
The SharePoint adapter will process all messages displayed by the view specified.
This receive location will process messages displayed by the Evaluated view.
8. In the BizTalk Server Administration Console, click Send Ports, right-click
CashOrdersFTP, and then click Properties.
10. On the second line of the existing filter expressions, in the Group by list, click Or.
11. Add two filter expressions and configure according to the information in the following
table, and then click OK.
Property Operator Value Group by
BTS.ReceivePortName == LoanApplications And
Messaging.PropertySchema.LoanStatus == Approved And
12. In the BizTalk Server Administration Console, click Receive Locations, right-click
LoanApplicationsSharePoint, and then click Enable.
14. Click CreditOrder{GUID}, and then, in the File Download dialog box, click Open.
17. In Internet Explorer, browse to ftp://localhost/CashOrders.
It may take up to a minute for the message to be processed.
18. Click the new Cash{GUID}.
19. Examine and then close the message
Lab 8 : Creating a BizTalk Orchestration
Scenario
BizTalk messaging can be used for basic message transformation and routing. Processing that
requires decisions or multiple actions generally requires the use of orchestrations. The IT
manager of Adventure Works has asked you to create orchestrations for processing both cash
and credit sales orders. In this lab, you will create the orchestration for processing cash sales
orders. In subsequent labs, you will create the orchestration responsible for processing credit
sales orders.
Procedure List
window.

Procedure List
Exercise 1: Import an Existing Schema and Map
Overview
The orchestration you are going to build requires the generation of a restock message and a
map to convert from the SalesOrder format to the Restock format. In this exercise, you will add
the Restock schema and the SalesOrder_To_Restock map to the Messaging project.
Add and Examine Existing Artifacts

Procedure List
AdvWorks.sln.
3. In the Add Existing Item dialog box, browse to C:\AllFiles\LabFiles\Lab8\Artifacts.
4. While holding the CTRL key, click both Restock.xsd and SalesOrder_to_Restock.btm,
and then click Add.
Examine the structure of the Restock schema.
6. In Solution Explorer, double-click SalesOrder_to_Restock.btm.
Examine the links in the SalesOrder_to_Restock map.
7. Close the Restock schema and the SalesOrder_to_Restock map.
Exercise 2: Create a New Project and Orchestration
Overview
The Adventure Works business process specifies that restock messages for the inventory system
and a copy of the completed sales order be generated when a cash sales transaction is
completed. In this exercise, you will create an orchestration that processes cash sales orders
sent by the Adventure Works stores.
Create a New Project

Procedure List
1. In Visual Studio, on the File menu, point to Add, and then click New Project.
2. In the Add New Project dialog box, in the left pane, click BizTalk Projects, then in the
center pane click Empty BizTalk Server Project. In the Name box, type Processes, and
then click OK.
4. In Solution Explorer, right-click Processes, and then click Properties.
5. In the Process property pages window, on the Application tab, in the Assembly Name
and Default Namespace boxes, type AdvWorks.Processes.
6. In the Process property pages window, click the Signing tab, and then check the Sign the
assembly check box.
7. Choose <Browse…> from the drop-down list, and navigate to
C:\AllFiles\LabFiles\Common, click AdvWorks.snk, and then click Open.
10. In Solution Explorer, right-click Processes, and then click Add Reference.
Since the Processes project will contain orchestrations that use the schemas in the
Messaging project, you will need a reference to the Messaging project.
11. In the Add Reference dialog box, on the Projects tab, click Messaging, and then click
OK.
Create an Orchestration
Procedure List
2. In the Add New Item dialog box, click Orchestration Files, click BizTalk Orchestration, in
the Name box, type ProcessOrder_Cash.odx, and then click Add.
The ProcessOrder_Cash orchestration opens automatically.
Create Messages
Procedure List
2. In the Message_1 Properties window, in the Identifier box, type msgSalesOrder.
4. In the Select Artifact Type dialog box, in the left pane, click AdvWorks.Messaging, in the
right pane, click SalesOrder, and then click OK.
This is the message variable for the incoming sales order.
6. In the Message_1 Properties window, in the Identifier box, type
msgSalesOrder_Complete.
8. In the Select Artifact Type dialog box, click in the left pane, AdvWorks.Messaging, in the
This is the message variable for the completed processing acknowledgement
message.
10. In the Message_1 Properties window, in the Identifier box, type msgRestock.
right pane, click Restock, and then click OK.
This is the message variable for the restock message sent to the inventory system.
Add Shapes to the Orchestration

Procedure List
1. Drag a Receive shape from the Toolbox to the area below the green circle (Start) in the
orchestration.
If the Toolbox is not docked on the left side of the window, on the View menu, click
Toolbox.
2. In the Properties window, in the Name box, type Sales Order.
4. Drag a Transform shape from the Toolbox to the area below the Receive shape in the
orchestration.
5. Click the ConstructMessage_1 shape, and then in the Properties window, in the Name
box, type Construct msgRestock.
7. Click the Transform_1 shape, and then in the Properties window, in the Name box, type
Map to Restock.
right pane, click SalesOrder_to_Restock, and then click OK.
11. In the Transform Configuration dialog box, click Source, and then in the Variable Name
list, click msgSalesOrder.
12. Click Destination, and then in the Variable Name list, click msgRestock, and then click
OK.
13. Drag a Message Assignment shape from the Toolbox to the area beneath the Construct
Message shape in the orchestration.
Notice that when you dropped the Message Assignment shape in the orchestration,
a new Construct Message shape was also added.
box, type Construct msgSalesOrder_Complete.
15. In the Messages Constructed list, click msgSalesOrder_Complete.
16. Click the MessageAssignment_1 shape, and then in the Properties window, in the Name
box, type Build Complete SO.
17. In the Build Complete SO Properties window, click Expression, and then click the ellipsis
(…) button.
18. In the BizTalk Expression Editor, in the text box, type the text shown in the text box in
the following screen shot, and then click OK.
20. Configure the Send_1 shape with the properties shown in the following table.
Property Setting
Name Restock
Message msgRestock
21. Right-click the arrow immediately below the Construct msgSalesOrder_Complete
shape, point to Insert Shape, and then click Send.
Property Setting
Name Complete Sales Order
Message msgSalesOrder_Complete
Overview
Orchestration ports (logical ports) provide the connections between an orchestration’s send and
receive shapes and the BizTalk MessageBox database. In this exercise, you will create a receive
port and two send ports. These ports will be connected to send and receive shapes in the
orchestration.
Create an Orchestration Receive Port

Procedure List
Wizard, click Next.
4. On the Select a Port Type page, in the Port Type Name box, type SalesOrderType, and
then click Next.
5. In the Port direction of communication list, click I’ll always be receiving messages on
6. In the URI box, type C:\AllFiles\LabFiles\Lab8\SalesOrderIN\*.xml, in the Transport list,
click FILE, and then click Next.
8. In the SalesOrder receive port shape, click Operation_1, and then in the Identifier box
of the Properties window, type ProcessOrder.
9. In the SalesOrder receive port shape, click Request, and then in the Name box of the
Properties window, type SalesOrder_XML.
10. Drag the green arrow from SalesOrder receive port to the Sales Order receive shape.
Create Orchestration Send Ports

Procedure List
Wizard, click Next.
4. On the Select a Port Type page, in the Port Type Name box, type RestockType, and then
click Next.
6. In the URI box, type C:\AllFiles\LabFiles\Lab8\OUT\Restock%MessageID%.xml, in the
Transport list, click FILE, and then click Next.
Surface.
8. In the Restock send port shape, click Operation_1, and then in the Identifier box of the
Properties window, type SendRestock.
9. In the Restock send port shape, click Request, and then in the Name box of the
Properties window, type Restock_XML.
Wizard, click Next.
13. On the Port Properties page, in the Name box, type SalesOrder_Complete, and then
click Next.
16. In the URI box, type C:\AllFiles\LabFiles\Lab8\OUT\CompleteSO%MessageID%.xml, in
the Transport list, click FILE, and then click Next.
18. Drag the green arrow from Complete Sales Order send shape to the
SalesOrder_Complete send port.
Your orchestration should look like the following figure:
Exercise 4: Build, Deploy, and Test the Solution
Overview
In this exercise, you will deploy and test the ProcessOrder_Cash orchestration. The early bound
orchestration ports that you defined in this lab will cause new messaging ports (physical ports)
to be created and will cause these ports to be bound to the orchestration ports (logical ports).
You will submit a test message to the newly created receive port. The orchestration will
generate two new messages and send them to the file system using the send ports.

Procedure List
2. You will receive the following error:
“You must specify at least one already-initialized correlation set for a non-
activation receive that is on a non-self correlating port.”
This is one of the most common errors committed when creating a new
orchestration. The receive shape for the orchestration is not configured as an
activation receive.
3. Click the Sales Order receive shape, and then in the Properties window, in the Activate
list, click True.
5. After the build has completed, right-click Processes, and then click Deploy.
BizTalk Group, Applications, BizTalk Application 1, and then click Resources.
Notice the AdvWorks.Messaging and AdvWorks.Processes resources.
9. In the Configure Application message box, read the message, and then click Yes.
The host instance used by the orchestration has not yet been configured. A host
instance must be set before the orchestration, and therefore the application, can be
started.
10. In the Configure Application dialog box, click ProcessOrder_Cash.
Notice that the physical receive port and send ports have been created and bound to
the orchestration. This is because you configured the port bindings when configuring
the orchestration ports. This is known as early binding.
11. In the Host list, click BizTalkServerApplication, and then click OK.
13. In the Start ‘BizTalk Application 1’ Application dialog box, click Options, ensure that all
check boxes are selected, and then click Start.
15. Navigate to the SalesOrderIN folder.
16. Navigate to the OUT folder.
17. Open CompleteSO{GUID}.xml.
The message is displayed using a Microsoft InfoPath® form.
18. Close InfoPath.
19. In Windows Explorer, open Restock{GUID}.xml.
The message is displayed in XML format.
Lab 9 : Automating Business Processes
Scenario
BizTalk orchestrations can be used to automate business decisions and other processes. In this
lab, you will create a new BizTalk orchestration that will process credit sales orders.
Procedure List
window.

Procedure List
Exercise 1: Examine an Existing Project
Overview
In upcoming labs, you will add functionality to the LoanApproval project that will evaluate and
approve loans. Initially, this project contains several artifacts that are required for this lab. In
this exercise, you will examine the FinalLoanDocument schema and the
SalesOrder_To_FinalLoanDocument map to familiarize yourself with their design.
Examine the LoanApproval Project

Procedure List
1. In Windows Explorer, navigate to C:\AllFiles\LabFiles\Lab9\AdvWorks and then double-
click AdvWorks.sln.
2. In Solution Explorer, double-click FinalLoanDocument.xsd.
3. In the FinalLoanDocument schema, right-click <Schema>, and then click Expand Schema
Node.
Notice the Distinguished Fields of the FinalLoanDocument schema.
5. Click the Property Fields tab.
Notice the Promoted Properties of the FinalLoanDocument schema.
6. Click OK to close the Promote Properties dialog box.
7. Close the FinalLoanDocument schema, and then click Yes to save changes.
8. In Solution Explorer, double-click SalesOrder_To_FinalLoan.btm.
Examine the SalesOrder_To_FinalLoan map.
9. Close the SalesOrder_To_FinalLoan map.
Exercise 2: Promote Distinguished Fields
Overview
Specifying a field in a schema as distinguished enables you to easily access the field from within
an orchestration for decision-making and data-manipulation purposes. In this exercise, you will
distinguish several fields that will be used in the orchestration.
Promote Three Distinguished Fields

Procedure List
1. In Solution Explorer, in the Messaging project, double-click SalesOrder.xsd.
2. In the SalesOrder schema, right-click <Schema>, and then click Expand Schema Node.
4. In the Promote Properties dialog box, click Comment, and then click Add.
5. Repeat step 4 for OrderTotal and OrderType, and then click OK.
6. On the File menu, click Save All, and then close the SalesOrder schema.
Exercise 3: Create a New Orchestration
Overview
Adventure Works offers two types of financing in their stores. Loans for more than $1,000 are
sent to Woodgrove Bank, while loans of $1,000 or less are managed by the Adventure Works
finance department. In this exercise, you will create an orchestration that will process the credit
sales orders and determine the loan type.
Create the ProcessOrder_Credit Orchestration

Procedure List
1. In Solution Explorer, expand Processes, right-click ProcessOrder_Cash.odx, and then
click Copy.
2. Right-click Processes, and then click Paste.
3. Click Copy of ProcessOrder_Cash.odx. In the Properties window, in the File Name box,
type ProcessOrder_Credit.odx, and then press ENTER.
5. In the Properties window, in the Typename box, type ProcessOrder_Credit.
7. In the Message_1 Properties window, in the Identifier box, type msgFinalLoan.
9. In the Select Artifact Type dialog box, in the left pane, click AdvWorks.LoanApproval, in
the right pane, click FinalLoanDocument, and then click OK.
10. In the ProcessOrder_Credit orchestration, right-click the arrow immediately below the
Sales Order receive shape, point to Insert Shape, and then click Transform.
box, type Construct msgFinalLoan.
12. In the Messages Constructed list, click msgFinalLoan.
13. Click the Transform_1 shape, and then in the Properties window, in the Name box, type
Map to Final Loan.
16. In the Select Artifact Type dialog box, in the left pane, click AdvWorks.LoanApproval, in
the right pane, click SalesOrder_to_FinalLoan, and then click OK.
17. In the Transform Configuration window, click Source, and then in the Variable Name
18. Click Destination. In the Variable Name list, click msgFinalLoan, and then click OK.
19. Right-click the arrow below the Construct msgFinalLoan shape, point to Insert Shape,
and then click Decide.
20. In the Properties window, in the Name box, type Determine Lender.
21. In the ProcessOrder_Credit orchestration, click the Rule_1 shape, and then in the
23. In the BizTalk Expression Editor, in the text box, type msgFinalLoan.Loan.Amount>1000,
and then click OK.
24. Right-click the placeholder below the Large branch, point to Insert Shape, and then click
Send.
Property Setting
Name Notify Bank
Message msgFinalLoan
You will make the necessary changes to the Else branch in a later lab.
Overview
The ports in this orchestration ports are configured as late bound (Specify Later), so they must
be bound to a physical port after the assembly is deployed. Using late binding separates the
design of an orchestration and its implementation. In this exercise, you will add a new late
bound orchestration port and reconfigure the existing ports to use late binding.
Reconfigure Port Types

Procedure List
1. In Orchestration View, expand Types, Port Types, right-click SalesOrderType, and then
click Delete.
2. Right-click RestockType, and then click Delete.
Since these port types are defined in the ProcessOrder_Cash orchestration, they
cannot be defined in this orchestration, too. You must delete the port types from this
list and then reconfigure the ports to use the existing port types from the
ProcessOrder_Cash orchestration.
3. On the left Port Surface, right-click the SalesOrder port, and then click Configure Port.
8. Repeat steps 3–7 for the SO_Complete port.
9. Right-click the Restock port, and then click Configure Port.
AdvWorks.Processes.RestockType, and then click Next.
Create a Send Port

Procedure List
Wizard, click Next.
3. On the Port Properties page, in the Name box, type BankNotification, and then click
Next.
4. On the Select a Port Type page, in the Port Type Name box, type BankNotifyType, and
then click Next.
7. Drag the green arrow from Notify Bank send shape to the BankNotification send port.
8. In the BankNotification send port, click Operation_1, and then in the Identifier box of
the Properties window, type NotifyLender.
9. In the BankNotification send port, click Request, and then in the Name box of the
Properties window, type msgFinalLoan.
Create Filter Expressions for Orchestrations

Procedure List
2. In the ProcessOrder_Cash orchestration, click the Sales Order receive shape, in the
Value box, type “CASH” (include the quotation marks), and then click OK.
4. On the File menu, click Save All, and then close the ProcessOrder_Cash orchestration.
5. In the ProcessOrder_Credit orchestration, click the Sales Order receive shape, in the
Value box, type “CRED” (include the quotation marks), and then click OK.
7. On the File menu, click Save All, and then close the ProcessOrder_Credit orchestration.
Exercise 5: Build, Deploy, and Test the BizTalk Application
Overview
When you test the application, you will submit both cash and credit orders. The cash orders will
be processed by the ProcessOrders_Cash orchestration, and the credit orders will be processed
by the ProcessOrders_Credit orchestration. Credit sales orders over $1,000 will result in a bank
notification message that is sent to Woodgrove Bank. In this exercise, you will deploy and test
the application.

Procedure List
2. Right-click Solution ‘AdvWorks’, and then click Project Build Order.
Notice the order in which the projects must be built. The Project Dependencies dialog
box can be used to reorder these builds. If you try to build or deploy the Processes
project, the Messaging and LoanApproval projects will automatically build and/or
deploy.
3. Click OK to close the Project Dependencies dialog box.
4. In Solution Explorer, right-click Processes, and then click Deploy.
5. In the Output window, notice that all three projects were built and deployed.
6. On the Start menu, point to All Programs, then point to Microsoft BizTalk Server 2010,
7. In BizTalk Server Administration Console, expand BizTalk Server Administration, BizTalk
Group, Applications, AdventureWorks.
9. In the Configure Application dialog box, click ProcessOrder_Cash, and then configure
the settings using the information in the following table.
Property Settings
Restock RestockFILE
In the previous lab, this orchestration was configured with “early binding,” meaning
that the physical ports were automatically created and bound to the logical ports
when the assembly was deployed. In this lab, you are using late binding, so the
logical ports must be bound to the physical ports manually.
settings using the information in the following table, and then click OK.
Property Setting
Restock RestockFILE
Both orchestrations use the SalesOrder receive port. The filter expressions you
configured on the receive shapes in each orchestration will prevent an orchestration
from getting any message it shouldn’t.
11. In the BizTalk Server Administration Console, right-click AdventureWorks, click Start,
and then in the Start ‘AdventureWorks’ Application dialog box, click Start.
12. In Windows Explorer, navigate to C:\AllFiles\LabFiles\Lab9, and then copy all four XML
files to the SalesOrderIN folder.
It may take a moment for the messages to be processed and moved from the
13. Open the OUT folder, and then examine each of the messages.
Notice that the Cash and Restock orders have been processed and that the Credit
order over $1000 has a BankNotify message.
Lab 10 : Creating Transactional Business Processes
Scenario
Exception handling can be added to scope shapes within orchestrations to specify actions to be
executed in the event that an exception occurs. BizTalk orchestrations can include both long-
running and atomic transactions. Compensation, a feature of transactions, allows for the
reversal of previously completed processes. In this lab, you will configure exception handling
and compensation for the ProcessOrder_Credit orchestration.
Procedure List
window.

Procedure List
Exercise 1: Adding Exception Handling to an Orchestration
Overview
Various things can cause an exception to occur in an orchestration. Adding exception handling
to an orchestration enables you to specify actions to be performed when an exception occurs.
Exception handling blocks can only be added to scope shapes. In this exercise, you will add a
scope shape to the ProcessOrder_Credit orchestration, and then configure an exception handler
that will send a message when a specific exception is caught.
Add a Scope Shape

Procedure List
AdvWorks.sln.
2. In Solution Explorer, in the Processes project, double-click ProcessOrder_Credit.odx to
open the orchestration.
above the Determine Lender Decide shape, point to Insert Shape, and then click Scope.
4. Right-click the Scope_1 shape and click Properties Window
5. In the Scope_1 Properties window, configure the properties as shown in the following
table.
Property Value
6. In Orchestration Designer, drag the Determine Lender Decide shape to a location inside
the Send Loan to Lender scope shape.
Add Exception Handling to the Send Loan to Lender Scope

Procedure List
1. In Orchestration Designer, right-click the Send Loan to Lender scope shape, and then
click New Exception Handler.
<.NET Exception>.
then click OK.
This exception handler will be initiated when the send port returns a delivery failure
notification to a send shape in the Send Loan to Lender scope.
5. In the Catch DeliveryFailure catch exception shape, right-click Drop a shape from the
6. In the Send_1 Properties window, in the Name box, type Rescind Notify Bank, and then
in the Message list, click msgFinalLoan.
Add the Rescind Port

Procedure List
3. On the Port Properties page, in the Name box, type Rescind, and then click Next.
4. On the Select a Port Type page, click Use an existing Port Type, in the Available Port
Types box, click AdvWorks.Processes.RescindType, and then click Next.
5. On the Port Binding page, in the Port direction of communication list, click I’ll always
be sending messages on this port, and then click Next.
Notice that the Rescind port has three operations; the RescindType Port Type has
been provided for you. The three operations will be used for the exception handling
and compensation of this orchestration.
7. Connect the Rescind Notify Bank send shape to the BankNotification operation on the
Rescind port.
Add a Throw Exception Shape

Procedure List
1. Right-click the arrow below the Rescind Notify Bank send shape, point to Insert Shape,
and then click Throw Exception.
rethrown DeliveryFailure exception.
Configure the BankNotification Port to Throw an Exception

Procedure List
1. On the left Port Surface, click the BankNotification port.
The BankNotification port will now throw the DeliveryFailure exception that the
Add a Scope Shape

Procedure List
1. Above the Construct msgSOComplete construct message shape, right-click the arrow,
point to Insert Shape, and then click Scope.
table.
Property Value
Name Completed Sales Order
3. Drag the Construct msgSOComplete and Complete Sales Order shapes to locations
inside the Completed Sales Order scope shape.
Add Exception Handling to the Completed Sales Order Scope

Procedure List
1. In Orchestration Designer, right-click the Completed Sales Order scope shape, and then
click New Exception Handler.
<.NET Exception>.
then click OK.
This exception handler will be initiated when the send port returns a delivery failure
notification to a send shape in the Completed Sales Order scope.
5. In the Catch DeliveryFailure catch exception shape, right-click Drop a shape from the
toolbox here, point to Insert Shape, and then click Throw Exception.
rethrown DeliveryFailure exception. Notice that this exception handler does not
send a message to the Rescind port. It simply re-throws the exception.
Configure the SO_Complete Port to Throw an Exception

Procedure List
1. On the right Port Surface, click the SO_Complete port.
The SO_Complete port will now throw the DeliveryFailure exception that the
Exercise 2: Adding Compensation to an Orchestration
Overview
Compensation is used to reverse a transaction that has been committed. Compensation blocks
can only be added to transactional scopes. In this exercise, you will create three transactions;
each transaction will have its own compensation block that is configured to send a rescinding
message if an approval message has previously been sent.
Configure the Orchestration and the Send Loan to Lender Scope Shape as a
Long-Running Transaction
Procedure List
1. Click any white space on the ProcessOrder_Credit orchestration, in the Properties
window, in the Transaction Type list, click Long Running, and then in the Transaction
Identifier box, type LR_ProcessOrder_Cred.
2. In the ProcessOrder_Credit orchestration, click the Send Loan to Lender scope shape,
and then configure its properties as shown in the following table.
Property Value
Transaction Identifier LR_LoanToLender
Add Compensation to the Send Loan to Lender Scope Shape

Procedure List
Block.
2. In the Compensation_1 Properties window, in the Name box, type Send Loan Comp.
3. In the Send Loan Comp compensation block, right-click Drop a shape from the toolbox
here, point to Insert Shape, and then click Send.
4. In the Send_1 Properties window, in the Name box, type Rescind Notify Bank, and then
in the Message list, click msgFinalLoan.
5. Connect the Rescind Notify Bank send shape to the BankNotification operation on the
Rescind port.
Alternatively, you could have copied and pasted the Rescind Notify Bank shape from
the exception handler above.

Procedure List
1. Above the Construct msgRestock construct message shape, right-click the arrow, point
to Insert Shape, and then click Scope.
table.
Property Value
Name Restock Inventory
Transaction Identifier LR_Restock
3. Drag the Construct msgRestock and Restock send shapes to a location inside the
Restock Inventory scope shape.
Add Compensation to the Restock Inventory Transaction

Procedure List
1. Right-click the Restock Inventory scope shape, and then click New Compensation Block.
2. In the Compensation_1 Properties window, change the Name to Restock Inventory
Comp.
3. In the Restock Inventory Comp compensation block, right-click Drop a shape from the
4. In the Send_1 Properties window, in the Name box, type Rescind Restock, and then in
the Message list, click msgRestock.
5. Connect the Rescind Restock send shape to the Restock operation on the Rescind port.
Add Compensation to the Completed Sales Order Transaction

Procedure List
1. Click the Completed Sales Orders scope shape, and then configure its properties as
shown in the following table.
Property Value
Transaction Identifier LR_CompleteSO
2. Right-click the Completed Sales Orders scope shape, and then click New Compensation
Block.
3. In the Compensation_1 Properties window, change the Name to Complete Sales Order
Comp.
4. In the Complete Sales Orders Comp compensation block, right-click Drop a shape from
5. In the Send_1 Properties window, change the Name to Rescind Complete Sales Order,
and then in the Message list, click msgSalesOrderComplete.
6. Connect the Rescind Complete Sales Order send shape to the CompletedSalesOrder
operation on the Rescind port.
Exercise 3: Calling Compensation
Overview
Transactions can be nested to provide a parent/child hierarchy. Parent transactions can call the
compensation for each child transaction from the parent’s exception handler, or as part of the
parent’s compensation. In this exercise, you will first add a long-running transaction to the
orchestration. Next, you will move all the existing shapes, including the transactional scope
shapes, into the parent transaction. Finally, you will add an exception handler to the parent
transaction that will call the compensation of some of the child transactions.

Procedure List
1. In the ProcessOrder_Credit orchestration, right-click the arrow just above the red stop
sign at the bottom of the orchestration, point to Insert Shape, and then click Scope.
table.
Property Value
Name Credit Process
Transaction Identifier LR_CreditProcess
3. Double-click the icon at the top of the Send Loan to Lender scope shape to collapse it.
4. Repeat step 3 to collapse the Restock Inventory scope shape and the Completed Sales
Order scope shape.
5. Drag the Completed Sales Order scope shape inside the Credit Process scope shape.
6. Drag the Restock Inventory inside the Credit Process scope shape, and above the
Completed Sales Order scope shape.
7. Drag the Send Loan to Lender scope shape inside the Credit Process scope shape, and
above the Restock Inventory scope shape.
Initiating Compensation from an Exception Handler

Procedure List
1. Right-click the Credit Process scope shape, and then click New Exception Handler.
General Exception, and then in the Name box type Catch General Exception.
3. In the Catch General Exception exception handler, right-click Drop a shape from the
toolbox here, point to Insert Shape, and then click Compensate.
4. In the Compensate_1 Properties window, change the Name to CompleteSO Comp, and
then in the Compensation list, click LR_CompleteSO.
5. Right-click the line below the CompleteSO Comp shape, point to Insert Shape, and then
click Compensate.
6. In the Compensate_1 Properties window, in the Name box, type Restock Comp, and
then in the Compensation list, click LR_Restock.
Notice that the exception handler for the Credit Process scope does not call the
compensation block of the Send Loan to Lender scope. Consequently, the Send Loan
to Lender compensation code will never be called.
Exercise 4: Testing the Application
Overview
In this exercise, you will test the application. First, you will process messages normally. You will
then reconfigure a port to simulate the loss of connectivity between Woodgrove Bank and
Adventure Works. Finally, you will resubmit the message to test the exception handling and
compensation.
Deploy the Solution

Procedure List
Configure and Start the Application

Procedure List
BizTalk Group, Applications, and AdventureWorks.
4. In the Configure Application dialog box, click ProcessOrder_Cash, and then configure
the bindings as shown in the following table.
Property Value
Restock RestockFILE

bindings as shown in the following table, and then click OK.
Host Value
Rescind RescindFILE
Restock RestockFILE
6. Right-click AdventureWorks, and then click Start.


Procedure List
2. Open and examine each message.
There are two Cash messages, which will be processed by the ProcessOrder_Cash
orchestration, and there are two Credit messages, which will be processed by the
ProcessOrder_Credit orchestration. The Credit order for over $1,000 will be sent to
Woodgrove Bank, and the other will be financed by Adventure Works.
Notice that the messages disappear when they are picked up for processing by
BizTalk Server.
5. In Windows Explorer, navigate to C:\AllFiles\LabFiles\Lab10\OUT, and then notice the
nine output messages.
Each order has a “Complete” message and a “Restock” message. The credit order
over $1,000 also has a BankNotify message, which will be sent to Woodgrove Bank.
6. Delete all of the XML files in the OUT folder.
Modify the CompleteFILE Send Port

Procedure List
2. Double-click the CompleteFILE send port.
The CompleteFILE send port won’t be able to send the completed sales order
message and will cause the exception handling and compensation to be called.
5. In the Send Port Properties dialog box, click Transport Advanced Options, change the
Retry count to 0, and then click OK.
6. Right-click the CompleteFILE send port, and then click Start.
Procedure List
Notice that this is the Credit order that totals $1,500, and will therefore be sent to
Woodgrove Bank for financing.
Server.
output messages.
The BankNotification and Restock messages were sent, but delivery of the Complete
message failed. The delivery failure triggered the Credit Process exception handler,
which attempted to execute compensation for the Restock Inventory scope and the
Completed Sales Order scope. A scope’s compensation execute only if it has
completed successfully earlier in the long-running transaction. Therefore, only the
Restock Inventory compensation block will execute.
Modify the BankNotifyFILE Send Port

Procedure List
2. Double-click the BankNotifyFILE send port.
The BankNotifyFILE send port won’t be able to send the bank notification message
and will cause the compensation and exception handling to be called.
5. In the Send Port Properties dialog box, click Transport Advanced Options, change the
Retry count to 0, and then click OK.

Procedure List
Notice that this is the Credit order that totals $1,500, and will therefore be sent to
Woodgrove Bank for financing.
Server.
output messages.
The BankNotification message was unable to send. The delivery failure triggered the
Send Loan to Lender exception handler, which send a message to the Rescind port,
and re-threw the delivery exception. The re-thrown exception was caught by the
Credit Process exception handler, which attempted to call compensation on the
Restock Inventory scope and the Completed Sales Order scope. Since these scopes
had not yet executed, their compensation blocks did not run.
Lab 11 : Integrating Business Rules
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.
Procedure List
window.

Procedure List
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
click Business Rule Composer.
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
Definition.
3. In the Definition name box, type Primary Income.
4. In the Definition description box, type Amount of principal income.
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.
8. In the Display name box, type Monthly Primary Income, and then click Finish.
Definition.
11. In the Definition name box, type Employment (months).
12. In the Definition description box, type Length of employment.
click Open.
14. In the Select Binding dialog box, expand LoanApp and Employment, click
16. In the Display name box, type Months Employed, and then click Finish.
Definition.
19. In the Definition name box, type Loan Amount.
20. In the Definition description box, type Desired loan amount.
click Open.
LoanAmount, and then click OK.
24. In the Display name box, type Requested Loan Amount, and then click Finish.
Definition.
27. In the Definition name box, type Residency (months).
28. In the Definition description box, type Length at residence.
click Open.
30. In the Select Binding dialog box, expand LoanApp and Residency, click TimeInMonths,
and then click OK.
32. In the Display name box, type Months at Current Residence, and then click Finish.
Definition.
35. In the Definition name box, type Secondary Income.
36. In the Definition description box, type Income from sources other than primary
income.
click Open.
38. In the Select Binding dialog box, expand LoanApp and Income, click OtherIncome, and
then click OK.
40. In the Display name box, type Monthly Secondary Income, and then click Finish.
Create the Update Loan Status “Set” Operation Definition

Procedure List
Definition.
3. In the Definition name box, type Update Loan Status.
click Open.
5. In the Select Binding dialog box, expand LoanApp and LoanConditions, click LoanStatus,
and then click OK.
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
Definition.
3. In the Definition name box, type Set Loan to Income Ratio.
click Open.
LoanToIncome, and then click OK.
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
Definition.
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
Definition.
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
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.
6. Drag Primary Income from the Facts Explorer pane to value1, and then drag Secondary
Income to value2.
8. Right-click AND, and then click Add logical OR.
10. Drag Employment (months) from the Facts Explorer pane to argument1, and then drag
17. Click Status Range, and then in the drop-down list, click Approved.
Create the Denied Income Rule

Procedure List
2. Rename the rule Denied Income.
3. Right-click Conditions, point to Predicates, and then click LessThanEqual.
5. Drag Primary Income from the Facts Explorer pane to value1, and then drag Secondary
Income to value2.
Create the Denied Residency and Employment Rule

Procedure List
2. Rename the rule Denied Residency and Employment.
3. Right-click Conditions, and then click Add logical AND.
5. Drag Employment (months) from the Facts Explorer pane to argument1, and then drag
Create the Loan to Salary Ratio Rule

Procedure List
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 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.
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.
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 -
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 BRE-
Approved.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 -
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.
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
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
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>.
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
Create Messages
Procedure List
2. In the Message_1 Properties window, in the Identifier box, type msgInterimLoan, in the
4. In the Message_1 Properties window, in the Identifier box, type msgLoanApp, in the
AdvWorks.LoanApproval.LoanApplication.

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

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.

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.
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 Destination msgLoanApp
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.
Property Value
Name Construct parFinalLoan
Message Constructed parFinalLoan
Transform Shape
Property Value
Map Destination parFinalLoan
Property Value
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 =
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.
Property Value
Name Construct msgInterimLoan
Message Constructed msgInterimLoan
Transform Shape
Property Value
Map Destination msgInterimLoan
Property Value
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 =
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 ManualApprovalCorrSet
Set
Message msgInterimLoan
Receive Shape
Property Value
Following Correlation Set ManualApprovalCorrSet
Message parFinalLoan
Add Orchestration Ports

Procedure List
Property Value
Name SharePointReq
Port Type Name (new Port Type) SharePointType
Direction Send
Property Value
Name SharePointResp
Port Type Name (existing Port Type) SharePointType
Direction Receive
5. Connect the Send shape to the SharePointReq port, and then connect the Receive
shape to the SharePointResp port.
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
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.

Procedure List
Property Value
Name LoanDenial
Port Type Name (new Port Type) LoanDenialType
Direction Send
3. Connect the Loan Denial send shape to the LoanDenial send port.
ProcessOrder_Credit.png.
Your ProcessOrder_Credit orchestration should look similar to the one shown in this
picture.
5. Close ProcessOrder_Credit.png.

Procedure List
Configure Port Bindings

Procedure List
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.

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
3. In the Start ‘Adventure Works’ Application dialog box, click Start.
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.
There are three messages: the notification that goes to Woodgrove Bank, the
completed message, and the restock message.
8. Delete the three messages.
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.
Notice the completed message and the restock message.
13. Delete the two messages.
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.
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.
22. In Windows Explorer, navigate to C:\AllFiles\LabFiles\Lab11\OUT, and notice the three
messages.
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.
27. In Windows Explorer, navigate to C:\AllFiles\LabFiles\Lab11\OUT, and notice the denial
message.
Lab 12 : Monitoring Business Activity
Scenario
Business Activity Monitoring (BAM) is a tool designed to be used by business analysts for
gathering business data from both archived and running business processes. In this lab, you will
see how to use several new tools, including the Microsoft Excel Business Activity Monitoring
Add-In and the BAM Portal, for analyzing business data that was processed by BizTalk Server.
Procedure List
window.

Procedure List
Exercise 1: Define a Business Activity
Overview
A business activity specifies the data from the business process that is captured by BAM. This
data may come from message content, message context, orchestrations, and other sources.
Once the business analyst has finished specifying the data to be gathered, the business activity
is exported to a BAM Definition File. In this exercise, you will use the Business Activity
Monitoring Add-In for Excel to specify the initial data to be collected as each purchase order is
processed by the system.
Define Milestones
Procedure List
1. On the Start menu, click All Programs, click Microsoft Office, and then click Microsoft
Excel 2010. In the Microsoft Office Activation Wizard window, click Cancel.
2. On the File menu, click Options
3. In the Excel Options window, in the left pane, click Add-Ins.
4. In the right pane, at the bottom, in the Manage list, click Excel Add-ins, then click Go.
5. In the Add-Ins dialog box, click Browse, and navigate to C:\Program Files
(x86)\Microsoft BizTalk Server 2010\ExcelDir, then click Bam.xla and click OK.
6. In the Add-Ins dialog box, in the Add-Ins available list, ensure that the Business Activity
Monitoring box is checked, and then click OK.
7. In the Excel menu ribbon, on the Add-Ins tab, click BAM, and then click BAM Activity.
8. In the Business Activity Monitoring Activity Definition dialog box, click New Activity.
9. In the Activity name box, enter OrderMgmt.
10. Click New Item, and in the New Activity Item dialog box, in the Item name box, enter
received, in the Item type list, click Business Milestones then click OK.
This milestone allows a timestamp value to be gathered from the message after the
message is received by the business process.
11. Repeat step 9, substituting in the following values to create the remaining Activity Items
needed to monitor the OrderMgmt business process.
Item Name Item type
denied Business Milestones
approved Business Milestones
acknowledged Business Milestones
City Business Data - Text
State Business Data - Text
Product Business Data - Text
Amount Business Data - Decimal
Later in this lab, you will specify the points in the business process at which each of
these data values will be collected by the BAM infrastructure.
12. Click OK twice.
Exercise 2: Define an Observation Model
The BAM definition that you initialized in the preceding exercise specifies the information to be
collected by BAM. In this exercise, you will create a BAM view. You will design this view by
adding progress dimensions and measures that categorize the data gathered by the BAM
activity. The data in the view is displayed as a Microsoft Office Excel PivotTable.
Create the Order Progress Dimension

Procedure List
1. On the Welcome to the Business Activity Monitoring View Creation page, click Next.
2. On the BAM View page, click Create a new view, and then click Next.
3. In the View name box, type SalesManager, select the Select all activities check box, and
then click Next.
This view will contain data most likely needed by a sales manager for daily, weekly,
or monthly reports. A BAM view can be thought of as similar to a Microsoft SQL
Server view in which you see only the data you need to see.
4. On the New BAM View: View Items page, select the Select all items check box, and
then click Next.
5. On the New BAM View: View Items page, review the aliases listed.
6. Click New Duration.
When a message is received, it is in the evaluation stage. After evaluation, it is either
approved or denied. If approved, two serial processes occur so that an instance is
either in the fulfillment stage or the fulfillment has occurred and a delivery
notification has been received. The sales manager is interested in how many
messages are in each phase, and therefore, this view is created to summarize this
data.
7. In the Duration Name box, type CycleDuration.
8. In the Start business milestone list, click received (OrderMgmt).
9. In the End business milestone list, click acknowledged (OrderMgmt).
10. In the Time resolution list, click Minute, and then click OK.
11. On the New BAM View: View Items page, click Next.
Dimension.
13. In the New Dimension dialog box, type OrderProgress as the Dimension Name, in the
Dimension Type list, click Progress Dimension, and then click New Milestone.
14. In the New Progress milestone dialog box, in the Progress milestone box, type
Received, in the Business milestone list, click received (OrderMgmt), and then click OK.
15. In the New Dimension dialog box, in the Progress milestones and stages section, click
Received, and then click New Stage.
16. In the New Progress Stage dialog box, in the Progress Stage field, type Evaluation, and
then click OK.
17. Click Evaluation, and then click New Milestone.
Approved, in the Business milestone list, click approved (OrderMgmt), and then click
OK.
19. Click Approved, and then click New Milestone.
20. In the New Progress Milestone dialog box, in the Progress milestone box, type Denied,
in the Business milestone list, click denied (OrderMgmt), and then click OK.
Approved, and then click New Stage.
22. In the New Progress Stage dialog box, in the Progress stage box, type Fulfillment, and
then click OK.
23. Click Fulfillment, and then click New Milestone.
DeliveredAck, in the Business milestone list, click acknowledged (OrderMgmt), and
then click OK.
Denied, and then click New Stage.
26. In the New Progress Stage dialog box, in the Progress stage box, type Contacting, and
then click OK.
27. Click Contacting, and then click New Milestone.
DeniedAck, in the Business milestone list, click acknowledged (OrderMgmt), and then
click OK.
Screen shot of the completed New Dimension dialog

29. In the New Dimension dialog box, click OK.
Create the Count Measure

Procedure List
Measure.
In the following steps, you will configure the Count aggregation type, which will
count all order activities passing through the system.
2. In the New Measure dialog box, in the Measure name box, type Count.
3. Click Count in the Aggregation Type section, and then click OK.
This will automatically select the OrderMgmt activity as the base data item because
it will be a count of all order activities passing through the system.
Create the AvgCycleDuration Measure

Procedure List
Measure.
2. In the New Measure dialog box, in the Measure name box, type AvgCycleDuration.
3. In the Base data item list, click CycleDuration (OrderMgmt).
4. Click Average, and then click OK.
Create the MyTimeSlice Time Duration

Procedure List
Dimension.
6. In the New Dimension dialog box, in the Dimension name box, type MyTimeSlice, in the
Dimension type list, click Time Dimension, in the Base business milestone list, click
received (OrderMgmt), click Year, month, day, hour, minute, and then click OK.
Configure the BAM View

Procedure List
1. On the New BAM View: Aggregation Dimensions and Measures page, click Next.
2. On the New BAM View: Summary page, click Next.
3. Click Finish.
An empty PivotTable will appear along with a pre-populated PivotTable field list.
4. From the PivotTable Field list box, drag the OrderProgress field onto the Drop Row
Fields Here box in the PivotTable.
5. Drag the Count measure from the PivotTable Field list box onto the Drop Value Fields
Here box.
6. Double-click the Received cell in the PivotTable to expand it.
You will see three values: Approved, Denied, and Evaluation.
7. Double-click the Approved cell.
You will see two values: DeliveredAck and Fulfillment.
8. Right-click the Approved cell, and then click Pivot Table Options.
9. In the PivotTable Options dialog box, in the Name box, type Order Progress, and then
click OK.
This is the name that will identify this particular aggregation in the BAM Portal that
will be used later.
10. On the Excel menu ribbon, click the Add-Ins tab, and in the Toolbar Commands section,
click the Real Time Aggregation (RTA) button.
11. In the Excel menu ribbon, click BAM, and then click Export XML.
12. In the Export BAM XML dialog box, type OrderMgmt_MyBAMDefinition.xml as the file
name, and then save the file to the desktop.
At this point, you can save the Excel workbook with any name you want to the
desktop before closing Excel.
Exercise 3: Deploy the BAM Observation Model
Overview
Once the business analyst has created the BAM activity and view, an IT professional will deploy
the BAM Observation Model to generate the structure of the BAM databases. In this exercise,
you will deploy the BAM Observation Model by using the BAM command-line tool.
Deploy the BAM Observation Model Created by the Business Analyst

Procedure List
3. In the command prompt window, type cd %BTSInstallPath%\tracking”, and
then press ENTER.
4. In the command prompt window, type bm.exe deploy-all -DefinitionFile:
“C:\AllFiles\LabFiles\Lab12\OrderMgmt_BAMDefinition.xml”, and then press ENTER.
5. When the command is complete, close the command prompt window.
This task dynamically creates all of the BAM infrastructure needed based on the
observation model that was created in Exercises 1 and 2.
Exercise 4: Map a BAM Activity to the Implementation
Overview
After the BAM activity has been deployed by the IT professional, a developer will link the BAM
activity to the BizTalk implementation. In this exercise, you will use the Tracking Profile Editor
(TPE) to create a tracking profile that maps the BAM activity to a receive port and to an
orchestration. You will then apply the tracking profile.
Select the Target BAM Activity for Which to Create a Tracking Profile
Procedure List
2. In the left pane, click Click here to import a BAM Activity Definition.
3. In the Import BAM Activity Definition dialog box, in the bottom pane, click OrderMgmt,
verify that Retrieve the current tracking settings for this activity definition check box is
cleared, and then click OK.
Map the Received Milestone

Procedure List
1. In the Tracking Profile Editor, in the top-right corner, click Select Event Source, and then
click Select Messaging Property.
Here you are mapping the Received milestone defined by the business analyst to an
actual step in the business process.
3. Drag the PortEndTime node to the received node in the left pane.
4. In the left pane, right-click PortEndTime, and then click Set Port Mappings.
5. In the Select Ports dialog box, click OrderMgmt_RcvPO, click the > button to map the
port, and then click OK.
The port mapping part of this step is necessary because the same order might pass
through multiple receive ports. The port mapping specifies the port from which the
information will be collected.
Map the City Payload Item

Procedure List
1. Click Select Event Source, and then click Select Messaging Payload.
3. In the Select Schema dialog box, under Schema Name, click
OrderMgmt.PurchaseOrder, and then click OK.
Now you will map the City item to actual values from the physical
OrderMgmt_RcvPO port configured in the BizTalk Server Administration Console.
5. Drag the City schema item under ShipTo from the right pane to the City item in the left
pane.
6. Right-click City in the left pane (where you just dropped it), and then click Set Port
Mappings.
Map Additional BAM Milestones

In the following steps, you will add BAM milestones to the actual orchestration. You will be able
to query BAM for information about messages that were denied and acknowledged. Every order
will either be denied or acknowledged, but cannot be both.
Procedure List
Multiple orchestrations could exist in the OrderMgmt assembly, so in these steps,
you must associate the correct orchestration with the business analyst’s BAM views.
4. Drag the FulfillmentDelay shape from the orchestration to the approved milestone in
the left pane.
5. Drag the RejectionDelay shape to the denied milestone in the left pane.
Any order received will reach only one of these milestones because they are mutually
exclusive outcomes of a presumed order evaluation—an order is either approved or
denied.
6. Drag the SendPOAck shape to the acknowledged milestone in the left pane.
Map the Remaining BAM Activity Items

In the following steps, you will associate specific fields from the PurchaseOrder schema to fields
in BAM.
Procedure List
1. Right-click the ReceivePO shape, and then click Message Payload Schema.
3. Expand Item and Summary.
4. Drag the State schema item (under ShipTo) to the State data item in the left pane.
5. Drag the Product schema item (under Item) to the Product data item in the left pane.
6. Drag the Amount schema item (under Summary) onto the Amount data item in the left
pane.
Create a Continuation
A BAM continuation is analogous to a correlation set in an orchestration. Continuations are sets
of unique values that allow the BAM infrastructure to identify all messages that belong to the
same instance of a BAM activity. In this lab, you must define a continuation to indicate that the
messages accepted by the receive port belong to the same activity as those that are processed
by the orchestration.
Procedure List
New Continuation.
2. Set the name of the new continuation to OrderMgmtContinuation.
3. In the Tracking Profile Editor, in the top-right corner, click Select Event Source, and then
click Select Messaging Property.
5. From the right pane, drag the InterchangeID node to the new OrderMgmtContinuation
node in the left pane.
6. In the left pane, right-click InterchangeID, and then click Set Port Mappings.
This step instructs the BAM infrastructure to initialize the continuation with the
value of the message’s interchange ID. The interchange ID is a GUID that identifies
this message and any of its descendants.
8. In the left pane of the Tracking Profile Editor, right-click OrderMgmt, and then click New
ContinuationID.
9. Set the name of the new continuation ID to OrderMgmtContinuation.
The name of the continuation ID must match the name of the original continuation.
13. Right-click the ReceivePO shape, and then click Message Property Schema.
14. In the right pane, expand MessageProperties, and then drag the InterchangeID node to
the new continuation ID node that you just created.
The ReceivePO shape will report the message’s interchange ID to the BAM
infrastructure, allowing BAM to associate this message with the correct BAM
activity.
Deploy the Tracking Profile

Once you have deployed the Tracking Profile to the BAM run-time environment, the BAM
infrastructure will start collecting data from messages that pass through the business process.
Procedure List
1. On the File menu, click Save.
2. In the left pane, click Desktop, in the File name box enter OrderMgmt.btt, and then
click Save.
3. In the Tracking Profile Editor, on the Tools menu, click Apply Tracking Profile.
4. In the Tracking Profile Editor message box, click OK.
Exercise 5: Use the BAM Portal to Test the BAM Implementation
The BAM portal provides users with a Web interface to view the data collected by BAM. In this
exercise, you will submit messages, and then use the BAM portal to view the information
collected by BAM about the processing of each purchase order.
Generate Initial Inbound Flow of Purchase Orders

Procedure List
1. In the BizTalk Server Administration Console, start the OrderMgmt application.
2. In Windows Explorer, double-click the file
C:\AllFiles\LabFiles\Lab12\Messages\Send20POs.bat.
The batch file used here generates 20 test orders so that you will have some data to
analyze in this exercise.
Launch the BAM Portal and View Order Progress Data Aggregation
Procedure List
1. In Internet Explorer, navigate to http://localhost:8080/BAM.
2. In the My Views navigation pane, expand the Sales Manager view.
3. Click the plus sign (+) to expand the function named Aggregations, and then click Order
Progress.
4. In the Microsoft Office 2003 Web Components message box, click OK.
If you do not see any data in the Pivot Table View, click the button with the red
exclamation point (!) icon in the PivotTable tool bar to refresh the view. Because of
SQL Server / OLAP caching, it might take up to one minute for the data to appear.
5. Click the plus signs (+) to expand cells in the PivotTable until Evaluation is shown with a
corresponding Total amount.
Generate Another Inbound Flow of Purchase Orders

Procedure List
1. Double-click the file C:\AllFiles\LabFiles\Lab12\ Messages\Send20POs.bat to create
and submit 20 new purchase orders.
Review the Detailed Status Information

Procedure List
1. Expand the Column Chooser section, select all remaining items in the Available Data
and Milestones pane, and then click the >> button to move them to the Items to Show
pane.
2. Collapse the Column Chooser section, and then click the Execute Query button at the
top right of the page to run the query again.
The user might want to modify the query itself. Specifically, if the number of items
presented by this Show Results action is too large, it might be necessary to use some
refinement criteria to limit the list to something workable. For example, of the orders
piling up in this processing stage, you might care only about those that have been in
that stage for more than a certain number of hours. You can refine the query by
expanding the Query section of this page and modifying the set of query clauses.
Lab 13 : Receiving Messages with a WCF Adapter
Overview
This lab will introduce you to the integration between the BizTalk Server messaging components
and Web services. You will use a built-in WCF adapter, which provides integration with Web
services using Windows Communication Foundation.
First, you will generate a Web service from an existing schema definition using the BizTalk WCF
Service Publishing Wizard. Then you will learn how to properly configure a receive port and the
virtual directory containing the generated service endpoint.
Procedure List
window.

Procedure List
Exercise 1: Publish a Schema as a Web Service
Overview
In the first part of this lab, you will publish the OrderExternal.xsd schema as a service, which will
make it easier for service-enabled consumers to integrate with the application. Your task now is
to configure a new receive location that accepts messages with the WCF-BasicHttp adapter. You
can accomplish this by generating a WCF service endpoint from OrderExternal.xsd. The rest of
the messaging implementation (e.g., the various send ports) will continue to work the same
way.
Examine the Northwind External Order XML Schema

Procedure List
1. In Windows Explorer, navigate to C:\AllFiles\LabFiles\Lab13\NorthWind, and then
open NorthWind.sln.
This is a new solution that contains three projects – the Maps, Orchestrations and
Schemas projects.
2. In the Schemas project, open the OrderExternal.xsd schema.
This is the schema that will be published as a WCF service.
Start the WCF Service Publishing Wizard

Procedure List
WCF-BasicHttp.
5. From the BizTalk application name list, select Northwind , and then click Next.
6. On the Create WCF Service page, click Publish schemas as WCF service, and click Next.
Specify the Service Details

In this step you will describe the service details, specifically the service contract details, such as
the service name, operation names, message exchange patterns, and what schema types each
request/response message maps to.
Procedure List
1. On the WCF Service page, in the Web service description pane, right-click
BizTalkWcfService, choose Rename web service description, and enter
OrderProcessingServiceDescription.
2. Right-click Service1, click Rename web service, and enter OrderProcessingService.
3. Right-click Operation1, click Delete web method, and then click Yes.
The WCF Publishing Wizard provides a request/response operation by default, but
the OrderProcessing service requires a one-way web method.
4. Right-click OrderProcessingService, point to Add web method and click One-way.
5. Right-click Operation1, click Rename web method, and then enter SubmitOrder.
6. Right-click on Request, and choose Select schema type.
7. In the Request Message Type dialog box, click Browse and navigate to
C:\AllFiles\LabFiles\Lab13\Northwind \Schemas\bin\Debug, click Northwind
.Schemas.dll, and then click Open.
8. In the Available schema types list, click Northwind .Schemas.OrderExternal, then click
OK, and then click Next.
enter http://services.northwind.com/orders, and then click Next.
10. On the WCF Service Location page, in the Location box, enter
http://localhost:8080/OrderProcessingService.
11. Check the Allow anonymous access to WCF service box, and then click Next.
12. On the WCF Service Summary page, review the summary text, click Create, and then
wait for the code-generation process to complete.
13. On the Completing the BizTalk WCF Service Publishing Wizard page, click on the link to
open the folder containing the generated code.
You now have a WCF service that is capable of receiving OrderExternal messages.
The service will submit any messages that it receives to the MessageBox.
14. In Windows Explorer, double-click OrderProcessingService.svc to view the generated
code.
Notice that the file contains only a ServiceHost directive using a custom factory for
BizTalk Services. This factory uses the metadata in the BizTalk management
database and the XML files found in the App_Data directory to generate a runtime
service and respond to metadata requests.
Configure the WCF Service in IIS

Before you can begin using this service to integrate with BizTalk, you must first configure the
directory to run in an IIS Application Pool running under an identity that is a member of the
BizTalk Isolated Host Users group.
Procedure List
1. On the Start menu, click Administrative Tools, and then click Internet Information
Services (IIS) Manager.
BIZTALKDEMO node, and then click Application Pools.
3. Right-click the Application Pools node, and then click Add Application Pool.
4. In the Add Application Pool dialog box, in the Name box, enter NorthwindWebServices.
5. In the .NET Framework version list, select .NET Framework v4.0.30319, and then click
OK.
6. In the center pane, right-click NorthwindWebServices, and then click Advanced
Settings.
7. In the Advanced Settings dialog box, click Identity, and then click the ellipses (…)
button.
8. Click Custom Account, and then click the Set button.
9. In the User name box, enter BizTalkIsoHost.
10. In the Password and Confirm password boxes, enter pass@word1, and then click OK
three times.
11. Right-click NorthwindWebServices and then click Recycle.
Sites and the Default Web Site nodes.
13. Right-click OrderProcessingService, point to Manage Application, and then click
Advanced Settings.
14. Click Application Pool, and then click on the ellipses (…) button.
15. From the Application pool list, select NorthwindWebServices, and then click OK twice.
At this point, the WCF service is configured to run in an application pool having an
identity that is allowed publish messages to the MessageBox.
Configure the Generated Receive Port

Procedure List
2. Expand BizTalk Server Administration, BizTalk Group, Applications and Northwind .
3. In the BizTalk Server Administration Console window, under the Northwind
application, click Receive Ports.
4. Double-click the WcfReceivePort_OrderProcessingService/OrderProcessingService
receive port.
5. In the Receive Port Properties dialog box, in the left pane, click Inbound Maps, and then
in the Inbound maps list, in the Maps column, select ExternalToInternal.
6. In the left pane, click Receive Locations, then in the right pane, double-click the
WcfService_ OrderProcessingService /OrderProcessingService receive location.
7. In the Receive Location Properties dialog box, verify that the Type is WCF-BasicHttp,
and the Receive handler is BizTalkServerIsolatedHost, and then click Configure.
Notice that the Address (URI) is simply the path to the generated .svc file.
9. Check the Suspend request message on failure box, and the Include exception detail in
faults box.
These settings are especially useful in development environments. In production you
would most likely not want to return exception details in your faults as it provides
more detailed information than you want the client to have. The option to suspend
messages generally comes down to dealing with denial of service (DOS) attacks or
problematic clients that send many faulty messages. Leaving this option unselected
enables you to ignore those messages.
12. Right-click the WcfService_ OrderProcessingService /OrderProcessingService receive
location and click Enable.
13. Verify that the status changes to Enabled.
Test the WCF Service Deployment

You now have an enabled receive location capable of receiving incoming SOAP requests. Before
proceeding, you will test the service to make sure it is configured correctly.
Procedure List
1. On the Start menu, click Run, and enter
http://localhost:8080/OrderProcessingService/OrderProcessingService.svc, and then
click OK.
2. Verify that the BizTalkServiceInstance page is displayed in Internet Explorer.
3. Click on the link near the top of the page to display the WSDL file for the web service.
Exercise 2: Consume and Test the Web Service
Overview
In this exercise, you will use a simple client application to submit orders to the web service
Update the Web Service Client Application

Procedure List
1. In Windows Explorer, navigate to C:\AllFiles\LabFiles\Lab13\OrderSubmissionApp, and
then open OrderSubmissionApp.sln.
2. In Solution Explorer, expand the Service References folder.
3. Right-click the Orders service reference, and then click Configure Service Reference.
4. Ensure that the value in the Address box is
http://localhost:8080/OrderProcessingService/OrderProcessingService.svc, and click
OK.
Visual Studio will update the service reference by downloading the latest WSDL from
the web service URL.
5. Right-click the OrderSubmissionApp solution, and then click Build Solution.
6. Verify that there were no compilation errors.
Submit Orders to the Web Service with the Client Application

Procedure List
1. Press CTRL + F5 to run the solution without debugging.
2. Enter some sample data as shown below, and then click Submit.
3. Verify that a dialog box appears confirming that the order was submitted successfully.
If you get an error, try running the application in debug mode with a breakpoint on
the catch block to get more detail on the error. Make sure your receive location is
enabled and the host instance are running.
4. In Windows Explorer, navigate to C:\AllFiles\LabFiles\Ports\BillingDept and verify that
a new message has been created.
Lab 14 : Calling a Web Service from an Orchestration
Overview
The purpose of this lab is to introduce you to the integration between the BizTalk Server
messaging components and Web services. You’ll use a built-in WCF adapter, which provides
integration with Web services using Windows Communication Foundation
First, you will add a service reference to generate the necessary artifacts for consuming a web
service using the WCF adapters. Next you’ll walk through the process of consuming a web
service from within an orchestration.
Procedure List
window.

Procedure List
Exercise 1: Setup a Web Service Call in the Orchestration Designer
Overview
In the first part of this lab, you will modify an orchestration to call a web service that returns the
credit rating for a given customer. You will set up a two-way send port in the orchestration to
the customer ID to the web service, and receive the response.
Review the CustomerService Web Service

Procedure List
1. In Internet Explorer, browse to http://localhost:8080/Northwind/CustomerCredit.svc
2. Verify that the CustomerCredit Service documentation page appears.
3. Click on the link at the top of the page to view the WSDL document. Notice that the
service has a single operation named GetCustomerRating.
The GetCustomerRating operation is designed to check the credit status for a
particular customer. The orchestration will use the returned information to make a
decision about whether to approve the order.
Add a Service Reference to the Orchestrations Project

Procedure List
1. In Windows Explorer, navigate to C:\AllFiles\LabFiles\Lab14\Northwind, and then open
Northwind.sln.
2. Double-click RouteOrder.odx in the Orchestrations project.
3. In Solution Explorer, right-click on the Orchestrations project, click Add, and then click
4. In the dialog that appears, select Consume WCF Service and click Add.
5. In the Consume WCF Service wizard, click Next until you can enter the URL for the
service.
6. In the URL box, enter http://localhost:8080/Northwind/CustomerCredit.svc
7. Click Get to retrieve the service description.
8. Click Next, and then click Import.
This downloads the service's WSDL definition and generates the corresponding
orchestration type definitions in the CustomerCredit.odx file
Add the Web Service Messages to the Orchestration

Procedure List
1. Make sure RouteOrder.odx is still visible in the Orchestration Designer, click on the
Orchestration View tab, and then expand the Types node.
You should see CustomerCredit in the list of port types. This port type models the
request/response message pair needed to invoke the service. Notice that it contains
a single operation named GetCustomerRating
2. Expand the Multi-part Message Types node.
Notice it contains two new message types, one for the GetCustomerRating request
message and another for the corresponding response
4. In the Properties window, in the Identifier box, enter GetCustomerRatingRequest.
Northwind.Orchestrations.CustomerService_GetCustomerRating_InputMessage
7. In the Properties window, in the Identifier box, enter GetCustomerRatingResponse.
OrderProcessing.Orchestrations.CustomerService_GetCustomerRating_OutputMessage
Add the Web Service Send Port to the Orchestration

Procedure List
1. Right-click on the right-side port surface.
2. Click New Configured Port, and in the Port Configuration Wizard, click Next.
3. On the Port Properties page, in the Name box, enter CheckCustomerCredit, and click
Next.
Port Types tree, click Northwind.Orchestrations.CustomerCredit.
5. Select I'll be sending a request and receiving a response for the direction of
communication and click Next.
6. Click Finish.
You should now see a Port on the port surface that models the interaction with
CustomerCredit.svc. Notice that the port type provided all of the operations from the
service, driven by the metadata you consumed with the wizard.
Add Orchestration Shapes to Call the Web Service

Procedure List
1. Place a Group shape just under the initial Receive shape.
2. In the Properties window, in the Name box, type Call CheckCustomerCredit.
3. Place a Construct Message shape within the Group shape.
4. In the Properties window, in the Name box, type Construct
GetCustomerRatingRequest.
5. In the Messages Constructed list, click GetCustomerRatingRequest.
6. Place a Message Transform shape within the Construct Message shape, and name it
CopyCustomerID.
7. Double-click on the CopyCustomerID shape to open the map configuration.
8. Rename the map to
Northwind.Orchestrations.MapOrderToGetCustomerRatingRequest.
9. Configure the Source message to be the OrderMessage.
10. Configure the Destination message to be GetCustomerRatingRequest.parameters.
11. Click OK, and when the map opens, drag a link from the source CustomerID node to the
destination CustomerID node, and close the map.
12. Place a Send shape within the Group under the Construct Message shape.
13. Name the new Send shape SendGetCustomerRatingRequest.
14. Set its Message to GetCustomerRatingRequest.
15. Place a Receive shape within the Group, under the Send shape.
16. Name the Receive shape ReceiveGetCustomerRatingResponse.
You're going to use the Send/Receive shapes to invoke the service by sending the
required messages to the Port
17. Drag a connection from the Send shape to the port’s Request connector.
18. Drag a connection from the Receive shape to the port’s Response connector.
19. Your orchestration should look like the following screenshot:
Promote Distinguished Fields in the Web Service Response Schema
Procedure List
1. In Solution Explorer, double-click on
CustomerCredit_northwind_com_fbts_customers.xsd.
2. Right-click on GetCustomerRatingResponse, and click Promote, then click Show
Promotions.
3. In Promote Properties dialog box, in the left pane, expand GetCustomerRatingResponse
and GetCustomerRatingResult.
4. Click Rating, and then click Add.
5. Click CreditLimit, and then click Add.
6. Press OK to accept the promotions, and on the File menu, click Save All.
Now the orchestration will have access to these fields (via the
GetCustomerRatingResponse message).
Add Shapes to Handle the Credit Decision

Procedure List
1. In Solution Explorer, double-click RouteOrder.odx.
2. Place a Decide shape just under the new Group and in the Properties window, in the
Name box, enter If customer has sufficient credit.
3. Rename Rule_1 to Rule_CheckCustomerCredit.
4. Double-click on Rule_CheckCustomerCredit to open the BizTalk Expression Editor. Then
enter the following expression:
GetCustomerRatingResponse.parameters.GetCustomerRatingResult.Rating > 2.5
5. Click OK to accept the expression.

When this expression evaluates to true, the left branch of the decision is followed.
Otherwise the right branch is followed.
6. Drag all of the remaining shapes in the orchestration into the left branch.
Normal processing will only occur when the customer has sufficient credit.
When the customer doesn't have sufficient credit, we need to send the
OrderMessage to a "Rejected" queue for human processing (we'll just use a folder on
the file system).
Add a Port to Handle Rejected Orders

Procedure List
1. Right-click on the right-side port surface and select New Configured Port.
3. On the Port Properties page, in the Name box, enter RejectedPort.
4. Click Create a new Port Type and in the Port Type Name box, enter PortType_Rejected,
then click Next.
5. Choose I'll always be sending messages on this port and leave Specify later for the
binding, then click Next.
6. Press Finish to create the new port.
7. Place a Send shape within the decision shape's Else branch.
8. In the Send shape’s Properties window, in the Name box, enter SendRejectedOrder.
9. In the Message list, click OrderMessage.
10. Connect the Send shape to the RejectedPort Request connector.
11. At this point, your orchestration should look like this screenshot:
Procedure List
1. In Solution Explorer, right-click on the Northwind solution and click Build Solution.
2. Verify that the build completes successfully.
3. Right-click on the Northwind solution and click Deploy Solution.
4. Verify that the deployment succeeds.
Exercise 2: Configure the Orchestration and Send Ports
Overview
In this exercise, you will configure the Northwind application using the BizTalk Administration
console. The first binding file that you will import does not include the bindings for the new
WCF ports. The second binding file that you import will configure the WCF send port required
for the web service call. Finally, you will bind the orchestration to its ports to complete the
configuration.
Procedure List
1. Open the BizTalk Administration Console and navigate to the Northwind application.
2. Right-click the Northwind application, point to Import, and click Bindings.
3. Navigate to C:\AllFiles\LabFiles\Lab14\Northwind, click Northwind.Bindings.xml, and
then click Open.
4. Validate that five send ports and one receive location are created.
Import the Configuration for the WCF Send Port

Procedure List
1. In the BizTalk Administration Console, right-click the Northwind application, point to
Import, and click Bindings.
2. Navigate to C:\AllFiles\LabFiles\Lab14\Northwind\Orchestrations, click
CustomerCredit.BindingInfo.xml, and then click Open.
This binding file contains information that was gathered when you added a service
reference. It can be used to configure the send port so that it properly
communicates with the listening service.
Configure the Orchestration Bindings

Procedure List
1. Within the Northwind application, select the Orchestrations folder.
2. Double-click on Northwind.RouteOrder, and select the Bindings tab.
3. Bind the logical CheckCustomerCreditPort to the physical
WcfSendPort_CustomerCredit_BasicHttpBinding_CustomerCredit port that was
created by the import.
4. Bind the logical RejectedPort to the physical Northwind_SendToRejected port.
All of the other ports should already be bound to their physical counter parts.
5. Click OK to accept the bindings.
6. Double-click the Northwind.Orchestrations.CustomerCredit orchestration.
7. Select the Bindings tab.
8. Select BizTalkServerApplication for the host.
Exercise 3: Test the Orchestration
Overview
In this exercise, you will submit a message to the orchestration that will initiate a call to the
CustomerCredit web service.
Send a Message to the Orchestration

Procedure List
1. In the BizTalk Administration Console, right-click on Northwind and click Start, and in
the Start ‘Northwind’ Application prompt, click Start.
2. Verify that the application starts successfully.
3. In Windows Explorer, copy C:\AllFiles\LabFiles\Lab14\OrderExternal.xml to the
C:\AllFiles\LabFiles\Ports\OrderIN folder, and click paste several times to generate
multiple copies of the order.
CheckCustomerService returns a random rating for each customer between 0-5. Our
rule rejects orders when the rating isn't greater than 2.5. Verify that some of the
orders are approved and some rejected. Approved orders will get inserted into the
Northwind database orders table, while rejected orders should show up in the
c:\ports\rejected folder.
4. You have successfully invoked a WCF service from within a BizTalk orchestration.
In production solutions, you will want to put the service interactions within Scope
shapes so you can handle SOAP faults and deal with them appropriately.
Lab 15 : Implementing Dynamic Messaging Patterns
Overview
In this lab you will update the Northwind ordering process to make the orchestration messaging
more dynamic and add support for correlation. You will use role links to provide partner specific
sending and receiving and add dynamic links to support a publish and subscribe messaging
model for you orchestrations. In addition, you will use correlation to route related messages to
an orchestration instance.
Procedure List
window.

Procedure List
Exercise 1: Use Correlation
Overview
In this part, you will message correlation to the order process. In this case, you will send a
message from the order process to a shipping process, and get a response back for this
particular order by correlating messages on the Order ID.
Examine the Shipping Orchestration

The shipping orchestration handles shipping requests and routes them to an appropriate
shipper.
Procedure List
1. In Windows Explorer, navigate to C:\AllFiles\LabFiles\Lab15\Northwind and open the
Northwind.sln solution in Visual Studio.
2. Open the Shipping.odx and examine the orchestration. This orchestration receives a
shipping request and then sends out a notice before replying with an acknowledgement.
3. Examine the MessageCreator.cs file in the Utilities project. This class is used by the
shipping orchestration to create the acknowledgement message. It clones an XML
document which contains a valid instance of the acknowledgement message type.
Set Up Schemas for Correlated Messaging

Procedure List
1. Open the MyProperties.xsd schema, and add a property named OrderIdentifier.
2. Save and close the property schema.
3. Open the ShippingRequest.xsd schema, expand the ShipRequest node and right-click
the OrderID attribute and click Promote, then click Show Promotions.
4. Go to the Property Fields tab and add the Northwind.Schemas.MyProperties schema as
a property schema.
5. Set the namespace prefix to prop and then add the OrderID attribute to the promoted
properties. In the Property Fields list, in the Property list, select prop:OrderIdentifier.
6. Save and close ShippingRequest.xsd.
7. Repeat steps 3-5 above for the ShipmentID field in the ShipAck.xsd schema.
Add Shipping Artifacts to the Ordering Orchestration
Procedure List
1. Add the existing MapOrderToShipRequest.btm file from the
C:\AllFiles\LabFiles\Lab15\Northwind\Artifacts directory to the Maps project.
2. Right-click on the Maps project and click Build.
3. Open the RouteOrder.odx orchestration.
4. In the Orchestration View, right-click the Messages node and add a new message.
5. Use the Properties window set the identifier of the message to ShipAcknowledgement.
6. Set the Message Type property by clicking Schemas, then click
Northwind.Schemas.ShipAck.
7. Create another message named ShipRequest with a type of
Northwind.Schemas.ShippingRequest.
Add Shapes to Communicate with the Shipping Orchestration

Procedure List
1. Delete the “Shipping Destination?” Decision shape.
2. Delete the ShippingUSASendPort and ShippingInternationalSendPort ports.
3. At the end of the RouteOrder orchestration add a Construct Message shape with a
Transform and a Message Assignment shape inside of it.
4. Follow this by a Send shape and then a Receive shape. Set the properties as shown in
the table below. Review the image that follows the table to see the intended outcome.
Property Value
Construct shape
Messages constructed ShipRequest
Name Construct ship request
Transform shape
Name MapOrderToShipRequest
Map Northwind.Maps.MapOrderToShipRequest
Note: This map exists in the Northwind.Maps assembly.
Input Message OrderMessage

Output Message ShipRequest
Message Assignment shape
Name AssignOrderID
Expression
ShipRequest(Northwind.Schemas.OrderIdent
ifier) =
System.String.Format("{0:N}",
System.Guid.NewGuid());
Send shape
Name SendShipRequest
Message ShipRequest
Receive shape
Name ReceiveShipAcknowledgement
Message ShipAcknowledgement
5. In the orchestration view window, expand the Types node and right click Correlation
Types, and then click New Correlation Type.
6. In the left pane, expand Northwind.Schemas, click OrderIdentifier then click Add, and
then click OK.
The Northwind.Schemas.OrderIdentifier property is now included in the correlation
type.
7. Set the Identifier property on the correlation type to ShippingCorrelationType.
You have defined a correlation type, which identifies which context properties will be
used to correlate. In the next step, you will define a correlation set which is a
container for specific data, based on this type.
8. Right click the Correlation Sets node to create a new correlation set.
9. Set the identifier property to ShippingCorrelation.
10. Set the correlation type to Northwind.Orchestrations.ShippingCorrelationType
11. On the SendShipRequest shape, set the Initializing Correlation Sets property to
12. On the ReceiveShipAcknowledgement shape, set the Following Correlation Sets to
You have configured the two ports to participate in correlation. When a message is
sent from the send port, it will initialize the correlation set with the values currently
in the context properties. The receive shape that follows the correlation set will now
have an instance subscription based on the correlation set values.
14. In the wizard, name the port ShippingPort and create a new port type named
ShippingPortType.
15. In the next wizard pane, indicate that you will be sending messages and accept all other
defaults.
17. In the wizard, name the port ShippingAckPort and create a new port type named
ShippingAckPortType.
18. In the next wizard pane, indicate that you will be receiving messages and accept all
other defaults.
19. Drag the connection points from the send and receive shapes to these new ports as
appropriate.
Construct the Shipping Acknowledgement Message

Procedure List
1. Open the Shipping.odx orchestration, and inside the ConstructAck Construct Message
shape, double-click the Create Ack Message Assignment shape.
2. In the BizTalk Expression Editor window, enter the following line of code, then click OK.
OrderShipAck = Northwind.Utilities.MessageCreator.CreateShipAck(
OrderShipRequest(Northwind.Schemas.OrderIdentifier));

Procedure List
The Northwind.Utilities project was already deployed to the GAC when you ran the
original setup script for this lab.
Configure the Application Ports

Procedure List
2. Right-click the Northwind application and click Import, then click Bindings.
3. Import the Northwind.Correlated.BindingFile.xml from the
C:\AllFiles\LabFiles\Lab15\Northwind folder.
4. Examine the send and receive ports added to the application and view the configuration
of the adapters. There are several File ports that will be used to send the messages
between the orchestrations.
5. Right-click the Northwind application and choose Configure.
6. Configure the RouteOrder orchestration by binding the logical ports to the physical
ports with the following mappings:
OrderReceivePort Northwind_ReceiveOrders
ShippingAckPort Northwind_ReceiveShipAck
ShippingPort Northwind_ShipRequest
7. Configure the Shipping orchestration by binding the logical ports to the physical ports
with the following mappings, and choosing the BizTalk Server Application as the host:

ReceiveShippingRequestPort Northwind_ReceiveShipping
ShipperPort Northwind_SendShippingAudit
ShipAckPort Northwind_SendShippingAck
8. Both orchestrations should show green check marks when all of the configuration is
complete.
9. Apply the changes and exit the configuration dialog.
Test the Solution

Procedure List
10. Right-click the Northwind application, and then click Start.
C:\AllFiles\LabFiles\Ports\OrderIN directory.
12. Open the C:\AllFiles\LabFiles\Ports\Audit directory and validate that the shipping
notice arrives.
13. To view the detailed steps, disable the Northwind_ReceiveShipAck_File and
Northwind_ReceiveShipping_File receive locations.
14. Submit a message, and you should find it waiting in C:\AllFiles\LabFiles\Ports
\shipping\requests.
15. Enable the Northwind_ReceiveShipping_File receive location and then you should find
the acknowledgement in the C:\AllFiles\LabFiles\Ports \shipping\acknowledgments
folder.
16. Enable the Northwind_ReceiveShipAck_File location and the process should complete.
Exercise 2: Using Role Links for Messaging
Overview
In this part, you will create a role link to identify the shipper role in the business process. Later,
you will define the parties which can play this role for this given process. This will allow the
actual send port to be chosen dynamically based on some data that identifies the party currently
playing that role.
Define a Role Link in the Shipping Orchestration

Procedure List
1. Open the Shipping.odx orchestration
2. Right-click in the right-hand port surface, and click New Role Link, and then click Next.
3. In the wizard, name the role link ShipperRoleLink and create a new role link type named
ShipperRoleLinkPortType.
4. Specify that the orchestration will be playing the role of consumer indicating that the
orchestration will be consuming the role link by sending the first message.
5. Click Finish.
6. Drag the ShipperPort to the provider space of the role link to indicate the port type
consumed by the orchestration as part of the role.
Notice that instead of ShipperPort the port is now called ShipperPortType. This is
because the role link is our logical entity now, and the port type is just that, a type.
Set the Destination Party
The orchestration must set the destination party for the role link so the appropriate send port
can be selected.
Procedure List
1. Using the orchestration view, add a new variable named shipperIdentifier of type
string.
2. Drag an Expression shape from the toolbox and add it to the orchestration just before
the SendToChosenShipper shape.
3. Set the name of the Expression shape to DetermineShipper and double-click the
Expression shape to edit the code.
4. Add the following code to the Expression shape which defines the shipper, and then sets
the destination party for the role link:
shipperIdentifier = "Federal Shipping";
ShipperRoleLink(Microsoft.XLANGs.BaseTypes.DestinationParty
) =
new Microsoft.XLANGs.BaseTypes.Party(
shipperIdentifier, "OrganizationName");
Note that in this scenario we hard code the shipper name. In a real scenario, you
would use business rules to dynamically determine the shipper. We use the shipper
name, but when defining parties, any custom identifier can be created as an alias for
that party and used to set the destination part. For example, your internal customer
id, or a DUNS number.
5. Your orchestration should look similar to the image below:
6. Build the solution and fix any problems that arise.

7. Right click the solution and choose Deploy Solution.
Exercise 3: Define Parties
Overview
In this part you will define the configuration related to the roles and send ports for the
orchestration. You will create physical send ports for each shipper and then enlist or link them
to the role link you defined in the business process.
Create the Send Ports for the Shippers

Procedure List
1. In Windows Explorer, validate that the folder c:\AllFiles\LabFiles\ports\shippers exists.
2. Within the folder above, are three folders representing the three shippers: Federal
Shipping, Speedy Express and United Package.
3. Open the BizTalk Server Administration Console and navigate to the Northwind
application node.
4. Add three static one-way send ports to represent three different shippers. The
configuration information is below:
Send Port: Shipper_United

Transport Type FILE
Address c:\AllFiles\LabFiles\Ports\shippers\UnitedPackage
Send Port: Shipper_Speedy
Transport Type FILE
Address c:\AllFiles\LabFiles\Ports \shippers\SpeedyExpress
Send Port: Shipper_Federal
Transport Type FILE
Address c:\AllFiles\LabFiles\Ports \shippers\ FederalShipping
5. Start all three send ports after they are created.
Define the Shippers and Assign Send Ports

Procedure List
1. Right-click the Parties node and create a new party.
2. Name the party Federal Shipping and then use the send port pane to select the
Shipper_Federal send port.
3. Repeat the above two steps to create parties named Speedy Express and United
Package associated to their respective send ports.
Enroll the Parties in the Orchestration Shipper Role

Procedure List
1. Click the Role Links node in the Northwind application
2. Double-click the Provider item and then click the Enlist button.
3. Check all three shippers and click OK
4. Highlight each party and click the Bind button, then select the appropriate send port to
bind to the NotifyShipper operation.
5. Be sure you have configured all shippers.
Test the Solution

Procedure List
1. Right-click the Northwind application and choose Start to start all send ports and
orchestrations.
3. Test the output by checking the FederalShipping directory to see if the shipping
acknowledgement appears.
Exercise 4: Use Direct Messaging Ports
Overview
In this part you will create a dynamic shared port between the two orchestrations. This will
continue to use a publish and subscribe model of messaging, but will not require that messages
be passed through an external intermediary like the file system used in the first part of the lab.
The messaging will all be done at the message box layer.
Configure a Dynamic Port

In this section, you will change the shipping request and acknowledgment ports to a single
dynamic port
Procedure List
2. Delete the ShippingPort and ShippingpAckPort from the design surface.
3. In the orchestration view, under the Types heading, delete the ShippingAckPortType
and ShippingPortType.
4. Right-click on the right-hand port surface, and click New Configured Port, and then click
Next.
5. In the Name box enter ShippingPort and then click Next.
6. Click Create a new port type, and in the Port Type Name box, enter ShippingPortType,
then click Request-Response, and then click Next.
7. On the port binding page, in the Port direction of communication list, click I’ll be
sending a request and receiving a response, then in the Port binding list, click Direct.
8. Click the radio button labeled To send messages to other orchestrations, select this
port here and in those orchestrations.
9. From the drop down, choose the Northwind.Orchestrations.RouteOrder. ShippingPort,
10. In the orchestration view, delete the ShippingCorrelation and ShippingCorrelationType.
You won’t need these correlation items now that you will be using direct messaging.
The messages will be correlated based on internal correlation values leveraging the
port information and orchestration instance ids.
11. Use the green connection points to hook the SendShipRequest and
ReceiveShipAcknowledgement shapes to the new port.
12. Build the solution and fix any problems.
Update the Shipping Orchestration to Use the Dynamic Port
Procedure List
1. Open the Shipping orchestration
2. Delete the ReceiveShippingRequestPort and ShipAckPort ports from the design surface.
3. From the orchestration view, delete the ReceiveShippingRequestPortType and
ShipAckPortType
4. Right-click on the left-hand port surface, and click New Configured Port, and then click
Next.
5. In the wizard, name the port RequestShippingReceivePort, and then click Next.
6. For the port type, choose to use the existing
Northwind.Orchestrations.ShippingPortType.
7. In the port binding page of the wizard, specify that you will be receiving and then
sending, and choose Direct for the port binding.
8. Click the radio button labeled To receive messages from other orchestrations, select
this port here and in those orchestrations.
9. From the drop down, choose: Northwind.Orchestrations.RouteOrder. ShippingPort,
10. In the orchestration designer, drag the connection points from the new port to the
receive and send shapes appropriately.
11. Your completed orchestration should look similar to the following:
12. Build your solution and fix any compiler errors.

14. Test by dropping the OrderExternal.xml file into the
15. Check the c:\AllFiles\LabFiles\Ports\Shippers\FederalShipping directory for the output.
Lab 16 : Applying the WCF LOB Adapter Framework
Overview
In this lab you’ll be using the WCF LOB Adapter SDK to build an “Adapter” which could be used
via a WCF Channel (inside or outside of BizTalk). After completing this lab, you should
understand how to create a WCF LOB Adapter using the WCF LOB Adapter SDK, use a WCF
Adapter and how to create a listener with a WCF Adapter. Using the WCF-Custom adapter, you
could invoke operations on the services from BizTalk as well.
Procedure List
window.
Exercise 1: Create a WCF LOB Adapter Framework Project
Overview
In this part, you will use a project wizard in Visual Studio to generate adapter code that can be
customized to suit your needs. You will use the wizard to generate connection properties that
you can use in your adapter to customize the runtime behavior.
Create a New Visual Studio Solution

Procedure List
1. Open Visual Studio 2010.
2. On the File menu, select New -> Project.
3. Highlight the Visual C# node in the Installed Templates pane, and find the WCF LOB
Adapter template in the center pane.
4. Specify the Name and Location as follows, then click OK to close the dialog:
Property Value
Name ContosoCustomAdapter
Complete the Wizard
Procedure List
1. The WCF LOB Adapter Wizard will appear, read the introduction and press the Next
button.
2. On the next page, enter the Scheme and Project Namespace as follows and click Next:
Property Value
Scheme Contoso
Project Namespace Contoso.CustomAdapter
3. On the Data flows page, select the checkboxes only for the synchronous data flows and
Metadata features so your dialog looks like this, and click Next:
This will create a project which allows all the different channel shapes as well as
enabling all metadata functionality.
4. On the Adapter Properties page, add the properties from the following table by
entering the information and clicking the Add button. Click the Next button when you
have completed.
Property Data Type Default Value

Transactional System.Boolean False
ListenerInterval System.Int32 5000
5. On the Connection Properties dialog, add a Connection Property of type System.String,

named UserName. Set the Default Value to "msmith".
6. Click Add, then the Next button.

7. Review the Summary Page, and then click the Finish button to generate the Adapter.
Build the Solution

Procedure List
1. Right-click on ContosoCustomAdapter in the Solution Explorer and select Build.
2. Confirm a successful build in the Output window.
Exercise 2: Implement an Outbound Handler
Overview
In this part, you will implement the outbound capabilities of the adapter that you created in
Exercise 1.
Implement an Outbound Handler

Procedure List
1. Open the ContosoCustomAdapterConnectionFactory.cs file.
2. Add a private field of type ContosoCustomAdapterConnectionUri named uri.
3. Update the constructor to set the value of this field based on the constructor
parameters.
//stores the connection string
private ContosoCustomAdapterConnectionUri uri;
public ContosoCustomAdapterConnectionFactory(
ConnectionUri connectionUri,
ClientCredentials clientCredentials,
ContosoCustomAdapter adapter)
{
this.clientCredentials = clientCredentials;
this.adapter = adapter;
this.uri =
(ContosoCustomAdapterConnectionUri)connectionUri;
}
4. Add a read-only property to the class to expose the uri.
public ContosoCustomAdapterConnectionUri ConnectionUri

{
get
{
return uri;
}
}
5. Open the ContosoCustomAdapterConnection.cs file.

6. Expand the hidden region marked IConnectionMembers.
7. In the Close, IsValid, and Open methods, remove the lines that throw a
NotImplementedException.
8. In the Open method, call Console.WriteLine and print out a string that indicates that the
connection object has been opened, indicating what the ServerName and UserName
properties of the connection are (these are properties on the ConnectionFactory
property of the Connection object).
uri = this.ConnectionFactory.ConnectionUri;
Console.WriteLine(
"Connection object opened - ServerName = {0}, UserName = {1}",
uri.Uri.Host,
uri.UserName);
You typically would open the phyiscal connection to your LOB or database in the
Open method of the IConnection object. .
9. In the Close method, call Console.WriteLine and print out a string that indicates that the
connection object has been closed.
uri = this.ConnectionFactory.ConnectionUri as
ContosoCustomAdapterConnectionUri;
Console.WriteLine(
"Connection object closed - ServerName = {0}, UserName = {1}",
uri.Uri.Host,
uri.UserName);
10. In the IsValid method, return true

11. Open the ContosoCustomAdapterConnectionUri.cs file.
12. Add a private field of type UriBuilder named "uriBuilder".
13. Update the constructor which takes a parameter to initialize the UriBuilder you just
defined.
this.uriBuilder = new UriBuilder(uri);

14. Provide the implementation for the Uri property so that you parse the URI to find the
value for the username field:
public override Uri Uri

{
get
{
return this.uriBuilder.Uri;
}
set
{
this.uriBuilder = new UriBuilder(value);
}
}
Write the Message Handling Code

Procedure List
1. In the adapter project, open the ContosoCustomAdapterOutboundHandler.cs file and
locate the Execute method.
2. Remove the line of code that throws a NotImplementedException.
3. Add code that prints out the body of the incoming Message.
Console.WriteLine("Incoming message {0}",

message.GetReaderAtBodyContents().ReadInnerXml());
4. After that code, add code that creates a new Message, with a MessageVersion of
MessageVersion.None, an action with a blank string, and a body of “A message from a
WCF Adapter”.
Message rm = Message.CreateMessage(
"",
"A message from a WCF Adapter");
return rm;
In a real implementation, this is where you would process the incoming message,
connect to your LOB application or database, and generate a proper return message.
5. Build the project and verify that it compiles before moving on to the next Exercise.
Exercise 3: Create an Outbound Client
Overview
In this part, you will create a simple WCF client application to test the adapter that you created
in Exercise 1.
Create a New Console Application Project

Procedure List
1. In Solution Explorer, right-click the ContosoCustomAdapter solution, then click Add, and
then click New Project.
3. Name the project OutBoundClient. The default location should be fine. Click OK.
4. Right-click on the OutBoundClient project, click Properties, then in the Target
Reference”.
6. Add a reference to the following assemblies (found under the .NET tab), then click OK:
Assembly Name
System.ServiceModel
Reference”.
8. Add a reference to the ContosoCustomAdapter project (found under the Projects tab).
Click OK to close the dialog.
Implement the Program Logic

Procedure List
1. Open the Program.cs file in the OutBoundClient project.
Namespace
System.ServiceModel
3. Inside of the Main method, create an instance of the ContosoCustomAdapterBinding

and set its Transaction property to true.
ContosoCustomAdapterBinding b = new
ContosoCustomAdapterBinding();
4. Use the ConstosoAdapterBinding reference to create an IChannelFactory<> of type

IRequestChannel, and Open the channel factory object.
IChannelFactory<IRequestChannel> rcf =
b.BuildChannelFactory<IRequestChannel>();
rcf.Open();
5. Create a new Message with a MessageVersion of MessageVersion.None, an action of a

blank string, and the body of “Sending message to adapter”).
Message msg = Message.CreateMessage(

"",
"Sending message to adapter");
6. Create a new EndpointAddress object, specifying the URI

"Contoso://alice@contososervername" as the URI to the constructor.
EndpointAddress epa =
new EndpointAddress("contoso://alice@contososervername");
7. Ask the ChannelFactory to create a Channel of the type of IRequestChannel passing in

the EndpointAddress you just created, and open the channel.
IRequestChannel rc = rcf.CreateChannel(epa);
rc.Open();
8. Call IRequestChannel.Request, passing in the Message you just created, use the return
value to initialize a new Message reference, and print out to the console the string value
of this message.
Message rmsg = rc.Request(msg);

Console.WriteLine("Adapter response message: {0}",
rmsg.GetReaderAtBodyContents().ReadInnerXml());
9. Build, and compile. Run once using Ctrl-F5 to verify the output to the console is correct.
Then set breakpoints in the methods you just implemented and run again – this time
using F5, so you can step through the interaction of the client to the adapter.
Exercise 4: Building an Inbound Handler
Overview
In this part, you will implement the inbound capabilities of the adapter that you created in
Exercise 1.
Setup the Handler

Procedure List
1. In the ContosoCustomAdapter project, open the
ContosoCustomAdapterInboundHandler.cs file.
2. Expand the hidden region named IInboundHandler Members.
3. Remove the lines of code that throw the NotImplementedException in the
StartListener, StopListener, TryReceive, and WaitForMessage methods.
4. Add a using statement for System.Threading and System.ServiceModel.Channels to the
top of the ContosoCustomAdapterInboundHandler.cs file.
5. Add a field named _messages of type Queue<Message> to the
ContosoCustomAdapterInboundHandler class.
Queue<Message> _messages = new Queue<Message>();
6. Inside of the StartListener method, add code that starts a Timer and adds a new
Message to _messages field every time the Timer hits.
int interval =
this.Connection.ConnectionFactory.Adapter.ListenerInterval;
Timer t = new Timer(delegate

{
Console.WriteLine("Timer hit");
lock (_messages)
{
Message msg =
Message.CreateMessage(MessageVersion.None,
"Test", "Test");
Console.WriteLine("Got a message");
_messages.Enqueue(msg);
Monitor.PulseAll(_messages);
}
}, null, 0, interval);
Console.WriteLine("Listening");
In a real implementation, this is where you would be connecting to your
LOB/database and looking for new messages to consume. This is your “listening”
functionality. A common implementation would be to use a timer, but depending on
your listening functionality your InboundHandler will be different depending on
what your Adapter is connecting to. In this case there isn’t any implementation,
however in a real implementation this is where you would stop the listening
functionality you started in StartListener. In this case, the anonymous delegate will
stop when the class is disposed.
7. Inside of the WaitForMessage method, add the code below. This is the first method that
will be called by the listening infrastructure. Return true here when there are messages
to process.
lock (_messages)
{
if (_messages.Count > 0)
{
return true;
}
return Monitor.Wait(this._messages,
timeout.TotalMilliseconds >= Int32.MaxValue ?
Int32.MaxValue :
(int)timeout.TotalMilliseconds);
}
The purpose of this code is to see if there any messages in the queue (locking the
queue first). It returns true if there are messages to receive. Then it waits the
appropriate Timeout value. It will return true if the Monitor gets the lock on the
_message field within the timeout. The call to Monitor.PulseAll in the timer delegate
will cause this to happen if a message is received (which in this implementation is a
certainty).
8. TryReceive is what will be called repeatedly by the WCF infrastructure over and over
once WaitForMessage returns true.
reply = new ContosoCustomAdapterInboundReply();
Console.WriteLine("TryReceive....");
lock (_messages)
{
if (!this.WaitForMessage(timeout))
{
message = null;
return false;
}
message = _messages.Dequeue();
}
return true;
The InboundReply object is built to be able to encapsulate the creation of the

outgoing WCF message. In this implementation we are using a one-way contract, so
that isn’t necessary. In a real implementation, you’d need to fill out the
InboundReply class’ methods.
9. Build the solution, and make sure it compiles successfully.

Exercise 5: Building an Inbound Listener
Overview
In this part, you will build an application to host your adapter while it listens for incoming
messages. The application is a simple console application which creates an instance of your
adapter and hosts it as a WCF service.
Create the Application

Procedure List
1. In Solution Explorer, right-click the ContosoCustomAdapter solution, then click Add, and
then click New Project.
3. Name the project InboundClient. The default location should be fine. Click OK.
4. Right-click on the InboundClient project, click Properties, then in the Target framework
list, click .NET Framework 4, and then click Yes.
Reference”.
6. Add a reference to the following assemblies (found under the .NET tab):
Assembly Name
System.ServiceModel
Reference”.
8. Add a reference to the ContosoCustomAdapter project (found under the Projects tab).
Click OK.
Namespace
System.ServiceModel
Create a Service Contract
Procedure List
1. Inside of Program.cs (but outside of the Program class) create an interface. Name it
IOneWay. Add the ServiceContract attribute to this interface.
2. Add a method to this interface and name it OneWayMethod. Have it take a single
parameter of type Message and return void. Add the OperationContract attribute to
the OneWayMethod, with Action as a wildcard value (“*”) and IsOneWay equal to true.
[ServiceContract]
public interface IOneWay
{
[OperationContract(Action="*",IsOneWay=true)]
void OneWayMethod(Message inmsg);
}
3. Inside of Program.cs (but outside of the Program class) create a class. Name it OneWay.
Have the OneWay class implement the IOneWay interface. Inside of the
OneWayMethod write the string value of the Message out to the console.
public class OneWay : IOneWay

{
public void OneWayMethod(Message inmsg)
{
Console.WriteLine("Received a message {0}",
inmsg.GetReaderAtBodyContents().ReadInnerXml());
}
}
4. Inside of the Main method in the Program class, create a ConstosoAdapterBinding and
set the Transactional property to true, and the ListenerInterval to 5000.
ContosoCustomAdapterBinding b = new
ContosoCustomAdapterBinding();
b.ListenerInterval = 5000;
5. Create a ServiceHost, pass the OneWay type as the parameter to the ServiceHost
constructor.
ServiceHost sh = new ServiceHost(typeof(OneWay));
6. Call ServiceHost.AddServiceEndpoint, specifying the IOneWay interface as the contract,

the ContosoCustomAdapterBinding as the binding, and
"contoso://alice@contososervername" as the address.
sh.AddServiceEndpoint(
typeof(IOneWay),
b,
"contoso:// alice@contososervername");
7. Call Open on the ServiceHost.
sh.Open();
Test the Solution

Procedure List
1. Write a message to the Console that the Service is up and running, and then add call to
Console.ReadLine to keep the process open.
Console.WriteLine("Service up and running - press enter to

exit");
Console.ReadLine();
2. Run once using Ctrl-F5 to verify the output to the console is correct. Then set
breakpoints in the methods you just implemented and run again – this time using F5, so
you can step through the interaction of the client to the adapter. Stop the command
windows when you are satisfied your service is receiving messages.
Lab 17 : Creating a BAM Interceptor Configuration
Overview
In this lab you will be configuring your applications to push KPIs into BAM using the BizTalk BAM
interceptors. In this lab the application is already created for you, you will only create and
configure the WF, WCF, and Orchestration’s interceptors to track data across a logical process
(spanning more than one physical processes). After completing this lab, you should understand
how to: author an interceptor configuration file; deploy an interceptor configuration file;
configure the BAM interceptor for WF; configure the BAM interceptor for WCF and use
continuations to instrument multiple processes with BAM.
Procedure List
window.

Procedure List
Exercise 1: Deploying the BAM Activity and View
Overview
In this part, you will deploy the BAM activity using the command line BAM Management
(bm.exe) tool.
Review the Environment and Deploy the Sample Application

Procedure List
1. Open the ContosoOrderingApplication.sln solution in the C:\AllFiles\LabFiles\Lab17
folder.
2. Right-click on Contoso.BizTalk.Orchestration project and select Deploy. This will deploy
the orchestration to an application named BAMIntegration.
3. in the BizTalk Administration Console , right-click the BAMIntegration application and
select Import-> Bindings. Browse to the C:\AllFiles\LabFiles\Lab17 directory and select
BindingFile.xml as the binding file to import. Click the Open button in the dialog.
4. Right-click the BAMIntegration application in the BizTalk Administration Console and
select Start. This will start the BizTalk orchestration and ports.
5. Open ContosoActivity.xml (under the Solution Files folder in the solution explorer),
which is the BAM Activity and View definition, and InterceptorConfig.xml, which is the
BAM interceptor configuration.
6. The BAM Activity (inside ContosoActivity.xml) is a very basic activity which just pushes
in 4 milestones:
Milestone Description
Start When the process starts; this will be when the WF
Workflow begins processing.
OrchProcessing When the BizTalk Orchestration starts processing.
Processing When the WCF Service begins processing.
Done When the BizTalk Orchestration receives the
response from the WCF Service and ends.
7. Open a command prompt and change the directory by typing:
8. From the command prompt, deploy the BAM Activity by typing the following command
(replacing the lab directory) and hitting enter:
bm.exe deploy-all -DefinitionFile: C:\AllFiles\LabFiles\Lab17\ContosoActivity.xml
You will have to type this command line in by hand. Copying the command from this
document will not work correctly
Exercise 2: Creating the Interceptor Configuration File
Overview
In this part, you will create a single interceptor configuration file for both WF and WCF
components. The WinForms application begins a workflow and sends data to an orchestration.
The orchestration then calls a WCF service.
If you encounter any problems, there is a copy of a the completed IC file in the
C:\AllFiles\LabFiles\Lab17\ContosoActivity.xml folder for reference.

Procedure List
1. In the InterceptorConfig.xml file (back in the solution files), create a BAM EventSource
for the WCF Service Contract:
<bam:EventSource Name="ContosoServices" Technology="WCF"

Manifest="ContosoOrderingService.IContosoOrderingService,
ContosoOrderingService, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=null" >
<bamwcf:NamespaceMappings>
<bamwcf:Namespace Prefix="test"
Uri="http://contoso.com/services/OrderingServiceData"/>
</bamwcf:NamespaceMappings>
</bam:EventSource>
2. Create an EventSource for the WF Workflow. The ContosoOrderingApplication will

spawn a Workflow when an Order is in process. (See the MainForm.cs – button1_Click
event handler.)
<bam:EventSource Name="ContosoWorkflow" Technology="WF"

Manifest="Contoso.Workflow.OrderFlow, Contoso.Workflow,
Version=1.0.0.0, Culture=neutral, PublicKeyToken=null">
</bam:EventSource>
Define a BAM Activity

Procedure List
1. Create a BamActivity element for all the data you’d like to push into the
ContosoOrderingSystem BAM Activity.
<bam:BamActivity Name="ContosoOrderingSystem">
</bam:BamActivity>
2. Inside of the BamActivity element for the interceptor configuration create an OnEvent
element for the WF source
<bam:OnEvent Name="WFStart" IsBegin="true" IsEnd="true"

Source="ContosoWorkflow" >
</bam:OnEvent>
3. Inside of the OnEvent element for the ConstosoWorkflow source which you just
created, create a filter for the Workflow Started event.
<bam:Filter>
<bam:Expression>
<bamwf:Operation Name="GetWorkflowEvent"/>
<bam:Argument>Started</bam:Argument>
</bam:Operation>
<bam:Operation Name="Equals"/>
</bam:Expression>
</bam:Filter>
4. After the filter you just added, still inside of the OnEvent element, create a
CorrelationId element that uses the Workflow.InstanceId as its context property (use
the GetContextProperty operation for InstanceId).
<bam:CorrelationID>
<bam:Expression>
</bamwf:Operation>
</bam:Expression>
5. Next you’ll add the Update element, which uses the GetContextProperty to cause a
timestamp to be written to the BAM Activity for the Start milestone.
<bam:Update Type="DATETIME" DataItemName="Start">
<bam:Expression>
<bamwf:Argument>EventTime</bamwf:Argument>
</bamwf:Operation>
</bam:Expression>
</bam:Update>
6. Next, create two Continuation Token elements – one for BizTalk to continue, one for
WCF to continue.
<bam:Expression>
<bam:Argument>CorrelationId_</bam:Argument>
</bam:Operation>
</bamwf:Operation>
</bam:Expression>
<bam:Expression>
</bam:Operation>
</bamwf:Operation>
</bam:Expression>
Define a WCF Event Collection

Procedure List
1. Inside of the BamActivity element for the interceptor configuration, create an OnEvent
element for the WCF source – AFTER the end tag of the OnEvent element for the WF
source.
<bam:OnEvent Name="WCFProcessing" IsBegin="true" IsEnd="true"

Source="ContosoServices">
</bam:OnEvent>
2. Inside of the OnEvent element for the ContosoServices source which you just created
(WCF source), create a filter for when messages are received by the Service for the
ProcessOrder operation.
<bam:Filter>
<bam:Expression>
<bamwcf:Operation Name="GetServiceContractCallPoint"/>
<bam:Argument>ServiceRequest</bam:Argument>
</bam:Operation>
<bamwcf:Operation Name="GetOperationName"/>
<bam:Argument>ProcessOrder</bam:Argument>
</bam:Operation>
<bam:Operation Name="And" />
</bam:Expression>
</bam:Filter>
3. Next specify the CorrelationId as a concatenation between the string WCF_ and XPath
operation on the message for the OrderId element's value. This will match what the WF
OnEvent has set up for the Correlation. After adding this code, Save the file.
<bam:CorrelationID>
<bam:Expression>
</bam:Operation>
<bamwcf:Operation Name="XPath">
<bamwcf:Argument>//test:OrderId</bamwcf:Argument>
</bamwcf:Operation>
</bam:Expression>
4. Next, create the Update for the WCF OnEvent - pulling the EventTime from the
GetContextProperty Operation.
<bam:Update DataItemName="Processing" Type="DATETIME">
<bam:Expression>
<bamwcf:Operation Name="GetContextProperty">
<bamwcf:Argument>EventTime</bamwcf:Argument>
</bamwcf:Operation>
</bam:Expression>
</bam:Update>
Exercise 3: Deploy the Interceptor File
Overview
In this part, you will deploy the interceptor file that you created in Exercise 3.

Procedure List
1. Deploy the interceptor file from the command line:
bm.exe deploy-interceptor –FileName:C:\AllFiles\LabFiles\Lab17\InterceptorConfig.xml
You will need to type this command in manually. Copying the command from this
document to a command line will not work because of formatting issues.
Exercise 4: Configure the Interceptor Runtimes
Overview
In this part, you will add the interceptors into their respective runtimes.

Procedure List
1. In the ContosoOrderApplication project, open the code view of the MainForm.cs file.
2. In the MainForm_Load method, add code to install the BamTrackingService as a
WorkflowRuntime service for this instance of the WorkflowRuntime. This configures
the interceptor for WF. This application is using WF as part of its internal logic.
BamTrackingService ts = new
BamTrackingService(
5000);
_wr.AddService(ts);
3. In the ContosoOrderingService project – in Program.cs – examine the

BamCodeExtension class (this code is necessary for this version of the interceptors as
there isn’t any built-in way to add this behavior with just code – only configuration).
4. In the ServiceHost initialization code in the Main method – add this behavior to the
ServiceEndpoint. This will configure the interceptor for WCF.
BamCodeExtension b = new
BamCodeExtension(
5000);
se.Behaviors.Add(b.Create());
Deploy the Orchestration Tracking Profile

Procedure List
1. In Windows Explorer, in the C:\AllFiles\LabFiles\Lab17 directory, double-click the
Contoso_TrackingProfile.btt file. This is the BAM interceptor configuration for the
BizTalk Orchestration.
2. Deploy this configuration by clicking on Tools–> Apply Tracking Profile. You will see a
warning about no corresponding Continuation elsewhere. Just press Yes and proceed.
You will get a confirmation that the profile was successfully applied.
Exercise 5: Test the Configuration
Overview
In this part, you will send messages through the interceptors and view the data that was
collected in BAM.

Procedure List
1. Select Debug –> Start Without Debugging from the Visual Studio Solution you have
open.
2. Send in a few orders by clicking on the Send Order button in the
ContosoOrderingApplication windows forms application and then clicking on the
Commit button to commit the transaction.
3. Open the BAM portal by selecting Start –All Programs – Microsoft BizTalk Server 2010 –
BAM Portal Web Site)
4. Click on the Aggregations link under the ContosoView menu item on the left side of the
page.
5. Click Yes on any security dialog boxes that appear.
6. Verify that you can see data in the Pivot Table
7. You may go back to the Windows Application and send in additional orders and then
refresh the Pivot Table.
At this point the BAM data is being populated partially from the Workflow, BizTalk,
and WCF and being correlated using the BAM infrastructure.
Lab 18 : Receiving EDI Messages
Overview
In this lab you will be configuring a BizTalk Application to be able to successfully process
incoming EDI documents. By deploying an EDI Schema and configuring a party, you’ll be able to
use the EDI components to translate EDI messages to XML. After completing this lab, you
should understand how to: deploy EDI Schemas, create Parties, configure Party specific EDI
properties and configure BizTalk Server to process EDI message.
Procedure List
window.

Procedure List
Overview
In this part, you will deploy an EDI Schema to BizTalk, and then you will configure a receive port
and a send port to handle an EDI message.
Deploy the Schema

Procedure List
1. Open the following solution:
C:\AllFiles\LabFiles\Lab18\Contoso.EDI.Artifacts\ Contoso.EDI.Artifacts.sln
2. Right-click on the Contoso.EDI.Artifacts project, point to Add, then click Existing Item,
and then browse to the C:\AllFiles\LabFiles\Lab18 directory. Click X12_00401_850.xsd,
and then click OK.
computer).
3. Right-click on the Contoso.EDI.Artifacts project and click “Deploy”.
Configure the application.

Procedure List
1. Open the BizTalk Administration Console (On the Start menu, click All Programs, then
click BizTalk Server 2010, and then click BizTalk Server Administration).
2. Expand BizTalk Server 2010 Administration, BizTalk Group, and Applications.
3. Right-click on the ContosoEDI application and click Properties.
4. Click the References node in the left side of Application Properties dialog, and then in
the right pane, click the Add button.
Since all of the BizTalk EDI artifacts are deployed to this application, in order to use
Create a Receive Location and Port.
Procedure List
1. In the ContosoEDI application, right-click the Receive Ports node and point to New,
then click One-Way Receive Port.
2. In the Name box, enter PartnerReceivePort.
3. In the left pane, click Receive Locations, then in the right pane, click New.
4. Name the loEcation EDIFileLocation and in the Type list, click FILE.
5. Click Configure, and set the Receive Folder to C:\AllFiles\LabFiles\Ports\EDIReceive
and change the File Mask to *.txt.
6. Click OK once to return to the Receive Location Properties dialog box, and in the Receive
Pipeline list, click EdiReceive, and then click OK twice.
If you don’t see EDIReceive make sure that you’ve created the reference to the
BizTalk EDI Application from this application.
Create a Send Port.

Procedure List
1. In BizTalk Server Administration, right-click on the Send Ports node under the
ContosoEDI application, point to New, and then click Static One-way Send Port.
2. After setting the properties using the table below, click OK to close the dialog.
Name Value
Name EDISend
Transport FILE
Destination Folder C:\AllFiles\LabFiles\Ports\EDISend
(Under Transport – click
Send Pipeline PassThroughTransmit
Filters BTS.ReceivePortName== PartnerReceivePort
(Note – this subscription for the Send Port is just
for testing purposes. Note the list of EDI-specific
properties that are available as Filter properties
which might be used in a messaging-only EDI
application with BizTalk)
3. In the BizTalk Administration tree view, right-click the ContosoEDI application, and then
click Start twice.
Exercise 2: Creating the Parties
Overview
In this part, you will create a party to represent the sender of a message that will be received
into BizTalk Server.
Create the Party

Procedure List
1. In the BizTalk Administration tree view, find the Parties node.
2. Right-click Parties, point to New, and then click Party.
3. In the Name box, enter BIGWINESELLER, then click OK
4. Click the Parties node, then expand the BIGWINESELLER party in the center pane and
right-click the BIGWINESELLER_Profile item and click Properties.
5. In the left pane, click Identities.
6. Fill out the X12 related identity properties with the following values:
Name Value
Mutually Defined (X12) SENDERISA
Duns Plus Suffix 0073268795005
7. In the Profile Properties dialog box, in the menu bar click Add protocol settings, point to
Encoding settings, and then click X12.
8. In the X12_Settings_1 panel, navigate to Inbound Settings, then Interchange Settings,
and then Validation.
9. Ensure that the check box next to Interchange control number is cleared.
These settings allow you to control how the EDI messages are processed including
validation, namespaces to use, etc.
10. Click OK to close the Profile Properties dialog box.
11. Find the Contoso850.txt file in the C:\AllFiles\LabFiles\Lab18 directory for this lab.
Open and examine the EDI message (pay special attention to the ISA line).
Notice that the ISA number is the same as that defined in the party properties, thus
providing BizTalk the information it needs to resolve the party
12. Place a copy of that file in C:\AllFiles\LabFiles\Ports\EDIReceive
13. In the C:\AllFiles\LabFiles\Ports\EDISend directory you should find an XML file. Open it
and examine it – it should be the XML representation of the 850.
Whenever you plan on using the EDI capabilities in BizTalk Server for receiving EDI
messages you’ll need to follow the steps of this activity at a minimum.
Lab 19 : Sending EDI Messages
Overview
In this lab you work for Contoso Winery. Your ERP system outputs invoice messages using a
custom XML Schema. You need to turn these custom XML messages into EDI messages to send
to a trading partner. The trading partner is located in Ireland, so the EDI messages must be
EDIFACT. Also the trading partner requests that the invoices be sent in batches of three (3). In
this lab, you will be deploying the artifacts necessary to turn the XML messages into EDI, and
you will configure EDI batching for the trading partner. After completing this lab, you should
understand how to: configure BizTalk Server EDI to send EDI messages, and configure BizTalk
Server EDI to batch outgoing EDI message.
Procedure List
window.

Procedure List
Overview
In this part, you will deploy the EDI schema needed in your solution, and configure the BizTalk
application which will contain your solution artifacts and configuration.
Deploy the EDI Schema

Procedure List
1. Open the following solution.
C:\AllFiles\LabFiles\Lab19\Contoso.EDI.EDIFACT\ Contoso.EDI. EDIFACT.sln

2. In the solution, examine both projects and examine the files.
computer).
File Purpose
EFACT_D96A_INVOIC.xsd The BizTalk Server Schema for EDIFACT
D96A INVOIC. Necessary for converting EDI
messages to XML or XML messages of this
type to EDI.
InternalEDIReceive.btp A custom Pipeline which will allow
processing of incoming XML messages but
also have the EDI component necessary to
support batching.
InternalInvoiceToD96A_INVOIC.btm The map (XSLT) which will transform the
custom invoice schema into the INVOIC XML
message.
InternalInvoice.xsd The internal XML schema for Invoices from
the ERP system.
PropertySchema.xsd A BizTalk property schema definition for the
name of the party sent from the ERP
system. The value is promoted from
InternalInvoice.xsd.
3. Open the InternalEDIReceive.btp pipeline file in the Contoso.EDI.EDIFACT project.

4. From the Toolbox, drag and drop the XML Disassembler onto the Disassemble stage of
the pipeline.
5. From the Toolbox, drag and drop the Batch Marker Component onto the Resolve Party
6. Click the Batch Marker Component and in the Properties window, set the Ignore EDI
Message Encoding Type property to True.
7. Right-click on the Contoso.Schemas.Internal project and click Deploy.
8. Right-click on the Contoso.EDI.EDIFACT project and click Deploy.
9. Open the BizTalk Administration Console (on the Start menu, click All Programs, then
click BizTalk Server 2010, and then click BizTalk Server Administration).
10. Expand BizTalk Server Administration, BizTalk Group, and Applications.
11. Right-click on the EDISending application and click Properties.
13. In the right pane click the Add button.
Since all the BizTalk EDI artifacts are deployed to this application, in order to use
Create the Receive Port

Procedure List
1. In the EDISending application, right-click the Receive Ports node, point to New, then
click One-Way Receive Port.
2. Name the port ERPReceive, and in the left pane click Inbound Maps.
3. In the Inbound Maps dialog, click on the grid under the Source Document property to
see the list of available maps. Pick InternalInvoice as the source document and the
other values will be filled in automatically
4. Click on the Receive Locations tab, then in the right pane, click the New button and
create the new location using the properties in the table below.
Property Value
Name EDIFileLocation
Transport FILE
Receive Folder C:\AllFiles\LabFiles\Ports\EDIReceive\
(Under Transport – click the
Configure Button)
File Mask (Under Transport – click *.xml
Receive Pipeline (Under General) InternalEDIReceive
5. Click OK to close the Receive Port Properties dialog box.
6. Under the EDISending application, right-click the Send Port node, point to New, then
click Static One-way Send Port. After setting the properties as shown below, click OK to
close the dialog.
Property Value
Name EDISend
Transport FILE
Destination Folder (Under C:\AllFiles\LabFiles\Ports\EDIFACTSend
Transport – click the Configure
Button)
File Name (Under Transport – click %MessageID%.txt
Send Pipeline EdiSend
Filter (under Filters tab) EDI.ReceiverPartyName == Contoso Buyer
And
EDI.ToBeBatched == False
7. Right-click the EDISending application, and then click Start.

8. If prompted, also elect to start the BizTalk EDI Application.
This starts the EDI Batching Orchestrations and the Command Receive location
which provides the batching of messages.
Exercise 2: Create an Agreement
Overview
In this part, you will create an EDI Agreement between two parties, and then configure EDI
batching.
Create the Party to Represent Your Company

Procedure List
1. In the BizTalk Administration tree view, right-click the Parties node, point to New, then
click Party and name the party Contoso Winery.
3. In the BizTalk Administration tree view, click the Parties node.
4. In the center pane, expand Contoso Winery, then right-click the Contoso
Winery_Profile and click Properties.
6. In the right pane, in the Name list, click Mutually Defined, and in the Value box, enter
ContosoWinery.
7. Click OK.
Create the Party for the Trading Partner

Procedure List
1. In the BizTalk Administration tree view, right-click on the Parties node, point to New,
then click Party and name the party Contoso Buyer.
3. Right-click the Contoso Buyer_Profile in the Parties and Business pane and click
Properties.
5. In the right pane, in the Name list, click Mutually Defined, and in the Value box, enter
ContosoBuyer.
6. Click OK.
Create an Agreement between the Two Parties

Procedure List
1. Right-click the Contoso Buyer_Profile, point to New, then click Agreement.
2. Change the protocol to EDIFACT and click Contoso Winery for the Second Party.
4. Notice the agreement appears under the selected profile for each party involved in the
agreement.
5. Double-click the agreement (from either party/profile) to edit the batch configuration.
Configure the Batch Information

Procedure List
1. Click the Contoso Winery -> Contoso Buyer tab.
2. Click on Batch Configuration in the left hand pane.
3. Click the New Batch button.
4. Click on the Filter button (opens another dialog box).
5. Under the Property column, find Contoso.Schemas.Internal.PropertySchema.__Name.
6. Leave the Operator as ==
7. Set the Value column to Contoso Buyer.
8. The expression at the bottom of the dialog should read :
Contoso.Schemas.Internal.PropertySchema.__Name == Contoso Buyer
9. Press OK to close the Filter dialog.

11. Click the radio button next to Maximum number of transaction sets in
12. On the combo box under this setting, set the value to Group:
13. In the text box next to Group: put the value 3.
14. Under the Activation section, check the Start Immediately check box.
15. Press the Apply button (do NOT press OK as that will close the dialog).
16. Press the Start button at the top of the batch page to start the batch processing
This sends a control message that the EDI application picks up to create a new,
unique instance of the batching orchestration for this agreement. If you wait a
minute, then click the refresh button, you will actually see the unique identifier for
the orchestration instance appear in the dialog.
17. Press OK to close the EDI Properties dialog.
Exercise 3: Test the Application
Overview
In this part, you will send an EDI message via the application that you configured in Exercises 1
and 2.
Test the Solution

Procedure List
1. Open the InternalInvoice.xml file from the C:\AllFiles\LabFiles\Lab19 folder and
review.
2. Copy InternalInvoice.xml and put it into C:\AllFiles\LabFiles\Ports\EDIReceive.
3. Do this two more times after the file is picked up by BizTalk.
4. Examine the C:\AllFiles\LabFiles\Ports\EdifactSend folder.
5. If your batching succeeded you should see a .txt file in this directory. Open and examine
the EDI document to see the batch information.
Whenever you plan on using the EDI capabilities in BizTalk for sending EDI messages
you’ll need to follow the steps of this activity at a minimum.

Cronica Del Pajaro Que Da Cuerd - Haruki Murakami

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Cronica Del Pajaro Que Da Cuerd - Haruki Murakami

Enviado por

Direitos autorais:

Formatos disponíveis

Microsoft MCTS BizTalk

Provide an overview of the course

Start End Module

9:00 9:30 Introduction

9:30 11:00 Module 1: Introduction to BizTalk Server 2010

11:00 11:15 Break

11:15 11:45 Lab: Examining a BizTalk Application

11:45 12:45 Module 2: Creating Schemas

12:45 1:45 Lunch

2:15 3:15 Module 3: Creating Maps

3:15 3:30 Break

3:30 4:00 Lab: Creating a BizTalk Map

Module 4: Deploying and Managing BizTalk

Start End Module

9:30 10:00 Lab: Deploying and Managing BizTalk Applications

10:00 10:45 Module 5: Routing BizTalk Messages

10:45 11:00 Break

11:00 11:45 Module 5: Routing BizTalk Messages (Continued)

11:45 12:45 Lunch

1:30 2:30 Module 6: Creating Pipelines

2:30 2:45 Break

2:45 3:45 Lab: Creating Pipelines

3:45 5:00 Module 7: Integrating with Adapters

Start End Module

9:00 9:30 Day 2 review

9:30 10:15 Lab: Integrating with Adapters

10:15 10:30 Break

10:30 11:30 Module 8: Creating a BizTalk Orchestration

11:30 12:15 Lab: Creating a BizTalk Orchestration

12:15 1:15 Lunch

1:15 2:15 Module 9: Automating Business Processes

2:15 3:15 Lab: Automating Business Processes

3:15 3:30 Break

3:30 4:15 Module 10: Creating Transactional Business Processes

4:15 5:00 Lab: Creating Transactional Business Processes

Start End Module

9:00 9:30 Day 3 review

9:30 10:30 Module 11: Business Rules

10:30 10:45 Break

10:45 11:45 Lab: Rules

11:45 12:30 Module 12: BAM

12:30 1:30 Lunch

1:30 2:15 Lab: BAM

2:15 3:15 Module 13: Using WCF Receive Adapters

3:15 3:30 Break

3:30 4:00 Lab: Using WCF Receive Adapters

4:00 5:00 Module 14: Using WCF Send Adapters

9:00 9:30 Day 4 review

9:30 10:00 Lab: Using WCF Send Adapters

10:00 10:15 Break

10:15 11:15 Module 15: Implementing Messaging Patterns

11:15 12:00 Lab: Implementing Messaging Patterns

Additional topics (optional):

Briefly describe each module.

Course outline (continued)

Briefly describe each optional module.

Course outline - Optional Topics.

Explain the classroom setup

Virtual machine Role

Course hardware level

Demonstrate how to use Microsoft Hyper-V

Describe the services and tools provided in BizTalk Server 2010.

BizTalk Tools and Services