Azure App Services Training is Awesome!

By John Callaway

If you weren’t one of the students that attended the recent Cloud-Based Integration Using Azure App Service class offered by QuickLearn you really missed out. I was able to attend and found the experience very informative.

Some technologies lend themselves to simply picking up a book and reading about how it works. BizTalk Server has never been one of those products and it looks like for the foreseeable future at least Azure App Services and Logic Apps are going to fall into that same category. It’s a good thing that Rob Callaway and Nick Hauenstein are braving the front lines to create and deliver quality training for all of us that are too busy to keep up with the rapid changes in Azure.

About the Class

This class was delivered by Rob Callaway, one of the best BizTalk and now Azure App Services instructors in the world! This three day class had an eclectic international audience with people traveling from Canada and Europe to attend the course.

As you can tell from the overview this class is jam-packed with everything that you need to prepare to build integration solutions using Microsoft’s newest addition to Azure App Service, Logic Apps. Since there is so much that goes into creating a logic app the class feels a bit like a snowball rolling down hill, it starts small but as it progresses the knowledge you gain becomes almost overwhelming. The labs ensure that you don’t get lost in the cloud (pun IS intended) by providing a rich hands on experience to match the excellent lecture.

As an integration specialist, I felt very comfortable with the early concepts. By the time we got into day two everything was new as we built first simple and then more complex logic apps.

For the uninitiated a logic app is comprised of triggers and actions which are themselves API Apps. These API Apps are in turn Web Apps that perform some simple function. This whole thing is hosted in Azure. When strung together a Logic App can be very powerful providing capabilities similar to BizTalk orchestrations.

We didn’t just explore Microsoft Azure App Services, but learned how to integrate with Microsoft Azure Service Bus as a reliable and persistent store for inbound and outbound data, and identified the role that Microsoft Azure BizTalk Services (MABS) plays in cloud-based integration. By the end of the course the participants were even able to build their own custom API Apps, no small feat!

The goal of the course, one that I think all the participants would agree was achieved, is to provide the best training possible on these evolving technologies. QuickLearn Training is able to deliver on this goal because we have spent the last two years digging through the sometimes scant documentation and Microsoft presentations to find the golden acorns of knowledge that we happily share with our customers.

Special Guests

One of the benefits of our close relationship with the product team and our proximity to the Microsoft campus is that from time to time we have special visitors. We appreciated Mark Mortimore and Jeff Hollan for taking time out of their busy schedules to drop by on Thursday evening for a meet and greet with the students. Students provided Jeff with some great feedback for features in Logic Apps, and they even convinced Jeff to take a BizTalk Server course. While we don’t always get our friends at Microsoft to visit when we do it’s exciting and fun.

To wrap up the class on Friday we had a special guest appearance by our own Nick Hauenstein where he previewed his Creating a Push Trigger API App to Process NFC Tag Reads demonstration that he will be delivering at the upcoming AzureCon2015 on September 29th.

What The Participants Are Saying

Rob did a great job helping the attendees navigate the mine field or maybe, given the mental challenge, that should read MIND field, of creating and configuring Microsoft Azure Logic Apps.

Some of the feedback that we received from the attendees of this class:

…the QuickLearn materials were flawless and perfectly adapted to the objective of the course…I think that the learning environment is close to perfect and I’m having a hard time thinking of anything that should be changed.

The pace of his speech is very easy and pleasant to follow. Important points are made and repeated, often with humor, which is yet another demonstration that Rob masters his topic and enjoys sharing his knowledge.

This class probably needs to be at least 4 days if not a week.  Need more time to complete labs.


With an evolving set of technologies such as this there were inevitable additions that were made between the initial deliveries of this course and the most recent one. With this new content the class will simply not fit into the three day time-box that we initially allotted. As a result of these additions, and the feedback that we got from the recent class, we are excited to announce that the Cloud-Based Integration Using Azure App Service class is being extended to five days!

Your first opportunity to attend this new expanded version of the class is November 30th. As with all QuickLearn Training classes it is offered for remote attendance if you prefer but of course you are all invited to attend at our state-of-the-art facilities in Kirkland Washington as well.

I predict that within one year, your customers will be asking you about cloud based integration. Wouldn’t you rather be the one that knows the answers already, and have several months experience under your belt?

If you are worried that new features will be added that you miss out on by being an early adopter, QuickLearn Training always offers the opportunity for students to retake any class within six months, thus future-proofing your learning. As new features are added to these technologies you can bet that we will do our best to stay on top of the changes so that we can share that knowledge with you.

So indeed if you weren’t one of the students that attended the recent Cloud-Based Integration Using Azure App Service class offered by QuickLearn you really missed out, but you have another chance to mend your ways and get an improved and lengthened version of the course. Don’t miss out on this great opportunity.

Accessing XML Fields Within a Logic App

By Nick Hauenstein

