The Upcoming End of Extended Support for BizTalk Server 2006

In July, Microsoft ended all support for BizTalk Server 2004. This got us to thinking about the looming end of support for other versions of BizTalk Server: mainstream support for 2006 and 2009 has already ended, and extended support for 2006 (and R2) ends in July 2016:

According to Microsoft, extended support differs quite a bit from mainstream support, including:

  • No non-security hotfixes
  • You will be charged for incident support requests
  • No warranty claims
  • No design or feature change requests

Our new BizTalk Server Administrator Deep Dive course covers the skills your team needs to assess and upgrade your infrastructure. View our upcoming advanced BizTalk Server administration class schedule:

Date Duration Location
Sep 29 5 days Kirkland, WA (+ Remote)
Nov 03 5 days Utrecht, Netherlands
Nov 17 5 days Kirkland, WA (+ Remote)

Top 5 Indicators of the BizTalk Server 2013 Community’s Vitality

This post is the twenty-fourth, and final, in a weekly series intended to briefly spotlight those things that you need to know about new features in BizTalk Server 2013.

For my final post in this series, I wanted to highlight something that is not part of the core on-premise product, or even a part of Windows Azure BizTalk Services. Honestly, it was a struggle trying to figure out what to close out this series on. I had debated ending with the coverage on WABS, the code-sample heavy posts on REST, or even an end-to-end build-out of a solution using the new SharePoint adapter. Instead, I am going to focus on something which really causes BizTalk Server 2013 stand out from the rest, and is born out of its lengthy history as Microsoft’s flagship integration platform – the BizTalk Server 2013 Community.

So without further ado, I would like to present, the Top 5 Indicators that the BizTalk Server 2013 Community is thriving now more than ever.

Expanded Community of Bloggers

It has been exciting over the last few years to see more people get involved with blogging about BizTalk Server. The ESB Toolkit, specifically, is something near and dear to my heart, and I’m seeing consistently great things related to the Toolkit coming from people like Tomasso Groenendijk, and Colin Meade on their respective blogs. It’s especially cool, though, to see blogs specifically dedicated to BizTalk Server Administration– as with Tord Nordahl’s blog.1 If you ever want to be inspired and feel like a small part of a much larger community, just read through either Richard Seroter’s 4 question series, or Steef-Jan Wiggers’ BizTalk Community Series.

New Community Sites

Lex Hegt has done some pretty interesting work lately for the BizTalk Server Community, but he’s not taking any credit in the process. Just last year he launched which aggregates event schedules from BizTalk Server user groups and training classes from all over the world. It also features a presentation archive organized by date and event, complete with slide deck downloads.

EDIT: Michael Stephenson also pointed out that another interesting initiative that has come about during this latest round of BizTalk Server offerings is the BizTalk Maturity Assessment, which helps organizations determine their level of maturity across a variety of different areas, and then use the results of the assessment to grow those areas in which they need work.

Robust Third-Party Products

houstonmissioncontrol Since BizTalk Server is often used to build mission critical systems, it has tended to attract fairly high quality third-party products. This generation of 3rd party products entering the BizTalk Server 2013 ecosystem is certainly raising the bar though for quality and innovation. One really only needs to look at the latest (currently in Beta) version of Kovai’s BizTalk 360 headed up by Microsoft Integration MVP Saravana Kumar. Fresh out of the trappings of Silverlight, and into the land of HTML5 goodness, BizTalk 360 is augmenting the BizTalk Server Administration Console with something that would make even Houston jealous.

The TechNet Wiki

Every time I go to the landing page for BizTalk Server articles on the TechNet Wiki, I wonder to myself what percentage of the overall wiki is comprised of articles about BizTalk Server. Countless community contributors and careful curating by contributors like Steef-Jan Wiggers, have grown this free-form body of knowledge into a treasure trove of information about all versions of BizTalk Server – including pointers to the edges of the BizTalk Server Community itself.

The BizTalk Summit

