(MCTS): Microsoft BizTalk Server 2010 (70-595) Certification Guide

By Johan Hedberg , Kent Weare , Morten la Cour
  • Instant online access to over 7,500+ books and videos
  • Constantly updated with 100+ new titles each month
  • Breadth and depth in over 1,000+ technologies
  1. Configuring a Messaging Architecture

About this book

Microsoft BizTalk Server 2010 is an Integration and connectivity server solution that enables organizations to easily connect disparate systems. Developing Business Process and Integration Solutions by Using Microsoft BizTalk Server 2010 (70-595) is the certification exam for professionals who need to integrate multiple disparate systems, applications, and data as well as automate business processes by using BizTalk Server.

(MCTS): Microsoft BizTalk Server 2010 (70-595) Certification Guide will show you how to prepare for and pass the Microsoft BizTalk Server 2010 (70-595) exam and become a Microsoft Certified Technology Specialist (MCTS) in Microsoft BizTalk Server 2010.

Packed with practical examples and Q&As, (MCTS): Microsoft BizTalk Server 2010 (70-595) Certification Guide covers the keys skills in the exam and starts by showing you how to configure a Messaging Architecture. The book then dives into BizTalk Artifacts such as creating Schemas and Pipelines, creating Maps and creating Orchestrations. It then moves on to topics such as debugging and exception handling, deploying, tracking and administrating a BizTalk Server 2010 solution, integrating Web Services and Windows Communication Foundation (WCF) Services and implementing Extended Capabilities. Additional practical resources are also included that will enable you to approach the Microsoft BizTalk Server 2010 (70-595) exam with ease, including certification test taking tips and tricks and sample certification test questions.

Publication date:
June 2012
Publisher
Packt
Pages
476
ISBN
9781849684927

 

Chapter 1. Configuring a Messaging Architecture

This chapter covers the Configuring a Messaging Architecture part of the exam. It will introduce some of the basic concepts of the messaging architecture in BizTalk, and also give the reader an insight into configuring some of the core Adapters in BizTalk. Other areas in this chapter will be: the publish/subscribe engine, Port Authentication, and some discussions about implementing messaging patterns.

The following topics will be covered:

  • Publish/subscribe mechanism

  • BizTalk platform settings

  • Ports

  • Core Adapters

  • Messaging patterns

  • Test your knowledge

Publish/subscribe

At its core, BizTalk is a publish/subscribe engine, nothing more nothing less. Whenever a message is received, BizTalk will look through all subscriptions and pass on a copy of the message to all the subscribers, if any. There are three kinds of artifacts inside BizTalk that can subscribe to messages:

  • Send Ports

  • Orchestrations

  • Request-response Receive Ports (these will also subscribe for the response it awaits, but this is out of the scope for this chapter).

If messages, for some reason, cannot be sent to one or more of the subscribers, BizTalk will store the message for resuming, or later analysis as to why the message could not be delivered. When all subscribers have received their message, BizTalk will no longer need to hold on to the message, and the message will be removed from BizTalk. A new subscriber will not be able to subscribe to messages that have already been processed and delivered inside BizTalk.

The following model shows how the BizTalk publish/subscribe mechanism works:

Receiving the message

First BizTalk will receive a message through the Receive Port. A message is received in a Receive Port through one of the Receive Locations associated with the port.

Adapter

The Adapter, responsible for communicating with the various Applications/protocols needed, picks up messages or a batch of messages, writes metadata to the Context of the message, and sends the message to the Pipeline.

Examples of Adapters are:

  • File

  • FTP

  • SQL

  • HTTP

Pipeline

The main purpose of the Pipeline on the receive side is to recognize the Message Type and disassemble the native format of the message to XML. Out of the box, a Receive Location can choose between either a PassThruReceive or XMLReceive Pipeline, where only XMLReceive will recognize the Message Type, whereas the PassThruReceive will slip the message onwards to the MessageBox as an anonymous message.

Some examples of native formats are:

  • XML

  • FlatFiles (comma separated values, positional, and so on)

  • EDI (X12, EDIFACT, and so on)

  • Excel *

  • PDF *

    Note

    * Not included in BizTalk, needs to be custom written or purchased from third party vendor.

The receive Pipeline will do parts or all of the following:

  • Decrypt the message if encrypted

  • Convert the native format into XML

  • De-batch the message if batched

  • Promote properties (write metadata to the Context of the message)

  • Validate the message

  • Resolve the sender of the message if signed (see more about this in Chapter 2,Developing BizTalk Artifacts—Create Schemas and Pipelines)

Maps

Now the message is evaluated with the Maps applied on the Receive Port (if any), and if the message matches the source Message Type on a Map, the Map will be applied.

MessageBox

The MessageBox is an SQL Server database, where all messages received by BizTalk are stored.

The three main purposes of the MessageBox are:

  • Stores all messages and Context received

  • Stores all subscriptions

  • Stores all Host Queues

Whenever a message is received by BizTalk, the receiving message agent will store the message in the MessageBox. During the publishing of the message, the agent will check all the subscriptions inside the MessageBox with the Context of the message and all matching subscribers will get a reference to the actual message in their respective Host Queues. When all subscribers have successfully processed their message, the message is no longer required in the MessageBox, and will be removed or moved to the Tracking database. The MessageBox also consists of all the subscriptions inside the BizTalk Group. Subscriptions are primarily made by Send Ports and Orchestrations and will be discussed in the following section.

Subscriptions

A subscription in BizTalk means that if certain parameters concerning the message are met, the subscriber will get a copy of that message.

A subscription could look something similar to the following pseudo code:

((Message Type = Order) and (Customer = HP)) or (Message Type = Invoice)

This would result in the subscriber getting all invoices entering BizTalk and also all orders from HP.

Subscriptions are typically made by Send Ports and Orchestrations. If a Send Port subscription is met, the message will be sent through the Send Port to the target system/location. If an orchestration activation subscription is met, a new instance of that Orchestration type will be initialized (read more about orchestrations in Chapter 4, Developing BizTalk Artifacts — Create Orchestrations). We will look further into Send Port subscriptions in the Setting up and managing Ports section later in this chapter.

Message Context properties

When subscribing, we cannot subscribe to any content of the actual messages entering BizTalk, but only to what information is on the Context of the message. The message metadata is called Context Properties and on receiving the message, both the Adapter and the Pipeline will add information to the Context.

Context properties can either be Promoted or Not promoted (also known as Written). Properties that are promoted can be used for subscribing to the message. However, written properties cannot be used for subscribing to the message.

Orchestrations

An Orchestration can receive messages from the MessageBox, based on its subscriptions. The subscriptions can be either activating (which will start a new Orchestration) or instance (which will deliver the message to an existing Orchestration). If the Orchestration needs to send/receive the messages during the execution, it will happens through the MessageBox, with the Orchestration submitting messages just like the Receive Port does.

Sending the message

When a message is sent to a Send Port, the process is almost the reverse of what happens in the Receive Port.

Maps

First, if Maps are applied to the port, BizTalk will try and match the message type with the source message type of the Map(s) on the port, and if a valid Map is found, it will be applied to the message.

Pipeline

Next, the Pipeline will typically do some or all of the following activities:

  • Validate the message

  • Convert the message from XML to the desired target format

  • Encrypt and sign the message if needed

Adapter

Finally, the adapter will transmit the message to its destination location.

 

Publish/subscribe


At its core, BizTalk is a publish/subscribe engine, nothing more nothing less. Whenever a message is received, BizTalk will look through all subscriptions and pass on a copy of the message to all the subscribers, if any. There are three kinds of artifacts inside BizTalk that can subscribe to messages:

  • Send Ports

  • Orchestrations

  • Request-response Receive Ports (these will also subscribe for the response it awaits, but this is out of the scope for this chapter).

If messages, for some reason, cannot be sent to one or more of the subscribers, BizTalk will store the message for resuming, or later analysis as to why the message could not be delivered. When all subscribers have received their message, BizTalk will no longer need to hold on to the message, and the message will be removed from BizTalk. A new subscriber will not be able to subscribe to messages that have already been processed and delivered inside BizTalk.

The following model shows how the BizTalk publish/subscribe mechanism works:

Receiving the message

First BizTalk will receive a message through the Receive Port. A message is received in a Receive Port through one of the Receive Locations associated with the port.

Adapter

The Adapter, responsible for communicating with the various Applications/protocols needed, picks up messages or a batch of messages, writes metadata to the Context of the message, and sends the message to the Pipeline.

Examples of Adapters are:

  • File

  • FTP

  • SQL

  • HTTP

Pipeline

