Utiliser des connecteurs dans Azure Functions

Azure Functions s’intègre à la plateforme de connecteurs managés sur laquelle reposent Logic Apps et Power Platform, offrant ainsi à vos fonctions un accès à des connecteurs vers des systèmes tels qu’Office 365, Microsoft Teams et de nombreux services tiers. Les fonctions ajoutent un modèle de déclencheur basé sur un connecteur et un SDK de connecteur pour recevoir des événements externes et appeler des opérations de connecteur à partir du code de fonction dans la même application. Vous écrivez la logique métier ; la plateforme de connecteurs gère l’enregistrement des webhooks, les flux OAuth, le rafraîchissement des jetons et les nouvelles tentatives.

Note

Les connecteurs dans Azure Functions sont en préversion publique. Les fonctionnalités, les noms de configuration et les connecteurs pris en charge peuvent changer avant la disponibilité générale. L’utilisation de cette fonctionnalité est soumise aux conditions d’utilisation complémentaires relatives aux préversions de Microsoft Azure.

Overview

Les connecteurs étendent le modèle de programmation Azure Functions avec deux fonctionnalités qui ciblent des services externes :

déclencheurs Connector : une fonction s’exécute lorsqu’un événement se produit dans un service externe, tel qu’un nouvel e-mail dans Office 365, un fichier ajouté à SharePoint ou OneDrive, ou un message publié dans Microsoft Teams. L’environnement d’exécution expose une liaison connectorTrigger qui reçoit des rappels de webhook en provenance de l’espace de noms du connecteur.
Actions du Kit de développement logiciel (SDK) du connecteur : le code de fonction appelle les opérations du connecteur via les clients à partir du Kit de développement logiciel (SDK) du connecteur. Le kit de développement logiciel couvre les connecteurs organisés (tels que Office 365 Outlook, Utilisateurs d’Office 365, Microsoft Teams, SharePoint et OneDrive) avec des modèles fortement typés. D’autres connecteurs sont accessibles via des modèles de charge utile dynamique.

Une application de fonction unique combine des déclencheurs et des actions de connecteur avec les liaisons que vous utilisez déjà, notamment HTTP, minuteur, file d’attente, Service Bus, Event Grid et Durable Functions.

Important

Le Connector Namespace est une ressource Azure distincte gérée par la plateforme des connecteurs. Il héberge des configurations de déclencheur de connecteur et des connexions sortantes, et gère l’authentification auprès des systèmes SaaS. Cet article décrit comment Functions consomme cette ressource. Pour plus d’informations, consultez Qu’est-ce que l’espace de noms connecteur Azure ?.

La préversion est disponible comme suit :

Région de l’espace de noms du connecteur – USA Centre Ouest (westcentralus). Votre application de fonction peut être déployée dans n’importe quelle région qui prend en charge le plan d’hébergement choisi.
Langages - .NET 10 et .NET 8 avec Worker isolé, Python 3.13+ et Node.js 22+ (JavaScript et TypeScript). Java, PowerShell et Go ne sont actuellement pas pris en charge.
Plans d’hébergement - Flex Consumption (recommandé), Premium, Dédié (plan App Service) et Azure Container Apps.
Pricing - La tarification Azure Functions standard s’applique. Aucun frais supplémentaire n’est facturé pour le déclencheur de connecteur ou le Kit de développement logiciel (SDK) pendant la préversion. La ressource d’espace de noms Connector dispose de sa propre facturation.

Quand utiliser des connecteurs

Utilisez des connecteurs lorsque la forme d’intégration, et non le code brut, domine la charge de travail. Les instructions suivantes décrivent les scénarios dans lesquels les connecteurs dans Functions sont adaptés :

