Designing for Operations - · PDF fileothers might use message queuing or something else. ... Dynamic Update No ... Siebel and JDEdwards

Designing for BizTalk Server

Prepared for Technet

Wednesday, 30 December 2015

Version 1.0

Prepared by

Balbir Singh Brench

Solutions Architect

[email protected]


Page ii


Page iii

Table of Contents

1 Executive Summary ............................................................................................................... 6

2 BizTalk Server........................................................................................................................ 7

2.1 Introduction ................................................................................................................................. 7

2.1.1 Key Features ........................................................................................................................ 8

2.2 Key Components ........................................................................................................................ 10

3 BizTalk Technology Choice ................................................................................................... 11

3.1 Standard Based Interchanges .................................................................................................... 11

3.2 Third Party Hosts and Applications ............................................................................................ 11

3.3 Asynchronous Communication Pattern ..................................................................................... 12

3.4 Synchronous Communication Pattern ....................................................................................... 12

4 BizTalk Scenarios ................................................................................................................. 14

4.1 Enterprise Application Integration (EAI) .................................................................................... 14

4.2 Business Process Automation (BPI) ............................................................................................ 15

5 BizTalk Architecture ............................................................................................................ 17

5.1 Publish/Subscribe Model ........................................................................................................... 17

5.2 Logical Architecture ................................................................................................................... 17

5.2.1 Receive Ports and Receive Locations ................................................................................ 19

5.2.2 Send Ports and Send Port Groups ..................................................................................... 19

5.2.3 Pipelines ............................................................................................................................ 19

5.2.4 MessageBox Database ...................................................................................................... 21

5.3 BizTalk Adapter and Accelerators .............................................................................................. 22

5.3.1 Receive Adapter ................................................................................................................ 23

5.3.2 Send Adapter..................................................................................................................... 23

5.4 BizTalk Orchestration Engine ..................................................................................................... 23

5.4.1 Dehydration and Rehydration ........................................................................................... 24

5.5 Hosts and Host Instances ........................................................................................................... 25

6 BizTalk Applications ............................................................................................................ 28

6.1 BizTalk Project ............................................................................................................................ 28

6.1.1 Schemas ............................................................................................................................ 29


Page iv

6.1.2 Maps .................................................................................................................................. 29

6.1.3 Pipelines ............................................................................................................................ 29

6.1.4 Orchestrations................................................................................................................... 29

6.1.5 Business Rules ................................................................................................................... 29

6.2 Visual Studio 2012 Development Tools ..................................................................................... 30

6.2.1 BizTalk Editor ..................................................................................................................... 30

6.2.2 BizTalk Mapper.................................................................................................................. 31

6.2.3 Pipeline Designer .............................................................................................................. 31

6.2.4 Orchestration Designer ..................................................................................................... 31

7 Business Rules Engine (BRE). ................................................................................................ 33

7.1 Business Rules Composer ........................................................................................................... 34

7.2 Business Rule Vocabularies ........................................................................................................ 34

7.3 Business Rule Policy ................................................................................................................... 35

8 Business Activity Monitoring (BAM) ..................................................................................... 36

8.1 BAM Activities ............................................................................................................................ 37

8.2 BAM Views ................................................................................................................................. 37

8.3 Aggregating and Filtering Data .................................................................................................. 37

9 BizTalk Design Patterns ....................................................................................................... 39

9.1 Aggregator.................................................................................................................................. 39

9.2 Calling Pipelines from an Orchestration .................................................................................... 39

9.3 Composed Message Processor .................................................................................................. 39

9.4 Content-Based Router ................................................................................................................ 40

9.5 Dynamic Router .......................................................................................................................... 40

9.6 Error Handling ............................................................................................................................ 40

9.7 Exception Handling and Compensation ..................................................................................... 40

9.8 Message Broker.......................................................................................................................... 41

9.9 Message Filter ............................................................................................................................ 41

9.10 Message Translator ................................................................................................................ 41

9.11 Parallel Convoy ....................................................................................................................... 41

9.12 Scatter and Gather ................................................................................................................. 42


Page v

9.13 Sequential Convoy .................................................................................................................. 42

9.14 Splitter .................................................................................................................................... 42

9.15 Suspend with Retry................................................................................................................. 42

10 Management and Operations .......................................................................................... 43

10.1 Deploying a BizTalk Application.............................................................................................. 43

10.1.1 MSI Packages. ................................................................................................................ 44

10.2 Tracking and Debugging BizTalk Processes ............................................................................ 45

10.3 Monitoring BizTalk Applications Using SCOM ........................................................................ 46

11 BizTalk Infrastructure Architecture ................................................................................... 48

11.1 Single Server – No High Availability ........................................................................................ 48

11.2 Multi Server – High Availability .............................................................................................. 49

11.3 Multi Server – High Availability and High Throughput ........................................................... 50

12 References ....................................................................................................................... 51


P a g e | 6

1 EXECUTIVE SUMMARY

This document is primarily intended to be used by Application Architects and System Designers. Its

main purpose is provide knowledge on the key features of BizTalk Server 2013, so that the designers

can make the correct technology choice for the application design under consideration.

The following sections provide information on

Key features of BizTalk Server 2013.

Selecting BizTalk as the Integration Platform.

Typical BizTalk Server Integration Scenarios.

Overview of BizTalk Server Architecture.

Development Tools.

Patterns and Practices.

Infrastructure Architecture.

Operations Monitoring.


P a g e | 7

2 BIZTALK SERVER

BizTalk Server is Microsoft's premier server for building business process and integration solutions.

BizTalk Server 2013, the eight major version of the product, builds on the innovation and success

introduced by the previous five versions and now includes full support and integration with

Windows Server® 2012, SQL Server® 2012, and Visual Studio® 2012.

BizTalk Server 2013 offers significant improvements and capabilities over BizTalk Server 2010 for

connecting applications and businesses, automating and managing business processes, and building

solutions based on a service-oriented architecture.

2.1 Introduction

The great majority of modern business processes depend on software. In most organizations, this

software has been created at different times using different technologies on different platforms.

Accordingly, automating business processes requires connecting diverse system, this brings its own

set of challenges.


P a g e | 8

Doing this requires solving many different problems, none of them simple.

These are the Integrations challenges that BizTalk Server 2013 addresses by acting as a central

integration platform. BizTalk 2013 allows you to:-

Connect to diverse software using a range of different approaches. Web services can be the

best choice for some connections, simple file sharing might be better for others, while still

others might use message queuing or something else.

Connect with line-of-business (LOB) applications.

Support, control, host and execute the automated processes.

Make connecting with applications in other organizations as easy as possible. This is

provided by supporting industry standards for cross-organization interactions, such as

Electronic Data Interchange (EDI), providing services that help connect to trading partners,

and more.

Monitor business processes in real time.

Handle events from the physical world, such as those generated by radio-frequency

identification (RFID) tags. These events can be connected to existing applications

2.1.1 Key Features

In an organisation, architects often have to select the appropriate technology to implement business

solutions. In order to assist with the selection process, the following table lists capabilities that are


P a g e | 9

provided out of the box by BizTalk Server 2013. The list also contain capabilities which are not

available in BizTalk Server 2013, but may be available in other Microsoft products.

Feature Available

