MCTS Biztalk Server 2010 Administrator Courseware

Transcription

Microsoft MCTS BizTalk
Server 2010
Biztalk Administrator 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
10:45
Module 1: Introduction to BizTalk Server 2010
10:45
11:00
Break
11:00
11:30
Lab 1: Examining a BizTalk Application
11:30
12:00
Module 2: Installing a BizTalk Server Hosting
Environment
12:00
12:15
Lab 2a: Install and Configure Windows SharePoint
Foundation
12:15
1:15
Lunch
1:15
1:45
Module 2: Installing a BizTalk Server Hosting
Environment
1:45
2:15
Lab 2b: Install and Configure BizTalk Server
2:15
2:30
Break
2:30
3:15
Module 3: Deploying BizTalk Applications
3:15
3:45
Lab 3a: Deploying an Application by Using an MSI
Package
3:45
4:15
4:15
5:00
Lab 3b: Composing and Deploying Business Rules
Start
End
Module
9:00
9:30
Day 1 review
9:30
10:00
Module 4: Managing BizTalk Applications
10:00
10:15
Break
10:15
11:00
Lab 4a: Administering a BizTalk Application
11:00
11:45
11:45
12:15
Lab 4b: Monitoring Message Activity and Debugging
Orchestrations
12:15
1:15
Lunch
1:15
1:45
1:45
2:00
Lab 4c: Scripting Administrative Tasks
2:00
2:30
2:30
2:45
Break
2:45
3:45
Lab 4d: Monitoring Business Activity
3:45
4:00
Module 5: Administering a BizTalk Server Environment
4:00
4:15
Lab 5a: Managing a BizTalk Server Group
4:15
4:30
Module 5: Administering a BizTalk Server Environment
Day 2
4:30
5:00
Lab 5b: Backing Up and Restoring BizTalk Server Data
Optional Topic
Start
End
Module
Module 6: Monitoring a BizTalk Environment with System
Center Operations Manager
Introduction
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 administrators who are responsible for managing a Microsoft
BizTalk Server 2010 group.
Individuals who attend this course are expected to have the following prerequisite
knowledge or experience:

At least one year of experience managing a Microsoft Windows Server environment

Familiarity with systems Microsoft SQL Server

Familiarity with a scripting language

Prior experience with of BizTalk Server is not required.
Course Outline
Course outline
This course contains a total of five modules. 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, “Installing a BizTalk Server Hosting Environment,” shows how to install and
configure BizTalk Server 2010.
Module 3, “Deploying BizTalk Applications,” shows how to deploy BizTalk Server
applications.
Module 4, “Managing BizTalk Applications,” shows how to manage BizTalk Server
applications.
Module 5, “Administering a BizTalk Server Environment,” shows how to script administrative
actions and back-up BizTalk Server databases.
Optional Content
Module 6, “Monitoring a BizTalk Environment with System Center Operations Manager”
show how to monitor a BizTalk environment using the Microsoft BizTalk Server 2010
Management Pack (MP) for System Center Operations Manager.
Setup
Explain the classroom setup
Hyper-V configuration
In this course, you will use Microsoft Hyper-V R2 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
bt10a-01
Supports the lab for module 1
bt10a-02
bt10a-03
bt10a-04
bt10a-05
bt10a-06
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 a virtual machine
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: 75 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, with BizTalk Server 2010, expands the offering 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 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 2010 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.
Information workers may use the BizTalk Server 2010 Administration Console to maintain
trading partner information. The Business Activity Monitor (BAM) portal site can be used to
monitor business processes and to view aggregated data.
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 highavailability/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 2010 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
Tools for Developers
Identify the purpose of the most common BizTalk developer tools.
Overview
The BizTalk developer tools are hosted in the Visual Studio environment and are used for
both messaging and orchestrations.
BizTalk Developer Tools
The following tools are used by developers to create the necessary BizTalk artifacts for
BizTalk message integration and business process integration:




BizTalk Editor. Helps you define schemas, which are used to describe the format of
data that is processed within organizations and between trading partners.
BizTalk Mapper. Presents source schemas and destination schemas side by side,
making it possible to define transformations between data fields in messages.
Pipeline Designer. Used to process incoming and outgoing messages by
implementing such operations as encryption and decryption, compression,
reformatting, and validation.
Orchestration Designer. Enables you to create orchestrations that are used to model
business processes.
Tools for Information Workers
Identify common BizTalk tools for information workers.
Overview
Information workers now have access to two tools for interacting with BizTalk Server.
Business Activity Monitoring (BAM) allows information workers to monitor running business
processes, and Trading Partner Management (TPM) gives information workers the tools
necessary to manage external trading partners.
Business Activity Monitoring
BAM provides information workers visibility into running business processes. BAM can be
used to view business data in as close to real time as possible, and business analysts can use
the BAM Activity Wizard to specify what data to collect and how to interpret it. This data can
then be saved and viewed in an Excel workbook. The BAM Portal is another new tool that
allows business analysts and information workers the ability to view business data. BAM is
covered in more depth in later modules.
Trading Partner Management
Because BizTalk Server 2010 is often used to connect trading partners, TPM is provided to
handle managing trading partner relationships. Trading partners must often agree on the
protocol they will use to communicate or the formats of messages that are exchanged, and
TMP provides information workers with an easy-to-use interface for managing these
relationships.
Tools for IT Professionals
Identify common BizTalk tools for IT Professionals.
Overview
BizTalk Server 2010 comes with several new features that IT professionals can use for
administering and monitoring their BizTalk Server installations. The improved BizTalk Server
2010 Administration Console and the equivalent command-line tool, BTSTask.exe, are the
main tools that IT professionals will use when administering a BizTalk Server computer.
BizTalk Server Administration Console. This Microsoft Management Console (MMC) snap-in
is used for creating, configuring, and managing applications as well as for creating and
configuring send ports, receive ports, and orchestrations. The Administration Console also
contains the Group Hub, which provides a complete view into the health of a running BizTalk
Server. The Group Hub is used by IT professionals to view live data.
BTSTask. This command can be used to perform the same tasks as the BizTalk Server
Administration Console.
System Center Operations Management Pack. The BizTalk Server 2010 Management Pack
offers monitoring capabilities for BizTalk artifacts and BizTalk-related platform components.
It allows administrators to monitor health state of various BizTalk artifacts such as Send
Ports, Orchestrations etc. and platform artifacts such as Host Instances (BizTalk service).
Further, this Management Pack includes performance views, diagnostic capability and alerts.
Scenario
Adventure Works is a company that sells sporting goods. Adventure Works has implemented
BizTalk Server 2010 to automate its purchase order approval system. In this lab, you will test
the process by submitting purchase orders from two companies to the BizTalk Server
application that uses schemas, pipelines, maps, and orchestrations. The application
calculates and applies a discount based on rules that have been defined by using the
Business Rule Composer.
The business rules are as follows:



Contoso, Ltd. is a preferred business partner. Orders greater than $10,000 receive a
10 percent discount, all other orders receive a 5 percent discount. The AckCode field
in each purchase order is updated to reflect the discount percentage.
Fabrikam, Inc. is not a preferred business partner. However, orders greater than
$10,000 receive a 5 percent discount. The AckCode field is updated with the
following text: 5% discount applied.
All orders that do not meet the minimum ($10,000) require manual approval. By
default, the AckCode field for these orders is set to Does not meet minimum.
A message is sent to a SharePoint document library when a purchase order requires manual
approval. A manager must manually override the AckCode field with a value of Accepted or
Denied before resubmitting the updated purchase order to BizTalk Server for further
processing. After the purchase order has been reviewed by the manager, it is included in a
view of the SharePoint document library that displays only evaluated orders. BizTalk Server
monitors the document library’s Evaluated view for messages to process.
If the purchase order is Accepted, BizTalk calculates and updates the total for the purchase
order and routes it to the PurchaseOrderAck folder. If the purchase order is Denied, the
purchase order is routed to the Denied folder.
An FTP site is used to post shipping notices for approved purchase orders.
Start the Virtual Machine
Procedure List
1. If the Server Manager window is not already open, click on the Server Manager icon
located in the task bar next to the Start button.
2. Expand Roles, Hyper-V, Hyper-V Manager. The last node to appear displays the
machine name. Click on it to see the list of virtual machines available.
3. Double-click the virtual machine bt10a-01 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.
Ensure that the BizTalk Services are started
Procedure List
1. In Windows Explorer, navigate to C:\AllFiles.
2. Double click on startBtServices.cmd.
3. When prompted, press any key to close the command-line window.
Extend the Office Trial Version
Procedure List
1. To extend the expiration date of the Microsoft Office 2010 installation on this virtual
machine, navigate to C:\AllFiles\, and then double click extend.cmd.
Exercise 1: Test a BizTalk Server Application
Overview
In this exercise, you will submit five purchase orders—three from Contoso, Ltd., and two
from Fabrikam, Inc.—to BizTalk Server 2010 for processing. Depending on the company
name and total order amount, the Business Rule Engine will apply a discount to each
purchase order. One purchase order will not meet any requirements of the business rule
policy and must be manually approved. Shipping information will also be generated for each
approved purchase order and posted to an FTP site. This exercise shows you how BizTalk
Server 2010 is used to automate business processes.
Test the Application
Procedure List
1. In Windows Explorer, navigate to C:\AllFiles\LabFiles\Module 1\Messages.
2. Copy the three ContosoPO… and the three FabrikamPO… XML messages to the
PurchaseOrderIN folder.
These are the purchase orders that will be processed by BizTalk Server.
3. After the messages disappear from the PurchaseOrderIN folder, navigate to the
PurchaseOrderAck folder.
4. In the PurchaseOrderAck folder, open each of the four Completed{GUID}.xml
messages, and verify that the AckCode field displays X% discount applied or
Accepted.
5. In Internet Explorer, type ftp://BizTalkDemo/ShippedOrders in the Address bar,
and then press ENTER.
6. When prompted to log in to the FTP site, in the User name box, enter Administrator
and in the Password box, enter pass@word1.
7. Open the ShippedOrders folder, and notice the four ShipNotice{GUID}.xml
messages.
8. In Internet Explorer, navigate to http://BizTalkDemo/PurchaseOrderAck.
9. 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 Customer Name; it is either Contoso or Fabrikam.
10. In the Ack Code list, choose Accept, and then close the form, saving your changes.
11. 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 accepted or rejected.
Notice that the message you modified will be picked up for processing. This may
take up to one minute to occur, so you may have to refresh your browser.
12. In Windows Explorer, navigate to C:\AllFiles\LabFiles\Module
1\Messages\PurchaseOrderAck, and notice that another message has been
processed.
13. In Internet Explorer, navigate to ftp://BizTalkDemo/ShippedOrders. Notice that
another ShipNotice{GUID}.xml message is in the folder.
14. 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 Reject button.
Take note of the Applicant Name; it is either Contoso or Fabrik.
15. In the Ack Code list, choose Reject, and then close the form, saving your changes.
16. Refresh the page, and notice that the message will be picked up for processing.
This may take up to one minute to occur.
1\Messages\PurchaseOrderAck, and notice that the message does not appear
there.
18. In Windows Explorer, navigate to C:\AllFiles\LabFiles\Module 1\Messages\Denied,
open the Denied{GUID}.xml message, and notice that the order was not approved.
The structure of this message is different from the acknowledgment messages
generated for completed orders. The design of this application is to send the
original PO as the denied message.
19. Close all open windows, and shut down the virtual machine.
[Type text]
Module 2: Installing a BizTalk Server
Hosting Environment
Module objective:
In this module, you will learn how to:
Install and configure Microsoft BizTalk Server 2010 and all prerequisite services.
Overview
After a Microsoft BizTalk application has been developed and tested, it is typically handed
off to the IT professional who is responsible for deploying and managing the application in
the production environment for the BizTalk applications. This module provides an overview
of planning and installation considerations for implementing a BizTalk production
environment.
[Type text]
Lesson 1: Planning a BizTalk Server Installation
Lesson objective:
After completing this lesson, you will be able to:
Plan a BizTalk Server 2010 installation for a production environment.
Lesson Overview
Because of the many product dependencies required to perform a complete installation of
BizTalk Server, careful planning is essential to a smooth and effective installation. The topics
in this lesson provide the concepts and information you will need when you design and
implement the optimal BizTalk configuration for your environment.
[Type text]
System and Software Requirements
Identify hardware and operating system requirements and required prerequisite services.
Operating System Requirements
BizTalk Server 2010 requires either Microsoft Windows 2008 Server R2 or Microsoft
Windows 2008 Server with Service Pack 2 (SP2). For development environments, you can
also use Microsoft Windows 7 or Microsoft Windows Vista with Service Pack 2, although it is
recommended that you use the same operating system as in your test and production
environment.
Hardware Requirements
The minimum hardware requirements for any computer on which you intend to install
BizTalk Server 2010 are as follows:

A 1-gigahertz (GHz) Pentium–compatible CPU or higher for single processors.
Multiple processors are supported and recommended.

2 gigabytes (GB) of random access memory (RAM).

10 gigabytes (GB) of available hard disk space.
[Type text]
Hardware Recommendation (Test and Production)
The hardware requirements, including the number of computers running BizTalk Server
required, will be highly dependent on the specific BizTalk solution. For example, a pure
messaging solution will have significantly different requirements than a solution that is
heavily dependent on processing a single large message per day or one that will be
processing hundreds of small messages through a long-running transactional orchestration.
For this reason, it is not possible to provide standardized hardware recommendations.
Frequently, after performance testing has been performed, it will be necessary to adjust
hardware requirements.
The hardware design needs to take into account fault tolerance, high availability
requirements, and the BizTalk solution, as well as the SQL Server environment. It is common
to have multiple computers running BizTalk Server and multiple (clustered) computers
running Microsoft SQL Server in a production environment.
Required Software
In addition to the operating system requirements described here, BizTalk Server 2010
requires access to a computer running SQL Server to host the databases required by BizTalk.
BizTalk Server 2010 supports SQL Server 2008 R2 or SQL Server 2008 with Service Pack 1
(SP1). SQL Server does not need to be installed on the computer running BizTalk Server, but
it must be accessible on the network.
Optional Software
If the BizTalk Server environment will support optional functionality, such as publishing
orchestrations as Web services or using Business Activity Monitoring (BAM), the following
additional optional software services are required:

Internet Information Services (IIS). BizTalk Server 2010 requires IIS 7.5 or 7.0 to host
a Hypertext Transfer Protocol (HTTP) receive location, which allows submission of
messages to BizTalk through an HTTP post. Also, orchestrations and schemas that
are published as Web services require IIS.

SQL Server 2008 R2/SP1 Analysis Services. Both message tracking operations and
Business Activity Monitoring (BAM) can utilize Analysis Services databases. These
optional databases can be created during the initial configuration or at a later time.

SQL Server 2008 R2/SP1 Integration Services. BizTalk Server 2010 uses SQL Server
Integration Services to update SQL Analysis Services databases.

SQL Server 2005 Notification Services. BAM allows users to define alert conditions
based on the tracking data that is collected. BAM requires SQL Server Notification
Services to handle the alert processing.
Installation Guides
The following documents include a feature dependency matrix that specifies which optional
software is required for each BizTalk feature:


“Installing BizTalk Server 2010 on Windows Server 2008 R2 and 2008”
“Installing BizTalk Server 2010 and BAM in a Multi-Computer Environment”
[Type text]
Planning the SQL Server Environment
Identify SQL Server requirements for high availability.
Overview
Due to the mission-critical nature of many BizTalk applications and also to BizTalk’s reliance
on SQL Server, it is critical to design a stable and high-performance SQL Server environment
to support BizTalk. In most production environments, you will likely install SQL Server on a
separate computer from the computer running BizTalk Server 2010, and depending on
performance requirements and load, you might also need to separate the BizTalk databases
onto multiple computers running SQL Server. As always in a highly available environment, it
is recommended that you set up clustering for each BizTalk database.
SQL Server Design Considerations
A BizTalk system will only be as fast and efficient as the SQL Server infrastructure on which it
is built. A flawed SQL Server design will result in lowered performance for a BizTalk Server
environment. For example, good SQL Server design dictates that you should use fast
hardware (disk drives and disk controllers) and that the databases and log files should be
located on separate physical disks. SQL Server design also specifies the types of RAID
(Redundant Array of Inexpensive Disks) arrays that should be used for best performance.
Recommended Configurations for High Availability
To provide for high availability in production environments, SQL Server supports
passive/active clustering and other options to improve reliability, such as backups and log
shipping. Without these options in place, even with multiple computers running BizTalk
[Type text]
Server, the computer running SQL Server will provide a single point of failure. Here are some
recommended cluster and database configurations for businesses of varying size:

For small BizTalk Server 2010 deployments that contain fewer than five computers
running BizTalk Server, it is preferable to have the SQL Server databases on a
separate computer from the computers running BizTalk Server. Having multiple
computers running BizTalk Server in a group provides for a level of fault tolerance,
scalability, and recoverability.

For medium-size deployments that contain 5 to 10 computers running BizTalk
Server, you should cluster the computers running SQL Server that contain the BizTalk
Server databases. Even in smaller environments, if high availability of the data is a
concern, SQL Server clustering is recommended.

For large-scale deployments that contain 10 or more computers, with dedicated
computers running BizTalk Server for the receiving, processing, and sending
functions, performance might be improved by adding additional MessageBox
databases, either in a single SQL Server cluster or, for performance, spread across
several SQL Server clusters.
There are no hard-and-fast rules for deciding how many computers running BizTalk and SQL
Server will be required for a specific BizTalk solution. The design of the solution,
recoverability requirements, and many other factors will define the final hardware and
software requirements for a given BizTalk system.
Note: For more information about designing the optimum performance for your computers
running SQL Server and BizTalk, refer to the topic “Sample BizTalk Server High-Availability
Scenarios” in the BizTalk Server 2010 documentation.
[Type text]
Configuring Microsoft Internet Information Services
Configure Microsoft Internet Information Services (IIS) for a BizTalk Server environment.
Overview
To enable Web services, you must have at least one Isolated Host in BizTalk Server. Isolated
Hosts represent external processes, such as Internet Information Server worker processes
that BizTalk Server does not create or control. These types of external processes must host
certain adapters, such as HTTP/S and SOAP. The Microsoft BizTalk Server 2010 Configuration
Wizard creates the BizTalkServerIsolatedHost that BizTalk uses as the default Isolated Host.
Internet Information Services (IIS)
IIS is required for BizTalk applications that require message integration by using HTTP, and it
enables BizTalk applications to publish Web services. IIS is also required to use the BAM
Portal. By default, IIS is not enabled when you install Windows Server 2008, so you must add
the Web Server (IIS) role manually and include ASP.NET as a role service.
Application Pools in IIS 7.5 and 7.0
IIS 7 in Windows Server 2008 supports the ability to create multiple application pools that
run simultaneously for different virtual directories. A different user context can be
associated with each application pool to provide security. Each application pool can be
assigned to a different user context. Each Isolated Host that will be used with BizTalk Server
must use a separate application pool. The permissions and accessibility required for these
application pools vary depending on whether the BizTalk configuration database is located
on the same server as BizTalk or on a remote server.
[Type text]
When publishing Web services in BizTalk Server 2010, you will need to identify which
application pool each Web service should be associated with. This is beneficial when
publishing orchestrations as Web services because you can assign a separate security
context to each Web service. You must also configure the application pool to use version 4
of the .NET framework.
Choosing the Application Isolation Mode
Application pools separate applications by process boundaries to prevent an application
from affecting another application on the server. In IIS 7, application pools continue to use
IIS 6.0 worker process isolation mode. In addition, you can now specify a setting that
determines how to process requests that involve managed resources: Integrated mode or
Classic mode.
When an IIS 7 application pool is in Integrated mode, you can take advantage of the
integrated request-processing architecture of IIS and ASP.NET. When a worker process in an
application pool receives a request, the request passes through an ordered list of events.
Each event calls the necessary native and managed modules to process portions of the
request and to generate the response.
There are several benefits to running application pools in Integrated mode. First the requestprocessing models of IIS and ASP.NET are integrated into a unified process model. This
model eliminates steps that were previously duplicated in IIS and ASP.NET, such as
authentication. Additionally, Integrated mode enables the availability of managed features
to all content types.
When an application pool is in Classic mode, IIS 7 handles requests in the same way as in IIS
6.0 worker process isolation mode. ASP.NET requests first go through native processing
steps in IIS and are then routed to Aspnet_isapi.dll for processing of managed code in the
managed runtime. Finally, the request is routed back through IIS to send the response.
This separation of the IIS and ASP.NET request-processing models results in duplication of
some processing steps, such as authentication and authorization. Additionally, managed
code features, such as Forms authentication, are only available to ASP.NET applications or
applications for which you have script mapped all requests to be handled by aspnet_isapi.dll.
You should only add an application to an application pool in Classic mode if the application
fails to work in Integrated mode. For example, your application might rely on an
authentication token passed from IIS to the managed runtime, and, due to the new
architecture in IIS 7, the process breaks your application.
[Type text]
Planning a Secure BizTalk Environment
Identify security options for a BizTalk Server environment.
Overview
BizTalk Server provides a standard gateway for sending and receiving documents both within
the intranet and over the Internet. Due to the possible business-critical nature of the
messages sent to and from BizTalk Server, it is important to consider measures for securing
these messages and the information they contain, both when they are being transmitted
and while they are being processed and stored in the BizTalk Server environment.
Message Security
When a BizTalk Server receive location receives an encrypted and signed message, it
attempts to obtain the sender's Windows security ID (SSID) from the sending process. If
successful, it passes the SSID downstream.
The message is processed by the receive pipeline, where the message is decrypted, and the
digital signature is verified. If the sender used a signing certificate on the incoming message,
then the MIME/SMIME decoder pipeline component overwrites any certificate information
obtained from the adapter.
If the sender encrypted the message, the MIME/SMIME decoder retrieves the decryption
certificate from the personal certificate store for the host instance service account and uses
the private key to decrypt the message.
You can choose to have the BizTalk Server engine check the Certificate Revocation List (CRL)
to ensure that a certificate has not expired and that it is trusted down to a Root Certificate
[Type text]
Authority (CA). This verification occurs while the pipeline processes the message, in the
MIME/SMIME decoder component.
In the last stage of the pipeline, the party resolution component will attempt to match the
sender’s ID, whether that is the SSID or the client certificate, to a trading partner that has
been configured in BizTalk’s Trading Partner Management (TPM) system. If a match is
found, then the party resolution component will add the trading partner’s Party ID (PID) to
the message’s metadata properties. If not, then the “guest” ID will be assigned to the
message.
When BizTalk Server sends a message, if the send pipeline is configured to sign all outbound
messages, the signing certificate for the BizTalk group is retrieved from the personal
certificate store for the host instance service account under which the pipeline is running,
and the message is signed using the private key associated with the certificate.
If the pipeline encoding component is configured to encrypt all outbound messages, the
encryption certificate thumbprint is used to retrieve the public key certificate from the
Other People certificate store, and the message is encrypted using that certificate.
Receive Authorization
Receive authorization is the method you can use to control which hosts can receive
(subscribe for) a given message. BizTalk Server uses the certificate information as a
subscription property to match predicates on the message: the MessageBox database only
routes messages marked as authorization required to the hosts that have the decryption
certificate for that message.
Routing an un-encrypted message. When BizTalk Server receives a message that the sender
did not encrypt, there is no decryption limitation as to how BizTalk routes the message. Both
hosts with and hosts without receive authorization certificates configured can receive the
message.
Routing an encrypted message. When an encrypted message arrives, the receiving pipeline
must contain a decoding component that decrypts the message. When BizTalk Server routes
a message after it is decrypted, BizTalk uses the certificate thumbprint used to decrypt the
message as evidence in the MessageBox database subscription mechanism, and only those
hosts configured with that certificate receive the message.
Enterprise Single Sign-On (SSO)
Enterprise Single Sign-On (SSO) allows the seamless integration of user information between
disassociated security providers. Users or external processes can access resources on myriad
systems without the need of re-authenticating to each system. These credentials are
encrypted and stored in a SQL Server database by using a shared secret technology.
Transport Security
Network communication can be secured by using industry-standard Secure Sockets Layer
(SSL) or Transport Layer Security (TLS). On the receive side, this would be handled by IIS.
BizTalk Server 2010 supports the WS-Security, WS-SecureConversation, WS-SecurePolicy and
WS-Trust standards through the BizTalk WCF adapters.
Access Control
BizTalk Server limits access to its processes and databases by using minimum user rights; you
can help secure important data in the system by using features from Microsoft Windows
[Type text]
Server. For security reasons, BizTalk Server Administrators and BizTalk Hosts should not have
more user rights than necessary to perform their jobs.
BizTalk Server does not support using any of the following built-in Windows accounts:



NT_AUTHORITY\NetworkService
LocalSystem
NT_AUTHORITY\LocalService
BizTalk is dependent on SQL Server 2008 for the messaging tracking database as well as
other databases. The SQL Server implementation should be planned so that it supports
security for the BizTalk Server databases. The most sensitive information (credential
information such as database connections strings and user name and passwords related to
the BizTalk adapters) is stored in an encrypted format in the Single Sign-On (SSO) database.
[Type text]
Planning a Multiple-Server Environment
Identify considerations for a multiple-server BizTalk Server environment.
Multiple-Server Configurations
BizTalk can be configured in multiple-server environments to provide scalability and
redundancy. This configuration also allows the use of clustered computers running SQL
Server for high reliability. Refer to the “Planning the SQL Server Environment” topic page in
this module for clustering and database performance recommendations.
The BizTalk administration tools can be installed on multiple workstations for distributed
administration. The BizTalk Server 2010 Management Pack for System Center Operations
Manager (SCOM) provides comprehensive discovery and monitoring of BizTalk Server
components and applications that are running in multiple machines.
The dependencies that you must install or update before performing an installation of
BizTalk Server 2010 will vary and will depend on the selection of features that you choose to
include in your installation.
You can download the document titled “Installing BizTalk Server 2010 and BAM in a MultiComputer Environment” for more details.
[Type text]
Lab 2a: Install and Configure SharePoint Foundation 2010
Introduction
Microsoft SharePoint Foundation 2010 is a prerequisite for installing the Windows
SharePoint Services adapter for BizTalk Server. In this lab, you will install and configure
Microsoft SharePoint Foundation 2010.
[Type text]
Procedure List
window.
Start.
Procedure List
[Type text]
Exercise 1: Install SharePoint Foundation 2010
Overview
In this exercise, you will install Microsoft SharePoint Foundation 2010.
Install SharePoint Foundation 2010
Procedure List
1. In Windows Explorer, navigate to C:\Temp, and then double-click
SharePointFoundation.exe.
2. In the Open File – Security Warning window, click Run.
3. In the Microsoft SharePoint Foundation 2010 window, click Install SharePoint
Foundation.
4. Click I accept the terms of this agreement, and then click Continue.
5. On the Data Location page, click Install Now, and wait for the installation to
complete.
6. In the Microsoft SharePoint Foundation 2010 window, on the Run Configuration
Wizard page, click Close.
The SharePoint Products Configuration Wizard will launch automatically.
[Type text]
Exercise 2: Configure SharePoint Foundation 2010
Overview
In this exercise, you will configure SharePoint Foundation 2010, including the Internet
Information Services (IIS) Manager application pool, and the SQL Server database and
credentials used.
Configure SharePoint Foundation 2010
Procedure List
1. In the SharePoint Products Configuration Wizard window, on the Welcome to
SharePoint Products page, click Next.
2. In the SharePoint Products Configuration Wizard warning dialog box, click Yes.
3. On the Connect to a server farm page, click Create a new server farm, and then
click Next.
4. On the Specify Configuration Database Settings page, in the Database server box,
enter BIZTALKDEMO.
5. In the Username box, enter ADVENTUREWORKS\SharePointService, and in the
Password box, enter pass@word1, and then click Next.
6. On the Specify Farm Security Settings page, in the Passphrase and Confirm
passphrase boxes, enter pass@word1, and then click Next.
7. On the Configure SharePoint Central Administration Web Application page, click
Next.
8. On the Completing the SharePoint Products Configuration Wizard page, click Next.
9. Allow the configuration to complete, and then on the Configuration Successful
page, click Finish, and wait for the configuration to complete.
The SharePoint Central Administration page will be launched automatically.
Configure the SharePoint Farm
Procedure List
1. In Internet Explorer, on the Help Make SharePoint Better page, click No, I don’t
wish to participate, and then click OK.
2. On the How do you want to configure your SharePoint farm? page, click Start the
Wizard.
3. Click Use existing managed account, and then click Next.
4. In the Title box, enter Lab2, and then click OK.
5. On the This completes the Farm Configuration Wizard page, click the
http://biztalkdemo link to view the new SharePoint site.
6. Verify that the Welcome to your site page appears.
7. Close all open windows and pause the bt10a-02 virtual machine.
[Type text]
Lesson 2: Installing and Configuring BizTalk Server
Lesson objective:
Install and configure BizTalk Server 2010 for a production environment.
Lesson Overview
Because of the many product dependencies required to perform a complete installation of
BizTalk Server, careful planning is essential to a smooth and effective installation. The topics
in this lesson provide the concepts and information that you will need when you design and
implement the optimal BizTalk configuration for your environment.
[Type text]
Installing BizTalk Components
Install required and optional components for a computer running BizTalk Server.
Required Components
The BizTalk Server 2010 Installation Wizard provides you with the ability to select specific
components required to support your development or production environment. Required
components include the services and tools required by your type of installation. For
example, a development and production computer will require the BizTalk run-time services
(messaging and orchestration engines).
Optional Components
Optional components include those components that you choose to install to support your
application environment. For example, you could choose to install the Rules Engine to
support applications requiring the use of the BizTalk Rules Engine or Business Activity
Monitoring (BAM) if you want to provide business analysts with the ability to monitor
business processes by using the new BAM Portal. Any components that do not have the
prerequisite software installed will be unavailable on the Component Installation page.
[Type text]
Configuring BizTalk Server
Configure BizTalk Server installation options.
Overview
When the Configuration Wizard starts, it identifies the current state of the installation and
any configuration tasks that still require action.
Using the Configuration Wizard
You can use the Configuration Wizard to perform the following tasks:
Configure the Single Sign-On (SSO) service. SSO provides services to store and transmit
encrypted user credentials across local and network boundaries, including domain
boundaries.
Create or Join a BizTalk Group. A BizTalk Server Group is a collection of settings that govern
the way BizTalk Server behaves and the data stores it uses.
Configure the BizTalk Server Runtime. The BizTalk Server Runtime is the core engine of
BizTalk Server, providing message routing capabilities.
Configure the Business Rules Engine. The BizTalk Business Rules Engine (BRE) is a rule-based
inference engine that evaluates rules against facts and initiates actions based on the results
of the evaluation.
Configure Business Activity Monitoring Tools and Alerts. Business Activity Monitoring (BAM)
tools provide business users with a set of monitoring tools for BizTalk Server 2010. BAM
[Type text]
alerts provide subscription-based notification services on user-defined instance or aggregate
data.
Configure the BAM Portal. The BAM portal is an ASP.NET application that presents data that
has been collected for BAM activities and views.
Configure the EDI/AS2 Runtime. BizTalk Server Electronic Data Interchange (EDI) and AS2
provide support for sending and receiving messages using the EDI or AS2 protocol.
Configure the Windows SharePoint Services Adapter Web Service. The Windows SharePoint
Services Web Service enables BizTalk and SharePoint integration for this Windows
SharePoint Services installation.
[Type text]
BizTalk Server Accounts and Databases
Configure BizTalk administrative accounts and databases.
BizTalk Configuration Settings
To complete a BizTalk Server 2010 installation, you must provide specific configuration
settings for the installed features required to support your BizTalk environment. This
includes configuration settings for administrative accounts and the creation of BizTalk Server
databases. Considerations for using administration accounts include:

Administrative accounts. During the configuration, you must specify the BizTalk
administrative and service accounts that will be used to perform specific tasks and
operations on the computer running BizTalk. BizTalk Server supports local or domain
groups and user accounts in single-computer configurations. If you install BizTalk
Server 2010 and all the prerequisite software on a single computer, the
Configuration Wizard will create the necessary BizTalk Group accounts for you by
default.

Domain Accounts. If your environment consists of multiple computers running
BizTalk Server, you should manually configure your BizTalk service accounts as
domain accounts prior to installing BizTalk Server. Also, when configuring Enterprise
Single Sign-On (SSO) service, it is required that you use domain groups and domain
user accounts to provide full functionality.
[Type text]
BizTalk Databases
During the configuration of the first computer running BizTalk Server, the BizTalk databases
will be created automatically. The default names (which can be changed during installation)
and a brief description of the most prominent databases follows:

BizTalkMgmtDb. The BizTalk Management database contains the configuration
information and metadata related to the BizTalk Server installation.

BizTalkMsgBoxDb. The MessageBox database stores messages and message
properties. This database also stores subscription predicates, is a host platform, and
keeps the queues and state tables for each BizTalk Server host.

BizTalkDTADb. The BizTalk Tracking database stores business and health-monitoring
data tracked by the BizTalk Server tracking engine. The properties to be tracked are
configurable.

SSODB. The Single Sign-On (SSO) database is used to store adapter configuration
information such as user credentials related to adapters.

BizTalkRulesEngineDb. The Rules Engine database maintains the published
vocabularies and policies associated with business rules.
[Type text]
Web Sites and Web Portals
Identify the Web sites and Web portals used in a BizTalk Server environment.
Tools for Business Analysis and Decision Support
Business Activity Monitoring (BAM) provides visibility into business processes in as close to
real time as possible. Business analysts can use the BAM Activity Wizard and the BAM Portal
to specify what data to collect and how to collect it and then report on the collected data.
Activity aggregations of business data are maintained in the form of online analytical
processing (OLAP) cubes, and systems administrators schedule SQL Agent jobs to run on a
regular basis to update data in the cubes.
BAM Portal
The BAM portal provides real-time, end-to-end visibility into a business process. It is a Webbased feature that consists of a collection of ASP.NET pages. You can customize BAM to
enhance the performance and experience for your users.
The BAM portal allows you to perform searches, aggregate data, and set alerts on a BAM
view, which is a perspective on your business data. This visibility can provide the necessary
KPI information for your business, or it can be used as proof of concept before you
implement another solution such as extending a Microsoft Office Excel spreadsheet, using
SQL Reporting, or building a custom user interface (UI).
[Type text]
BAM Databases
When you configure Business Activity Monitoring for the first time, the BizTalk Configuration
Wizard will create a set of databases for collecting and reporting data that is collected by
application components configured to perform Business Activity Monitoring.

BAMPrimaryImport. This database holds BAM tracking data for current instances of
BAM activities.

BAMArchive. This database holds BAM tracking data for completed instances of BAM
activities.

BAMAnalysis. This SQL Server Analysis Services database keeps the aggregated
historical data for Business Activities. This database will only be created if the
“Enable Analysis Services for BAM aggregations” option is selected.

BAMStarSchema. This database transforms the data collected from the Business
Activity Monitoring for OLAP Processing. This database is required when using the
BAM Analysis database.
[Type text]
Troubleshooting Configuration Errors
Troubleshoot problems in a BizTalk Server installation.
Log File
The configuration process generates a single, unified log file. This file contains a summary of
the configuration steps performed, as well as diagnostic information about any failures that
might have occurred during the BizTalk Server configuration process. The configuration log
file is saved in the current user’s Temp folder, and a link to this log file is provided at the end
of the Configuration Wizard.
Common Errors
The configuration process for BizTalk Server 2010 has been greatly improved from earlier
versions, which reduces the likelihood of installation and configuration errors. For example,
in BizTalk Server 2004, missing prerequisites could cause the configuration to fail and
completely roll back. In BizTalk Server 2010, the portion that can succeed does and any
components that cannot be configured can be retried later. Here are some of the common
configuration errors you’re likely to encounter:

Problem: You attempt to configure BizTalk and receive and error that the database
cannot be created.

Resolution: The account that you are attempting to install under does not have
sufficient permissions in SQL Server. Try again using an account with the appropriate
permissions.
[Type text]

Problem: You attempt to configure BizTalk and receive an error that the databases
already exist.

Resolution: If configuration fails, and if you plan to run the Configuration Wizard
again, you must first manually delete any BizTalk databases that have been created.
This will include SQL Server databases as well as optional Analysis Services databases
that might have been created.

Problem: You are trying to install BizTalk Server on multiple computers, but you
cannot locate the users in Active Directory directory services.

