BizTalk Server 2013 R2 Available!

If you have been waiting for BizTalk Server 2013 R2, the wait is over. Although this is not a huge new release, if the new features are of interest to you then it is available for download from MSDN as of today. It has a huge long ugly url which I shortened to help you all out. We haven’t seen the specific numbers but the buzz is that performance is greatly enhanced especially for EDI specifically HL7 scenarios. to download the bits, (with an MSDN license of course). for a comparative list of features between BTS 2013 and BTS 2013 R2.

Happy BizTalking!

BizTalk Server vNext TAP Program

We are pleased to announce to our customers and partners
that we will once again be participating in the Technology Adoption Program
(TAP) for the next version of BizTalk Server. Microsoft has yet to announce a
final name for the product, it is presently being referred to as BizTalk Server
2010 R2 or simply v-next, however they have indicated that the release date
will be about six months after the release of Windows 8 Server. I recently
posted another blog that talks about the future of BizTalk, check it out.

The TAP program assists Microsoft in soliciting feedback
from customers and partners regarding yet to be released products. As
participants in the TAP program we will be under strict non-disclosure
requirements so we won’t be able to say too much about the product until
Microsoft does, but rest assured that we will providing all the feedback that
we can to get all the cool features into the product that we have been looking



QuickLearn has previously participated in the TAP program
for other versions of BizTalk and for Windows Azure. We will be prepared to
offer training on whatever new features are coming down the line as soon as the
product is fully baked!


Does Microsoft BizTalk Server Have a Future?

I know that many of you have been wondering if BizTalk is just going away, and Microsoft has been particularly closed mouthed about their plans for it of late. After a period of relatively rapid growth, with BizTalk 2006 R2 in 2008, BizTalk 2009 and BizTalk 2010, all in rapid succession there has been nothing new except a few patches out of the BizTalk team for 2+ years. Information about the latest cumulative update for BizTalk Server 2010 is available here.

With Microsoft pushing AppFabric and Azure as they have been, and with so much of the functionality seeming to overlap with BizTalk who could blame us for wondering? Many have hypothesized that BizTalk would simply be subsumed into AppFabric and disappear forever. Why wouldn’t Microsoft push for just such an agenda? Wouldn’t you rather rent customers their software for an ongoing monthly fee as opposed to selling the software just once that runs and runs and runs? Since most BizTalk customers acquire their licenses through an enterprise agreement, this has effectively already been the case. Moving BizTalk to a cloud-hosted tool solidifies this arrangement and makes it much easier to add new customers. This effectively is the concept behind SaaS (Software as a Service) and the more recent incarnations of PaaS and IaaS (Platform and Infrastructure as a Service respectively).

The most official communication regarding the future of BizTalk was conveyed by Tony Meleg last year at various conferences (including the 2011 World Partner Conference). He stated that over the next several iterations, spaced approximately 2-3 years apart, BizTalk would evolve to become more cloud based and more integrated into a SaaS type product. This would seem to indicate about 10 year evolution cycle. Not a bad timeline for a product that has only been around for about 10 years, (let’s face it BizTalk really started with BizTalk 2004!)

At TechEd 2012 in Orlando there were two sessions on BizTalk Server. Oh you say, you missed them? Not surprising as only one had BizTalk in its name and it was a late entry, and both sessions were scheduled at the end of the conference; the last two session of the last day (AZR207 and AZR211 if you have access and want to watch them yourself).

In these sessions Balasubramanian Sriram, Javed Sikander, and Rajesh Ramamirtham shared several very promising particulars regarding BizTalk Server 2010 including: of the 12,000 worldwide customers for BizTalk Server over 79% have already upgraded to BizTalk Server 2010. I take this as a very positive number since this indicates a strong and interested base. Also, any future upgrades will be made easier by having 80% of customers ready to go (historically “in-place” upgrades are only supported for the current version). Of course for those of us that love BizTalk like I do, we hope to see this number grow by 100 fold or more! However, that will only come if the product gets easier, and cheaper for customers to use.

Here is what I took away from these sessions. Microsoft intends to continue to innovate in the integration space with improvements to BizTalk server in three primary areas.

BizTalk Server on-premises: Microsoft will continue to support new platforms including Windows 8 Server, SQL Server 2012, Visual Studio 2012, Office 15 and System Center. The proposed release date for this next version is about 6 months after the release of Windows 8 Server, so late 2012 or early 2013. While it is currently being called BTS 2010 R2, we have verbal confirmation that Microsoft understands it would be more aptly named BizTalk Server 2012, or more likely 2013. An R2 probably doesn’t make sense three plus years after R1!