Orchestration Yes

Low Latency No

Web Services Yes

Messages Yes

Durable Messaging Yes

Visual Designer Yes

Persistence Yes

Hydration / Dehydration Yes

Suspend / Resume Yes

Operations Monitoring Yes

Dashboard Yes

Tracking Yes

Versioning – Side by Side No

Versioning – Dynamic Update No

Business Activity Monitoring Yes

Cloud Host (Azure) Yes

Publish / Subscribe Yes

Integration Adapters Yes

Data Transformation Yes

Message Redelivery Yes

Rules Engine Yes

BPEL Yes

Throttling Yes


P a g e | 10

2.2 Key Components

BizTalk Server provides a host of capabilities that enable developers to create powerful business

process integration and management solutions and allow administrators and business users to

effectively monitor ongoing business processes. BizTalk Server 2013 includes the following core

components

Messaging. BizTalk Server enables the efficient processing of incoming and outgoing

messages. This capability provides connectivity to disparate systems and trading partners

through a variety of file formats and adapters and is enforced by message-level security.

Orchestration. BizTalk orchestration provides transactional and non-transactional message

processing through centrally managed business processes. Orchestrations enable the

automation and standardization of complex processes that are composed in an intuitive

visual drawing and executed by the BizTalk Orchestration engine at run time.

Business Rules Framework. The Business Rules Framework enables the creation of business

rule policies that define the logic for a given business process. The policy logic abstracts the

business process logic out of an orchestration. This enables updates to be made to the

business process logic without requiring recoding of the orchestration.

Business-to-Business integration. Electronic transactions with trading partners can play a

vital role in enterprise business processes. BizTalk Server enables business-to-business

integration through industry standards and well-established protocols such as Electronic

Data Exchange (EDI) data (including X12, EDIFACT, and HIPAA support) and Availability

Statement 2 (AS2) data for EDI over the Internet. BizTalk Server Accelerators speed up the

development of B2B solutions within specific industry segments that adhere to specific

protocols such as SWIFT, HL7, and RosettaNet.

BizTalk RFID. BizTalk RFID provides a device management and event processing platform

that enables the development, deployment, and management of Radio Frequency ID (RFID)

and sensor solutions.

Business Activity Monitoring (BAM). BAM provides real-time monitoring and archived

statistical data of BizTalk processes. BAM enables business users to gain true end-to-end

visibility of these processes.

Management and Operations. BizTalk Server has robust management of the BizTalk Server

runtime environment, including application management, application deployment, host

management, and process execution tracking and reporting.

Tools. BizTalk Server provides a number of tools that help configure, design, deploy,

manage, and view BizTalk processes and capabilities. These tools come in a variety of forms;

some are integrated into Microsoft Visual Studio 2012, some are add-ins to the Microsoft

Management Console (MMC), while others are Web-based.


P a g e | 11

3 BIZTALK TECHNOLOGY CHOICE

For most of the scenarios that involve server-based business processes, BizTalk Server 2013 is the

right choice. These include EAI, B2B Process, Abstraction of Rules from Business Process, Enterprise

Rule Repository, and Enterprise Service Bus (ESB)/Message Broker.

In these scenarios, you want to focus on producing business value, instead of investing in building

the "plumbing" to make your solution scalable, reliable, and manageable; so, the licensing cost of

BizTalk Server 2013 is well worth it, because of what it provides.

These scenarios require high scalability. Also, they require the ability to view running processes, and

to stop and restart them. Finally, they require support for scaling out to multiple servers. In these

scenarios, the advanced hosting features of BizTalk Server 2013 are required and well worth the

investment.

BizTalk Server 2013 is generally going to be the best platform for the Long Running Business Process

scenario. These processes tend to be asynchronous, long-running, and stateful. These processes are

often mission-critical to the organization; therefore, they require high availability, visibility, security,

and manageability. The Group or "Farm" topology of BizTalk Server 2013 allows you to manage an

array of servers to provide scalability and redundancy.

The persistence mechanism of BizTalk Server 2013 for storing process state has robust security built

in to protect the privacy of the persisted state, which might be important for regulatory reasons. The

Business Activity Monitoring (BAM) of BizTalk Server 2013 provides appropriate business-level

visibility into the running processes in a secure fashion. Finally, these scenarios often require support

for heterogeneous message formats and transport protocols, including legacy systems.

3.1 Standard Based Interchanges

If the application will be using standard based interchanges then use BizTalk Server.

Description

Industry groups seeking to standardize messages within their respective industries develop

standards message formats. These standard message formats are very complicated and require a

large amount of up-front effort to implement.

Examples of Standards Based Interchanges are EDI, HIPAA, SWIFT and RosettaNet.

Reason

BizTalk has accelerators for most of these industry message standards. Choosing BizTalk will enable

the project team to focus on more implementing the business process and less on the complicated

message format.

3.2 Third Party Hosts and Applications

If the application will integrate with third party hosts and applications then use BizTalk Server.

Description


P a g e | 12

Mainframe application integration and Enterprise Applications like SAP, Siebel and JDEdwards

presents special challenges such as WebSphere MQ Integration, LU6.2 Integration and Enterprise

Application specific message formats.

Reason

Host Integration Server (HIS) contains many features designed for mainframe or host system

integration. HIS is part of BizTalk product. Implementing BizTalk’s HIS features will minimize the

time required to deliver a solution.

BizTalk has adapters for Enterprise Applications. These adapters will accelerate the solution

development.

3.3 Asynchronous Communication Pattern

If the application will be using asynchronous messaging pattern then use BizTalk.

Description

The Asynchronous communication pattern occurs when a user or another application submits a request to the application and is able to start work on other tasks. The application processes the request at its convenience and optionally notifies the user or application when it is complete. An example of an asynchronous communication pattern is an email. A user submits the email to an email server. The user is then able to perform other tasks. The email server sends the email to the recipient at its convenience. It may also provide a return receipt after the recipient opens the email.

Reason

This scenario aligns well with BizTalk features. Orchestrations can be used to communicate with multiple systems. Orchestrations also support long-running transactions for transactions that may take a long time to return. In addition, Business Activity Monitoring can be used to track the state of a transaction and to provide long-term metrics.

3.4 Synchronous Communication Pattern

If the application will be using synchronous messaging and average response required is less than 1.5 seconds then use BizTalk Sever with AppFabric. Although BizTalk Server can be tuned for low latency by adjusting the polling interval on a host basis, it would be more efficient to implement the low latency part of the application in AppFabric. If the application will be using synchronous messaging and average response required is greater than 1.5 seconds then use BizTalk Sever.

Description

The Synchronous communication pattern occurs when a user waits for a response before processing other tasks.


P a g e | 13

An example of a synchronous communication is using a search engine. The user submits a search request, waits for search results, clicks on a results link and navigates to the web page.

Reason

The design of BizTalk Server of persisting every message to the MessageBox database for durability

introduces additional latency.

All communication within BizTalk is through the SQL Server based message box. BizTalk polls the SQL Server database to determine which subscribing components should receive the message. BizTalk will serialize a message into the Message Box when it is received by BizTalk, then serialized into and out of the message box for each real-time message call (e.g. Web Service) and serialize it into the message box prior to sending it back out to the calling application.