Resolution: You must manually create any domain groups and user accounts before
installing BizTalk Server on multiple computers.
[Type text]
Installing Client Administration Tools
Install BizTalk Server client administration tools on a computer running Microsoft Windows.
Overview
The BizTalk Server client administration tools enable you to perform BizTalk Server
administration tasks remotely from a client computer. Missing dependencies are detected
during installation, and the user is prompted to install them before continuing. The prompt
includes the option to download the latest version of the component or to install the
components from the installation media.
Administration Tools
The administration tools include tools to monitor, administer, and deploy applications on a
computer running BizTalk Server. These tools include the Business Rules Composer,
Enterprise Single Sign-On (SSO) administration, and the BizTalk Server 2010 Administration
Console and other tools for managing the BizTalk Server environment remotely.
To perform SSO administration, Microsoft Management Console (MMC) 3.0 SP1 is required.
This update is not included in the .cab file that is downloaded and/or executed during the
installation.
Client Requirements
The BizTalk client administration tools require the BizTalk Server components and the
Windows 7, Windows Vista SP2, Windows Server 2008 R2, or Windows Server 2008 SP1
operating system. To install the client administration tools, you must be an administrator on
the computer. During the installation process, BizTalk will detect whether the required
[Type text]
prerequisites are installed, including Microsoft SQL XML 4.0 SP1 and ADOMD.NET versions
10.0 and 9.0.
After the installation is complete, the Configuration Wizard will allow you to specify the
configuration database that you want to manage. Additional databases can be added to
support configuration of development, test, and production environments from a single tool
installation.
[Type text]
Changing a BizTalk Configuration
Modify an existing BizTalk Server configuration.
About the BizTalk Server 2010 Configuration Tool
The BizTalk Server 2010 Configuration tool allows you to set up and change the
configuration settings for a computer running BizTalk Server. BizTalk Server 2010 provides a
Default Configuration option that simplifies a simple single-server configuration. By
performing a custom installation, you can select how the various features will be configured.
Here are some of the features of the computer running BizTalk Server that can be
configured:

BizTalk Server groups. You can create a new BizTalk Group or join an existing group.
All servers in a BizTalk Server group (or system) share a common set of databases,
including the management database and the MessageBox database or databases.

SQL Server Analysis Services. You can create an analysis database for aggregation of
tracking data and Business Activity Monitoring (BAM) data by using SQL Server
Analysis Services, and you can configure database names and administrative roles
for these databases.

Business Activity Monitoring (BAM). You can enable and disable BAM tools for the
BizTalk Group, enable Analysis Services for BAM aggregation, and view the BAM
databases. You can also specify the BAM Portal server and site name. The BAM
Portal uses ASP.NET functionality, and is not dependent on SharePoint.
[Type text]

Enterprise Single Sign-On (SSO). You can enable or disable SSO, create a new SSO
system, or join an existing SSO system. You can also view or change the SSO
database, the Windows service account, and the Windows accounts used by SSO.

BizTalk Server Runtime. You can view the BizTalk Host name and the Isolated Host
name as well as view and change the accounts associated with each host.

Business Rules Engine. You can update the account used by the Rules Engine Update
Service as well as view the Rules Engine database name and server name.

Electronic Data Interchange (EDI). You can configure support for EDI protocol
messaging.
Note: Most of the options listed here will already be configured for your current installation
of BizTalk Server. If you need to reconfigure any of these options, you can do so by using the
Actions menu in the BizTalk Server 2010 Configuration tool.
[Type text]
Exporting and Importing a Configuration
Export an existing BizTalk Server configuration, and import the configuration to a new computer
running BizTalk Server.
Export and Import
Any time after you have completed the BizTalk installation, you can export the configuration
settings to an XML file. This XML file will contain a snapshot of all of the configuration
choices that you made during the configuration, including administrative accounts,
databases, and all other settings.
The BizTalk Server configuration can also be exported during the silent custom installation or
from the Configuration Summary page. During the initial configuration, you can save a
configuration snapshot. The XML file that is generated can then be modified (by changing
user names and so forth) and subsequently used on other computers to replicate the
configuration as part of a scripted installation. This is helpful in an environment where
several computers running BizTalk Server require the same installed components and the
same configuration (multiple-server groups and development environments).
You can use this XML file to import these configuration settings to another server running
BizTalk to replicate the installation process of a new computer during a scripted installation.
[Type text]
Removing a BizTalk Server Installation
Uninstall BizTalk Server from a computer.
Add/Remove Programs
To remove Microsoft BizTalk Server 2010, you can use the Microsoft Windows Add/Remove
Programs utility.
Uninstalling BizTalk
When removing BizTalk Server, keep the following points in mind:

It is important that you not remove any of the BizTalk Server prerequisites before
you uninstall BizTalk. All of the prerequisites must be present for the uninstall
process to complete successfully.

If any assemblies stored in the Global Assembly Cache (GAC) are in use while you are
uninstalling BizTalk, the assemblies might not be removed completely. To ensure
that all assemblies are completely removed, stop all host instances and Internet
Information Services (IIS) prior to uninstalling BizTalk.

All active BizTalk services will be stopped and uninstalled during the removal
process.

The BizTalk Server 2010 uninstall process will remove neither the maps nor the
schemas from the GAC nor the BizTalk Server 2010 databases. All such artifacts must
be removed manually.
[Type text]

All receive and send port configurations, such as Web sites and file drop locations,
must be removed manually.
[Type text]
Demonstration: Using the BizTalk Configuration Wizard
In this demonstration, you will see how to configure a BizTalk Server computer and export the
configuration settings to an XML file.
Examine the Existing Configuration
1. On the Start menu, point to All Programs, point to Microsoft BizTalk Server 2010,
and then click BizTalk Server Configuration.
2. Click Group in the left pane.
Notice that the database servers, database names windows group names are
configurable.
3. Click BizTalk Runtime in the left pane.
Notice that the default host names, windows service users and windows group
names are configurable.
Exporting a BizTalk Server Configuration
1. In the Microsoft BizTalk Server 2010 Configuration Wizard, click Export
Configuration.
2. In the Save As window, click Desktop in the left pane, and then type
DemoBTSConfig.xml as the File name.
3. Click Save, and then click OK.
4. Close the Microsoft BizTalk Server Configuration window.
5. On the Desktop, double-click DemoBTSConfig.xml to open the configuration file.
[Type text]
6. Examine the file.
7. Shut down the bt10a-demos virtual machine.
[Type text]
Introduction
In this lab, you will install and configure BizTalk Server 2010. You must have completed Lab
2a in order to successfully complete this lab.
[Type text]
Exercise 1: Install BizTalk Server 2010
Overview
In this exercise, you will perform an installation of BizTalk Server 2010, choosing the
components to be installed. Any missing prerequisites will be installed automatically from
the provided CAB file.
Install BizTalk Server 2010
Procedure List
1. Resume the bt10a-02 virtual machine.
2. In Windows Explorer, navigate to C:\AllFiles\LabFiles\Module 2\BT Server, and
then double-click Setup.exe.
3. In the Microsoft BizTalk Server 2010 Installation Wizard, click Install Microsoft
BizTalk Server 2010.
4. On the Customer Information page, click Next
5. On the License Agreement page, click Yes, I accept the terms of the license
agreement, and then click Next.
6. On the Customer Experience Improvement Program page, click No, I don’t want to
participate in the program, and then click Next.
7. On the Component Installation page, expand Additional Software, select all
available components, and then click Next.
The prerequisites for the MQSeries Agent have not been installed, so that option
will be disabled.
8. On the Summary page, click Install, and then wait for the installation to complete.
9. On the Installation Completed page, ensure that Launch BizTalk Server
Configuration is selected, and then click Finish.
[Type text]
Exercise 2: Configure BizTalk Server 2010
Overview
In this exercise, you will perform a custom configuration of BizTalk Server 2010. You will
specify the user account and database names used by BizTalk Server.
Manually Configure BizTalk Server 2010
Procedure List
1. If the Microsoft BizTalk Server 2010 Configuration Wizard is not already running, on
the Start menu, point to All Programs, point to Microsoft BizTalk Server 2010, and
then click BizTalk Server Configuration.
2. In the Microsoft BizTalk Server 2010 Configuration Wizard, click Custom
Configuration.
3. Click the Browse button to the right of the User name box.
4. In the Select User dialog box, click the Advanced button, then click Find Now, and in
the Search results list, double-click BizTalkHost, and then click OK.
5. In the Password box, enter pass@word1, and then click Configure.
6. In the left pane of the Microsoft BizTalk Server 2010 Configuration Wizard, click
Enterprise SSO.
7. In the right pane, select Enable Enterprise Single Sign-On on this computer.
Notice that the account information is automatically populated with the account
specified on the first page of the wizard.
8. Click the ellipsis (…) to the right of Enterprise Single Sign-On Service, and then in the
in the User Credentials dialog box, click Browse.
the Search results list, double-click SsoService, and then click OK.
10. In the User Credentials dialog box, in the Password box, enter pass@word1, and
then click OK.
Enterprise SSO Sign-On Secret Backup.
12. In the right pane, type pass@word1 in the Secret backup password and Confirm
password boxes, and then type Default password in the Password reminder box.
When you use the Basic Configuration option to configure a BizTalk Server
installation, the SSO Single Sign-On secret backup password defaults to the
password of the user installing BizTalk Server 2010.
13. In the left pane, click Group.
14. In the right pane, select Enable BizTalk Server Group on this computer.
15. Click the ellipsis (...) to the right of BizTalk Administrators Group.
16. In the Select Group dialog box, click the Advanced button, and then click Find Now.
17. In the Search results list, double-click BizTalk Server Administrators, and then click
OK.
18. Click the ellipsis (...) to the right of BizTalk Operators Group.
[Type text]
20. In the Search results list, double-click BizTalk Server Operators, and then click OK.
21. Click the ellipsis (...) to the right of BizTalk B2B Operators Group.
23. In the Search results list, double-click BizTalk Server B2B Operators, and then click
OK.
24. In the left pane, click BizTalk Runtime.
25. In the right pane, select Register the BizTalk Server runtime components.
26. Click the ellipsis (…) to the right of BizTalk Isolated Host Instance Account, and then
in the in the User Credentials dialog box, click Browse.
the Search results list, double-click BizTalkIsoHost, and then click OK.
then click OK.
29. Click the ellipsis (...) to the right of BizTalk Host Users Group.
31. In the Search results list, double-click BizTalk Application Users, and then click OK.
32. Click the ellipsis (...) to the right of BizTalk Isolated Host Users Group.
34. In the Search results list, double-click BizTalk Isolated Host Users, and then click OK.
35. In the left pane, click Business Rules Engine.
36. In the right pane, select Enable Business Rules Engine on this computer.
37. Click the ellipsis (…) to the right of Rule Engine Update Service, and then in the in
the User Credentials dialog box, click Browse.
the Search results list, double-click ReuService, and then click OK.
then click OK.
40. In the left pane, click SharePoint Adapter.
41. In the right pane, select Enable Windows SharePoint Services Adapter on this
computer.
42. Click the ellipsis (...) to the right of BizTalk SharePoint Adapter Enabled Hosts.
44. In the Search results list, double-click SharePoint Enabled Hosts, and then click OK.
45. In the Windows SharePoint Services Adapter Web Site list, select SharePoint - 80.
46. Click the Apply Configuration button.
47. On the Summary page, click Next.
48. Click Finish.
[Type text]
49. On the Overview page of the Microsoft BizTalk Server 2010 Configuration wizard,
notice that BAM Tools, BAM Portal and BizTalk EDI/AS2 Runtime have exclamation
points next to them. This is because the components are not configured.
50. Click the Export Configuration button, and then save the file to the desktop.
51. Examine the configuration file.
Module objective:
In this module, you will learn:
How to choose an application deployment method and deploy applications to a production
environment.
Overview
Microsoft BizTalk Server 2010 includes features that simplify the 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: Introduction to Application Deployment
Lesson objective:
Explain how BizTalk applications are deployed and identify the tools available for deploying and
managing different versions of applications.
Lesson Overview
Before you deploy a BizTalk Server solution within your business environment, you need to
understand how application deployment works and be familiar with the various methods
available for deploying applications. This lesson provides an overview of application
deployment and how to manage different versions of applications.
What Are BizTalk Server Artifacts?
Identify the types of artifacts that make up a BizTalk application.
Definition of Artifact
An artifact is a BizTalk Server 2010 file that is created by using Microsoft Visual Studio® 2010.
Artifacts include schemas, maps, pipelines, and orchestrations. Visual Studio 2010 provides
several BizTalk Server project templates that are used to create artifacts for a BizTalk
application. Although a BizTalk Server project can contain only BizTalk artifacts, a Visual
Studio solution can contain other non-BizTalk projects that might be required by an
application. Each project, including all of its contained artifacts, is compiled into a single
dynamic-link library (DLL).
Types of Artifacts
BizTalk artifacts include:

Schemas. Files that represent the structure of a message. Most messages that
BizTalk Server processes must be represented by a schema. For example, when you
receive a purchase order from a customer, the schema for the purchase order
describes the format for information received, such as the customer name, address,
purchase order number, and so on. BizTalk schemas have an .xsd extension (for
example, PurchOrder.xsd).

Maps. Extensible Markup Language (XML) files that define the correspondence
between the records and fields in one message and the records and fields in another
message. For example, a purchase order might need to be converted from a format
used by a customer to an internal format that can processed by BizTalk. BizTalk
maps have a .btm extension and are typically named to represent the purpose of the
map (for example, PurchOrder_to_CustomerOrder.btm).

Pipelines. Software components that can perform processing functions on messages.
The functions might include processing tasks such as encrypting or decrypting
messages, validating incoming messages against a specific schema, or decoding and
encoding messages. Pipelines are unique to BizTalk and have a .btp extension (for
example, DecryptMessage.btp).

Orchestrations. Provide a logical representation of a business process.
Orchestrations are built in the Orchestration Designer by using various shapes, each
of which has underlying code. Visual Studio uses the orchestration design to
generate C# code, which is then compiled in to a .NET assembly that can be
executed by computers running BizTalk Server. Orchestrations have an .odx
extension and are typically named to represent the purpose of the orchestration (for
example, ProcessCustomerOrder.odx).
After the artifacts have been created, compiled, and tested by developers, they can then be
deployed into a production environment.
How Deployment Works
Describe the difference between BizTalk assemblies and non-BizTalk assemblies, and explain how
the BizTalk assembly deployment process works.
Non-BizTalk Assemblies
In the Microsoft .NET Framework, one or more associated files that can be loaded as a unit
into memory in the form of an executable or a code library image are referred to as an
assembly. Assemblies function as the fundamental unit of deployment, versioning, reuse,
and security. Microsoft .NET assemblies can be written in any of several languages. BizTalk
can make use of assemblies written in any .NET language to perform processing that you
might not want, or be able, to perform within BizTalk.
Assemblies can be private or shared. A private assembly is deployed with an application and
is available for the exclusive use of that application, whereas a shared assembly is available
for use by multiple applications on the computer. The global assembly cache (GAC) is a
system folder reserved for shared assemblies. For an assembly to be registered in the GAC, it
must be assigned a strong name. A strong name requires a key and provides for uniqueness
to allow multiple versions of the same assembly to be deployed.
BizTalk Assemblies
BizTalk assemblies are shared .NET assemblies that include BizTalk artifacts and are based on
a BizTalk project. Each BizTalk project, along with all its contained artifacts, will be built into
a single assembly (DLL file), which must be deployed to the BizTalk configuration database
and installed in the GAC on each computer running BizTalk Server. Because the assembly
must be registered in the GAC, it must have a strong name.
BizTalk Assembly Deployment Process
A typical BizTalk installation consists of development, test, and production environments. In
this example, the assemblies will be deployed initially in the development environment
before being tested and then finally deployed to the production environment. These two
deployment steps will need to be duplicated in each environment:
1. Install the assembly in the GAC. All BizTalk assemblies must be registered in the GAC
on each computer running BizTalk Server that requires the artifacts. In a production
environment, it is likely that not every server needs to perform all BizTalk functions.
Only the assemblies containing the artifacts needed by the function being
performed on that server need to be deployed. For example, if a server is
performing only the purchase order receive process and is not involved with running
orchestration instances for the purchase order process itself, only the DLL containing
the purchase order schema needs to be deployed to that server.
2. Register the assembly in the BizTalk configuration (BizTalkMgmtDb) database. The
BizTalk configuration database is a central repository for BizTalk Server configuration
settings and information. In a BizTalk environment consisting of multiple computers
running BizTalk Server, the configuration database is shared between all computers
running BizTalk Server. Each assembly needs to be deployed to the database only
once. Only BizTalk assemblies can be registered in the configuration database.
Although all configuration information is stored in the configuration database, securitycritical information relating to adapter configuration and so on is maintained in the Single
Sign-On (SSO) database where the data is encrypted.
Application Deployment Methods
Describe the different methods available for deploying a BizTalk application and identify the
scenarios for using each deployment tool.
Microsoft Visual Studio 2010
The most common deployment option used by developers is the capability built in to Visual
Studio. Visual Studio can be used to deploy and redeploy assemblies from a BizTalk project.
Developers can use this method to deploy assemblies to the GAC and the configuration
database in one easy step.
Visual Studio offers a redeploy option that is useful for developers who might need to
redeploy an application many times during the development process. After redeploying, it is
usually necessary to restart the BizTalk host instances to load the latest copy of the
assemblies. Visual Studio includes a project option to automatically perform the restart
after each deployment.
BizTalk Server Administration Console
BizTalk Server includes a feature that allows administrators to create MSI packages for
BizTalk applications. These MSI packages can contain all of the assemblies required by the
application, as well as any other files that the administrator needs to include. This tool
enables simplified deployment of BizTalk artifacts from a test environment to a production
environment and to multiple servers.
Command-Line Deployment
In a production environment that includes multiple computers running BizTalk Server, an
assembly needs to be deployed only once to the BizTalk configuration database. However,
each computer running BizTalk Server in a BizTalk Server group must have the assemblies
registered in its own GAC. An administrator can do this manually or can create a script to do
this by using the BTSTask command-line tool. BTSTask can be used to perform most of the
tasks that are found in the BizTalk Administration Console.
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.
How Assembly Versioning Works
Explain the implications of assembly versioning in a test and production environment.
Overview
When you deploy a BizTalk-based assembly, you must be aware of the effects of versioning.
Two versions of the same BizTalk assembly with the same name can be deployed
simultaneously provided they have strong names that use the same key and have a unique
version number.
Testing Environments
A single assembly might need to be deployed and redeployed several times to successfully
test its functionality. Normally, BizTalk requires that an assembly version (such as 1.0.0.0) be
removed before the same assembly version can be redeployed. This is a necessary security
precaution for production environments. However, in a test environment, it is often
necessary to redeploy a number of times to test a minor modification. In BizTalk Server
2010, Visual Studio 2010 enables an assembly to be deployed over an existing assembly to
speed up and simplify the testing process.
Production Environments
In a production environment, it might be necessary to run multiple versions of the same
process side by side. For example, if you have a process that takes three days to complete (a
long-running process), you cannot simply replace the existing version of the application
without cancelling all existing instances of the process, because all changes to the running
instances would be lost. In this case, a new version of the application can be deployed while
the old version continues to run. Once the new version is deployed, it will process all new
instances of the business process. After the old version has completed processing of existing
instances, it can be safely un-deployed.
Version Numbering
Before you deploy an assembly, you need to verify that the same version of the assembly is
not already deployed. If you attempt to deploy an assembly with the same version number,
the deployment will fail, and an error will be generated. An assembly version is represented
in the following four-part numbering format:
Major Version.Minor Version.Revision.Build Number
If a change is made to the major version or minor version numbers, the assembly will be
identified as being a different version and will support side-by-side deployment.
Removing Assemblies
Before you remove a BizTalk assembly from the management database, you must ensure
that any artifacts that it contains are not in use. For example, if any orchestration is enlisted
or if any of the assembly’s maps or pipelines are in use within send or receive ports, the
removal will fail. Management of these artifacts will be discussed in detail in upcoming
modules.
An existing assembly can be removed by using the BizTalk Administration Console. Navigate
to the Resources folder under the application in which the assembly is deployed, right-click
the assembly name, and then click Remove. This process will remove the assembly from the
Configuration database; however, the DLL will still exist on each computer running BizTalk
Server. To completely remove the assembly, this file will need to be deleted.
You can also remove an assembly by using the BTSTask command-line tool with the
RemoveResource option. This utility can remove the assembly from the BizTalk
Configuration database and, optionally, from the GAC on the local computer. Type BTSTask
/? at the command prompt for a list of all available options for BTSTask.
Viewing Deployed BizTalk Assemblies
Using the BizTalk Administration Console to view the assemblies that have been deployed.
Overview
Before deploying a new version of an assembly, it is important to know what versions are
already deployed.
Using BizTalk Server Administration Console to View Assemblies
The assemblies used by BizTalk Server must be deployed to both the GAC of each computer
running BizTalk Server and the configuration database. The BizTalk Server Administration
Console allows you to view the assemblies which are deployed to the configuration
database. You can view all the assemblies deployed to the BizTalk group together or view
them on a per application basis. The Resources folder can be used to add additional
assemblies (BizTalk and non-BizTalk) and script files. Removing resources from this folder
will remove it from the configuration database. Individual artifacts within an assembly can
be viewed and managed in the other folders of the BizTalk Server Administration Console.
Demonstration: Viewing Deployed Assemblies
In this demonstration, you will see how to use the BizTalk Server Administration Console to view
multiple versions of deployed assemblies.
To View Deployed Assemblies
3. Start the bt10a-demos virtual machine.
and then click BizTalk Server Administration.
5. In the BizTalk Server 2010 Administration Console, expand BizTalk Server
Administration, BizTalk Group, Applications, and Module3, and then click
Resources.
6. Notice that three versions of the OrderManagement assembly are deployed—
versions 1.0.0.0, 2.0.0.0, and 4.0.0.0.
7. In the left pane, click Maps.
8. Notice that there are three versions of the
OrderManagement.PurchaseOrder_To_ShipNotice,
OrderManagement.PurchaseOrder_to_PurchaseOrderAck, and
OrderManagement.SimpleOrder_to_PurchaseOrder maps.
9. In the left pane, click Schemas.
10. Notice that there are three versions of each of the five schemas.
11. In the left pane, click Orchestrations.
12. Notice that there are three versions of both orchestrations.
13. Pause the bt10a-demos virtual machine.
Lesson 2: Deploying Assemblies by Using an MSI Package
Lesson objective:
Deploy an application by using MSI packages.
Lesson Overview
BizTalk applications contain BizTalk artifacts (such as schemas and maps) as well as policies,
receive ports, and send ports configured within that particular application. Exporting a
BizTalk application as an MSI package makes it much easier to copy and move these artifacts
between multiple computers running BizTalk Server.
What Is a BizTalk Application MSI Package?
Explain what an MSI package is and what can be contained in an MSI package.
Overview
BizTalk Server provides developers and IT professionals with an easy way to generate
Microsoft Installer (MSI) packages for moving deployed applications from one physical
environment to another. For example, you can create an MSI package when you need to
move a BizTalk application from a staging environment to a production environment or from
one computer running BizTalk Server to another. This greatly simplifies a process that
required many steps in earlier versions of BizTalk Server.
A BizTalk application MSI package can contain:
•
The BizTalk assemblies that make up the application, including schemas, maps,
pipelines, and orchestrations.
•
The configuration information required to start the application on a computer.
•
Any non-BizTalk items, such as .NET assemblies.
•
Business rule policies to be processed by the Business Rules Engine (BRE).
•
Any Web resource information required to enable Web-based applications.
Deployment with MSI packages
Package and deploy an application as an MSI package.
What Is an MSI package?
BizTalk Server 2010 allows entire solutions to be packaged into MSI package files by using
the Microsoft Windows Installer technology. The MSI package contains all of the assemblies
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. Also, any
deployment mechanism can be used to deploy MSI packages, including Microsoft System
Center Configuration Manager.
Deploying with an MSI package
The completed MSI package can then be handed off to an administrator for installation and
deployment. The use of MSI packages has several advantages, such as easy deployment
upgrade and removal. Executing the MSI registers the assembly in the GAC and deploys to
the configuration database.
To facilitate moving from development to test or production environments, an entire
application with all its contents and configuration information can be packaged into a single
MSI file.
As noted earlier, all servers in a BizTalk group share the BizTalk Configuration database, so
when you deploy an MSI package to multiple physical servers, the assemblies are added only
once to the Configuration database. However, all assemblies and non-BizTalk items must
also be added to a physical location on each server as well as to each server’s GAC. Because
each server in the group generally needs to have the same artifacts installed, the MSI
package can be executed on each server to facilitate this installation.
Exporting an Application as an MSI Package
Export an application as an MSI package.
MSI File Export Utility
The MSI File Export Utility enables you to create a BizTalk Server application MSI package.
You can use this utility to select which parts of an application you want to export as an MSI
package. You can also specify binding information, dependencies, and any Internet
Information Services (IIS) virtual directories required by the application.
Before exporting the application as an MSI package, additional resources—such as
preprocessing scripts, post-processing scripts, BizTalk assemblies, supporting (non-BizTalk)
DLLs, files, and so on—can be added to the application. You can also configure properties for
defining how and when the assembly should be registered in the GAC, including:
•
Installing the assembly in the GAC on the local computer when the assembly is
added to the application.
•
Installing the assembly in the GAC on the local computer when the application MSI
file is imported.
•
Installing the assembly in the GAC on the local computer when the application is
installed from the MSI file.
Importing a Microsoft Installer Package
Install an MSI application package.
Overview
Before a computer running BizTalk Server can use a BizTalk assembly, the assembly needs to
be registered in the GAC and deployed to the configuration database. An MSI package can
perform either or both of these tasks. The registering of the assembly in the GAC needs to
be performed only once for the BizTalk group and can be performed on any server in the
group. Registering the assembly in the GAC must be performed on each computer running
BizTalk Server that will be referencing artifacts contained in the assembly.
Deploying an MSI Package to another Environment
You must perform the following steps to deploy the MSI application package to other
computers:

Import the application. During the import, the options that were defined when the
package was created can be modified (for example, which application to deploy to,
the file location, and so on).

Install on first server. After the Import Wizard has completed, you have the option to
install the MSI application package. Choosing this option launches the wizard to start
the installation process, which then registers the assembly in the GAC on the
computer running BizTalk Server.

Install on additional servers. For each additional computer running BizTalk Server in
the group, you can double-click the MSI package to start the application Setup
Wizard, which will result in the assemblies being registered in the GAC on each
computer running BizTalk Server. The import process must be executed only one
time per BizTalk Server group.
If an application having the same name does not already exist in the BizTalk Server group,
importing the application creates a new application in the group. If the application already
exists in the BizTalk Server group, this operation imports the application’s artifacts into the
existing application. While importing, an option to overwrite existing artifacts is presented
(and is not selected, by default). Select this check box to overwrite all selected artifacts on
the destination server.
After you have installed the MSI package and all the necessary files have been copied to the
correct location, an entry is made in Add or Remove Programs in Control Panel. You can then
use the BizTalk Administration Console to import the configuration information for the
application into a BizTalk Server group in the new environment.
Removing a BizTalk Application
Remove a BizTalk application.
Overview
Because a BizTalk deployment affects several different components, removing it will involve
several steps. A complete removal will include removing the assemblies from the
configuration database and removing the references in the GAC and the actual DLLs from
the local computer or computers.
Removing BizTalk Application Files by Using Add or Remove Programs
When an application is installed by using an MSI package (whether created by a BizTalk
developer or by a BizTalk administrator), an entry is added to Add or Remove Programs in
Control Panel. Selecting this option removes the installation files from the local computer,
but you will still need to remove the application from the BizTalk configuration, and also
uninstall the assemblies from the GAC.
Removing a BizTalk Application from the Configuration Database
The BizTalk Administration Console and the BTSTask command-line utility provide options
for removing individual assemblies as well as entire applications from the BizTalk
configuration database.
To remove an application from the BizTalk management database using the BizTalk
Administration Console, perform a full stop of the application, then right-click the
application name and then click Delete. To remove an assembly from an application by
using the BizTalk Administration Console, navigate to the Resources folder in the containing
application. In the right pane, right-click the assembly and then click Delete. The assembly
and all its contained artifacts will be disassociated from the application.
If artifacts are un-deployed by using the command-line utility, BTSTask.exe, you can choose
to remove the artifacts from the configuration database by simply deleting them.
Manual Steps to Be Performed After Removal
Regardless of the method that you use to remove BizTalk assemblies and applications, the
following additional steps might be necessary:

If the deleted application includes a virtual directory, the virtual directory and all its
files are removed, unless files were not included in the MSI package, and they were
added to the virtual directory following installation. In this case, the virtual directory
and the added files are not removed. You must remove these files explicitly.

If your application is using a certificate, the certificate will be deleted unless another
application is also using the certificate. In this case, you must manually delete the
certificate from the certificate store on the server by using the Certificates snap-in
for the Microsoft Management Console (MMC).

Any preprocessing and post-processing scripts are removed, but any files added by
the scripts during installation or removal are not removed, nor are any actions that
were taken by the scripts rolled back. You must manually reverse any actions and
remove any files added by scripts.

Components are not removed from the Windows registry; they must be removed
manually.

To completely remove the application, you must also uninstall the assembly from
the GAC by either deleting it in C:\Windows\Assembly or by using the gacutil
command-line utility.
Before you delete an application, consider the following points:

The application must be stopped before it can be deleted.

You can delete an application only if no other applications contain references to it.

You cannot delete the application if it contains a send port group of which a send
port in another application is a member. You must unenlist the member send port
before you can delete the application.

You cannot delete the default application. If you want to delete a default
application, you must first make another application the default. The default
application is created when you install BizTalk Server.
The BizTalk Server 2010 Help files contain detailed instructions on how to perform these
procedures.
Demonstration: Deploying an MSI Package
In this demonstration, you will see how to import a BizTalk MSI package that contains an
assembly that will be deployed to the BizTalk configuration database. You will then see how to
export a BizTalk assembly to an MSI, and how to undeploy an assembly.
To Import a BizTalk MSI Package
1. On the Start menu, point to All Programs, point to Microsoft BizTalk Server, and
then click BizTalk Server Administration.
2. In the BizTalk Server Administration Console, expand BizTalk Server Administration,
BizTalk Group, Applications, and Module3.
3. Right-click the Module3 application, point to Import, and then click MSI file.
4. In the MSI file to import box, type
C:\AllFiles\DemoCode\Module3\OrderManagementVersion3.msi, and then click
Next.
5. On the Application Settings page, click Next.
6. On the Application Target Environment Settings page, click Next.
7. On the Import Summary page, 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.
The Application Installation Wizard starts.
9. On the Select Installation Folder page, click Next.
10. On the Welcome to the Module3 Setup Wizard page, click Next.
11. On the Confirm Installation page, click Next.
12. On the Module3 Information page, click Next.
13. On the Installation Complete page, click Close.
14. In the BizTalk Server Administration Console, under Module3, click Resources.
15. Notice that OrderManagement, Version=3.0.0.0… assembly has been deployed.
If you do not see version 3.0.0.0 of the assembly listed, refresh the BizTalk Server
Administration Console at the Module3 application level.
To Export an Assembly to a BizTalk MSI Package
1. In the left pane of the BizTalk Server Administration Console, right-click Module3,
point to Export, and then click MSI file.
2. On the Welcome to the Export MSI File Wizard page, click Next.
3. On the Select Resources page, deselect OrderManagement, Version=2.0.0.0…,
OrderManagement, Version=3.0.0.0…, and OrderManagement, Version=4.0.0.0…,
and then click Next.
You want to export only the Version=1.0.0.0 assembly in this MSI package.
4. On the Specify IIS Hosts page, click Next.
5. On the Dependencies page click Next.
6. On the Destination page, click the ellipsis (…) button next to the MSI file to
generate box.
7. In the Export MSI dialog box, navigate to C:\AllFiles\DemoCode\Module3, in the
File name box, type OrderManagementVersion1, and then click Save.
8. On the Destination page, click Export.
9. On the Summary page, click Finish.
To Undeploy an Assembly
1. In the left pane of the BizTalk Server 2010 Administration Console, click Resources.
2. In the right pane, right-click OrderManagement, Version=1.0.0.0, and then click
Remove.
3. In the Confirm remove pop-up message box, click Yes.
4. Notice that the OrderManagement, Version=1.0.0.0… assembly is no longer
displayed in Resources.
5. In the left pane, click Schemas.
6. Notice that no schemas from the OrderManagement, Version=1.0.0.0… assembly
are displayed.
7. Repeat the preceding steps to remove OrderManagement, Version=2.0.0.0… and
OrderManagement, Version=3.0.0.0.
To Move an Assembly Between Applications
1. In the left pane of the BizTalk Server 2010 Administration Console, click Resources
under the Module3 application.
2. Right-click OrderManagement, Version=4.0.0.0, and then click Move To
Application.
3. In the Move to Application dialog box, select Module4 in the Destination
application list.
Notice that the dependent assemblies are listed, as well as all the other artifacts
that will be moved.
4. In the Move to Application dialog box, click OK.
5. Expand the Module4 application, and then click Resources.
6. Notice that one assembly has been moved.
7. Close all open windows.
Lab 3a: Deploying an Application by Using an MSI Package
Scenario
You are responsible for managing and administering the computers running BizTalk Server
for Adventure Works. The BizTalk development team has just completed a new version of a
BizTalk application and exported it as an MSI package. In this lab, you will remove the
previous version of the application, install the new version of the application, and then test
its functionality.
Procedure List
window.
Start.
Procedure List
Exercise 1: Remove the BizTalk Application
Overview
In this exercise, you will uninstall an older version of the Module 3 application from the
computer running BizTalk Server. You will first uninstall the application by using Add or
Remove Programs in Control Panel. You will then use the BizTalk Server Administration
Console to remove the application from the BizTalk configuration database.
Uninstall the Old BizTalk Application
Procedure List
BizTalk Group, and Applications, and then notice that the Module 3 – Uninstall
application is displayed.
3. On the Start menu, click Control Panel, and then under Programs, click Uninstall a
program.
4. In the Programs and Features window, right-click Module 3 – Uninstall, and then
click Uninstall.
The application name shown in Add or Remove Programs is the application
name associated with the MSI from which the application was installed. This
name might not be the same as the one shown in the BizTalk Server
5. After the uninstall completes, close the Programs and Features window.
6. In the BizTalk Server Administration Console, right-click Applications, and then click
Refresh.
7. Notice that the Module 3 – Uninstall application is still displayed.
Uninstalling the application removes the assembly from the global assembly
cache (GAC) of the local computer, but it does not remove the application from
the BizTalk Configuration database. You will need to remove the assembly or
delete the application by using the BizTalk Server Administration Console.
8. In the BizTalk Server Administration Console, right-click Module 3 – Uninstall, and
then click Stop.
9. In the dialog box, click Full Stop – Terminate Instances, and then click Stop.
You must terminate any running instances of the application before uninstalling
the application. If you do not perform this step, the uninstall will most likely fail.
then click Delete.
11. In the Confirm delete application dialog box, click Yes.
12. Notice that the Module 3 – Uninstall application is no longer displayed.
Exercise 2: Deploy a BizTalk Application from an MSI Package
Overview
Deploying a BizTalk Server application is a two-step process. The BizTalk assembly must be
installed to the global assembly cache of the computer running BizTalk Server, and
registered in the BizTalk configuration database. In this exercise, you will deploy a BizTalk
Server application by using an MSI package. First you will import the MSI package to the
BizTalk Server configuration database by using the BizTalk Server Administration Console.
Then, you will run the MSI package to install the application to the computer running BizTalk
Server.
Import the BizTalk MSI
Procedure List
1. In the BizTalk Server Administration Console, right-click Applications, point to
Import, and then click MSI file.
2. In the Import MSI Wizard, type C:\AllFiles\LabFiles\Module 3\Module3.msi in the
MSI file to import box, and then click Next.
3. On the Application Settings page, ensure that the Application name is set to Module
3, select the Overwrite resources check box, and then click Next.
6. 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.
Selecting this check box will start the MSI installation. If you do not select this
check box, you must manually execute the Module3.msi file.
Install the BizTalk MSI
Procedure List
1. On the Select Installation Folder page of the Module 3 window, click Next.
2. On the Welcome to the Module 3 Setup Wizard page, click Next.
4. On the Module 3 Information page, click Next.
Exercise 3: Start and Test the BizTalk Application
Overview
In this exercise, you will start and test the BizTalk Server application.
Start the BizTalk Application
Procedure List
1. In the BizTalk Server Administration Console, notice that the Module 3 application
has been added to the list of applications.
2. In the left pane, click Applications, and then notice the red “stopped” icon next to
the Module 3 application.
3. Expand the Module 3 application.
4. Click Policies, right-click DiscountPolicy, click Deploy, and then in the Deploy Policy
dialog box, click Yes.
Deploying a business rule such as this one allows the BRE to evaluate business
rules based on calls from orchestrations. The DiscountPolicy business policy is
made up of several rules pertaining to company names and total order amounts.
These rules, which are described in Lab 1, apply different discounts to orders
based on the total order amount and the company placing the order.
5. Click Schemas and then notice the five schemas in this application.
Schemas define the structure of XML messages. BizTalk Server uses schemas to
ensure that data being sent to BizTalk Server is in the correct structure and has
all the information that BizTalk Server needs to process the document. This
particular application supports five different schemas.
6. Click Maps, and then notice the three maps in this application.
BizTalk Server uses maps to translate and transform data from one format to
another. For example, data might be received by BizTalk Server in a flat-file
format. BizTalk Server can use a map to transform that data from a flat-file
format to XML for further processing.
7. Click Resources, and then notice the OrderManagement assembly—this is the only
assembly in this application.
Assemblies in BizTalk Server are built and compiled by the BizTalk developer, and
they contain BizTalk artifacts such as schemas and maps. Any BizTalk artifacts
must be contained in an assembly before they can be used by BizTalk Server. In
BizTalk Server, an assembly is compiled as a DLL.
8. Click Receive Ports, and then notice that the MSI package includes two receive
ports: RcvPO, and RcvPOReview.
Receive ports pick up messages for BizTalk Server to process.
9. Click Receive Locations, and then notice that the RcvPOFILE and RcvPOReviewFILE
receive locations are also included in the MSI package.
Receive locations specify information such as the physical file location, the
adapter used, and the BizTalk Server host used to pick up messages that BizTalk
Server processes. In this example, both receive locations are using the FILE
adapter type and will poll a specific directory for messages with a file extension
of .xml.
10. Click Send Ports and then notice the five send ports that are included in the MSI
package.
Send ports specify the destination of a message after being processed by BizTalk
Server. Send ports allow you to specify settings such as the adapter type, the
location to send the message to, and any maps used to transform the message
before exiting BizTalk Server.
11. Click Orchestrations, and then notice the two orchestrations listed.
Orchestrations are used for more complex processing of messages inside BizTalk
Server. Orchestrations are automated business processes that can perform
actions such as calling business rules and making calls to Web services.
12. Right-click Module 3 and then click Start.
You must start an application before it will process messages.
13. In the Start ‘Module 3’ Application dialog box, click Options, ensure that all the
check boxes are selected, and then click Start.
Starting an application in this fashion will by default try to start all send ports,
orchestrations, and host instances, as well as enable all receive ports and resume
suspended service instances. If you need to, each port/location, orchestration, or
host can be started or stopped individually.
14. In the left pane, click Applications and then notice that the red “stopped” icon in the
right pane has been replaced with the green “running” icon.
There is another application status icon, the blue “partially started” icon, which
means that at least one port, location, orchestration, or host is not running.
Test the BizTalk Application
Procedure List
2. Copy the ContosoPO_Large.xml, ContosoPO_Medium.xml, and
ContosoPO_Small.xml files to the POIn folder.
Do not move the messages. After the messages have been processed by BizTalk,
the original files are not retrievable. If you do accidentally move the messages,
additional copies can be found at C:\AllFiles\LabFiles\Module
3\Messages\MessageCopies.
3. After the messages disappear from the POIn folder, navigate to
C:\AllFiles\LabFiles\Module 3\Messages\Completed, and then notice the two
POAck{GUID}.xml messages.
It might take up 2 minutes for the messages to appear. Any messages in this
folder have been approved, and a new field—AckCode—has been added, stating
the discount amount.
4. Navigate to C:\AllFiles\LabFiles\Module 3\Messages\POReviewOut.
Only orders that do not meet the minimum purchase order amount are routed to
this folder.
5. Move the {GUID}.xml file from the POReviewOut folder to
C:\AllFiles\LabFiles\Module 3\Messages\POReviewIn.
Moving the file to this location represents approving the order.
6. Navigate to C:\AllFiles\LabFiles\Module 3\Messages\Completed and notice that
another POAck{GUID}.xml file is displayed.
This is the message that was manually approved in step 5 when you moved the
order to POReviewIn.
7. Delete the three messages in the Completed folder.
8. Navigate to the C:\AllFiles\LabFiles\Module 3\Messages\Shipped folder.
These messages contain shipping information for each approved purchase order.
9. Delete the three messages in the Shipped folder.
10. Do not shut down the virtual machine without saving your changes. The
configuration you performed in this lab is required for the next lab.
Lesson 3: Deploying Business Rules
Lesson objective:
Explain how business rules are composed managed and implemented into a BizTalk Server
application.
Overview
The BizTalk Server Business Rule Engine (BRE) enables business users to create policies that
contain rule sets for processing documents. The policies can be called from BizTalk
orchestrations as well as from an application programming interface (API).
What are Business Rules?
Explain what business rules are and how the Business Rule Engine works.
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 consist of several different rules that need to be evaluated. The policy is
executed, and each rule is evaluated and 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 quite complex. The condition is evaluated, and
if it evaluates to True, the specified actions are asserted by the Business Rule Engine. Unlike
most programming models, there is no else clause in the Business Rule Engine. 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 less then $1,000, and one for purchase orders with totals greater than or equal to
$1,000. These two rules would make up the discount policy, which is what is called (not the
individual rules).
Business Rule Engine
Because 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 by using the Business Rule Composer, or they
can be written using the business rule APIs. After it is 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, and any orchestrations
that use business rules do not need to be recoded or rebuilt when a business rule 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.
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 lesson is 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.
Example
Consider the 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.
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 manufacturer? 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 more 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 that each question can be answered either True or False. These rules apply basic
business logic to determine whether a purchase order can be fulfilled.
Business rules can be used to:

Trigger notifications. For example, if a product is low in 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.
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 or False
expressions, 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.
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.
When called programmatically, the version of the policy is specified. Once published, a
business rule policy is immutable and can only be changed 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 one field in one record in a single 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 the
creation of a vocabulary definition.
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 Server group. Additionally, policies and vocabularies can be exported to an XML store
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.
Conditions
A condition is a True or 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.
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 Business Rule Engine through predefined vocabularies,
XML schemas, .NET classes, and 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 purchase order message. Other facts might be long term—for example, interest
rates usually change infrequently and do not need to be rechecked each time a rule is fired.
Long-term facts are determined once and then held in cache until refreshed, whereas
instance facts are determined for each rule execution.
Business Rule Vocabulary
Describe how business rule vocabularies work.
Creating a Vocabulary
The Business Rule Framework gives you the option of creating vocabularies to simplify the
development of rules by offering users intuitive, language-specific, and domain-specific
terminology that they can associate with rule conditions and actions.
You can identify the data sources to be used, create a new vocabulary, and add vocabulary
definitions to the BRE. You can save a version of your vocabulary to the rule store, and when
the vocabulary is complete, you can publish it to provide users with a well-defined,
immutable set of terms that are bound to the appropriate data references.
The rules are created (or modified) to use the terms defined within a specific vocabulary. If
the vocabulary changes, the rule will need to updated (and republished) to take advantage
of the changes. In BizTalk Server 2010, applications are BRE policy aware. When applications
are exported and imported, the policies and vocabularies that are deployed are part of the
MSI package that is generated, thereby making the process of synchronizing rules easier.
New Vocabulary Versions
Like business rule policies, vocabulary versions are also immutable. If you want to make
changes to your vocabulary after you publish it, you must create a new version of the
vocabulary that reflects the changes. Also any policies that use these vocabularies will need
to be updated with the changes.
Example
In the example in the preceding illustration, ShoppingCartAmount has been created as a
vocabulary definition that represents the
Company.Namespace.ShoppingCart.PurchaseAmount node in a schema. The term
ShoppingCartAmount is much more human readable than the node in a schema it
represents. These vocabularies (generally created by developers) are easier for
administrators and business analysts to understand than having to learn complex XML and
Transact-SQL.
The business rule is easy to read and interpret, and if a change is needed for the business
rule, a business analyst or an administrator could use the Business Rule Composer to make
the change. If the discount amount changes from 10 percent to 15 percent, you could copy
the old rule into a new version of a policy, and simply change the discount amount from 10
to 15. No recompiling or redeploying of orchestrations is necessary.
We will be referring to this example rule in subsequent topics.
Business Rule Orchestration Scenarios
Identify scenarios where calling the BRE from an orchestration is appropriate
Overview
You can integrate business rules into your orchestrations to support a variety of 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 BRE and
thus allow information workers to update the rules instead.

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 determine whether the item is in stock. After initially
checking the stock of an item that is not available, the rule delay would be 1 minute.
The next time, the rule would wait 5 minutes before executing; the time after that,
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 a customer does
not exist for a particular purchase order, 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

Create vocabularies to make it easier for information workers to edit and
understand business rule policies.

Create the initial business rule policies.

Bind business logic to data. Developers create the orchestrations from which the
business rules will be called and 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.
Information Workers

Manage business policies in real time. 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

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 BRE administrator have both
read/execute and modify/delete access. The BRE 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 by using the MSI process defined earlier in this module.