Vous réagissez à des événements provenant de systèmes SaaS (nouveaux e-mails, invitations de calendrier, fichiers, éléments de liste, activité Teams) et vous souhaitez éviter d’avoir à développer l’enregistrement des webhooks, les échanges de validation et le renouvellement des jetons OAuth.
Votre code de fonction appelle déjà des API SaaS Microsoft 365 ou tierces via des clients HTTP développés maison, et la prolifération des paramètres de connexion (secrets, autorisations, stratégie de réessai) devient une charge de maintenance.
Vous étendez une application pilotée par les événements qui s’exécute déjà sur Functions et vous souhaitez que les déclencheurs SaaS se trouvent dans le même projet, pipeline de déploiement et pile d’observabilité.
Vous créez des flux de travail agentiques où une fonction reçoit un événement, des raisons avec un modèle IA, puis retourne dans un système SaaS par le biais d’une opération de connecteur.
Vous avez besoin d’un contrôle de l’orchestration par le code (branchements conditionnels, authentification personnalisée entre les étapes, réutilisation de bibliothèques .NET, Python ou Node.js existantes), mais vous souhaitez que les connecteurs prennent en charge l’intégration entrante et sortante.

Si la charge de travail est une orchestration pure entre les connecteurs sans code personnalisé, Logic Apps Standard reste le choix le plus direct. Consultez Liens avec les autres options d’intégration Azure.

Packages et prérequis

Chaque langage pris en charge dispose d’un petit nombre de packages qui incluent la liaison de déclenchement et les clients connecteurs typés.

La liaison de déclencheur du connecteur est fournie dans le package d’extension du worker ; les charges utiles typées et les clients du kit de développement logiciel sont fournis dans les packages Azure.Connectors.Sdk.* (un par connecteur).

dotnet add package Microsoft.Azure.Functions.Worker.Extensions.Connector --prerelease
dotnet add package Azure.Connectors.Sdk --prerelease

Pour le worker .NET isolé, utilisez net8.0 ou net10.0 ainsi que la version la plus récente du worker Functions.

Python utilise le bundle d’extensions en version préliminaire pour charger la liaison de déclencheur et le package azurefunctions-extensions-connectors pour les modèles Office 365 typés. Ajoutez le bundle à host.json :

{
    "version": "2.0",
    "extensionBundle": {
        "id": "Microsoft.Azure.Functions.ExtensionBundle.Preview",
        "version": "[4.42.0, 5.0.0)"
    }
}

Installez les packages d’exécution et d’extension :

pip install "azure-functions>=2.2.0b4"
pip install azurefunctions-extensions-connectors

Le décorateur @app.connector_trigger fonctionne pour tous les types de connecteurs. Les modèles de charge utile typés sont activement développés et ajoutés via le azurefunctions-extensions-connectors package. Pour les connecteurs sans modèles typés, la charge utile doit être traitée comme une chaîne.

Node.js utilise le bundle d’extensions expérimental pour charger la liaison de déclenchement. Ajoutez le bundle à host.json :

{
    "version": "2.0",
    "extensionBundle": {
        "id": "Microsoft.Azure.Functions.ExtensionBundle.Preview",
        "version": "[4.42.0, 5.0.0)"
    }
}

Installez la bibliothèque Functions et les packages de connecteur :

npm install @azure/functions
npm install @azure/functions-extensions-connectors
npm install @azure/connectors

Utilisez les points d’entrée typés dans @azure/functions-extensions-connectors (par exemple, connectors.office365.onNewEmail) lorsque des modèles typés existent ; utilisez app.connectorTrigger depuis @azure/functions pour n’importe quel connecteur lorsque vous souhaitez obtenir le payload brut.

Java et PowerShell ne sont pas pris en charge dans la préversion publique. Consultez langues pour obtenir la liste actuelle des runtimes pris en charge.

Déclencheurs basés sur le connecteur

Un déclencheur basé sur un connecteur déclenche votre fonction lorsqu’un événement se produit dans un service externe. L’espace de noms du connecteur transmet l’événement à votre application de fonction via le point de terminaison webhook de l’extension du connecteur :

POST /runtime/webhooks/connector?functionName={FunctionName}&code={connector_extension_key}