P a g e | 14

4 BIZTALK SCENARIOS

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 that

were never designed to work together. This is because each application is usually designed to fulfil a

specific task—such as inventory tracking, human resources management, or customer relationship

management (CRM).

There are three main integration scenarios:-

Connecting applications within a single organization: Enterprise Application Integration

(EAI).

Connecting applications in different organizations: Business to Business (B2B).

Creating applications through combination of above and added development: Business

Process Automation (BPA).

4.1 Enterprise Application Integration (EAI)

BizTalk Server 2013 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, in BizTalk Server 2013, expands its toolset with many industry accelerators and adapters.

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:

The request is sent to a BizTalk Server 2013 application

1. The BizTalk application requests a purchase order (PO) from the organization’s Enterprise

Resource Planning (ERP) application.

2. The ERP application, which might be running on a UNIX system, sends back the requested

PO.

3. The BizTalk application informs a fulfillment application, built on the Microsoft, .NET

Framework, that the item should be ordered.


P a g e | 15

In this scenario, each application communicates by using a different protocol and by 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. Note that no single

application is aware of the complete business process. The business process, along with the

intelligence required to coordinate all of the parts while tracking the status of the business process,

is implemented in the BizTalk application.

4.2 Business Process Automation (BPI)

For automation of critical business activities, the BizTalk Server engine uses orchestrations to define

the logic of these business processes. To create and evaluate groups of business rules, it uses the

Business Rule Engine.

Orchestrations are designed using shapes such as Send, Receive, Transform, Construct, and Decide

that are used to coordinate system-to-system communication that requires more processing beyond

the capabilities of the messaging engine. This provides coordination between different external

processes leading to higher productivity and efficiency.

For example, if your organization has employees who approve invoices and purchase orders, and

then manually submit them to the next person or application in the process, this can result in an

inefficient and time-consuming process. By automating business processes, a business uses

technology to manage the flow between users, databases, applications, and vendors, Automating

business processes is much more productive and efficient than trying to achieve the same results

without automation tools.


P a g e | 16


P a g e | 17

5 BIZTALK ARCHITECTURE

At the core of BizTalk Server 2013 are the Messaging Engine and the Orchestration Engine, which

provide the underlying architecture for integrating and exchanging messages between various

services, both within and outside your organization.

The BizTalk Messaging Engine:

Receives inbound messages.

Parses inbound messages to identify their specific formats.

Evaluates message content to identify how the message is to be routed and processed.

Delivers messages to their respective destinations.

Tracks the status and state of documents.

The BizTalk Orchestration Engine, in contrast, coordinates and schedules message processing and

performs complex logic on the message as it is passed through a defined workflow.

5.1 Publish/Subscribe Model

BizTalk Server implements the publish/subscribe model to route messages. The publish/subscribe

model enables developers to design processes and services that subscribe to messages rather than

create point-to-point connections between two services. This enables new service providers and

consumers to be added or existing services to be modified without having to redesign the

application.

In this model the message providers, also called the publishers, submit messages to a central store

(the MessageBox database). The subscribers, which can be send ports or orchestrations, subscribe to

specific messages. After the MessageBox receives a message of interest, the message is delivered to

all subscribers.

Subscriptions in BizTalk Server are based on matching expressions to name and value pairs

associated with each message that is processed by BizTalk Server. These name and value pairs are

known as message context properties. Each BizTalk message has a message context associated with

it, which travels with the message as it is processed by BizTalk Server. The message context is

represented in memory as an object, and persisted with the message as a set of name and value

pairs when stored in the MessageBox database. When a message is received by the MessageBox,

certain message context properties are evaluated against known subscriptions, which are

expressions made up of potential message context properties and values and operators (such as

“And”, “Or”, and “Exists”).

5.2 Logical Architecture

The following diagram shows how BizTalk Server implements the publish/subscribe model.


P a g e | 18

1. Messages enter the BizTalk Server system through a receive port. Each receive port contains

one or more receive locations. Each receive location is configured with an adapter, which

defines the communication method used to connect to and receive data from an external

system or application, such as a file folder, an HTTP site, an SQL database, or a third-party

application.

2. The received message is processed by the receive pipeline. A pipeline can contain various

components that help decrypt a secure message, split batched messages, convert a message

from its native format into an XML document, or validate the digital signature of a message.

3. Receive ports can optionally be configured with one or more maps, which transform

messages from one data structure to another. Maps are used to transform messages from

various disparate formats to a single internal or canonical format used by the BizTalk

application.

4. The message is then delivered to a Microsoft SQL Server database, called the MessageBox.

When a message arrives in the MessageBox, the metadata associated with the message is

evaluated against the existing subscriptions to determine which send ports or orchestrations

the message should be delivered to.

5. An orchestration defines the logic that controls a business process workflow. A business

process can use one or more orchestrations. Each of these orchestrations consists of specific

types of shapes that are used to express conditions, loops, and other behaviors.

6. The message, which may or may not be processed by an orchestration, can be delivered to a

send port. The send port can transform the message data using a map and then process the

message through a send pipeline.


P a g e | 19

7. The send pipeline may convert the message from the internal XML format used by BizTalk

Server to the format required by its destination as well as encrypt the message for secure

communication.

8. The send port then uses an adapter to connect and transmit the data to the external system

or application.

5.2.1 Receive Ports and Receive Locations

A receive port is a collection of one or more receive locations that define specific entry points into

BizTalk Server. A receive location is a combination of a receive adapter and a receive pipeline. The

adapter is responsible for the transport and communications part of receiving a message. Examples

include the File adapter and SOAP adapter, each of which receives messages from different types of

sources. The receive pipeline is responsible for preparing the message for publishing into the

MessageBox. A pipeline is a series of components that are executed in sequence, each providing

specific processing to a message such as decryption/encryption, parsing, or validation.

5.2.2 Send Ports and Send Port Groups

A send port group is a collection of send ports and works much like an e-mail distribution list. A

message sent to a send port group will be sent to all send ports in that group. A send port is the

combination of a send pipeline and a send adapter. The send pipeline is responsible for preparing a

message coming from BizTalk Server for transmission to another service. The send adapter is

responsible for actually sending the message using a specific protocol such as SOAP, or FTP.

5.2.3 Pipelines

The purpose of a pipeline is to prepare a message for processing by the server after it has been

received by an adapter or to prepare a message for sending through an adapter after it has been

processed by BizTalk Server. A pipeline is a set of .NET components that process messages in a

predefined sequence to complete a specific task, such as encrypting a document or validating a

document against a schema. Pipelines enable pre- and post-processing of messages as they enter or

leave the MessageBox database, which means that pipelines can process messages either as they

are received or just before they are sent out through a send port.

Pipelines provide additional processing to messages such as encoding and decoding, encrypting and

decrypting, and other processing that might be required when working with messages in BizTalk

Server. You can also call a pipeline component from within an orchestration.

Pipelines commonly perform:

Data normalization from various formats to XML.

Data transformation from XML to various formats.


P a g e | 20

Property promotion and demotion to enable routing decisions based on specific data in a

message.

Document disassembly and assembly.

Document decoding and encoding.

Document decryption and encryption.

Document signing and digital signature verification.

Receive Pipe Line

Stage Purpose

