BizTalk Server 2006 Artefactos – Formação

Sandro PereiraDevScopeSandro PereiraDevScope

Agenda

BizTalk Server Services and Tools BizTalk Schemas BizTalk Maps BizTalk Orchestration BizTalk Adapters Tools for DevelopersDevelopers Tools

BizTalk Schemas

BizTalk Schema

Each unique document type requires a separate schema that defines the records and fields contained in that document. The XML schema defines: The elements, attributes, and data types that appear in a document. The ordering of tags in the document. Fields that are mandatory or that might occur multiple times in a single

document.

BizTalk Server 2006 uses the XML Schema definition language (XSD) to define the structure of all messages that it processes, and refers to the definitions of message structure as schemas.

BizTalk Schema Types

XML Schema An XML schema defines

the structure of XML messages. This type of schema uses XML Schema definition language (XSD) to define the structure of an XML message.

Flat File Schema A flat file schema defines the structure of messages that use a flat file

format. Flat files can be either delimited or positional. Property Schema A property schema is a special type of schema that defines specific field

elements that you want to promote as a property field.

Using Multiple Schemas

To use a type defined in one schema (Schema1) within another schema (Schema2): 1. Provide a reference to Schema1 within Schema2 by using the

Importsproperty of the Schema node in Schema2. 2. Click the ellipsis button (...) in the Imports property field to open the

Imports dialog box. 3. In the Import New Schema as drop-down list, choose XSD Import,

XSD Include, or XSD Redefine. 4. Click Add to open the BizTalk Type Picker dialog box, and then

browse within your BizTalk project to select Schema1.

Reusing and Redefining Schemas

Creating a Schema Using BizTalk Editor

Child Record. Represents a collection of information. A record node can include simple types of information, such as strings and numbers, represented as child field nodes. A record node can also include complex types of information represented as a child record node or as a group node (sequence group node or choice group node).

Field Attribute. Represents items of information that are simple in nature, such as strings and numbers.

Field Element. Represents items of information that are simple in nature, such as strings and numbers. Must use a field element if the field has children or is repeated.

The following menu choices are available when inserting nodes into a schema tree: Sequence Group.

Contains other nodes that must appear in an instance message in the same order in which they appear within the Sequence Group node.

Promoting a Schema Property

Promotion is a mechanism that you must use when you want to reference a specific value within a message instance and make it available to various BizTalk Server components (such as orchestration) or for content-based routing purposes.

The promoted property will also be visible to IntelliSense® in the Expression Editorwhen code is required.

Promoting a Schema Property

Property fields are used in filter expressions and employ property schemas to specify the fields that are to be promoted. You can use the Quick Promotion feature to streamline the process of promoting a property field and to automatically create a property schema. Message properties are referred to by the name of the message, followed by the

namespace (the schema) and property name in parentheses: MyMessage(InvoicePropertySchema.InvoiceID)

Distinguished fields are used in a message when you need to make decisions or to manipulate data within your orchestration. You can designate a field as a distinguished field by decorating it with the Distinguished Field attribute. Distinguished fields are referred to by the path to the field in the message, using

dots to separate the message name, the names of any records that enclose the field, and the name of the field itself: MyMessage.MyRecord.MySubrecord.MyDistinguishedField

Creating a Flat File Schema BizTalk Editor is designed to

make it easy to create schemas for positional flat files, delimited flat files, and combined positional and delimited flat files.

Positional Flat Files. A positional flat file is made up of fields that are of the same fixed length and records that have a common end-of-record terminator. The structure of an incoming file must be represented in the records and fields of the schema so that the positional nature of the incoming file is preserved. Therefore, before defining the message structure of a schema, obtain a layout of the necessary records and fields.

Delimited Files. A delimited flat file contains one or more records separated by a specified delimiter. BizTalk Editor does not read delimiters as part of the data. However, if the delimiter character does appear as data, the data can be formatted (placed within quotation marks, for example) so that the data and the delimiter are distinguishable.

Testing a Schema

Validating the schema. After you have finished creating a schema, or at various times during its creation, you can validate it to find out whether it contains any internal inconsistencies or other issues that might prevent it from being used effectively for processing instance messages.

Generating a sample instance. After you have validated a schema, you can use it to generate a sample instance message. The sample instance message that is generated contains the element and attribute structure specified by the schema and generates fake data where required.

Validating an instance message. You can use BizTalk Editor to find out whether any instance message conforms to that schema.

Best Practices

BizTalk Schemas

BizTalk Maps

What Is a BizTalk Map?

A map is the XML file that defines the correspondence between the records and fields in one schema and the records and fields in another schema. You create a map when you want to transform or translate data that you receive or send from one schema to another.

BizTalk Map Process Data transformation is the process of creating a correspondence between the

records and fields in a source schema and the often different records and fields in a destination schema. Data transformation can also be used to perform operations such as:

Averaging data from a looping record and sending the output to a single field in the destination schema.