The main purpose of the Pipeline on the receive side is to recognize the Message Type and disassemble the native format of the message to XML. Out of the box, a Receive Location can choose between either a PassThruReceive or XMLReceive Pipeline, where only XMLReceive will recognize the Message Type, whereas the PassThruReceive will slip the message onwards to the MessageBox as an anonymous message.

Some examples of native formats are:

  • XML

  • FlatFiles (comma separated values, positional, and so on)

  • EDI (X12, EDIFACT, and so on)

  • Excel *

  • PDF *

    Note

    * Not included in BizTalk, needs to be custom written or purchased from third party vendor.

The receive Pipeline will do parts or all of the following:

  • Decrypt the message if encrypted

  • Convert the native format into XML

  • De-batch the message if batched

  • Promote properties (write metadata to the Context of the message)

  • Validate the message

  • Resolve the sender of the message if signed (see more about this in Chapter 2,Developing BizTalk Artifacts—Create Schemas and Pipelines)

Maps

Now the message is evaluated with the Maps applied on the Receive Port (if any), and if the message matches the source Message Type on a Map, the Map will be applied.

MessageBox

The MessageBox is an SQL Server database, where all messages received by BizTalk are stored.

The three main purposes of the MessageBox are:

  • Stores all messages and Context received

  • Stores all subscriptions

  • Stores all Host Queues

Whenever a message is received by BizTalk, the receiving message agent will store the message in the MessageBox. During the publishing of the message, the agent will check all the subscriptions inside the MessageBox with the Context of the message and all matching subscribers will get a reference to the actual message in their respective Host Queues. When all subscribers have successfully processed their message, the message is no longer required in the MessageBox, and will be removed or moved to the Tracking database. The MessageBox also consists of all the subscriptions inside the BizTalk Group. Subscriptions are primarily made by Send Ports and Orchestrations and will be discussed in the following section.

Subscriptions

A subscription in BizTalk means that if certain parameters concerning the message are met, the subscriber will get a copy of that message.

A subscription could look something similar to the following pseudo code:

((Message Type = Order) and (Customer = HP)) or (Message Type = Invoice)

This would result in the subscriber getting all invoices entering BizTalk and also all orders from HP.

Subscriptions are typically made by Send Ports and Orchestrations. If a Send Port subscription is met, the message will be sent through the Send Port to the target system/location. If an orchestration activation subscription is met, a new instance of that Orchestration type will be initialized (read more about orchestrations in Chapter 4, Developing BizTalk Artifacts — Create Orchestrations). We will look further into Send Port subscriptions in the Setting up and managing Ports section later in this chapter.

Message Context properties

When subscribing, we cannot subscribe to any content of the actual messages entering BizTalk, but only to what information is on the Context of the message. The message metadata is called Context Properties and on receiving the message, both the Adapter and the Pipeline will add information to the Context.

Context properties can either be Promoted or Not promoted (also known as Written). Properties that are promoted can be used for subscribing to the message. However, written properties cannot be used for subscribing to the message.

Orchestrations

An Orchestration can receive messages from the MessageBox, based on its subscriptions. The subscriptions can be either activating (which will start a new Orchestration) or instance (which will deliver the message to an existing Orchestration). If the Orchestration needs to send/receive the messages during the execution, it will happens through the MessageBox, with the Orchestration submitting messages just like the Receive Port does.

Sending the message

When a message is sent to a Send Port, the process is almost the reverse of what happens in the Receive Port.

Maps

First, if Maps are applied to the port, BizTalk will try and match the message type with the source message type of the Map(s) on the port, and if a valid Map is found, it will be applied to the message.

Pipeline

Next, the Pipeline will typically do some or all of the following activities:

  • Validate the message

  • Convert the message from XML to the desired target format

  • Encrypt and sign the message if needed

Adapter

Finally, the adapter will transmit the message to its destination location.

 

BizTalk platform settings and Applications


This section talks about how the various BizTalk platform settings and Applications work and are configured.

BizTalk Administration Console

In this section, we will look at the BizTalk Administration Console, which is used to manage and configure the BizTalk Server and to deploy, manage, monitor, and troubleshoot Applications.

The Group Hub

The Group Hub gives the user an overview of what is currently going on inside BizTalk.

In order to view the Group Hub, open the BizTalk Administration Console and click on the BizTalk Group.

A large dashboard will appear where we get an overview of which Applications are currently running, how many running messages are currently in the MessageBox, and how many suspended messages there are.

Work in Progress should not be of any concern to us unless the amount of messages are large and keeps rising, in that case we might have a bottleneck in one of our solutions that needs to be addressed.

Suspended Items, on the other hand, requires our attention, as they are messages that for some reason cannot be further processed until manual actions have been taken. Suspended Items fall into two categories:

  • Resumable: Messages which can be manually resumed.

  • Non-resumable: Messages, which typically hold metadata and cannot be resumed. They will either disappear when the corresponding resumable instance is resumed, or in other cases they might need manual termination.

Hosts and Host Instances

For each BizTalk Group, multiple Hosts can be created. Creating a Host is merely creating a logical container where various BizTalk tasks can be assigned.

A Host can be either of type In-Process or Isolated.

The In-process type is used for most BizTalk tasks and what in-process means is that all the tasks performed in the Host will happen in an actual BizTalk process (Windows Service). The Isolated Host, on the other hand, will have its work done by "someone other than BizTalk", for example an IIS receiving service calls and processing the message on its own. By using various BizTalk Modules, the IIS Host will run the received message through the same steps that would occur when using an in-process BizTalk service, Adapter and Pipeline processing, and storing the message in the MessageBox.

Out of the box, the use of Isolated Hosts is limited to:

  • HTTP Receive

  • SOAP Receive

  • WCF-BasicHttp Receive

  • WCF-CustomIsolated Receive

  • WCF-WSHttp

What the Adapter Handlers have in common is that receiving the messages will happen through the IIS and not a Windows Service (when BizTalk receives HTTP messages, the submitter will actually call a URL on an IIS residing on the BizTalk Server).

Each Host should have at least one corresponding Host Instance running. An In-Process Host Instance is nothing more than a Windows service running on one or more BizTalk Servers and performs the tasks assigned to the Host.

Creating a Host

Creating a Host can be done through the BizTalk Service Administration Console, by choosing Platform settings | Hosts | New | Host:

Creating a new Host will result in a new entry in the Host table inside the Management database, and also create a new Host Queue inside the MessageBox.

There are a few parameters that should be taken into consideration when creating Hosts:

  • Name: The name of the Host is very important when moving a BizTalk solution from one environment to another. If we use binding files to replicate one environment to another, the naming of Hosts must be the same on each environment.

  • Type: Either In-Process or Isolated.

  • Allow Host Tracking: If enabled, the Host Instances created for the Host, will perform Tracking tasks such as moving data from the MessageBox to the Tracking database.

  • Authentication Trusted: This is used to mark that the current Host is trusted. If a Host is trusted, other Hosts will trust the given Host and will be able to trust that the messages received from the Host have correct Sender ID and Party ID and will not overwrite these. This is mainly used if credentials from the original caller to BizTalk are needed to travel through BizTalk in order to make Single-Sign On credential control on the send side.

  • 32-bit only: This flag is enabled by default. If it is removed, then the process will run as a 64-bit process, otherwise as a 32-bit.

  • Make this the default Host in the group: Any BizTalk Group will always have one default Host. If this checkbox is disabled, the Host is already a default Host.

  • Windows group: Specify a Windows group that will be given access to all tasks that needs to be performed by a Host Instance running under the Host. It is recommended that all users running Host Instances under this Host are members of the group.

There can be several reasons for creating multiple Hosts inside a BizTalk environment. There is no Host setup recommendation that will fit all environments, and some considerations will need to be made based on the actual environment and the specific requirements.

Here are a few general guidelines:

  • As a default it is recommended to have five Hosts:

    • Receive Host: Used for all in-process receiving

    • Isolated Host: Used for all IIS Receive

    • Processing Host: Used for all Orchestrations

    • Send Host: Used for all sending of messages

    • Tracking Host: A dedicated Host for moving data from the MessageBox to the Tracking and BAM databases, as this task can have a performance impact, the other Hosts should not be set to allow Host Tracking

  • When using adapters that must run in a 32 bit process, 32 bit Hosts might need to be created on receive and/or send side to Host the 32 bit only adapters. Another approach could be to have the Receive and Send Hosts running in 32 bit mode. If 64 bit processing is required (typically when receiving large messages) a 64 bit Host can be created for handling the tasks where 64 bit is desired.

  • Some Receive Adapters should not run in a multi-server environment (such as FTP, POP3, and MSMQ). So, in that case a special Host for hosting these Receive Locations might be created and only run on one server. If high availability is required, this Host should be clustered.

  • Don't just make thousands of Hosts. The advantages of multiple Host Instances (Windows services) on each BizTalk Server are that they will use their own threads, have their own queues, and so on. However, each service will also consume resources (such as memory) and therefore creating too many Host Instances can have a negative impact. Therefore we need to find a balance. If we have a small BizTalk solution with only a few messages running through the BizTalk environment, chances are that performance will be fine by just using one in-process Host for everything.

