Chapter 4

In this screenshot, we can see the query expression that was used to build this
specific view. The query tool itself consistently follows the same pattern that
allows us to select: Search For, Operator, and Value. Depending on what we select
in Search For, the options for Operator and Value change. Mostly, the option for
Operator is Equals, but for time based values like suspension time, greater than
and less than operators are available for using with a date and time based value.
Other Search For options will list specific sets of values to choose from; some
allowing free text entry. This tool is used to help us create queries that display
views we may specifically be interested in. We can save queries for later use to
help in troubleshooting specific issues.

If we right-click on one of the results of the query, a context menu appears; this menu
also changes depending upon the context of the selected item. For messages, the
menu appears as follows:

[ 109 ]
Operating BizTalk

Here we can see details about the message, including its content and context, as
well as having the option to resume or terminate the message. For orchestrations
in this results pane, an option Orchestration Debugger is present that allows us to
graphically trace through an orchestration to see which shapes were executed and
when. This can be a very useful tool for debugging issues with orchestrations, but
should be used sparingly.

This same query tool allows us to view tracked service instances and message events.
This capability, formerly done through the Health and Activity Tracking tool (HAT),
which has since been largely retired, allows us a window into the past processing
activities that have taken place in a BizTalk group. As we discussed previously,
BizTalk, by default, internally tracks a great deal of information on what processing
has taken place in the DTA database. On any port or orchestration, we can specify
what level of detail we want to track down to complete a message- or property-
level detail before and after pipeline processing. This can be turned on or off by an
administrator in the BizTalk Administration console through the Tracking tab of the
configuration for a specific port or orchestration. This capability greatly aids us when
we start experiencing issues and can be performed in any environment, including
production. That said, there is a cost to overusing tracking information. The DTA
(tracking) database will grow extremely large if we track too much detail for too
many service instances. This will also impact the throughput of our environment
by causing more database writes and general IO operations. As useful as this
tracking information is, it should be used sparingly. If we want visibility into
processes, Business Activity Monitoring (BAM) is a much better approach than
tracking information.

Summary
In this chapter we have learned how BizTalk runs on servers in our environment
and the different roles and servers required for building scalable and reliable BizTalk
installations. We learned about scalability and high availability, as well as disaster
recovery. We also examined sample topologies and their benefits and requirements.
We ended with some configuration best practices and a brief introduction to
troubleshooting issues in BizTalk Server. This concludes Part I of the book.

[ 110 ]
Part 2
Basic Messaging Solution

Unit Tests and BAM

Leveraging Orchestration

The WCF-SQL Adapter and

WCF Services

Expanding the Solution with Services

and Rules

Envelopes, Flat Files, and Batching

Completing the Order

Processing Solution

Asynchronous Solutions

Performing Parallel Processing

and Branching

Processing Message Convoys

 Part 2
The rest of the book will cover the story of Performance Racing Parts (PRP); a
company just beginning to use BizTalk Server. PRP is a distributor of car and
motorcycle aftermarket components. The company has been around for thirty years
and has experienced rapid growth in the last ten. PRP sells parts via its own call
center application and a public facing website. PRP also receives sales through a
mail order catalog that is outsourced for processing. PRP recently purchased an
inventory management system and is currently assessing how to integrate it into
their enterprise which contains a CRM system. Eventually all purchase orders must
be sent to the new inventory management system for processing. As a stop gap,
orders today are entered a second time manually. The company assessed integration
and middleware products and has decided to try out BizTalk Server. You have been
tasked with implementing their solutions.
 Basic Messaging Solution
This chapter will walk through the first BizTalk solutions for Performance Racing
Parts (PRP). These solutions will be messaging only, but leverage useful and
expressive designs.

Pass thru messaging scenario

The IT Director at PRP decides that a quick and simple project with low risk is the
best path forward with BizTalk. You review the project backlogs and find a request
by the finance department to consolidate reports from the different ordering systems
in the enterprise to a single file share. Currently, this is a manual job that often loses
reports and takes time from IT staff to copy files; aspects that make it disliked by
IT as well as finance. Initially, the idea was to write scheduled task scripts to copy
the files, but you decide that BizTalk can do this as well. Further, this process can
change and may use SharePoint or FTP in the future, so the company would prefer
a configuration approach over a code-based approach.

You must create a simple BizTalk solution that will receive binary files from two
directories and copy them to a single destination. One directory is for call center
order reports; the other is for website order reports. As this project is a pass thru
messaging solution it will only involve using the BizTalk Administration Console:

1. Open the BizTalk Server Administration Console (Start | Programs |

Microsoft BizTalk Server 2010 | BizTalk Server Administration Console).
2. Expand the BizTalk Group node.
Basic Messaging Solution

3. Right-click the Applications node and select New | Application….

4. Name the application Order Processing.

5. Expand the new Order Processing application, right-click the Receive Ports
node, and select New | One-way Receive Port…. Name this new port
OP_Receive_Reports and click OK when done. The naming convention
follows the basic pattern [Application]_[Direction]_[Noun]. This will help us
organize the artifacts in this solution over time. More information is provided
in the appendix under Naming Conventions.