{FunctionName} correspond au nom indiqué dans l’attribut [Function] (.NET), @app.function_name (Python) ou l’enregistrement du déclencheur (Node.js). {connector_extension_key} est la valeur d’une clé système nommée connector_extension que l’extension provisionne au premier démarrage. Vous récupérez la clé avec la Azure CLI :

az functionapp keys list \
    --resource-group <resource-group> \
    --name <function-app> \
    --query "systemKeys.connector_extension" \
    --output tsv

La configuration du déclencheur dans votre espace de noms du connecteur stocke cette URL de rappel et transmet la clé système à chaque rappel. Le runtime Functions valide la clé avant d’appeler votre fonction. Pour une topologie sans secret, vous pouvez placer l’authentification intégrée App Service devant l’application de fonction et valider un jeton d’identité managée à partir de l’espace de noms du connecteur ; consultez .NET exemple : authentification intégrée avec l’identité managée pour le modèle complet.

Tip

Utilisez le plan Flex Consumption pour les fonctions déclenchées par le connecteur pendant la préversion. Consommation flexible offre la prise en charge de la mise à l’échelle par instance et de l’identité gérée, conformément au modèle d’authentification de la plateforme de connecteurs.

Les charges utiles de requête portent le corps de l’événement ainsi qu’un ensemble d’en-têtes x-ms-* qui identifient la configuration du déclencheur, la connexion, le type d’événement et un ID de corrélation. Lorsque le connecteur dispose d’un modèle SDK typé, l’environnement d’exécution peut désérialiser la charge utile directement dans ce modèle ; pour les connecteurs sans modèle typé, votre fonction reçoit le corps JSON brut.

L’exemple suivant montre une fonction qui se déclenche lorsqu’un nouvel e-mail arrive dans une boîte aux lettres Office 365 Outlook. L’inscription du déclencheur est par langue ; la configuration du déclencheur dans l’espace de noms du connecteur est la même dans tous les cas.

using Microsoft.AspNetCore.Mvc;
using Microsoft.Azure.Functions.Worker;
using Microsoft.Azure.Functions.Worker.Extensions.Connector;
using Azure.Connectors.Sdk.Office365.Models;
using Microsoft.Extensions.Logging;

public class OnNewEmail
{
    private readonly ILogger<OnNewEmail> _logger;

    public OnNewEmail(ILogger<OnNewEmail> logger) => _logger = logger;

    [Function("OnNewEmail")]
    public IActionResult Run(
        [ConnectorTrigger()] Office365OnNewEmailTriggerPayload payload)
    {
        var emails = payload?.Body?.Value ?? [];
        foreach (var email in emails)
        {
            _logger.LogInformation(
                "Received email from {From} with subject '{Subject}'.",
                email.From, email.Subject);
        }

        return new OkResult();
    }
}

Le modèle Office365OnNewEmailTriggerPayload et d’autres types de charge utile d’opération proviennent de Azure.Connectors.Sdk.Office365.Models. Pour obtenir la correspondance complète entre les opérations et les charges utiles, consultez Correspondance des opérations avec les signatures Azure Functions dans le dépôt de l’extension.

import azure.functions as func
import json
import logging

app = func.FunctionApp()

@app.function_name(name="OnNewEmail")
@app.connector_trigger(arg_name="payload")
def on_new_email(payload: str) -> None:
    data = json.loads(payload)
    emails = data.get("body", {}).get("value", [])
    for email in emails:
        logging.info(
            "Received email from %s with subject '%s'.",
            email.get("from"), email.get("subject"))

Pour l’opération Office 365 OnNewEmailV3 en particulier, vous pouvez utiliser le décorateur typé de azurefunctions-extensions-connectors :

import azure.functions as func
import azurefunctions.extensions.connectors.office365 as office365
import logging

app = func.FunctionApp()

@app.function_name(name="OnNewEmail")
@app.connector_trigger(arg_name="email")
def on_new_email(email: office365.ClientReceiveMessage) -> None:
    logging.info(
        "Received email from %s with subject '%s'.",
        email.from_, email.subject)

import { InvocationContext } from '@azure/functions';
import {
    connectors,
    EmailTriggerContext,
} from '@azure/functions-extensions-connectors';