Decode Decrypts or decodes the message data

Disassemble Disassembles an interchange into smaller messages and parses message contents

Validate Validates the message data, generally against a schema

Resolve

Party

Identifies the BizTalk Server party associated with some security token in the

message or message context

Send Pipe Line


P a g e | 21

Stage Purpose

Pre-

assemble

Performs any message processing necessary before assembling the message

Assemble Assembles the message and prepares it to be transmitted by taking steps such as

adding envelopes, converting XML to flat files, or other tasks complementary to the

disassemble stage in a receive pipeline

Encode Encodes or encrypts the message before delivery

5.2.4 MessageBox Database

The heart of the publish/subscribe engine in BizTalk Server is the MessageBox database. The

MessageBox is made up of two components: one or more Microsoft® SQL Server™ databases and

the Messaging Agent. The SQL Server database provides the persistence store for many things

including messages, message parts, message properties, subscriptions, orchestration state, tracking

data, host queues for routing, and others.

In addition, using stored procedures, the database provides some of the business logic related to

routing messages and fulfilling subscriptions. The Message Agent, however, is the component that

encapsulates and abstracts the database component and is the interface used by all parts of BizTalk

Server to interact with the messaging subsystem. The Message Agent is a Component Object Model

(COM) component that provides interfaces for publishing messages, subscribing to messages,

retrieving messages, and so on. This interface is the only mechanism used by other BizTalk Server

components, including the adapter framework and orchestrations, to interact with the MessageBox.


P a g e | 22

5.3 BizTalk Adapter and Accelerators

BizTalk Server 2013 requires specialized adapters to exchange messages with disparate applications

and systems. An adapter is a.NET-based software component that enables BizTalk Server to interface

with different types of systems through standards-based protocols and with specialized applications

that use proprietary communication mechanisms.

Most adapters support both send and receive operations, whereas others support communication in

a single direction only. You define the behavior of an adapter by configuring the properties of the

send port or the receive location for a given instance of an adapter.

Using adapters greatly simplifies the transfer of messages into or out of BizTalk Server. If your

existing infrastructure uses any of the transports for which there is a corresponding BizTalk adapter,

then the process of sending messages to or receiving messages from BizTalk Server is as simple as

configuring the appropriate adapter to send or receive messages with the corresponding transport

mechanism. The table below show the Adapters that are supplied with BizTalk Sever 2013.

In addition to the adapters included in BizTalk Server 2013, there are two additional sources of

BizTalk adapters:

BizTalk partner adapters. For unique and specialized integration scenarios, adapters have

been created by a number of third-party companies. These application-specific and

technology-specific adapters can be purchased from companies who specialize in developing

adapters or from those companies that provide adapters to enable integration with their


P a g e | 23

proprietary applications. Some examples of third-party adapters include SAP, Lotus Notes,

and CICS.

Microsoft WCF Line of Business Adapter SDK. If you are unable to locate an adapter to

support your communication requirements, you can develop your own custom adapter. To

simplify this process Microsoft provides a consistent framework for developers to build line–

of-business adapters based on Windows Communication Foundation (WCF). The WCF LOB

adapter SDK includes a rich set of development tools to automate and simplify adapter

development in a consistent and repeatable manner.

Pre-existing Custom Adapters. Existing custom adapters that were built with the Adapter

Framework (prior to the BizTalk Server 2013 release) are still supported for backward

compatibility.

BizTalk Server 2013 also provides accelerators to help implement other popular standards, such as

RosettaNet, SWIFT, and HL7. Each accelerator includes pre-defined message definitions for the

standard, along with relevant guidance and examples.

5.3.1 Receive Adapter

A receive adapter works in conjunction with a receive port and a receive pipeline to retrieve

messages from the source location, also known as the endpoint. After receiving, the messages are

saved to the MessageBox database.

Each receive adapter has specific context information about the message or the metadata that is

associated with the protocol that it supports. This metadata can include information such as the

original file name, the time the message was received, and the sender information. The metadata is

saved along with the message data and can be accessed by the BizTalk Messaging Engine when

evaluating subscriptions for routing purposes or by the BizTalk Orchestration Engine to make

processing decisions within an orchestration instance.

5.3.2 Send Adapter

A send port adapter and the send pipeline work together via the messaging engine to send the

message from the MessageBox to a specific endpoint.

5.4 BizTalk Orchestration Engine

The BizTalk orchestration run-time engine is a highly optimized service that monitors and executes

orchestrations.

The BizTalk Orchestration Engine performs the following tasks:

Creating instances of and executing orchestrations.


P a g e | 24

Maintaining the state of a running orchestration instance so that it can be restored to

memory when required.

Performing optimizations of running orchestrations to maximize scalability, throughput, and

efficient use of resources.

Providing a reliable shutdown-and-recovery system.

The orchestration engine executes orchestrations by creating individual instances of the business

process. The run-time engine coordinates these multiple instances to ensure that a response

message gets routed to the correct orchestration instance, by using a specialized routing pattern

called correlation.

5.4.1 Dehydration and Rehydration

When many business processes run at the same time, memory and performance can be

compromised. The BizTalk Orchestration Engine solves this problem by dehydrating and rehydrating

orchestration instances. Dehydration is the process of saving the state of an active orchestration

instance to the MessageBox database and then removing that instance from memory. This can

happen when the orchestration engine determines that an instance has been idle for a period of

time. Dehydrating the instance frees up the resources that were being used by the instance.

Dehydration

The orchestration engine calculates thresholds to determine how long an orchestration will wait for

various actions to take place, and if those thresholds are exceeded, it dehydrates the instance. This

can occur under the following circumstances:

When the orchestration is waiting to receive a message and the wait is longer than a

threshold determined by the engine.

When the orchestration is waiting for a subscribed message.

When a delay in the orchestration is longer than a threshold determined by the engine.

Between the retries of an atomic transaction.

The orchestration engine saves the entire state of a running orchestration instance to persistent

storage at various points so that the instance can later be completely restored in memory. The

dehydration of orchestration instances enables the orchestration engine to have more "in-flight"

instances than the physical resources of the computer running BizTalk Server would normally allow.

Dehydration is automatically controlled by the orchestration engine; however, you can control the

dehydration threshold by changing specific BizTalk Server configuration properties.

Rehydration


P a g e | 25

Rehydration is the reverse of dehydration. It is the process of de-serializing the last running state of

an orchestration from the database or restoring the saved state of an orchestration instance from

disk back to memory. The orchestration engine is triggered to rehydrate an orchestration instance

when it either receives a message or when a time-out expires. It then loads the saved orchestration

instance into memory, restores its state, and runs it from the point where it left off.

An orchestration can be configured to run on more than one server. After an orchestration instance

has been dehydrated, it can be rehydrated on any of these servers. If one server goes down, the

engine continues to run the orchestration on a different server, continuing from its previous state.

The engine also takes advantage of this feature to implement load balancing across servers.

5.5 Hosts and Host Instances

BizTalk has logical hosts and physical host instances that represent the processes in which BizTalk

applications execute. A configured logical host is specified on ports and orchestrations to

determine, logically, where they will execute. Each host has one or more host instances which

represent actual processes on a server, and which inherit the settings of the host.

All orchestrations and send handler (ports) are hosted in an In-Process host. An in-process host can