Earlier this week, I was revisiting a design for a Logic App that interacted with an event about a business entity that was represented as an XML message. It used data from this XML message to invoke actions later in the process, and relied on the XPath Extractor API App to provide access to the data contained within the XML. It looked something like this:


At the time, the choice to use XPath Extractor API Apps was an alright choice, given that there weren’t really any alternative API Apps in the marketplace that allowed one to cross the XML / JSON divide – JSON being the native tongue of Logic Apps. That has since changed, and upon revisiting the design, it became apparent that using the XPath Extractor was a poor choice.

I wasn’t doing anything complex (e.g., selecting the text inside an element only when that element had an attribute with a specific value and appeared nested inside an element beginning with a certain set of characters), I was just trying to retrieve the values stored within scalar elements within the same location in the XML document each time – elements that I would have simply treated as distinguished fields in BizTalk Server and happily dotted into while editing an expression.

Despite not doing something complex, the original design was using 3 separate API App executions just to read 3 separate values. That seems a little bit wasteful for something that the Logic App runtime would give me for free with JSON data.

Using the Right Tool to Bridge the XML / JSON Divide

So what API App was added into the mix since the original plan for this Logic App? The BizTalk JSON Encoder API App – which provides translation from/to XML/JSON.


It accomplishes this in a similar way to BizTalk Server’s own JSON Encoder / JSON Decoder pipeline components, and like those components also requires an XML schema in order to perform the conversion from JSON to XML. The schema can be written by hand, generated from JSON in the Azure Portal, generated from a Flat-file in the Azure Portal, or created using Visual Studio 2012 with the MABS SDK.

Once you have your schema, you can use the Components tile of the JSONEncoder API App within the Azure Portal to access an interface to upload and provide a name for the schema.


In the case of XML to JSON, the conversion can occur with or without a schema (i.e., a schema isn’t going to be used, but it won’t hurt anything if you upload one either).

Doing Simple Things with Simple Data

So how do we do something simple (e.g., access a few fields) with simple data? Thankfully, the answer is quite easily. First off, you will need to create an instance of the BizTalk JSON Encoder API App. This instance can be re-used for any XML to JSON conversions that you will require. Converting back to XML from JSON assumes that you have created the requisite schemas and uploaded them for the instance. One downside here is that you cannot share schemas between instances (as they are stored in local storage for the API App on the Gateway).

Once you have the API App, you can feed it any arbitrary XML payload and it will provide a nice JSON representation that you can dot into for any later actions in a Logic App. Unfortunately, its flexibility comes at the cost of rich metadata describing the shape of the output (i.e., the designer won’t be able to help you know which nodes will actually exist in the output, regardless of potentially having a schema available).


So let’s make it happen. I have an event about a business entity (product) that looks something like this as XML:


Let’s say that I want to retrieve the ProductName out of this message. In that case, the expression within a Logic App to retrieve the value would look something like this:


If the Remove Outer Envelope property on the BizTalk JSON Encoder API App was set to true, then it would look like this instead:


As shown in the screenshot above, neither of these expressions are going to show up within my nice little drop-down list of values to select. Instead, I must dot into it in trust that it will be there. But how can we be a little bit more sure? We could couple it with an XML Validator, or add a condition on the action based on the logical existence of the node.

Does the simple case work though? Well, after updating the expression:


And then submitting the sample message to the source queue, this was the input/output set of the BizTalk JSON Encoder:



And this was the data that showed up in the request bin:


What If I Have More Complex Data?

What if the data that I have isn’t just a bunch of text in elements, but I have a complex structure with repeating nodes and attribute values? To find out, I loaded up the sample message with some sample data to see.


Running that through the JSON Encoder, I saw this output:


Attributes are represented as properties prefixed with @ and the text included in a node is represented as the value of a property named #text. Repeating nodes are collapsed into an array sharing the name of the node name – perfect for repeating an action against.Smile

Then, When Is the XPath Extractor the Right Answer?

Simple data or complex data might not be the determining factor in the choice between using the XPath Extractor or JSON Encoder API Apps to access data locked up in an XML message. Instead, it looks like the determining factor is how hard it is to describe where that data lives (or doesn’t live) within the content. In all the cases we’ve seen thus far, we referenced by name / location in the document. XPath will shine when we don’t have that information, or when we want information about the content in the document, and as such still deserves a place in the toolbox.

However, just because you’re trying to get data out of XML, and all previous knowledge points to XPath as the answer, it might not be – instead, the answer might be to translate that message into the native tongue of the runtime that’s interacting with it.

What’s Next?

I currently owe all of you readers out there a post about push triggers. I have most of it written, but I’m not yet fully pleased with it. I’ll try to get that out as soon as possible. Additionally, there’s another post that I’m even more excited about, one that I’ve been thinking about for the last 3 years. I’m likely going to be posting that one shortly after WPC.

Stay tuned. There’s heaps that I want to share, but, alas, the constraints of the solar day and the capacity of my human flesh prevent it from happening all at once.