connectors.office365.onNewEmail('OnNewEmail', {
    handler: async (
        context: EmailTriggerContext,
        invocationContext: InvocationContext,
    ) => {
        for (const email of context.emails) {
            invocationContext.log(
                `Received email from '${email.from}' with subject '${email.subject}'.`,
            );
        }
    },
});

Pour tout connecteur qui n’a pas encore de point d’entrée typé, utilisez le générique app.connectorTrigger à partir de @azure/functions:

import { app, InvocationContext } from '@azure/functions';

app.connectorTrigger('OnNewItem', {
    handler: async (payload: unknown, context: InvocationContext) => {
        const data = typeof payload === 'string' ? JSON.parse(payload) : payload;
        const items: Record<string, unknown>[] = (data as any)?.body?.value ?? [];
        for (const item of items) {
            context.log(`Item ID: ${item.Id}`);
        }
    },
});

Le déclencheur du connecteur n’est pas disponible dans cette langue dans le cadre de la version préliminaire publique.

Vous créez la configuration du déclencheur dans l’espace de noms du connecteur à l’aide des Azure CLI, ARM ou Bicep. Cette étape fait partie du périmètre de la plateforme des connecteurs et est documentée dans la documentation relative aux connecteurs. Functions n’inclut pas ses propres commandes de configuration pour l’enregistrement du déclencheur.

Authentification entre Azure Functions et l’espace de noms du connecteur

Tip

Exemple fonctionnel de bout en bout : functions-connectors-net-builtinauth

Le modèle d’authentification par défaut utilise une clé système partagée (connector_extension) que le namespace du connecteur transmet à chaque callback. Pour les charges de travail de production qui nécessitent des topologies sans secret, vous pouvez configurer l’espace de noms du connecteur pour s’authentifier auprès de votre application de fonction à l’aide d’une identité managée et appliquer cette authentification à la périphérie de l’application de fonction à l’aide de l’authentification intégrée App Service (également appelée Authentification simple).

Dans ce schéma, l’espace de noms du connecteur utilise sa propre identité gérée affectée par le système ou identité gérée affectée par l’utilisateur pour générer un jeton Entra ID pour chaque rappel. L’application de fonction valide ce jeton, y compris son audience, son émetteur et l’ID d’objet de l’appelant avant qu’une requête n’atteigne l’hôte Functions. Aucune clé partagée, aucun secret client, n’importe où.

Configuration de l’application de fonction

L’authentification intégrée s’exécute en périphérie du processus de travail App Service, avant que l’environnement d’exécution de Functions ne traite la requête. Vous la configurez via la propriété authsettingsV2 ARM (ou son équivalent dans Bicep) :

Setting	Purpose
`requireAuthentication: true`	Rejette une requête sans jeton valide (retourne 401).
`identityProviders.azureActiveDirectory.enabled: true`	Valide les jetons Entra ID.
`registration.clientId`	L’ID d’application (client) de l’inscription d’application Entra par rapport à laquelle l’authentification intégrée valide les jetons.
`registration.openIdIssuer`	URL de l’émetteur pour votre locataire : `https://login.microsoftonline.com/{tenantId}/v2.0`.
`validation.allowedAudiences`	ID client et URI d’identificateur de l’application Entra. Les jetons doivent inclure l’une de ces audiences dans la réclamation `aud`.
`validation.defaultAuthorizationPolicy.allowedPrincipals.identities`	ID d’objet (principal) des identités gérées autorisées à appeler la fonction. Seule l’identité gérée de l’espace de noms du connecteur doit être répertoriée ici. Tout jeton avec une revendication différente `oid` obtient un 403.

L’application de fonction a également besoin d’une identité gérée attribuée par l’utilisateur fédérée à l’enregistrement d’application Entra. L’authentification intégrée utilise cette information d’identification fédérée (FIC) pour générer des assertions client pour l’application Entra sans stocker de secret client. Le modèle Bicep définit clientSecretSettingName comme un paramètre d’application qui contient l’ID client de l’identité gérée attribuée par l’utilisateur, afin d’indiquer à l’authentification intégrée d’utiliser FIC au lieu d’un secret.