6. Click the Receive Locations item on the left side of the Receive Port
Properties dialog that you just created and click New… on the right side.
Name this receive port OP_File_Receive_Reports_CallCenter and select File
as the transport type.

[ 114 ]
 Chapter 5

7. Be sure not to change the Receive Pipeline. It should remain the default
PassThruReceive.
8. Click on the Configure button and set this new location to point to the
pickup folder C:\BizTalk\PRP\CallCenterReportDrop with a File
mask of *.* as shown in the following screenshot:

9. Click OK to close each of the dialogs.

We now need to create a send port that will send the files to our destination location,
which is very similar to the receive location we just set up.

1. Right-click Send Ports in the Administration Console and select New |

Static One-way Send Port.

[ 115 ]
Basic Messaging Solution

2. Name this send port OP_File_Send_Reports and select FILE as the Type.
Click on the Configure button and set the transport properties so that the
destination folder is C:\BizTalk\PRP\SendReports and the file name is
%SourceFileName%; the port should resemble the following screenshot:

3. Now we must connect our Receive Port to our Send Port. This is done via
Subscription and the simplest form of subscription is the Send Port Filter.
This type of filter, as the name suggests, is configured on the send port itself.
On the left side of the Send Port Properties dialog click on the Filters node.
Then click on the Property column to select a property to filter by. You
|will notice there are many properties, but we are only interested in the
BTS.ReceivePortName property. Keep the default operator of == and type
in the Value of OP_Receive_Reports. This is the name of the receive port we
created before and will be used to connect the two ports together.

[ 116 ]
 Chapter 5

4. Click OK to close the send port configuration dialog.

5. Finally, we need to start these ports in order for messages to flow through.
The easiest way to do this is to right-click the Order Processing application
in the Administration Console and select Start.

6. Accept the default properties in the next dialog and click Start.

You should now be able to drop any file in the receive location (C:\BizTalk\PRP\
CallCenterReportDrop) and it will be routed to the send location (C:\BizTalk\
PRP\SendReports).

If this does not immediately work, the most likely cause is that the user account
under which the BizTalk host instance is running does not have permission to either
receive or send paths. If you have not already done so, grant this user Full Control to
C:\BizTalk\PRP.

The File Receive adapter will need a specific permission that is

part of the Modify set of rights, but is not granted by default;
this is the Delete Sub Folders and Files option, which can be
granted in the Advanced tab of Windows Explorer. It is simply
often easier to grant Full Control.

The second most common cause will be if the subscription is not entered correctly.
This is where typos can cause some headaches in BizTalk. To see if the message has
suspended you can refer to Chapter 4, Operating BizTalk.

[ 117 ]
Basic Messaging Solution

Examining the solution

Let's review exactly what's happening at this point in this solution. This is explored
in detail in Chapter 2, Introduction to BizTalk Development, but we'll summarize here
for convenience:

1. Message (File) is received as raw binary by file adapter.

2. Message is submitted to message box.
3. A subscription matched for send port OP_File_Send_Reports on messages
from received port named OP_Receive_Reports.
4. The subscription is filled (that is, work item queued) for send port OP_
Receive_Reports which retrieves the work item and uses the file adapter to
write out to the file system as raw binary.

At first glance, this may seem like it was a lot of steps, but we didn't write any code
or have to do any extra work to get reliability, locking (concurrency), persistence,
high availability/scalability, and tracking. These are all features that come as part of
the BizTalk platform and did not require custom code.

Now let's see how much more work it is to add another receive location to handle the
web sales reports.

Adding a second receive location

Right-click Receive Locations in the BizTalk Administration Console (under the
OrderProcessing application) and select New | One-way Receive Location.

1. You will be presented with a list of Receive Ports to attach this receive
location to (this is required, as there can be no orphan receive locations).
Select the only Port in the list OP_Receive_Reports and click OK.

2. In the Location Details dialog that pops up, enter the name OP_File_
Receive_WebSiteReports. Configure the receive location transport type to
FILE to read files from C:\BizTalk\PRP\WebSiteReportDrop much like
we did before. Use the same mask, *.*, as before and be sure to leave the
PassThruReceive pipeline.
[ 118 ]
 Chapter 5

3. When you click OK you will see the list of receive locations in the
Administration Console. You will notice that the new location is disabled
so you must enable it (which can be done by right-clicking the location and
selecting Enable).

You should now be able to drop files in either location and they will be moved to the
destination folder.

You may be asking yourself 'Why all this just to move some files, why not use a
script'? at this point. That's a good question, so let's address some of the motivations.
Suppose you wanted to change from file shares to FTP sites. All you would do is
change the transport type in your send port or receive locations. Perhaps you want
the reports to be sent to a SharePoint document library or maybe an iSeries server.
This is also not a problem; these are just other adapters (equating to transport types).
Not even routing (that is, filtering) changes pose a problem and are in fact activities
that can be performed by operations staff if need be. This decouples the creator of the
application from the operator of that application.