host any of the receive handlers except for SOAP and HTTP.

The corresponding host instance for an In-Process host runs under BTSNTSVC.exe process. You

would see the corresponding service in Services, under BizTalk service BizTalk Group: <HostName>

Isolated hosts primarily host adapters that must run outside of the normal BizTalk Server runtime

process, i.e. outside of BTSNTSVC.exe process. You cannot host orchestrations or send handlers

(ports) in an isolated host. An isolated host can host only the receive handlers associated with

HTTP/S and SOAP adapters (the isolated-type adapters).

Using the BizTalk Settings Dashboard, administrators can configure the settings at the Group, Host,

and Host Instance level. These settings are mostly made up of performance and throttling related

values, but also include settings related to message behavior. As an example, there are several

different tabs for managing the various throttling and performance settings for all instances of this

logical host as shown below.


P a g e | 26

For a host instance, there are settings focused on the CLR threadpool and orchestration memory

throttling. Figure below shows the settings for a specific host instance.


P a g e | 27


P a g e | 28

6 BIZTALK APPLICATIONS

BizTalk Server 2013 provides a rich set of development tools for designing, organizing, and building

the various elements of a BizTalk application. The BizTalk project system is hosted in Visual Studio

2012 and provides developers with a fully integrated design experience to create parts of a BizTalk

application or an entire business solution. The core element of a BizTalk solution is a BizTalk

project—a collection of items (artifacts) including schemas, orchestrations, pipelines, maps, Web

message types, classes, and references. These artifacts are compiled into an assembly before

deployment for testing or to a production environment.

6.1 BizTalk Project

A simple BizTalk Server business application may consist of a single BizTalk project compiled into a

single assembly. However, a more complex business solution that integrates many disparate systems

and processes may require many different assemblies that are deployed individually to several

different BizTalk Server computers. Individual BizTalk projects can be developed separately by


P a g e | 29

different developers who are responsible for specific parts of an application. These projects can be

deployed individually or combined into a single application solution.

A BizTalk project consists of one or more artifacts, which are saved as specific file types. Each type of

artifact plays a specific role in the BizTalk solution. The BizTalk project system provides a

corresponding graphical design tool for creating and modifying each type of artifact.

6.1.1 Schemas

A schema provides a definition for the structure of the data within an XML message. While BizTalk

Server natively processes XML formatted messages, special extensions of the XSD standards enable

BizTalk Server to process EDI and flat-file messages. BizTalk Editor is the design tool that simplifies

the process of defining schemas.

6.1.2 Maps

A map is used to transform the data from one structure to another. BizTalk Mapper is the design tool

that presents a source schema and destination schema side-by-side and enables you to define

transformations between the data elements of different messages.

6.1.3 Pipelines

A pipeline performs a variety of operations to prepare incoming or outgoing messages for further

processing. Pipeline Designer enables you to implement operations such as encryption and

decryption, compression, reformatting, and validation.

6.1.4 Orchestrations

An orchestration represents the workflow for a business process. Orchestration Designer enables

you to design the logic and flow for an orchestration by dragging and configuring different graphical

shapes to the designer surface.

6.1.5 Business Rules

Although the orchestration could be used to define business process and rule, an easier way to

define and change business rules is to use the Business Rules Engine. Developers will most often use

the BRE, but more business-oriented users can create and modify sets of business rules using a tool

called the Business Rule Composer.


P a g e | 30

6.2 Visual Studio 2012 Development Tools

Microsoft Visual Studio 2012 is used for designing, organizing, and building the various elements of a

BizTalk application. The following Visual Studio tools are used by developers to create the necessary

BizTalk artifacts for BizTalk message integration and business process integration.

6.2.1 BizTalk Editor

Helps you define schemas, which are used to describe the format of data that is processed within

organizations and between trading partners.

You use BizTalk Editor to create, edit, and manage the schemas for a BizTalk application without

needing to learn all the intricacies of the XSD syntax. This tool runs within the Microsoft Visual

Studio 2013 environment and starts automatically when you either add a new schema to a BizTalk

project or open an existing schema in the project. BizTalk Editor displays a hierarchical order of

records, field elements, and field attributes to represent the structure of message instances.


P a g e | 31

6.2.2 BizTalk Mapper

BizTalk Mapper enables you to create and edit maps. You use BizTalk Mapper to define the

relationship between an input and an output schema by using links and functoids as shown below.

BizTalk Mapper supports one-to-one and one-to-many links. For example, a link can connect a single

record or field from the source schema to a single record or field in the destination schema. A link

can also connect a single record or field from the source schema to multiple records or fields in the

destination schema. BizTalk Mapper supports complex structural transformations from records and

fields in the source schema to records and fields in the destination schema. When working with large

or complex schemas, BizTalk Mapper highlights active items, allows for multiple pages of links, and

enables you to search for nodes.

6.2.3 Pipeline Designer

Used to create custom pipelines to process incoming and outgoing messages by implementing such

operations as encryption and decryption, compression, reformatting, and validation.

6.2.4 Orchestration Designer

Orchestration Designer provides a design surface that enables you to create visual representations

of your business processes. The design surface is a working canvas where you drag different shapes

from the Toolbox as shown below. The shapes correspond to the different actions that you need to


P a g e | 32

perform when processing a message. In most cases, you must configure options for each shape that

you use when you build the orchestration.

The design surface is divided into three areas: one Process Area and two Port Surfaces. The Process

Area contains shapes that describe the actual process flow of the orchestration. For example, scope

shapes helps you define transactions in a business process. A scope contains one or more blocks. It

has a body and can optionally have any number of exception-handling blocks as well as a

compensation block appended to it.

The Process Area of the design surface is flanked on both sides by Port Surfaces, which contain only

Port and Role Link shapes that interact with the send and receive shapes in the Process Area. You

can use either side (right or left) of a Port Surface to create a send or receive port. This enables you

to create well-documented orchestrations that have fewer crisscrossing connectors, making your

orchestrations easier to read.


P a g e | 33

7 BUSINESS RULES ENGINE (BRE).

BizTalk Server 2013 includes the Business Rules Engine as a stand-alone .NET-compliant class library

that includes a number of modules, support components, and tools. The primary modules include

the Business Rule Composer for constructing policies, the Rule Engine Deployment Wizard for

deploying policies created in the Business Rule Composer, and the Run-Time Business Rule Engine

that executes policies on behalf of a host application.

You can integrate business rules into your orchestrations to support a variety of scenarios:

Use rules instead of coding and recoding constantly changing business policies and logic

within your complex business processes. Incorporate a call and allow information workers to

update business rules.

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 one minute. The next time, the rule would wait five

minutes before executing; the time after that, the rule would wait 30 minutes before

executing; and so on.

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.

The BRE is most useful when a complex set of business rules must be evaluated. Deciding whether to

grant a loan, for example, might entail working through a large set of rules based on the customer’s

credit history, income, and more. Similarly, determining whether to sell life insurance to an applicant

depends on a number of things, including the applicant’s age, gender, and a myriad of health factors.

Expressing all of these rules as conditional statements using, say, an orchestration’s Decide shape

might be possible, but it’s not simple. For rule-intensive processes like these, the BRE can make a

developer’s life significantly simpler.