Vous pouvez également désactiver la vérification de la clé du système pour le point de terminaison du webhook du connecteur en configurant "extensions": { "connector": { "system": { "webhookAuthorizationLevel": "Anonymous" } } } dans host.json, car la vérification du jeton Entra est désormais active.

Configuration de l’espace de noms du connecteur

L’espace de noms du connecteur doit avoir une identité gérée attribuée par le système ou par l’utilisateur, activée et associée. Lorsque vous créez la configuration du déclencheur, vous spécifiez authentication.type = ManagedServiceIdentity et authentication.identity = <resource-id-of-managed-identity> (pour l’utilisateur affecté) ou omettez identity (pour le système affecté). Vous spécifiez également authentication.audience = <entra-app-client-id> pour que l’environnement d’exécution du connecteur sache quelle audience demander dans le jeton.

Le runtime du connecteur utilise ensuite cette identité managée pour générer un jeton Entra ID à chaque rappel. Le iss (émetteur) du jeton est votre tenant, le aud (audience) est l’ID client de l’application Entra, et le oid (ID d’objet) est l’ID principal de l’identité gérée. L’authentification intégrée valide les trois.

La ressource d’espace de noms Connector elle-même doit également avoir accès à la connexion (par exemple, la connexion office365). Vous accordez cet accès via une stratégie d’accès qui répertorie l’ID principal de l’identité managée. L’exemple bicep montre le câblage complet pour l’identité de l’espace de noms et la stratégie d’accès aux connexions.

Qu’est-ce qui est appliqué ?

L’authentification intégrée valide les jetons dans l’ordre :

Présence de jeton - Jeton manquant ou expiré → 401
Signature : vérifié par rapport au jeu de clés web de l’émetteur pour votre locataire
iss (émetteur) - Doit correspondre openIdIssuer
aud (audience) – Doit être dans allowedAudiences
oid (ID d’objet/principal) : doit correspondre à l’une des identités dans allowedPrincipals.identities. Toute autre identité → 403

Comme cette vérification s’exécute en périphérie d’App Service, votre code de fonction ne reçoit jamais de requête qui ne provienne pas de l’identité managée du Connector Namespace. Aucun code d’application n’est nécessaire pour la vérification d’accès.

Flux d’authentification

┌─────────────────────────────────────────────────────────────────┐
│  Connector Namespace  (westcentralus)                           │
│  • System-assigned or user-assigned managed identity enabled    │
│  • Trigger config: authentication.type = ManagedServiceIdentity |
│                    authentication.audience = <Entra app ID>     │
│                    callbackUrl = https://<func>/runtime/…       │
└────────────────────────┬────────────────────────────────────────┘
                         │
                         │  POST callbackUrl
                         │  Authorization: Bearer <AAD token>
                         │     iss = your tenant
                         │     aud = Entra app clientId
                         │     oid = managed identity principalId
                         ▼
┌──────────────────────────────────────────────────────────────┐
│  Function App  (any region)                                  │
│                                                              │
│   ┌──────────────────────────────────────────────────────┐   │
│   │ Built-in authentication  (App Service edge)          │   │
│   │   • Validates signature, iss, aud, exp               │   │
│   │   • Checks oid ∈ allowedPrincipals.identities        │   │
│   │   → No token  → 401                                  │   │
│   │   → Wrong oid → 403                                  │   │
│   └────────────────────┬─────────────────────────────────┘   │
│                        │ pass                                │
│                        ▼                                     │
│   ┌──────────────────────────────────────────────────────┐   │
│   │ /runtime/webhooks/connector                          │   │
│   │   (webhookAuthorizationLevel = Anonymous)            │   │
│   └────────────────────┬─────────────────────────────────┘   │
│                        ▼                                     │
│   ┌──────────────────────────────────────────────────────┐   │
│   │ Your function(payload)                               │   │
│   └──────────────────────────────────────────────────────┘   │
└──────────────────────────────────────────────────────────────┘
                        ▲
                        │ FIC (federated identity credential)
        ┌───────────────┴────────────────┐
        │  Entra app registration         │
        │  (federated to function-app MI) │
        └─────────────────────────────────┘