The newest version will include:

  • Support of the latest B2B standards including HL7, Swift and EDIFACT and X12 EDI schemas. Considering the huge uptake in customers using BizTalk Server for EDI transactions this is a pretty big deal.
  • Improved performance for dynamic send ports including the ability to specify the host to be used, (yay).
  • Integration of ESB functionality into the core of BizTalk Server (installation will just be a checkbox?)
  • Better manageability to view artifact dependencies through the Administration console, for example what map is used in what port.
  • Improvements to several adapters, including SharePoint, HIS, SMTP and the ability to consume RESTful services directly from BizTalk.
  • And easy integration with BizTalk on Azure…

BizTalk on Azure (BizTalk IaaS): The new on-premise BizTalk will be offered as a hosted service available “in the cloud” to make provisioning additional servers faster, easier, and we can only hope, less costly. The time-line for this is the same as BizTalk on-premise since it is virtualization of the same technology.

  • This would provide the ability to easily move applications developed for on-premise hosting to the cloud, and vice-versa.
  • Initially this will only be available for development and test but Microsoft will obviously make this feature available for production relatively soon.

BizTalk PaaS: The timeline for this one is a bit less clear, but it is happening to some extent already. For those customers that don’t have need of heavily customized BizTalk deployment and maybe don’t have a volume that would justify a multi-server installation, some BizTalk functionality will be offered as a cloud-hosted service. I don’t think that anyone sees this as a replacement for on-premise BizTalk servers however in messaging only scenarios this makes a lot of sense.

  • The primary benefit is for route and transform functionality where no custom orchestrations would be required. This provides an easy entry point for customers which will later probably require more power and will end up with custom BizTalk solutions. For BizTalk to be viable going forward the customer base must expand from the current 12,000.
  • Most new innovation would take place in this area and then the capability would be moved into the on-premise (or hosted) versions of BizTalk.
  • Best use case here would be companies that buy BizTalk purely for the EDI capability. Today this requires dedicated hardware and a development staff when really all they need are the schemas and some configuration all hosted in the cloud.
  • Another likely scenario would be integration between various enterprise applications where once the schemas are defined the processing is completely automated.

What all this means is, after an extended period of seeming inactivity on the BizTalk Server front, I am pleased to inform you that BizTalk Server is not dead! The “key takeaways” from the sessions sum this up very clearly:

  1. Microsoft is committed to releasing a new version of BizTalk very soon with additional versions to follow on a 2-3 year cadence as in the past.
  2. Conventional on-premise BizTalk, plus BizTalk IaaS, plus BizTalk PaaS is the way forward and it should drive higher adoption and more innovation in the integration area that we all know and love.
  3. Continue to bet on BizTalk as Microsoft continues to invest in BizTalk, (their words, not mine, but I agree).

In several discussions that I have had with BizTalk MVPs, students, customers and Microsoft employees over the years, my feeling for years is that as awesome as BizTalk is, it has needed update, a big one, and that this update would require quite a change in thinking. I am thrilled to see them releasing more definitive plans that we can tie our futures to.

It looks like we will have several years of BizTalk development and support ahead! Long Live BizTalk!

BizTalk is Dead? Long Live BizTalk!

The BizTalk Server team blog sneaked out an announcement yesterday that you might have missed. I caught it due to an RSS feed. BizTalk Server 2010 R2 is coming. Now the question is when, and a better question will they change the name, as they should to BizTalk 2011?

We have a while to wait, no firm dates yet, but since it adds support for Windows Server 8 and SQL Server 2010 (codename Denali) which don’t have announced release dates yet either, that isn’t too much of a surprise. They are saying about six months after those products release. Support for Visual Studio 11 was also part of the announcement.

It doesn’t sound at all earth shattering, more just a bit of a jiggle. It may calm some of the fears as they are frequently bandied about from the title of the article, that BizTalk is a dying breed. Rest assured that QuickLearn will be on the forefront of training for this new product as soon as a beta is available.

In addition to support for the new platforms another point of interest is a change to licensing making it possible to provide BizTalk as a hosted service , and to transfer a license to a hosting provider. This is obviously a step in moving BizTalk into the cloud, a change that has long been planned. We’ll have to see what that means as to whether Microsoft will be a possible provider themselves (a la Office 365 and SharePoint online).

That’s about it for what’s new unless you are interested in IBM host integration there are some adapter improvements that way. For the whole article check out the BizTalk Team blog at

Until next time, see you in the funny papers.

Lessons Learned From Years of BizTalk "Vision Quests"

OK, think fast! Name three features of BizTalk that you really love. Now name three that “need some work”. If you have been around BizTalk for more than a few weeks your answers to both of these questions included: “You mean I am limited to three?”, and the two lists likely have some overlap.

If you are reading this, you are interested in knowing what the future of BizTalk is, as am I. It seems that every time Microsoft releases a new technology such as the .NET framework 3.0 (with WF and WCF), Oslo, Dublin, Azure, AppFabric, whatever, the eminent demise of BizTalk is debated. These rumblings have been rolling around once again.

BizTalk isn’t perfect but warts and all it is, in my humble opinion, the best integration option out there. Most of what we know as BizTalk Server today has remained unchanged since BizTalk 2004. Sure there have been some improvements to the interface, and some performance tweaks, and some features have been added, (WCF and EDI support most notably) but the core processing engine has remained untouched.

In no small part I think this is because with an installed base of well over 10,000* customers worldwide Microsoft realizes that the transition to the next BIG version of BizTalk can’t look like the process of upgrading from BizTalk 2002 to 2004. That transition for those of you lucky enough to miss it was more of a wholesale rewrite then a simply upgrade.

The changes that are needed to bring integration into the current decade will be dramatic and will necessarily take some time; maybe even into the next decade if the timeline hinted at by Tony Meleg is anywhere near accurate. In a presentation given at the 2011 Microsoft Worldwide Partner Conference July , 2011, Tony outlined the roadmap for the next few versions of BizTalk and how that is going to play with technologies such as WF, WCF and AppFabric.

In the presentation Tony identified some customer requests that they are hoping to address over the next few iterations of BizTalk and in the interim with Microsoft’s newest favorite buzzword “AppFabric”. I’ll discuss some of his requests later but for now on to…

My BizTalk Asks

Your list may vary from mine, and I am not going to limit myself to three “needs some improvement” features, but here goes, in no particular order:

Easier control over message box persistence: Since BizTalk always persists every message; it isn’t designed for super-low latency scenarios. Many people have asked for an easy switch to turn off persistence when it isn’t needed, and this happens more often than you might believe. Some competing products have taken a different approach, that is they don’t persist any messages, thus their throughput is much improved. In these systems when persistence is turned on, (frequently requiring additional servers and licenses) their performance positively tanks. This request is not a “simple-fix” since BizTalk at its very core is a publish/subscribe (hub and spoke if you prefer) engine.

Dynamic orchestration filtering: As BizTalk developers we are very aware changing the subscription for an orchestration isn’t a configuration change so much as a coding change. This typically requires versioning considerations, retesting, redeployment, etc. Although a well thought out orchestration design can reduce the frequency of these changes, when changes are necessary the process can be painful. Having a more loosely coupled holistic approach to the end-to-end design, including exposing the orchestration filter as configuration (much as send ports already are) would assist greatly in this area. This has been a long-term request of experienced BizTalk developers.

Support for mirrored databases: Many BizTalk administrators that we work with have asked why mirroring is not supported for the BizTalk databases. This is really more of an issue for the SQL team since that is where the issue originates. SQL server does not support mirroring of transactional databases (though clustering is of course supported). Since most of BizTalk’s core databases communicate with each other transactionally this is a big change and not one that can be implemented by the BizTalk team alone.

ESB like capabilities easier to implement: This is really two requests in one. First it seems that the ESB way of dealing with exceptions really should just become the default. Expecting operations personnel to troubleshoot problems using only the Group Hub and event logs seems rather arcane when compared to the slick web based interface available with the ESB management portal. Second for those companies that desire itinerary processing abilities as available in ESB I’d like a switch that turns that on. Of all the items in the list this one (seemingly) would be the easiest to implement, and may be coming to BizTalk sooner than some of the others.

Ability to change the host used by dynamic send ports: This is a sub-request related to the preceding one. Since the ESB toolkit so heavily leverages dynamic send ports, the ability to change what host they are running on would be really nice. While we are on the topic, how about the ability to dynamically change the pipeline and/or map used by a dynamic port. This feature is effectively offered using the ESB toolkit, but how about making it easier if I don’t want the “whole itinerary thing?”

Callback support for WCF adapters: I’d like to be able to have a client initiate a process via a web service call and then have the process call the client back when it completes. This is certainly supported in WCF itself but at present neither BizTalk’s WCF adapters nor AppFabric supports callbacks.

Microsoft’s BizTalk Asks

In his presentation Tony identified several additional Asks that Microsoft has identified. I don’t doubt that some customers have asked for these features but some of them are going to be big for Microsoft as well.

Low Latency: (already discussed above).

More Flexible Messaging: Tony ignored this point in the presentation so I’m going to say I have addressed it in my Asks above.

Alignment to Windows Workflow: This means different things to different people. Tony identified it as “replace the orchestration engine with the WF engine”. I myself don’t really care whether we call it an orchestration or a workflow what I want is scalability and robustness which at least (so far) we don’t really have in WF. Would it make sense to do this? Sure, having a single engine to maintain makes a lot more sense than two very similar engines but this will not be a trivial change, (Tony identified it as “heart surgery”!)

Put BizTalk on Azure: This seems to have become Microsoft’s solution to almost everything, and who can blame them? Instead of selling you software that you pay for and install once, how much better to sell you software as a service where you get the latest and greatest functionality instantaneously (plus for you) and Microsoft gets to charge you over and over again for it, (plus for Microsoft). That’s what we call a win-win situation? Considering the issues that all cloud providers have experienced over that last few months I think it is going to be a while until companies are going to be fully comfortable outsourcing something as mission critical as integration.

Service Virtualization/Discovery/Tooling: As services become more ubiquitous there is a definite need to enable automatic discovery and integration with these services. Whether the provider and/or consumers are BizTalk this need exists. UDDI held the initial promise for a part of this, while for other parts Microsoft hasn’t really offered a solution. This is one of those things that the BizTalk team likely won’t own, but they have a tight dependency on the eventual solution, whatever it may be.

And I’m going to lump Tony’s last two bullets together: Align Business Rules, and Invest in BAM, improve tooling and make them work across the Microsoft stack: As any of my former students can attest to, I am a huge proponent of using these two features of BizTalk. They are each easy enough to implement if you are using orchestrations, but their abilities go so far beyond that, and I don’t think Microsoft has done a good enough job selling them. For a long time I have seen these as two pieces that could certainly be spun off to stand alone and simply be used by BizTalk as they could be by any other .NET component. As much as I’d hate to see them go, I welcome all developers to use them, so long as we still can!

Any one of these features on its own could; if really fixed to my satisfaction, be quite an effort. Taken as a collection they are going to be very challenging and will necessarily take a long time. The cadence that has been identified is that the changes will come first to the AppFabric space and will be evolutionary, two to three releases per year. I see AppFabric as an incubator where some features will live, some will die, and where change will be frequent. If you are not comfortable with living on the bleeding edge I’d stay clear for now.

BizTalk will continue to be developed and new releases will come every couple of years. The best and the brightest of the AppFabric changes will be integrated a few at a time. If you remember WSE 1.0, 2.0, 3.0 which finally morphed into WCF, the cycle will be similar with AppFabric being the WSE releases and BizTalk being the WCF release.

When I look at BizTalk as a 10 year old product, and considering that the evolution to the eventual BizTalk replacement at least as Tony sees it is being 10 years, I’m feeling pretty good about my decision to stick with BizTalk Server, but I’m also going to keep a weather eye on WF, WCF, and all the AppFabric(s).

For anyone that read this whole thing and watched Tony’s presentation here is my concept of a cloudy thing! Asperatus is a new and upcoming type of cloud. Maybe this should be the code name for the BizTalk in the cloud. It has to be better than v-next right?

*The latest published numbers for customers is from the BizTalk 2009 release and at that time the number was 10,500. With the previous years’ rates of growth this is likely approaching 12,000, but we can only speculate since Microsoft has not released more recent numbers.

Want a Preview of BizTalk 2010?

Get sneak peak of QuickLearn’s BizTalk Online Anytime Training and learn about new features in BizTalk 2010 including:

  • Enhancements to the BizTalk Mapper
  • Adapter and Integration Changes
  • Improved Trading Partner Management
  • BizTalk Server Settings Dashboard
  • New OpsMgr Management Pack
  • Updated Platform Support

See all of QuickLearn’s BizTalk Training Courses


kick it on

BizTalk 2006 Book Rating

Students frequently ask my opinion on which BizTalk Books will be most helpful. I have reviewed several books, and will recommend a few of them here. I haven’t really seen any terrible BizTalk 2006 books (and believe me, I have seen some terrible technical books in the past!), so this is really a ranking of several really good books. It should be noted that many of the books below mention BizTalk Server 2006 R2 only in passing, because they were all written prior to the release of R2. I do not know if updates are planned for them.

In the interest of full disclosure, I should mention that QuickLearn has received a slew of books from Apress that we occasionally pass out in classes (thanks, Apress). Also, Darren Jefford, the author of one of the other books, is a friend and has provided signed copies of books that we have given away at various conferences. Despite my affiliations, I hope to provide a fair assessment of the literature.

The top of my list is Professional BizTalk Server 2006, by Darren Jefford, Kevin B. Smith, and Ewan Fairweather, published by Wrox Publishers. “Wrox” is pronounced like “Rocks,” which is exactly what this book does. It’s very telling that, as I was writing this post, Amazon has eight listed reviews, and all eight give the book full marks (five stars) – I would definitely give it the same. Because this book assumes a moderate level of existing BizTalk knowledge, it is definitely not a good book to learn BizTalk from scratch (it’s a great companion book to our Deep Dive). Nevertheless, it’s a book by three guys who have been there, done that, and own the tee shirt when it comes to BizTalk implementation. This is a book that I refer to frequently.

Coming in at a close second on my list of favorites is Pro BizTalk 2006, by George Dunphy and Ahmed Metwally, published by Apress. (These books share more than a similarity in their names!) This is also an excellent book with very similar coverage to the Wrox book (Deep Dive level). If you own either of these books, you’re in good shape. I prefer the writing style of the authors of the Wrox book, but you may like this one better. Either one or the other of these is great, but you probably won’t need both.

If you’re looking for a book for someone totally new to BizTalk, consider Foundations of BizTalk Server 2006, by Daniel Woolston, published by Apress. This book contains good, concise description of common BizTalk terms (BizTalk vocabulary on steroids), and is a great pre-class primer for QuickLearn’s BizTalk Server Developer Immersion. If you’ve already attended any of QuickLearn’s BizTalk classes, you will probably find this book overly simple.

If you’ve identified a problem in your design/development, and you’re looking for a quick way to solve it, your best choice is BizTalk 2006 Recipes: A Problem-Solution Approach, by Mark Beckner, Ben Goeltz, Brandon Gross, and Brennan O’Reilly, published by Apress. This may not be the best book for learning BizTalk from scratch, but it’s a necessity for every BizTalk shop. This book takes a no-nonsense approach to “Here’s the problem, now how do I fix it?”, and identifies the implementation of the patterns necessary to solve the problem.

Although not a BizTalk book, per se, a good general overview of messaging and other integration patterns can be found in Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions, by Gregor Hohpe and Bobby Woolf. DO NOT EXPECT TO LEARN ANYTHING ABOUT BIZTALK FROM THIS BOOK! I am recommending this book as an excellent resource about integration in general non-Microsoft terms; however, many BizTalk-related documents, available from Microsoft sources, reference the patterns revealed in this book. So do the BizTalk 2006 scenarios (more on these later, if you aren’t familiar with them). Gregor maintains a site that contains much of the information available in the book, but the book still makes a great paperweight, (it’s big and hardcover) J. I have been referencing it in my classes for so long that I thought I better mention it here as well.

Where’s my functoids?

QuickLearn is in the process of updating our now famous BizTalk Deep Dive course (NEW and IMPROVED!). As I have been collecting and reviewing content for the advanced mapping module, I am reminded of one of the most common “Eureka” moments for many students is the realization of just how easy it is to create custom maps without using functoids. Many people come to BizTalk after having developed a custom integration project that required them to create their own XSLT. Often I am asked, “Can’t I leverage the work that I’ve already done and use the XSLT I’ve created? Do I have to use all those functoids?” The answer: Of course you can use your own XSLT, and some of the best maps do! You really have three options here: The first two involve the use of Scripting functoids; the third relies strictly on the XSL that you provide.

Inline XSLT

Many times, the result of chaining several functoids together can be more concisely defined in a little custom XSL. When using the inline XSLT option, the Scripting functoid cannot have any input links; rather, it should contain references to the source schema nodes through XPath expressions. The functoid must link directly to a record or field in the destination schema (it cannot be input for other functoids).

Inline XSLT Call Templates

Like an inline XSLT script, the inline XSLT call template must connect directly to a destination node; however, it may receive input through links coming from other functoids, or from the source schema. On the map grid, setting the Custom Extension XML property enables Scripting functoids, configured as either Inline XSLT or Inline XSLT Call Templates, to make calls to external assemblies.

Custom XSLT Code (Look ma, no functoids!)

If you have XSLT code you have written to convert instance messages, you can use that code directly, instead of creating a map.

  1. Create an empty map and set the source and destination schemas as you normally would.
  2. With the map grid selected, configure the Custom XSLT Path property to use the file containing your custom XSL.

NOTE – Using custom XSL overrides all links and/or functoids in the map.

Remember that you can always validate your map to access the generated XSL, which will be executed for the map. Also remember that maps do not validate the messages generated, except while testing in Visual Studio. The warnings you receive in Visual Studio provide design-time assistance to identify possible problems. BizTalk is totally content with generating exactly the message that you tell it to, valid or not!

Until next time, have a great day.