Blog Leave a comment

Azure App Service Logic Apps Course: Update 1

By Rob Callaway

Lessons Learned

Over the last few months, everyone here at QuickLearn Training has learned a thing or two about the Azure App Service and Logic Apps team at Microsoft. The most obvious is that the team is full of Work-a-saurus-Rexes. The number of changes and added features since Azure App Service Logic Apps went into Public Preview (on March 24th) is astounding.

Here’s another thing we’ve learned: keeping up with those changes (and more importantly keeping our Cloud-Based Integration Using Azure App Service course up-to-date with those changes) is going to be a fascinating process. It seems like every day we discover something new or different and we have to decide the best way to incorporate it into our course. Honestly, with the cutting-edge technology, the always interesting integration stories, and awesome team that I work with, I’ve never had more fun designing a course.

Updates to Azure App Service Logic Apps

Enough with the praise! The real purpose of this entry is to provide a log of the updates that we’ve made to the course since our first run last month (May 6th – 8th).

  • Coverage of the updates and changes to Visual Studio templates introduced in the Azure SDK 2.6
  • Added coverage for the JSON encoder API App
  • Added lecture and labs on building custom API Apps that implement Push and Poll triggers
  • Added using the T-Rex Metadata Library to markup API App objects and create custom Swagger metadata for use by the Logic App Designer
  • Restructured the course to provide a more seamless flow through the various technologies

These changes represent a month’s worth of work for the QuickLearn team, and are additive to all the amazing content that we had previously.

Trust Us, We’re Professionals

Azure App Service Logic Apps are the future of the Microsoft integration story. If you haven’t looked at it yet, the time to start is now. If you have looked and you’re finding it hard to keep up with the rapid evolution, don’t fret because we have your back. It’s probably not your full-time job to stay up-to-date on these rapid changes, but it is ours. We love doing it and our team is committed to staying up-to-date on everything in the realm of Logic Apps, and we’re happy to help keep you up-to-date too. Your next chance to catch this exciting and fun class is July 13th, 2015.

As always, your purchase of our class comes with the ability to retake the course for free anytime within 6 months.

Announcement, Azure App Service, Blog , , , Leave a comment

Azure App Service Logic Apps in Visual Studio 2013 with Azure SDK 2.6

By Nick Hauenstein

As shown today in Ilya Grebnov, and Stephen Siciliano’s Build 2015 Session titled simply “Logic Apps”, there is now (as of the 29th actually) a nice project template for creating a deployment project containing a Logic App with separate per-environment parameters files. The deployment project is really scoped higher than the Logic App itself, it is instead a definition for an Azure Resource Group to be provisioned by Azure Resource Manager.

Azure Resource Group Project Template

Selecting the project template (found in the Cloud category as Azure Resouce Group) launches a dialog asking for the type of resource(s) that you would like the resource group project to start with. There are two resource types that include Logic Apps: Logic App, and Logic App and API App.

Logic App and API App resource selection dialog

Once created, the project (like any other Cloud Deployment Project up to this point) contains a PowerShell script to perform the actual deployment, along with a helper executable named AzCopy.exe. However, in addition to that, we not only get a file describing the deployment of an App Service Plan, Gateway, API App, and Logic App, we also get a parameters file — initially for a dev environment, but it is a step in the right direction and shows how to make it happen.

Resource Group Project Contents

How do we know that this parameters file will be used? Well the parameters file itself is actually a parameter within the Deploy-AzureResourceGroup.ps1 deployment script, and the default is to use dev:

image

Inside, you will find the parameters apiAppName, gatewayName, logicAppName, and svcPlanName.

Parameters

The definition for the Logic App itself is contained deep within the LogicAppAndAPIApp.json file (starting around line 271 in my test shown here):

Logic App Definition

It consists of a recurrence trigger (polling very hour) that invokes an operation with id of getValues on the deployed API App and outputs an array containing the value of the readValues property on the body of the API App response. I guess that’s the “Hello World” of the Logic App world, eh?

Code where Code Belongs

This represents a big step in the right direction for the team building Logic Apps. It’s putting code where code belongs, in the best IDE ever made and backed by proper source control. It also cleanly separates logic and configuration, enabling multiple environments.

However, without a visual editor, and an/or an quick/easy way to resolve API App ids from the marketplace, it’s going to be tough to build more complex flows in this fashion. I would also like to see the deployment spread across files. Imagine a resource group with multiple Logic Apps (a receive pipeline style Logic App, a process orchestration-style Logic App and a send pipeline style Logic App), working with that in one giant file would be a little bit painful.

In theory, there is a concept of a definitionLink to the body of the workflow itself (so as to not include it directly within the deployment script), but that’s not what the project template will give you:

image

That’s All From Build

I know that I wrote a lot for each of the major BizTalk events over the last 6 months, but for Build 2015, I’m going to keep it short and sweet and to the point. I’m juggling a lot of really cool things right now that I’m excited to share with you as soon as they’re ready. So stay tuned!

As a side note, BizTalk Server on-premise is going to be getting some love over the next year as well. Another major version is in the works, and you’d better bet that I’m going to be all over that as well.