Important

Cette section traite de l’authentification entre l’espace de noms du connecteur et votre application de fonctions, ainsi que de la façon dont le moteur d’exécution du connecteur prouve son identité lors de l’appel de la fonction. L’authentification depuis l’espace de noms du connecteur vers le service cible (par exemple, Microsoft 365, Teams ou SharePoint) relève de l’équipe Connectors et est gérée via la ressource de connexion sur l’espace de noms du connecteur. Ce flux d’authentification est hors de portée pour cet article. Consultez Vue d’ensemble des connecteurs Azure pour le modèle d’authentification connecteur-à-SaaS.

Utilisation de connecteurs dans votre code

Le Kit de développement logiciel (SDK) du connecteur permet à votre fonction d’appeler des opérations de connecteur en tant qu’actions sortantes. La surface cliente utilise la même connexion sous-jacente du Connector Namespace que celle utilisée par les déclencheurs, de sorte qu’une seule connexion puisse prendre en charge à la fois les déclencheurs entrants et les appels sortants pour le même compte SaaS.

Dans .NET, chaque connecteur fournit un client typé (par exemple, Office365Client, Office365UsersClient, TeamsClient) dans Azure.Connectors.Sdk.{Service}. Le constructeur du client accepte l’URL d’exécution de la connexion et un TokenCredential permettant de s’authentifier auprès de celle-ci. Enregistrez des clients dans Program.cs et injectez-les dans vos fonctions.

Le schéma suivant provient de l’exemple Teams de recherche d’utilisateurs par e-mail de bout en bout :

using Azure.Core;
using Azure.Identity;
using Azure.Connectors.Sdk.Office365;
using Azure.Connectors.Sdk.Office365Users;
using Azure.Connectors.Sdk.Teams;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;

var credential = new DefaultAzureCredential(new DefaultAzureCredentialOptions
{
    ManagedIdentityClientId = Environment.GetEnvironmentVariable("AZURE_CLIENT_ID")
});

var host = new HostBuilder()
    .ConfigureFunctionsWebApplication()
    .ConfigureServices(services =>
    {
        services.AddSingleton<TokenCredential>(credential);

        services.AddSingleton(sp => new Office365Client(
            new Uri(Environment.GetEnvironmentVariable("OFFICE365_CONNECTION_RUNTIME_URL")!),
            sp.GetRequiredService<TokenCredential>()));

        services.AddSingleton(sp => new Office365UsersClient(
            new Uri(Environment.GetEnvironmentVariable("OFFICE365USERS_CONNECTION_RUNTIME_URL")!),
            sp.GetRequiredService<TokenCredential>()));

        services.AddSingleton(sp => new TeamsClient(
            new Uri(Environment.GetEnvironmentVariable("TEAMS_CONNECTION_RUNTIME_URL")!),
            sp.GetRequiredService<TokenCredential>()));
    })
    .Build();

host.Run();

Les paramètres *_CONNECTION_RUNTIME_URL pointent vers le point de terminaison du runtime par connexion dans l’espace de noms du connecteur. Injectez les clients dans votre fonction et appelez des méthodes typées telles que UserProfileAsync, GetEmailsAsyncou FlagAsync. Vous pouvez également appeler des clients du Kit de développement logiciel (SDK) à partir de déclencheurs non connecteurs (par exemple, un déclencheur HTTP qui publie sur Teams).

Dans Python, installez azure-connectors pour les clients typés (par exemple, office365, teams, office365Users). Les clients acceptent l’URL d’exécution pour chaque connexion et des informations d’identification. La couverture des actions du SDK continue de s’étendre pendant la phase de préversion ; consultez le dépôt Connectors Python SDK pour connaître la liste actuelle.

