Objective

To create, deploy and use a custom Connector that can be used in Azure Logic Apps. We also want to be able to publish this connector in the gallery (so that it shows up in the list with other connectors). For now the latter appears to be primarily available as invite-only for Microsoft partners.

Disclaimer

During my research it became clear that Azure and the Microsoft Flow services are constantly changing, both in terms of functionality and user interface. What follows are based on my experience at the time of this writing. By the time you read this there have likely been additional changes.

What you need to know first

1. Custom connectors are just ASP.NET Web API applications.
2. An action (the functionality provided by a connector) in Microsoft Flow and Logic Apps relates directly to an operation in your Web API – The connector/action executes the configured operation from your Web API.
3. While it’s technically not required, you’re going to want your Web API to be described using Swagger (aka OpenAPI Specification). Microsoft uses an extended Swagger spec to provide additional information and functionality to the connector.
4. Logic Apps will timeout an HTTP request after 1 minute (the documentation for Flow says 90 seconds). If the call to your Web API might take longer you will need to implement the async pattern.

Microsoft Flow / Azure Logic Apps

Logic Apps are an outgrowth of BizTalk and various workflow platforms from Microsoft. They are a way to build workflows that can integrate with a variety of external services. Think IFTTT with the ability to provide more logic, or Yahoo! Pipes.

Flow is kind of a “lite” version of Logic Apps. Flows use the same connectors as Logic Apps, but expose less of their functionality and have fewer options for linking connectors. Microsoft Flow is a direct competitor to IFTTT.

Workflows in both consist of actions. These actions come in two flavors:

• Triggers – Every workflow must start with a trigger action. Triggers are executed in response to some event. There are two types of triggers:
  • Polling triggers periodically check status (e.g. by calling a Web API) and only take action when the status conditions are met.
  • Push triggers, sometimes called webhooks, provide a special endpoint for the Logic App. When that endpoint is called from an external process with the appropriate values the workflow starts.
• “Normal” actions – This encompasses all non-trigger actions. These respond to the previous action and may pass their data on to the next action.

There are already several good tutorials on-line that cover the basics of creating Flows and Logic Apps, so I’m not going to go into that here. These are a few that I recommend:

• Getting started with Microsoft Flow
• Azure Logic Apps – Post to Twitter
• Create a new logic app connecting SaaS services
• How to Automate Business Processes Using Azure Logic Apps
• Design, build, and deploy Azure Logic Apps in Visual Studio

Because Microsoft Flow and Logic Apps both allow the user to select the same connector/actions from the gallery, we will start by adding our Custom API to Flow. Once there it can be rolled out for Logic Apps.

The built-in HTTP connectors

If you don’t need your custom API to be in the gallery where other users can select it to include in their own Flows the easiest way to access it is with one of the built-in connectors:

• HTTP is for Web APIs that don’t have a Swagger description. The user will need to provide the HTTP method (e.g. POST), URL, headers, body and authentication information when added to the Flow.
• HTTP + Swagger requires a Swagger endpoint URL for your API. The user will then be asked to select an operation provided by the service. There are a variety of libraries that can dynamically add Swagger to your API.
• HTTP Webhook allows push notifications into the Flow. The user will need to provide the same information as for HTTP above – for both subscribe and unsubscribe endpoints. Configuring a webhook is beyond the scope of this article. See Using webhooks with Microsoft Flow.

Custom APIs

What we’re looking to do, however, is provide our own branded connector that customers can choose from the gallery instead of one of the built-in HTTP connectors. In Microsoft Flow, this is referred to as a Custom API. In Logic Apps this is referred to as a connector.

To register a Custom API for use in your flows click the gear icon in the top right and select Custom APIs.

On the next page click the Create custom API button:

1. Upload the Swagger file that describes your API. (As of this writing the process will only accept an uploaded file. It will not accept a URL.)
2. Upload an icon that represents your service. While the icon is required, it is already pre-populated with a generic image.
3. Provide a description if you like.
4. The Host and Base URL should be filled in from the contents of the Swagger file.
5. Click Continue.
6. Select the authentication method required by our API. You may be prompted for additional information.
7. Click the Definition tab. This page shows the operations, parameters, entities, etc. that Flow found in your Swagger file. You may fine-tune names, descriptions, etc. here.

When done click Create API in the top right. If successful, your API should be listed on the Custom API page. From here you can create Connections, edit or remove the API.

T-Rex = Swagger + MS extensions

You may have noticed near the end of the steps in the previous section that a lot of cleanup was needed on the Definition screen. Maybe you needed to provide friendlier names, descriptions or set visibility.

Microsoft has provided the following extensions to the Swagger specification which covers some of these situations:

• x-ms-summary provides a display name.
• x-ms-visibility allows an element to be hidden from the UI or behind an “advanced” dialog.
• x-ms-trigger denotes a trigger as well as what type.
• x-ms-dynamic-values indicates that the values come from some other process (e.g. the result of another operation).
• x-ms-dynamic-schema indicates that the format of the values is dynamic.

For more details see Customize your Swagger definition for Microsoft Flow.

Maintaining these extensions in your API’s Swagger by hand could become a real headache, so a Microsoft MVP by the name of Nick Hauenstein has created a library for that. T-Rex extends the Swashbuckle library, which generates Swagger for ASP.NET WebAPI applications, with additional attributes to generate the Microsoft extensions listed above.

Here is an example from the T-Rex documentation:

[Trigger(TriggerType.Poll, typeof(SamplePollingResult))]
[Metadata("Roll the Dice", "Roll the dice to see if we should trigger this time")]
[SwaggerResponse(HttpStatusCode.BadRequest, "Bad configuration. Dice require 1 or more sides")]
[HttpGet, Route("diceRoll")]
public HttpResponseMessage DiceRoll(string triggerState,
                                    [Metadata("Number of Sides", "Number of sides that should be on the die that is rolled")]
                                    int numberOfSides,
                                    [Metadata("Target Number", "Trigger will fire if dice roll is above this number")]
                                    int targetNumber)

