United States Change | All Microsoft Sites
Microsoft Home | Servers and Tools | Application Platform
At the core of BizTalk Server 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.
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 (as shown in Figure 1) 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”).
Figure 1. The BizTalk Server publish/subscribe model
Figure 1 shows how BizTalk Server implements the publish/subscribe model.
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.
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.
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.
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.
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.
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.
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.
The send port then uses an adapter to connect and transmit the data to the external system or application.
The BizTalk Server messaging subsystem enables communication with a wide range of systems and applications. It supports the conversion to and from different data formats to handle proprietary protocols and standards-based services.
BizTalk Server relies on the use of structured documents for all internal messaging and orchestration operations. Regardless of the format of the incoming message (for example, XML, flat-file, or EDI) the BizTalk messaging and orchestration engines can only process XML formatted messages internally. To create a basic message processing application, a developer must:
Create the schema definitions for all types of messages to be processed by BizTalk Server.
Create one or more maps to transform the data from one schema structure to another.
Configure the receive ports and receive locations to enable the receiving of messages
Configure the send ports for the sending of data to external systems.
Create a custom pipeline for any custom processing that the message data requires.
The schemas processed by BizTalk Server can come from a variety of different sources. A schema definition might be predefined by some external application or it might be sent by a trading partner. To integrate with an existing EDI application, BizTalk Server provides over 8,000 different schemas to support existing EDIFACT and X12 message standards. However, in many cases you will have to create the schemas yourself for XML or flat-file document structures by using BizTalk Editor.
Supported Schema Types
BizTalk Server natively supports the following schema types:
XML. The BizTalk messaging and orchestration engines require that all messages be in XML format. An XML schema defines the hierarchical structure of an XML message. BizTalk Server identifies and validates all messages against an associated schema.
Flat-file. A flat-file schema defines the structure of messages that are received in a flat-file format. A flat file can be either delimited or positional. The XML Schema Definition language (XSD) does not natively support the flat-file structure; therefore, BizTalk Server uses the annotation capabilities of XSD to store this extra information within the XSD schema itself. BizTalk Server defines a rich set of specific annotation tags that can be used to store all of the required additional information.
EDI. BizTalk Server enables the creation and use of schemas to represent standard EDI document formats such in EDIFACT and X12. An EDI message is a variation of a text message and does not use typical delimiters such as carriage returns and linefeeds. As with flat-file schemas, BizTalk Server uses the annotation capabilities of XSD to store the extra information related to the format of the EDI messages.
Figure 1: BizTalk Schema Editor
You use a BizTalk map to convert an input message that conforms to one schema into an output message that conforms to a different schema. These conversions can be either simple or complex, involving calculations and consolidation of information.
A map defines the relationship between an input and output schema by using links and functoids. A link defines a direct data copy of a record or field. A link specifies the basic function of copying data from an element or attribute in an input instance message to an element or attribute in an output instance message. You create links between records and fields in the source and destination schemas at design time. As a result, during run time, links direct the creation of an output instance message conforming to the destination schema from an input instance message conforming to the source schema. Links may either directly connect to items in the other schema or form connections through functoids.
Figure 2: BizTalk Mapper
BizTalk Server 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.
WCF Adapters
BizTalk Server includes several adapters that enable communication to and from BizTalk Server and Web services-based applications via Windows Communication Foundation (WCF). The WCF adapters support HTTP/HTTPS, SOAP, MTOM, TCP, MSMQ, and Named Pipes transports.
The BizTalk Line-of-Business (LOB) Adapter Pack
Microsoft also provides a broad array of technology and application adapters that enable BizTalk Server to connect to numerous line-of-business (LOB) applications such as SAP, PeopleSoft, JD Edwards, Oracle, Siebel, Microsoft Dynamics, and many others. Adapters are released or updated regularly. You can see a list of the LOB adapters currently available on the BizTalk Adapters page.
Additional Sources for Adapters
In addition to the adapters included in BizTalk Server, 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 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. You can download the SDK from http://go.microsoft.com/fwlink/?LinkID=96184.
Pre-existing Custom Adapters. Existing custom adapters that were built with the Adapter Framework (prior to the BizTalk Server release) are still supported for backward compatibility.
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.
Figure 3: BizTalk Pipeline Designer
For more information on BizTalk Messaging please refer to the BizTalk Product Documentation on MSDN.
Messaging