Finally, if you want to see the BizTalk Server community thrive, go to one of the BizTalk Summit events. Hosted by Microsoft, these are special events where the community can come together, meet each other, swap battle stories, and bond over the shared love of bringing systems together. Last year, I had the opportunity (along with Rob Callaway, John Callaway, Chap Phillips and Paul Pemberton of QuickLearn) to bring some hands on labs to life, showing both Salesforce integration and an early peak at the EDI capabilities of WABS. I’m hoping to be a part of bringing even more this year – especially now that we have a platform for easy setup of such labs in Azure.

Registration is open for the summit right now, so don’t miss it!

The End?

While this post does mark the end of my series on the new features in BizTalk Server 2013, I’m not going to pack up my mouse and keyboard and call it a year. We’ll keep this space up to date with interesting tidbits that come up along the way. Some of it will be new stuff, some will be written responses to frequent questions that come up in class – but hopefully all of it will be adding value to the BizTalk Server community as a whole.

Take care until next time!

– Nick Hauenstein

1 If you’re ever stuck at a conference with people you don’t know, go find Tord and he’ll talk to you as if you were his best friend and keep you entertained in the process).

BizTalk Server 2013 Ordered Delivery Improvements

This post is the twentieth in a weekly series intended to briefly spotlight those things that you need to know about new features in BizTalk Server 2013.

Almost buried in the middle of the new features list, you will find that for those in the healthcare industry, Microsoft has finally delivered on a longer-term ask in the form of improvements to the handling of ordered delivery in BizTalk Server 2013. The ask was for better performance when using the MLLP adapter, but in reality – anyone who relies on ordered delivery with more than a single Send Port can benefit and see anywhere from 300-500% better performance.

This is the glimpse into the improvement that we get from the What’s New article:

In previous BizTalk versions with scenarios where ordered delivery uses multiple endpoints, the slowest adapter type is the maximum speed. This behavior directly impacts HL7 solutions. When using the MLLP adapter, acknowledgements (ACK) are required. Delays can occur because an ACK must be received before the next message is sent.

In BizTalk Server 2013, the next message can be sent without waiting for an ACK from the previous message. When the ACK arrives, it is internally correlated/connected with its message.

What was the Problem?

If you spend some time snooping around the blogs on MSDN from those involved in BizTalk Server development, you are likely to come across this post (back from when BizTalk Server 2013 hadn’t yet been christened 2013).

The post explains that in previous versions of BizTalk Server, whenever a host had a set of messages queued up and ready for delivery, if the first one was destined for an ordered Send Port, then the Host would be blocked until delivery of the message was successful (regardless of available threads, or other non-ordered Send Ports).

So what is the fix?

In the 2013 version of BizTalk Server, instead of relying only on the Host Queue, and blocking all messages that follow an ordered message, each Send Port with ordered delivery enabled is dedicated its own thread within the Host Instance, and messages sent to those locations will not block any other Send Ports that also have messages ready and waiting.

How Do I Take Advantage of This New Functionality?

That’s the really beautiful part about this feature; it’s built into the Messaging Engine. There is nothing special that you have to configure to enable this behavior, no code that you have to write – it’s just there and better by default. The only thing to keep in mind, is that since each ordered send port is dedicated its own thread, you may want to go to the BizTalk Settings Dashboard, and ensure that the  Messaging Engine Threads is appropriately configured to accommodate those Send Ports along with any other work that the Host has been assigned.

Best BizTalk Server Version Yet

If you haven’t made the move to BizTalk Server 2013 yet, or at least explored the evaluation to see what it has to offer, I would strongly encourage you to do so. Of course, if you want some dedicated hands-on time and instruction at the same time, I highly recommend our completely overhauled BizTalk 2013 Administrator Immersion class.

That’s all for this week. I’m back in the saddle after spending some time on vacation, so I will be back again next week. Until then, take it easy!

BizTalk Server 2013: Discovering Dependencies

This post is the eighteenth in a weekly series intended to briefly spotlight those things that you need to know about new features in BizTalk Server 2013.