NOTE: At the time of this writing the stable release of T-Rex only includes support for the summary, visibility and trigger extensions.

Creating a connection

After the Custom API has been registered you will need to create a connection to it before it can be used in a Flow.

From the Custom API page, click the plus (+) icon for the API you want to connect to. Enter the connection information when prompted then click the Create Connection button.

That’s it! You can now select your Custom API from the list of actions in a Flow.

Getting into the public gallery

Following the previous steps, your Custom API will only be available to you, your team and others you share it with – using the same connection (including credentials) you created. It will not be available to all Flow users. Nor will it be available to Logic Apps.

To get your Custom API into the public gallery, where it can be used by anybody, you will need to contact Microsoft. They will review and test the Custom API and, if approved, make the necessary changes to require each user to set up their own connection. Only then will they make it available to all users.

Once your Custom API is in the Flow gallery Microsoft will incrementally roll it out across data centers for use in Azure Logic Apps.

Additional references

• Using Web APIs as a Custom API in Microsoft Flow
• Integrating a Custom API with Flow
• Create a new logic app connecting SaaS services
• Get started with API Apps, ASP.NET, and Swagger in Azure App Service
• Deploy your first web app to Azure in five minutes
• Deploy an ASP.NET web app to Azure App Service, using Visual Studio
• Call custom APIs hosted on Azure App Service with Azure Logic Apps
• Diagnosing logic app failures
• Microsoft videos
• Build holistic integration solutions using Azure Logic Apps and API Management from Connect(); // 2016
• Integrate all of the things! from AzureCon 2015
• Integrating your Systems with Logic Apps from Build 2016
• Online forums for Microsoft Flow

So, I’ve been working for K2 for about a year-and-a-half now and am still enjoying being part of an actual software company again. Today I found out they’ve produced a new How To video for the product I’ve been the primary developer on for the last year or so.

This component is a broker that connects to a RESTful web service and exposes its entities and methods as K2 SmartObjects – which can be used in workflows, reports and other K2 blackpearl or Appit processes.

The area outlined by the blue box below is the functionality I am responsible for:

Just finished watching the ReSharper Secrets video on the JetBrainsTV channel on YouTube. Several good tips there. Definitely worth watching. The presenter spends the bulk of the time talking about Annotations – which are how ReSharper works a lot of its magic and are now available to us for decorating our own code. He closes by sharing a few of his own favorite features he thinks are not very well known. I didn’t know most of them.

Managing database projects within Visual Studio can be extremely confusing. There seems to be very little information out there on how to use the provided project templates properly, and what little there is is often cryptic and clearly written by insiders. Watch this blog for a forthcoming article which will hopefully clear up some of this confusion, but for now I wanted to share what I’ve learned about referencing other, existing databases from within your Visual Studio database project.

With the 2010 release, Visual Studio’s database project templates appear to want you to encapsulate your entire database within the project – and the IDE. This can create a problem when the new database you’re creating needs to reference some objects from another database on the server (an enterprise data store, for example) – since the project doesn’t know anything about this other database two things happen:

1. You lose those handy Intellisense^TM tips when referencing the external database, and
2. Attempting to build and/or deploy the project spews a bunch of errors about missing references.

An afternoon of hunting revealed that there are a couple of ways to address this – one of which involves creating another project, importing the other database, and then adding a reference to the first project. I don’t know about you, but that sounds like an awful lot of work and overhead for what’s essentially a Reference link.

Fortunately, there is a slightly easier way: The key is the .dbschema file. These files represent the compiled state of a database which is ready to be deployed with Visual Studio or some other tool. But what is useful for us here is that Visual Studio can also use these files to determine what objects are in the database – providing Intellisense^TM and reference mapping. So this is what we need to do:

1. Create a .dbschema file for the external database we want to reference
2. Add that file to your SQL Server 2008 Database Project

Creating the .dbschema file

The reason some people recommend creating another database project in Visual Studio is because that will create the .dbschema file for you, but there is also a handy tool you can use by the name of VsDbCmd. This command-line tool for deploying Visual Studio database projects can be found in the following location:

C:Program FilesMicrosoft Visual Studio 10.0VSTSDBDeployvsdbcmd.exe

(Note: It will be in C:Program Files (x86) on 64-bit Windows.)

While most of the documentation out there focuses on how VsDbCmd can be used to deploy database projects, it can also be used to generate a .dbschema file from an existing database. To do this, use the following syntax:

vsdbcmd /a:Import /cs:”ConnectionString” /dsp:Sql /model:DatabaseName.dbschema

Where ConnectionString is the full connection string for the database you want, and DatabaseName is the name of the file to create.

Adding the Reference

Now that you’ve created the file, it’s time to add it to your Visual Studio project as a Database Reference. Expand the project node in the Solution Explorer, right-click References, then select Add Database Reference…. Finally, make the following changes to the Add Database Reference dialog:

• Select the Database project schema radio button, and Browse to the .dbschema file you just created.
• Check the Define database variable box and enter the name of the external database for the following values:
  • Name:  $(DatabaseName)
  • Value:  DatabaseName
• Check the box that says Update the existing schema object definitions and scripts to use the database reference variables.

After clicking OK, and a bit of processing on Visual Studio’s part, you should now be able to compile your database project without errors.

Please feel free to comment below if you have any questions or information to add.

• Database references in visual studio database project question on the MSDN forums.
• Database References at Home of the Data Dude.
• How to: Import a Schema from a Command Prompt in the MSDN Library.