A very helpfull, hands on approach of learning, well, anything is to do it yourself. Microsoft Technet Virtual Labs lets you discover BizTalk in a virtual environments for testing Microsoft's newest products and technologies. Guided, hands-on labs that you can complete in 90 minutes or less. There is no complex setup or installation
required to use TechNet Virtual Labs, you can start right away.

 

 

Short descriptions of some of the labs:

BizTalk projects can contain four types of artifacts:

- Schemas

- Maps

- Pipelines

- Orchestrations

 

The schema represents the format of messages that BizTalk processes. These messages are received from different systems.

.btm files are datamapping files created in BizTalk

.odx files are orchestrations

 

The business activity monitoring (BAM) framework in Microsoft BizTalk provides business analysts with a direct view as those transactions occur.

A business activity specifies the data from the business process that is captured by BAM. 

 

BizTalk messaging can be used for basic message transformation and routing.

Processing that requires decisions or multiple actions generally requires the use of orchestrations.

Orchestration ports (logical ports) provide the connection between an orchestrations send and receive port shapes and the BizTalk messagebox database.

These send ports will be connected to send and receive shapes in the orchestration.

 

Each type of message processed by a BizTalk server application requires an xml schema that defines the structure of the message. You can define an XML schema by manually defining each node , or by importing or including other schemas. In a schema, the root node should always be renamed with a meaningful name that represents the type document described by the schema. You can use the validate schema command to determine whether a schema contains any internal inconsistencies, or has other issues that might prevent it from being used for processing instance messages.

 

You can use the BizTalk Server Administration console to manage the BizTalk configuration database. BizTalk server uses receive ports and receive locations to process inbound messages. Subscriptions can be created based on multiple message properties.

 

All BizTalk Server assemblies must be must be signed with a strong name before being deployed. Applications provide a means to group ports, business rule policies and BizTalk assemblies whit their contained artifacts, and non-BizTalk for easy administration. Each BizTalk project can be configured to deploy a specific application. Building a BizTalk 2010 project compiles a .NET assembly.

Port and orchestration configuration can be managed by using binding files. Binding files contain information about the relationship between orchestrations and logical ports.

Bindings files also include all the physical port settings, such as pipelines, adapter configuration, maps and filters.

BizTalk MSI packages can contain all of the BizTalk and non BizTalk assemblies, business rule policies, associated web services and configuration info for an application.

Application artifacts (ports, assemblies, policies etc.) can be moved between applications. All dependent artifacts will be moved together.  

 

Application artifacts (ports, assemblies, policies etcetera) can be moved between applications. All dependent artifacts will be moved together.

BTSTTask.exe is a command line utility that can be used to create, delete and manage applications.  All assemblies used by BizTalk applications must be in the Global Assembly Catch (GAC) of the computers running BizTalk Server. Additionally, all BizTalk assemblies must be registered in the BizTalk configuration database.

 

Pipelines allow you to customize the processing of messages within send or receive ports. Communicating with trading partners often requires that messsages be decrypted. In order to process encrypted messages, a certificate must be installed on the computer running Biztalk server that will process the message. An interchange, also known as a message batch, is a single message that contains multiple nested messages. A pipeline can be used to split an interchange into smaller messages.

Disassembler components in custom flat files pipelines can be configured to split interchanges by defining seperate header and bodt schemas. The header schema represents the introductory portion of a batch. The header typically contains information common to all messages in the batch. The pipeline used to process inbound messages is configured on the receive location. A succesfully processed interchange message will result in multiple individual messages. By default, any invalid interchange message will be sudpended.