This week, I have decided to spotlight a simple feature that probably won’t be readily noticed unless you know it’s there, and you’re looking for it: Dependency Tracking1. This feature can prevent you from being yelled at by a dreaded 4-6 line error dialog, or other unforeseen consequences, providing you check dependencies before removing or redeploying an artifact.

the New Dependency Statistics Panel

If you have spent very much time in the new BizTalk Server 2013 Administration Console, you may have noticed that there is a new panel that shows up along the bottom:


If you’re anything like me, then it probably took you a while to figure out how to make this panel display information. As you can see, it hangs out at the bottom of the screen devoid of content by default.

In order to get those statistics, you have to access the context menu of the artifact that you’re interested in, and then click View Dependencies:


This will populate the two sections of the panel with (1) number of items that depend on the artifact, and (2) the number of items that the artifact depends on:


Clicking on one of these numbers will take you to the matching items with a breadcrumb to bring you back into context:


While none appeared while viewing the Orchestration dependencies, the items may include Schemas, Maps, Pipelines, Orchestrations, Receive Locations, Receive Ports, and Send Ports (e.g., below where we have Receive Locations / Maps in play):


Discovering Dependencies Not Found in the Binaries

As you continue to drill-down and view dependencies of each item, you will see the bread crumb update with the dependency chain. Here I can see that the original Orchestration I was examining ultimately depends on the JsonReceive pipeline (due purely to configuration in this case):


The Little Things

This is one of those little things that I have not yet had to make heavy use of, but I can see how it will bring value while tearing through more complex integrations trying to make heads or tails of what’s really going on.

If you want to try this out for yourself and get a glimpse of the Admin experience in BIzTalk Server 2013, come join us in October, November, or December for our BizTalk 2013 Administrator Immersion class.

1 Interestingly enough, this is the first feature highlighted in a similar series that Nitin Mehrotra has been running on his blog.

Publishing a WCF Service via Service Bus Relay in BizTalk Server 2013 (Part 2)

This post is the eighth in a weekly series intended to briefly spotlight those things that you need to know about new features in BizTalk Server 2013. It is also the second part of a two-part series on the Service Bus Relay features in BizTalk Server 2013 (Click here for part 1).

Last week, we examined how BizTalk Server 2013 (and even 2010 in that case) can use the Windows Azure Service Bus Relay to make a service endpoint available in the cloud without otherwise directly exposing the machine, and while being able to take advantage of the claims-based authentication and authorization framework provided by the Access Control Service. This was done in such a way that the service was hosted in IIS rather than within an In Process BizTalk Host Instance. This week, we are going to look at the other side – a service endpoint that is ultimately hosted in IIS.

In this case, we have been provided with a few new adapters to help us along the way (although, if we were really adventurous, WCF-Custom could have still done the trick for us in the past). These two adapters are the WCF-BasicHttpRelay adapter and the WCF-NetTcpRelay adapter:


Last week, we published a NetTcpRelay endpoint that required some additional work on the client to authenticate with the service. This week, we’re going to go to the other extreme, and publish a WCF-BasicHttpRelay endpoint that will be more or less transparent to the client.

Starting the Game of Telephone

We’re going to start out with the BizTalk version of Hello World, a simple (technically unnecessary, but convenient for illustrative purposes) orchestration. This orchestration receives a simple single node XML message (the single node containing the text “Hello”), and returns a simple single node XML message (containing the word “World”) as the response:


The Setup

With this, we’re going to go through the typical process of creating an in-process receive location, and then walk through the BizTalk WCF Service Publishing wizard to publish the service. Then we’re going to consume the service as it sits. Once that is complete, we will change up the end point so that it is listening over a Service Bus Relay, and see that the client can still call the service.

We’ll start with the Receive Location. In order to keep this in-process, we’re actually using the WCF-Custom adapter (since WCF-BasicHttp will force us to an Isolated Host):


Now that we have an endpoint to receive messages, we need to create an endpoint that informs clients what messages we’re even interested in – our MEX endpoint. For that, we will go back to the BizTalk WCF Service Publishing wizard, and select the second option – the path less traveled:


