Azure App Service: BizTalk Server PaaS Done Right

By Nick Hauenstein

Today’s announcement from Scott Guthrie not only brought with it a re-imagined Microsoft Azure platform, but also finally gave BizTalk Server a pure PaaS home right in the center of the stack. To be fair, we’ve had clues that this was coming since Bill Staples’ keynote at the the Integrate 2014 conference in December, but we’re finally on the edge of it all becoming real.

AN Inevitable, Yet Happy, Re-imagination

Today's Azure App Platform

It’s a shift that was inevitable given the nature of the existing Azure services – all stand-alone with their own distinct hosting environment, extensibility points, and management experiences. Imagine that you were working with an integration involving an Azure Website, Service Bus Topic, and MABS Itinerary. In order to manage it, you may have found yourself using 3 separate versions of the management portal – with one living on top of Silverlight.


With the re-organized app platform, we’re seeing a move into a single hosting container – the Azure Website. That means that all investments in that space (hybrid connectivity, auto-deployment, language support, etc…) now serve to benefit the entire platform.

For the purposes of the rest of this article, and the interests of the community that this blog generally attracts, I’m going to focus in on two of the components of the Azure App Service – Logic Apps and API Apps.

Core Concepts of the Azure App Service Platform

Before we take a look under the hood at what it looks like to use this stuff, it would serve us well to examine some of the core concepts behind this new platform.

Logic Apps

Logic Apps are the workflow of the cloud. However, these flows are composed not of “activities” in the WF sense or “shapes” in the BizTalk sense, but instead are composed of API Apps – RESTful API calls. Logic Apps can be triggered manually, on a schedule, or by a message received by a connector – a special classification of API App. Within the Logic Apps, calls to the API Apps are referred to as Actions, and are configured graphically within a web-based Designer.

Logic App Blank Canvas

The web-based designer starts as a blank canvas. If you’ve never created one before, you will need to get some API Apps from the marketplace to use within your flow. Once you select them from the marketplace, an instance of each will provision itself within your Azure subscription – in the resource group of your choosing (think BizTalk Application for the cloud – a logical grouping mechanism) .

Each API App will be locked to the version that was retrieved at the time that you originally fetched it – until you update it. Versioning of each API app is done through NuGet-style packaging.

Getting ready to create the Twitter Connector

Benefits of this model are that you are able to control the scaling and locality of each of the API Apps that you use, you have some level of control of the version in use, and you’re not subject to the demands of everyone else in the world on that same capability.

This is a nice way to handle the concept of a service marketplace – not only selling the raw capability that the service provides, but providing an isolated / personal container for your calls against that logic that can be located directly alongside your app for the lowest possible latency.

There are quite a few connectors/actions available for use in the marketplace, and this is where we start to see capabilities from BizTalk Server light up in a purely PaaS way within Azure.

API Apps in the Marketplace

API Apps

Microsoft is not the only provider of API Apps – you too will have the ability to create API Apps for use in your own Logic Apps or for use by others when published to the marketplace. The new release of the Azure Tools for Visual Studio provides project templates to make this happen, as well as a new Publish Web experience.

Azure API App Template

When creating a new Azure API App, you will find quickly that you’re really building a Web API application that has a nice SwaggerConfig.cs class within the App_Start folder for publishing metadata about the endpoint itself. You can think of Swagger as the answer to WSDL for the RESTful world:


Other than where you’re ultimately publishing the bits, how the metadata is exposed, and some hooks you have into the Azure runtime, this is just a stock-standard Web API project. In fact, you could write it in any of the languages supported by Azure Websites.

For now, that’s all I’m going to say about custom API apps. Keep watching this space in the coming weeks though, as we at QuickLearn will be gearing up for a live in person and virtual event focused around building custom API apps and connectors.

That being said, let’s focus in on a few of the API Apps that are available right now in the marketplace – specifically the BizTalk API Apps.

BizTalk API Apps


Looking through the BizTalk API Apps, we find the ability to validate XML, execute maps (MABS-style maps), and execute Rules (among other things). When doing those tasks, additional artifacts will be required (beyond just the message itself, or a simple string parameter).

For such API Apps, the Azure portal allows you to navigate directly to the API App, and configure it further (e.g., uploading schemas for validation, creating transforms, and/or defining vocabularies and rules).

Adding maps for use in the transform service

I’m happy to see that the BizTalk API Apps will allow us to re-use existing artifacts (at least for schemas and maps). For rules, the story is a little bit different. We can actually define rules within the browser itself (more on that in a later post).

API Gateway

At this point we have Logic Apps (composite flows that bring together calls to multiple API Apps), and API Apps themselves (micro services that can be called directly). They live together in a logical resource group, but how can we manage authentication / authorization for calls to these apps? The answer to that is the API Gateway – a web app that handles API management functions such as authentication for all API apps in a resource group.

API Gateway

Everything is New

This is a time of huge change for Microsoft, not only embracing open source and greater platform support, but also investing more deeply into their own platform and integration. It’s definitely an exciting time to be a developer.

Here at QuickLearn, we will be hard at work making sure that you have a company that you can turn to for world-class cutting edge training in this space. So stay tuned, because some of the best days are still ahead.

Leave a Reply

Your email address will not be published. Required fields are marked *