Creating a Host Instance

Unlike creating a Host, creating a Host Instance will happen on both the BizTalk Server and also in the BizTalk databases. A new Host Instance will result in a new Windows service running on a BizTalk Server. Only one instance of a certain Host type can be created on each BizTalk Server in the BizTalk Group. When creating a new Host Instance, we are presented with the following screen:

In the preceding example, we have created a new Host Instance of the Host NewHost on server ALASKA.

After selecting the correct Host and server, click on Configure to specify which user the service should run as. This user will need access to the Host queues/tables in the MessageBox and the easiest way to grant the user these privileges is to add the user to the Windows group that we associated with the Host when creating it.

If the recommendation of adding the user to the Host Windows Group is followed, the service will be able to do all the tasks needed towards communication with the MessageBox, but not necessarily with the outside world. The user running a Receive Location using a FILE Adapter will be the user trying to access the source file folder, read the file, move/delete the file, and so on. When dealing with granting the BizTalk Host Instances access to various surrounding environments, the Host Windows Group should always be used and not the individual user.

There are several reasons for granting the group and not the users the required access:

  • It is usually recommended that only groups get permissions so that IT operators never have to deal with individual users, but rather just add and remove users from the relevant groups.

  • In a BizTalk setup, we might have three BizTalk Servers and therefore 3 different Host Instances of the same Host. These three Host Instances could be running under three different users. Now, let us say that we configure a File Receive Location to poll files from a certain folder and have it run under our Host. Any of the three Host Instances could now be getting the task of having to retrieve files from the folder, and therefore all three users need the correct set of folder rights. If we make sure that all three users are members of the Host Windows Group and that the group is given the correct set of credentials, we need not worry about anything else, and at some point we might even add an additional BizTalk Server with a new Host Instance and a new user, who, as long as they are added as a member of the Host Group, will be able to access the folder immediately.

Managing Adapter Handlers

Each adapter installed in the BizTalk Group has corresponding Receive and/or Send Handlers that are used to link the adapter to a certain Host.

Managing the Adapter Handler is done through the BizTalk Administration Console, as shown in the following screenshot:

From here we can install new adapters and add Receive or Send Handlers to adapters.

In order to add a new handler to an adapter, click on the Adapter and right-click somewhere in the blank space underneath the existing handlers:

Each handler will be the link between an adapter and a Host. Only one handler per adapter and Host can be created, and only Hosts for which a handler of the correct type exists can be chosen when configuring the transport adapter and its handler in Receive Locations and Send Ports.

Some handlers have the ability to have some basic configuration that will be applied to all adapter settings using that Host as default.

The SMTP Adapter is an example, where we often set up some basic configuration on the Handler level, because these properties will often be the same for all Send Ports using the SMTP Adapter. To change these standard properties, open the relevant SMTP Handler and choose Properties:

In the preceding screenshot, we can configure some general properties for all SMTP Adapter usage under the Host NewHost. (See the Configuring core Adapters section later in this chapter for more information.)

Applications

Applications are logical containers inside the BizTalk Administration Console, which allows us to group certain items together. The purpose of Applications is mainly to make planning, deployment, administration, and the general overview easier when working with BizTalk.

In order to create a new Application, carry out the following steps:

  1. 1. Open the BizTalk Administration Console.

  2. 2. Right-click on Applications and choose New | Application.

  3. 3. Give the Application an appropriate name and click on OK.

When working inside an Application, we are only able to work directly with the other artifacts in that Application. For example, if we need to use a Pipeline in a Send Port, that Pipeline needs to be deployed in the same Application, or we need to make a reference to the Application which contains the pipeline.

Referencing another Application

When making a reference to another Application, right-click on the Application that needs a reference to another Application, and carry out the following steps:

  1. 1. Click on Reference, and then click on Add:

We now get a list of all available Applications other than the Application we are working with. Choose one or more Applications you want to reference.

Notice that BizTalk.System is already referenced in all new Applications. As a result of this, we can work with several Pipelines as soon as a new Application is created, even though these Pipelines are deployed in the BizTalk.System Application.

 

Setting up and managing Ports


Inside BizTalk, we have both Receive and Send Ports. Ports are entry points and exit points in and out of BizTalk. All messages entering BizTalk will be received through a Receive Port and almost all messages exiting BizTalk will be through a Send Port. (Even if it is possible to send out messages directly through code inside an Orchestration, this will not very often be the correct approach.)

Receive Ports