Dans Node.js, installez @azure/connectors pour les clients typés (par exemple, office365, teams, office365Users). Les clients acceptent l’URL d’exécution pour chaque connexion et des informations d’identification. La couverture des actions du KIT DE DÉVELOPPEMENT logiciel (SDK) s’étend pendant la préversion ; vérifiez le dépôt Connectors Node.js SDK pour obtenir la liste actuelle.

Le Kit de développement logiciel (SDK) du connecteur n’est pas disponible dans cette langue pour la préversion publique.

Principaux scénarios

Traitement déclenché par e-mail

Une fonction se déclenche sur chaque nouvel e-mail dans un dossier Office 365 Outlook surveillé. Il classifie le message, appelle le connecteur Office 365 pour lire les messages récents du même expéditeur à des fins d’enrichissement, puis effectue une action telle que l’indicateur de l’e-mail, le déplacement vers un dossier ou la notification d’un canal Teams. La fonction ne conserve jamais de jeton d’actualisation ; c’est la connexion au sein de l’espace de noms du connecteur qui le conserve.

interaction Microsoft Teams et Microsoft Graph

Une fonction réagit à l’activité Teams ou publie des cartes dans un canal via le connecteur Teams, et recherche les utilisateurs avec le connecteur Utilisateurs d’Office 365 pour les vérifications dans l’organisation et les recherches de gestionnaire. Combinez les deux connecteurs avec Microsoft Graph pour gérer les actions opérationnelles sur l’appartenance au groupe ou les licences avant l’exécution d’un chemin de code.

Flux de travail agentiques

Le modèle de déclencheur de connecteur et le kit de développement logiciel s’intègrent au runtime d’assistants sans serveur d’Azure Functions. Une fonction d’agent reçoit un événement SaaS, l’analyse à l’aide d’un modèle et utilise les clients des kits de développement logiciel (SDK) des connecteurs comme outils pour exécuter des actions dans le système source ou dans un autre service SaaS. Cet article ne détaille pas le modèle de programmation de l’agent lui-même ; consultez l’article des agents serverless pour le modèle complet.

Relation avec d’autres options d’intégration Azure

Les connecteurs dans Azure Functions sont additifs. Le bon choix dépend de la quantité de code personnalisé dont la charge de travail a besoin et de la surface de création que l’équipe préfère.

Logic Apps Standard. Si la charge de travail est principalement orchestration entre les connecteurs et que l’équipe préfère un concepteur visuel, utilisez Logic Apps Standard. Logic Apps possède l’expérience de création à faible code pour le même écosystème de connecteurs et reste le produit de référence pour les flux de travail pilotés par le concepteur. Choisissez Logic Apps lorsque le code entre les étapes est minimal et que la valeur se trouve dans l’orchestration.

Azure Functions avec des connecteurs. Si la charge de travail est axée sur le code (logique de branchement personnalisée, bibliothèques in-process, intégration avec d’autres liaisons Azure Functions ou appels à des modèles d’IA entre le déclencheur et l’action), utilisez Functions avec des connecteurs. Vous développez en .NET, Python ou Node.js, vous conservez le modèle de déploiement Functions et la pile d’observabilité, et vous évitez d’écrire le code d’infrastructure des webhooks et de gérer OAuth à la périphérie du SaaS.

Déclencheurs HTTP avec des SDK de service. Si aucun connecteur managé n’existe pour le système cible, ou si vous avez besoin d’un contrôle au niveau du protocole que l’abstraction du connecteur masque, restez sur une fonction déclenchée par HTTP qui appelle directement le Kit de développement logiciel (SDK) de service. Cette approche vous laisse responsable de l’authentification, de la nouvelle tentative et de la validation du webhook, mais elle n’a aucune dépendance à l’espace de noms du connecteur.

Une application de fonction unique peut combiner les trois modèles. Vous pouvez ajouter un déclencheur de connecteur à une application existante avec déclencheur HTTP et adopter progressivement des clients SDK.

Étapes suivantes

Commentaires

Cette page a-t-elle été utile ?

Last updated on 2026-06-03