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.

Some exciting changes coming to our TFS courses

By Anthony Borton

One of the things that really helps set QuickLearn apart from our competitors is the fact our TFS courseware is being continually updated to ensure it is as current as possible.

With Microsoft releasing quarterly updates for Visual Studio and Team Foundation Server, you want to make sure you don’t miss out on any new or improved features that could make your job easier.

We also review the structure of our courses to ensure they are a great fit for the market and sometimes that means we change existing courses and sometimes it means we develop brand new courses.

Here are a list of changes that will take place over the next few months.

1. Merging and refining our offering for Team Leaders, Project Managers and Scrum Masters.

Our 2-day Managing Projects with Microsoft Visual Studio TFS 2013 course is being merged with our 3-day Applied Scrum Using Visual Studio 2013 course to become Managing Agile Projects using Visual Studio TFS 2015 (3-days).

2. Expanding our TFS Administration and Configuration offering

To help keep up with all the changes and to allow us to add more hands-on-lab exercises, we’re expanding our TFS 2013 Configuration & Administration course from 3-days to a 4-day course for TFS 2015. You’ll see this change occurring from July 1st, 2015.

3. An improved offering for DevOps training

Our Build, Release, and Monitor Software Using Visual Studio 2013 course is being replaced with a new DevOps using Visual Studio ALM 2015 course from July 1st, 2015. This has been revamped to offer a broader range of topics and some great new hands-on-labs exercises. Want to know about the new Build features? Perhaps you’re trying to get your head around Desired State Configuration (DSC)?

4. DeveloperS – choose Git or Team Foundation Version Control

Our TFS 2013 Developer Fundamentals course has always focused on Team Foundation Version Control in the past. The market has asked us for something to help them if they are using Git for their version control and we’ve got a solution.

Our TFS 2013 Developer Fundamentals is now available in two different flavors for the 2015 release. Simply choose the course corresponding to the version control provider you and your team are using.

  • TFS 2015 Developer Fundamentals – TFVC  (2-days)
  • TFS 2015 Developer Fundamentals – Git (2-days)

5. Developer Enterprise Features – NEW

Microsoft has long offered a tiered pricing/feature model for Visual Studio with versions ranging from Professional up to Ultimate. Often development teams continue to use just the “standard” Visual Studio capabilities and don’t take advantage of some of the great productivity features available in the higher level editions.

Starting with the 2015 release, we’re offering a brand new course “Visual Studio 2015 Enterprise Features” (2-days) which will focus in on the features only found in the higher level editions. Many of these features offer huge benefits to teams or enterprise developers and we want to make sure you’re using them to achieve your optimum productivity.

This new course hits the public calendar in the second half of 2015.