We will walk through this wizard, ignoring everything that mentions Service Bus publishing for now. Ultimately, what we will end up with is a local endpoint that is exposing the WSDL necessary to consume the service. We can use the svcutil.exe utility to download and share this metadata offline, or even generate proxy classes for re-use later if we’d like. In this case, we will be consuming it in place, and generating a client that can be used to call the service no matter where it lives.

Since we started with an orchestration, and that will define the shape of the incoming/outgoing data, we will select the Publish BizTalk orchestrations as WCF service option. Do note the plural orchestrations in that sentence, I see way too many single operation services out there. Winking smile


After browsing for and selecting an orchestration, you should be presented with a list of all public port types within the assembly containing the orchestration. If they Type Modifier property on the Port Type is not set to public, it will not be listed, and you will be sad:


After you click through a few more screens, you will be prompted for the location where you would like this metadata hosted. In this case, it will be hosted within IIS on the local machine:


A few more clicks through the wizard, and the MEX endpoint is created and hosted in IIS – though the service endpoint itself is still hosted in-process.

A visit to IIS manage demonstrates that the MEX endpoint is now:


Consuming the Service

So far, we haven’t really done anything earth shattering, so consuming the service is equally simple. In this case, I just fired up Visual Studio, used the Add Service Reference context menu option in Solution Explorer, and then provided the MEX endpoint to the wizard. With the (local, not relayed) Service Reference in place, I added the following code to my console app:

using System;