Transport properties
At this point, it is worth exploring some of the other advantages we have over
scripting or other common solutions to this trivial example. First let's look at some of
the Send Port Properties; do this by right-clicking (or double-clicking) the send
port OP_File_Send_Reports. There is a screenshot of these properties after the
next paragraph.

We can see under the Transport Advanced Options that we can set the Retry
Count, Interval, and other settings. Importantly, we also see a setting for a Service
Window. This is a setting that will control when BizTalk will send messages on
this port. Outside of the service window, messages will simply queue up in the
message box to be delivered when the service window is reached. This allows us to
address another aspect of coupling: time. Time is perhaps one of the most insidious
forms of coupling. It is usually not a thought in our solution development. Our
test environments and workstations are always running when we are using them.
Normally this sort of dependency rears its head in production or late in testing. Even
in this trivial example we are able to resolve this without changing our solution or
writing any code.

[ 119 ]
Basic Messaging Solution

Sending applications drops the files in the receive locations, and they do not care that
the destination is down. They do not need to care because they are decoupled from
the process.

We can also specify a backup transport to use in the event of failure of the primary
transport. This backup transport will become active after the primary transport fails
(that is, its retry count has been exceeded) and it has its own retry count and service
window settings. We are completely free to use a different transport type altogether
such as FTP. This feature can be used to provide automatic failover or even instant
failover by setting the retry count on the primary transport to zero.

[ 120 ]
 Chapter 5

The receive location has similar settings that can be used to provide service windows
as well. In the receive context, a service window simply stops the receive location
from trying to pick up messages. Providing these capabilities in a script would
be much more difficult. You would quickly exceed the amount of time we spent
creating this solution and it would still not be as robust.

Although this lesson is intentionally trivial it should be pretty clear how flexible
BizTalk can make even a simple solution. Flexibility, after all, is one of the primary
motivations for using BizTalk. Now let's take a quick look at exactly how this
solution works in detail.

[ 121 ]
Basic Messaging Solution

Basic subscriptions
Click the BizTalk Group node in the Administration Console (above Applications).
You will see a Group Hub tab that gives you an overview of the group and a tab
called New Query. Click on the New Query tab. This allows us to query the BizTalk
server for a variety of information; in this case we will select Subscriptions.

We can then further refine our search by using the Subscription Type field
and selecting the value Activation Subscription. Activation subscriptions are
subscriptions that are used to initiate a service. Services can be either orchestrations
or send ports. This is an important distinction because it shows that there is a
marked difference between receiving and doing (read sending) in BizTalk. The
other subscription type option, Instance Subscription, is for service instances
that are already active and awaiting another message.

By clicking the Run Query button, we can see the list of results returned. At
the top of this list will be our most recently added subscriptions: the send port
OP_File_Send_Reports is the one we are interested in. From returned list itself
we can see some summary information about the subscriptions.

[ 122 ]
 Chapter 5

Right-clicking anywhere in the results allows us to see our command options:

Subscription Details (the default double-click handler) and Add/Remove Columns,
which is self-explanatory. This behavior is typical of the BizTalk Administration
Console query tool and the columns to be added are unique to the specific view
of the query (driven by the Search For criteria).

This allows operators, administrators, and developers to create unique views into
BizTalk applications to facilitate their respective roles. These queries can then be
saved as .btq files by right-clicking the tab at the top of the query and sorted by
clicking any column header. More about the query tool in the BizTalk Administration
console was covered in Troubleshooting BizTalk issues in Chapter 4, Operating BizTalk.
Double-clicking the OP_File_Send_Reports entry will allow us to see its details.

[ 123 ]
Basic Messaging Solution

The Expression tab shows us the details of the subscription itself and here we can
see the subscription that we entered earlier (plus some bits that BizTalk has put
in for us).

You will notice that these subscription details are read only, but this is a very
useful place to find why messages aren't routing the way you expect. You would
be surprised how easy it is to type a subscription incorrectly.

If we were to go back to our send port OP_File_Send_Reports and stop it, then run
the subscriptions query again, we would see its state listed as Stopped under the
General tab that we looked at in the previous screenshot. If we were to go unenlist
that send port, the subscription would disappear from the Activation Subscriptions
query altogether. This should help to drive home the point that BizTalk operates on
a publish-subscribe model that is highly expressive. Subscriptions are only present
when they are enlisted and only active when started. If you have a send port, but it
is not enlisted, the messaging engine doesn't actually know it exists. When ports are
stopped (or enlisted, but not started) the messaging engine will see them and will
queue messages for them. This is similar to the service window concept we
saw before in the port configurations.

Simple XML messaging with maps

After the success of the report collecting solution, the team decides it's time to
develop a real solution with BizTalk. The call center application team have already
developed an XML export for purchase orders that occurs in real time. They
decided to write out an XML file containing the purchase order when it is saved to
their database. These files need to get to the fulfillment system, which came with a
purchase order import capability that uses XML files. The two file formats do not,
however, match.

[ 124 ]