Monitor the results of executed business rules by using BizTalk Administration
Console. This tool allows auditing of the rules based on decisions made within each
orchestration instance.
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 that will contain one or more business rules. These rules can evaluate facts to
determine whether specific actions should be performed. To assist in making these rules
human readable, 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 by using the Business Rule Composer to make management of
these artifacts easier.
Creating a Business Rule Policy
A policy is a collection of rules. Each rule is a conditional comparison of facts; if the
comparison evaluates to True, the actions defined in the rule are executed. Rules are
constructed in the Business Rule Composer by adding predicates and facts (which can be
direct facts or can 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 to the Business Rule Composer design surface.
Actions will update nodes in the document specified. This is one notable exception to the
immutability of messages in BizTalk orchestrations. The BRE makes changes to the message
that is passed during the call to the engine. For this reason, you might want to create a
specific message that is sent to the engine, rather than having the BRE change the original
message.
Creating a Business Rule Vocabulary
Earlier, you saw an example of a rule that said:
If the Shopping Cart contains more then $1,000 worth of items, give the customer a
10% 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 1,000. 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 Visual Basic, this looks like:
If
Company.Namespace.ShoppingCart.PurchaseAmount > Qualifying
Amount
as System.Decimal
Then
Company.Namespace.Customer.DisocuntAmount =
Company.Namespace.ShoppingCart.PurchaseAmount * .1
EndIf
You need to create a vocabulary that takes an obscure concept and makes it more human
readable. This is the purpose for creating vocabularies.
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 If the Shopping Cart contains more than $ 1,000 worth of
items is actually a greater than comparison (Shopping Cart > 1,000). The built-in Greater
Than function in the Functions vocabulary could have an additional vocabulary term defined
that represents this relationship, which might make it easier for information workers to
understand the relationship.
Testing and Publishing
When a version of a policy is defined to the business analyst’s satisfaction, the policy should
be tested. This should be done prior to publishing. It will be necessary to provide sample
messages and database connections on which the policy is to be performed.
The act of publishing the policy to the rule store makes the policy available to the BRE. By
default, the BRE uses a Microsoft 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.
Deploying Business Rules
Deploy a business rule.
Overview
After a policy is published, it must be deployed before it can be used by external processes.
The shortcut menu in the Business Rule Composer includes an option to deploy the policy.
The Rule Engine Deployment Wizard, found on the Microsoft BizTalk Server 2010 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.
The Rule Engine Deployment Wizard allows you to:

Export a version of a policy or vocabulary from an SQL rule store into a file rule store.
This creates an XML file containing 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 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 from a 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 Business Rule
Engine database but cannot be used by other applications.
Demonstration: Using Business Rules
In this demonstration, you will see how to examine and test a deployed business rule policy.
To Examine Existing Business Rules
and then click Business Rule Composer.
2. In Microsoft Business Rule Composer, in the Policy Explorer pane, expand
DiscountPolicy and Version 1.0 – Deployed.
3. In then Facts Explorer pane, under MyVocabulary, 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.
4. Click Current Order Total.
The Current Order Total definition refers to the Amount node of the message
when it is received into the Business Rules Engine (BRE). This value is from
PurchaseOrderAck.xsd, which you can see by examining the Schema and
XPathField properties in the Properties dialog box.
5. Click Customer Name.
The Customer Name definition refers to the Name node of the message. This
value is also derived from the Name XPath field in PurchaseOrderAck.xsd.
6. Click Discounted total.
The Discounted total definition has a multiplication function built in. This
definition will update the Amount node with the product of the two variables
specified within the function.
7. Click Set AckCode.
The vocabulary definition Set AckCode refers to the AckCode node in the
PurchaseOrderAck schema. By using these vocabularies, it is possible to create
user-readable (and manageable) rules in plain business language.
8. In Policy Explorer, click Small Order Contoso (5% disc).
The Conditions pane shows that this rule will be applied when Customer Name is
equal to Conto, and current order total is less than or equal to 10,000. The
Actions pane shows that two events will occur when the conditions are met:
AckCode will be changed to 5% discount applied, and amount will be changed to
the current order total multiplied by 0.95.
9. Click Large Order Contoso (10% disc).
This rule is similar to the previous rule with two exceptions: if the current order
total is greater than 10,000, the action will be to change AckCode to 10%
discount applied and the current order total will be discounted by 10 percent.
10. Click Large Order Non-Contoso (5% disc).
This rule uses the same actions as the Small Order Contoso rule, but the
conditions state that if the customer name is not Conto and the total order
amount is greater than 10,000, the discount is applied.
To Test the Business Rule Policy
1. In Windows Explorer, navigate to C:\AllFiles\DemoCode\Module3 and open
BRETestMessage.xml.
Notice that AckCode equals Accepted, the CustomerName equals Fabrik, and
that Summary Amount equals 10500.
2. In Policy Explorer, right-click Version 1.0 – Deployed, and then click Test Policy.
3. In the Select Facts dialog box, click OrderManagement.PurchaseOrderAck, and then
click the Add instance button.
4. In the Open dialog box, navigate to C:\AllFiles\DemoCode\Module3, select
BRETestMessage.xml, and then click Open.
5. In the Select Facts dialog box, click Test.
6. In the Output pane, select the first three FACT ACTIVITY processes. Notice that the
Operation property is Assert.
This is where the facts that will be used to evaluate the first rule condition or
conditions are added to the facts list.
7. Select the first two CONDITION EVALUATION TEST (MATCH) processes. Notice the
Test Expression and Operand values.
This step performs the conditional test to determine whether the value in the
message that was passed is less than or greater than 10,000.
8. Select the next FACT ACTIVITY process.
Because the second condition in the preceding step is true, a new fact
(Customer) is asserted to be used in the next two CONDITION EVALUATION
processes.
9. Select the next two CONDITION EVALUATION TEST (MATCH) processes. Notice the
Test Expression and Operand values.
This step performs a conditional test to determine whether the company name is
Conto.
10. Select the AGENDA UPDATE and the RULE FIRED processes.
The AGENDA UPDATE step adds an action item to update the AckCode to apply a
5% discount. RULE FIRED steps execute the action items that have been included
in the agenda.
11. Select the remaining FACT ACTIVITY processes. Notice that the Operation property
is Retract.
This is where all of the facts which were previously asserted are being retracted
as they are no longer needed. Our test is quite simple, but additional facts can be
asserted, or retracted at any time to assist in the decision process.
12. In Windows Explorer, navigate to and open
C:\AllFiles\DemoCode\Module3\BRETestMessage.xml, and notice that AckCode
now reads 5% discount applied.
Scenario
The Module 3 application uses a BRE policy to calculate a discount amount for the purchase
orders based on the customer name and total order amount. In this lab, you will create a
new rule that will provide a 2 percent discount to all orders that do not meet the criteria for
any other discounts. After you have composed and tested the rule in the Business Rule
Composer, you will deploy and test it within the application.
Preparation
You must have successfully completed the previous lab before starting this lab.
Exercise 1: Create a New Business Rule
Overview
In this exercise, you will create a new version of the DiscountPolicy business rule policy, and
then add a new rule to the policy.
Create a New Version of the DiscountPolicy Business Rule Policy
Procedure List
then click Business Rule Composer.
3. In the Open Rule Store dialog box, click OK.
4. Under DiscountPolicy, expand Version 1.0 – Deployed.
5. Right-click DiscountPolicy in Policy Explorer, and then click Add New Version.
After a version of a business rule has been published, the rule cannot be
changed. However, you can create a new version of a rule and copy and paste
from other policies that have been published and deployed.
6. Drag the Large Order Contoso (10% disc) rule to Version 1.1 (not saved).
7. Drag the Large Order Non-Contoso (5% disc) rule to Version 1.1 (not saved).
8. Drag the Small Order Contoso (5% disc) rule to Version 1.1 (not saved).
Create the Small Order Non-Contoso (2% disc) Business Rule
Procedure List
1. Right-click Version 1.1 (not saved) in Policy Explorer, and then click Add New Rule.
2. Name the rule Small Order Non-Contoso (2% disc).
3. In the IF pane, right-click Conditions, and then click Add logical AND.
4. Right-click AND, point to Predicates, and then click NotEqual.
5. In Facts Explorer, expand Version 1.0 – Published under MyVocabulary.
6. Drag Customer Name from the Vocabularies tab to argument1.
7. Click argument2, and then type Conto in the text box.
8. Right-click AND, point to Predicates, and then click LessThanEqual.
9. Drag Current Order Total from the Vocabularies tab in the Facts Explorer pane to
argument1.
Current Order Total has been created for you by a BizTalk developer to make
your rules easier to understand. This value originates from the Amount field of
the PurchaseOrderAck schema.
10. Click argument2, and then type 10000 in the text box.
11. Drag Set AckCode from the Vocabularies tab in the Facts Explorer pane to Actions in
the THEN pane.
12. Click <empty string>, and then type 2% discount applied.
13. Drag Discounted total from the Facts Explorer pane to Actions in the THEN pane.
14. Right-click 0, point to Functions, and then click Multiply.
15. Drag Current Order Total from the Facts Explorer pane to value1.
16. Click value2, and then type 0.98.
Here you are applying the 2 percent discount to non-Contoso orders that have a
total order amount less than or equal to $10,000.
Exercise 2: Deploy and Test the New Policy
Overview
Publishing the policy makes the policy immutable, and deploying the policy makes it
available for other applications to use. BizTalk Server uses the latest deployed version of
each business rule engine policy. In this exercise, you will deploy a new version of the
DiscountPolicy and then test it by using the BizTalk Server application.
Deploy Version 1.1 of the DiscountPolicy Business Rule Policy
Procedure List
1. In Policy Explorer, right-click Version 1.1 (not saved), and then click Save.
2. Right-click Version 1.1 in Policy Explorer, and then click Publish.
3. Right-click Version 1.1 in Policy Explorer, and then click Deploy.
Test the New Policy Version
Procedure List
2. Open ContosoPO_Large.xml, notice that the customer name is Conto, and then
close Internet Explorer.
The total order amount of this order is 10300.
3. Open FabrikamPO_Large.xml, notice that the customer name is Fabrik, and then
4. Copy ContosoPO_Large.xml and FabrikamPO_Large.xml to the
C:\AllFiles\LabFiles\Messages\POIn folder.
5. Navigate to C:\AllFiles\LabFiles\Module 3\Messages\Completed, notice the two
6. Open both POAck{GUID}.xml messages.
Notice that the message with a customer name of Fabrik has 5% discount
applied in the AckCode field, and that the message with Conto as the customer
name has 10% discount applied in the AckCode field.
7. Close Internet Explorer, and then delete all the messages in the Completed folder.
9. Open FabrikamPO_Medium.xml. Notice that the total order amount will equal 1030
and that the customer name is Fabrik, and then close Internet Explorer.
10. Copy FabrikamPO_Medium.xml to the POIn folder.
11. Navigate to C:\AllFiles\LabFiles\Module 3\Messages\Completed, and then open
the POAck{GUID}.xml message. Notice that the customer name is Fabrik and that
the AckCode field contains the text 2% discount applied.
12. Close Internet Explorer, and then delete the message from the Completed folder.
14. Open the ContosoPO_Small.xml file, notice that the customer name is Conto and
that the total order amount will equal 526, and then close Internet Explorer.
15. Copy ContosoPO_Small.xml to the POIn folder.
This folder simulates a more advanced process of manually approving the order.
17. Move the {GUID}.xml files to C:\AllFiles\LabFiles\Module
3\Messages\POReviewIn. Moving the message to this folder represents approving
the order.
18. Navigate to C:\AllFiles\LabFiles\Module 3\Messages\Completed.
19. Open the POAck{GUID}.xml file.
20. Notice that the customer name is Conto and that the AckCode field contains the
text 5% discount applied.
Module objective:
How to manage Microsoft BizTalk Server applications by using administrative tools and
command-line scripts.
Overview
After you have installed and configured Microsoft BizTalk Server 2010 in a production
environment, and have deployed BizTalk applications to one or more computers running
BizTalk Server, a number of ongoing administration tasks need to be performed regularly.
This module will cover the administration tasks that need to be performed on a day-to-day
basis.
Lesson 1: Administering a BizTalk Server Application
Lesson objective:
In this lesson you will learn how to:
Describe the BizTalk application environment, and identify components that must be configured
to support message processing, including managing and binding ports and locations, and
managing applications by using the Group Hub.
Overview
BizTalk Server 2010 provides a number of administrative tools for managing your BizTalk
Server environment. Before you can effectively manage or administer a BizTalk Server
environment, you will need a good understanding of the BizTalk components that must be
configured to support specific application requirements. This lesson provides an overview of
application messaging functions and components and the tools required to manage them.
What Are Physical Ports and Logical Ports?
Explain the differences between physical and logical ports
What Is a Port?
BizTalk Server uses the term port to refer to two distinct entities:
Physical ports. Used by BizTalk Server to communicate with external systems. Physical ports
are used to receive and send messages between BizTalk Server and the outside world.
Physical ports are configured and managed by using the BizTalk Server Administration
Console or by using scripts.
Logical ports. Also called orchestration ports, logical ports are internal to a specific
orchestration and are used within BizTalk to pass messages in and out of a BizTalk
orchestration. Logical ports are configured by developers by using the Orchestration
Designer in Microsoft Visual Studio® 2010.
Port Types
Ports, whether physical or logical, can be either one-way or two-way. As their name implies,
one-way ports provide communication in one direction only—for example, when sending a
purchase order. Two-way ports are used for synchronous communication, where a request is
sent and a response is required before processing can continue.
BizTalk Messaging Example
Here is an example of how messages are passed through BizTalk messaging and
orchestration services:
1. A message—for example, a purchase order—is received by a physical receive port,
which has an associated receive location. This receive location will be of a specific
type representing the protocol and transport used—for example, Hypertext Transfer
Protocol (HTTP), File Transfer Protocol (FTP), Microsoft SQL Server™ database, file
drop, and so on.
2. The purchase order is passed through the receive location and any associated
pipelines and is published in the MessageBox database as Extensible Markup
Language (XML).
3. The purchase order is processed by a subscribing orchestration and passed to the
logical receive port within the orchestration that processes the message.
4. A new purchase order acknowledgment message (POAck) is generated, and the
POAck is passed back to the MessageBox database through the logical send port.
5. A subscribing physical send port retrieves the POAck message from the MessageBox
and passes it through an associated send pipeline.
6. The message is then sent to its destination.
Note: There is an association between the logical ports and physical ports referred to as a
binding. Bindings will be discussed in detail later in this module.
Managing Receive Ports and Locations
Explain the relationship between receive ports and receive locations.
Receive Ports
A receive port is a container for one or more receive locations. Receive locations define the
various protocols and processes used to receive a message. For example, different
customers might need to send purchase orders by using methods such as e-mail or FTP, or
through an HTTP location. Each receive location would then be configured to support the
specific protocol or transport method required to support the customer.
Managing Receive Ports
Receive ports can be created by using command-line tools, Microsoft Windows®
Management Instrumentation (WMI) scripts, and the BizTalk Server Administration Console.
(Developers can also create receive ports by using Visual Studio 2010.) A receive port
contains configuration information for authentication and tracking, optionally ports can be
configured with one or more maps for transforming documents.
Receive Locations
A receive location is the combination of a specific address where inbound messages arrive
and the messaging pipeline processes the messages. Receive locations are created in the
BizTalk Server Administration Console and are associated with a single receive port. Receive
locations have both adapter-specific properties and common properties—for example, an
FTP adapter has properties such as the firewall port and password that the FILE adapter does
not require. When naming the receive location, it is typical to use the name of the port with
which the location is associated with the protocol appended—for example,
PurchaseOrderFTP.
For each adapter that is supported by BizTalk, global properties can, and in some cases must,
be configured. For example, the SMTP adapter and MQSeries adapter have a Server
property which identifies which server the adapter is to communicate with. In the case of
the SMTP adapter, this global property is optional because it can be set on a per-instance
basis, whereas the Server property is required for the MQSeries adapter.
Receive Location States
Receive locations can be in one of two states, which can be set through the BizTalk Server
Administration Console:

Enabled. You enable a receive location to start receiving messages. With most
receive locations, such as file receive locations, messages that arrive while the port
is disabled will simply wait for the port to be enabled before the message will be
processed.

Disabled. You disable a receive location if you want to prevent it from receiving
messages or if you want to delete the receive location. If an error occurs while a
receive location is listening for messages at a specific address and BizTalk uses all
retry attempts, BizTalk will disable the receive location automatically. Receive
locations are disabled by default.
For more information about receive locations and configuring properties of specific receive
location types, refer to “About Receive Locations” in the BizTalk Server documentation.
Managing Send Ports and Send Port Groups
Create and manage send ports and send port groups.
Send Ports
Send ports are the endpoints to which BizTalk Server sends messages. Like receive ports,
send ports have two communications patterns: one-way and two-way, referred to as solicitresponse. Solicit-response ports are used by BizTalk Server (principally through
orchestrations) to consume external resources. Two-way send ports are used for Web
service invocation and SQL adapter queries, among other uses.
Static vs. Dynamic Ports
In addition to being one-way or two-way, send ports can be either static (which is most
common), dynamic (which is generally more powerful), or direct (which must be configured
within the orchestration itself):

Static send ports. These send ports contain a fixed destination address. When you
create a static send port, you specify the adapter type, destination address (Uniform
Resource Identifier, or URI), and pipeline used for the static send port.

Dynamic send ports. Dynamic ports are addressed in the developer documentation
because their dynamic nature is available only from orchestrations. By using
dynamic ports, which do not contain a fixed destination, a decision can be made by
the orchestration at run time as to how the port is to be configured. For example,
some vendors might choose to receive catalog updates from your company by email, whereas others would like to receive updates by means of FTP. With a dynamic
send port, a decision can be made within the orchestration (possibly through a call
to the Business Rule Engine or BRE) as to how the port should be configured for each
instance of the orchestration.

Direct send ports are send ports which are bound to a specific end-point specified in
an orchestration. This binding can only be changed within the orchestration.
Send ports can be created by using the BizTalk Server Administration Console or by using
WMI scripts. Also when importing binding files or importing from MSI packages, ports are
created automatically.
Send Port Groups
A send port group is a named collection of send ports that you can use to send the same
message to multiple destinations in a single configuration. Send port groups are useful when
you need to send a message from a specific business process to multiple physical locations.
For example, you might need to submit a confirmation message for 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.
Send Port States
Once created, send ports will not begin processing messages until a subscription is created.
In BizTalk Server, subscriptions are created by enlisting send ports. Send ports have three
possible states indicating whether a subscription exists and whether the port will actively
process messages:

Bound. Send ports or send port groups that are fully configured but do not have any
subscriptions are considered Bound. When send ports are in the bound state, they
are ready to be enlisted and started. Fully configured ports are have been assigned a
pipeline, are associated with a BizTalk Host, and have been bound to an
orchestration’s logical port. Messages will not be queued or processed until the port
is enabled. Clicking Unenlist on the shortcut menu for stopped or started ports will
change the state to bound.

Stopped. Enabling a bound send port or stopping a started send port will switch the
port to the Stopped state. 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 host where the send handler is running. If the send port or send port
group was previously started, processing continues in the work queue; however, no
new messages begin processing. Clicking Enlist or Stop (depending on the initial
state) will switch the port to this state.

Started. When a send port is in the started state, the subscription for this send port
exists and is active. When the port is in this state, messages are delivered and
processed by the send port. Starting a send port implies enlisting the port as well.
Demonstration: Configuring Ports and Receive Locations
In this demonstration, you will see how to use the BizTalk Server Administration Console to
create and configure multiple receive ports, receive locations, send ports, and a send port group.
You will also see how to import a binding file to create ports.
This demonstration can be a little long. If in the interest of time you do not want to create all
the ports manually, the DemoABindings binding file will create all the required ports for you.
If you turned off the demonstration virtual PC without saving changes after completing
Module 3 you will need to perform the following before continuing with these
demonstrations. Remove the versions 1.0.0.0 and 2.0.0.0 of the OrderManagement
assembly from the Module3 application, and then move the version 4.0.0.0
OrderManagement assembly from the Module3 application to the Module4 application.
To Create Two Receive Ports
BizTalk Group, Applications, Module4, and then click Receive Ports.
3. Right-click Receive Ports, point to New, and then click One-way Receive Port.
4. In the Receive Port Properties dialog box, change the Name to PurchaseOrders, and
then click OK.
6. In the Receive Port Properties dialog box, change the Name to
ReviewPurchaseOrders, and then click OK.
To Create Two Receive Locations
1. In the BizTalk Server Administration Console, right-click Receive Locations, point to
New, and then click One-way Receive Location.
2. In the Select a Receive Port dialog box, click PurchaseOrders, and then click OK.
3. In the Receive Location Properties dialog box, change the name to
PurchaseOrdersFILE, click FILE in the Type list, and then click Configure.
4. In the FILE Transport Properties dialog box, click Browse.
5. In the Browse For Folder dialog box, browse to
C:\AllFiles\DemoCode\Module4\Messages, click POIn, and then click OK.
6. In the FILE Transport Properties dialog box, click OK.
7. In the Receive Location Properties dialog box, click XMLReceive in the Receive
pipeline list, and then click OK.
8. In the BizTalk Server Administration Console, right-click Receive Locations, point to
New, and then click One-way Receive Location.
9. In the Select a Receive Port dialog box, click ReviewPurchaseOrders, and then click
OK.
10. In the Receive Location Properties dialog box, change the name to
ReviewPurchaseOrdersFILE, click FILE in the Type list, and then click Configure.
C:\AllFiles\DemoCode\Module4\Messages, click POReviewIN, and then click OK.
14. In the Receive Location Properties dialog box, click XMLReceive in the Receive
To Create Three Send Ports
1. In the BizTalk Server Administration Console, right-click Send Ports, point to New,
and then click Static One-way Send Port.
2. In the Send Port Properties dialog box, change the name to ToAccountingFILE, click
FILE in the Type list, and then click Configure.
This port will be used to send an acknowledgment to the accounting department.
C:\AllFiles\DemoCode\Module4\Messages, click POAckOUT, and then click OK.
5. In the FILE Transport Properties dialog box, change the File name to
AccountingACK%MessageID%.xml, and then click OK.
6. In the Send Port Properties dialog box, click PassThruTransmit in the Send pipeline
list, and then click OK.
For better performance, use the PassThruTransmit Pipeline when send pipeline
processing is not required.
8. In the Send Port Properties dialog box, change the name to ToCustomerFILE, click
FILE in the Type list, and then click Configure.
This port will be used to send an acknowledgment to the customer.
10. In the Browse For Folder dialog box, browse to C:\AllFiles\DemoCode\
Module4\Messages, click POAckOUT, and then click OK.
CustomerACK%MessageID%.xml, and then click OK.
14. In the Send Port Properties dialog box, change the name to ToSalesManagerFILE,
click FILE in the Type list, and then click Configure.
This port will be used to send an acknowledgment to the sales manager.
16. In the Browse For Folder dialog box, browse to C:\AllFiles\DemoCode\
Module4\Messages, click POAckOUT, and then click OK.
SalesManagerACK%MessageID%.xml, and then click OK.
To 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, change the Name to
PurchaseOrderACK.
3. In the Send ports section, click ToAccountingFILE, ToCustomerFILE, and
ToSalesManagerFILE in the Name list, and then click OK.
To Import Port Bindings by Using a Binding File
1. In the BizTalk Server Administration Console, right-click the Module4 application,
point to Import, and then click Bindings.
2. In the Import Bindings dialog box, navigate to C:\AllFiles\DemoCode\Module4, and
then double-click DemoABindings.xml.
3. In the left pane of the BizTalk Server Administration Console, click Send Ports, and
then notice that three new send ports (ToErrorFILE, ToShipNoticeFILE, and
ToPOReviewFILE) have been created.
What Is Port Binding?
Describe port bindings and export and import port bindings.
Port Bindings
Port bindings specify the entry points into a BizTalk application and are most often used to
associate logical ports in an orchestration with physical ports. The port binding contains
configuration information that specifies where and how a message is to be sent or from
where it is received.
You can bind logical send ports to physical send ports and logical receive ports to physical
receive ports. Port bindings must be used when developers use the Specify Later port
binding option in the Orchestration Designer. Developers typically choose the Specify Later
option because only the port type that describes the port must be specified. Administrators
can then specify the actual port location separately from the logical flow of the message
after the application has been deployed.
Exporting and Importing Binding Information
After the port bindings have been configured, the binding information can be exported to an
XML file and later imported into another environment. Because the binding file is written in
XML, it is easy to read and edit the XML if a simple change in the configuration needs to be
made. Options for exporting binding files include:

Export all bindings from the current application. Choose this option if you want to
save the binding information for all orchestrations and ports in the selected
application.

Export all bindings from the current group. Choose this option to export all the port
bindings for the BizTalk group which you are connected to.

Export bindings for the selected assembly. Choose this option to export bindings for
orchestrations in a specific assembly and select the assembly for which you want to
export bindings. This option is only enabled if there is at least one assembly
registered within the current application.
Using MSI files to export applications results in the binding information being included in the
MSI package. It is not necessary to perform export or import bindings if you create an MSI
package to deploy an application.
BizTalk protects passwords in exported binding files. Whenever a file containing a password
is exported from BizTalk, the password node is included with the substitution value
***Hidden***. Before the file can be imported, it is necessary to supply the correct
password for the account specified.
Managing Orchestrations
Manage the processing state of a BizTalk orchestration.
Overview
Both orchestrations and send ports have similar states and require similar actions for
changing the state of a port or orchestration. Once an assembly containing an orchestration
has been deployed to the BizTalk Configuration database and its ports have been bound to
physical send and receive ports, you can enlist the orchestration and then start it so that it
can begin to process messages.
Orchestration States
You can use either the BizTalk Server Administration Console or WMI to enlist, start, stop,
and unenlist orchestrations. The states of an orchestration include:

Unbound. When an orchestration is in this state, the orchestration is deployed to the
Configuration database but is not bound to ports. Orchestrations with missing
binding information will remain in this state.

Bound. Orchestrations in this state are bound to all required ports, and the
orchestration is ready to be enlisted.

Started. In this state, an orchestration is running and is able to create new instances.

Stopped. Enlisting a bound orchestration or stopping a started orchestration results
in a stopped state. In this state, the subscription exists and messages are being
queued for processing; however, the orchestration is not actively processing new
messages. If the orchestration had been previously started and is currently
processing messages, processing continues in the work queue; however, no new
orchestration instances will start.

Stopping. When an orchestration is stopping, it is attempting to stop but dependent
processes are not yet complete.
Enlisting Actions
The actions that can be invoked to change the state of an orchestration are Enlist, Start,
Stop, and Unenlist. The actions associated with orchestrations are similar in function to the
actions of send ports and send port groups.
Demonstration: Binding an Orchestration
In this demonstration, you will see how to use the BizTalk Server Administration Console to
configure orchestration hosts, bind orchestration ports, and start and then test a BizTalk server
application.
To Bind the Application
1. In the BizTalk Server Administration Console, right-click Module4, and then click
Configure.
2. In the Configure Application dialog box, under Orchestrations, click
orchCalculateShipping.
3. Select BizTalkServerApplication in the Host list.
4. In the Configure Application dialog box, under Orchestrations, click
OrchProcessOrder.
5. Select BizTalkServerApplication in the Host list.
6. Bind the logical ports to the physical ports as shown in the following table.
Inbound logical ports
Receive ports
RcvPO
PurchaseOrders
RcvPOReview
ReviewPurchaseOrders
Outbound logical ports
Send ports/send port groups
SndPOReview
ToPOReviewFILE
SndError
ToErrorFile
SndShipNotice
ToShipNoticeFILE
SndFinalPOAck
PurchaseOrderACK
PurchaseOrderACK is a send port group that includes the ToAccountingFILE,
ToCustomerFILE, and ToSalesManageFILE send ports. This means that the
message being sent out of the orchestration will be processed by all three of
these ports.
7. Click OK.
Procedure List
To Start the Application
1. In the BizTalk Server Administration Console, right-click the Module4 application,
and then click Start.
2. In the Start ‘Module 4’ Application dialog box, click Start.
3. In the left pane of the BizTalk Server Administration Console, click Module4.
4. Notice that the Module4 icon at the top of the center pane contains a green arrow.
To Test the Application
1. In Windows Explorer, navigate to C:\AllFiles\DemoCode\Module4\Messages, and
then open the ContosoPO_Large.xml file.
2. Copy ContosoPO_Large.xml to the POIn folder; wait for the message to disappear.
Be sure to copy the files. After the file is processed by BizTalk, the original
message will not be retrievable.
3. Navigate to the ShipNoticeOUT folder, and then open the {GUID}.xml message.
Notice that a Shipment node has been added to the message and that Amount
equals 10300.
4. Close Internet Explorer.
5. In Windows Explorer, navigate to the POAckOUT folder, and notice the three
acknowledgment messages.
The orchestration uses the PurchaseOrderACK send port group, which sends the
single outgoing message through the three send ports making these
acknowledgments.
6. Open the AccountingACK{GUID}.xml message.
7. Close Microsoft Internet Explorer®.
8. Delete all the messages from the POAckOUT and ShipNoticeOUT folders, and then
close all open windows.
Scenario
In previous labs, all send and receive ports were provided for you. In this lab, you will create
send and receive ports. After you have created the physical ports, you will bind them to the
orchestration, and then submit several purchase orders to the BizTalk Server application to
see whether the purchase orders are successfully processed.
Procedure List
window.
Start.
Procedure List
Procedure List
Exercise 1: Create Receive Ports and Locations
Overview
BizTalk Server receive ports can have one or more receive location. In this exercise, you will
use BizTalk Server Administration Console to create a receive port with a single receive
location that uses the FILE adapter to process purchase orders from a directory. You will
then create and configure another receive port and a POP3 receive location.
Create and Configure a Receive Port and FILE Receive Location
Procedure List
BizTalk Group, Applications, and Module 4, and then click Orchestrations.
3. Double-click the ProcessOrder.OrchProcessOrder orchestration.
4. In the Orchestration Properties dialog box, click Bindings.
5. Notice that this orchestration has two Inbound Logical Ports and four Outbound
Logical Ports listed.
Logical ports are found in orchestrations, and they are used to specify logical
entry and exit points for messages as they are being processed by the
orchestration. All logical ports must be “bound” to physical ports before an
orchestration can process messages.
6. Click Cancel.
then click Receive Locations.
Naming receive ports with descriptive names is important for tracking and
troubleshooting later.
9. Click the New button.
10. In the Receive Location Properties dialog box, change the Name to
Here you are creating a physical receive location that will use the FILE adapter to
pick up messages for processing by the orchestration.
11. In the FILE Transport Properties dialog box, click the Browse button.
12. In the Browse For Folder dialog box, expand Computer, Local Disk (C:), AllFiles,
LabFiles, Module 4, and Messages, click PurchaseOrderIN, and then click OK.
Notice that you can create new folders from here if a folder does not already
exist.
14. In the Receive Location Properties window, click XMLReceive in the Receive
Receive pipelines handle such processes as decrypting a file and making sure the
inbound document matches a particular schema. In this case, any documents
processed by this receive location must be well-formed XML.
15. In the Receive Port Properties dialog box, click OK.
Create and Configure a SharePoint Receive Location
Procedure List
1. In the BizTalk Server Administration Console, right-click Receive Ports, point to New,
and then click One-way Receive Port.
2. In the Receive Port Properties dialog box, in the Name box, type ManualReview.
3. Click Receive Locations, and then click New.
4. In the Receive Location Properties dialog box, in the Name box, type
PurchaseOrderAckSharePoint.
5. In the Type list, click Windows SharePoint Services. In the Receive pipeline list, click
XMLReceive, and then click Configure.
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
60
SharePoint Site URL
http://BIZTALKDEMO
Source Document Library URL
PurchaseOrderAck
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.
7. Click OK twice.
Exercise 2: Create Send Ports
Overview
BizTalk Server uses send ports to communicate with external systems. In this exercise, you
will create four send ports. The first is an FTP send port that is used to send shipping
information for all successfully processed purchase orders. The second is an SMTP port that
is used to forward purchase orders that need approval to the sales manager. The last two
send ports are used to separate approved and denied purchase orders into file folders.
Create and Configure an FTP Send Port
Procedure List
1. In the BizTalk Server Administration Console, under Module 4, right-click Send Ports,
point to New, and then click Static One-way Send Port.
2. In the Send Port Properties dialog box, change the Name to ShipNoticeFTP, click
FTP in the Type list, and then click Configure.
FTP is one of several types of adapters that BizTalk Server can use to send
documents after they have been processed. Global configuration settings for the
FTP adapter can be found in the Adapters section of the Microsoft BizTalk Server
Administration Console, under Platform Settings.
3. In the FTP section of the FTP Transport Properties dialog box, configure the
properties as shown in the following table. Leave all other properties at the default
settings, and then click OK.
The Target File Name property adds the prefix ShipNotice to the GUID
associated with each approved purchase order’s shipment information.
Property
Setting
Folder
ShippedOrders
Password
pass@word1
Note: Click the down arrow to the right of the
Password box before entering the password.
Server
BIZTALKDEMO
Target File Name
ShipNotice%MessageID%.xml
User Name
Administrator
4. In the Send Port Properties window, click OK.
Create and Configure a SharePoint Send Port
Procedure List
2. In the Send Port Properties dialog box, change the Name to
ManualReviewSharePoint.
3. In the Type list, click Windows SharePoint Services, and then click Configure.
click OK.
Property
Setting
Destination Folder URL
PurchaseOrderAck
Filename
PoAck%MessageID%.xml
SharePoint Site URL
http://BIZTALKDEMO
This send port will send messages to a SharePoint Document Library named
PurchaseOrderAck.
5. Click OK to close the Send Port Properties dialog box.
Create and Configure a FILE Send Port for Denied Orders
Procedure List
2. In the Send Port Properties dialog box, change the Name to DeniedFILE, click FILE in
the Type list, and then click Configure.
Notice that the word FILE appears in the name of the send port. It is a good
practice to include the adapter type in the name of your send ports for ease of
tracking and troubleshooting.
LabFiles, Module 4, and Messages, click Denied, and then click OK.
Denied%MessageID%.xml, and then click OK.
This prepends the word Denied to the name of any messages dropped in this
folder. Only messages that have been explicitly denied by the sales manager
should end up in this folder.
Create and Configure a FILE Send Port for Approved Orders
Procedure List
2. In the Send Port Properties window, change the Name to POAckFILE, click FILE in
LabFiles, Module 4, and Messages, click PurchaseOrderAck, and then click OK.
Completed%MessageID%.xml, and then click OK.
This pre-pends the word Completed to the name of any messages dropped in this
folder. Only purchase orders that were successfully processed should end up in
this folder.
6. In the Send Port Properties dialog box, click OK.
Exercise 3: Bind the Orchestration
Overview
In this exercise, you will bind the orchestration’s logical ports to the physical send and
receive ports that you created in earlier exercises.
Configure the Orchestration Bindings
Procedure List
1. In the BizTalk Server Administration Console, click Orchestrations.
2. Right-click ProcessOrder.OrchProcessOrder, and then click Properties.
3. In the Orchestration Properties window, click Bindings.
4. In the Orchestration Properties window, configure the properties as shown in the
following table, and then click OK.
Notice that logical receive ports can be bound only to physical receive locations
and logical send ports can be bound only to physical send ports.
Property
Setting
Host
BizTalkServerApplication
RcvPO
PurchaseOrders
RcvPOReview
ManualReview
SndPOReview
ManualReviewSharePoint
SndError
DeniedFILE
SndShipNotice
ShipNoticeFTP
SndFinalPOAck
POAckFILE
Exercise 4: Start and Test the Application
Overview
In this exercise, you will start and test the BizTalk Server application that processes purchase
orders.
Start the Application
Procedure List
1. In the BizTalk Server Administration Console, right-click Module 4, and then click
Start.
2. Notice that the Configure Application dialog box states that the application cannot
be started because it is not fully configured. Click Yes to finish configuring the
application.
3. In the Configure Application window, notice that the orchCalculateShipping
orchestration has a yellow exclamation point next to it.
This orchestration has not been fully configured. Until all orchestrations are
configured, the application cannot start.
4. Click orchCalculateShipping.
5. Click BizTalkServerApplication in the Host list, and then click OK.
The BizTalk host defines the process boundary in which the orchestration will
run. Notice that this orchestration does not have any ports. It communicates
internally with the ProcessOrder.OrcheProcessOrder orchestration.
Start.
7. In the Start ‘Module 4’ Application dialog box, click Options, ensure that all of the
Procedure List
2. Copy the three ContosoPO… and the two FabrikamPO… XML messages to the
the original files are not retrievable.
4. In the PurchaseOrderAck folder, notice the four Completed{GUID}.xml messages,
open each, and verify that the AckCode field displays X% discount applied.
5. In Internet Explorer, type ftp://BIZTALKDEMO/ShippedOrders in the Address bar,
6. When prompted to log in, in the User name box, enter Administrator, and in the
Password box, enter pass@word1, then click Log On.
7. Notice the four ShipNotice{GUID}.xml messages.
8. In Internet Explorer, navigate to http://BIZTALKDEMO/PurchaseOrderAck.
9. Click the message, and then in the File Download dialog box, click Open. If the
Take note of the Customer Name; it is either Contoso or Fabrik.
The Evaluated view shows purchased that have been accepted or rejected.
processed.
13. Pause the bt10a-04 virtual machine.
Lesson 2: Monitoring Orchestrations and Messages
Lesson objective:
Manage and monitor the state of message and orchestration processing.
Lesson Overview
Microsoft BizTalk Server provides tools that can be used to troubleshoot messaging and
orchestration processes. The BizTalk Server Administration Console offers the BizTalk Group
Hub page, which can be used for viewing live BizTalk Server instances, as well as historical
instances. Live instances are defined as currently executing, whether in an active,
dehydrated, or suspended state. Historical instances refer to completed processes. The
BizTalk Group Hub provides powerful search and summary capabilities to assist in identifying
the overall health of a BizTalk system.
What Is the BizTalk Group Hub Page?
Use the Group Hub Page to determine the health of your BizTalk system and view details on
instances.
The Group Hub Page
The BizTalk Server Group Hub provides IT Professionals with an overview of the health of a
BizTalk group by displaying data relating to orchestrations, suspended service instances, host
instances, and adapters.
Viewing Information in the Group Hub Page
Clicking any of the links in the Group Hub Page executes a query that returns details in a new
Hub page. You can also create and save your own queries. The Group Hub Page is broken
down into 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 status 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 status of these items.

Work in Progress and Suspended Items. This section displays dehydrated
orchestrations; retried and idle ports; and running, ready, scheduled, and suspended
service instances. You can also view suspended messages by using the Group Hub
page.

Grouped Suspended Service Instances. This section of the Group Hub page displays
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 grouped here by error code.
Once the error has been resolved (perhaps an unavailable server or incorrect
configuration), all instances can be resumed (or terminated) together.

Tracked Service Instances and Tracked Message Events. This section of the Group
Hub page displays completed and terminated service instances, as well as tracking
events related to individual messages, including transmission failure events.
You can also use the BizTalk Administration Console 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
Run queries to find specific message activity in the Group Hub.
Viewing Instance Details
When a query is executed in the Group Hub, 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. Each service instance
has multiple ways to track or troubleshoot errors, as well as several actions which can be
performed on the instance.
The options for viewing instance information include:

Service Details. The Service Details option will display the status of the instance—for
example, the instance ID, start time, and any errors that occurred. The Messages
page shows all the messages associated with this instance. 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. The Show Messages option initiates a new query that returns the
messages associated with this instance; this is the same list you see if you navigate
the Service Details option.

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 the related instances at once.

Two additional options are provided, Message Flow and Orchestration Debugger,
which will open a window displaying tracked properties of the message or a window
displaying the status of running orchestration instances. These options will be
covered later in this module.
Viewing Tracking Data
Use Group Hub queries to track and monitor message activity.
Overview
A BizTalk Server messaging system can process tens of 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 Group Hub queries allow users to view the tracking details related to
either messaging or orchestration instances.
Benefits
Some of the benefits of using Group Hub queries include:

Tracking when a service begins or ends or when a message is sent or received. The
query results show the start time and the end time for every message processed by
BizTalk Server. The results also show the state of any messages processed through
BizTalk Server. Message states include active, suspended, completed, and
terminated.

Monitoring the health of operations and creating reports to analyze the current
state of business processes. Every message goes through a series of contiguous
processing steps, and you can access this message flow by querying for messages
and then right-clicking the message that you want to track. Click Message Flow in
the drop-down list to see the processing steps for the message and to see whether
any errors occurred while the message was being processed by BizTalk Server.

Gathering 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, and
redeployment of assemblies is not necessary when changing tracking options.
Changes to which properties are tracked is managed through the BizTalk Server
Administration Console. Monitoring live data also enables you to monitor your
system so that you can fix problems in the development or staging environment.
Tracking Levels

The level of tracking is configurable within the BizTalk Server Administration
Console. For example, tracking can be performed at the port or schema levels. This
configuration includes being able to specify that message bodies must be retained
before and after processing. Each property that is tracked adds to the amount of
data maintained in the tracking database (size) and requires additional steps to
process. This means that tracking can have a negative impact on message processing
performance. For this reason, care should be taken in enabling specific message
tracking levels. It is highly recommended that tracking should be anticipated and
included in the testing process to identify the overall impact.
Note: Many of the desired goals of message tracking can be better achieved by configuring
Business Activity Monitoring (BAM), with a drastically smaller impact on performance.
Identifying Group Hub Tracking Job Roles
Describe various user roles for the Group Hub.
Message Tracking Roles
The BizTalk Group Hub can be used to query completed instances. Different users might
need access to this data at different times and for different reasons:

Systems administrators. Can use the Group Hub to track the health of a BizTalk
application, determine bottlenecks, and monitor the BizTalk environment. They can
view the technical details of a particular orchestration, pipeline, or message
instance, as well as view the message flow for an individual message being
processed. Systems administrators can configure various tracking options during run
time, and tracking options can be changed for an item at any time without
interrupting the business process.

Business users. Can view, monitor, and query data that is being tracked with the
Group Hub. Additionally, business users can create custom views and queries and
save them for reuse. They can also track the state of business processes by viewing
both live and archived data.

Developers. Can use the Group Hub in a development environment to debug
orchestrations in real time, and to track messages as they are processed by BizTalk.
The orchestration debugger attaches to an instance of a running orchestration and
enables developers to track the path a message takes through the orchestration.
Developers can also use the Group Hub to view message properties and real-time
values contained in messages.
Identifying the Types of Events and Data to Track
Explain the messaging events and data that can be tracked.
Event Tracking
BizTalk tracks data as events based on tracking filters that you have set. You can track events
such as:

The starting or ending of a service.

When messages are sent or received.

When a pipeline starts or ends.

When an orchestration starts or ends.

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 Group Hub also allows you to see suspended
orchestrations and pipeline information. You can also track:

Promoted properties. This is useful when you have implemented content-based
routing that uses promoted properties and want to locate messages that were
processed. After you turn 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 property 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 Administration
Console.

Routing information. Because tracking allows you to trace the path of a message as
it is routed through BizTalk Server, enabling tracking can be useful for
troubleshooting errors. The Group Hub can display error codes and routing states for
a message so that you can troubleshoot errors in real time.

Partner data. In addition to tracking messages based on their schemas, you can
additionally track data based on the trading partner associated with the message.
This allows you to query message activity based on specific partners that have been
set up in the Trading Partner Management (TPM) system. This is especially useful if
you have multiple parties using the same schema or port and you want to filter the
data based on which party is involved in the message flow.

Schema information. The BizTalk Group 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
Use the Message Flow view to view specific message details.
Overview
You can view both live and archived data by using various views provided by the Group Hub.
You must have message body tracking turned on to save messages after service instance
processing is complete. Also verify that the SQL Server Agent service is running on all
MessageBox databases. This makes message bodies available to the Group Hub and WMI,
and it enables you to perform cleanup in the MessageBox database. Message body tracking
is configured by using the BizTalk Administration Console and is covered later in this module.
Capabilities of Message Tracking
Message tracking 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 Group 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 bodies. 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 Group Hub that can be used to track the flow
of a message through an orchestration.
Demonstration: Tracking and Viewing Message Activity
In this demonstration, you will see how to use the BizTalk Group Hub to view and track message
activity.
To Create Message Activity
1. In Windows Explorer, navigate to C:\AllFiles\DemoCode\Module4\Messages.
2. Copy the ContosoPO_Large.xml, ContosoPO_Small.xml, and
ContosoPO_BadNameSpace.xml files from the Messages folder to the POIn folder.
Be sure to copy the messages to the POIn folder. If you move the messages, they
will be permanently modified by the BizTalk process. If you happen to move any
of the messages, a copy can be found at C:\AllFiles\DemoCode\MessageCopies.
To Use the Group Hub Page to View Message Activity
2. Expand BizTalk Server Administration, and then click BizTalk Group.
3. Press the F5 key to refresh the view.
4. On the BizTalk Group Hub page, notice the six sections: Configuration Overview,
Work in Progress, Suspended Items, Grouped Suspended Service Instances,
Tracked Service Instances and Tracked Message Events.
5. In the Configuration Overview section, notice that the Group name, Server, and
Database are displayed. Also notice that summaries of the Applications, Host
Instances, and Adapter Handlers are displayed, including their status.
6. In the Work in Progress section, notice that there is one Running service instance.
7. In the Suspended Items section, notice that there is one Suspended service instance
(Resumable).
8. In the Suspended Items section, click Suspended service instances.
9. In the Query results section, click Suspended (resumable).
10. In the Preview for the selected query result pane, right-click the service instance,
and then click Service Details.
11. In the Service Details dialog box, click the Error Information tab.
12. Notice the last line of the Error Description, which reads: Reason: Finding the
document specification by message type
"http://IncorrectNamespace#PurchaseOrder" failed. Verify that the schema is
deployed properly.
This error message explains why this message was suspended. In this case, the
message type does not match a deployed schema.
13. Click the Messages tab.
14. Right-click the message, and then click Message Details.
The Message Details dialog box opens. The General page of the Message
Details dialog box displays information about the message associated with this
service instance, including the Host, Adapter, and URI.
15. Click Context in the left pane of the Message Details dialog box.
The Context page displays the metadata associated with the message instance,
including ReceivedFileName, InboundTransportLocation,
ReceiveLocationName, and ReceivePortName.
16. Click body in the left pane of the Message Details dialog box.
All XML messages have at least one message part, known as the message body.
The body page displays the actual message body in both text and binary
formats.
17. Click the Binary tab on the body page.
18. Close the Message Details dialog box.
19. Close the Service Details dialog box.
To Use the Group Hub Page to Track Completed Service Instances
2. Copy the ContosoPO_Large.xml file to the POIn folder.
3. On the BizTalk Group Hub page, beneath the Tracked Service Instances heading,
click the Completed instances link.
4. Right-click the most recent service instance, which is at the top of the list, and then
click Message Flow.
5. Maximize the Message Flow window.
The top section of this window has information about this service instance, such
as the type, start and end times, and the host used. The lower section has In and
Out parts.
6. Click the ProcessOrder.OrchProcessOrder link at the bottom of the Message Flow
window.
The top section has information about the service instance. The lower section
provides information about how the message was received into the
orchestration (Microsoft.BizTalk.DefaultPipelines.XMLReceive) and where the
orchestration sent the message (one instance of the PassThruTransmit pipeline
on the SndShipNotice port, and three instances of the PassThruTransmit pipeline
on the SndFinalPOAck port).
7. Click the first Microsoft.BizTalk.DefaultPipelines.PassThruTransmit link under the
SndFinalPOAck port.
Notice the URL and port used by this instance of the pipeline. Because send port
groups are nondeterministic in the order in which the message is sent, the order
of the send ports used is random.
8. Click the ProcessOrder.OrchProcessOrder orchestration link.
9. Click the second Microsoft.BizTalk.DefaultPipelines.PassThruTransmit link under
the SndFinalPOAck port.
10. Click the ProcessOrder.OrchProcessOrder orchestration link.
11. Click the third Microsoft.BizTalk.DefaultPipelines.PassThruTransmit link under the
SndFinalPOAck port.
Notice the URL and port used by this instance of the pipeline.
12. Close all Health and Activity Tracking windows.
Using the Group Hub to View Orchestrations
Explain the service instance states and message instance states displayed in the Group Hub.
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.

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 monitor orchestration processing and debug an
orchestration.
Overview
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 created in Orchestration Designer.
Accessing the Orchestration Debugger
You can start the Orchestration Debugger from within the Group Hub to view archived data
or debug orchestrations in real time. Simply right-click any service or message instance
associated with an orchestration type, and then choose Orchestration Debugger from the
context menu. You can switch back and forth between Orchestration Debugger view and
Message Flow view.
Orchestration Debugger Features
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 (for
running instances only). The maroon dot on the Receive_1 shape in the
Orchestration Debugger denotes a breakpoint.

View the specific variables and message data associated with an orchestration
instance while in debugging mode.

Enable all of the tracking options for a particular orchestration instance when that
instance is opened in the Orchestration Debugger.

Continue and resume in debug mode, and terminate the particular orchestration
instance.
Demonstration: Troubleshooting Orchestrations
In this demonstration, you will see how to use the Orchestration Debugger to troubleshoot a
running orchestration.
Note: When debugging orchestrations, it’s possible that the debugger may not stay attached
to the first instance. It’s recommended that if you do not get the expected results the first
time submit another message (without clearing breakpoints) and try the debugging process
again.
To Open the Orchestration Debugger from the BizTalk Group Hub Page
2. Expand BizTalk Server Administration, and then click BizTalk Group.
3. Click the Refresh button.
4. In the Work in Progress section, click Running service instances.
5. In the Preview for the selected query result section (bottom pane), right-click the
ProcessOrder.OrchProcessOrder… with a Status of Dehydrated, and then click
Orchestration Debugger.
The right pane of the Orchestration Debugger displays the orchestration being
debugged. The left pane displays event tracking. Every event has a start and an
end. The start is represented with a green arrow and the completion is
represented with a blue arrow.
To Set Breakpoints on Orchestration Shapes
1. In the Orchestration Debugger, right-click the Receive PO Ack receive shape, and
then click Set Breakpoint on Class.
2. Right-click the Apply Discount scope shape, and then click Set Breakpoint on Class.
3. Right-click the Invoke Shipper Info scope shape, and then click Set Breakpoint on
Class.
To Resume and Complete the Dehydrated Orchestration Instance
1. In Windows Explorer, navigate to
C:\AllFiles\DemoCode\Module4\Messages\POReviewOUT.
2. Move the {GUID}.xml file to the POReviewIn folder.
3. On the File menu of the Orchestration Debugger, click Refresh.
The breakpoints will not be applied to this instance of the orchestration, but they
will be applied to all future orchestration instances until the breakpoints are
removed.
4. Close the Orchestration Debugger window.
To Debug a New Instance of the Orchestration
2. Copy ContosoPO_Large.xml to the POIn folder.
3. In the BizTalk Group Hub, on the Running page, click Run Query.
In the Preview for the selected query result pane at the bottom of the Group
Hub window, notice that the Status of the orchestration is In Breakpoint
(Active).
4. Right-click ProcessOrder.OrchProcessOrder…, and then click Orchestration
Debugger.
Notice that the Receive PO Ack event has started.
5. On the Debug menu of the Orchestration Debugger, click Attach.
Notice that the Receive PO Ack event has completed, and the orchestration
instance is stopped at the breakpoint on the Apply Discount scope shape.
6. In the Variable List section, click RcvPO.
Notice the Address property. This is the physical location from which this
message was received.
7. In the Variable List section, click msgPO.
8. In the Variable Properties section, click the ellipsis (…) button next to (Collection).
The Message Properties dialog box contains contextual information about this
message instance, such as InboundTransportType, InboundTransportLocation,
and MessageType.
9. Close the Message Properties dialog box.
10. On the Debug menu of the Orchestration Debugger, click Continue.
Notice that the Calculate Discount event starts and completes, along with the
Apply Discount event. The Invoke Shipper Info event begins.
11. On the Debug menu of the Orchestration Debugger, click Continue.
The orchestration completes successfully.
12. On the Debug menu, click Clear All Breakpoints on Class.
Tracking Business Policy Execution
Use the Group Hub to track the execution of business rules.
Tracking Business Policies
You can use the Group Hub to monitor rule activities and to track the overall progress of an
orchestration that uses the Business Rules Framework. You can click a policy to view the
policy or to change the current tracking configuration for that policy. Tracking the execution
of business policies can be helpful in identifying how and why business decisions were made.
With business policy execution tracking, you can:

Use Track Fact Activity to track the instance data on which the policy operates.

Use Track Condition Evaluation to track the True or False results of conditions in the
selected policy.

Use Track Rule Firings to track the actions triggered as a result of the policy.

Use Track Agenda Updates to track updates to the agenda, which generates a list of
actions that are True and need to be fired.
After tracking configurations have been set, you can then use the BizTalk Group Hub page to
track policy and message details. You should be aware that tracking rules execution can have
an effect on performance and should be used conservatively in performance testing.
Demonstration: Tracking Business Policy Execution
In this demonstration, you will see how to configure and track business policy execution by using
the BizTalk Administration Console.
Enable Policy Tracking
2. Expand BizTalk Server Administration, BizTalk Group, Applications, and Module4,
and then click Policies.
3. Right-click DiscountPolicy, and then click Properties.
4. In the Policy Properties dialog box, click Tracking.
5. Select the four check boxes, and then click OK.
Track Policy Execution
1. In Windows Explorer, navigate to C:\Labs\AllFiles\DemoCode\Module4\Messages.
2. Copy FabrikamPO_Large.xml to the POIn folder.
4. Right-click the most recent service instance, which is at the top of the list, and then
click Message Flow.
5. In the Message Flow window, click ProcessOrder.OrchProcessOrder.
6. Click the Follow this link to view the Policy execution details for the Orchestration
Instance.
7. In the Policy Execution dialog box, click Discount Policy 1.0.
8. Click Fact Activity.
This page shows the facts that were used to evaluate the rule condition(s) being
asserted to and retracted from the facts list.
9. On the File menu, click Navigate back.
10. Click Rules that Fired.
11. Click Large Order Non-Contoso (5% disc).
The rule as it is displayed in the Business Rule Composer is shown.
14. Click Rules that did not Fire.
The two rules that did not fire are displayed.
16. Click Conditions that Evaluated.
This page shows all the conditional tests that were performed to determine
which rules would be applied.
18. Click Agenda Updates.
This page shows the Business Rule Engine agenda update, which states that the
Large Order Non-Contoso (5% disc) was to be applied.
Orchestrations
Scenario
In this lab, you will use the BizTalk Group Hub to troubleshoot archived messages. You will
also use the Group Hub page in the Microsoft BizTalk Server Administration Console to track
running business processes.
Preparation
Exercise 1: Track and View Message Activity
Overview
The BizTalk Group Hub page is used to view the details of running service instances, as well
as those of completed instances. In this exercise, you will use the Group Hub to view the
message flow of the messages that were processed in the previous lab. Then you will use the
Group Hub page to troubleshoot a running service instance.
Track Archived Message Activity by Using the BizTalk Group Hub
Procedure List
2. Copy ContosoPO_Large.xml to the PurchaseOrderIN folder.
3. In the BizTalk Server Administration Console, in the left pane, click BizTalk Group.
4. Press the F5 key to refresh the page.
6. In the Query results pane, right-click the first record that is listed with a Service
Name of Microsoft.BizTalk.DefaultPipelines.XMLReceive, and then click Message
Flow.
8. 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.
9. The lower section displays the flow of the message instance. This message was
received as an Unparsed Interchange through the PurchaseOrders port. It was then
sent to the ProcessOrder.OrchProcessOrder orchestration by using the
PurchaseOrders port.
10. Click the ProcessOrder.OrchProcessOrder link at the bottom of the page.
11. Notice that the Type of the service is Orchestration, the State is Completed.
12. In the lower section, notice that the message was received with the RcvPO port,
sent through the SndShipNotice and SndFinalPOAck ports.
13. Click the Microsoft.BizTalk.DefaultPipelines.PassThruTransmit link in the
SndShipNotice port section.
14. Information about the service instance is displayed.
15. Click the ProcessOrder.OrchProcessOrder link.
View Running Instances by Using the Group Hub Page
Procedure List
1. In Windows Explorer, navigate to C:\AllFiles\LabFiles\Module 4\Messages, and
then copy BadNameSpace.xml and ContosoPO_Small.xml to the PurchaseOrderIN
folder.
2. In the BizTalk Server Administration Console, in the center pane, click the Group Hub
tab.
3. Press F5 to refresh the page. Notice that there is one Running service instance and
one Suspended service instance shown as Resumable.
Remember to refresh the Group Hub page periodically, especially if you have
made a change and want to see new information on a running orchestration
instance.
If a service instance is marked as Resumable, it will continue to process the
message after the error is fixed.
4. Click Running service instances.
5. In the bottom pane of the Group Overview page, right-click
ProcessOrder.OrchProcessOrder, and then click Message Flow. The Message Flow
window allows you to track the message.
6. Close the Message Flow window.
7. In the lower pane, right-click ProcessOrder.OrchProcessOrder, and then click
Service Details.
The General tab contains information such as the start time, service class, and
status of the selected service.
9. Double-click the message with the Message Type of
http://MyCompany/OrderMgmt.PurchaseOrder#PurchaseOrder to open the
Message Details dialog box.
The General tab of the Message Details window displays information about this
message instance.
10. In the left pane, click Context.
The Context tab of the Message Details window displays the message context
information that is used to route and track the message.
11. In the left pane, click body. The body tab of the Message Details window displays
the message body.
12. Close the Message Details dialog box, and then close the Service Details dialog box.
15. In the Status list, choose Accept, and then close the form, saving your changes.
4\Messages\PurchaseOrderAck, and notice that the processed message is here.
It might take up to one minute for the message to appear.
17. In the BizTalk Server Administration Console, click the Group Hub tab, and then
press the F5 key to refresh the data.
The running service instance has now been completed and is no longer displayed
here.
18. Under Suspended Items, click Resumable.
19. In the lower pane, double-click the service instance with a Service Name of
PurchaseOrders.
20. Click the Error Information tab.
You can use the information on this tab to troubleshoot errors in the message.
You can also use Event Viewer to see BizTalk error messages.
22. Double-click the message in the lower pane.
23. In the Message Details dialog box, click body.
Notice in the first line that the namespace
(xmlns:ns0=“http://BADNAMESPACEDATA”) is not a valid namespace, in that
there are no assemblies deployed with a schema with this namespace. The
namespace should be http://MyCompany/OrderMgmt.PurchaseOrder.
24. On the File menu, click Save Message, and then click OK.
25. In the BizTalk Server Administration Console message box, click OK.
26. In the Browse for Folder dialog box, navigate to C:\AllFiles\LabFiles\Module
4\Messages, and then click OK.
28. Close the Message Details window, and then close the Service Details window.
29. In the lower pane, right-click the PurchaseOrders service, and then click Terminate
Instance.
30. Click Yes, and then click OK.
31. Click the Run Query button, and notice that there are no more Suspended
(resumable) instances.
Notice the two new files that have been created; one is the context of the saved
message, the other is the message itself, saved as an OUT file.
33. Rename the {GUID}_{GUID}_body.out file FixedNameSpace.xml.
34. Right-click FixedNameSpace.xml, and then click Edit.
35. In the first line of the message, change http://BadNameSpace to
http://MyCompany/OrderMgmt.PurchaseOrder, and then save and close the
message.
36. Copy FixedNameSpace.xml to the PurchaseOrderIN folder, and then navigate to the
PurchaseOrderAck folder and notice that the message was processed correctly.
37. Close all open windows, and pause the bt10a-04 virtual machine.
Lesson 3: Scripting Administrative Tasks
Lesson objective:
In this lesson, you will learn how to:
Administer BizTalk operations by using command-line tools and scripts.
Lesson Overview
BizTalk applications are made up of assemblies that contain schemas, maps, pipelines, and
orchestrations. The assemblies must be deployed to both the BizTalk Configuration database
and the global assembly cache (GAC) before an application can begin to process messages.
In addition to using MSI packages and the BizTalk Server Administration Console to deploy
BizTalk Server assemblies, you can also use WMI to script assembly deployments and other
administrative tasks by using command-line utilities. This lesson shows you how to automate
common BizTalk administration tasks by using command-line utilities. The BizTalk Server
2010 software development kit (SDK) includes several examples of how this can be
performed. In a default BizTalk Server installation, these examples can be found in
C:\Program Files\Microsoft BizTalk Server 2010\SDK\Samples\Admin.
Deploying from the Command Prompt
Deploy a BizTalk application by using command-line tools.
Deploying by Using BTSTask
You can use the BTSTask command-line utility to perform many of the same tasks as the
BizTalk Server Administration Console; the restrictions are the same as those when
deploying assemblies by using the BizTalk Server Administration Console. By using BTSTask,
you can register BizTalk assemblies in the BizTalk Configuration database and deploy them to
the global assembly cache (GAC).
When to Use BTSTask
The following BTSTask command adds the assembly named NewAssembly.dll to the
DemoApp application, overwriting the assembly if it already exists. The application resides
(or will be created) in the BizTalkMgmtDb database, which is the default Configuration
database for BizTalk. The SQL Server is named SQL6.
BTSTask AddResource /ApplicationName:DemoApp /Type:BizTalkAssembly
/Overwrite /Source:"C:\Source Assemblies\NewAssembly.dll"
/Destination:"C:\New Assemblies\NewAssembly.dll "
/Options:GacOnInstall,GacOnImport /Server:SQL6
/Database:BizTalkMgmtDb
With the GAC options specified, the assembly will be installed to the GAC either when
imported or when installed. Only one option is required, but executing the command this
way will ensure that if the application is later exported to an MSI package, both settings are
provided.
The parameter values listed here are not case-sensitive, and you can type only the first few
letters of the parameter name to specify it unambiguously.
Refer to the BizTalk Server 2010 online documentation about either the “BTSTask” or
“AddResource command” for more help on deploying assemblies by using BTSTask.
Removing Deployed Assemblies
Remove a BizTalk application by using command-line tools.
Overview
Undeploying an assembly removes it from the BizTalk Configuration database and,
optionally, from GAC. You can undeploy an assembly by using BTSTask.
Undeploying by Using BTSTask
To undeploy an assembly by using the BTSTask utility, use the RemoveResource command.
You can use the BTSTask command-line utility to perform the same tasks as the BizTalk
Server Administration Console; the restrictions are the same as when undeploying
assemblies by using the BizTalk Server Administration Console.
The syntax for removing an assembly by using BTSTask is:
BTSTask RemoveResource ApplicationName LocallyUniqueIdentifier
ServerName DatabaseName
Refer to the BizTalk Server 2010 online documentation on “BTSTask” for more
information about undeploying assemblies by using BTSTask.
Creating and Binding Ports by Using the Command Prompt
Export and import binding files by using command-line tools.
Overview
As described earlier, a port binding specifies the entry points into the BizTalk application and
is most often used to associate logical ports in an orchestration with physical send and
receive ports. The port binding contains configuration information that specifies where and
how a message is to be sent or received.
Exporting a Binding File by Using the Command Prompt
To export a binding file for a deployed orchestration by using the command prompt, use the
BTSTask utility with the ExportBindings option. This allows you to export bindings for a
BizTalk assembly, application, or group and save the binding file as an XML file for later use
on another server or in another environment. An example of using ExportBindings is as
follows:
BTSTask ExportBindings /Destination:"C:\Binding
Files\MyBindings.xml" /GroupLevel /Server:MyDatabaseServer
/Database:BizTalkMgmtDb
Refer to “BTSTask ExportBindings Command” in the BizTalk Server 2010 documentation for
more information about each of the parameters that can be used.
Importing a Binding File by Using the Command Prompt
To import a binding file for a deployed orchestration by using the command prompt, use the
BTSTask utility with the ImportBindings option. This allows you to import bindings for a
BizTalk assembly, application, or group from a previously created XML file. An example of
using ImportBindings is as follows:
BTSTask ImportBindings /ApplicationName:MyApplication
/Source:C:\Bindings\Binding1.xml
Refer to the topic “BTSTask ImportBindings Command” in the BizTalk Server 2010
documentation or more information about each of the parameters that can be used.
Managing Applications by Using the Command Prompt
Export and import binding files by using command-line tools.
Overview
In addition to using the BTSTask command-line utility for deploying and undeploying
assemblies and exporting and importing binding files, a number of other actions can be
performed, including:

Adding a BizTalk application to the BizTalk Configuration database by using the
AddApp command.

Listing all of the resources in an MSI file by using the ListApps command.

Listing all of the resources for an application by using the ListApps command.

Listing all of the applications in the BizTalk Configuration database by using the
ListApps command.

Listing all of the artifact types supported by BizTalk Server by using the ListTypes
command.
Refer to “BTSTask Command” in the BizTalk Server 2010 documentation for more
information about each of the parameters that can be used.
Demonstration: Managing BizTalk Server Applications by Using BTSTask
In this demonstration, you will see how to script administrative tasks by using the BTSTask
command-line utility. You will use BTSTask to add resources to an application and remove
resources from an application.
To Add an Assembly to an Application
1. On the Start menu, click Run.
2. In the Open box, type cmd, and then press ENTER.
3. In the command prompt window, type the following command and then press
ENTER.
BTSTask AddResource -ApplicationName:Module4
-Type:System.BizTalk:BizTalkAssembly
-Source:C:\AllFiles\DemoCode\Module4\OrderManagement.dll
-Destination:C:\Allfiles\DemoCode\Module4\Orders.dll
BizTalk Group, Applications, and Module4, and then click Orchestrations.
6. Notice that two new orchestrations have been added for Version 5.0.0.0 of the
orchestration.
7. If they are not already unenlisted, right-click both Version=4.0.0.0 orchestrations,
and then click Unenlist. Unenlist the ProcessOrder.OrchProcessOrder first.
To Remove an Assembly from an Application
ENTER.
BTSTask RemoveResource -ApplicationName:Module4
-Luid:"OrderManagement, Version=4.0.0.0,
Culture=neutral,
PublicKeyToken=f77ab8a2e6630f49"
2. In the BizTalk Server Administration Console, refresh the view, and notice that the
Version 4.0.0.0 assembly has been removed.
Scenario
BTSTask is a command-line utility used by BizTalk Server administrators for performing
common administrative tasks such as exporting an application to an MSI file, adding BizTalk
Server applications to a computer running BizTalk Server, or removing applications from a
computer running BizTalk Server. BTSTask can be used to script actions that are performed
multiple times on one or more servers. In this lab, you will use BTSTask to export an
application to an MSI file, remove the exported application, and then import a separate MSI
package. More information about the use of BTSTask can be obtained by typing BTSTask /?
at the command prompt.
Preparation
Exercise 1: Export and Remove an Application by Using BTSTask
Overview
Exporting an application to an MSI package groups all assemblies, ports, other artifacts, and
binding information into an MSI package for easy distribution to other computers running
BizTalk Server. In this exercise, you will export the Module 4 application to an MSI package
by using the BTSTask command-line utility. You will then remove the Module 4 application.
Export the Module 4 Application
Procedure List
2. In the Open box in the Run dialog box, type cmd, and then press ENTER.
3. In the command prompt window, type btstask /?, and then press ENTER to view the
available commands.
4. Type the following command and then press ENTER.
BTSTask ExportApp –ApplicationName:“Module 4”
–Package:“C:\ExportMod4.msi”
This step packages up all ports and artifacts in the Module 4 application into the
ExportMod4.msi file.
Remove the Module 4 Application
Procedure List
2. In the BizTalk Server Administration Console, expand BizTalk Server
Administration, BizTalk Group, Applications, right-click Module 4, and then click
Stop.
You must stop the application before you can remove it from the computer
3. In the Stop ‘Module 4’ Application dialog box, click Full Stop – Terminate instances,
and then click Stop.
Performing a full stop terminates any running, suspended, or dehydrated
instances of the orchestration. If any running, suspended, or dehydrated
instances are present in memory, the remove will fail.
ENTER.
BTSTask RemoveApp –ApplicationName:“Module 4”
Refresh.
Notice that the Module 4 application is no longer listed.
Exercise 2: Import a BizTalk Application by Using BTSTask
Overview
In this exercise, you will import a BizTalk Server application by using a MSI package. After the
application has been imported, you will configure and start the application. The Module 4
BAM application will be used in the next lab to test Business Activity Monitoring.
Import the Module 4 BAM Application
Procedure List
ENTER.
BTSTask ImportApp
-Package:"C:\AllFiles\LabFiles\Module 4 BAM\Module4-BAM.msi"
-ApplicationName:"Module 4 BAM"
2. In the BizTalk Server Administration Console, right-click Applications, then click
Refresh and notice that the Module 4 application has been removed, and that the
Module 4 BAM application has been deployed.
3. Right-click Module 4 BAM, and then click Configure.
4. In the Configure Application window, click OrderMgmtProcess, notice that the ports
and host have been configured, and then click OK.
5. Right-click Module 4 BAM, and then click Start.
Starting the application enables any receive ports, starts any send ports, and
makes the application available for testing.
6. In the Start ‘Module 4 BAM’ Application dialog box, click Start.
Lesson 4: Monitoring Business Activity
Lesson objective:
Monitor business activity by using Business Activity Monitoring (BAM).
Lesson 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 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.
Gaining Visibility into Business Processes
Describe how BAM is used to gain visibility into running business processes.
Overview
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 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. BAM also provides
auditing capabilities by being able to answer the how or why a message was processed.
BAM enables you to determine how your business is performing by answering questions
such as:

How long did it take for this process to be approved?

How quickly was this order filled after it was received?

How many process cycles occurred in the last month? In the last year?

How many purchase orders were processed last week?

How large is our total revenue this year?
By aggregating data, BAM provides an overview of trends experienced in the business while
allowing users to investigate individual instances. This visibility in a near real-time
environment is tremendously beneficial for making critical business decisions.
What Is Business Activity Monitoring?
Describe what BAM is and how it can be used by IT Professionals for monitoring business
activities.
Overview
BAM makes it possible for developers, business analysts, and end users, working
collaboratively, to extract the data they need from their business processes.
The BAM roles and the tools associated with these roles are as follows:
Business analysts use a Microsoft Office Excel® 2003 add-in, and optionally Orchestration
Designer for Business Analysis (ODBA), which integrates into Microsoft Office Visio® 2003, to
define the business requirements in a data collection model. This model includes process
milestones and the key performance indicators (KPIs) needed to monitor execution of the
business process. At this stage, the business analyst also creates one or more views, which
can include Excel pivot tables and pivot charts. For example, sales managers might require a
different level of detail from a customer service representative or a vice president of loss
prevention.
Systems administrators use the BAM Manager to deploy the business requirements into the
BAM databases. This process creates the table structure required to collect the data, as well
as the online analytical processing (OLAP) cubes. Views defined previously are rendered for
the BAM Portal.
Developers map the business processes to run-time components by using the Tracking
Profile Editor (TPE) for BizTalk Server. This tool links the data collection model created by the
business analyst to the implementation of the model created as an orchestration by the
developer.
Any user with sufficient permissions and an interest in the collected data can use the BAM
Portal to view, aggregate, and drill down into 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 components that BAM uses include:

BizTalk Primary Import database. This database acts as the principal collection point
for 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 OLAP cubes, which are also dynamically generated, along with the
necessary Data Transformation Services (DTS) packages and a staging database.

Real-Time aggregations (RTA). Special tables are created in which triggers are used
to maintain the aggregations synchronously along with the incoming events.

BAM interceptors. The collection of 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 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.
Enabling Business Activity Monitoring (Analyst Role)
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. The next four topics discuss
configuring, deploying, and consuming BAM data.
Business Analyst Role
The role of the business analyst is to create a BAM activity definition and to create the views
that will be available to end users to view the business processes. Generally, business
analysts do not know or need to know what the actual orchestration that defines the
business process looks like. They know only the information that is important for tracking
the order in which the process occurs.
Create Activity
Analysts use Excel 2003 to create activities that identify in list form the KPIs of the business
processes—for example, receiving and processing a purchase order (PO). These activities will
include milestones (the receipt of a PO or the sending of an invoice, for example), as well as
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.
Optionally, a business analyst might choose to start with ODBA (an add-in in Visio 2003) to
model the initial activity. This tool provides a graphical view of the business process that
might aid in identifying the flow and KPIs.
Although ODBA existed earlier, this use of ODBA is new in BizTalk Server 2010. For more
information about other uses of ODBA, refer to the Help file for BizTalk Server 2010. The BAM
add-in is a freely distributable add-in included in BizTalk Server 2010. Each workbook will
contain one activity, which might have multiple views.
Create View(s)
After the activity has been defined, the business analyst will use Excel to create one or more
views of the data—this will be the case even if the process was begun in ODBA. To begin the
view creation process, the business analyst will define:

Durations. The period of time between two milestones—for example,
OrderCycleTime might be the time from the receipt of a PO to delivery of the
product.

Dimensions. Used for grouping data logically—for example, by city and state or by
customer name. Dimensions can also include ranges—for example, low, medium,
and high total amounts on POs.

Measures. Identify averages and counts—for example, the AverageOrderCycleTime
representing the average of the OrderCycleTime duration identified earlier, or the
POCount representing the total number of POs processed.
After the durations, dimensions, and measures have been defined, the business analyst will
create a PivotTable® view, and optionally a PivotChart®, to display the data defined in the
view.
A single activity can have multiple views—for example, the data that interests a sales
manager might be different from the data that interests the vice president of loss
prevention or a customer service representative. The analyst would proceed through the
view creation process as many times as necessary to create the required views. After the
views are completed, the workbook is saved and handed off to the systems administrator for
deployment.
Enabling Business Activity Monitoring (Administrator Role)
Describe the role of the systems administrator in enabling Business Activity Monitoring.
Systems Administrator Role
The role of the systems administrator in enabling BAM is limited to deploying the workbook
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.
The steps in deploying a workbook are as follows:
1. Copy the workbook to the BAM Tracking folder (C:\Program Files\Microsoft BizTalk
Server 2010\Tracking).
2. Deploy activity definition by using BM deploy command prompt utility with the
appropriate option and provide the name of the definition file created in step 1.
Example of Using BM deploy command prompt utility
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
Refer to the BizTalk Server 2010 Help files for more information on updating, unconfiguring,
and viewing BAM Management data.
Enabling Business Activity Monitoring (Developer Role)
Describe the role of the developer in enabling Business Activity Monitoring.
Tracking Profile Editor (TPE)
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 the following two elements:

One or more BizTalk assemblies that have been deployed in the BizTalk
Configuration database. Each assembly can contain one or more orchestrations.

The Activity created by the business analyst that has been deployed to the tracking
database by using the BAM Management tool.
This process 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 and dropped onto 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 all the KPIs in the activity have been identified, the profile is deployed, and the
collection of data begins immediately. As long as the activity file does not change, it is
possible to modify how and from where the data is collected— 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 new 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 2.0 Web portal (meaning that it does not rely
on Microsoft Windows SharePoint® Services). 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 predefined 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 as well as 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 of particular threshold
conditions being 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
In this demonstration, you will see how to implement an existing Business Activity Monitoring
activity for a BizTalk Server solution.
Deploy the BAM View Created by the Business Analyst
3. In the command prompt window, type cd C:\Program Files (x86)\Microsoft BizTalk
Server 2010\Tracking, and then press ENTER.
4. In the command prompt window, type the following command, and then press
ENTER.
bm deploy-all -DefinitionFile:C:\AllFiles\DemoCode\Module4BAM\OrderMgmt.xml
5. In Windows Explorer, navigate to C:\AllFiles\DemoCode\Module4-BAM , and
double-click cfgBAMPart.cmd.
This script essentially disables the caching performed by SQL Analysis Services of
the data used to populate the OLAP cube. This will allow us to see the OLAP cube
update within seconds, for the purposes of this demo. You should not, of course,
disable this caching under normal circumstances.
6. After the command completes, close the command prompt windows.
Prepare for BAM Data Collection
and then click Tracking Profile Editor.
2. On the File menu, click Open, and then navigate to and open
C:\AllFiles\DemoCode\Module4-BAM\OrderMgmt.btt.
3. In the left pane of the Tracking Profile Editor, expand City, and then click the City
subnode.
BAM intercepts individual pieces of information during the execution of the
BizTalk processes, writing 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 Tracking Profile Editor.
Test BAM Functionality
1. In Windows Explorer, double-click C:\AllFiles\DemoCode\Module4BAM\Send20POs.bat.
2. In Internet Explorer, browse to http://BIZTALKDEMO:8080/BAM.
3. Maximize the Internet Explorer window.
4. In the My Views task pane, expand Aggregations, and then click Order Progress.
5. If the Microsoft Office 2003 Web Components dialog box appears, click OK.
6. In the pivot table, expand the Received, Approved, and Evaluation cells to show the
status of the various completed processes.
7. Notice the relationship between the data in the graph and the pivot table.
8. In Windows Explorer, double-click C:\AllFiles\DemoCode\BAM\Send20POs.bat.
9. Immediately switch back to Internet Explorer and refresh the page.
10. In the Microsoft Internet Explorer dialog box, click Retry.
11. Expand the Received, Approved, and Evaluation cells to show the status of the
various completed processes.
12. Notice that the counts have increased.
13. In the pivot table, right-click the cell that contains the total count for Fulfillment,
and then click Show Results.
14. Click any link in the City column.
15. In the My Views task pane, click OrderMgmt.
16. In the Query section, in the Business Data list, click City.
17. In the Value box, type LosAngeles.
18. In the Column Chooser section, select all the data and milestones, and then click
Add (>>).
19. Click Execute Query.
20. The details for each order in which the selected city was LosAngeles are displayed.
21. Double-click any row in the Results section, and notice that the level of detail is the
same as was seen previously.
22. Close Internet Explorer.
Scenario
BAM is a tool that is used to gather business data from archived and running business
processes. In this lab, you will use several tools, spanning multiple user roles, to configure
BAM to analyze data being processed by BizTalk Server.
Preparation
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.
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.
6. Navigate to C:\Program Files (x86)\Microsoft BizTalk Server 2010\ExcelDir, click
Bam.xla, and then click OK.
7. in the Add-Ins available list, check Business Activity Monitoring, then click OK.
8. In the Excel menu ribbon, on the Add-Ins tab, click BAM, and then click BAM
Activity.
9. In the Business Activity Monitoring Activity Definition dialog box, click New Activity.
10. In the Activity name box, enter OrderMgmt.
11. 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.
12. 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
Product
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.
13. 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.
5. In the New Measure dialog box, in the Measure name box, type AvgCycleDuration.
6. In the Base data item list, click CycleDuration (OrderMgmt).
7. 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 “\Program Files (x86)\Microsoft BizTalk
Server 2010\tracking”, and then press ENTER.
4. In the command prompt window, type bm.exe deploy-all -DefinitionFile:
“C:\AllFiles\LabFiles\Module 4 BAM\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
1. On the Start menu, click All Programs, click Microsoft BizTalk Server 2010, and then
click Tracking Profile Editor.
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 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
TheImplementationOfOrderMgmt.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 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.
then click OK.
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
TheImplementationOfOrderMgmt.OrderMgmtProcess, and then click OK.
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
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.
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.
then click OK.
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, verify that the profile was deployed
successfully, and then 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.
Procedure List
Configure SQL Server Analysis Services Proactive Caching
Procedure List
1. In Windows Explorer, navigate to C:\AllFiles\LabFiles\Module 4 BAM and doubleclick cfgBAMPart.cmd.
2. When prompted, press any key to close the command-line window..
This script configures SQL Server Analysis Services to refresh the OrderMgmt
OLAP cube every second. While this may be suitable in a development
environment, it would severely affect performance as the application processes
under heavier load.
Generate Initial Inbound Flow of Purchase Orders
Procedure List
1. In Windows Explorer, double-click the file C:\AllFiles\LabFiles\Module 4
BAM\Messages\Send20POs.bat.
The batch file used here generates 20 test orders so that you will have some data
to analyze in this exercise.
2. Close the Command Prompt window.
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\Module 4 BAM\ Messages\Send20POs.bat
to create and submit 20 new purchase orders.
Review the Detailed Status Information
Procedure List
1. Click the plus sign (+) to expand the function named Activity Search, and then click
OrderMgmt.
2. 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.
3. 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 5: Administering a BizTalk Server
Environment
Module objective:
Manage a BizTalk Server environment
Overview
Now that you have learned about installing and configuring Microsoft BizTalk Server 2010 in
your business environment and how to create and deploy BizTalk applications, the lessons in
this module will provide you with important information about how to administer your
BizTalk Server installation on an ongoing basis, as well as how to back up and restore your
computers running BizTalk Server in case of failure.
Lesson 1: Managing a BizTalk Server Group
Lesson objective:
Manage BizTalk Server group operations
Lesson Overview
BizTalk Server provides a number of administration features for managing multiple
computers running BizTalk Server. Most administration tasks can be performed by using the
BizTalk Server Administration Console. The topics in this lesson provide essential information
about managing BizTalk groups and databases, as well as working with BizTalk hosts and
host instances.
Identifying Server Operations Tasks
Identify common tasks when administering a BizTalk Server group
Overview
BizTalk Server provides the ability to coordinate application activity and transaction
processing; dynamically route messages, validate and transform data, apply encryption and
digital signatures, and transport data over a variety of adapters. The BizTalk Server
Administration Console allows you to manage and control multiple installations of BizTalk
Server.
Tasks that you can perform by using the BizTalk Server Administration Console include:

Adding and managing computers running BizTalk Server to a BizTalk group.

Configuring BizTalk group properties.

Adding and configuring MessageBox databases.

Creating hosts.

Creating and managing host instances that run on separate computers running

Configuring and managing adapters.

Creating and managing receive locations.

Creating and managing send ports and send port groups.

Enlisting and starting orchestrations and ports.
Managing BizTalk Groups
Identify common properties of a BizTalk Server group
Overview
A BizTalk Server group is an organizational unit that represents an enterprise, a department,
a hub, or other business unit that requires a contained BizTalk Server implementation.
Multiple computers running BizTalk Server can be in a single BizTalk group, but all servers in
the group share a BizTalk Configuration database (the BizTalkMgmtDb database).
The BizTalk Configuration database stores configuration information for the BizTalk group
and the servers in that group. The configuration information contained in this database
specifies part of the message-processing logic, such as BizTalk maps and orchestrations, as
well as where the logic will be physically executed.
BizTalk Group Properties
Many of the properties of the BizTalk group can be managed through the BizTalk Server
Administration Console, by right-clicking the group and then clicking Properties in the
context menu.
General Page
When storing and retrieving large messages from the MessageBox database or databases,
BizTalk Server supports fragmenting the messages which can significantly enhance runtime
performance. Fragmenting enables BizTalk Server to handle very large messages (for
example, messages that are several gigabytes [GB] in size). The following properties specify
when and how messages are to be fragmented:

Performance—Large Message Threshold (bytes). Messages of the specified size or
larger will be fragmented. The default is 102,400 bytes.

Performance—Large Message Fragment Size (bytes). This is the fragment size for
messages that will be fragmented. The default is 102,400 bytes.
In addition to the properties affecting large messages, the following properties can be
specified on the General tab as well:

SSO Server Name – This is the name of the Enterprise Single Sign-On (ESSO) server
that the BizTalk Server uses to connect to the encrypted Credential database. This
database contains all of the credentials used by all adapters to connect to their
respective endpoints, which unless encrypted would provide a possible security
vulnerability. This database is contacted each time BizTalk Server accesses the
adapters’ configuration information.

Performance – Cache Refresh (Seconds)l – This is the interval at which all items
stored in the administration cache, such as MessageBox databases, server
properties, adapters, and connections to the Tracking database are refreshed. The
default is 60 seconds and would not typically need to be changed.
Databases Page
This tab provides a read-only view of the principal databases in use by BizTalk as well as the
computer running Microsoft SQL Server™ on which they are located.
Certificate Page
This tab lists the digital signature certificate, including a certificate description and a
thumbprint of the certificate with which outbound messages will be signed. This certificate
must be added to the Personal certificate store on each computer running BizTalk Server for
the user account associated with the host that will be signing the messages. Certificates in
this store can be displayed by clicking the Browse button.
Managing the MessageBox Databases
Explain the importance of MessageBox databases and common administrative tasks associated
with MessageBox databases.
Overview
The MessageBox databases store the queues and state tables for each BizTalk host,
messages and message properties as well as message subscriptions and tracking
information. The databases also deliver the messages to the services that have matching
subscriptions.
Multiple MessageBox Databases
MessageBox databases are the basis for work-item load balancing across multiple
computers running BizTalk Server that perform cooperative processing. Initially, the BizTalk
Server group has a single MessageBox database. To increase the number of messages that
your system can process and to improve performance in general, you might eventually need
to create additional MessageBox databases. Multiple MessageBox databases, however, do
not provide fault tolerance. All MessageBox databases are treated as a single logical
MessageBox, with the Master MessageBox routing messages to the other databases for
storage.
When multiple MessageBox databases exist within a BizTalk group, a single physical
database, the Master MessageBox database, is responsible for performing all the routing,
while any additional databases store the messages. There is never a performance
improvement in creating a second MessageBox database. The improvement in performance
comes in the creation of the third and subsequent databases. For this reason, you should
have either one MessageBox database or three or more.
For example, when you have a single MessageBox database, it performs all the message
storage itself and no routing is necessary. When a second database is added, the roles are
split, with the first database (the Master MessageBox) doing the routing and the second
database storing the messages. This results in a slight performance decline, as the messages
are being handled twice. Adding a third MessageBox database now splits the load of storing
messages between two databases while the routing continues to be performed by the
Master.
Adding MessageBox Databases
Adding MessageBox databases is done in the BizTalk Administration Console, in the Platform
Settings section. Provide the SQL Server name and database name. The SQL Server Agent is
responsible for the execution of several scheduled jobs related to the MessageBox
databases; for this reason, the SQL Server Agent should be configured to start automatically
on any computers running SQL Server that will be hosting BizTalk MessageBox databases.
In situations where the MessageBox is experiencing deadlocks (multiple writes to the same
table being attempted at the same time), adding additional databases on the same instance
of SQL Server might be beneficial. When resources (memory, disk access speed, and so on)
on the instance of SQL Server become the bottleneck, you might consider adding
MessageBox databases to other computers running SQL Server. Once created, the new
databases will immediately begin receiving, storing, and routing messages to subscribers.
Disabling New Message Publication
If you want to create the MessageBox but not begin using it immediately or if you need to
take the computer running SQL Server where the database is maintained offline for
maintenance, you can disable new message publication by selecting the appropriate check
box in the MessageBox Properties window. This effectively takes the MessageBox offline
and disables any new messages being sent to it.
In situations where multiple MessageBox databases exist, it is generally beneficial to disable
new message publication on the Master MessageBox. This takes this database out of the
round-robin selection process used by BizTalk Server to determine where messages should
be routed and will generally improve performance.
Deleting MessageBox databases
Situations might arise in which you want to delete a MessageBox database from a BizTalk
group. For example, you might want to delete a MessageBox database used for a series of
tests now concluded. Deleting a MessageBox database from a BizTalk group does not
physically remove the database from the computer running SQL Server. To remove the
MessageBox database completely and permanently, you must remove it manually from
computer running SQL Server after it has been removed from the BizTalk group.
The steps to permanently and completely remove a MessageBox database from your BizTalk
deployment are as follows:
1. Disable new message publication on the MessageBox database you will be deleting.
2. Wait for the cache refresh interval to expire. The wait time is defined as twice the
length of the cache refresh interval, and the default cache refresh interval is 60
seconds. This value can be changed in the Properties window for the BizTalk group.
3. Delete the MessageBox database from the BizTalk group by using the BizTalk Server
4. Restart host instances that contain cached connections to the MessageBox
database.
5. Stop all in-process host instances that access the MessageBox database.
6. Ensure that any background SQL Server Agent jobs have finished executing.
7. Remove the MessageBox database from the computer running SQL Server.
You can also use Microsoft Windows® Management Instrumentation (WMI) to add, disable,
and delete MessageBox databases.
For more information, refer to the topic “Deleting a MessageBox Database” in the BizTalk
Server 2010 documentation.
What Is a BizTalk Host?
Explain the purpose of BizTalk Server hosts and common administrative tasks associated with
hosts.
BizTalk Host
A host is a logical container representing one or more BizTalk Server run-time instances.
Hosts are virtual process boundaries that provide an administrative and a security context
for running instances of a BizTalk application. A BizTalk host provides a container for items
such as adapter handlers, receive locations (including pipelines), and orchestrations.
Host Types
BizTalk offers two types of hosts, In-Process and Isolated. When the first computer running
BizTalk Server is installed for a BizTalk group, one host of each type is created. The physical
configuration and the type of adapter will determine which host must be used.
In-Process Hosts
By default, a BizTalk installation creates an In-Process Host (BizTalkServerApplication) that is
used for most host-related functions. The In-Process Host is implemented as a Microsoft
Windows NT service (BTSNTSvc.exe) and is associated with all orchestrations, send handlers,
and most receive handlers. In-Process Hosts have the following characteristics:

Orchestrations must be run under an In-Process Host.

Built-in send handlers must use In-Process Hosts.

Only adapter receive handlers associated with In-Process-type adapters such as the
File and MSMQ adapters are supported.

The first In-Process Host you create in a BizTalk Server 2010 deployment is the
default host and you cannot delete it, although another In-Process Host can be
defined as being the default.
Isolated Hosts
The Isolated host is used in conjunction with the HTTP and some WCF receive handlers.
Isolated Hosts have the following characteristics:
They primarily host adapters that are designed to run outside of the normal BizTalk Server
runtime process; for example, external processes such as IIS application pools.
Used with adapters which are hosted in a process other than the BizTalk process including
socket adapters and many application adapters. These adapters run in their own space and
send BizTalk the results of their findings.
The default Isolated Host is associated with the HTTP adapter and the WCF adapters that run
in the Internet Information Services (IIS) process.
Isolated Hosts cannot be the default host.
When viewed in BizTalk Server Administration Console, these hosts always have a status of
Status Unavailable since BizTalk Server does not access the status information of external
processes.
Creating Hosts
Any items running in a host (for example, orchestrations, pipelines, and receive and send
handlers) run under the same identity and have access to the work and suspended queues
for that host. As a result, it is recommended that you create different hosts for each function
to provide security boundaries for different applications and to make management of the
BizTalk hosts more granular. In particular, it is recommended that you use different hosts for
orchestration processing and for receive and send functionality. You should also separate
trusted and untrusted items.
The Advanced Property page for each host in the BizTalk Administration Console has
properties that can be set to restrict (throttle) BizTalk processing to ensure that system
resources are employed optimally and that the host performance does not deteriorate as a
result of higher messaging loads.
Creating BizTalk Host Instances
Explain the purpose of host instances, including the relationship between host instances and
hosts.
What is a host instance?
A host instance is the physical installation of a host on a BizTalk Server computer. An
administrator can use either the BizTalk Administration console or Windows Management
Instrumentation (WMI) to install host instances. Each BizTalk Server in a group can support
multiple host instances, though only a single instance of each host.
Adding Host Instances
After you create a host, you can associate one or more computers running BizTalk Server
with this host. Each association is known as a host instance and can run any processes
associated with the host. Although each host can have multiple instances (running on
separate computers running BizTalk Server), each server can have at most one instance of a
given host.
When adding a new instance of the host, the server names and logon credentials must be
provided. The account specified here must be a member of the group identified when the
host was created. Members of that group have permissions to execute this host. After an
instance is added, a new Windows NT service (BTSNTSrrv.exe) will be added to the computer
running BizTalk Server named BizTalk Service BizTalk Group: NewHostName, which is
configured to start automatically.
There are also four possible status states in the Installation Status column in the results pane
for hosts in the BizTalk Administration Console:

Installation failed – This status is displayed when BizTalk Server cannot install the
host instance. In order to install a host, you must have privileges to create a
Windows service, and to grant SQL Server logon and access rights for the BizTalk
databases to the Host Windows user group. You might also get this error if network
problems interrupted the installation.

Installed – You installed the host instance successfully.

Un-installation failed – Deleting the host instance failed.

Not installed – No host instances are installed.
Host Instance Status
Host instances can be in one of the following statuses as shown in the Status column:

Start pending – A host instance is in this state when you have started the host
instance but there is some delay between starting the host instance and the change
taking effect. Click the refresh button to see the status change.

Running – The host instance is currently running.

Stopped – The host instance is currently stopped.

Status Unavailable – This status displays for a host when the host instance install or
uninstall fails or when BizTalk Server cannot retrieve status information for that
host. Isolated hosts display Status Unavailable because the processes it contains are
external to BizTalk Server.
Demonstration: Managing BizTalk Server Operations
In this demonstration, you will see how to view global properties for an adapter, create a new
host and host instance, change the host used by an orchestration, and create a new MessageBox.
To Examine Global Properties for Adapters
2. Expand BizTalk Server 2010 Administration, expand BizTalk Group, expand
Platform Settings, and then expand Adapters.
The global settings for BizTalk adapters are considered the default configuration
for all instances of the adapter. However, these settings can be overridden at the
port level.
3. Click FTP.
4. In the right pane, double-click the Receive direction handler.
5. In the Adapter Handler Properties dialog box, click Properties.
Configuring adapter properties at the BizTalk Group level prevents you from
having to duplicate settings each time an adapter is configured to be used by a
port.
6. Notice the sections for the Batch, Firewall, FTP, and Tuning Parameters settings.
7. Click OK twice.
8. In the BizTalk Server Administration Console dialog box, click OK.
9. In the left pane, collapse Adapters.
To Create a New BizTalk Host
1. In the left pane of the BizTalk Server Administration Console, click Hosts.
2. Right-click Hosts, point to New, and then click Host.
3. In the Name field, type NorthwindDedicatedHost.
4. In the Windows group field, type ADVENTUREWORKS\BizTalk Application Users.
5. Click OK.
To Create a New BizTalk Host Instance
1. In the left pane of the BizTalk Server Administration Console, click Host Instances.
2. Right-click Host Instances, point to New, and then click Host Instance.
3. Set the Host name to NorthwindDedicatedHost, and then set Server to
BIZTALKDEMO.
4. Click Configure.
5. In the Logon Credentials dialog box, type BizTalkHost as the logon name and
pass@word1 for the password.
6. Click OK.
7. In the right pane, right-click NorthwindDedicatedHost, and then click Start.
To Change the Host Used by an Orchestration
1. In the left pane of the BizTalk Server Administration Console, expand Applications,
and then expand Module5.
2. Right-click the Module5 application, and then click Stop.
3. In the Stop ‘Module5’ Application dialog box, click Full Stop – Terminate instances,
4. Click Orchestrations, and then double-click
Orders.OrderProcesses.NorthwindProcessOrderType.
5. In the Orchestration Properties dialog box, click Bindings in the left pane, and then
click NorthwindDedicatedHost in the drop-down list.
6. Click OK.
7. Right-click the Module5 application, and then click Start.
To Test the Orchestration Running on the New Host
1. In Windows Explorer, navigate to C:\AllFiles\DemoCode\Module5\Northwind
Messages.
2. Copy and paste CustomerOrder1.xml into this folder.
The application is configured to pick up all XML files that end with Copy. The
Copy of CustomerOrder1.xml file disappears, and three new messages appear.
3. Rename the ReqSupA{GUID}.xml message to Resp ReqSupA{GUID}.xml.
The orchestration is waiting for a response. The port is configured to pick up all
XML files that begin with Resp. The Resp ReqSupA{GUID}.xml file disappears,
and a Completed{GUID}.xml file appears.
To Create a New MessageBox Database
1. In the left pane of the BizTalk Server Administration Console, under Platform
Settings, click Message Boxes.
2. Right-click Messages Boxes, point to New, and then click Message Box.
3. In the Message Box Properties dialog box, type BIZTALKDEMO in the SQL server
field, and then type BizTalkMsgBoxDb2 as the Database.
4. Click OK.
Having two MessageBox databases will result in decreased performance. A
BizTalk group should have either a single database or more than two.
Scenario
You can create additional BizTalk hosts and MessageBoxes to provide for scalability and
security. In this lab, you will create a new BizTalk host. You will also create a new BizTalk
MessageBox database.
Procedure List
window.
Start.
Procedure List
Exercise 1: Manage BizTalk Hosts
Overview
BizTalk hosts provide the context that BizTalk Server components (orchestrations and ports)
run under. Using multiple hosts can provide scalability and security for the BizTalk Server
environment. In this exercise, you will create a new BizTalk host, an instance of the host, and
then reconfigure an orchestration to use the new host instance.
Create a New BizTalk Host and Host Instance
Procedure List
2. Expand BizTalk Server 2010 Administration, expand BizTalk Group, and then
expand Platform Settings.
5. In the Name field, type PurchaseOrderProcHost.
6. Select the Authentication Trusted check box.
7. In the Windows group field, type ADVENTUREWORKS\BizTalk Application Users,
and then click OK.
8. In the left pane of the BizTalk Administration Console, click Host Instances.
10. Set the Host name to PurchaseOrderProcHost, and then set Server to BI
ZTALKDEMO.
11. Click the Configure button.
12. In the Logon Credentials dialog box, type ADVENTUREWORKS\PurchaseOrderHost
as the logon name and pass@word1 as the password.
13. Click OK twice.
Change the Host Instances Used by an Orchestration
Procedure List
1. In the left pane of the BizTalk Administration Console, right-click BizTalk Group, and
then click Refresh.
2. Expand Applications, and then expand Module 5.
3. Click Orchestrations, right-click ProcessOrder.OrchProcessOrder, and then click
Unenlist.
4. Double-click ProcessOrder.OrchProcessOrder.
5. In the Orchestration Properties dialog box, click Bindings in the left pane, then click
PurchaseOrderProcHost in the Host list, and then click OK.
6. Right-click the Module 5 application, and then click Start.
Exercise 2: Manage MessageBoxes
Overview
Multiple Messagebox databases can be used to provide scalability for your BizTalk
environment.
For performance reasons, when you add a second MessageBox database to the BizTalk
group it is recommended that a third be created as well. In this exercise, you will create a
second BizTalk MessageBox.
Create an Additional Message Box Database
Procedure List
1. In the left pane of the BizTalk Administration Console, under Platform Settings, click
Message Boxes.
box, and then type BizTalkMsgBoxDb2 in the Database box.
4. Click OK.
Lesson 2: Lesson: Backing Up and Restoring BizTalk Server
Lesson objective:
Backup and restore a BizTalk Server computer
Overview
To guard against the possibility of irrecoverable loss of business-critical data, you must
perform backups of your computer running BizTalk Server on a regular basis.
Backing Up a BizTalk Server Computer
Explain the process of backing up a BizTalk Server environment.
Backup procedures and schedule
You must perform backup procedures on a regular schedule in order to ensure your ability
to restore a consistent BizTalk environment in the event of data loss. BizTalk Server performs
distributed transactions across multiple databases, so it is of critical importance that you
back up and then restore all databases to exactly the same state. You use the SQL Enterprise
Manager to backup and restore a computer running BizTalk Server.
Important: Do not store your backup files in the same storage system where the database
resides, because then in the event of a failure both the backups and the databases would be
lost.
Backup BizTalk Server job
BizTalk Server requires a customized backup process that uses full database backups and full
transaction log backups, in conjunction with log marking and distributed transactions. This
process, the Backup BizTalk Server job, runs as scheduled by the SQL Agent service. You use
the Backup BizTalk Server job to back up all of your databases except the BAM Analysis
database and the Tracking Analysis Server database, which you back up by using SQL
Analysis Manager. Refer to the BizTalk Server 2010 documentation under Database Backup
and Recovery for a full list of all the BizTalk Server databases that are backed up by the
Backup BizTalk Server job.
BizTalk Server 2010 includes a SQL Server role named BTS_BACKUP_USERS so that the user
account you use to back up your databases does not require System Administrator
permissions within SQL Server, except for the primary server controlling the backup process.
When setting up the user account that you are using to back up your databases, you must
configure the SQL Server Agent service to run under a domain account or a local account
with a mapped user on each instance of SQL Server.
You must configure a SQL Server logon account for this user and assign this user to the
BizTalk BTS_BACKUP_USERS role on each server.
You must assign this user to the System Administrators role within SQL Server for the BizTalk
Management database server.
Please refer to the BizTalk Server 2010 documentation for detailed steps on Configuring the
Backup BizTalk Server Job.
The Backup BizTalk Server job does not delete outdated backup files, so you need to manage
those backup files to conserve disk space. After you have created a new full backup of your
databases, you should move the outdated backup files onto an archival storage device to
reclaim space on the primary disk.
Also, BizTalk Server does not write tracking data directly to the BizTalk Tracking database;
rather it caches the data in the MessageBox database and then moves it to the BizTalk
Tracking database. In the event of a MessageBox data loss, some tracking data may be lost.
Running Synchronized BizTalk Server Back Ups
Explain advanced options for performing a backup of a BizTalk Server environment.
Synchronized backups
BizTalk Server makes it possible for you to run synchronized backups of all BizTalk databases.
You synchronize your backups by using both full database backups and transaction log
backups in conjunction with a mechanism called a marking transaction. For each BizTalk
database, the Backup BizTalk Server job creates a transaction log backup every time it runs,
and creates a full backup only at the specified periods.
Marking transactions
Marking transactions are transactions that insert a mark into the transaction log of each
database participating in the transaction. The marking transaction first blocks new
distributed transactions from starting, then waits for currently running distributed
transactions to complete, and finally executes to place the mark.
The mark represents a point that is transactionally consistent across all databases; you can
use a specific mark in conjunction with subsequent transaction log backups to restore all of
your databases to the same consistent point.
Full backups
The Backup BizTalk Server job runs its first step, BackupFull, only once every period, not
every time the job runs. You must specify the period: hourly, daily, weekly, monthly, or
yearly.
The first time Backup BizTalk Server runs during a newly specified period, it performs a full
backup. For example, if you schedule the job to run every hour, but configure the period as
daily, then Backup BizTalk Server performs a full backup the first time it runs, and thereafter
once every day at midnight.
Transaction log backups
The second step that the Backup BizTalk Server job performs is MarkAndBackupLog. Each
time the job executes, this second step inserts a mark into each BizTalk database, and also
performs a transaction log backup.
You will also want to configure log shipping to provide warm standby server capabilities
which reduce downtime in the event of a system failure.
For more information, please refer to the BizTalk Server 2010 documentation on Configuring
the Log Shipping Destination System.
Restoring a BizTalk Server Computer
Restoring a BizTalk Server environment from a backup.
Restoring a database
If you do not restore all BizTalk databases to the same mark, then your BizTalk Server
environment will be in an inconsistent state and may not work correctly.
To restore a database:
Working in SQL Enterprise Manager and using the NORECOVERY option, restore all
databases by using the most recent full database backup set after which at least one further
log backup set was created.
Using the NORECOVERY option again, restore all log backups created between the full
backup set used in step 1 and the most recent log backup. Do not restore the last (most
recent) log backup yet. If only one log backup was created after the most recent full backup,
skip this step.
Using both the RECOVERY option and the STOPATMARK option, restore all log backups from
the most recent log backup set. STOPATMARK must specify the BizTalk Server log mark that
is contained in the log. (The log mark is part of the backup file name.)
Example
For example, assume that the following backup sets exist:
01:00 (full & log), 01:15 (log only), 01:30 (log only), 01:45 (log only),
02:00 (full & log), 02:15 (log only), and 02:30 (log only).
To restore your databases, you would perform the following procedure:

Using NORECOVERY, restore all of the databases from the 2:00 full backup set.

Using NORECOVERY again, restore the log backups from the 2:15 log backup set.

Using both RECOVERY and STOPATMARK now, restore the log backups from the 2:30
log backup set.
For more information on mark names and restoring your BizTalk Server environment, refer
to the BizTalk Server 2010 documentation on Restoring Your Databases.
Demonstration: Backing Up a Computer Running BizTalk Server
Show how to back up and restore a computer running BizTalk Server.
In the following task you will delete the BizTalk Server databases, if you have trouble
deleting them, ensure that all applications are fully stopped and that there are no running,
suspended, or dehydrated instances. Also, the MessageBox databases should be deleted and
restored together.
Back Up BizTalk Databases
1. On the Start menu, point to All Programs, point to Microsoft SQL Server 2008, and
then click SQL Server Management Studio.
2. In the Connect to Server dialog box, click Connect.
3. In Object Explorer, expand SQL Server Agent, and then click Jobs.
4. In the right pane, right-click the Backup BizTalk Server job, and then click Properties.
5. In the Job Properties - Backup BizTalk Server (BizTalkMgmtDb) dialog box, click the
Steps tab, select BackupFull, and then click the Edit button.
6. On the General tab, in the Command box, edit the command by changing
‘<destination path>’ to ‘C:\AllFiles\DemoCode, and then click OK.
To avoid potential data loss, you should specify a computer for your backup that
is different from the computer with the original data.
7. On the Steps tab, click MarkAndBackupLog, and then click Edit.
‘<destination path>’ to ‘C:\AllFiles\DemoCode’, and then click OK.
To avoid potential data loss, you should specify a computer to store the database
logs that is different from the computer with the original database logs.
9. On the Steps tab, click Clear Backup History, and then click Edit.
10. On the General tab, in the Command box, notice the DaysToKeep=14 option, which
indicates that the backup history will be kept for 14 days, and then click Cancel.
11. In the Job Properties - Backup BizTalk Server (BizTalkMgmtDb) dialog box, click the
Schedules tab, select MarkAndBackupLogSched, and then click the Edit button.
12. Review the Job Schedule Properties dialog box—by default, this job is scheduled to
run every 15 minutes of every day.
13. Click One Time in the Schedule type list, and then click OK.
This will schedule the job to run immediately.
14. In the Job Properties - Backup BizTalk Server (BizTalkMgmtDb) dialog box, click OK.
15. In Microsoft SQL Server Management Studio, right-click Backup BizTalk Server
(BizTalkMgmtDb), and then click Enable.
16. In the Enable Jobs dialog box, click Close.
(BizTalkMgmtDb), and then click Start Job.
18. In the Start Job on ‘BIZTALKDEMO’ dialog box, click Start at step.
19. In the Start Jobs dialog box, after the job has completed, click Close.
Restore the BizTalk Databases
1. On the Start menu, point to Administrative Tools, and then click Services.
2. Right-click Enterprise Single Sign-On Service, and then click Stop.
3. Right-click Stop Other Services dialog box, click Yes.
4. In Microsoft SQL Server Management Studio, click Databases, and in the right pane,
select and delete the following databases: BAMPrimaryImport, BizTalkDTADb,
BizTalkMgmtDb, BizTalkMsgBoxDb, BizTalkMsgBoxDb2, BizTalkRuleEngineDb, and
SSODB.
5. In the Delete Objects dialog box, select the Close existing connections checkbox,
and then click OK.
7. Expand BizTalk Server 2010 Administration, and then click BizTalk Group.
8. An error message appears because the BizTalkMgmtDb database does not exist.
Close the BizTalk Server Administration Console.
9. In Microsoft SQL Server Management Studio, right-click Databases, and then click
Restore Database.
10. In the To database box, type BAMPrimaryImport, click From device, and then click
the ellipsis (…) button.
11. In the Specify Backup dialog box, click Add.
12. In the Locate Backup File dialog box, navigate to C:\AllFiles\DemoCode select
BIZTALKDEMO_BAMPrimaryImport_Full_BTS….bak, and then click OK.
13. In the Specify Backup dialog box, click OK.
14. In the Restore Database dialog box, select the Restore check box, and then click the
Options tab.
15. On the Options tab, select Overwrite the existing database, and then click OK.
16. In the Microsoft SQL Server Management Studio dialog box, click OK.
17. Repeat the preceding steps for the following databases:
To database
Backup file
BizTalkMsgBoxDb2
BIZTALKDEMO_
BizTalkMsgBoxDb2_Full….bak
BizTalkDTADb
BIZTALKDEMO_ BizTalkDTADb_Full….bak
BizTalkMgmtDb
BIZTALKDEMO_ BizTalkMgmtDb._Full….bak
BizTalkMsgBoxDb
BIZTALKDEMO_ BizTalkMsgBoxDb_Full….bak
BizTalkRuleEngineDb
BIZTALKDEMO_
BizTalkRuleEngineDb_Full….bak
SSODB
BIZTALKDEMO_ SSODB_Full….bak
18. Close Microsoft SQL Server Management Studio.
The BizTalk Server databases have been restored to their previous states.
Scenario
All BizTalk implementations should include a comprehensive recovery plan that includes
database backup and restoration procedures. In this lab, you will back up the BizTalk Server
databases. To test the backups, you will delete all the databases from SQL Server and then
restore them from the backups.
Preparation
Exercise 1: Back Up BizTalk Databases
Overview
When the BizTalk Server configuration is performed and as the databases are created on a
computer running SQL Server, a SQL Server agent job is also created. This job automates the
process of backing up the BizTalk databases. A schedule to perform both full and
incremental backups of these databases should be enabled. In this exercise, you will perform
a full back up the BizTalk Server databases.
Configure the SQL Server Job
Procedure List
3. In Object Explorer, expand SQL Server Agent and Jobs.
4. Right-click the Backup BizTalk Server job, and then click Properties.
5. In the Job Properties - Backup BizTalk Server (BizTalkMgmtDb) dialog box, on the
Steps page, select BackupFull, and then click the Edit button.
6. On the General page, in the Command box, edit the command by changing
‘<destination path>’ to ‘C:\AllFiles\LabFiles\Module 5\BizTalkBackup’, and then
click OK.
To avoid potential data loss, you should actually specify a computer for your
backup that is different from the computer with the original data.
7. On the Steps page, click MarkAndBackupLog, and then click Edit.
‘<destination path>’ to ‘C:\AllFiles\LabFiles\Module 5\BizTalkBackup\Logs’, and
then click OK.
Note that ‘Module 5’ within this path contains a space character.
9. On the Steps page, select Clear Backup History, and then click Edit.
10. On the General page, in the Command box, notice the DaysToKeep=14 option,
which indicates that the backup history will be kept for 14 days, and then click
Cancel.
Schedule the Backup BizTalk Server Job
Procedure List
Schedules page, select MarkAndBackupLogSched, and then click the Edit button.
3. Click One time in the Schedule type list, and then click OK.
Back Up the BizTalk Server Databases
Procedure List
2. In the Enable Jobs - BIZTALKDEMO dialog box, click Close.
(BizTalkMgmtDb), and then click Start Job at Step.
4. In the Start Job on ’BIZTALKDEMO’ dialog box, click Start.
5. In the Start Jobs - ‘BIZTALKDEMO’ dialog box, after the job has completed
successfully, click Close.
Exercise 2: Delete and Restore the BizTalk Databases
Overview
A careful disaster recovery plan should include occasional test restorations of the BizTalk
databases. In this exercise, you will delete the BizTalk databases, and then restore the
databases from the back up created in the previous exercise.
Delete Existing BizTalk Databases
Procedure List
2. Right-click Enterprise Single Sign-On Service, click Stop, and then click Yes in the
Stop Other Services dialog box.
3. In Microsoft SQL Server Management Studio, in Object Explorer, click Databases,
then in the View menu, click Object Explorer Details.
4. In the right pane, click each of the following databases while holding down the CTRL
key: BAMPrimaryImport, BizTalkDTADb, BizTalkMgmtDb, BizTalkMsgBoxDb, and
BizTalkMsgBoxDb2.
5. Right-click the selected items, and then click Delete.
and then click OK.
7. In the left pane, click Databases, then press the F5 key to refresh the view, and then
verify that the databases are no longer listed.
An error message appears because the BizTalkMgmtDb database does not exist.
If the BizTalk Administration Console was already open, then you will need to
press the F5 key to see the error message.
10. Close the BizTalk Server Administration Console.
Restore the BizTalk Database
Procedure List
Restore Database.
4. In the Locate Backup File dialog box, navigate to C:\AllFiles\LabFiles\Module
5\BizTalkBackup, select BIZTALKDEMO_BAMPrimaryImport_Full_BTS….bak, and
then click OK.
6. In the Restore Database dialog box, in the Select the backup sets to restore list,
select the Restore check box, and then click the Options tab.
8. In the Restore Database dialog box, click OK.
9. In the Microsoft SQL Server Management Studio dialog box, verify that the message
states that the database was restored successfully, and then click OK.
To database
Backup file
BizTalkMsgBoxDb2
BIZTALKDEMO_
BizTalkDTADb
BizTalkMgmtDb
BizTalkMsgBoxDb
12. In the Services window, right-click Enterprise Single Sign-On Service, then click
Start.
14. Expand BizTalk Server 2010 Administration, BizTalk Group, and Applications.
15. Right-click Module 5 and then click Stop.
16. In the dialog box click Stop.
18. In the dialog box click Start.
Procedure List
2. Copy the ContosoPO_Large.xml file to the PurchaseOrderIN folder.
3. After the message disappears from the PurchaseOrderIN folder, navigate to the
PurchaseOrderAck folder, and notice the PoAck{GUID}.xml message.
4. Navigate to the Shipped folder, and notice the and the Shipment{GUID}.xml
message.
5.
Close all open windows, and shut down the virtual machine.
Module 6 (Optional): Monitoring a BizTalk
Environment with System Center
Operations Manager (SCOM)
Module objective:
How to monitor a BizTalk environment using System Center Operations Manager (SCOM)
Overview
Now that you have learned how to install, configure and administrate Microsoft BizTalk
Server 2010, it is time to learn how to monitor your BizTalk environment. This will ensure it
is healthy and performing up to your organization’s expectations. Microsoft System Center
Operations Manager (SCOM) is a monitoring platform that allows for proactive and reactive
monitoring of applications, servers, network devices and hardware. The purpose of this
module is for students to get introduced to SCOM and learn how to monitor their BizTalk
environment using the Microsoft BizTalk Server 2010 Management Pack (MP) for System
Center Operations Manager.
Lesson 1: Introduction to SCOM
Lesson objective:
Learn about the System Center Operations Manager platform and discover the benefits that it
can provide when monitoring BizTalk Server.
Lesson Overview
Microsoft System Center Operations Manager is platform used for proactive and reactive
monitoring. It provides an end to end monitoring solution for both Microsoft and nonMicrosoft technologies. The topics in this lesson provide essential information about
monitoring BizTalk groups, databases and underlying foundational components required to
have a healthy BizTalk environment.
SCOM Overview
Identify core features and capabilities
Overview
Microsoft System Center Operations Manager is a mature, enterprise grade monitoring
platform for both Microsoft and non-Microsoft technologies. As of May 2011, the current
version of SCOM is 2007 R2 which is the 4th version of the product. The next version of
SCOM is called System Center Operations Manager 2012 and is set to be released in the last
half of 2011.
SCOM leverages Windows Management Instrumentation (WMI), Performance Counters and
Event Viewers when determining the health of an application or server. Network device
monitoring is accomplished by using Simple Network Management Protocol (SNMP).
Core monitoring scenarios include:

Client, Server and Device Monitoring is provided through the use of Management
Packs. Management Packs contain the rules and thresholds that determine the
health of a particular application or server.

Security Audit Collection provides the ability to consolidate Security logs from
Windows Servers for auditing purposes such as for Sarbanes-Oxley (SOX).

Client Monitoring allows end user system crash and diagnostic data collection to be
sent to the SCOM Management server.

Service Oriented Monitoring provides the ability to determine inter-dependencies
between applications when determining the overall health of a distributed system.

Knowledge Management capabilities exist as administrators have the ability to add
to the existing Knowledge base with new information. This feature becomes a
valuable tool when identifying resolutions to specific alerts that have been raised.
SCOM Architecture
Identify core Architectural Components
Overview
System Center Operations Manager is a large monitoring platform made up of many
components. For the purpose of a BizTalk Administration course, we will simplify into three
areas:



Root Management Server
Management Components
Scripting Components
Root Management Server
The Root Management Server to SCOM is the MessageBox to BizTalk Server. It represents
the “brains” of the monitoring platform and hosts the following three Services:



SDK Service provides a software development kit but also acts as a central point of
access for SDK connectivity.
The Config Service provides a single point access for all resources requesting
configuration information from Ops Manager database.
Many out of the box Management Packs include Workflow, such as Health Watch
Instances. These workflows will run within the Health service on the Root
Management Server.
Management Components
Management Components provide administrators and operations staff with tools that allow
them to monitor their respective systems. These tools include Command Shells, such as
PowerShell cmdlets, Thick and Web Consoles. Developers also have the ability to build
custom applications that take advantage of SCOM’s API.
Scripting Components
Scripting Components allow for communication between end points and the Root
Management Server. These components come in a few forms:

When a server has been configured to be Agent Managed, it means that a System
Center agent, or Health Service, has been installed on the actual server. Through a
discovery process, SCOM will be able to detect what types of software exists on the
server and gives SCOM administrators the ability to select whether or not they
would like SCOM to monitor it. This discovery process requires appropriate
management packs to be installed on the SCOM Root Management Server. For
instance if we wanted to monitor a BizTalk Server, we would need to have the
BizTalk Server Management Pack installed on the SCOM RMS server. We then
deploy an Agent to the BizTalk Server and will have the ability to monitor it through
SCOM.

In situations where you do not want to install an Agent on the endpoint that you
would like to monitor, you may be able to still monitor the server in a Non-Agent
Managed, or agent-less, fashion. Do note that not all Management Packs can be
used in an agentless mode including the BizTalk Server Management Pack.
Agentless monitoring cannot take advantage of Event Log providers and since the
BizTalk 2010 Management pack does rely upon the Event Log provider, monitoring
BizTalk Servers in an agentless manner is just not possible.

Microsoft has provided the ability for Independent Software Vendors (ISVs) to build
Management Packs for both Microsoft and Non-Microsoft technologies. Since
SCOM is an enterprise grade system, Microsoft felt it was important to provide
monitoring capabilities to non-Microsoft technologies as well as their own. In
addition to 3rd Party management packs, Microsoft also provides the ability to
integrate SCOM with other 3rd party Monitoring solutions and Help Desk solutions
through the use of Connectors.
SCOM Architecture (continued)
This slide provides a visual representation of the topics that were discussed previous slide. What
is important to note is just how comprehensive the SCOM platform is.
Data
Another important topic that was not discussed in the previous slide is where all of the data
the SCOM is collecting is stored. The default behavior for collecting diagnostic information
about the systems that you are monitoring is 7 days. It is recommended that if you need to
retain data for longer than this time frame that you implement a Reporting Warehouse. By
implementing a Reporting Warehouse, we have the ability to aggregate trend and
performance data that can be used for reporting purposes.
SCOM Console
Explain the purpose of the SCOM Console and introduce the two versions
SCOM Consoles
Much like Microsoft has provided an Administration console for BizTalk Developers and
Administrators, they have also provided a console for administering SCOM. The target
audience for these consoles are SCOM administrators but also other Support personnel
including BizTalk Administrators.
The purpose, of these consoles, is to provide the following features:




Viewing overall Health of an environment that we are monitoring
Alert Management including the creation, suppression and resolving of alerts
generated
Performance Monitoring of endpoints
Rule and Monitor Authoring. In addition to the Microsoft and 3rd Party management
packs that are available, we also have the ability to write our own Management
packs which may include custom Rules and Monitors. Rules are used to collect
performance related data where Monitors are actually determining the state of a
particular component. In the BizTalk world, we could think of a rule when we have a
message that has failed validation within a Pipeline event. There is no state to this
event, it either passed validation or failed validation and once the event has
occurred it will not change. A monitor works differently, the component that the
monitor is watching may change state. This state change may alter the overall
health of that component. An example of this situation would be a Host instance
that is currently offline. In this case the Monitor would determine this Host’s health

status to be critical(red). However once this host instance comes back online, a
monitor will discover this change and report the Host’s health is now in a healthy,
green state.
Another important function that the SCOM Console provides is the ability to install a
Management Pack such as the BizTalk Management Pack.
SCOM Console – Web Console
Explain the capabilities that are lost by using the Web Console
Web Console
The SCOM Web Console is a zero foot print console that is better suited for Application and
Infrastructure support teams who have monitoring needs but not Administration needs. The
reason for this is that it does not provide Administration functions like Management Pack
installations or Rule/Monitoring Authoring.
Even though the console is displayed in a browser, the console is still role based aware. If
your role includes access to information pertaining to BizTalk Servers, then you will only be
able to access this same information inside the Web Console. Also, if you have created any
custom views, you will be able to view these custom views in the Web Console.
The Web Console also has a restriction on the amount of data that is returned to the client
by default. For instance if we have 500 alerts in our Operations Console, only 200 will be
available in the Web Console.
SCOM Console – Thick Client Console
Explain the capabilities that are gained by using the Thick Client Console
Thick Client Console
The Thick Client Console requires a software installation and is intended for SCOM
administrators who need to take advantage of all of the features that are provided including:



The ability to create, modify or delete rules and monitors
Installing Management Packs
Running the Discovery Process against new servers added to the environment
For the purpose of this module we are going to focus on the Thick Client Console as installing
the BizTalk Management Pack is one of the key takeaways of this module. Other key
takeaways including learning about the following core features of SCOM:

Monitoring

Authoring

Administration

My Workspace
SCOM Console – Monitoring
Explain the general concepts of Monitoring
Monitoring
Monitoring is one of the key features that is provided by System Center Operations
Manager. Within the Monitoring view we have the ability to:

Review and close Active Alerts

Launch Health Explorer which will probe the source of the alert and any
dependencies to determine if the issue still exists or if it has been resolved.

Search the Discoverable Inventory. This feature becomes extremely useful when
trying to find a particular set of servers based upon standard naming convention.

Creating Synthetic transactions allow us to create ping, or heartbeat, processes that
will determine whether resources are online such as databases or web sites.
SCOM Console – Authoring
Explain the importance of Rules and Monitors and why Authoring is important
Authoring
Authoring provides SCOM Administrators with the ability to create custom Rules and
Monitors. In addition to creating Rules and Monitors, SCOM Administrators also have the
ability to override existing Rules and Monitors. When creating overrides, a Custom
Management pack should be created in order to store the override. Otherwise an update to
the original Management Pack may overwrite your custom override.
In the event that a Management Pack does not provide coverage for your specific scenario
or you have a custom application, a custom Rule or Monitor may be created and saved in a
Custom Management pack. For example, we may write events to the Event Viewer from
within our BizTalk application. If we wanted to generate alerts whenever these events
occur, we could write a custom rule that will monitor the Event Log for any occurrences of
this event.
SCOM Console – Administration
Explain the operations that exist within the Administration node
Administration
The Administration view provides operations that are essential in establishing and
maintaining a functional Monitoring Platform. Within this view we will find operations such
as:
 Device Management which provides us with visibility into the types of devices that
are being monitored such as Servers or Network devices. We also have the ability to
see if these devices are being monitored by Agents or through an Agentless
mechanism.

The management of Management Packs is also fulfilled through the Administration
view. Through this operation, we have the ability to Create, Delete, Download and
Import management packs.

Notification Management is provided in this view as well. Within this menu we have
the ability to create Notification channels such as Email, Instant Messaging (IM), Text
Messaging (SMS) or run a command line operation. We also have the ability to
create subscriptions that will use these channels, or transports, to deliver the
alertnotification. This allows us to create email notifications whenever a particular
event occurs. For instance if a Host Instance going offline was a significant event for
an organization, we could create a subscription whenever this event occurs. Any
subscribers for this event would receive an email notification, or SMS text message,
so that they would be aware of the issue.

The Discovery Wizard provides SCOM administrators with the ability to discover new
devices that can be added to SCOM’s inventory for monitoring purposes. Using this
wizard provides administrators the ability to scour a corporate network or browse to
a specific machine name. Once discovered, we can push an agent or configure it to
be monitored without an agent.
Demonstration: Navigating the System Center Operations Manager Console
In this demonstration, you will learn to navigate the SCOM Console and some fundamental
concepts required when monitoring BizTalk Servers.
Launch System Center Operations Manager console
Procedure List
1. On the Start menu, point to All Programs, point to System Center Operations
Manager 2007 R2, and then click Operations Console.
Determine if a Server is being monitored
1. In the left pane of the System Center Operations Manager Console, click on the
Monitoring view button.
2. Since we are interested in Windows based Computers, click on the Windows
Computers label in the left pane underneath Monitoring.
3. In the center pane we should discover that our BizTalk Lab machine called
BIZTALKDEMO is currently being monitored.
4. If an organization has many servers being monitored, we can take advantage of the
Find feature by typing in a partial server name in the Look for: text box and by
clicking on the Find Now button.
5. In the center pane, all servers that match our criteria will be displayed. We will see
some basic information about the status of our servers including:

State

Whether or not our Server is in Maintenance Mode

Server Name

Whether or not an Agent has been deployed

If the server belongs to the Management group

Whether or not the Windows Management Pack is being utilized
6. If we want to drill down into the specific health of a particular computer we can do
so by utilizing the Health Explorer.
7. To check the detailed health of our BIZTALKDEMO server, click on the Name cell for
the BIZTALKDEMO record. With this record selected, click on the Health Explorer
for BIZTALKDEMO.adventureworks.lab label in the top right hand corner of the
console.
8. A Health Explorer window will open which will allow us to drill down into specific
objects that are currently being monitored. If the objects are in a healthy state, we
should see a Green checkmark. If objects are in a warning state then a Yellow
triangle and when in a critical state a Red X.
9. If a critical error exists that we are sure we have resolved, we can click the Reset
Health button in the top left hand corner of this window. This will reset the object’s
health state to being healthy. However, if the root cause of the underlying issue has
not been resolved, this state of this object will revert back to an unhealthy the next
time SCOM probes this object.
10. If we are unsure whether an issue has been resolved, we can click on the
Recalculate Health button next to the Reset Health button. This will force SCOM to
probe the object to determine if it is healthy or not. We will have an opportunity to
use this feature in a future lab.
Check for Active Alerts
1. In the Monitoring view, click on the Active Alerts button.
2. Alerts are group by their Severity including Critical and Warnings.
Determine if the BizTalk Management Pack has been installed
1. Click on the Administration view button in the left pane of the System Center
Operations Manager Console.
2. Click on the Management Packs label in the left pane.
3. In the center pane, all Management Packs that have been installed will be displayed.
4. In the Look for: text box we can type in BizTalk and click the Find Now button. We
will discover the BizTalk Management Pack has not been installed. We will install
the Management Pack in an upcoming Lab and will return back to this view to see
that it has been installed.
Lesson 2: SCOM coverage for BizTalk
Lesson objective:
To discover how SCOM and the BizTalk Management Pack work together to monitor our BizTalk
environment.
Overview
Management Packs play a pivotal role in determining application specific health information.
This lesson will focus on BizTalk artifacts that are probed when determining the health of a
BizTalk environment.
Management Packs
Explain what the purpose of Management packs and highlight some of the other management
packs that are available.
Management Packs
Management packs provide SCOM with the information required to monitor applications
and servers. These management packs will instruct SCOM on what to monitor, how to
monitor and provides threshold information that allows SCOM to determine when an
application is in a healthy or unhealthy state.
Out of the box coverage
Microsoft provides many management packs out of the box, or free for download. Some of
the popular management packs available include:





Microsoft Exchange Server
Microsoft SQL Server
Microsoft Windows Server
Microsoft SharePoint Server
Microsoft BizTalk Server
Management Pack - Downloads
Explain the different ways of obtaining Management Packs
Management Pack downloads
Management Packs can be downloaded from the SCOM Administration console, Microsoft
Download Center or from the Management Pack catalogue that is available on Microsoft’s
website: http://pinpoint.microsoft.com/en-US/systemcenter/managementpackcatalog
Third party Management Packs may also be downloaded from this catalogue. Some of these
Management Packs require a license and provide coverage for non-Microsoft systems
including 3rd party:





Database Systems
Operating Systems
Mobile Phone Management
Virtualization Management
Middleware
Management Pack - Downloads
Describe where Management Packs need to be installed.
Installing Management Packs
Management Packs need to be installed on the Root Management Server. They do not need
to be installed on the actual BizTalk Server. The exception to this statement is when BizTalk
and SCOM are installed on the same server as in the case of our lab configuration.
Upon Server Discover, Agents need to be deployed to the BizTalk Servers that we want to
monitor.
Lab 6A: Installing BizTalk 2010 Management Pack
Scenario
In order for SCOM to monitor our BizTalk Server and look for BizTalk specific events, we
need to install the BizTalk Server 2010 Management Pack.
Procedure List
window.
Start.
Procedure List
Exercise 1: Install BizTalk 2010 Management Pack from System Center
Operations Manager console
Overview
Since our lab environment does not have internet connectivity, the BizTalk Server 2010
Management Pack has been downloaded and unpackaged. We now need to import this
Management pack in the SCOM console.
Procedure List
Navigate to Management Packs View
Procedure List
1. In the lower left corner of the Operations Console, click on the Administration
button.
2. In the left pane, find Management Packs, right-click and select Import Management
Packs.
3. A new form will load called Import Management Packs. Find the Add button, click it
and then select Add from disk …
4. When prompted to search an online catalogue for dependent management packs
select No.
5. When prompted to Select Management Packs to import, browse the C:\Program
Files (x86)\System Center Management Packs\BizTalk Server 2010 Monitoring
Management Pack\ folder and select the 3 Management Packs that exist in this
folder: Microsoft.BizTalk.Server.2010.Discovery.mp,
Microsoft.BizTalk.Server.2010.Library.mp and
Microsoft.BizTalk.Server.2010.Monitoring.mp. Once selected, click the Open
button.
6. We should now see an Import list that contains these three management packs and
a green check mark beside each one.
7. The Status details should display a message indicating This management pack is
ready to import.
8. Click the Install button to proceed.
9. After a couple minutes, we should see that all 3 Management Packs have been
Imported successfully and have a green check mark beside each one.
10. Click Close to complete this wizard.
11. In the center of our Management Packs view, we should now see 3 BizTalk related
Management Packs: BizTalk Server Discovery, BizTalk Server Library and BizTalk
Server Monitoring.
Note: it may take a couple minutes for the BizTalk Management Packs to appear in
the Management Packs list in the center pane of the console.
BizTalk 2010 Management Pack
Describe some of the coverage that the BizTalk 2010 Management Pack provides.
BizTalk 2010 Management Pack coverage
The BizTalk 2010 Management Pack provides comprehensive monitoring coverage for
BizTalk Server 2010. This coverage includes:




Health monitoring by determining whether core components such as Host
Instances, Enterprise Single Sign On and SQL Server Instance(s) are available.
Configuration monitoring is achieved by determining if artifacts such as Receive
Locations, Orchestrations and Send Ports are enabled.
Performance data is collected via Performance Counters that are included in the
Operating System and BizTalk Server products. BizTalk specific counters include
Message Box, Messaging and Adapter specific counters whereas Operating System
counters include CPU and Memory utilization.
In addition to Performance counters, the BizTalk Management Pack is also aware of
BizTalk specific thresholds. These thresholds are used to determine the health of
our BizTalk servers. For example if a Host is receiving more messages than it can
handle, these messages will start to backup in the Host’s message queue. The
BizTalk Management pack provides default thresholds that can be used to notify
support personnel in these situations as BizTalk will begin to throttle these messages
to ensure that the Server does not crash.
BizTalk 2010 Management Pack – Role specific views
Describe the two different views available and the purpose of separating them from each other.
Views
The BizTalk Management Pack includes two views out of the box for two separate
audiences. The Application View is tailored towards BizTalk Administrators who are
interested in knowing the state of BizTalk applications and their artifacts. Included in this
view are a list of applications that are currently being monitored and the ability to launch
the Health Explorer for this application. The Health Explorer will probe the application and
ensure that all application related artifacts are available. If any of these artifacts are not
available, the state of this application will be in a Critical Error state.
The Deployment view may be of interest to BizTalk administrators but is tailored towards
Infrastructure support teams. The information provided in this view focuses on the
underlying infrastructure components that are required for the BizTalk applications to run
properly. Information contained within this view includes the state of Hosts, BizTalk
Management database, Business Rules Engine, BAM portal and the overall performance of
our BizTalk environment.
BizTalk 2010 Management Pack – New Features
Describe the new features that available in the BizTalk 2010 Management Pack.
BizTalk 2010 Management Pack
The BizTalk 2010 Management Pack includes many features that were not available in
previous versions of the Management Pack.

In previous versions of the management pack, opportunities existed for duplication of
alerts when multiple BizTalk servers are present within the same BizTalk group.
Optimized discovery of artifacts across multiple machines has addressed this issue.

Optimized discovery of relationships is included in the BizTalk 2010 management pack.
Previous management packs did not properly sequence the relationships between
BizTalk artifacts. For example, in order to establish a relationship between a Receive
Port and a Receive location, the Management Pack must detect all Receive Ports and
then Receive Locations.

The BizTalk 2010 Management pack implements a visual representation of health
status by providing color schemes to identify the state of a specific BizTalk service or
artifact. The 3 different colors that represent states are Green (healthy), Yellow
(warning), and Red (troubled or error). The new management pack also takes the
runtime state into consideration when determining the health of your BizTalk
environment. An example of this may be having all of your BizTalk host instances and
application artifacts online but having numerous suspended messages.

This version of the management pack includes improved diagnostic information over
previous versions. You can now expect more information about the error.

Previously, whenever a small change was made to a BizTalk artifact that SCOM was
monitoring, a round trip to the SCOM database was made when in some situations it
was not required. In the new Management Pack, performance enhancements have
been made by only writing changes to the database when they are relevant to the needs
of the system. Other improvements have been made to fix performance issues related
to high resource usage if discovery levels are set too low.
BizTalk 2010 Management Pack – Supported Configuration
Highlight the supported versions of BizTalk that this Management Pack supports as it is not
backward compatible in all situations.
Supported Configurations
All other BizTalk versions and locales are not supported with this version of the Management
pack but may have their own version of the management pack. For instance, separate
Management packs exist for BizTalk 2006 and BizTalk 2009. The older Management packs
will not have some of the features that were just described in this slide deck.
Demonstration: Exploring BizTalk 2010 Management Pack
In this demonstration, you will learn to navigate the views that are installed with the BizTalk
Management Pack and fundamental concepts required when monitoring BizTalk Servers.
Overview
In this exercise we are going to explore the BizTalk 2010 Management pack and its features
including the Application and Deployment views.
Note: When making changes to your system(s) that will trigger state changes that SCOM is
monitoring for, it may take a couple minutes for the SCOM console to reflect the update. In
this situation it is recommended to be patient but to also leverage the Health Explorer to
probe SCOM for state changes.
Procedure List
Explore the BizTalk Server 2010 Application View
Procedure List
1. In the lower left corner of the Operations Console, click on the Monitoring view
button.
2. In the left pane, find Microsoft BizTalk Server 2010, expand this hierarchy tree by
clicking on the + sign.
3. Expand Application Views by clicking on the + sign.
4. Click on the Application State View. Within this view, we will discover all of the
BizTalk Server applications that have been deployed on our server. Not all BizTalk
applications can be monitored including the default BizTalk Application 1. The
reason for this is because this application does not have any objects that SCOM is
monitoring including Receive Locations, Orchestrations or Send Ports.
5. For applications that are being monitored by SCOM, we have a few Actions available
to us in the top right pane including running the Health Explorer and initiating
Maintenance Mode. The Health Explorer allows us to probe the BizTalk Application
and related dependencies to determine its overall health. Since stopping a BizTalk
Application, so that we can perform maintenance activities, will generate SCOM
alerts we can set the Application in Maintenance Mode. When in this state, SCOM
will ignore any activities on that application while we are working on it. We have the
ability to put applications in Maintenance Mode as well as the whole server in the
event that the change requires all BizTalk applications to go offline. We can tell
when an object is in Maintenance Mode by the wrench being displayed beside the
object’s state:
6. The next area that we want to focus on is the Groups State View which can be found
directly below the Applications State View. The Groups State View provides
visibility into the overall health of the BizTalk Group that is being monitored. In our
scenario we have a single server in a BizTalk group, but otherwise this view would
give us insight into our distributed BizTalk environment.
7. Below the Groups State View we have the Hosts State View. In this view we will see
a list of our BizTalk Hosts that have been configured inside the BizTalk
Administration Console. From here we are able to determine the overall health of
our Hosts and have the ability to launch the Health Explorer and Start Maintenance
Mode.
8.
Also note a context aware menu that has been displayed in the upper right pane
called BizTalk Host Tasks. From this menu, we have the ability to start or stop host
instances without launching our BizTalk Administration Console.
9. The next view that we can expand is Application Artifact Views. Within this view we
will get a detailed summary of all deployed Orchestrations, Receive Locations,
Receive Ports, Send Port Groups and Send Ports. We have the ability to select a
single artifact and then use the available actions from the top right pane. Much like
the options for Host State we have the ability to launch the Health Explorer and
start Maintenance Mode.
Explore the BizTalk Server 2010 Deployment View
Procedure List
1. At the same level, in the tree hierarchy as the Application Views, we will see
another folder called Deployment Views. This is a set of views are similar to the
Application Views but focus on the underlying infrastructure components that
BizTalk requires to function correctly.
2. The first view that we are going to take a look at is the Deployment State View.
Within this view we will see our BizTalk Management Database:
BizTalkMgmtDb.BIZTALKDEMO. This view is an aggregation of some underlying
components that are necessary for BizTalk to be completely healthy. We will see
columns that will indicate these component’s underlying health status including
BAM Role, BizTalk Run-Time Role, Rule Engine Role.
3. To demonstrate how the aggregation of these core component’s impacts the
Deployment State View, we are going to stop the Rule Engine Update Service. On
the Start menu, point to All Programs, point to Administrative Tools and then click
Services.
4. Scroll down until you find a server called Rule Engine Update Service. Right mouse
click on this service and click Stop.
5. Return to the Deployment State View in the SCOM Console. Underneath the Rule
Engine Role we should discover a Critical Error exists. If we locate the State Column
we should also discover a Critical Error exists. Note: This state change may take up
to 5 minutes for it to show up in your SCOM Operations Console. Your console should
refresh automatically but you can also press F5 to force a refresh.
6. We now want to return to the Services manager that we launched in step 3. We
need to Start the Rule Engine Update Service by right mouse clicking on it and
clicking Start.
7. We should see both the State and Rule Engine Role columns updated and revert to a
state of Healthy automatically.
Note: to have SCOM probe this object, click the record and then click on the Health
Explorer for BizTalkMgmtDb.BIZTALKDEMO. Once launched, expand Entity Health –
Availability – BizTalkMgmtDb.BIZTALKDEMO,BizTalk Group Deployment Dependent
On Server Role, Availability(2nd one), Rule Engine Service Availability Monitor and
click the Recalculate Health button at the top of the form.
8. Below the Deployment State View we will discover other views that, collectively,
make up the Deployment State View including Hosts State View, Rule Engine View
and Run-Time Role State Views.
9. The next view is called the BAM Component Views and contains individual views for
determining the health of:

BAM Alerts State View

BAM Analysis State View

BAM Performance View

BAM Portal State View

BAM Run-Time State View
10. The last set of views that we are going to discuss are found in the Run-Time
Components Views tree hierarchy. Inside this view we will discover our
Performance counter views that provide visibility into the following areas:

MessageBox Performance

Messaging Adapters Performance

Messaging Performance

Orchestration Performance

Server Resource Usage View
Lab 6B: Generating and Resolving BizTalk Host Instance Alerts
Scenario
In the previous demonstration we saw how the state of the Rule Engine Update Service had
an impact on the overall health of a BizTalk environment. In this Lab we are going to
discover the impact that a BizTalk Host instance has on BizTalk’s health. We will see
BizTalk’s Host State health change and an Alert will be generated in the Active Alerts view.
We will then discover how to start this Host instance from SCOM Console and watch both
the Active Alerts and Host State views change.
Launch the BizTalk Administration and System Center Operations Manager
console
Procedure List
1. On the Start menu, point to All Programs, point to Microsoft BizTalk Server 2010
and then click on BizTalk Server Administration.
Exercise 1: Generating and Resolving BizTalk Host Instance Alerts
Procedure List
1. In the BizTalk Administration Console ensure that your BizTalkServerApplication
Host Instance has a status of Running.
2. Switch to the SCOM Operations Console. Click on the Monitoring view button in the
bottom left pane.
3. In the left pane, expand the Microsoft BizTalk Server 2010 view.
4. Expand Applications Views and then click on Hosts State View.
5. In the center pane, observe the State column value for the BizTalkServerApplication
Host. This value should have a value of: Healthy.
6. Click on the BizTalkServerApplication record and then click on the Stop BizTalk Host
label in the BizTalk Host Tasks pane on the right hand side.
7. In the Run Task – Stop BizTalk Host form that loads, ensure the
BizTalkServerApplication checkbox is checked and click the Run button.
8. A Task Status – Stop BizTalk Host form will load indicating the status of this action.
When complete, the status column should have a value of Success. Click the Close
button to close this form.
9. Click on the Active Alerts view in the top left hand corner of the SCOM Operations
Console underneath the Monitoring hierarchy.
10. You should now see Severity:Critical alert in the center pane. The source of this
alert should be the name of our BizTalk Host Instance: BizTalkServerApplication.
Note: It may take up to 10 minutes for this alert to appear within this Alerts View.
11. To obtain more information about this alert. Double click on the record. An Alert
Properties form will be displayed. Here you will find diagnostic information about
the alert including Product Knowledge from Microsoft, Company Knowledge where
organizations have the ability to provide their own information, History, Alert
Context, and Custom Fields. Click on the OK button to close this form.
12. If we navigate back to the Hosts State View, as described in Step #4, we should see
that the state of our BizTalkServerApplication Host Instance has changed its state
from Healthy to Critical.
Explorer for BizTalkServerApplication. Once launched, expand Entity Health –
Availability – BizTalk Host Availability Monitor and click the Recalculate Health
button at the top of the form.
13. To start our BizTalk Host instance back up, select the BizTalkServerApplication
record and then click the Start BizTalk Host label found in the BizTalk Host Tasks
found in the right hand pane.
14. In the Run Task – Start BizTalk Host form, ensure BizTalkServerApplication is
checked and click the Run button.
15. In the Task Status – Start BizTalk Host form, a status column will indicate the state
of this action. Once the status value has changed to Success, click the Close button.
17. The Severity:Critical alert, that was described in step 10, indicating the
BizTalkServerApplication Host Instance was offline should no longer exist within the
pane. You may need to refresh your console by pressing the F5 button. This alert
was automatically cleared since SCOM has determined that the issue has been
resolved.
18. Navigate back to the Hosts State View, as described in Step #13. Press the F5
button to refresh your console. We should see that the state of our
BizTalkServerApplication Host Instance has changed its state from Healthy to
Critical.
Note: if the state of your Host Instance has not changed, you may need to run the
Health Explorer. To do this select the BizTalkServerApplication record and then click
the Health Explorer for BizTalkServerApplication. Once launched, expand Entity
Health – Availability – BizTalk Host Availability Monitor and click the Recalculate
Health button at the top of the form. Once the Health Explorer process is complete,
press the F5 button to refresh your console.
Monitoring Scenarios
Describe some of the scenarios that the BizTalk Management pack provides coverage for.
Monitoring Coverage
1. Suspended Message Alerts – The BizTalk Management Pack allows you to monitor and
troubleshoot both inbound and outbound Message Alerts. For example an inbound flat
file message that fails to be disassembled will end up in a Suspended state within the
BizTalk Administration Console. In an outbound scenario if a destination system is not
available, BizTalk will attempt to retry submitting the message to this system based
upon the retry threshold that has been configured in the Send Port. In the event that
the retry threshold has been exceeded, this message will also end up in a Suspend State.
In both of these situations, SCOM can detect these conditions and raise an alert to the
appropriate support group so that the issue may be resolved.
2. Alert Suppression – In the event we have a high traffic situation and a destination
system is down, we have the potential to receive hundreds if not thousands of alerts.
Alert Suppression will detect that there is a re-occurring event by detecting a message
continues to fail for the same URI. In this situation, SCOM will suppress these redundant
alerts and the appropriate support group will only receive 1 alert. Once the issue has
been resolved, it is important to reset the health of this alert otherwise we will continue
to have alerts suppressed for this particular event.
3. From the BAM Portal, an End user has the ability to request Technical Assistance. When
this event occurs, the BAM Portal will insert an event into the Event Viewer on the BAM
Portal. SCOM is able to detect this event and then notify the appropriate support staff.
4. The BizTalk Management Pack allows us to set specific thresholds for the BizTalk group
and at a more granular level that allows us to specify individual thresholds for specific
hosts. An example of these thresholds are the ones that may put BizTalk in a throttling
state. A Host that enters throttled state for an extended period of time likely requires
attention of a Support team.
5. Providing alerts for Orchestrations that encounter exceptions is another feature that is
provided in the BizTalk Management pack. Perhaps we encounter a situation where a
.Net Component may fail when called from an Orchestration and we would like to be
informed of this event.
6. BizTalk Server has many underlying services that are required in order for it to function
properly. If one of these underlying services fail, such as the SQL Service instance that is
hosting our BizTalk databases we want to be notified as this situation will result in our
Host Instances shutting down since they cannot contact our database.
7. Much like we have the ability to monitor at the infrastructure level, we also have the
ability to monitor at the Application level. For instance if one of our receive locations
goes offline, this will result in a state change in the health of our BizTalk application. The
BizTalk Management pack provides us with the ability to monitor these types of events.
Lab 6C: Generating and Closing Application Alerts
Scenario
One of BizTalk Server’s core competencies is the ability to process different types of
messages from a variety of trading partners. Since some of these messages are received
from external parties, the messages that are received may not be the same type of message
that we are expecting. These messages that have an unexpected format may fail to be
processed in the inbound receive pipeline. SCOM provides us with visibility into these
situations so that we can react when these events occur.
Conversely, we may want to send messages from our organization to another. In these
situations it is important to raise Send Port errors when they occur so the appropriate
support staff can address the issue before Service Level Agreements (SLAs) are missed. Once
again SCOM provides BizTalk Administrators with visibility into these types of issues.
Exercise 1: Generating and Closing Receive Pipeline Errors
Overview
An existing solution called Module 6 has been deployed for the purposes of this Lab. This
application is a copy of a previous lab that has been renamed. The goal of this lab is to
submit a message to an existing Receive Location that will fail validation within the Receive
Pipeline. We can expect a Suspended Message instance inside the BizTalk Administration
console. In the SCOM Operations Console we expect an alert to be generated within the
Active Alerts menu.
Start Module 6 BizTalk Application
Procedure List
2. Expand BizTalk Server Administration, BizTalk Group and Applications.
3. Right mouse click on Module 6. Ensure application is currently running. If it is not,
click on Start.
System Center Operations Manager console
Submit message to BizTalk
Procedure List
1. In Windows Explorer, browse to C:\AllFiles\LabFiles\Module 6\Messages.
2. Right mouse click on GenerateReceivePipelineError.xml file and select Copy.
3. Double click on the PurchaseOrderIN folder.
4. Right mouse click on Windows Explorer surface and click Paste.
Check for Active Alert in System Center Operations Manager console
1. In the SCOM Operations Console click on the Monitoring view button. In the upper
left corner click on Active Alerts view.
2. Click F5 to refresh your screen.
3. You should find a Severity:Critical alert with a Source of
BIZTALKDEMO.adventureworks.lab and a Name of ERROR: FILE-Receive Message
Suspended.
4. Double click on this record and you will be presented with an Alert Properties form.
Within this form we will be presented with some additional details about the alert
and some recommendations on how to resolve it. Click the OK button to close this
form.
Close the Alert
1. Right mouse click on the alert and click Close Alert. This will remove the alert from
the Active Alerts view.
Exercise 2: Generating and Closing Suspended Message Errors
Overview
In the previous example we demonstrated generating an alert for an inbound event. In this
example we are going to generate an event for an outbound operation. We are going to use
this same Module 6 BizTalk application. In order to get the outbound message to fail, one of
our send ports is configured to deliver files to non-existent location. In order to expedite
these files to fail, the send port retry interval has been set to 0.
Procedure List
1. On the Start menu, point to All Programs, point to Microsoft BizTalk Server 2010 and
then click on BizTalk Server Administration.
click on Start.
Procedure List
3. Right mouse click on GenerateSendPortError.xml file and select Copy.
BIZTALKDEMO.adventureworks.lab and a Name of ERROR: An outbound message
is being suspended by the Adapter.
form.
Close the Alert
Lab Exercises
Contents
Lab Exercises.................................................................................................................................... 1
Lab 1: Examining a BizTalk Application........................................................................................ 4
Exercise 1: Test a BizTalk Server Application ........................................................................... 6
Lab 2a: Install and Configure SharePoint Foundation 2010 ........................................................ 8
Exercise 1: Install SharePoint Foundation 2010 .................................................................... 10
Exercise 2: Configure SharePoint Foundation 2010 .............................................................. 11
Lab 2b: Install and Configure BizTalk Server.............................................................................. 12
Exercise 1: Install BizTalk Server 2010 ................................................................................... 13
Exercise 2: Configure BizTalk Server 2010 ............................................................................. 14
Lab 3a: Deploying an Application by Using an MSI Package ..................................................... 17
Exercise 1: Remove the BizTalk Application .......................................................................... 19
Exercise 2: Deploy a BizTalk Application from an MSI Package ............................................. 20
Exercise 3: Start and Test the BizTalk Application ................................................................. 21
Lab 3b: Composing and Deploying Business Rules .................................................................... 24
Exercise 1: Create a New Business Rule ................................................................................ 25
Exercise 2: Deploy and Test the New Policy .......................................................................... 27
Lab 4a: Administering a BizTalk Application .............................................................................. 29
Exercise 1: Create Receive Ports and Locations .................................................................... 31
Exercise 2: Create Send Ports ................................................................................................ 33
Exercise 3: Bind the Orchestration ........................................................................................ 36
Exercise 4: Start and Test the Application ............................................................................. 37
Lab 4b: Monitoring Message Activity and Debugging Orchestrations ...................................... 39
Exercise 1: Track and View Message Activity ........................................................................ 40
Lab 4c: Scripting Administrative Tasks ...................................................................................... 43
Exercise 1: Export and Remove an Application by Using BTSTask......................................... 44
Exercise 2: Import a BizTalk Application by Using BTSTask ................................................... 45
Lab 4d: Monitoring Business Activity ........................................................................................ 46
Exercise 1: Define a Business Activity .................................................................................... 47
Exercise 2: Define an Observation Model.............................................................................. 49
Exercise 3: Deploy the BAM Observation Model ................................................................... 53
Exercise 4: Map a BAM Activity to the Implementation........................................................ 54
Exercise 5: Use the BAM Portal to Test the BAM Implementation ....................................... 58
Lab 5a: Managing a BizTalk Server Group ................................................................................. 60
Exercise 1: Manage BizTalk Hosts .......................................................................................... 62
Exercise 2: Manage MessageBoxes ....................................................................................... 63
Lab 5b: Backing Up and Restoring BizTalk Server Data ............................................................. 64
Exercise 1: Back Up BizTalk Databases .................................................................................. 65
Exercise 2: Delete and Restore the BizTalk Databases .......................................................... 67
Lab 6a: Installing BizTalk 2010 Management Pack .................................................................... 69
Exercise 1: Install BizTalk 2010 Management Pack from System Center Operations
Manager console ................................................................................................................... 71
Lab 6b: Generating and Resolving BizTalk Host Instance Alerts................................................ 72
Exercise 1: Generating and Resolving BizTalk Host Instance Alerts ...................................... 73
Lab 6c: Generating and Closing Application Alerts.................................................................... 75
Exercise 1: Generating and Closing Receive Pipeline Errors .................................................. 76
Exercise 2: Generating and Closing Suspended Message Errors ........................................... 77
Scenario
Adventure Works is a company that sells sporting goods. Adventure Works has implemented
BizTalk Server 2010 to automate its purchase order approval system. In this lab, you will test
the process by submitting purchase orders from two companies to the BizTalk Server
application that uses schemas, pipelines, maps, and orchestrations. The application
calculates and applies a discount based on rules that have been defined by using the
Business Rule Composer.
The business rules are as follows:

Contoso, Ltd. is a preferred business partner. Orders greater than $10,000 receive a
10 percent discount, all other orders receive a 5 percent discount. The AckCode field
in each purchase order is updated to reflect the discount percentage.
 Fabrikam, Inc. is not a preferred business partner. However, orders greater than
$10,000 receive a 5 percent discount. The AckCode field is updated with the
following text: 5% discount applied.
 All orders that do not meet the minimum ($10,000) require manual approval. By
default, the AckCode field for these orders is set to Does not meet minimum.
A message is sent to a SharePoint document library when a purchase order requires manual
approval. A manager must manually override the AckCode field with a value of Accepted or
Denied before resubmitting the updated purchase order to BizTalk Server for further
processing. After the purchase order has been reviewed by the manager, it is included in a
view of the SharePoint document library that displays only evaluated orders. BizTalk Server
monitors the document library’s Evaluated view for messages to process.
If the purchase order is Accepted, BizTalk calculates and updates the total for the purchase
order and routes it to the PurchaseOrderAck folder. If the purchase order is Denied, the
purchase order is routed to the Denied folder.
An FTP site is used to post shipping notices for approved purchase orders.
Procedure List
window.
Start.
Procedure List
Procedure List
Exercise 1: Test a BizTalk Server Application
Overview
In this exercise, you will submit five purchase orders—three from Contoso, Ltd., and two
from Fabrikam, Inc.—to BizTalk Server 2010 for processing. Depending on the company
name and total order amount, the Business Rule Engine will apply a discount to each
purchase order. One purchase order will not meet any requirements of the business rule
policy and must be manually approved. Shipping information will also be generated for each
approved purchase order and posted to an FTP site. This exercise shows you how BizTalk
Server 2010 is used to automate business processes.
Procedure List
2. Copy the three ContosoPO… and the three FabrikamPO… XML messages to the
These are the purchase orders that will be processed by BizTalk Server.
4. In the PurchaseOrderAck folder, open each of the four Completed{GUID}.xml
messages, and verify that the AckCode field displays X% discount applied or
Accepted.
5. In Internet Explorer, type ftp://BizTalkDemo/ShippedOrders in the Address bar,
6. When prompted to log in to the FTP site, in the User name box, enter Administrator
and in the Password box, enter pass@word1.
7. Open the ShippedOrders folder, and notice the four ShipNotice{GUID}.xml
messages.
8. In Internet Explorer, navigate to http://BizTalkDemo/PurchaseOrderAck.
9. Click the first message, and then in the File Download dialog box, click Open. If the
Take note of the Customer Name; it is either Contoso or Fabrikam.
The Evaluated view shows applications that have been accepted or rejected.
processed.
13. In Internet Explorer, navigate to ftp://BizTalkDemo/ShippedOrders. Notice that
another ShipNotice{GUID}.xml message is in the folder.
14. 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 Reject button.
Take note of the Applicant Name; it is either Contoso or Fabrik.
15. In the Ack Code list, choose Reject, and then close the form, saving your changes.
16. Refresh the page, and notice that the message will be picked up for processing.
This may take up to one minute to occur.
1\Messages\PurchaseOrderAck, and notice that the message does not appear
there.
18. In Windows Explorer, navigate to C:\AllFiles\LabFiles\Module 1\Messages\Denied,
open the Denied{GUID}.xml message, and notice that the order was not approved.
The structure of this message is different from the acknowledgment messages
generated for completed orders. The design of this application is to send the
original PO as the denied message.
Lab 2a: Install and Configure SharePoint Foundation 2010
Introduction
Microsoft SharePoint Foundation 2010 is a prerequisite for installing the Windows
SharePoint Services adapter for BizTalk Server. In this lab, you will install and configure
Microsoft SharePoint Foundation 2010.
Procedure List
window.
Start.
Procedure List
Exercise 1: Install SharePoint Foundation 2010
Overview
In this exercise, you will install Microsoft SharePoint Foundation 2010.
Install SharePoint Foundation 2010
Procedure List
1. In Windows Explorer, navigate to C:\Temp, and then double-click
SharePointFoundation.exe.
2. In the Open File – Security Warning window, click Run.
3. In the Microsoft SharePoint Foundation 2010 window, click Install SharePoint
Foundation.
4. Click I accept the terms of this agreement, and then click Continue.
5. On the Data Location page, click Install Now, and wait for the installation to
complete.
6. In the Microsoft SharePoint Foundation 2010 window, on the Run Configuration
Wizard page, click Close.
The SharePoint Products Configuration Wizard will launch automatically.
Exercise 2: Configure SharePoint Foundation 2010
Overview
In this exercise, you will configure SharePoint Foundation 2010, including the Internet
Information Services (IIS) Manager application pool, and the SQL Server database and
credentials used.
Configure SharePoint Foundation 2010
Procedure List
1. In the SharePoint Products Configuration Wizard window, on the Welcome to
SharePoint Products page, click Next.
2. In the SharePoint Products Configuration Wizard warning dialog box, click Yes.
3. On the Connect to a server farm page, click Create a new server farm, and then
click Next.
4. On the Specify Configuration Database Settings page, in the Database server box,
enter BIZTALKDEMO.
5. In the Username box, enter ADVENTUREWORKS\SharePointService, and in the
Password box, enter pass@word1, and then click Next.
6. On the Specify Farm Security Settings page, in the Passphrase and Confirm
passphrase boxes, enter pass@word1, and then click Next.
7. On the Configure SharePoint Central Administration Web Application page, click
Next.
8. On the Completing the SharePoint Products Configuration Wizard page, click Next.
9. Allow the configuration to complete, and then on the Configuration Successful
page, click Finish, and wait for the configuration to complete.
The SharePoint Central Administration page will be launched automatically.
Configure the SharePoint Farm
Procedure List
1. In Internet Explorer, on the Help Make SharePoint Better page, click No, I don’t
wish to participate, and then click OK.
2. On the How do you want to configure your SharePoint farm? page, click Start the
Wizard.
3. Click Use existing managed account, and then click Next.
4. In the Title box, enter Lab2, and then click OK.
5. On the This completes the Farm Configuration Wizard page, click the
http://biztalkdemo link to view the new SharePoint site.
6. Verify that the Welcome to your site page appears.
Introduction
In this lab, you will install and configure BizTalk Server 2010. You must have completed Lab
2a in order to successfully complete this lab.
Exercise 1: Install BizTalk Server 2010
Overview
In this exercise, you will perform an installation of BizTalk Server 2010, choosing the
components to be installed. Any missing prerequisites will be installed automatically from
the provided CAB file.
Install BizTalk Server 2010
Procedure List
2. In Windows Explorer, navigate to C:\AllFiles\LabFiles\Module 2\BT Server, and
then double-click Setup.exe.
3. In the Microsoft BizTalk Server 2010 Installation Wizard, click Install Microsoft
4. On the Customer Information page, click Next
5. On the License Agreement page, click Yes, I accept the terms of the license
agreement, and then click Next.
6. On the Customer Experience Improvement Program page, click No, I don’t want to
participate in the program, and then click Next.
7. On the Component Installation page, expand Additional Software, select all
available components, and then click Next.
The prerequisites for the MQSeries Agent have not been installed, so that option
will be disabled.
8. On the Summary page, click Install, and then wait for the installation to complete.
9. On the Installation Completed page, ensure that Launch BizTalk Server
Configuration is selected, and then click Finish.
Exercise 2: Configure BizTalk Server 2010
Overview
In this exercise, you will perform a custom configuration of BizTalk Server 2010. You will
specify the user account and database names used by BizTalk Server.
Manually Configure BizTalk Server 2010
Procedure List
1. If the Microsoft BizTalk Server 2010 Configuration Wizard is not already running, on
the Start menu, point to All Programs, point to Microsoft BizTalk Server 2010, and
then click BizTalk Server Configuration.
2. In the Microsoft BizTalk Server 2010 Configuration Wizard, click Custom
Configuration.
3. Click the Browse button to the right of the User name box.
the Search results list, double-click BizTalkHost, and then click OK.
5. In the Password box, enter pass@word1, and then click Configure.
Enterprise SSO.
7. In the right pane, select Enable Enterprise Single Sign-On on this computer.
Notice that the account information is automatically populated with the account
specified on the first page of the wizard.
8. Click the ellipsis (…) to the right of Enterprise Single Sign-On Service, and then in the
in the User Credentials dialog box, click Browse.
the Search results list, double-click SsoService, and then click OK.
then click OK.
Enterprise SSO Sign-On Secret Backup.
12. In the right pane, type pass@word1 in the Secret backup password and Confirm
password boxes, and then type Default password in the Password reminder box.
When you use the Basic Configuration option to configure a BizTalk Server
installation, the SSO Single Sign-On secret backup password defaults to the
password of the user installing BizTalk Server 2010.
13. In the left pane, click Group.
14. In the right pane, select Enable BizTalk Server Group on this computer.
15. Click the ellipsis (...) to the right of BizTalk Administrators Group.
17. In the Search results list, double-click BizTalk Server Administrators, and then click
OK.
18. Click the ellipsis (...) to the right of BizTalk Operators Group.
20. In the Search results list, double-click BizTalk Server Operators, and then click OK.
21. Click the ellipsis (...) to the right of BizTalk B2B Operators Group.
23. In the Search results list, double-click BizTalk Server B2B Operators, and then click
OK.
24. In the left pane, click BizTalk Runtime.
25. In the right pane, select Register the BizTalk Server runtime components.
26. Click the ellipsis (…) to the right of BizTalk Isolated Host Instance Account, and then
in the in the User Credentials dialog box, click Browse.
the Search results list, double-click BizTalkIsoHost, and then click OK.
then click OK.
29. Click the ellipsis (...) to the right of BizTalk Host Users Group.
31. In the Search results list, double-click BizTalk Application Users, and then click OK.
32. Click the ellipsis (...) to the right of BizTalk Isolated Host Users Group.
34. In the Search results list, double-click BizTalk Isolated Host Users, and then click OK.
35. In the left pane, click Business Rules Engine.
36. In the right pane, select Enable Business Rules Engine on this computer.
37. Click the ellipsis (…) to the right of Rule Engine Update Service, and then in the in
the User Credentials dialog box, click Browse.
the Search results list, double-click ReuService, and then click OK.
then click OK.
40. In the left pane, click SharePoint Adapter.
41. In the right pane, select Enable Windows SharePoint Services Adapter on this
computer.
42. Click the ellipsis (...) to the right of BizTalk SharePoint Adapter Enabled Hosts.
44. In the Search results list, double-click SharePoint Enabled Hosts, and then click OK.
45. In the Windows SharePoint Services Adapter Web Site list, select SharePoint - 80.
46. Click the Apply Configuration button.
47. On the Summary page, click Next.
48. Click Finish.
49. On the Overview page of the Microsoft BizTalk Server 2010 Configuration wizard,
notice that BAM Tools, BAM Portal and BizTalk EDI/AS2 Runtime have exclamation
points next to them. This is because the components are not configured.
50. Click the Export Configuration button, and then save the file to the desktop.
51. Examine the configuration file.
Lab 3a: Deploying an Application by Using an MSI Package
Scenario
You are responsible for managing and administering the computers running BizTalk Server
for Adventure Works. The BizTalk development team has just completed a new version of a
BizTalk application and exported it as an MSI package. In this lab, you will remove the
previous version of the application, install the new version of the application, and then test
its functionality.
Procedure List
window.
Start.
Procedure List
Exercise 1: Remove the BizTalk Application
Overview
In this exercise, you will uninstall an older version of the Module 3 application from the
computer running BizTalk Server. You will first uninstall the application by using Add or
Remove Programs in Control Panel. You will then use the BizTalk Server Administration
Console to remove the application from the BizTalk configuration database.
Uninstall the Old BizTalk Application
Procedure List
BizTalk Group, and Applications, and then notice that the Module 3 – Uninstall
application is displayed.
3. On the Start menu, click Control Panel, and then under Programs, click Uninstall a
program.
4. In the Programs and Features window, right-click Module 3 – Uninstall, and then
click Uninstall.
The application name shown in Add or Remove Programs is the application
name associated with the MSI from which the application was installed. This
name might not be the same as the one shown in the BizTalk Server
5. After the uninstall completes, close the Programs and Features window.
Refresh.
7. Notice that the Module 3 – Uninstall application is still displayed.
Uninstalling the application removes the assembly from the global assembly
cache (GAC) of the local computer, but it does not remove the application from
the BizTalk Configuration database. You will need to remove the assembly or
delete the application by using the BizTalk Server Administration Console.
then click Stop.
9. In the dialog box, click Full Stop – Terminate Instances, and then click Stop.
You must terminate any running instances of the application before uninstalling
the application. If you do not perform this step, the uninstall will most likely fail.
then click Delete.
11. In the Confirm delete application dialog box, click Yes.
12. Notice that the Module 3 – Uninstall application is no longer displayed.
Exercise 2: Deploy a BizTalk Application from an MSI Package
Overview
Deploying a BizTalk Server application is a two-step process. The BizTalk assembly must be
installed to the global assembly cache of the computer running BizTalk Server, and
registered in the BizTalk configuration database. In this exercise, you will deploy a BizTalk
Server application by using an MSI package. First you will import the MSI package to the
BizTalk Server configuration database by using the BizTalk Server Administration Console.
Then, you will run the MSI package to install the application to the computer running BizTalk
Server.
Import the BizTalk MSI
Procedure List
1. In the BizTalk Server Administration Console, right-click Applications, point to
Import, and then click MSI file.
2. In the Import MSI Wizard, type C:\AllFiles\LabFiles\Module 3\Module3.msi in the
MSI file to import box, and then click Next.
3. On the Application Settings page, ensure that the Application name is set to Module
3, select the Overwrite resources check box, and then click Next.
6. 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.
Selecting this check box will start the MSI installation. If you do not select this
check box, you must manually execute the Module3.msi file.
Install the BizTalk MSI
Procedure List
1. On the Select Installation Folder page of the Module 3 window, click Next.
2. On the Welcome to the Module 3 Setup Wizard page, click Next.
4. On the Module 3 Information page, click Next.
Exercise 3: Start and Test the BizTalk Application
Overview
In this exercise, you will start and test the BizTalk Server application.
Start the BizTalk Application
Procedure List
1. In the BizTalk Server Administration Console, notice that the Module 3 application
has been added to the list of applications.
2. In the left pane, click Applications, and then notice the red “stopped” icon next to
the Module 3 application.
3. Expand the Module 3 application.
4. Click Policies, right-click DiscountPolicy, click Deploy, and then in the Deploy Policy
dialog box, click Yes.
Deploying a business rule such as this one allows the BRE to evaluate business
rules based on calls from orchestrations. The DiscountPolicy business policy is
made up of several rules pertaining to company names and total order amounts.
These rules, which are described in Lab 1, apply different discounts to orders
based on the total order amount and the company placing the order.
5. Click Schemas and then notice the five schemas in this application.
Schemas define the structure of XML messages. BizTalk Server uses schemas to
ensure that data being sent to BizTalk Server is in the correct structure and has
all the information that BizTalk Server needs to process the document. This
particular application supports five different schemas.
6. Click Maps, and then notice the three maps in this application.
BizTalk Server uses maps to translate and transform data from one format to
another. For example, data might be received by BizTalk Server in a flat-file
format. BizTalk Server can use a map to transform that data from a flat-file
format to XML for further processing.
7. Click Resources, and then notice the OrderManagement assembly—this is the only
assembly in this application.
Assemblies in BizTalk Server are built and compiled by the BizTalk developer, and
they contain BizTalk artifacts such as schemas and maps. Any BizTalk artifacts
must be contained in an assembly before they can be used by BizTalk Server. In
BizTalk Server, an assembly is compiled as a DLL.
8. Click Receive Ports, and then notice that the MSI package includes two receive
ports: RcvPO, and RcvPOReview.
Receive ports pick up messages for BizTalk Server to process.
9. Click Receive Locations, and then notice that the RcvPOFILE and RcvPOReviewFILE
receive locations are also included in the MSI package.
Receive locations specify information such as the physical file location, the
adapter used, and the BizTalk Server host used to pick up messages that BizTalk
Server processes. In this example, both receive locations are using the FILE
adapter type and will poll a specific directory for messages with a file extension
of .xml.
10. Click Send Ports and then notice the five send ports that are included in the MSI
package.
Send ports specify the destination of a message after being processed by BizTalk
Server. Send ports allow you to specify settings such as the adapter type, the
location to send the message to, and any maps used to transform the message
before exiting BizTalk Server.
11. Click Orchestrations, and then notice the two orchestrations listed.
Orchestrations are used for more complex processing of messages inside BizTalk
Server. Orchestrations are automated business processes that can perform
actions such as calling business rules and making calls to Web services.
You must start an application before it will process messages.
13. In the Start ‘Module 3’ Application dialog box, click Options, ensure that all the
Starting an application in this fashion will by default try to start all send ports,
orchestrations, and host instances, as well as enable all receive ports and resume
suspended service instances. If you need to, each port/location, orchestration, or
host can be started or stopped individually.
14. In the left pane, click Applications and then notice that the red “stopped” icon in the
right pane has been replaced with the green “running” icon.
There is another application status icon, the blue “partially started” icon, which
means that at least one port, location, orchestration, or host is not running.
Test the BizTalk Application
Procedure List
2. Copy the ContosoPO_Large.xml, ContosoPO_Medium.xml, and
ContosoPO_Small.xml files to the POIn folder.
the original files are not retrievable. If you do accidentally move the messages,
additional copies can be found at C:\AllFiles\LabFiles\Module
3\Messages\MessageCopies.
3. After the messages disappear from the POIn folder, navigate to
C:\AllFiles\LabFiles\Module 3\Messages\Completed, and then notice the two
It might take up 2 minutes for the messages to appear. Any messages in this
folder have been approved, and a new field—AckCode—has been added, stating
the discount amount.
Only orders that do not meet the minimum purchase order amount are routed to
this folder.
5. Move the {GUID}.xml file from the POReviewOut folder to
C:\AllFiles\LabFiles\Module 3\Messages\POReviewIn.
Moving the file to this location represents approving the order.
6. Navigate to C:\AllFiles\LabFiles\Module 3\Messages\Completed and notice that
another POAck{GUID}.xml file is displayed.
This is the message that was manually approved in step 5 when you moved the
order to POReviewIn.
7. Delete the three messages in the Completed folder.
8. Navigate to the C:\AllFiles\LabFiles\Module 3\Messages\Shipped folder.
These messages contain shipping information for each approved purchase order.
9. Delete the three messages in the Shipped folder.
10. Do not shut down the virtual machine without saving your changes. The
configuration you performed in this lab is required for the next lab.
Scenario
The Module 3 application uses a BRE policy to calculate a discount amount for the purchase
orders based on the customer name and total order amount. In this lab, you will create a
new rule that will provide a 2 percent discount to all orders that do not meet the criteria for
any other discounts. After you have composed and tested the rule in the Business Rule
Composer, you will deploy and test it within the application.
Preparation
Exercise 1: Create a New Business Rule
Overview
In this exercise, you will create a new version of the DiscountPolicy business rule policy, and
then add a new rule to the policy.
Create a New Version of the DiscountPolicy Business Rule Policy
Procedure List
then click Business Rule Composer.
3. In the Open Rule Store dialog box, click OK.
4. Under DiscountPolicy, expand Version 1.0 – Deployed.
5. Right-click DiscountPolicy in Policy Explorer, and then click Add New Version.
After a version of a business rule has been published, the rule cannot be
changed. However, you can create a new version of a rule and copy and paste
from other policies that have been published and deployed.
6. Drag the Large Order Contoso (10% disc) rule to Version 1.1 (not saved).
7. Drag the Large Order Non-Contoso (5% disc) rule to Version 1.1 (not saved).
8. Drag the Small Order Contoso (5% disc) rule to Version 1.1 (not saved).
Create the Small Order Non-Contoso (2% disc) Business Rule
Procedure List
1. Right-click Version 1.1 (not saved) in Policy Explorer, and then click Add New Rule.
2. Name the rule Small Order Non-Contoso (2% disc).
3. In the IF pane, right-click Conditions, and then click Add logical AND.
4. Right-click AND, point to Predicates, and then click NotEqual.
5. In Facts Explorer, expand Version 1.0 – Published under MyVocabulary.
6. Drag Customer Name from the Vocabularies tab to argument1.
7. Click argument2, and then type Conto in the text box.
8. Right-click AND, point to Predicates, and then click LessThanEqual.
9. Drag Current Order Total from the Vocabularies tab in the Facts Explorer pane to
argument1.
Current Order Total has been created for you by a BizTalk developer to make
your rules easier to understand. This value originates from the Amount field of
the PurchaseOrderAck schema.
10. Click argument2, and then type 10000 in the text box.
11. Drag Set AckCode from the Vocabularies tab in the Facts Explorer pane to Actions in
the THEN pane.
12. Click <empty string>, and then type 2% discount applied.
13. Drag Discounted total from the Facts Explorer pane to Actions in the THEN pane.
14. Right-click 0, point to Functions, and then click Multiply.
15. Drag Current Order Total from the Facts Explorer pane to value1.
16. Click value2, and then type 0.98.
Here you are applying the 2 percent discount to non-Contoso orders that have a
total order amount less than or equal to $10,000.
Exercise 2: Deploy and Test the New Policy
Overview
Publishing the policy makes the policy immutable, and deploying the policy makes it
available for other applications to use. BizTalk Server uses the latest deployed version of
each business rule engine policy. In this exercise, you will deploy a new version of the
DiscountPolicy and then test it by using the BizTalk Server application.
Deploy Version 1.1 of the DiscountPolicy Business Rule Policy
Procedure List
1. In Policy Explorer, right-click Version 1.1 (not saved), and then click Save.
2. Right-click Version 1.1 in Policy Explorer, and then click Publish.
3. Right-click Version 1.1 in Policy Explorer, and then click Deploy.
Test the New Policy Version
Procedure List
2. Open ContosoPO_Large.xml, notice that the customer name is Conto, and then
3. Open FabrikamPO_Large.xml, notice that the customer name is Fabrik, and then
4. Copy ContosoPO_Large.xml and FabrikamPO_Large.xml to the
C:\AllFiles\LabFiles\Messages\POIn folder.
5. Navigate to C:\AllFiles\LabFiles\Module 3\Messages\Completed, notice the two
6. Open both POAck{GUID}.xml messages.
Notice that the message with a customer name of Fabrik has 5% discount
applied in the AckCode field, and that the message with Conto as the customer
name has 10% discount applied in the AckCode field.
7. Close Internet Explorer, and then delete all the messages in the Completed folder.
9. Open FabrikamPO_Medium.xml. Notice that the total order amount will equal 1030
and that the customer name is Fabrik, and then close Internet Explorer.
10. Copy FabrikamPO_Medium.xml to the POIn folder.
11. Navigate to C:\AllFiles\LabFiles\Module 3\Messages\Completed, and then open
the POAck{GUID}.xml message. Notice that the customer name is Fabrik and that
the AckCode field contains the text 2% discount applied.
12. Close Internet Explorer, and then delete the message from the Completed folder.
14. Open the ContosoPO_Small.xml file, notice that the customer name is Conto and
that the total order amount will equal 526, and then close Internet Explorer.
15. Copy ContosoPO_Small.xml to the POIn folder.
This folder simulates a more advanced process of manually approving the order.
17. Move the {GUID}.xml files to C:\AllFiles\LabFiles\Module
3\Messages\POReviewIn. Moving the message to this folder represents approving
the order.
18. Navigate to C:\AllFiles\LabFiles\Module 3\Messages\Completed.
19. Open the POAck{GUID}.xml file.
20. Notice that the customer name is Conto and that the AckCode field contains the
text 5% discount applied.
Scenario
In previous labs, all send and receive ports were provided for you. In this lab, you will create
send and receive ports. After you have created the physical ports, you will bind them to the
orchestration, and then submit several purchase orders to the BizTalk Server application to
see whether the purchase orders are successfully processed.
Procedure List
window.
Start.
Procedure List
Procedure List
Exercise 1: Create Receive Ports and Locations
Overview
BizTalk Server receive ports can have one or more receive location. In this exercise, you will
use BizTalk Server Administration Console to create a receive port with a single receive
location that uses the FILE adapter to process purchase orders from a directory. You will
then create and configure another receive port and a POP3 receive location.
Create and Configure a Receive Port and FILE Receive Location
Procedure List
BizTalk Group, Applications, and Module 4, and then click Orchestrations.
3. Double-click the ProcessOrder.OrchProcessOrder orchestration.
4. In the Orchestration Properties dialog box, click Bindings.
5. Notice that this orchestration has two Inbound Logical Ports and four Outbound
Logical Ports listed.
Logical ports are found in orchestrations, and they are used to specify logical
entry and exit points for messages as they are being processed by the
orchestration. All logical ports must be “bound” to physical ports before an
orchestration can process messages.
6. Click Cancel.
then click Receive Locations.
Naming receive ports with descriptive names is important for tracking and
troubleshooting later.
9. Click the New button.
10. In the Receive Location Properties dialog box, change the Name to
Here you are creating a physical receive location that will use the FILE adapter to
pick up messages for processing by the orchestration.
LabFiles, Module 4, and Messages, click PurchaseOrderIN, and then click OK.
Notice that you can create new folders from here if a folder does not already
exist.
14. In the Receive Location Properties window, click XMLReceive in the Receive
Receive pipelines handle such processes as decrypting a file and making sure the
inbound document matches a particular schema. In this case, any documents
processed by this receive location must be well-formed XML.
15. In the Receive Port Properties dialog box, click OK.
Create and Configure a SharePoint Receive Location
Procedure List
1. In the BizTalk Server Administration Console, right-click Receive Ports, point to New,
and then click One-way Receive Port.
2. In the Receive Port Properties dialog box, in the Name box, type ManualReview.
3. Click Receive Locations, and then click New.
4. In the Receive Location Properties dialog box, in the Name box, type
PurchaseOrderAckSharePoint.
5. In the Type list, click Windows SharePoint Services. In the Receive pipeline list, click
XMLReceive, and then click Configure.
click OK.
Property
Setting
Polling Interval
60
SharePoint Site URL
http://BIZTALKDEMO
Source Document Library URL
PurchaseOrderAck
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.
7. Click OK twice.
Exercise 2: Create Send Ports
Overview
BizTalk Server uses send ports to communicate with external systems. In this exercise, you
will create four send ports. The first is an FTP send port that is used to send shipping
information for all successfully processed purchase orders. The second is an SMTP port that
is used to forward purchase orders that need approval to the sales manager. The last two
send ports are used to separate approved and denied purchase orders into file folders.
Create and Configure an FTP Send Port
Procedure List
2. In the Send Port Properties dialog box, change the Name to ShipNoticeFTP, click
FTP in the Type list, and then click Configure.
FTP is one of several types of adapters that BizTalk Server can use to send
documents after they have been processed. Global configuration settings for the
FTP adapter can be found in the Adapters section of the Microsoft BizTalk Server
Administration Console, under Platform Settings.
3. In the FTP section of the FTP Transport Properties dialog box, configure the
properties as shown in the following table. Leave all other properties at the default
settings, and then click OK.
The Target File Name property adds the prefix ShipNotice to the GUID
associated with each approved purchase order’s shipment information.
Property
Setting
Folder
ShippedOrders
Password
pass@word1
Note: Click the down arrow to the right of the
Password box before entering the password.
Server
BIZTALKDEMO
Target File Name
ShipNotice%MessageID%.xml
User Name
Administrator
Create and Configure a SharePoint Send Port
Procedure List
2. In the Send Port Properties dialog box, change the Name to
ManualReviewSharePoint.
3. In the Type list, click Windows SharePoint Services, and then click Configure.
click OK.
Property
Setting
Destination Folder URL
PurchaseOrderAck
Filename
PoAck%MessageID%.xml
SharePoint Site URL
http://BIZTALKDEMO
This send port will send messages to a SharePoint Document Library named
PurchaseOrderAck.
5. Click OK to close the Send Port Properties dialog box.
Create and Configure a FILE Send Port for Denied Orders
Procedure List
2. In the Send Port Properties dialog box, change the Name to DeniedFILE, click FILE in
Notice that the word FILE appears in the name of the send port. It is a good
practice to include the adapter type in the name of your send ports for ease of
tracking and troubleshooting.
LabFiles, Module 4, and Messages, click Denied, and then click OK.
Denied%MessageID%.xml, and then click OK.
This prepends the word Denied to the name of any messages dropped in this
folder. Only messages that have been explicitly denied by the sales manager
should end up in this folder.
Create and Configure a FILE Send Port for Approved Orders
Procedure List
2. In the Send Port Properties window, change the Name to POAckFILE, click FILE in
LabFiles, Module 4, and Messages, click PurchaseOrderAck, and then click OK.
Completed%MessageID%.xml, and then click OK.
This pre-pends the word Completed to the name of any messages dropped in this
folder. Only purchase orders that were successfully processed should end up in
this folder.
6. In the Send Port Properties dialog box, click OK.
Exercise 3: Bind the Orchestration
Overview
In this exercise, you will bind the orchestration’s logical ports to the physical send and
receive ports that you created in earlier exercises.
Configure the Orchestration Bindings
Procedure List
1. In the BizTalk Server Administration Console, click Orchestrations.
2. Right-click ProcessOrder.OrchProcessOrder, and then click Properties.
3. In the Orchestration Properties window, click Bindings.
4. In the Orchestration Properties window, configure the properties as shown in the
following table, and then click OK.
Notice that logical receive ports can be bound only to physical receive locations
and logical send ports can be bound only to physical send ports.
Property
Setting
Host
BizTalkServerApplication
RcvPO
PurchaseOrders
RcvPOReview
ManualReview
SndPOReview
ManualReviewSharePoint
SndError
DeniedFILE
SndShipNotice
ShipNoticeFTP
SndFinalPOAck
POAckFILE
Exercise 4: Start and Test the Application
Overview
In this exercise, you will start and test the BizTalk Server application that processes purchase
orders.
Start the Application
Procedure List
Start.
2. Notice that the Configure Application dialog box states that the application cannot
be started because it is not fully configured. Click Yes to finish configuring the
application.
3. In the Configure Application window, notice that the orchCalculateShipping
orchestration has a yellow exclamation point next to it.
This orchestration has not been fully configured. Until all orchestrations are
configured, the application cannot start.
4. Click orchCalculateShipping.
5. Click BizTalkServerApplication in the Host list, and then click OK.
The BizTalk host defines the process boundary in which the orchestration will
run. Notice that this orchestration does not have any ports. It communicates
internally with the ProcessOrder.OrcheProcessOrder orchestration.
Start.
7. In the Start ‘Module 4’ Application dialog box, click Options, ensure that all of the
Procedure List
2. Copy the three ContosoPO… and the two FabrikamPO… XML messages to the
the original files are not retrievable.
4. In the PurchaseOrderAck folder, notice the four Completed{GUID}.xml messages,
open each, and verify that the AckCode field displays X% discount applied.
5. In Internet Explorer, type ftp://BIZTALKDEMO/ShippedOrders in the Address bar,
6. When prompted to log in, in the User name box, enter Administrator, and in the
Password box, enter pass@word1, then click Log On.
7. Notice the four ShipNotice{GUID}.xml messages.
The Evaluated view shows purchased that have been accepted or rejected.
processed.
13. Pause the bt10a-04 virtual machine.
Orchestrations
Scenario
In this lab, you will use the BizTalk Group Hub to troubleshoot archived messages. You will
also use the Group Hub page in the Microsoft BizTalk Server Administration Console to track
running business processes.
Preparation
Exercise 1: Track and View Message Activity
Overview
The BizTalk Group Hub page is used to view the details of running service instances, as well
as those of completed instances. In this exercise, you will use the Group Hub to view the
message flow of the messages that were processed in the previous lab. Then you will use the
Group Hub page to troubleshoot a running service instance.
Track Archived Message Activity by Using the BizTalk Group Hub
Procedure List
2. Copy ContosoPO_Large.xml to the PurchaseOrderIN folder.
3. In the BizTalk Server Administration Console, in the left pane, click BizTalk Group.
4. Press the F5 key to refresh the page.
6. In the Query results pane, right-click the first record that is listed with a Service
Name of Microsoft.BizTalk.DefaultPipelines.XMLReceive, and then click Message
Flow.
8. 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.
9. The lower section displays the flow of the message instance. This message was
received as an Unparsed Interchange through the PurchaseOrders port. It was then
sent to the ProcessOrder.OrchProcessOrder orchestration by using the
PurchaseOrders port.
10. Click the ProcessOrder.OrchProcessOrder link at the bottom of the page.
11. Notice that the Type of the service is Orchestration, the State is Completed.
12. In the lower section, notice that the message was received with the RcvPO port,
sent through the SndShipNotice and SndFinalPOAck ports.
13. Click the Microsoft.BizTalk.DefaultPipelines.PassThruTransmit link in the
SndShipNotice port section.
14. Information about the service instance is displayed.
15. Click the ProcessOrder.OrchProcessOrder link.
View Running Instances by Using the Group Hub Page
Procedure List
1. In Windows Explorer, navigate to C:\AllFiles\LabFiles\Module 4\Messages, and
then copy BadNameSpace.xml and ContosoPO_Small.xml to the PurchaseOrderIN
folder.
2. In the BizTalk Server Administration Console, in the center pane, click the Group Hub
tab.
3. Press F5 to refresh the page. Notice that there is one Running service instance and
one Suspended service instance shown as Resumable.
Remember to refresh the Group Hub page periodically, especially if you have
made a change and want to see new information on a running orchestration
instance.
If a service instance is marked as Resumable, it will continue to process the
message after the error is fixed.
4. Click Running service instances.
5. In the bottom pane of the Group Overview page, right-click
ProcessOrder.OrchProcessOrder, and then click Message Flow. The Message Flow
window allows you to track the message.
6. Close the Message Flow window.
7. In the lower pane, right-click ProcessOrder.OrchProcessOrder, and then click
Service Details.
9. Double-click the message with the Message Type of
http://MyCompany/OrderMgmt.PurchaseOrder#PurchaseOrder to open the
Message Details dialog box.
The General tab of the Message Details window displays information about this
message instance.
10. In the left pane, click Context.
The Context tab of the Message Details window displays the message context
information that is used to route and track the message.
11. In the left pane, click body. The body tab of the Message Details window displays
the message body.
12. Close the Message Details dialog box, and then close the Service Details dialog box.
15. In the Status list, choose Accept, and then close the form, saving your changes.
4\Messages\PurchaseOrderAck, and notice that the processed message is here.
It might take up to one minute for the message to appear.
17. In the BizTalk Server Administration Console, click the Group Hub tab, and then
press the F5 key to refresh the data.
The running service instance has now been completed and is no longer displayed
here.
18. Under Suspended Items, click Resumable.
19. In the lower pane, double-click the service instance with a Service Name of
PurchaseOrders.
20. Click the Error Information tab.
You can use the information on this tab to troubleshoot errors in the message.
You can also use Event Viewer to see BizTalk error messages.
22. Double-click the message in the lower pane.
23. In the Message Details dialog box, click body.
Notice in the first line that the namespace
(xmlns:ns0=“http://BADNAMESPACEDATA”) is not a valid namespace, in that
there are no assemblies deployed with a schema with this namespace. The
namespace should be http://MyCompany/OrderMgmt.PurchaseOrder.
24. On the File menu, click Save Message, and then click OK.
26. In the Browse for Folder dialog box, navigate to C:\AllFiles\LabFiles\Module
4\Messages, and then click OK.
28. Close the Message Details window, and then close the Service Details window.
29. In the lower pane, right-click the PurchaseOrders service, and then click Terminate
Instance.
30. Click Yes, and then click OK.
31. Click the Run Query button, and notice that there are no more Suspended
(resumable) instances.
Notice the two new files that have been created; one is the context of the saved
message, the other is the message itself, saved as an OUT file.
33. Rename the {GUID}_{GUID}_body.out file FixedNameSpace.xml.
34. Right-click FixedNameSpace.xml, and then click Edit.
35. In the first line of the message, change http://BadNameSpace to
http://MyCompany/OrderMgmt.PurchaseOrder, and then save and close the
message.
36. Copy FixedNameSpace.xml to the PurchaseOrderIN folder, and then navigate to the
PurchaseOrderAck folder and notice that the message was processed correctly.
37. Close all open windows, and pause the bt10a-04 virtual machine.
Scenario
BTSTask is a command-line utility used by BizTalk Server administrators for performing
common administrative tasks such as exporting an application to an MSI file, adding BizTalk
Server applications to a computer running BizTalk Server, or removing applications from a
computer running BizTalk Server. BTSTask can be used to script actions that are performed
multiple times on one or more servers. In this lab, you will use BTSTask to export an
application to an MSI file, remove the exported application, and then import a separate MSI
package. More information about the use of BTSTask can be obtained by typing BTSTask /?
at the command prompt.
Preparation
Exercise 1: Export and Remove an Application by Using BTSTask
Overview
Exporting an application to an MSI package groups all assemblies, ports, other artifacts, and
binding information into an MSI package for easy distribution to other computers running
BizTalk Server. In this exercise, you will export the Module 4 application to an MSI package
by using the BTSTask command-line utility. You will then remove the Module 4 application.
Export the Module 4 Application
Procedure List
2. In the Open box in the Run dialog box, type cmd, and then press ENTER.
3. In the command prompt window, type btstask /?, and then press ENTER to view the
available commands.
4. Type the following command and then press ENTER.
BTSTask ExportApp –ApplicationName:“Module 4”
–Package:“C:\ExportMod4.msi”
This step packages up all ports and artifacts in the Module 4 application into the
ExportMod4.msi file.
Remove the Module 4 Application
Procedure List
2. In the BizTalk Server Administration Console, expand BizTalk Server
Administration, BizTalk Group, Applications, right-click Module 4, and then click
Stop.
You must stop the application before you can remove it from the computer
3. In the Stop ‘Module 4’ Application dialog box, click Full Stop – Terminate instances,
Performing a full stop terminates any running, suspended, or dehydrated
instances of the orchestration. If any running, suspended, or dehydrated
instances are present in memory, the remove will fail.
ENTER.
BTSTask RemoveApp –ApplicationName:“Module 4”
Refresh.
Notice that the Module 4 application is no longer listed.
Exercise 2: Import a BizTalk Application by Using BTSTask
Overview
In this exercise, you will import a BizTalk Server application by using a MSI package. After the
application has been imported, you will configure and start the application. The Module 4
BAM application will be used in the next lab to test Business Activity Monitoring.
Import the Module 4 BAM Application
Procedure List
ENTER.
BTSTask ImportApp
-Package:"C:\AllFiles\LabFiles\Module 4 BAM\Module4-BAM.msi"
-ApplicationName:"Module 4 BAM"
2. In the BizTalk Server Administration Console, right-click Applications, then click
Refresh and notice that the Module 4 application has been removed, and that the
Module 4 BAM application has been deployed.
3. Right-click Module 4 BAM, and then click Configure.
4. In the Configure Application window, click OrderMgmtProcess, notice that the ports
and host have been configured, and then click OK.
5. Right-click Module 4 BAM, and then click Start.
Starting the application enables any receive ports, starts any send ports, and
makes the application available for testing.
6. In the Start ‘Module 4 BAM’ Application dialog box, click Start.
Scenario
BAM is a tool that is used to gather business data from archived and running business
processes. In this lab, you will use several tools, spanning multiple user roles, to configure
BAM to analyze data being processed by BizTalk Server.
Preparation
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.
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.
6. Navigate to C:\Program Files (x86)\Microsoft BizTalk Server 2010\ExcelDir, click
Bam.xla, and then click Open.
7. in the Add-Ins available list, check Business Activity Monitoring, then click OK.
8. In the Excel menu ribbon, on the Add-Ins tab, click BAM, and then click BAM
Activity.
9. In the Business Activity Monitoring Activity Definition dialog box, click New Activity.
10. In the Activity name box, enter OrderMgmt.
11. 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.
12. 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
State
Product
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.
13. 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.
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.
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.
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 “\Program Files (x86)\Microsoft BizTalk
Server 2010 (x86)\tracking”, and then press ENTER.
4. In the command prompt window, type bm.exe deploy-all -DefinitionFile:
“C:\AllFiles\LabFiles\Module 4 BAM\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
1. On the Start menu, click All Programs, click Microsoft BizTalk Server 2010, and then
click Tracking Profile Editor.
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
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.
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
TheImplementationOfOrderMgmt.PurchaseOrder, and then click OK.
Now you will map the City item to actual values from the physical 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.
then click OK.
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.
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.
then click OK.
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, verify that the profile was deployed
successfully, and then 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.
Procedure List
Configure SQL Server Analysis Services Proactive Caching
Procedure List
1. In Windows Explorer, navigate to C:\AllFiles\LabFiles\Module 4 BAM and doubleclick cfgBAMPart.cmd.
2. When prompted, press any key to close the command-line window..
This script configures SQL Server Analysis Services to refresh the OrderMgmt
OLAP cube every second. While this may be suitable in a development
environment, it would severely affect performance as the application processes
under heavier load.
Generate Initial Inbound Flow of Purchase Orders
Procedure List
1. In Windows Explorer, double-click the file C:\AllFiles\LabFiles\Module 4
BAM\Messages\Send20POs.bat.
The batch file used here generates 20 test orders so that you will have some data
to analyze in this exercise.
2. Close the Command Prompt window.
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\Module 4 BAM\ Messages\Send20POs.bat
to create and submit 20 new purchase orders.
Review the Detailed Status Information
Procedure List
1. Click the plus sign (+) to expand the function named Activity Search, and then click
OrderMgmt.
2. 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.
3. 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.
Scenario
You can create additional BizTalk hosts and MessageBoxes to provide for scalability and
security. In this lab, you will create a new BizTalk host. You will also create a new BizTalk
MessageBox database.
Procedure List
window.
Start.
Procedure List
Exercise 1: Manage BizTalk Hosts
Overview
BizTalk hosts provide the context that BizTalk Server components (orchestrations and ports)
run under. Using multiple hosts can provide scalability and security for the BizTalk Server
environment. In this exercise, you will create a new BizTalk host, an instance of the host, and
then reconfigure an orchestration to use the new host instance.
Create a New BizTalk Host and Host Instance
Procedure List
2. Expand BizTalk Server 2010 Administration, expand BizTalk Group, and then
expand Platform Settings.
5. In the Name field, type PurchaseOrderProcHost.
6. Select the Authentication Trusted check box.
7. In the Windows group field, type ADVENTUREWORKS\BizTalk Application Users,
and then click OK.
8. In the left pane of the BizTalk Administration Console, click Host Instances.
10. Set the Host name to PurchaseOrderProcHost, and then set Server to
BIZTALKDEMO.
11. Click the Configure button.
12. In the Logon Credentials dialog box, type ADVENTUREWORKS\PurchaseOrderHost
as the logon name and pass@word1 as the password.
13. Click OK twice.
Change the Host Instances Used by an Orchestration
Procedure List
1. In the left pane of the BizTalk Administration Console, right-click BizTalk Group, and
then click Refresh.
2. Expand Applications, and then expand Module 5.
3. Click Orchestrations, right-click ProcessOrder.OrchProcessOrder, and then click
Unenlist.
4. Double-click ProcessOrder.OrchProcessOrder.
5. In the Orchestration Properties dialog box, click Bindings in the left pane, then click
PurchaseOrderProcHost in the Host list, and then click OK.
6. Right-click the Module 5 application, and then click Start.
Exercise 2: Manage MessageBoxes
Overview
Multiple Messagebox databases can be used to provide scalability for your BizTalk
environment.
For performance reasons, when you add a second MessageBox database to the BizTalk
group it is recommended that a third be created as well. In this exercise, you will create a
second BizTalk MessageBox.
Create an Additional Message Box Database
Procedure List
1. In the left pane of the BizTalk Administration Console, under Platform Settings, click
Message Boxes.
box, and then type BizTalkMsgBoxDb2 in the Database box.
4. Click OK.
Scenario
All BizTalk implementations should include a comprehensive recovery plan that includes
database backup and restoration procedures. In this lab, you will back up the BizTalk Server
databases. To test the backups, you will delete all the databases from SQL Server and then
restore them from the backups.
Preparation
Exercise 1: Back Up BizTalk Databases
Overview
When the BizTalk Server configuration is performed and as the databases are created on a
computer running SQL Server, a SQL Server agent job is also created. This job automates the
process of backing up the BizTalk databases. A schedule to perform both full and
incremental backups of these databases should be enabled. In this exercise, you will perform
a full back up the BizTalk Server databases.
Configure the SQL Server Job
Procedure List
3. In Object Explorer, expand SQL Server Agent and Jobs.
4. Right-click the Backup BizTalk Server job, and then click Properties.
Steps page, select BackupFull, and then click the Edit button.
6. On the General page, in the Command box, edit the command by changing
‘<destination path>’ to ‘C:\AllFiles\LabFiles\Module 5\BizTalkBackup’, and then
click OK.
To avoid potential data loss, you should actually specify a computer for your
backup that is different from the computer with the original data.
7. On the Steps page, click MarkAndBackupLog, and then click Edit.
‘<destination path>’ to ‘C:\AllFiles\LabFiles\Module 5\BizTalkBackup\Logs’, and
then click OK.
Note that ‘Module 5’ within this path contains a space character.
9. On the Steps page, select Clear Backup History, and then click Edit.
10. On the General page, in the Command box, notice the DaysToKeep=14 option,
which indicates that the backup history will be kept for 14 days, and then click
Cancel.
Schedule the Backup BizTalk Server Job
Procedure List
Schedules page, select MarkAndBackupLogSched, and then click the Edit button.
3. Click One time in the Schedule type list, and then click OK.
Back Up the BizTalk Server Databases
Procedure List
2. In the Enable Jobs - BIZTALKDEMO dialog box, click Close.
(BizTalkMgmtDb), and then click Start Job at Step.
4. In the Start Job on ’BIZTALKDEMO’ dialog box, click Start.
5. In the Start Jobs - ‘BIZTALKDEMO’ dialog box, after the job has completed
successfully, click Close.
Exercise 2: Delete and Restore the BizTalk Databases
Overview
A careful disaster recovery plan should include occasional test restorations of the BizTalk
databases. In this exercise, you will delete the BizTalk databases, and then restore the
databases from the back up created in the previous exercise.
Delete Existing BizTalk Databases
Procedure List
2. Right-click Enterprise Single Sign-On Service, click Stop, and then click Yes in the
Stop Other Services dialog box.
3. In Microsoft SQL Server Management Studio, in Object Explorer, click Databases,
then in the View menu, click Object Explorer Details.
4. In the right pane, click each of the following databases while holding down the CTRL
key: BAMPrimaryImport, BizTalkDTADb, BizTalkMgmtDb, BizTalkMsgBoxDb, and
BizTalkMsgBoxDb2.
5. Right-click the selected items, and then click Delete.
and then click OK.
7. In the left pane, click Databases, then press the F5 key to refresh the view, and then
verify that the databases are no longer listed.
An error message appears because the BizTalkMgmtDb database does not exist.
If the BizTalk Administration Console was already open, then you will need to
press the F5 key to see the error message.
10. Close the BizTalk Server Administration Console.
Restore the BizTalk Database
Procedure List
Restore Database.
4. In the Locate Backup File dialog box, navigate to C:\AllFiles\LabFiles\Module
5\BizTalkBackup, select BIZTALKDEMO_BAMPrimaryImport_Full_BTS….bak, and
then click OK.
6. In the Restore Database dialog box, in the Select the backup sets to restore list,
select the Restore check box, and then click the Options tab.
8. In the Restore Database dialog box, click OK.
9. In the Microsoft SQL Server Management Studio dialog box, verify that the message
states that the database was restored successfully, and then click OK.
To database
Backup file
BizTalkMsgBoxDb2
BIZTALKDEMO_
BizTalkDTADb
BizTalkMgmtDb
BizTalkMsgBoxDb
12. In the Services window, right-click Enterprise Single Sign-On Service, then click
Start.
14. Expand BizTalk Server 2010 Administration, BizTalk Group, and Applications.
15. Right-click Module 5 and then click Stop.
16. In the dialog box click Stop.
18. In the dialog box click Start.
Procedure List
2. Copy the ContosoPO_Large.xml file to the PurchaseOrderIN folder.
3. After the message disappears from the PurchaseOrderIN folder, navigate to the
PurchaseOrderAck folder, and notice the PoAck{GUID}.xml message.
4. Navigate to the Shipped folder, and notice the and the Shipment{GUID}.xml
message.
5.
Close all open windows, and shut down the virtual machine.
Lab 6a: Installing BizTalk 2010 Management Pack
Scenario
In order for SCOM to monitor our BizTalk Server and look for BizTalk specific events, we
need to install the BizTalk Server 2010 Management Pack.
Procedure List
window.
Start.
Procedure List
Exercise 1: Install BizTalk 2010 Management Pack from System Center
Operations Manager console
Overview
Since our lab environment does not have internet connectivity, the BizTalk Server 2010
Management Pack has been downloaded and unpackaged. We now need to import this
Management pack in the SCOM console.
Procedure List
Navigate to Management Packs View
Procedure List
1. In the lower left corner of the Operations Console, click on the Administration
button.
2. In the left pane, find Management Packs, right-click and select Import Management
Packs.
3. A new form will load called Import Management Packs. Find the Add button, click it
and then select Add from disk …
4. When prompted to search an online catalogue for dependent management packs
select No.
5. When prompted to Select Management Packs to import, browse the C:\Program
Files (x86)\System Center Management Packs\BizTalk Server 2010 Monitoring
Management Pack\ folder and select the 3 Management Packs that exist in this
folder: Microsoft.BizTalk.Server.2010.Discovery.mp,
Microsoft.BizTalk.Server.2010.Library.mp and
Microsoft.BizTalk.Server.2010.Monitoring.mp. Once selected, click the Open
button.
6. We should now see an Import list that contains these three management packs and
a green check mark beside each one.
7. The Status details should display a message indicating This management pack is
ready to import.
8. Click the Install button to proceed.
9. After a couple minutes, we should see that all 3 Management Packs have been
Imported successfully and have a green check mark beside each one.
10. Click Close to complete this wizard.
11. In the center of our Management Packs view, we should now see 3 BizTalk related
Management Packs: BizTalk Server Discovery, BizTalk Server Library and BizTalk
Server Monitoring.
Note: it may take a couple minutes for the BizTalk Management Packs to appear in
the Management Packs list in the center pane of the console.
Lab 6b: Generating and Resolving BizTalk Host Instance Alerts
Scenario
In the previous demonstration we saw how the state of the Rule Engine Update Service had
an impact on the overall health of a BizTalk environment. In this Lab we are going to
discover the impact that a BizTalk Host instance has on BizTalk’s health. We will see
BizTalk’s Host State health change and an Alert will be generated in the Active Alerts view.
We will then discover how to start this Host instance from SCOM Console and watch both
the Active Alerts and Host State views change.
Launch the BizTalk Administration and System Center Operations Manager
console
Procedure List
Exercise 1: Generating and Resolving BizTalk Host Instance Alerts
Procedure List
1. In the BizTalk Administration Console ensure that your BizTalkServerApplication
Host Instance has a status of Running.
2. Switch to the SCOM Operations Console. Click on the Monitoring view button in the
bottom left pane.
3. In the left pane, expand the Microsoft BizTalk Server 2010 view.
4. Expand Applications Views and then click on Hosts State View.
5. In the center pane, observe the State column value for the BizTalkServerApplication
Host. This value should have a value of: Healthy.
6. Click on the BizTalkServerApplication record and then click on the Stop BizTalk Host
label in the BizTalk Host Tasks pane on the right hand side.
7. In the Run Task – Stop BizTalk Host form that loads, ensure the
BizTalkServerApplication checkbox is checked and click the Run button.
8. A Task Status – Stop BizTalk Host form will load indicating the status of this action.
When complete, the status column should have a value of Success. Click the Close
button to close this form.
10. You should now see Severity:Critical alert in the center pane. The source of this
alert should be the name of our BizTalk Host Instance: BizTalkServerApplication.
Note: It may take up to 10 minutes for this alert to appear within this Alerts View.
11. To obtain more information about this alert. Double click on the record. An Alert
Properties form will be displayed. Here you will find diagnostic information about
the alert including Product Knowledge from Microsoft, Company Knowledge where
organizations have the ability to provide their own information, History, Alert
Context, and Custom Fields. Click on the OK button to close this form.
12. If we navigate back to the Hosts State View, as described in Step #4, we should see
that the state of our BizTalkServerApplication Host Instance has changed its state
from Healthy to Critical.
Explorer for BizTalkServerApplication. Once launched, expand Entity Health –
Availability – BizTalk Host Availability Monitor and click the Recalculate Health
button at the top of the form.
13. To start our BizTalk Host instance back up, select the BizTalkServerApplication
record and then click the Start BizTalk Host label found in the BizTalk Host Tasks
found in the right hand pane.
14. In the Run Task – Start BizTalk Host form, ensure BizTalkServerApplication is
checked and click the Run button.
15. In the Task Status – Start BizTalk Host form, a status column will indicate the state
of this action. Once the status value has changed to Success, click the Close button.
17. The Severity:Critical alert, that was described in step 10, indicating the
BizTalkServerApplication Host Instance was offline should no longer exist within the
pane. You may need to refresh your console by pressing the F5 button. This alert
was automatically cleared since SCOM has determined that the issue has been
resolved.
18. Navigate back to the Hosts State View, as described in Step #13. Press the F5
button to refresh your console. We should see that the state of our
BizTalkServerApplication Host Instance has changed its state from Healthy to
Critical.
Note: if the state of your Host Instance has not changed, you may need to run the
Health Explorer. To do this select the BizTalkServerApplication record and then click
the Health Explorer for BizTalkServerApplication. Once launched, expand Entity
Health – Availability – BizTalk Host Availability Monitor and click the Recalculate
Health button at the top of the form. Once the Health Explorer process is complete,
press the F5 button to refresh your console.
Lab 6c: Generating and Closing Application Alerts
Scenario
One of BizTalk Server’s core competencies is the ability to process different types of
messages from a variety of trading partners. Since some of these messages are received
from external parties, the messages that are received may not be the same type of message
that we are expecting. These messages that have an unexpected format may fail to be
processed in the inbound receive pipeline. SCOM provides us with visibility into these
situations so that we can react when these events occur.
Conversely, we may want to send messages from our organization to another. In these
situations it is important to raise Send Port errors when they occur so the appropriate
support staff can address the issue before Service Level Agreements (SLAs) are missed. Once
again SCOM provides BizTalk Administrators with visibility into these types of issues.
Exercise 1: Generating and Closing Receive Pipeline Errors
Overview
An existing solution called Module 6 has been deployed for the purposes of this Lab. This
application is a copy of a previous lab that has been renamed. The goal of this lab is to
submit a message to an existing Receive Location that will fail validation within the Receive
Pipeline. We can expect a Suspended Message instance inside the BizTalk Administration
console. In the SCOM Operations Console we expect an alert to be generated within the
Active Alerts menu.
Procedure List
click on Start.
Procedure List
2. Right mouse click on GenerateReceivePipelineError.xml file and select Copy.
BIZTALKDEMO.adventureworks.lab and a Name of ERROR: FILE-Receive Message
Suspended.
form.
Close the Alert
Exercise 2: Generating and Closing Suspended Message Errors
Overview
In the previous example we demonstrated generating an alert for an inbound event. In this
example we are going to generate an event for an outbound operation. We are going to use
this same Module 6 BizTalk application. In order to get the outbound message to fail, one of
our send ports is configured to deliver files to non-existent location. In order to expedite
these files to fail, the send port retry interval has been set to 0.
Procedure List
1. On the Start menu, point to All Programs, point to Microsoft BizTalk Server 2010 and
then click on Microsoft BizTalk Server 2010.
click on Start.
Procedure List
2. Right mouse click on GenerateSendPortError.xml file and select Copy.
BIZTALKDEMO.adventureworks.lab and a Name of ERROR: An outbound message
is being suspended by the Adapter.
form.
Close the Alert

MCTS Biztalk Server 2010 Administrator Courseware

Transcription

Similar documents

Integrating Mainframe Systems in Microsoft® Environments

Piano Spec Sheet Template

Remote System Management

(Harrisburg Area Community College Project), Series of 2016 Sta

RESULTS COMMERCIAL INSIGHTS CHALLENGES

StairMaster Gauntlet - Tower Fitness Equipment Services Inc.

Flyer - Indu-Sol

19 FT Center Console Boat Comparison | Yamaha Boats

The 800-Pound The 800-Pound

user manual for the HP J3591A