namespace QuickLearn.WCF.Client
    class Program
        static void Main(string[] args)
            var client = new IOServiceReference.WcfService_QuickLearn_BizTalk_ProcessClient("BasicHttpBinding_ITwoWayAsync",

            var response = client.ProcessMessage(new IOServiceReference.InOutRequest()
                 Contents = "Hello"



In the code above, the only moderately odd thing that I did was to use an overload of the client constructor that included an endpoint address. The reason for that was so I could more easily demonstrate the only change necessary as we switch to the WCF-BasicHttpRelay adapter.

To the Cloud

Since my client code is currently working and happy, I am ready to move this to the cloud. I am actually going to maintain my local endpoint (Receive Location) as well and simply add another Receive Location that will open the relay. The configuration of this one will be a little bit different, and certainly more involved.

NOTE: Before you continue, please be sure that you have read part 1.

I’m going to re-use my Azure Service Bus namespace from last week (though I have a new key for this week). I will start by creating a new receive location, selecting the WCF-BasicHttpRelay adapter, and then opening the adapter configuration. The first thing I am prompted for is the listen URI for the endpoint. This URI must incorporate my Service Bus Namespace, and should also add some identifier for the service after:


The only other page of the configuration that I must visit is the Security page. This is where I get to determine if the client needs to provide some sort of authentication information in order to invoke the service, if the existence of the service is going to be discoverable by hitting the root of the namespace, and this is also where I set the authentication details for the access control service – so that BizTalk can prove to Azure that it can listen at that address and receive messages.

Since we don’t want to make changes to our client (other than the endpoint address), we will set the client authentication type to None. Then we need to click Edit under Access Control Service to bring up this dialog:


In this dialog, we need to re-iterate our namespace (leaving the –sb suffix in-tact), and then then we also need to provide our super secret key which we can look up through the Azure Management Portal (see the previous post for details).

Once that is all in place, we’re set to Enable our Receive Location and then update the client to point to the relay.

Updating the Client

I mentioned before that we really only want to update the endpoint in the client. While this is true, the change of endpoint does (in this case) require a single simple change in configuration. The reason has nothing to do with the Service Bus Relay itself, but instead the change of scheme from http to https. An http address does not imply any security added in by the transport, it is just clear text over the wire. An https address, on the other hand, implies transport level security, as a result we need this small tweak to the otherwise auto-generated config file:


And then an update to our endpoint in code (everything else remains):

using System;

namespace QuickLearn.WCF.Client
    class Program
        static void Main(string[] args)
            var client = new IOServiceReference.WcfService_QuickLearn_BizTalk_ProcessClient("BasicHttpBinding_ITwoWayAsync",

            var response = client.ProcessMessage(new IOServiceReference.InOutRequest()
                 Contents = "Hello"


This gives us the very happy result:


Clearly this is one of the most robust, secure, and complex ways to write the word “World” out to the console.

The Take-away

The take-away here for the last two posts is that BizTalk Server 2013 gives you some new options for exposing select endpoints over the internet without touching firewall configuration, without involving IIS (if you don’t want to involve it), and without exposing the whole box out to the internet. All the while giving you the ability to work with clients that are aware of the setup (in the case of the NetTcpRelay) or are blissfully ignorant of the magic behind the scenes (in the case of the BasicHttpRelay).

A Brief Tour of the BizTalk Server 2013 Evaluation Windows Azure Virtual Machine

This post is the sixth in a weekly series intended to briefly spotlight those things that you need to know about new features in BizTalk Server 2013.

In this blog post, I’m going to take a little bit of a departure (for this week only) from the tone of my earlier posts – which focused on scenarios you will encounter after using the product – and look instead at things that would be of interest to people who are new to product, or are still evaluating BizTalk Server 2013 as an option for enterprise integration.

By far the quickest way to get started with BizTalk Server 2013 is to be handed a machine that has it pre-installed. With the Infrastructure-as-a-Service offering in BizTalk Server 2013, we have just that. In fact, we have it both for production as well as evaluation use.

Just Give Me a VM

While attending “//build/” this week (quick shout-out to those also here), I spent some time in the big room next to the Windows Azure booths. They had 3 challenges for attendees that involved completing certain tasks using the platform, and were offering a prize for each challenge completed. They were designed to sound somewhat difficult, yet prove to the participant just how easy life can be with Windows Azure. The first challenge was to provision a virtual machine running Windows Server 2012 — a trivial task (like it should be).

Well guess what? Provisioning a BizTalk Server 2013 instance is just as easy. You can start by logging into the Windows Azure Management Portal. From there, I can show you all the requisite clicks in a single screenshot:


Coffee Break #1

That should kick-off the provisioning process for the Virtual Machine, and also starts off your first coffee break within this process.


Get Connected

So you have a virtual machine running BizTalk Server in the cloud, now what? Well you probably want to get connected, and remote in so that you can make use of it. That can be done by clicking the Connect button in the toolbar while the virtual machine is highlighted in the list of Virtual Machines.


This will cause a .rdp file to download with all of the settings (DNS name/port) required to make an Remote Desktop Protocol (RDP) connection, and fire up the Microsoft Terminal Services Client (still named mstsc.exe) to make it all happen. Make sure your internal firewall allows this, or you will not have much fun after this point.

You will be connecting using the user name that you entered while creating the virtual machine (not your internal domain account). The virtual machine starts out in workgroup mode, and will not be joined to a domain.

Make IE Usable

I think we all know that secure != usable, and sometimes there is an inverse relationship between the two. You will find this to be the case with the virtual machine that you have just provisioned. It is configured to be a headless server by default, and to have a really small attack surface. That’s fantastic, and I love security by default. However, for our purposes of evaluating the product, and doing some development within the Virtual Machine, it’s probably not our first choice.

As a result, you will probably want to head straight over to Server Manager first thing (which will open up automatically). From there, you will click Local Server, and then proceed to toggle IE Enhanced Security Configuration to the Off state:


What will this do for us? It will allow us to use the Internet in a more reasonable fashion. But it will also potentially open you up to make poor choices. Do this with care:


Write Some Code

If you’re evaluating BizTalk Server 2013, it’s likely that you will want to have a development environment available to you – Visual Studio 2012 would be our environment of choice in this case. If we want to do anything interesting with BAM activities and views, we will also need Microsoft Office installed.

So you will probably want to get those installed. With double-click mounting of disk images, it shouldn’t be a problem to install once you have the download links to the ISO files. Where do those live? Right here (but your best bet is to go to the product sites directly and walk through the registration process which will give you a longer evaluation period without persistent nag screens):

Configure This Beast

At this point you will have quite a few tools installed, but a BizTalk Group hasn’t yet been setup. Luckily, since you’re using the Evaluation image, you already have SQL Server installed and ready to serve. At this point you could run through the configuration wizard, or you could go with some happy defaults and just get it done.

So let’s go with the happy defaults. Go ahead and download this file.

Open it up, and then replace the following values, and then save it out to D:\config.xml:

Special String Replace With
@@ADMINUSER@@ Name of user that you created when you created the virtual machine
@@MACHINENAME@@ Name of your virtual machine
@@PASSWORD@@ Password for the user that you created when you created the virtual machine

Once you have that all put together, you can automate the configuration by executing the following commands at the command prompt:

cd “C:\Program Files (x86)\Microsoft BizTalk Server 2013\”
.\Configuration.exe /s “D:\config.xml” /l “D:\config.log”

This should bring you around to Coffee Break #2

What About the Adapter Pack / ESB Toolkit?

At this point you have a usable installation of BizTalk which will give you hours of fun. But what if you want to do something with one of the adapters in the Adapter Pack, or even install the ESB Toolkit? In that case, you will find the binaries for the BizTalk 2013 Evaluation edition at: C:\BizTalkServer2013Evaluation\

Now What?

Now that you have a fully configured BizTalk environment. Kick the tires, play around, look through this blog for some of the capabilities you can experiment with. After that, get some training to find out what BizTalk Server is really capable of. I recommend you check out one of our upcoming BizTalk Server 2013 classes. We have classes for Administrators and classes for Developers now available on the QuickLearn Training calendar.

That’s all from me at //build/, see you next week!

Why Updated Platform Support Matters

This post is the fifth in a weekly series intended to briefly spotlight those things that you need to know about new features in BizTalk Server 2013.

Each new version of BizTalk brings with it support for the latest Microsoft Operating System, Database Engine, and Integrated Development Environment. It is listed as a new feature each time, and many tend to skip over that feature on the new features list. However, this is actually very powerful – especially when considering the change over time in those underlying platforms.

In this post, I’m going to examine how the Microsoft Fakes framework (found in Visual Studio 2012.2 Premium) can enable interesting testing scenarios for code that wasn’t built specifically for test. In the process, I’m also going to be using the Winterdom  PipelineTesting library – which is easily upgraded to 2013 with some re-referencing of BizTalk assemblies.

Testing the Un-Testable

The Microsoft Fakes framework (available in Visual Studio 2012 Ultimate, or 2012.2 Premium edition and above) provides the ability to create both stubs and shims of any .NET interface or class respectively. While the stubs capability is pretty neat, they don’t feel nearly as magical as the shims.

Consider that you have developed a pipeline component with a little bit of logic to inject a context property based on the current date/time. The scenario (although contrived) that I have come up with is that of an order processing system in which rush orders are all received through the same receive location. In that location is a custom pipeline that must promote a property to route to the warehouse that will be able to get the order picked and shipped the quickest (based on which warehouse is picking orders at the current hour, or will be doing so next). When testing the code, we will need to verify the behavior of the code at specific times.

While we could write the code in such a way that the retrieval of the current date/time was done through a special date/time provider class (which implements some interface specialized to that purpose), the logic is being re-used from another location – one which will not be modified.

BizTalk Server 2013 will rise to this occasion due to relying on Visual Studio 2012 as its development environment. We can use the included Microsoft Fakes framework to create a shim that will inject logic for all calls to DateTime.UtcNow to return a fixed DateTime object of our choosing.

getting Started with Shims

In order to get started, we need to instruct Visual Studio to generate some helper classes for the assembly or assemblies of our choosing. These classes will enable us to generate Stubs/Shims for classes within these assemblies.

For our solution, we will be working with the DateTime class, found in System. We can add a fakes assembly in two clicks via the context menu:


After adding the assembly, our project, and its references, look like this:


Now we will have to write the code in such a way that calls to DateTime.UtcNow will return the value of our choosing. In order to hook into those calls only within a specific portion of code, we will need to create a ShimsContext. Because the ShimsContext class implements IDisposable, we are able to wrap a using statement around it to provide better visibility of the scope it will control.

        public void RushOrderMarker_FirstPartOfDay_FirstWarehouseReturned()

            // Arrange
            var pipeline = GeneratePipeline();
            var testMessage = GenerateTestMessage();

            DateTime fakeTime = new DateTime(
                                    year: 2013,
                                    month: 01,
                                    day: 01,
                                    hour: 1, minute: 0, second: 0);

            using (ShimsContext.Create())

                System.Fakes.ShimDateTime.UtcNowGet = () => { return fakeTime; };
                var expectedId = WarehouseIdentifiers[0];

                // Act
                var output = pipeline.Execute(testMessage);

                // Assert
                var warehouseId = output[0].Context.Read(WAREHOUSE_ID_PROPERTY_NAME, WAREHOUSE_ID_PROPERTY_NAMESPACE);
                Assert.AreEqual(expectedId, Convert.ToString(warehouseId), "Incorrect warehouse id returned");




Here we assign logic directly to System.Fakes.ShimDateTime.UtcNowGet that will execute when any code within the scope after ShimsContext.Create() was called attempts to call DateTime.UtcNow. We then submit a message through our pipeline and verify that the correct warehouse id was promoted into the context of the message (based on the current time).

Know your Tools

If you’ve just made the move up to BizTalk Server 2013, it really is important that you not only know what feature set you have in the platform, but also what is available to you in the underlying platform, and the tools you use to create your applications.

If you want to learn BizTalk Server 2013 in the environment it was designed for, check out one of our upcoming BizTalk 2013 Developer Immersion, or BizTalk Server 2013 Deep Dive classes. The hands-on-lab environment is running the latest and greatest versions of Windows Server, SQL Server, and Visual Studio, so that you have the optimal BizTalk Server development experience.

If you would like to access sample code for this blog post, you can find it on github.

BizTalk Server 2013 Beta Released

It’s finally happened!! Microsoft has officially opened a public beta for BizTalk Server 2013. The beta bits can be downloaded here.

Here are my personal top 5 new features of BizTalk Server 2013. I know that many of my customers have been asking for some of these features for a while.

  1. Too many new adapters to keep up with
    • Integration with RESTful services – new BizTalk adapters provide CRUD operations using REST endpoints.
    • New and Improved SharePoint adapter – Previous SharePoint versions did not support client-side API calls so the BizTalk Adapter required installing a special web service on the SharePoint front-end server(s). SharePoint 2010 and the soon-to-be-released SharePoint 2013 both support client-side API calls. The new BizTalk Adapter for SharePoint takes advantage of these client-side APIs to provide an easier, more seamless integration experience.
    • Azure Service Bus integration – adapters to connect to Azure Service Bus endpoints
    • SFTP adapter – If I had a dime for every time someone asked about an SFTP adapter…
  2. ESB Toolkit 2.2 – while the internals of the ESB Toolkit is largely untouched, the latest release boasts a better configuration experience, and full-fledged support.
  3. Dynamic send port configuration – You can now specify which adapter handler your dynamic send port will use rather than being stuck with the default handler.
  4. Artifact Dependency Tracking – The BizTalk Server Administration console provides better explanation of dependencies among artifacts (for example, orchestration X requires: schemas Y and Z).
  5. General Performance Improvements – Significant changes under the covers has improved the performance of send port when using ordered delivery as well as the mapping engine

Although not available yet, I’m also excited that a new Azure VM with the BizTalk Server 2013 Beta is on its way.

I’m also pleased to announce that QuickLearn Training is diligently working on new versions of all of our Developer and Administrator BizTalk Server courses designed for BizTalk Server 2013.