Receive Ports are the entry points for messages that enter BizTalk. Each Receive Port contains from one to many different Receive Locations (we can create Receive Ports without any Receive Locations, but that would not make much sense).

  1. 1. In order to create a new Receive Port, right-click on the Receive Ports folder in the Application where the Port should be created, and choose New | One-way Receive Port or Request Response Receive Port.

    In most routing scenarios, one-way Ports are used, and the use of Request-Response Receive Ports should be limited to flows where BizTalk exposes services, where an actual response message is required. (Read more about best practices later in this chapter in the Implementing messaging patterns section.

  2. 2. Next, we need to give the Port a name. (Note that names of the various Ports inside a BizTalk Group must be unique not just inside an Application but for the whole BizTalk Group.)

  3. 3. Next, click on OK to create the Receive Port.

Port Authentication

One way of making sure that only messages from known partners enters BizTalk, is by using the Port Authentication feature available on Receive Ports, as seen in the following screenshot:

When using Receive Ports, we can set up filters so that only messages from known parties are allowed through to the MessageBox. This will only work if messages are signed and we have all the certificates of our parties in store, or if the Windows User who submitted the message can be located. There are three properties on each Receive Port:

Type

Description

No authentication (Default)

All messages will be let through to the MessageBox whether or not the party resolution inside the Pipeline finds a valid sender or not

Drop messages if authentication fails

If the party resolver does not match a valid sender from the message signature, the message will be thrown away and not submitted to the MessageBox

Keep messages if authentication fails

If the party resolver does not match a valid sender from the message signature, the message will be suspended inside the MessageBox and an error will be raised in the EventLog

Receive Locations

As mentioned earlier, a Receive Port with no Receive Location does not make any sense. No messages will ever be received through that Port. So for each Receive Port, at least one Receive Location should be created and configured.

The reason for having multiple Receive Locations inside one Receive Port is to have the ability to receive different messages from different locations and having BizTalk treat them as if they were received from the same place and/or had the same message type.

In order to create a new Receive Location, create a new Receive Location from within the Receive Port:

Alternatively, right-click on the Receive Locations folder in the Application and choose New | One-way Receive Location or Request Response Receive Location. As for Receive Location types, only one-way Receive Locations can be added to a one-way Receive Port, and only Request-Response locations to a Request-Response Port.

If a Receive Location is created directly, we will be prompted for a parent Receive Port before we can configure the location, since all locations must be part of one specific Port. In the following screenshot, we are presented with the available Receive Ports:

Choose the appropriate Receive Port, click on OK, and the Receive Location configuration will appear:

Like Receive Ports, Receive Locations need to be supplied with a Name. Also, a Type (Adapter) needs to be selected and configured, a Receive Handler (Host type) also needs to be selected (note that the default Host for the chosen handler will always be automatically selected), and finally a Pipeline needs to be selected. Read more about Pipelines in Chapter 2, Developing BizTalk Artifacts – Create Schemas and Pipelines.

Service Windows

Each Receive Location can be scheduled to only operate at certain times.

On the Schedule page inside the Receive Location, a Start date, Stop date, and a Service Window can be applied, as shown in the following screenshot:

Each of the three parameters can be enabled or disabled, and each enabled time period will limit the time the Receive Location is enabled for receiving messages.

Location states

A Receive Location can have two different states: enabled or disabled. If the location is enabled, it will receive messages, if disabled, no messages will be received.

Enabling a Receive Location can be done by right-clicking on it inside the BizTalk Administration Console and choosing enable. It can also be done through code script.

Error threshold

The state of a Receive Location is merely a flag inside the Receive Location table in the Management database. It has nothing to do with whether or not the Host Instances (Windows services) are running. Therefore a Receive Location will only pick up messages if it is enabled, and at least one instance of the Host type it is using is running.

If errors occur in a Receive Location when trying to pick up messages (access denied in a file folder, or on a database, and so on), the Host Instance will start to write error/warning entries in the EventLog. At some point, the error threshold (this differs from adapter to adapter) might be reached, and the Receive Location will become disabled. If a Receive Location becomes disabled, it will not start itself again automatically, but instead it will write an error message in the EventLog of the BizTalk Server that did the shut down, and therefore monitoring these events is critical, as a disabled Receive Locations results in no messages being received by BizTalk.

In the following example, we are polling mails from a mail server by using the POP3 Receive Adapter, and want to examine the error threshold:

When setting up the adapter, we are asked for the polling interval and the error threshold. If set to 5 and 10, as shown in the preceding screenshot, the following is what would happen if Receive Location started failing:

  • BizTalk will poll mails every five minutes. At some point, the mail server becomes unavailable and the process of logging on and retrieving mails starts failing.

  • The first time BizTalk unsuccessfully tries to access the Mail Server, it will write a warning in the EventLog saying that it wasn't able to connect to the Mail Server, and that it will try again later.

  • The second try will be five minutes later and unless the Mail Server suddenly becomes available again, this will go on for another nine times.

  • When the 10th try occurs, BizTalk will no longer retry and will therefore put a stop to the retrying by disabling the Receive Location, writing an error to the EventLog saying that the number of retries were reached, and now it is up to the administrators to fix the problem and enable the Receive Location again.

When configuring the various Receive Locations, we need to find a balance between how many retries (the threshold) we configure. If we have an unstable environment, such as an FTP Server residing somewhere outside our control, with multiple unscheduled service windows and general unavailability, it might be tempting to increase the error threshold to 9,000 or something similar, so that we have long periods of unavailability, and when the FTP Server eventually comes back online, we do not risk the Receive Location having shut down. This might not be the best approach, as it is likely that the people monitoring BizTalk will only look at errors and not warnings in EventLog, so nobody will notice that we are not polling data from the source if something more critical happens (such as our password expires or something similar to it). In that case, we will not be notified until all 9,000 tries have been failing and the Receive Location, after maybe months, eventually shuts do wn.

Receive Port Maps

Receive Port Maps are applied to the message after the message leaves the Pipeline, in which case all messages should be in the format of XML. This is important since Maps can only take XML as input and also a Map will always output XML.

Maps can only be applied if the Pipeline has discovered the message type of the incoming message (this will happen automatically unless the PassThruReceive Pipeline is used, refer to the next chapter). If the message type is not known by the time the message exists the Pipeline, no Map will be applied, even if a Map matching the message is present on the port.

The matching of a Map works as follows:

If the message type was discovered and promoted by the receiving Pipeline, BizTalk will look for a Map with a source type matching the message type. If such a Map is found, it will be executed and the source message will be mapped using that Map.

It is also worth mentioning that after a Map has been executed on a Receive Port, an XML Disassemble Pipeline Component is executed against the output XML. This is why we can promote properties on the destination Schema of a Map executed on the Receive Port and still have the properties promoted before the message is submitted to the MessageBox. The following example will explain this.

On a Receive Port (PortA), we have applied three different Maps:

  • MessageA_to_MessageU

  • MessageB_to_MessageU

  • MessageU_to_MessageI

If we receive message A (and the message type is applied in the Pipeline), the message will be transformed to Message U, but after that the message exits the Port, and no additional Map discovery will be done, so even though we might want message A to be transformed first into message U and then into message I, this will not happen. The same goes for message B, and only if we submit a message U will the Map (MessageU_to_MessageI) be applied.

Maps are applied to Receive Ports by selecting Properties on the Port and then selecting Inbound Maps, as shown in the following screenshot:

Under the Map section, use the drop-down list, then all Maps deployed in the Application (or Applications that are being referenced) should appear. Choose the Map that should be used in the Receive Port, remember that multiple Maps can be selected.

Send Ports

Unlike a Receive Port, Send Ports do not operate with more than one location. Each Send Port will point to a specific location, database, Application, service, and so on, somewhere outside of BizTalk. Like a Receive Location, a Send Port uses one Pipeline and one Adapter, so that the desired message(s) and the desired protocol are used for transporting the message to the target destination. In order to create a new Send Port do the following:

After choosing New | Static One-way Send Port... the following screen will appear:

When creating a new Send Port, at least three properties should be selected, and in some cases, configured.

First, we need to supply the Send Port with a name. A type (Adapter) also needs to be selected and configured. Next we can choose a Send Handler (Host), if we do not want to use the default Host. Finally, if the default Pipeline is not adequate, another Pipeline must be chosen and configured.

Transport Advanced Options

In Transport Advanced Options, several common parameters can be configured in the Send Port:

The transport options consist of three parameters:

Retry count

The number of tries the Send Port should try to resend the message on failure before giving up and suspending the message in the MessageBox

Retry interval

The number of minutes to wait between the retries in case of failure

Priority

The priority given to the Send Port subscription (1 being the highest and 10 the lowest), the higher the priority, the faster the Send Port will get messages it has subscribed for

Retry on a Send Port is a bit different from Receive Locations. First of all, the behavior is per message and the port will never stop itself after any number of retries has been exhausted.

What the Send Port does is try to send each message it receives the number of times specified in the Retry count parameter, and with an interval specified in Retry interval. When the number of retries has been exhausted, the message will be suspended and an error will be written to the EventLog. (Like the Receive Location, the first failure(s) results in warnings being written to the EventLog, only the final try, with the following suspension of the message, will result in an error.)

Scheduling and Service Window

Each Send Port created can have a scheduled service window in which messages will be sent through the Port. The set up is done under Transport Advanced Options:

Like Receive Locations, certain operation periods can be set up on a Send Port. We can specify a period within the day, where messages should be sent through the Port. At all other times, all messages going to the Port will be queued up inside BizTalk, and when the Operation Window opens, all the queued up messages will be sent.

The term service window might be a bit confusing, normally a service window is a time period where maintenance is going on, and therefore a period where no messages should be sent to the system, but in this case the service window is the time where messages are actually sent through the Send Port.

Backup transport

Each Send Port can have a backup transport configured, where an alternative Adapter and/or address can be selected, so that if the primary target is unavailable the Send Port will try to send the message to an alternative location instead.

Send Port Maps

Just like Receive Ports, multiple Maps can be applied to the Send Ports in order to transform the messages being sent from the MessageBox to the target format requested by the target system. Just like the Receive Port, multiple Maps may be applied to the Send Port, but only one of them will be used, and only if the message type is known by BizTalk at the time the message is sent from the MessageBox to the Send Port.

In order to apply Maps to Send Ports, open the Send Port properties and select the Outbound Maps:

Configuring Filters (Subscriptions)

Inside the Filters page, it is possible to set up subscriptions for the Send Port. The filters can be a combination of several boolean expressions and include a combination of and/or with promoted properties deployed to the BizTalk Group (in Property Schemas). The following is an example of setting up a subscription on a Send Port:

The example in the preceding screenshot will subscribe to all messages that comes out of the Receive Port CG0101_Receive.

Port states

A Send Port can have the following three different states:

  • Started: The Send Port will be getting messages that matches its subscriptions and send them to the target system, if not outside the service window.

  • Stopped: The Send Port will be getting messages that match its subscriptions but the messages will lie in a queue inside the MessageBox and not be sent through the Send Port until the Send Port is started.

  • Unenlisted: The Send Port does not subscribe to any messages and no messages will be sent through the port. The port will not be able to get messages later on, which are already received in the MessageBox.

Port states can be changed by right-clicking on the port inside the Administration Console:

Note

Note that if we right-click on an Unenlisted Port, the state will be named Enlist in the menu and not Stop.

The Stopped state will queue up all messages for the Send Port, and when the Port is started again all messages will be sent immediately through the Send Port (if no service window is configured). This might not always be what is desired, especially if the Port was stopped due to some configuration error in BizTalk or the target system, resulting in messages failing upon arrival at the target. In that case, sending 100 messages all at once when we think the problem has been resolved might not be the best approach. If we just want to send one of the 100 messages currently lying in the MessageBox waiting for the Port to be started, we can go to the Group Hub, find the 100 suspended messages, and resume just one of them. This will force the one message to be sent through the Send Port even though the state is still set to stopped, and on acceptance that the problem has been fixed, we c an then start the port and the last 99 messages (or more if more messages have arrived in the MessageBox) will automatically be sent through the Port.

Dynamic Send Ports

Dynamic Send Ports differ from Static Ports as their adapter and/or address are not configured and hardcoded. Both protocol (adapter) and address can be coded from inside BizTalk and therefore the port could send messages to different locations using different protocols (SMTP, FTP, and so on).

They are often used for SMTP, because an SMTP Send Port often requires sending mails to different addresses that might be located somewhere in the message. This is not possible with a static Send Port, which will always point to the same address (as will all other adapters). Hence, to solve that problem Dynamic Ports can be used.

Dynamic Ports are usually combined with Orchestrations and will be discussed further in Chapter 5, Debugging and Exception Handling.

Send Port Groups

Send Port Groups are logical subscription containers where one or more Send Ports can join the subscription of the group. A Send Port can be part of multiple Send Port Groups, and also have its own local subscription, and can therefore have multiple subscriptions.

Send Port Groups are created by right-clicking on the Send Port Group folder inside an Application, and choosing New | Send Port Group.

Failed message routing

On both Receive and Send Ports, it is possible to enable routing for failed messages. What this will do is, in case of an error occurring in the port (could be either the Pipeline throwing an error, mapping failing, or a Send Port that is not able to send to the target system, and so on), the message will have all the regular Context Properties unpromoted (written) and instead have some error-specific Context Properties promoted (all in the ErrorReport namespace).

Examples of Error Context Properties are: ErrorReport.ErrorType and ErrorReport.ReceivePortName.

A Send Port or Orchestration can then subscribe to these error properties and deal with the errors in some way.

In order to set up failed message routing on a Receive Port, go to the properties of the Port, on the General tab and enable the Enable routing for failed messages checkbox.

In order to set up failed message routing on a Send Port, go to the Properties of the port, on the Transport Advanced Options, enable the Enable routing for failed messages checkbox.

See more about failed message routing in Chapter 5, Debugging and Exception Handling.

Ordered delivery

Ordered delivery might not come as easy as one might think in BizTalk. Out of the box, only few Receive Adapters are able to provide true ordered delivery.

An example: We receive files during the day from a file drop location. Our ERP system has requested that it receives all files in the same order as they were submitted to the file folder, because receiving data in the wrong order could potentially cause inconsistent data. Let us think of BizTalk as a post office. If some customer has asked the mailman to deliver today's letters, the exact same way he received the letters in the mailbox on the street, the mailman immediately faces a problem. He can give the customer the letters in the same order that he got the letters out of the mailbox, but that is not necessarily the same order that they were put into the mailbox. The same is true for BizTalk: we are able to send messages through a Send Port or to an Orchestration in the same order they were submitted to the MessageBox, but that order might not be the same order the original submitter intended.

Again, back to the file drop example: The FILE adapter, like many other adapters, might not submit the messages received in the same order as one might intend/expect. The FILE adapter does not look at timestamps, file sizes, or even filenames when choosing which file to process first. There could also be more than one Host Instance receiving batches of files at the same time from the same folder, and submitting them in the same MessageBox. In other words, if BizTalk is started and two files are present at a certain file location, we have no way of knowing whether the oldest file is taken first or second, and therefore have no certain way of making a total FIFO (first in first out) scenario using the File Receive Adapter. In fact this is true for most of the BizTalk Receive Adapters, and out of the box, only the message queue adapters (MSMQ and MQSeries) support true ordered delivery. (Some database adapters and WCF Service Adapters can be set up to im plement ordered delivery, but only with certain limitations such as only one Host Instance, and so on.)

Receive Locations

On the receive side, it is based on the different protocols (Adapters) if ordered delivery is supported or not. For the very few Adapters that do support it (mainly MQ), it can usually be enabled on the Receive Adapter.

Send Ports

Each Send Port can be set up to use ordered delivery. Setting a Send Port to ordered delivery means that all messages will be sent through that Port in the same order as they were received in the MessageBox. If messages are not received in the MessageBox in the order intended, as discussed earlier, using ordered delivery on a Send Port might not have the desired result.

Using ordered delivery on a Send Port has some serious performance impacts, because only one thread can submit messages through the Port, and each message has to wait for the message ahead to complete before it can be processed. This can be both an advantage and a disadvantage. The disadvantage is obvious. BizTalk will perform more slowly when using ordered delivery. In some cases, however, this might turn into an advantage. If, for instance, a Send Port calls a service that cannot handle multiple calls, we might experience a lot of messages going into a retry or even fail state, because the amount of messages being sent to the service is exceeding the amount of messages the service can handle. In this case, it could make sense to introduce ordered delivery to the Send Port, not because we necessarily need the messages to be sent in a certain order, but merely because this will result in BizTalk only sending one message at a time:

  1. 1. In order to set up ordered delivery on a Send Port, go to the properties of a Send Port (either by double-clicking on the Send Port or right-clicking and choosing Properties.

  2. 2. Go to the Transport Advanced Options page, and enable Ordered delivery:

When enabling ordered delivery, an additional sub setting will become active: Stop sending subsequent messages on current message failure. This means that if 10 messages are currently queued up to be sent through the sent port (message 1 to 10) and message 3 fails, the rest of the messages (4 to 10) will get suspended together with message 3. If true ordered delivery is required, this option should be enabled, simply because if it is not, the solution is not 100% ordered delivery. On the other hand, if ordered delivery is nice to have, not 100% vital for the solution, or we are simply using ordered delivery to slow down the Send Port, then the option should be disabled.

Note

Note that ordered delivery does not work on the backup transport, if used.

 

Configuring core Adapters


When choosing an Adapter on both Receive Locations and Send Ports, the Adapters need to be configured.

On either a Send Port or Receive Location, choose the Configure button as shown in the following screenshot:

What will appear next depends on which type of adapter was chosen. In this chapter, we will look at some of the core adapters and how they are configured.

HTTP

This section will discuss the use of the HTTP Adapter in both receive and send scenarios.

Sending HTTP

When configuring the HTTP Send Adapter, the URL of the target HTTP site needs to be configured. The following screenshot shows the basic configuration, and the Destination URL being configured:

Receiving HTTP

Setting up BizTalk to receive HTTP requires more work than sending HTTP. In order to be able to receive HTTP, we need to use the local IIS (Internet Information Services) and have it receive the actual message for us using an Isolated Host.

First, we need to add BTSHttpReceive.dll. This file is found in the %Program Files%\Microsoft BizTalk Server 2010\HttpReceive64 folder (HttpReceive folder if not using a 64-bit IIS). This DLL needs to be added as an extension inside the IIS. Open the IIS Manager (Start | Administrative Tools | Internet Information Services(IIS) Manager), click on the computer name and double-click on Handler Mappings. In the action pane on the right, choose Add Script Map:

In the Request path type BTSHttpReceive.dll. In executable, choose the BTSHttpReceive.dll file from within program files, and give the mapping a proper name. Now, click on OK:

Click on Yes in the Add Script Map dialog to the information that an ISAPI extension will be created, and that the entries will be made in other configuration stores inside the IIS.

Now, we need to make a Virtual Directory containing the BTSHttpReceive.dll mentioned earlier. Right-click on the Default Web Site folder and select Add Virtual Directory. Set the Alias property to the name that we want the callers of our HTTP service to use in the URL (http://servername/Alias/BTSHTTPReceive.dll). Under Physical Path, choose the folder where the BTSHTTPReceive.dll is located (under Program Files) and click on OK.

Next, we need to set up a HTTP Receive Location. The HTTP flow that we are receiving in BizTalk can be both one-way or request-response (refer to the Implementing messaging patterns section).

When configuring the HTTP Receive Adapter, we need to specify the Virtual Directory and the DLL extension, as shown in the following screenshot:

In some cases it also makes sense to enable Suspend failed requests. What this option does is to give BizTalk the responsibility of processing the message as soon as it has been submitted. If this option is not enabled, the caller will get an error back if the message could not be processed correctly (the Pipeline fails or no subscribers were found, and so on). This could be a valid set up, but in some situations it would make more sense to have the HTTP receive Adapter handle errors the same way as a FILE adapter, by taking responsibility of the message as soon as it was submitted and not bother the caller with any problems inside BizTalk, but rather suspend the message and deal with the problems internally and let the caller believe that everything processed as expected.

POP3

The POP3 Adapter is used to receive e-mails. The Adapter is a receive-only Adapter, because sending something through POP3 does not make any sense. The send equivalent of POP3 is usually SMTP, which we will look at in the following section.

Note

Under certain conditions, the POP3 Adapter will not run under a multi-server set up, and in these cases the use of clustering Hosts might be needed. Read more about this at http://msdn.microsoft.com/en-us/library/cc296808(v=bts.10).aspx.

Here are the possible parameters used for configuring the POP3 Adapter, with the most common parameters highlighted:

As a minimum, the Mail Server, User Name, Password, and Body Part Index need to be configured.

The body part index is used to choose what part of the mail will be considered the actual message inside BizTalk. 0 is the message body, 1 is the first attachment, 2 is the second attachment, and so on.

Note

Note that if Body Part Content Type is set to a specific content type, the algorithm for choosing which part of the mail to use is a bit more complex. For further information see http://msdn.microsoft.com/en-us/library/aa560251(v=bts.70).aspx).

SMTP

The SMTP Adapter is used for sending e-mails. In order to set up the SMTP Adapter, it is often a good idea to configure the General Server Credentials inside the SMTP Send Handler (refer to the Managing Adapter Handlers section).

The following screenshot shows the configuration screen of the SMTP Adapter:

On the Send Handler, the SMTP server name and the From (e-mail address) can be configured as they will likely be the same for all SMTP Send Ports. These parameters can be overwritten on a single Send Port if required.

When configuring the actual SMTP Adapter on a Send Port, carry out the following steps:

  1. 1. In the General tab, choose the e-mail address to send to in the To: textbox. Also give the email a subject and, if needed, specify a CC address.

  2. 2. In the Compose tab, choose either the BizTalk message body part as the e-mail body or choose Text for standard text.

  3. 3. If a standard text is chosen, move to the Attachments tab:

  4. 4. Choose Attach only body part to have the actual message as an attachment.

  5. 5. Use the Handler Override options if the SMTP server setup in the Adapter Handler should be overwritten.

FTP

The FTP Adapter can be used on both the receive and send side of BizTalk. On the receive side only single server setup is allowed.

When configuring the FTP Adapter, there are some basic features that apply to both sending and receiving:

For all FTP configurations, at least the following four parameters should be configured:

  • Server: The name or IP address of the FTP Server

  • User Name: The username of the user logging onto the FTP Server

  • Password: The password for the user logging onto the server

  • Folder: The folder to either download files from (receive) or upload files to (send)

Receiving FTP

When using basic configuration, the FTP Server will delete the files from the FTP Server when they are processed, so that the same files are not fetched more than once.

However, this might not always be the desired functionality, as we might not be allowed to delete the files, the server could be holding files that are not just for us, but published for many subscribers.

In order to overcome this issue, new polling features have been introduced in BizTalk Server 2010, which are shown in the following screenshot:

It is now possible to change the Delete After Download attribute on the FTP receive Adapter from Yes to No. By doing this, BizTalk will keep a track of which files have already been downloaded, and the same files will not be downloaded again even though they are still on the FTP Server. If existing files are edited and overwritten on the FTP Server and we want a new copy if changes happen to the files, we should also set the Enable Timestamp comparison to Yes. By doing this we will both get new files once, but also a fresh copy of any files that have changed on the FTP Server.

The interval (in the previous example is 60 seconds) should also be taken into consideration when setting up the receive FTP. This is an indication of how often BizTalk will look in the FTP folder for new messages. If set too often, we might experience too much network traffic and problems with the FTP Server. If it is set to only poll rarely, we might experience that messages submitted for BizTalk take a long time to process, because they are not polled by BizTalk often enough.

The FTP protocol does not have any proper lock mechanism, so if a large file is being written to the folder where BizTalk is polling from, BizTalk will start downloading the file as soon as the file is visible, and not necessarily when the file is complete. This problem needs to be addressed by the systems uploading the files to BizTalk in the FTP folders, either by creating the files with a temporary extension (filename.xml.tmp), and then removing the .tmp after the file is completed. In that case, we also need to set up the File Mask property on the FTP receive to look for files with the xml extension (*.xml).

Another way of dealing with the problem of files being downloaded by BizTalk before the file is fully written, is having the uploader upload the file to a temporary folder and then moving it to the correct folder where BizTalk is polling from, when the file is completed.

Sending FTP

When sending FTP, it is basically the core configuration that is needed (server, username, and so on). However, there are two other properties that are often relevant to take into consideration:

First, we will look at Target File Name. This is used to specify the name that BizTalk will give to the file written to the FTP Server. The default is %MessageID%.xml where %MessageID% will be replaced with an internal GUID unique for each message, so that no two files uploaded to an FTP Server from BizTalk will ever have the same name. The use of hardcoded names (such as Order.xml) is not recommended, as this will cause a failure on the send side if BizTalk tries to upload a file with the same name twice, and the first file has not been processed by the destination party yet.

It is also possible to use %SourceFileName% as a file mask in Target File Name. This will give the file the same name as it had when submitted to BizTalk by either a file or FTP. Again, we need to take into consideration whether or not two files could end up with the same name and therefore cause the FTP Send Adapter to fail, also this will only work if all files sent through the FTP Adapter were in fact received into BizTalk by either the File or FTP Adapter (See Implementing messaging patterns section).

Another property that might be useful when sending FTP is the Temporary Folder. This enables the adapter to upload the file to another, than the one specified in the Temporary Folder property, and move the file to the correct folder when upload has completed. As we discussed with the receive FTP Adapter, this might be useful because FTP does not have any proper locking mechanism.

File

The FILE adapter is one of the most used adapters, both for testing/demo but also for communicating with several legacy systems where the only protocol supported is exporting and importing files.

Receiving files

Configuring the Receive File Adapter requires a path to the folder where BizTalk should pick up files (Receive folder), as well as a File mask that specifies which type of files and/or filenames should be received. This folder can be either local or located on a file server somewhere on the network. Using local folders is not recommended when working with multi-server environments as that would cause BizTalk to have more than one file entry-point. It should be transparent to the surrounding environments how many BizTalk Servers a BizTalk Group contains.

If using a File Server, be aware that using mapped drive letters in the Receive folder might not work as intended (Z:\Inbox), because it will use the mapped drives of the user running the Host Instance and not necessarily the mapped drives seen by the user configuring the port. Therefore, UNC paths are recommended (\\ServerName\Path\Inbox). The following screenshot shows the general configuration properties for a receive FILE Adapter:

The Receive folder can only point to a single folder. It is not possible to have the same Receive Location probing in more than one folder. This limitation also includes subfolders.

If working on NTFS file systems, the FILE adapter will work using File System Events, so every time a file is submitted, BizTalk will be notified almost immediately and will start processing the file (except if Service Windows are implemented on the Receive Location).

Sending files

When using the FILE adapter on the send side, the configuration looks similar to the following screenshot:

When sending files using the FILE adapter, we need to specify the Destination folder and the File name. The default file name is %MessageID%.xml, which will give the filename a unique GUID, to make sure no two files are given the same name.

Like the FTP Adapter, %SourceFileName% can also be used on the FILE adapter, but again we should use it with caution, as it will only work if the original message was received through either a FTP or FILE adapter.

It is also possible to set how the FILE adapter should write the file to folder using the Copy mode. There are three possible modes:

  • Append: This will append the message to an existing file, if the file is already present. It requires a hardcoded filename, and it is usually used for FlatFiles (comma delimited, positional text files) and not for XML.

  • Create New (default): This setting is the most commonly used setting. It will create, or try to create, a new file each time a message is sent to the port. Using this setting it is recommended that the filename is unique, which can be done by using %MessageID%.

  • Overwrite: This also requires a hardcoded filename; it will overwrite an existing file with the file currently being written to a file folder. This is often used when dealing with daily inventory reports and so on where the old data is obsolete as soon as new data is present.

Credentials

If no credentials are specified in the FILE adapter configuration, it will be the user running the Host Instance which needs to have the correct amount of rights to the folder it is receiving from or sending to. If the user does not have the sufficient amount of credentials, we can supply another username and password for the FILE adapter to use, shown as follows:

Click on the Authentication tab and specify a username and password, and that user will be used instead of the Host Instance user. This can be done for both receiving and sending files.

 

Configuring content-based routing


The following is a walk-through of a routing sample in BizTalk. The sample is done by using the FILE adapter only, and also no coding is done. The next chapter will introduce us to creating various BizTalk artifacts inside Visual Studio, but for now let us look at an example showing how BizTalk routes messages.

The setup is as follows:

  • We receive files from both partner A and B in different file folders

  • These files need to be routed to both System I and System II

Creating folders and Application

The first step is to create a Receive Port with two different Receive Locations. We should to be able to pick up messages at two different file locations:

  • C:\BTS2010CertGuide\Chapter01\Example01-Messaging\FileDrop\PartnerA\Inbox

  • C:\BTS2010CertGuide\Chapter01\Example01-Messaging\FileDrop\PartnerB\Inbox

We should be able to send messages to two different systems (file locations):

  • C:\BTS2010CertGuide\Chapter01\Example01-Messaging\FileDrop\SystemI\Outbox

  • C:\BTS2010CertGuide\Chapter01\Example01-Messaging\FileDropSystemII\Outbox

Make sure that the BizTalk Host user has sufficient permissions for the folders. Give the user Full control permissions on folder C:\BTS2010CertGuide\Chapter01\Example01-Messaging\FileDrop, shown in the following screenshot:

Next, we need to create an Application called BTS2010CertGuide-Ch01. In order to do this we need to carry out the following steps:

  1. 1. Open the BizTalk Administration Console.

  2. 2. Right-click on Applications and then click on New | Application:

  3. 3. Name the new Application as BTS2010CertGuide-Ch01 and click on OK.

Creating Receive Ports and Receive Locations

Now we need to create a Receive Port inside our new Application and add two file Receive Locations, one for each partner (A and B). Carry out the following steps in order to do this:

  1. 1. In the BTS2010CertGuide-Ch01 Application, right-click on Receive Ports and choose New | One-way Receive Port:

  2. 2. Name the Receive Port as CG0101_Receive and click on OK:

  3. 3. Right-click on Receive Locations and choose New | One-way Receive Location.

  4. 4. Select Receive Port CG0101_Receive and click on OK.

  5. 5. Name the location as CG0101_ReceiveFromPartnerA_FILE, choose FILE in Transport Type (adapter) and click on the Configure button, as shown in the following screenshot:

  6. 6. Configure the FILE adapter, as shown in the following screenshot and click on OK. (The Receive folder path is C:\BTS2010CertGuide\Chapter01\Example01-Messaging\FileDrop\PartnerA\Inbox):

  7. 7. Click on OK again.

  8. 8. Make another Receive Location from steps 3 to 7, name it PartnerB instead of PartnerA and choosing the PartnerB file folder instead of PartnerA.

In the Administration Console our Receive Locations should now look similar to the following screenshot:

Testing the Receive Locations

Now we need to see that everything is running as intended, by testing the solution:

  1. 1. Create a small text file and fill it with a few characters and copy the file into each inbox folder (PartnerA, PartnerB). The files must consist of at least one character as the FILE adapter will throw away empty messages, as they do not make sense in a BizTalk perspective. Do not give the files a name containing the phrase "Copy".

  2. 2. Verify that the BizTalk Host Instance executing the Receive Locations is running.

  3. 3. Right-click on each Receive Locations and choose Enable.

  4. 4. Check the Event Viewer and verify that no BizTalk Server errors have been written to Windows Logs/Application when enabling the Receive Locations. If errors are present, examine them as they are most likely caused by the BizTalk Host user not having sufficient permission in the folders (refer to the Creating Folders and Application section).

  5. 5. Go to C:\BTS2010CertGuide\Chapter01\Example01-Messaging\FileDrop\PartnerA\Inbox. Copy/paste the file into the same folder so that a copy is inserted, and confirm that BizTalk deletes the file. If the file is deleted by BizTalk, it means that our PartnerA locations are working. Do the same test for PartnerB.

Debugging the messages

Now let us examine what happened to the messages that we had submitted to BizTalk:

  1. 1. Open the Event Viewer again and we should find four errors (two for each message submitted).

  2. 2. Open the last error submitted in the Event Viewer, it should look something similar to the following screenshot:

What BizTalk is telling us here is that even though received processing of the messages was successful, the messages could not be routed, because there were no subscribers. In other words, no Send Ports or Orchestrations were created with a subscription matching the Context of the messages.

Now we will examine the Context of one of the messages that failed to be routed:

  1. 1. Go to the Group Hub, by clicking on the BizTalk Group folder in the Administration Console, and then press F5 to refresh the dashboard showing in the right pane.

  2. 2. We should now see four suspended items:

  3. 3. Click on the Resumable link. (The Non-resumable instances are not important right now. They are used internally by BizTalk, and will not make sense to look at until we start working with Pipelines). We should now see the following screen:

  4. 4. Double-click on one of the suspended items:

  5. 5. Choose the Messages tab, and double-click on the message:

  6. 6. Choose Context and click on Type until the promoted properties are shown on top.

  7. 7. Examine the five promoted properties. These are the only properties we can use for subscription for now. The best candidate for subscription might be the ReceivePortName with the value of CG0101_Receive.

Setting up a Send Port

Now we will make a Send Port that subscribes to all messages with ReceivePortName with the value of CG0101_Receive in the Context:

  1. 1. Create a new Send Port by right-clicking on the Send Port folder and choosing New | Static One-way Send Port.

  2. 2. Fill in Name and Type as shown in the following screenshot and click on Configure.

  3. 3. The FILE Transport Properties window will pop up. Fill in the Destination folder path (C:\BTS2010CertGuide\Chapter01\Example01-Messaging\FileDrop\SystemI\Outbox) and the File name as shown in the following screenshot. Click on OK:

  4. 4. Choose the Filters page. Select BTS.ReceivePortName in the Property drop-down list. Leave the Operator as == and type the Receive Port name in the Value textbox. (Note that string values should not be placed inside quotation marks) and click on OK:

  5. 5. Start the Send Port by right-clicking on it and choosing Start.

  6. 6. Submit a message from either Partner A or B.

  7. 7. Check that System I gets a file in its Outbox folder.

  8. 8. Go back to the Group Hub, choose the two resumable suspended items, right-click and choose Resume Instances. Click on Yes and then click on OK.

  9. 9. Verify that the two additional files are now in the System I folder.

Setting up Send Port for System II and a Send Port Group

System II also needs a copy of all messages received by the Receive Port. So instead of making two Send Ports with identical filters, we will make a Send Port Group with the subscription for the Receive Port name, and then add both Send Ports to the group:

  1. 1. Create a new Send Port for System II, the same way we created the first Send Port, with SystemII in its name instead of SystemI and also use the SystemII outbox folder instead. Do not give the new Send Port any filter. Start the Send Port.

  2. 2. Create a new Send Port Group, by right-clicking on the Send Port Groups folder and choosing New | Send Port Group...:

  3. 3. Give the group a name as shown in the preceding screenshot, and add the two Send Ports to the group.

  4. 4. Give the group a filter with the Receive Port name, just as we did with the first Send Port and click on OK

  5. 5. Right-click on the group and start it.

  6. 6. Submit a message from one of the partners.

  7. 7. Notice how System II got one message, but System I got two. This is because a Send Port inside a Send Port Group will have two subscriptions: its own as well as the group subscription. If both of them are met, the port will receive two messages.

  8. 8. Go to the System I Send Port, and remove the subscription inside the Filter page, by clicking on Delete and then on OK.

  9. 9. Test again; this time System I should only get one copy.

 

Implementing messaging patterns


When working with BizTalk, the design considerations are very important. A bad design might result in poor performance, difficulty in changing the solution if the surrounding environment changes, and redundant code.

Working with canonical messages

One of the design patterns that we should always try to meet (unless there is a good reason for doing something else) is the use of canonical messages inside BizTalk.

If BizTalk receives a message of type A and that message needs to be sent to another system and transformed to type B, instead of transforming directly from A to B, we should make up our own internal type not looking at the structure of either type A or B, but rather make a type of the message that is independent of both types (type I).

This will require two transformations, one from type A to type I, and another from type I to type B.

We should also make sure that only the canonical/internal messages hits the MessageBox, so the Map A to I should be applied on the Receive Port, and I to B on the Send Port.

This pattern has the following advantages:

  • If we receive messages from various partners/systems (type Ai, Aii, Aiii, and so on) and we Map all of these different structures to a canonical type on the receive side, then the target system (type B) could change structure or format. In this case, we would only have to change the solution in one place, the transformation from the canonical type to B.

  • If more subscribers are interested in the message, and we make transformations directly from message type A to all of the desired formats of the subscribers, and we start receiving the messages in other formats, we would again need to make transformations from the new format to each of the subscribers, instead of just transforming the new format to the internal format.

This is also the case when working with Orchestrations. Try not to use the Adapter-specific Schemas inside the Orchestrations. Instead use internal versions of the messages. Use these internal versions inside the Orchestrations and then Map from and to the internal Schemas in the Receive and Send Ports. By doing this, we do not have to recompile (let alone recode) an Orchestration if a message type on a Send or Receive Port was changed. The structure of the XML sent and received from the old and new messages would be different, but if we are only dealing with internal messages in our Orchestrations, only the Maps on the Send and Receive Ports would need to be changed.

De-batching

Another pattern we should try to implement, for most solutions, is the use of singular messages inside BizTalk. If we receive batches, such as several items inside the same message, we should de-batch them into individual items on the receive side of BizTalk (the Receive Pipeline).

The rule of thumb is that the solution should act in the same way if we receive one large file containing 10 orders, as it should, if we receive 10 orders in 10 files.

BizTalk cannot handle the items individually if they are kept as a batch through BizTalk. If we receive orders and some subscribers are only interested in orders containing a specific customer number, we would have no means (at least not with normal content-based routing) of subscribing to just those messages if all of them were kept inside a batch.

There are other cases where keeping multiple items inside a batch and not de-batching them makes sense. If a solution picks up a large batch of products, because full inventory is done once a day and all subscribers are interested in seeing these products as a whole inventory report, we should not try to de-batch them. Also note that as BizTalk comes with great de-batching functionality on the receive side there is no automatic way of batching these items again. If some subscribers need the inventory report as it was received and others need them individually, then we would need to keep the batch inside BizTalk, and then do some extra code (possibly using Orchestrations), to also make de-batched copies.

In other words, a de-batched message is not easily assembled again with the same items in the same order.

Using the correct flow

We often stand with a decision whether to use a one-way or request-response flow. The following table describes some of scenarios where it makes sense to use one over the other:

Direction

Type

Usage

Receive

Request-response

Used only if the caller submitting messages to BizTalk needs an answer back or if it is vital to the calling system to know that everything in the flow went well

Receive

One-way

Used for all other cases than the ones described in request-response

Send

Request-response

Used if BizTalk calls a system and needs an answer back from that system

Send

One-way

Used for all other cases

It is important not to use request-response when only one-way is needed. If calling a Web Service on a Send Port, it does not provide us with more reliability if we can use a request-response port, instead of a one-way port. The one-way port will, just like all other adapters, wait for the service to finish and the acknowledgement that everything went well until the message is removed from the MessageBox. Also, using request-response when not needed, will give us less performance and less flexibility, because a request-response message submitted to the MessageBox can only have one subscriber.

Adapter independence

When designing, whenever possible try not to make BizTalk solutions where code or logic is dependent on messages being received or sent using specific adapters.

It might seem like a good idea to send files to an FTP Server using the %SourceFileName% macro in the Target File Name property, because we want to give the target server the same filename as the file had when we received it either by file or FTP. If this is a requirement, then this is of course how the solution should be made. However, always try to focus on whether the solution will work if we change the adapter. If tomorrow we start receiving messages from both a file folder and also from an Oracle database, well then the %SourceFileName% logic on our Send Ports will fail to work for the messages received from Oracle, simply because no original filename exists.

On the send side, people also tend to hardcode specific adapter properties inside Orchestrations, which would result in a situation where changing the adapter type would require us to change and recompile Orchestrations.

 

Test your knowledge


  1. 1. HWLC Motors, is sending XML orders to our BizTalk server using FTP and BizTalk picks up the messages using a FILE adapter. All orders have been signed by the partner using certificates. We need to implement a secure solution where only orders from EAS Industry get through the processing inside BizTalk. If any orders with an unknown signature are received, we want to keep those messages as we would still assume they are valid. What certificate needs to be stored where for this to work in BizTalk?

    • a. Install EAS's public key certificate in the Current User/Personal store

    • b. Install EAS's public key certificate in the Local Machine/Other People store

    • c. Install our own private key certificate in the Current User/Personal store

    • d. Install our own private key certificate in the Local Machine/Other People store

  2. 2. We receive XML from several trading partners through Receive Port RP1. At times, the XML is not well formed, and the XMLReceive Pipelines throws errors and the messages are suspended. Our partner coordinator Brian has requested that invalid XML be sent to him in an e-mail, instead of being suspended in BizTalk. How would you achieve this? (Choose all that apply):

    • a. Set up e-mail alerting on the server if errors occur in the Event Viewer with BizTalk Server as the source.

    • b. Create a Send Port: SP1, using the SMTP Adapter and target it to Brian's e-mail address. Set up a filter on the Send Port with the following format: BTS.ReceivePortName == RP1 and (ErrorReport.ErrorType Exists).

    • c. Enable routing for failed messages on the Send Port SP1.

    • d. Enable routing for failed messages on the Receive Port RP1.

    • e. Create a Send Port: SP1, using the SMTP Adapter and target it to Brian's e-mail address. Set up a filter on the Send Port with the following format: BTS.ReceivePortName == RP1 and (BTS.FaultName Exists).

  3. 3. HWLC has several Send Ports that point to different internal systems. One of the Send Ports targets the company's ERP system. The adapter used is an HTTP Adapter. The ERP administrator wants to take the system offline for the next 24 hours, and no messages should be sent to the system during that time. How should we accomplish this with the minimum amount of interference with the other systems?

    • a. Disable all Receive Locations so that no messages are received in BizTalk for the next 24 hours

    • b. Stop the ERP Send Port and start it again when the system comes back online

    • c. Unenlist the ERP Send Port and start it again when the system comes back online

    • d. Stop all in-process BizTalk Services

  4. 4. HWLC receives XML from an FTP site using a standard FTP Receive Adapter. The messages received are of type: http://namespace#Root. You set up a Send Port with the following filter: BTS.MessageType == http://namespace#Root. The schema for the message type is also deployed. You start your Application and the Receive Location starts receiving messages from the FTP site. However, no messages are sent through the Send Port, and when examining the Event Viewer, you realize that you get the following error: The published messages could not be routed, because no subscribers were found. You examine the Context of the messages suspended and realize that the message type is not Promoted. What should you do?

    • a. Write a custom Pipeline component that promotes the message type.

    • b. Enable Failed Message Routing on the Receive Port and change the filter on the Send Port to ErrorReport.ReceivePortName == [Name of Receive Port].

    • c. Change the Pipeline on the Receive Location from PassThruReceive to XMLReceive.

    • d. Create an Orchestration that receives XMLDocument messages and bind it to the Receive Port. Finally, have the Orchestration send the message to the Send Port.

  5. 5. You are receiving messages from customers sending mails with attachments through an Exchange Server 2010. You want BizTalk to process the messages. How should you approach this?

    • a. Use the FTP Adapter to receive messages from the exchange server

    • b. Use the FILE adapter to receive messages from the exchange server

    • c. Use the POP3 Adapter to receive messages from the exchange server, and set the body part index to 0

    • d. Use the POP3 Adapter to receive messages from the exchange server, and set the body part index to 1

 

Summary


This chapter has dealt with some of the basics of BizTalk, looking at the subscription engine, Ports, and Adapters. You should now have a basic knowledge of how BizTalk works, and how to navigate through the Administration Console. Next, we will look at XML, Schemas, Pipelines, and start using Visual Studio.

About the Authors

  • Johan Hedberg

    Johan Hedberg is based in Stockholm, Sweden, where he does consultancy, solution architecture, training, mentoring, speaking, and authoring. Johan has 15 years of experience architecting and developing enterprise-grade solutions based on Microsoft technologies. He works closely with Microsoft as a Virtual Technology Solution Professional (V-TSP) and with the community as a Microsoft Most Valuable Professional (MVP), and is one of the founders of the BizTalk User Group Sweden. He blogs irregularly at http://blogical.se/blogs/johan and can be found as @JoHed on Twitter.

    Browse publications by this author
  • Kent Weare

    Kent Weare was born in Regina, Saskatchewan, Canada. He developed a love for ice hockey, football, and technology. He attended the University of Regina, where he obtained a Degree in Computer Science. After completing his undergraduate degree, he spent time in India completing a Post Graduate diploma in Object Oriented Technology. Recently, Kent has decided to pursue a Master's Degree in Information Management from Arizona State University. He currently lives in Calgary, Alberta, Canada but remains a die-hard Saskatchewan Roughrider football fan. Kent began his career at a small Internet startup before taking on a junior role with the Saskatchewan Government. Since then, he has worked on projects for the Canadian Federal Government, a multinational bank in the United States, health care projects in Eastern and Western Canada, and has spent the last eight years employed in the Energy/Utilities sector in Calgary. Kent's current role as a senior enterprise architect involves setting the technical direction for the organization and is very involved in cross-domain disciplines such as Integration and Mobility. During Kent's time at the Federal Government, he had an opportunity to participate in his first BizTalk project. Ten years later, he is still "hooked" on BizTalk, having worked with every BizTalk version released since then. In 2008, Kent was awarded his first Microsoft MVP award for BizTalk Server. He continues to be active in the BizTalk community and recently, received his sixth consecutive MVP award. Kent maintains active blogs at http://kentweare.blogspot.com and http://www.MiddlewareInTheCloud.com. He may also be seen presenting BizTalk-related material at local and international user groups. Recently, Kent has co-authored two BizTalk books: Microsoft BizTalk 2010: Line of Business Systems Integration and (MCTS) and BizTalk Server 2010 (70-595) Certification Guide.

    Browse publications by this author
  • Morten la Cour

    Morten la Cour has worked with the MS BizTalk Server platform for nine years. Besides designing and developing Integration solution for customers, he has also worked on deployment and maintenance of BizTalk applications and BizTalk Server environments. Starting in 2011, he is also working with Windows Azure, Azure Service Bus, and the new Windows Azure BizTalk Services. He has taught several BizTalk Server courses in development, deployment, and management. Besides working with MS BizTalk Server, Morten has 15 years of experience on the Microsoft development platform, including the .NET Framework and SQL Server. Other experiences include XML, XSLT, XPATH, and Oracle databases.

    Browse publications by this author
Book Title
Access this book, plus 7,500 other titles for FREE
Access now