Développer un workflow dans une Azure Logic App standard qui se connecte à d’autres ressources implique de choisir les connecteurs à utiliser. Pour cela, deux types de connecteurs existent : Built-in (intégrés) et Managed (gérés). Nous allons ici examiner les différences entre ces deux types de connecteurs.
Les connecteurs définissent les actions et les déclencheurs pouvant être utilisés pour implémenter un workflow dans une Logic App. Ils varient d’actions basiques, comme l’initialisation d’une variable ou l’itération sur les valeurs d’un tableau, à des actions plus complexes, comme la connexion à un serveur SFTP pour télécharger un fichier ou l’envoi d’un message vers un Service Bus.
Les connecteurs peuvent être disponibles soit en tant que connecteurs Built-in (service provider connections), soit en tant que connecteurs Managed (API connections), certains étant disponibles dans les deux formats. Les connecteurs Built-in s’exécutent nativement au sein du workflow, tandis que les connecteurs Managed agissent généralement comme un wrapper autour d’une API utilisée pour communiquer avec le service.
Bien que les différences fonctionnelles entre les connecteurs Built-in et Managed puissent être minimes, elles peuvent aussi impacter leurs capacités. Par exemple, le connecteur Built-in pour Azure Service Bus peut gérer des messages de grande taille, tandis que le connecteur Managed a une limite de 1 Mo par message (voir ici).
Un autre exemple concerne le connecteur Azure Blob Storage. Son déclencheur Built-in traite tous les blobs existants lors de sa première exécution. Ensuite, à chaque exécution, il traite les fichiers ajoutés ou modifiés, y compris dans les sous-dossiers. En revanche, le déclencheur du connecteur Managed ignore les fichiers existants et se concentre uniquement sur le répertoire racine.
Des différences apparaissent également lorsque la Logic App s’exécute au sein d’un réseau virtuel (VNet).
Cela a un impact sur la stratégie d’accès aux systèmes. Par exemple, si un pare-feu est en place, des règles de sortie peuvent être nécessaires pour permettre à la Logic App d’accéder aux connecteurs Managed. Si le connecteur Managed utilise une passerelle (gateway) dans le même VNet que la Logic App, il peut réintégrer le réseau via cette passerelle. Cela peut être une solution en cas de règles de sécurité complexes.
Les connecteurs Built-in sont directement inclus dans le déploiement (CI/CD) du workflow de la Logic App. Ils sont gérés via un fichier JSON qui contient les service provider connections et leurs informations associées dans une section spécifique. S’il y a des connecteurs Managed, les informations de connexion seront dans une section séparée du même fichier
Mais comme les connecteurs Managed sont des ressources indépendantes qui doivent être déployées séparément. Bien que le fichier JSON serve à créer un lien entre la Logic App et le connecteur Managed, le connecteur lui-même est créé en dehors de la Logic App.
Comme les connecteurs Managed sont des ressources distinctes exécutées sur un cluster différent de la Logic App, ils nécessitent un On-Premises Data Gateway (OPDG) pour se connecter à des systèmes on-premise (serveurs SQL, systèmes de fichiers, etc.). Les connecteurs Build-in peuvent, eux, se connecter directement aux ressources situées dans le Virtual Network ou dans les réseaux appairés.
En revanche, un avantage des connecteurs Managed est qu’ils peuvent être partagés entre plusieurs Logic Apps au sein du même groupe de ressources. Cela permet une centralisation des mises à jour d’identifiants, directement au niveau du connecteur.
Dans une Logic App Standard exécutée sur un App Service Plan, les actions et déclencheurs utilisant des connecteurs Built-in sont gratuits et inclus dans le plan standard.
Les connecteurs Managed, en revanche, sont facturés à l’appel, selon la même tarification que les Logic Apps en mode Consumption.
Le choix entre connecteurs Built-in et connecteurs Managed repose donc sur plusieurs critères :
