Developing a workflow in a standard Azure Logic App that connects to other resources means selecting what connectors to use. For that purpose, two types of connector exist : Built-in and Managed. Here we will look at the differences between the two types of connectors.
The connectors define the actions and triggers that can be used to implement a logic app workflow. They vary from basic actions like initializing a variable or looping on an array value to more complex actions like connecting to an SFTP to upload a file or sending a Service Bus message.
Connectors can be available either as built-in connectors (service provider connections) or managed connectors (API connections), with some being available in both formats. Built-in connectors run natively within the workflow. Managed connectors generally act as a wrapper around an API used to communicate with the service.
While the functional differences between built-in and managed connectors can be minor, they can also have effects on the capabilities of the connectors. For example, while the built-in connector for Azure Service Bus can handle large messages, the managed connector has a maximum message size of 1MB (see here).
Another example is the Azure Blob Storage connector. Its built-in connector trigger processes all the existing blobs the first time it is run. Then for all subsequent runs, it processes any that are added or updated, including in subfolders. The managed connector trigger ignores existing files and focuses on the root folder only.
Differences also come up when the logic app runs from within a virtual network (VNet).
This has an impact on system strategy and rules for access. For example with a firewall, outbound rules may be necessary to allow the logic app to access the managed connectors. If the managed connector uses a gateway in the same VNet as the logic app, it re-enters the network via the gateway. This can also solve connection issues when more complex security rules are in place.
Built-in connectors are bundled in with the CI/CD of the logic app workflow. They are handled with a JSON file that contains the service provider connections and their associated connection information in a dedicated section. If managed connectors are used, the information for the managed API connections is in a separate section of the same file.
The difference is that the managed connectors are independent entities that have to be deployed. While the JSON file serves to create a link between the logic app and the managed connector, the connector itself is created separately.
Because managed connectors are separate resources running in a different cluster from the logic app, they require an on-premises data gateway (OPDG) to connect to any on-premise systems such as file systems or SQL Servers. In-app connectors, on the other hand, can connect directly to resources that are in the virtual network or paired networks.
However because the managed connectors are separate from the logic app, they can be shared among logic apps within the same resource group. This allows for updates to credentials to be centralized to the connector itself.
For a standard logic app on an app service plan, actions and triggers using built-in connectors are free and included in the standard plan.
Managed connectors, on the other hand, are billed by call with the same pricing as the Consumption logic apps.
Choosing between Built-in and Managed connectors means taking into consideration multiple aspects:
