Reflections on Integration 2014 (aka BizTalk Summit)

Posted on by Richard Broida

I’ve just returned from Integrate 2014, the annual gathering of BizTalk developers in Redmond. The big story this year was that Microsoft’s BizTalk team gave its first public briefings and demonstrations of the new BizTalk architecture it’s been planning for several years. The key features of this new architecture are:

  • BizTalk Server will be refactored and re-implemented as small pluggable components. Each component can be used separately from the others, and new ones can be written by third parties and developers. They can each be developed and versioned separately, so there will no longer be single monolithic releases of “BizTalk Server”. I was reminded of how Microsoft has been breaking up ASP.NET into components with OWIN and Katana.
  • But unlike OWIN, the new BizTalk components will not connect directly to each other. Instead their inputs and outputs will all pass through a new type of runtime engine that acts as a message broker. The message flow will thus be pub/sub rather than a pipeline.
  • There will a web-based “gallery” where developers and business users can pick and choose components and arrange them into workflows. Developers will also have access to components in Visual Studio via Nuget.
  • This architecture will be implemented first on Windows Azure, but will also run on-premise in a future version of the Windows Azure Pack. The latter appeared to be how the Microsoft devs were running their demos.

At the conference Microsoft referred to the new components as “microservices”. This term didn’t seem to appeal to everyone, and I won’t be surprised if Microsoft comes up with new terminology. (They no longer refer to it as “AppFabric” as they did in 2010.) And although the BizTalk team is moving the technology forward, we learned from Scott Guthrie (who gave the keynote) and Bill Staples (Director of Program Management for the Azure Application Platform) that Microsoft is planning to adopt this architecture for other Azure features and services.

Microsoft did not have a public preview of the microservice architecture to announce at the conference, but they promised it for 2015 Q1. That is also when they plan to release the first preview of the BizTalk Server 2015, which should be a “major” release since it will come in an odd-numbered year.

Although GA for the new BizTalk architecture is probably more than a year off, the most exciting takeaway for me was the affirmation, both from Microsoft and the developers assembled from round the world, that BizTalk Server and Microsoft Azure BizTalk Services (MABS) are still strong, vital and more able than ever to handle demanding enterprise integration. Old customers are sticking with BizTalk, and new ones are adopting it all the time. At Bennett Adelson we will continue to keep BizTalk at the center of our Connected Systems practice.

BizTalk Server: Three Tips for Initiates

Posted on by Bennett Adelson Consulting

I often consult with clients who are in the early stages of building applications with BizTalk. While many find it easier than they expected to get started, there are some less-than-obvious things about BizTalk that newcomers can miss. Here is a roundup of tips I like to share with them.

Pipeline Configuration Dialogs
Applies to: Receive Locations, Send Ports
The dialogs for configuring receive locations and send ports have a dropdown for choosing the adapter and another dropdown (or two, if it’s a two-way port) for choosing the pipeline. Everyone knows that the adapter dropdown has a button to the right marked “Configuration” that launches an adapter configuration dialog. But not everyone notices another button, to the right of each pipeline dropdown, which is labeled with just three dots “…”. This button launches a configuration dialog for the pipeline. Here is the dialog for the XMLReceive pipeline:

properties

You often don’t need this dialog because the pipeline works correctly by default. But when they need to change a default setting, some developers think the only way is to create and deploy a custom pipeline. They should try clicking the button first.

ElementFormDefault
Applies to: XSD Schemas
ElementFormDefault is an attribute of XSD schemas that I think should have been named “BizTalkDoesNotWorkUnlessYouChangeThisFromItsDefaultToQualified”. If you want a full explanation you can read here and here. But all you really need to know is the answers to two questions:

  1. Do you want BizTalk to work the same way as the rest of .NET?
  2. Do you enjoy getting error messages that say, “The element ‘foo’ in namespace ‘http://blah.com/foo’ has invalid child element ‘foofoo’ in namespace ‘http://blah.com/foo’. List of possible elements expected: ‘foofoo’.”

If you answered “No” to the first question and “Yes” to the second, then leave ElementFormDefault alone. But otherwise you should make it your business, whenever you create a new XSD schema in Visual Studio, before you do anything else, to change ElementFormDefault from its default setting (innocently marked “Default”) to the correct setting, which is Qualified. And it’s easy: just double click on it in the Properties window, and it changes to Qualified. You should do this consistently until it becomes like a reflex.

(Yes, there could be times when ElementFormDefault would need to be Unqualified, most likely so BizTalk can interoperate with some unenlightened outside system. If I ever that situation should arise I would map the Unqualified schema to a Qualified one within BizTalk as quickly as possible. But I’ve seldom seen it arise.)

Let’s review: what’s the first thing you should do when you create an XSD schema in Visual Studio? Answer: change ElementFormDefault to Qualified

configurePipelineXMLReceive  

Started/Enlisted/Unenlisted
Applies to: Send Ports, Orchestrations and Send Port Groups
Receive locations have two states: Enabled and Disabled. The meaning of these is self-explanatory. But send ports, orchestrations and send port groups have three states: Started, Enlisted and Unenlisted. You can think of Started as being just like Enabled, and Unenlisted as just like Disabled. But what does Enlisted mean?

It means the port/orchestration/group has an active message subscription but is not currently handling messages. Suppose you have a send port that sends invoices to your customer Fabikom’s web service, and you know that Fabikom’s web service will be going down for maintenance. If you change the port’s state from Started to Enlisted, then any Fabicom invoices that come through BizTalk will be held in reserve for the port, but the port won’t try to send them. Then when Fabikom’s web service comes back online, you can change the port state to Started, and all the reserved invoices will immediately get sent, along with all new ones that come in. Orchestrations and send port groups work the same way.

Richard Broida
Principal Consultant