The BRE can also make changing rules faster and easier. To see why, think about what’s required to

change a business rule that’s implemented within an orchestration. A developer must first open the

orchestration in Visual Studio, modify the appropriate shapes (and perhaps any .NET objects they

invoke), then build and deploy the modified assembly. Doing this also requires stopping and re-

starting the BizTalk application that includes this orchestration. If instead this business rule is

implemented using the BRE, it can be modified without recompiling or restarting anything. All that’s

required is changing the desired rule, then redeploying the new set of rules. The change will take

effect immediately. And while orchestrations are typically created and maintained by developers,

business rules are readable enough that in some cases they can be modified by business analysts

without the need to involve more technical people.


P a g e | 34

7.1 Business Rules Composer

The Business Rule Composer enables you to create rules by adding predicates and facts and defining

actions. You can add facts and actions by dragging them to the Business Rule Composer design

surface. The actions update the nodes in the specified document. You can also add AND, OR, and

NOT operators to conditions to create complex comparisons.

The Business Rule Composer helps you create, test, publish, and deploy multiple versions of business

rule policies and vocabularies to make the management of these artifacts easier. The Business Rule

Composer can be used by developers, administrators, and information workers to develop and apply

rules and policies.

7.2 Business Rule Vocabularies

Business rule vocabularies are user-defined names for the facts that you use in rule conditions and

actions. Vocabulary definitions make rules easier to read, understand, and share among various

workers within a particular business domain. For example, the source location for a particular fact is

a specific field in one record in a single database and is represented as an SQL query. Instead of using

the SQL query in the rule, you can use a vocabulary definition to assign a meaningful name with the

query for the benefit of all the relevant parties in the development and deployment process for the

rule.

Consider the following example of a business rule:

If the Shopping Cart contains more than £1,000 worth of items, give the customer a 10% discount.


P a g e | 35

This rule is easy to understand. It 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. In computer terms, this rule will look like this:

If Company.Namespace.ShoppingCart.PurchaseAmount > Qualifying Amount as System.Decimal

Then

Company.Namespace.Customer.DiscountedAmount = Company.Namespace.ShoppingCart

.PurchaseAmount * .1

To provide a more user-friendly alias, you can create a business rule vocabulary to abstract difficult

concepts by defining an alias to the schema nodes, database fields, and .NET classes. Vocabularies

make the creation and maintenance of these rules much easier. Correctly defined vocabularies can

empower information workers in maintaining policies.

The Business Rule Composer contains two built-in vocabularies, Predicates and Functions, which are

used in the creation of all rules. You can extend these vocabularies if required. 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). You can define an additional vocabulary term to clarify the

meaning of the relationship represented by the built-in Greater Than function.

7.3 Business Rule Policy

A business rule policy is a logical collection of business rules. Each rule is a conditional comparison of

facts. If the comparison evaluates to True, the actions defined in the rule are executed. Business

rules are versioned together as part of a business policy. Therefore, if a rule changes, you simply

need to create a new version of the policy, test it, and deploy it. You do not need to recompile or

modify orchestrations or other business processes that use that specific business policy.

When called from an orchestration, the BRE always executes the latest version of a policy. Changes

made to a business rule policy are immediate. The next time the policy is called from an

orchestration, the latest version number of the policy that is in a deployed state is used. When you

call a policy programmatically, you need to specify the policy version.

Publishing the policy to the rule store makes it available to the BRE. By default, the BRE uses a

Microsoft SQL Server database as the rule store; however, you can also export rules to an XML-

based rule store as well. After a policy is published, it is immutable and you can change it only by

creating a new version.

Although policies are typically used in conjunction with BizTalk orchestrations, you can also call

them from any .NET assembly by using the supplied APIs.


P a g e | 36

8 BUSINESS ACTIVITY MONITORING (BAM)

The most critical factor for the success of any business is getting the right information at the right

time. The ease of information access can determine the fate of business deals and partnerships. One

of the major incentives driving growth and demand for a new generation of integration solutions is

the ability to provide both technical and non-technical users with end-to-end visibility into the

business process on a near real-time basis. This improved visibility enables organizations to make

timely and well-formed decisions to improve business agility and customer satisfaction.

Business Activity Monitoring (BAM) in BizTalk Server 2013 allows business analysts, developers, and

information workers to monitor and analyze data from business process information sources in real

time. By using BAM, users can get information about business state, trends, and critical conditions.

Additionally, the BAM application programming interface (API) enables developers to expose

visibility into data that is external to BizTalk processes, such as archival data or other non-BizTalk

processes and systems. Developers, administrators, business analysts, and end users can use the

BAM Portal to view, aggregate, search, or create alerts based on the data collected by BAM.

Microsoft Office SharePoint can display KPIs and charts based on BizTalk BAM data

A major goal for SOA is to provide total process visibility. In some cases, there are dozens or

hundreds of different services, each of which plays its own part in a larger business process. Each


P a g e | 37

one of these services is likely to have its own tracking or monitoring mechanism. By using BAM, a

developer could create a single activity that spans across all of these processes and gathers the

relevant information about each process. This kind of implementation provides a single view for

information about the process as a whole rather than using different tools to look at disparate data

stores to view information about a single service.

8.1 BAM Activities

To gather the necessary business data, you need to create one or more BAM activities. A BAM

activity represents a unit of work in a business, such as a purchase order or a loan application. BAM

activities can also contain milestones, which are a date/time measure, throughout the business

process that allow business analysts to see the overall progress of the business process and

investigate each individual step of the process. BAM activities are independent of the actual

implementation of your BizTalk solution. Think of a BAM activity as a record in an SQL table that you

keep in synchronization with the actual unit of work.

You can relate multiple BAM activities together as well. An example of relating activities is a

situation where a single purchase order contains multiple shipments. Properly configured BAM

activities can allow you to view the shipping information for each item in the purchase order. You

can use the BAM API to create BAM activities that span multiple disparate systems. For example, if

one step in a loan process is to execute a Web service or make a call to a mainframe system,

business analysts can include this data in their analysis.

8.2 BAM Views

After you have defined the information that you want BAM to collect, you need to define how the

data will be displayed or viewed. To do this you define a BAM view; the view defines the context for

the information being collected.

Because there are business processes that several different users will have an interest in it's

important to be able to provide different contexts for the same data based on the user accessing it.

A single BAM activity can have multiple views; there could be a Store Manager view, a Sales

Associate view, and a Supplier view. While that actual data displayed is the same for all three views

the way that it is displayed can change based on how the user wants to consume it.

8.3 Aggregating and Filtering Data

BAM provides interceptors that are used to gather data from incoming messages and from any point

within the business process such as an orchestration, pipeline, or message type. By aggregating data,

BAM provides an overview of business trends. You can also use BAM to link together various

messages as they travel through the system to create a unified BAM view, which shows the entire

business process and spans multiple orchestrations and data external to BizTalk Server. This visibility

is tremendously beneficial for users making critical business decisions.

You can also filter the data received from BAM. This can be useful, for example, if you want to see

loans that were processed from a certain state or by a certain loan officer or between two dates.


P a g e | 38

Filtering allows business users to focus on only the data they require to make business decisions

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 much is our total revenue this year so far?


P a g e | 39