Converting character data to its ASCII format. Adding data to or subtracting data from one or more records and sending the

result to a single field in the destination schema.

Data translation is the process of changing the format of an instance message. If your internal processes utilize only XML data, but your trading partner needs to receive instance messages in a flat file format, you can perform the necessary translation before you send such messages to your trading partner. Data translation can be especially helpful in solving enterprise application

integration problems by rendering a given type of message into alternative formats required by existing systems.

Types of BizTalk Maps

Basic Mapping This type of mapping involves copying a value from an element or

attribute that occurs once in an input instance message to an element or attribute that occurs once in an output instance message.

Complex Mapping Complex mapping involves records or fields that can occur multiple times

for a single instance of the Record node or Field Element node in the schema tree. This type of variable count mapping is called looping.

Creating a Map Using BizTalk Mapper

BizTalk Mapper consists of the following views within the Visual Studio .NET shell: Destination schema

tree view. This view displays the schema that describes the transformed instance message to be processed by BizTalk Server.

Source schema tree view. This view displays the schema that describes the incoming instance message. The links that define the mapping originate from the source schema tree view, passing through the map zone view and ultimately to the destination schema tree view.

Map grid view. This view is located between the source and destination schemas, and contains the links and functoids that control how data in a source instance message is transformed to the destination schema. You work actively in this view to construct your map.

Working with Functoids

Functoids perform calculations by using predefined formulas to process specific field values. These calculations are executed based on the designated order of the records and fields.

By linking a functoid to nodes in both the source schema and the destination schema, data can be concatenated; values added together, date and time information can be modified, and so forth.

If you want to implement functionality that is not available in the functoids that are included with BizTalk Mapper, you can create custom functionality by using the Scripting functoid, which allows you to access custom script or code during run time to perform functions not otherwise available. For example, you can call a COM object or Microsoft .NET object at run time by using the Scripting functoid and writing your own custom script.

BizTalk Server 2004 supports the following languages for the Scripting functoid: C, Jscript, Microsoft Visual Basic® .NET, Extensible Stylesheet Transformation

(XSLT), XSLT Call Templates

Using Basic Functoids

Using Advanced Functoids

Adding Functoids to a Map

Managing Map Zone Layers

Best Practices

BizTalk Maps

BizTalk Orchestrations

What Is BizTalk Orchestration?

Orchestration Designer You can use BizTalk orchestration to create detailed representations of

business processes that can be implemented programmatically within an integrated design environment called Orchestration Designer. This design environment provides a versatile drawing surface and a comprehensive set of implementation tools..

Working in BizTalk Orchestration Designer

Physical Ports vs. Logical Ports

Physical ports are used to receive and send messages between BizTalk Server and the outside world. Physical ports are configured and managed by using BizTalk Explorer.

Logical ports are used within BizTalk Server to pass messages to and from a BizTalk orchestration. Logical ports are configured by using Orchestration Designer and appear on the Port Surface areas.

Using Message and Data-Handling Shapes

Using Port and Role Link Shapes

Using Orchestration Flow Shapes

Using Orchestration Flow Shapes

Using Orchestration Nesting Shapes

Using Transaction and Exception Handling Shapes

Creating Orchestration Variables and Types

Creating Expressions

Correlating Messages with Orchestration Instances

BizTalk Messaging

How BizTalk Messaging Works

The BizTalk Messaging service performs the following tasks: Receives inbound documents Parses inbound documents to determine their specific format Extracts key identifiers and identifies applicable routing rules Delivers documents to their respective destinations Tracks documents

What Is the Publish and Subscribe Messaging Model?

BizTalk Server uses a publish and subscribe (or pub/sub) messaging infrastructure that is highly scalable at both database and processing levels.

This publish and subscribe routing mechanism can manage large volumes of messages (including large messages) and interact with a wide variety of backend systems.

Subscriptions are criteria that describe which message types each business process will receive. Business processes hold subscriptions to specified types of messages; each subscription allows the business process holding it to initiate or continue the processing of one type of message.

What Is a Port? Ports specify how your

orchestration will send messages to and receive messages from other business processes. Each port has a type, a direction, and a binding, which together determine the direction of communication, the pattern of communication, the location the message is sent to or received from, and how the communication takes place.

