Azure Enterprise Integration Series – Part 3

Azure Enterprise Integration Series

Part 3: Visual Studio and Project
Types

This is the third in a series of 12 blog posts on Azure Enterprise
Integration.

Each blog post is accompanied by a video that covers the same
content.

Part
1: Challenges in Enterprise Integration Development in Azure – video
Part
2: Azure Resource Manager Overview – video
Part
3: Visual Studio and Project Types – video
Part 4: Visual Studio Build and Deployment – video
Part 5: VSTS Build and Deployment – video
Part 6: Layout and Naming Conventions – video
Part 7: Security and Identity Management – video
Part 8: Exception Handling and Logging – video
Part 9: Monitoring and Operations – video
Part 10: Common Patterns – video
Part 11: Designing an Azure Integration Solution – video
Part 12: Putting it all together – video

1. Visual Studio Development

As an enterprise integration developer, Azure gives you some new
choices. Foremost amongst those is the ability to develop code *outside of Visual
Studio*. Whilst that is the norm for most open-source and non-Microsoft technologies
(e.g. Python, Ruby, anything developed on a non-Windows PC), for most Microsoft integration
developers, developing outside of Visual Studio may take you outside of your comfort
zone.

In fact, when Logic Apps first debuted, much was made of the fact
that you could develop in your browser – a revolutionary idea (to Microsoft developers)
and one that Microsoft have put a lot of time and effort into.

In fact, the early versions of Visual Studio Online were focused
around you being able to write. Test, and deploy C# code from your browser, the legacy
of which still carries on with Azure Functions today.

But developing in a browser introduces its own concerns: how you
do manage your code, how do you source control it, what about promoting it to different
environments, etc.

Some organisations love the idea of browser development: these are
organisations that have jumped whole-heartedly on the Agile bandwagon, use Git and
Scrum, release regularly, and much prefer a lighter-weight development process.

But for most Enterprises, Visual Studio is where it’s at: it complements
our existing development processes; reduces training on new development techniques;
and is familiar to most of the developers we employ.

2. Project Types

Although Visual Studio contains templates for many different types
of projects, we’re only interested in a subset of them for Azure integration development:

Visual Studio Project Type	Supported Azure Resources
Azure Resource Group	API Connection App Service Azure SQL Server1 Integration Account2 Logic Apps3 Service Bus Storage Account etc.
Azure Functions	Functions
ASP.NET Web Application	Web App4 Mobile App4 API App4
Integration	Integration Account contents (schemas etc.) 3
Web Job	Web Job
SQL Server Database	Database objects (tables etc.) 2

There are a few discrepancies with the project types though:

1 An Azure SQL Server is
defined in an ARM template, although the SQL entities (databases, tables, stored procedures,
etc.) need to be defined in a separate SQL Server Database project.

2 At the current time, the Integration project
type doesn’t support the creation of the actual Integration
Account in Azure, so you need a separate Azure
Resource Group project that contains the ARM Template
for the Integration Account.

3 Although Logic Apps are created in an Azure
Resource Group project, they have their own designer.
They are the only resource in an Azure Resource Group project that has a dedicated
designer.

4 The ASP.Net Web Application project
type contains the code for web applications, but doesn’t define the App
Service or App Service Plan (ASP):
you need a separate ARM Template for this. Although you can create the App Service/ASP
at the time you publish from Visual Studio, this doesn’t allow you put the definition
for the App Service/ASP in source control.

Most of the project types we use for integration development can
be found in the cloud category:

The rest of this section covers the individual project types.

2.1 ASP.NET Web Application Project

The ASP.NET Web Application project
template covers most Azure App Service technologies (Web Apps, API Apps, Mobile Apps).

After selecting this option (and entering the project/solution name
details), you are given a dialog where you can select the type of ASP.NET technology,
and whether you want to host in in Azure:

Note: If you’re using the Visual Studio
testing framework, we suggest you select the option to Add
unit tests in the above dialog – this will create a
separate Unit Tests project with an example of a unit test.

The example in the image above shows that we wish to create an Azure
API App and to host it in Azure.

Selecting the Host in the cloud option
will cause a secondary dialog to appear, which is used to create an App Service and
create/select an App Service Plan (this is the same dialog used when you choose the
Publish option):

Remember: An App Service is equivalent
to an IIS Application, and the App Service Plan defines
the type of Server Farm your application is hosted on (i.e. how many servers, types
of servers, how much memory you have, etc.).

We recommend that you *don’t* select the option to host in Azure at project
creation: the rationale behind this is that you still must supply the same information
in an ARM template (i.e. the App Service and App Service Plan) to deploy the App Service
(and your ASP.NET application) from VSTS.

Note: Although Visual Studio can create
an App Service/App Service Plan for this app (via the Publish option), we recommend
creating a separate Azure Resource Group project
in Visual Studio that contains an App Service and App
Service Plan for this ASP.NET
Web Application project. This Resource Group Project
can then be deployed from both Visual Studio and VSTS.

Note: One thing that the above dialog is
useful for, is creating an ARM Template that specifies your App Service and App Service
Plan: if you fill in the dialogue, and then click the Export… button,
it will save an ARM Template file that you can use in an Azure
Resource Group project, and you can then cancel out
of the dialog.

2.2 API App Project

API Apps are a type of ASP.NET Web Application project,
and are created by selecting that option under Cloud projects. The API App template
is then selected:

The API App template in Visual Studio creates a stubbed MVC REST
app, with a Swagger interface:

The developer then modifies this stub to implement the required functionality:
the actual REST methods are contained in the ValuesController.cs file.

2.3 Azure Functions Project