9 BIZTALK DESIGN PATTERNS

This section discusses the common patterns of BizTalk Server programming as well as enterprise

integration patterns. You can leverage a single pattern or combine multiple patterns to design your

business process and then implement the design by using shapes in BizTalk Orchestration Designer.

Message Routing Patterns can also be implemented using the BizTalk 2013 ESB Tookit, for more

information refer to:-

http://msdn.microsoft.com/en-us/library/ee236697(v=bts.80).aspx

The section below list common design patterns that can be implemented using BizTalk

Orchestrations.

9.1 Aggregator

Aggregator is the pattern of receiving information from multiple sources and consolidating it into a

single message.

For an example of this pattern, see Aggregate.odx in Aggregator (BizTalk Server Sample).

http://msdn.microsoft.com/en-us/library/aa561747(v=bts.80).aspx

9.2 Calling Pipelines from an Orchestration

You can call send and receive pipelines from your orchestrations. This allows the reuse of pipelines

and helps maintain the decoupling of an orchestration from the pipeline stages.

For an example of this pattern, see Aggregate.odx in Aggregator (BizTalk Server Sample).


Another example is CMP.odx in Composed Message Processor (BizTalk Server Sample).


9.3 Composed Message Processor

Composed Message Processor is the pattern of processing individual items from an aggregated or

batched interchange message. For an example of this pattern, see CMP.odx in Composed Message

Processor (BizTalk Server Sample).


http://msdn.microsoft.com/en-us/library/ee236697(v=bts.80).aspx









P a g e | 40

9.4 Content-Based Router

Content-Based Router is the pattern of determining the recipient of a message based on some part

of the message content.

For an example of this pattern, see CBRSample (BizTalk Server Sample).


9.5 Dynamic Router

Dynamic Router is the pattern of determining the destination address as well as the transport

protocol based on the result of message processing. You can use a dynamic send port or a Role Link

shape to implement this pattern.

For an example of this pattern, see ReceiveSend.odx in SendMail.


Another example is SupplierProcess.odx in PartyResolution (BizTalk Server Sample)


9.6 Error Handling

BizTalk Server allows you to designate automated handling of messaging failures as an alternative to

the default behavior of placing failed messages in the Suspended queue. You can route failed

messages to a subscribing port for reporting or processing.

For an example of this pattern, see ResubmitLogic.odx in Error Handling (BizTalk Server Samples

Folder).


9.7 Exception Handling and Compensation

You can use an exception handler and a Throw Exception shape or an Expression shape for

exception handling. For example, you can place the following code in the Expression shape to throw

the exceptions

You can use a compensation block and a Compensate shape to perform the compensation on the

transactions that have been committed.

For an example of this pattern, see UpdateContact.odx in Compensation (BizTalk Server Sample).








P a g e | 41

Another example is in Custom Exceptions


9.8 Message Broker

Message Broker is the pattern of determining the destination of a message and still maintaining

control over the message flow.

For an example of this pattern, see OrderBroker.odx in File Inventory for the Business Process

Management Solution.


9.9 Message Filter

The Message Filter pattern selects messages meeting particular criteria for processing. You can

implement this pattern by adding the filter expression to an activated Receive shape.

For more information, see Using Filters with the Receive Message Shape.


9.10 Message Translator

The Message Translator pattern converts a message from one form to another form. You can

implement this pattern by using a BizTalk map with a Transform shape in an orchestration.

For an example of this pattern, see HelloOrchestration.odx in HelloWorld (BizTalk Server Sample).


9.11 Parallel Convoy

The Parallel Convoy pattern enables multiple single items to join together to achieve something that

an individual item cannot accomplish by itself. The set of related items can arrive in any order, but

BizTalk Server must receive all of them before starting the process.

For more information see:-

Working with Convoy Scenarios


Parallel Convoys









P a g e | 42

9.12 Scatter and Gather

The Scatter and Gather pattern enables messages to be sent to multiple recipients and messages to

be received back from each recipient. You can implement this pattern by using the Splitter pattern

and the Aggregator pattern. You use the Aggregator pattern to assemble the results from using the

Splitter pattern and put them under a Parallel Actions shape.

For an example of the Splitter pattern, see SDK sample named Implementing Scatter and Gather

Pattern at

http://msdn.microsoft.com/en-us/biztalk/aa937647.aspx

Alternatively you can also use the BizTalk 2013 ESB tool to implement this pattern. See the ESB

Toolkit Sample Applications.

http://msdn.microsoft.com/en-us/library/ff699831(v=bts.80).aspx

9.13 Sequential Convoy

The Sequential Convoy pattern enables multiple single items to join together to achieve something

that an individual item cannot accomplish by itself. A sequential convoy is a set of related items that

have a predefined order. Although the items do not have to be exactly the same, BizTalk Server must

receive the items in a sequential order.

For more information see:-

Working with Convoy Scenarios


Sequential Convoys


9.14 Splitter

The Splitter pattern takes a single message and splits it into multiple messages.

9.15 Suspend with Retry

The Suspend with Retry pattern enables the orchestration to suspend a message when there is an

error. The suspension occurs within a loop so that the orchestration suspends, asks for intervention,

and then retries the operation a fixed number of times.

http://msdn.microsoft.com/en-us/biztalk/aa937647.aspx

http://msdn.microsoft.com/en-us/library/ff699831(v=bts.80).aspx




P a g e | 43

10 MANAGEMENT AND OPERATIONS

After a BizTalk application has been developed and tested, it is typically handed off to the site

administrator who deploys and manages the application in the production environment. BizTalk

Server 2013 comes with tools to help you manage and monitor your BizTalk Server environment.

These tools provide powerful query and reporting capabilities to assist in identifying the overall

health of a BizTalk Server system.

The BizTalk Server 2013 Administration console helps you create, configure, deploy, and manage

applications as well as create and configure 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 system. You can use the Group Hub to view live BizTalk Server instances,

which can be in an active, dehydrated, or suspended state. You can also use a command-line option,

BTSTask, to perform the same tasks as the BizTalk Server 2013 Administration console.

10.1 Deploying a BizTalk Application

A complete BizTalk Server 2013 solution typically contains various components such as:

BizTalk artifacts such as orchestrations, schemas, maps, and pipelines.

Messaging components such as receive ports, receive locations, and send ports.

Supporting .NET assemblies such as helper applications and test harnesses.


P a g e | 44

Other related items such as security certificates, business rules policies, BAM configuration

files, bindings, and scripts required by the application.

A BizTalk application acts as a logical grouping of business solution components, simplifying their

management and deployment. You can create one or more BizTalk applications to:

Manage the artifacts and supporting configurations for separate business processes.

Isolate the applications for security and manageability.

Scale specific parts of the application to multiple BizTalk Server computers.

10.1.1 MSI Packages.

Deploying a BizTalk application involves deploying BizTalk assemblies into the BizTalk Configuration

database and installing the assemblies into the global assembly cache (GAC) on each BizTalk Server

computer. Developers usually deploy these assemblies from their own development environments

to the development server, and then the site administrators deploy them from the development to

test environments and further to production environments.

BizTalk Server 2013 simplifies the process of deploying BizTalk assemblies and moving deployed

applications from one physical environment to another by enabling you to generate standard MSI

