Azure Logic Apps - Connectors vs HTTP Calls

Getting Started

In previous solutions I used a mixed of connectors that come out-of-the-box with Azure Logic Apps, as well as custom HTTP calls to do basicly the same but a bit different.

Today I will show the differences between using a connector that is already present or using a custom HTTP call, and when it will be the best (in my opinion) to use one or the other for your solutions.

To be able to make a good distinction between both lets check what is the use of thes connectors!

Connectors

Within Azure Logic Apps there are more then 300+ connectors available for all kind of different services.

Some of the connectors are built-in as it is called, and preform their opperations solely within the Logic Apps itself. A Great example of this would be the Data Operations Connector, which contains all kind of Data utilities you might need do some simple transformations.

Connectors that get their data from external sources can also be divided in two categories: first up, The Microsoft connectors for services like Sharepoint, Excel, OneDrive, Azure KeyVault, Azure Resource Mananger, Event Grid and more. Secondly, The thirdparty connectors for services such as Adobe, Salesforce, Twitter and more.

With this wide range of connectors available to us, you can create a lot of automation flows for your business needs and which also makes it easier due to their intuative interface.

Behind all the connectors with external sources lays an API that will be called. For example for all the Microsoft 365 connectors, the underlaying API is the Microsoft Graph. While most of these connectors contain the same options available to us as the API itself, this is not always the case. This could be some properties you need but you don't get these returned within the connector itself.

An example I resondly encountered were the Tags within the KeyVault. The KeyVault connector with the List Secret Action did not return the Tags of the Secrets, while I wanted to use them to find the Tag of the service the Secret was ment for. But when using the KeyVault API to list the Secrerts, the Tags did appear in the results.

While this is a minor thing for some specific use, there are also a major scenario for which it will be better to use the APIs itself via an HTTP Call.

HTTP Calls

Within your Logic App you can connect to different APIs via the HTTP Connector and the HTTP Request action. This allows you to connect to both REST as well as SOAP APIs and allows you to connect to more then there are connectors of within Logic Apps itself, but also to the already existing services to get a bit more details. A major advantage (in my option) is that the APIs to Microsoft services allow for Managed Identity Authentication if the Logic App is provided the required access to them. In itself this allows for a better connectivity and doesn't require any form of username and password.

Another Major advantage to this is when converting your Logic App to Infrastructure as Code (IaC), which doesn't need the additional loose API services to be coded as well, which is needed for connectors and can be sometimes be tedious when it comes to authentication methodes.

An example of this would be the API for Blob storage vs SQL Server. Both have MSI build within the connector itself, but within the IaC they are both called different. For Blob storage this needs to be specified as managedIdentityAuth but for SQL Server this is oauthMI. With HTTP Calls you don't need those additional API Connections to be coded, which can save time and a headache to figure out those things.

To help with this if every needed, I created an Bicep module:

param subscriptionID string 
param location string 
param apiName string 
param apiConnector string

var authentication = (apiConnector == 'sql') ? 'oauthMI' : 'managedIdentityAuth'

resource APIconnector 'Microsoft.Web/connections@2018-07-01-preview' = {
  name: apiName
  location: location
  kind: 'V1'
  properties: {
    displayName: apiName
    alternativeParameterValues: {}
    customParameterValues: {}
    api: {
      name: apiName
      id: '/subscriptions/${subscriptionID}/providers/Microsoft.Web/locations/${location}/managedApis/${apiConnector}'
      type: 'Microsoft.Web/locations/managedApis'
    }
    parameterValueSet: {
            name: authentication
            values: {}
    }
  }
}

But I need to emphasize that HTTP Calls are not all glorious, they also have lack in functionality. Some connectors have some amazing integrations options for Triggers, which HTTP Calls don't have. An example here would be to react on a Sharepoint or SQL Change or something like a new Topic within an Event Grid. Besides Triggers, some connectors don't have an public API to call upon to make request the data you need, such as the SQL Server Connector to execute Queries or Stored Procedures.

Conclusion

As stated both have their own pros and cons when using either a connector or the API behind it. As a general rule of thumb I would recommand Connectors for the ease of use, but when you need specific data or authentication methodes that a Connector doesn't offer but are possible via the API, then use the API.

What's Next?

Next week is a busy week with a lot of visits to clients as well as international events, so the blog will have to wait a bit but will be more than worth it! Stayed tuned an see you in two weeks!