An Azure Functions project is a specialization
of an ASP.NET Web Application project: Functions
are hosted in a Function App, which is a specialized version of an App Service (technically,
Functions are a type of Web Job, which is a type of App Service). Function Apps also
use an App Service Plan: A Function App can use
a standard App Service Plan (which limits
the number of executions, but is charged at a regular monthly amount); or it can use
a dynamic App Service Plan (known as consumption billing),
where you pay per execution. The Azure Functions project
in Visual Studio represents the Function App that needs to exist in Azure.

Note: Functions can also be authored in
the portal, but this is not recommended as any changes are not automatically reflected
in Source Control in VSTS.

The Azure Functions project
template is (as of this writing) in preview – therefore its capabilities (and its
location) may change in future.

To create an Azure Functions project, select the template from the
New Project screen:

This will create a stub Function App project that looks like this:

An Azure Functions project
can contain one or more functions – each function will be in a separate folder in
the project. When the project is first created, it will contain no functions – functions
can be added by the “Add” option in the project:

The New Azure Function dialog allows
you to select the type of function to create:

A function will consist of several files, depending on the template
chosen. The example shown (and discussed) below is for a C# Generic Webhook function:

The function and function app files shown are:

File Name	Level	Description
function.json	Function	Contain settings for the function e.g. type of trigger, type of output, whether it starts disabled etc. For Logic App functions, you shouldn’t need to edit this, if a Generic WebHook template was used.
project.json	Function	Contains a list of dependencies this function needs from NuGet (or locally).
run.csx	Function	Contains the source code for the function.
sample.dat	Function	Contains sample data that works with the sample code in run.csx.
appsettings.json	Function App	Contains settings that affect the Function App App Service.
host.json	Function App	Contains information about the host used with the App Service.
Project_Readme.html	Function App	Read Me file, is displayed by Visual Studio when an Azure Functions project is first created.

Note: support is being added to functions
for ability to use code from a pre-compiled assembly; and additionally, to have a
parent function that can look at a request and forward it to a child function (function
proxy). Neither of these features are available in Visual Studio now, but moving forward
it will make sense to have a separate C# Library project that contains classes with
the function code in them: this will allow for easier unit testing and editing.

Note: Although an Azure Functions project
has a Publish option, the Function App it deploys is broken, and not visible from
Logic Apps. For this reason, we recommend creating a separate Azure
Resource Group project in Visual Studio that contains
an App Service and App
Service Plan for the Function App.

The default run.csx file
for a C# Generic Webhook project looks like this:

2.4 Azure Resource Group Project

The Azure Resource Group project type
lets you manage resources specified via ARM Templates.

When you create an Azure Resource Group project,
you can choose to start from a number of pre-populated ARM Templates (including QuickStart
templates from GitHub), or from a blank ARM Template:

Notice that Logic Apps are one of the items in the list – if you select this
option, you get a stub Logic App (i.e. something that the Logic App designer recognises
as a Logic App and which it can open). Note that this assumes you have installed the
Logic App tooling for Visual Studio.

Note: The link to download the Logic App
visual studio extension can be found at the end of this article.

For some resources, e.g. Service Bus Namespaces, Storage Accounts,
API Connections, etc., there is no template: you must start with a blank ARM Template
file and add the content yourself.

No matter which template you select, you’ll end up with a project
with 3 files in it:

File Name	What	Description
azuredeploy.json	An ARM Template	A JSON file that describes what should be created.
azuredeploy.parameters.json	An ARM Template parameters file	A JSON file which contains values passed in to the ARM template. Note: although only one of these is created, the idea is to create multiple template files, one for each environment.
Deploy-AzureResourceGroup.ps1	A Deployment PowerShell script	Contains a default script that creates the Resource Group and then deploys the ARM Template. This is the script that Visual Studio executes when you select the Deploy option for the project. Changing the name of this file will break the ability to deploy this project from Visual Studio.

When you right-click the project file and select Deploy, you’re given
the option of selecting an existing deployment, or creating a new one. All this does
is pre-populate the name of the ARM Template file to use, the Parameter file to use,
and the subscription being used:

Creating a new deployment prompts us to select the Subscription,
Resource Group, ARM Template, Parameters File, and also allows us to edit the parameter
values:

When we kick off a deployment, all that happens is that Visual Studio executes
the Deploy-AzureResourceGroup.ps1 using
the values supplied above.

For this reason, it is important that you don’t edit the Deploy-AzureResourceGroup.ps1 file
unless you are extending the deployment in some fashion.

2.5 Integration Account Project

An Integration Account project type
is used to create and store XSD Schemas and Transforms used with Azure Integration
Accounts.

It is created via this option:

When the project is created, it has no resources in it.

Selecting the “Add New Item” gives 3 options:

The available items are:

Item Name	Description
Flat File Schema	Opens the BizTalk Flat File Parser wizard, allowing you to build a flat-file schema (for use with the Flat File Parsing connectors in Logic Apps) from a sample flat file (e.g. csv or positional file).
XML Schema	Opens the BizTalk Schema Editor, which allows you to create/edit an XSD file.
Map	Opens the BizTalk Mapper, which allows you to create or edit a BTM map file.

There are a couple of restrictions with this project type:

You can’t install the Integration Account type on the same PC that
has BizTalk Server installed – they use the same components and don’t currently play
nice with each other
Only Visual Studio 2015 is supported (at this time)
The BTM files generated by the mapper are converted into XSLT files
(stored in the bin folder) when the project is built
You can’t put maps in folders: they need to stay in the root folder
There is no option to create an Integration
Account nor publish the schemas/maps to an existing Integration
Account from this project

Note: The link to download the Integration
Account project extension can be found at the end of this article.

Note: We recommend that you create a separate Azure
Resource Group project that will create the Integration
Account in Azure and deploy the schemas/maps from this project. The script for this
will be covered in the next article/video.