Depending on these factors, a port may be associated with: A URI (a physical location). A transport (either file, HTTP, or BizTalk Message Queuing). A send pipeline, to prepare a message for sending (for example, by assembling,

encrypting, compressing, or performing A receive pipeline, to prepare a received message for processing (for example, by disassembling, decrypting, or decompressing it).

What Is a Web Port?

Web ports are specially configured ports that are used to access Web services. A Web port can contain multiple Web operations that represent a mix of oneway

(request-only) and two-way (request-response) Web methods. Each Web operation in a Web port represents one method of a Web service.

What Is a Send Port Group?

A send port group is a named collection of send ports that you can use to send the same message to multiple destinations in a single configuration. This is useful when you want to send a message to multiple destinations.

What Is Message Routing?

A typical BizTalk Server business process involves receiving, processing, and sending messages. At times, you may receive types of messages (such as partner-to-partner correspondence) that do not require intensive processing in an orchestration, and could therefore benefit from a simpler solution.

Content-based routing eliminates the need for message subscriptions for messages that are deterministically bound to specific ports, and provides additional flexibility for users who want to route messages based on context properties (or simply based on receive port configuration properties).

To enable content-based routing, you must perform the following steps: 1. From the source schema for

the incoming message, promote the field nodes that will contain the filters.

2. Create and configure both a receive port and a receive location for incoming messages.

3. Create a send port, and configure a filter on the send port to create a subscription for messages that meet the conditions of the filter expression.

4. Enlist and start the send port.

Creating a Receive Location

A receive location is the combination of a specific address at which inbound messages arrive and a specific address of the messaging pipeline that processes the messages received at the first specific address. Receive locations are created in BizTalk Explorer as part of the process of creating a receive port.

Receive locations have both adapter-specific properties and common properties. Only the common properties can be accessed by an administrator using the BizTalk Server Administration console.

Deploying and Testing a BizTalk Solution

Assembly Deployment Steps

Binding the Physical Ports

Specify Later You can bind your port either to a receive location or to a send port. If you do not have all of the

information you need to specify a physical location, you can choose the Specify Later port binding option in Orchestration Designer, and then you need only to specify the port type that describes the port.

The information about the actual location will be specified separately, after the application has been deployed, either by an administrator working in BizTalk Explorer or programmatically, perhaps by using a script.

Dynamic Binding If you will not know the location of a communication until run time, you can use dynamic binding.

For example, you might specify the location based on a property of an incoming message.

A port binding specifies the entry points into the BizTalk-based application, and is used to associate the application with physical ports. The port binding contains configuration information that specifies where and how a message is to be sent or received.

Web Service References If your project contains a reference to a

Web service, Orchestration Designer will detect the reference and make available a corresponding Web port type.

You simply add a port to your orchestration and assign it an existing Web port type, and BizTalk Server will provide a complete Web port.

Completing Post-Deployment Tasks

Completing Post-Deployment Tasks

Create a Receive Location A receive location is the combination of a specific address at which inbound messages arrive

and the messaging pipeline that processes the message received at that specific address. Receive locations have both adapter-specific properties and common properties. Only the common properties (enable, receive handler, and processing schedules) can be accessed by using BizTalk Server Administration.

Create Physical Send Port Similar to a receive location, a send port is a grouping of endpoints that are used for

transmitting messages. A send port consists of a primary URL and a backup URL, and optionally refers to one send pipeline and an encryption certificate.

Bind the Ports You can use BizTalk Explorer to bind an orchestration to a BizTalk Server port,such as a

receive port or send location, on a per-message per-port level. For example, a one-way inbound port matches a one-way receive port; a requestresponse inbound port matches a request-response receive port. An orchestration is fully bound only when all of its ports are bound. Optionally, you can specify a map to be used for mapping the message types on each port.

Enlist the Orchestration After orchestrations are bound in BizTalk Explorer, you must use BizTalk Server

Administration to enlist the orchestrations into a host.

Deploying Assemblies: Best Practices

Tools for Developers

Orchestration Designer simplifies the process of creating orchestrations models of business processes that are compiled into executable code.

BizTalk Editor helps you define schemas, which are used to describe the format of data that is processed within organizations and between trading partners.

BizTalk Mapper presents source schemas and destination schemas side by side, making it possible to define transformations between data fields in messages.

Pipeline Designer prepares incoming and outgoing messages for further processing by implementing such operations as encryption and decryption,compression, reformatting, and validation.

The BizTalk project system is shipped with a Visual Studio template called the BizTalk Server Project template. When you use the template, the following BizTalk tools become available to you in Visual Studio:

Consuming and Publishing Web Services

BizTalk Web Integration Scenarios

Consuming a Web Service from an Orchestration

Creating a Web Port

Publishing an Orchestration as a Web Service

Publishing a Schema as a Web Service

Business Rules

What Are Business Rules?

Business Rules Terminology

Business Rules Example

Integrating Business Rules into an Orchestration

Business Rules

Tracking BizTalk Message Activity

What Is Health and Activity Tracking?

To help you monitor, track, and debug your business processes, Health and Activity Tracking (HAT) offers the following capabilities: Displays the processing steps taken by messages Can retrieve messages either by data or by system information Allows real-time monitoring and tracking Can display both archived and real-time data Limits data access to only those people with appropriate permissions Allows you to modify which data is tracked without affecting the rest of the BizTalk

Server environment - no redeployment is necessary Allows you to do real-time debugging of your orchestrations

Event Tracking HAT tracks data based on events—when a service begins or ends, for example, or

when a message is sent or received. Data Tracking

You can track both the contents of a message and the promoted properties of a message. These actions are called, respectively, message body tracking and message property tracking.

Unlock your business potencial