packages by using the Microsoft Windows Installer technology. Using MSI packages eases the

process of deployment upgrade and removal.

When you export a BizTalk application, it generates an MSI file that contains the application and

some or all of its artifacts. You can specify the artifacts that should be exported. You can later import

this MSI file into another BizTalk group to add the artifacts to an existing application in the new

group, update the artifacts in an existing application, or create a new application in the group that

contains the artifacts being imported.

A BizTalk application MSI package can contain:

The BizTalk assemblies that make up the application, including schemas, maps, pipelines,

and orchestrations.

The configuration information or bindings required to start the application on a computer.

Any non-BizTalk items, such as .NET assemblies.

Business rule policies to be processed by the BRE.

Any Web resource information required to enable Web-based applications.

Using an MSI package to install a BizTalk application is beneficial for developers because they can

control its contents and easily hand it off to administrators.


P a g e | 45

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 for a BizTalk application must also be added to a physical location

on each server as well as to each server’s GAC.

You must execute the MSI on each server to facilitate this installation. After an MSI package is

installed, it creates an entry in the Add or Remove Programs list on the BizTalk Server computer. This

allows administrators to manage BizTalk applications in the same way as other applications that

have been installed on the computer.

10.2 Tracking and Debugging BizTalk Processes

The BizTalk Group Hub page is an operations management tool used for monitoring the running

processes in a BizTalk group. As part of the BizTalk Server Administration console the Group Hub

page is the first place that an administrator or business user should look to track or debug a running

BizTalk process. The Group Hub page provides a view into the activity within the MessageBox

database.

As shown above, the Group Hub is divided into three sections that provide an overview of the health

of your BizTalk Server system:

Configuration Overview. This section provides information about the overall health of the

BizTalk group by displaying the number and state of Applications, Host Instances, and

Adapter Handlers within the BizTalk group. This section shows a red light or green light view

of the health of these different items.


P a g e | 46

Work in Progress and Suspended Items. This section displays the summary links for viewing

dehydrated orchestrations, retrying and idle ports, and running, ready, scheduled, and

suspended service instances.

Grouped Suspended Service Instances. This section, the bottom section of the Hub page,

displays summary links for viewing suspended service instances grouped in various ways.

This grouping assists in managing suspended instances in a batch fashion. For instance, if

several messages are caused by the same error, they are grouped together here by the Error

Code. After the error has been resolved, all instances can be resumed (or terminated) at the

same time.

With many of out-of-the-box queries to help you quickly find the service instance you're looking for

and the ability to create your own custom queries, the Group Hub page is a tool that both

Administrators and Developers can't live without. Functionality of the Group Hub page includes:

Queries. The Group Hub page provides you with several default queries that allow you to

quickly view running, dehydrated, and suspended service instances. You can also create your

own queries to further refine your tracking.

Service instance visibility. Often times your queries will return suspended service instances,

a service could be suspended for any number of reasons. You can use the Group Hub page to

view errors, messages (including the message bodies and contexts), and running

orchestrations.

Orchestration Debugger. The Orchestration Debugger provides the same graphical view of

the orchestration as the Visual Studio design experience but includes information on the

execution of the orchestration shapes. This allows you to see the process flow of the

individual instance such as which branch in a decision shape the instance processed.

Additionally, you can set breakpoints on orchestration shapes. After a breakpoint is set each

instance of that orchestration will be caught in the breakpoint. You can attach to

orchestration instances in breakpoints to see the specific variables and message data

associated with the orchestration instance.

10.3 Monitoring BizTalk Applications Using SCOM

The Microsoft BizTalk Server 2013 Management Pack for System Center Operations Manager

(SCOM) provides options for proactive and reactive monitoring of BizTalk Server computers. This

management pack is provided as a download for users of BizTalk Server.

The BizTalk Server management pack provides for comprehensive monitoring of BizTalk events and

performance counters to provide a centralized management and monitoring experience for a BizTalk

Server environment. SCOM enables you to monitor BizTalk Server events, collect BizTalk Server-

specific performance counters in one central location, and raise alerts that require operator

intervention.


P a g e | 47

The BizTalk Server management pack includes the following features:

Event and performance-based alerts for all major BizTalk Server components. All alerting

rules contain product knowledge.

Separate infrastructure and application views for events.

Streamlined alerts. Redundant alerts are minimized and alert suppression is typically based

on end points, especially for suspended messages in BizTalk Server.

Cluster awareness provides a single view of the system.

Rich views specific to the BizTalk Server 2013 management pack.

State Monitoring view. The pack provides Green/Yellow/Red states for important health

aspects of BizTalk Server and indicates overall health.

BizTalk Server SCOM tasks to execute common operational tasks.

Additional SCOM tasks to transition directly from a SCOM alert to BizTalk Server

Administration console.

Comprehensive monitoring for the health of BizTalk Server MessageBoxes and hosts.


P a g e | 48

11 BIZTALK INFRASTRUCTURE ARCHITECTURE

11.1 Single Server – No High Availability

The is usually used for development environments


P a g e | 49

11.2 Multi Server – High Availability

This BizTalk Server deployment provides high availability for the both SQL Server and BizTalk Server

and is made up of four computers. Two computers form the BizTalk group and run all the BizTalk

Hosts (receive, process, and send). If one BizTalk computer fails or encounters errors, the other

computer maintains service availability.

The other two computers form an active/passive SQL Server cluster and host all the BizTalk

databases. The Enterprise Single Sign-On master secret server service is clustered on the SQL Server

Cluster.


P a g e | 50

11.3 Multi Server – High Availability and High Throughput

For large-scale deployments, dedicated separate BizTalk Server computers are used for the

receiving, processing, and sending functions. The three most traffic intensive BizTalk databases are

separated and deployed on their own SQL Server clusters.


P a g e | 51

12 REFERENCES

Main BizTalk Server Site.

http://www.microsoft.com/en-us/biztalk/default.aspx

BizTalk: Enterprise Integration Patterns.

http://social.technet.microsoft.com/wiki/contents/articles/11862.biztalk-enterprise-integration-

patterns.aspx#BPM_Scenarios

What's New in BizTalk Server 2013?

http://msdn.microsoft.com/en-us/library/jj248703(v=bts.80).aspx

Planning and Architecture


BizTalk Development


BizTalk Deployment


BizTalk Operations


BizTalk Server Team Blog

http://blogs.msdn.com/b/biztalk_server_team_blog/

BizTalk Performance Optimization Guide.

http://msdn.microsoft.com/en-us/library/ee377064.aspx

http://www.microsoft.com/en-us/biztalk/default.aspx

http://social.technet.microsoft.com/wiki/contents/articles/11862.biztalk-enterprise-integration-patterns.aspx#BPM_Scenarios

http://social.technet.microsoft.com/wiki/contents/articles/11862.biztalk-enterprise-integration-patterns.aspx#BPM_Scenarios

http://msdn.microsoft.com/en-us/library/jj248703(v=bts.80).aspx





http://blogs.msdn.com/b/biztalk_server_team_blog/

http://msdn.microsoft.com/en-us/library/ee377064.aspx

Documents

Designing for Operations - · PDF fileothers might use message queuing or something else. ... Dynamic Update No ... Siebel and JDEdwards