Usare i connettori in Funzioni di Azure

Funzioni di Azure si integra con la piattaforma di connettori gestiti alla base di Logic Apps e Power Platform, fornendo alle funzioni l'accesso a connettori per sistemi come Office 365, Microsoft Teams e molti servizi di terze parti. Le funzioni aggiungono un modello di trigger basato su connettore e un SDK del connettore in modo da ricevere eventi esterni e chiamare le operazioni del connettore dal codice della funzione nella stessa app. Si scrive la logica di business; la piattaforma del connettore gestisce la registrazione del webhook, i flussi OAuth, l'aggiornamento dei token e i nuovi tentativi.

Note

I connettori in Funzioni di Azure sono in anteprima pubblica. Le funzionalità, i nomi di configurazione e i connettori supportati possono cambiare prima della disponibilità generale. L'utilizzo di questa funzionalità è soggetto alle condizioni d'uso supplementari per le versioni di anteprima di Microsoft Azure.

Overview

I connettori estendono il modello di programmazione Funzioni di Azure con due funzionalità destinate ai servizi esterni:

  • trigger Connector: una funzione viene eseguita quando si verifica un evento in un servizio esterno, ad esempio un nuovo messaggio di posta elettronica in Office 365, un file aggiunto a SharePoint o OneDrive o un messaggio inviato a Microsoft Teams. Il runtime espone un connectorTrigger binding che riceve i callback del webhook dal namespace del connettore.
  • Azioni dell'SDK del connettore : il codice della funzione chiama le operazioni del connettore tramite i client dell'SDK del connettore. L'SDK include connettori curati (ad esempio Office 365 Outlook, Utenti di Office 365, Microsoft Teams, SharePoint e OneDrive) con modelli fortemente tipizzati. Altri connettori sono raggiungibili tramite modelli di payload dinamici.

Una singola app per le funzioni combina trigger e azioni del connettore con le associazioni già usate, tra cui HTTP, timer, coda, bus di servizio, Griglia di eventi e funzioni durevoli.

Importante

Lo spazio dei nomi del connettore è una risorsa Azure separata di proprietà della piattaforma dei connettori. Ospita le configurazioni dei trigger del connettore e le connessioni in uscita e gestisce l'autenticazione nei sistemi SaaS. Questo articolo descrive come le funzioni utilizzano tale risorsa. Per altre informazioni, vedere Che cos'è Azure Connector Namespace?.

L'anteprima ha la disponibilità seguente:

  • Area geografica per il namespace del connettore - Stati Uniti centro-occidentali (westcentralus). L'app per le funzioni può essere distribuita in qualsiasi area che supporta il piano di hosting scelto.
  • Lingue: .NET 10 e .NET 8 ruoli di lavoro isolati, Python 3.13+ e Node.js 22+ (JavaScript e TypeScript). Java, PowerShell e Go non sono attualmente supportati.
  • Piani di hosting - A consumo flessibile (consigliato), Premium, Dedicato (piano di App Service), e App contenitore di Azure.
  • Pricing - Si applicano i prezzi Funzioni di Azure Standard. Non sono previsti costi aggiuntivi per il trigger del connettore o l'SDK durante l'anteprima. La risorsa Connector Namespace ha una fatturazione propria.

Quando usare i connettori

Usare i connettori quando la forma di integrazione, non il codice non elaborato, domina il carico di lavoro. Le istruzioni seguenti descrivono gli scenari in cui i connettori in Funzioni sono la scelta appropriata:

  • Reagisci agli eventi nei sistemi SaaS (nuove email, inviti di calendario, file, elementi di elenco, attività di Teams) e vuoi evitare di scrivere il codice per la registrazione dei webhook, gli handshake di verifica e il rinnovo dei token OAuth.
  • Il codice della funzione chiama già Microsoft 365 o API SaaS di terze parti tramite client HTTP sviluppati internamente, e la proliferazione delle connessioni (segreti, ambiti di autorizzazione, criteri di ritentativo) sta diventando un onere di manutenzione.
  • Si estende un'app guidata dagli eventi che è già in esecuzione in Funzioni e si vogliono attivare trigger SaaS nello stesso progetto, pipeline di distribuzione e stack di osservabilità.
  • Stai creando workflow agentici in cui una funzione riceve un evento, ragiona con un modello di IA e quindi agisce su un sistema SaaS tramite un’operazione di connettore.
  • È necessario il controllo code-first sull'orchestrazione (diramazione, autenticazione personalizzata tra passaggi, riutilizzo di .NET esistenti, Python o librerie di Node.js), ma si vuole che i connettori siano proprietari dell'integrazione in ingresso e in uscita.

Se il carico di lavoro consiste esclusivamente nell'orchestrazione tra i connettori, senza codice personalizzato, Logic Apps Standard rimane la scelta più diretta. Vedere Relazione con altre opzioni di integrazione di Azure.

Pacchetti e prerequisiti

Ogni linguaggio supportato include un numero limitato di pacchetti che forniscono il binding del trigger e i client tipizzati per i connettori.

Il binding trigger del connettore è incluso nel pacchetto di estensione del worker; i payload tipizzati e i client SDK sono inclusi nei pacchetti Azure.Connectors.Sdk.* (uno per ogni connettore).

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

Per il worker isolato di .NET, usare come destinazione net8.0 o net10.0 e la versione più recente del worker di funzioni.

Python usa il pacchetto di estensioni in anteprima per caricare il binding del trigger e il pacchetto azurefunctions-extensions-connectors per i modelli Office 365 tipizzati. Aggiungere il bundle a host.json:

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

Installare i pacchetti di runtime ed estensione:

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

Il decoratore @app.connector_trigger funziona per tutti i tipi di connettori. I modelli di payload tipizzati vengono sviluppati e aggiunti attivamente tramite il azurefunctions-extensions-connectors pacchetto. Per i connettori senza modelli tipizzati, il payload deve essere considerato come stringa.

Node.js usa il pacchetto di estensioni sperimentale per caricare il binding del trigger. Aggiungere il bundle a host.json:

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

Installare la libreria di Funzioni e i pacchetti del connettore:

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

Usare i punti di ingresso tipizzati in @azure/functions-extensions-connectors (ad esempio , connectors.office365.onNewEmail) quando esistono modelli tipizzati. Usare app.connectorTrigger da @azure/functions per qualsiasi connettore quando si desidera il payload non elaborato.

Java e PowerShell non sono supportati nell'anteprima pubblica. Vedere Lingue per l'elenco corrente dei runtime supportati.

Trigger basati su connettore

Un trigger basato su connettore attiva la funzione quando si verifica un evento in un servizio esterno. Lo spazio dei nomi del connettore recapita l'evento all'app per funzioni tramite HTTPS, attraverso l'endpoint webhook dell'estensione del connettore:

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

{FunctionName} corrisponde al nome nell'attributo [Function] (.NET), @app.function_name (Python) o nella registrazione del trigger (Node.js). {connector_extension_key} è il valore di una chiave di sistema chiamata connector_extension che l'estensione crea al primo avvio. La chiave viene recuperata con il interfaccia della riga di comando di Azure:

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

La configurazione del trigger nello spazio dei nomi del connettore memorizza l'URL di callback e include la chiave di sistema in ogni callback. Il runtime di Funzioni convalida la chiave prima di richiamare la funzione. Per una topologia senza segreti, è possibile usare l'autenticazione predefinita di App Service davanti all'app per funzioni e convalidare un token di identità gestita dal namespace del connettore; vedere esempio .NET: autenticazione predefinita con identità gestita per lo schema completo.

Tip

Usare il piano Flex Consumption per le funzioni attivate dal connettore durante l'anteprima. Flex Consumption offre supporto per la scalabilità per istanza e per le identità gestite, in linea con il modello di autenticazione della piattaforma dei connettori.

I payload di richiesta contengono il corpo dell'evento insieme a una serie di x-ms-* intestazioni che identificano la configurazione del trigger, la connessione, il tipo di evento e un ID di correlazione. Quando il connettore ha un modello SDK tipizzato, il runtime può deserializzare il payload direttamente in tale modello; per i connettori senza modelli tipizzati, la funzione riceve il corpo JSON non elaborato.

L'esempio seguente mostra una funzione che viene attivata quando arriva un nuovo messaggio di posta elettronica in una cassetta postale di Office 365 Outlook. La registrazione del trigger è per lingua; la configurazione del trigger nello spazio dei nomi del connettore è la stessa in tutti i casi.

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();
    }
}

Il modello Office365OnNewEmailTriggerPayload e altri tipi di payload dell'operazione provengono da Azure.Connectors.Sdk.Office365.Models. Per la mappatura completa tra operazioni e payload, consultare Mapping delle operazioni alla firma delle funzioni Azure nel repository dell'estensione.

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"))

Per l'operazione Office 365 OnNewEmailV3 nello specifico, è possibile usare il decoratore tipizzato di 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}'.`,
            );
        }
    },
});

Per qualsiasi connettore che non dispone ancora di un punto di ingresso tipizzato, usare il generico app.connectorTrigger da @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}`);
        }
    },
});

L'attivatore del connettore non è disponibile in questa lingua per l'anteprima pubblica.

Si crea la configurazione del trigger nel namespace del connettore usando interfaccia della riga di comando di Azure, ARM o Bicep. Questo passaggio fa parte dell'ambito della piattaforma dei connettori ed è documentato nella raccolta di contenuti relativa ai connettori. Functions non include comandi di configurazione propri per la registrazione dei trigger.

Autenticazione tra Funzioni di Azure e lo spazio dei nomi del connettore

Tip

Esempio end-to-end funzionante: functions-connectors-net-builtinauth

Il modello di autenticazione predefinito usa una chiave di sistema condivisa (connector_extension) presentata dallo spazio dei nomi del connettore in ogni callback. Per i carichi di lavoro di produzione che richiedono topologie prive di segreti, è possibile configurare il namespace del connettore in modo che si autentichi all'app per le funzioni usando un'identità gestita e applicare tale autenticazione sul perimetro dell'app per le funzioni usando l'autenticazione predefinita di App Service (detta anche Easy Auth).

In questo modello, lo spazio dei nomi del connettore usa una propria identità gestita assegnata dal sistema o identità gestita assegnata dall'utente per generare un token Entra ID per ogni callback. L'app per le funzioni convalida il token, verificandone il destinatario, l'emittente e l'ID oggetto del chiamante, prima che qualsiasi richiesta raggiunga l'host di Functions. Nessuna chiave condivisa, nessun segreto client, ovunque.

Configurazione dell'app per le funzioni

L'autenticazione predefinita viene eseguita all'edge del ruolo di lavoro di App Service, prima che il runtime di Functions riceva la richiesta. È possibile configurarla tramite la proprietà authsettingsV2 ARM (o equivalente in Bicep):

Setting Purpose
requireAuthentication: true Rifiuta qualsiasi richiesta senza un token valido (restituisce 401).
identityProviders.azureActiveDirectory.enabled: true Convalida i token di Entra ID.
registration.clientId L'ID dell'app (client) della registrazione dell'app Entra rispetto alla quale l'autenticazione integrata convalida i token.
registration.openIdIssuer URL dell'emittente per il tenant: https://login.microsoftonline.com/{tenantId}/v2.0.
validation.allowedAudiences L'ID client e l'URI identificatore dell'app Entra. I token devono contenere uno di questi destinatari nel claim aud.
validation.defaultAuthorizationPolicy.allowedPrincipals.identities Gli ID oggetto (entità) delle identità gestite autorizzate a chiamare la funzione. Qui deve essere indicata solo l'identità gestita dello spazio dei nomi del connettore. Qualsiasi token con un'attestazione diversa oid ottiene un valore 403.

L'app per le funzioni richiede anche un'identità gestita assegnata dall'utente federata alla registrazione dell'app Entra. L'autenticazione integrata usa tale credenziale di identità federata (FIC) per generare asserzioni client per l'app Entra senza dover archiviare un segreto client. Il modello Bicep imposta clientSecretSettingName su un'impostazione dell'app che contiene l'ID client dell'identità gestita assegnata dall'utente, specificando all'autenticazione integrata di usare FIC anziché un segreto.

È anche possibile disabilitare il controllo della chiave di sistema per l'endpoint webhook del connettore impostando "extensions": { "connector": { "system": { "webhookAuthorizationLevel": "Anonymous" } } } in host.json, poiché il controllo del token Entra è ora attivo.

Configurazione dello spazio dei nomi del connettore

Lo spazio dei nomi del connettore deve avere un'identità gestita assegnata dal sistema o dall'utente, abilitata e associata. Quando si crea la configurazione del trigger, si specificano authentication.type = ManagedServiceIdentity e authentication.identity = <resource-id-of-managed-identity> (per l'identità assegnata dall'utente) oppure si omette identity (per l'identità assegnata dal sistema). È anche possibile specificare authentication.audience = <entra-app-client-id> in modo che il runtime del connettore conosca il gruppo di destinatari da richiedere nel token.

Il runtime del connettore utilizza quindi tale identità gestita per generare un token Entra ID a ogni callback. iss del token (emittente) è il tenant, aud (destinatario) è l'ID client dell'app Entra e oid (ID oggetto) è l'ID principale dell'identità gestita. L'autenticazione predefinita convalida tutti e tre.

Anche la risorsa dello spazio dei nomi del connettore stessa deve avere accesso alla connessione (ad esempio, alla connessione office365). Concedi questo accesso tramite un criterio di accesso che elenca l'ID principale dell'identità gestita. L'esempio Bicep mostra la configurazione completa sia per l'identità del namespace sia per il criterio di accesso alla connessione.

Elementi applicati

L'autenticazione predefinita convalida i token in ordine:

  1. Presenza del token - Token mancante o scaduto → 401
  2. Firma: verificata rispetto al JWKS dell'emittente per il tenant
  3. iss (emittente) - Deve corrispondere a openIdIssuer
  4. aud (gruppo di destinatari): deve trovarsi in allowedAudiences
  5. oid (ID oggetto/entità): deve corrispondere a una delle identità in allowedPrincipals.identities. Qualsiasi altra identità → 403

Poiché questo controllo viene eseguito nel perimetro di App Service, il codice della funzione non riceve mai una richiesta che non provenga dall'identità gestita del namespace del connettore. Per il controllo di accesso non è necessario alcun codice dell'applicazione.

Flusso di autenticazione

┌─────────────────────────────────────────────────────────────────┐
│  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) │
        └─────────────────────────────────┘

Importante

Questa sezione descrive l'autenticazione tra il namespace del connettore e l'app per le funzioni e come il runtime del connettore dimostra la propria identità quando chiama la funzione. L'autenticazione dal namespace del connettore al servizio a monte (ad esempio Microsoft 365, Teams o SharePoint) è di competenza del team dei connettori ed è gestita attraverso la risorsa di connessione nel namespace del connettore. Il flusso di autenticazione non rientra nell'ambito di questo articolo. Vedere Azure connectors overview per il modello di autenticazione dal connettore al SaaS.

Contenuti correlati

Uso dei connettori nel codice

L'SDK del connettore consente alla funzione di chiamare le operazioni del connettore come azioni in uscita. L'interfaccia client usa la stessa connessione sottostante al namespace del connettore utilizzata dai trigger, quindi una singola connessione può supportare sia i trigger in ingresso sia le chiamate in uscita per lo stesso account SaaS.

In .NET ogni connettore fornisce un client tipizzato (ad esempio, Office365Client, Office365UsersClient, TeamsClient) in Azure.Connectors.Sdk.{Service}. Il costruttore del client richiede l'URL di runtime della connessione e un TokenCredential che consente di autenticarsi alla connessione. Registrate i client in Program.cs e iniettarli nelle funzioni.

Lo schema seguente proviene dall'esempio di Teams end-to-end per la ricerca dell'utente tramite email:

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();

Le impostazioni *_CONNECTION_RUNTIME_URL puntano all'endpoint di runtime relativo a ciascuna connessione nello spazio dei nomi del connettore. Inserisci i client nella tua funzione e chiama metodi tipizzati come UserProfileAsync, GetEmailsAsync o FlagAsync. È anche possibile chiamare i client SDK da trigger che non usano connettori, ad esempio un trigger HTTP che pubblica in Teams.

In Python, installa azure-connectors per i client tipizzati (ad esempio, office365, teams, office365Users). I client accettano l'URL di runtime per ogni connessione e una credenziale di accesso. La copertura delle azioni SDK è in espansione durante la fase di anteprima; consultare il repository Python SDK Connectors per l'elenco attuale.

In Node.js, installare @azure/connectors per i client tipizzati (ad esempio, office365, teams, office365Users). I client accettano l'URL di runtime per ogni connessione e una credenziale di accesso. La copertura delle azioni dell'SDK è in espansione durante la fase di anteprima; consulta il repository Connectors Node.js SDK per l'elenco aggiornato.

L'SDK del connettore non è disponibile in questa lingua per l'anteprima pubblica.

Scenari chiave

Elaborazione attivata dalla posta elettronica

Una funzione si attiva per ogni nuovo messaggio di posta elettronica in una cartella monitorata di Office 365 Outlook. Classifica il messaggio, chiama il connettore di Office 365 per leggere i messaggi recenti dallo stesso mittente per l'arricchimento e quindi esegue un'azione come contrassegnare il messaggio di posta elettronica, spostarlo in una cartella o notificare un canale di Teams. La funzione non conserva mai un refresh token; lo fa invece la connessione nel namespace del connettore.

Interazione tra Microsoft Teams e Microsoft Graph

Una funzione risponde all'attività di Teams o pubblica schede in un canale tramite il connettore Teams e cerca gli utenti con il connettore Utenti di Office 365 per eseguire verifiche all'interno dell'organizzazione e individuare i responsabili. Combinare i due connettori con Microsoft Graph per controllare le azioni operative sull'appartenenza al gruppo o sulle licenze prima dell'esecuzione di un percorso di codice.

Flussi di lavoro agentici

Il modello di trigger del connettore e l'SDK si integrano con il runtime serverless degli agenti di Funzioni di Azure. Una funzione di agente riceve un evento SaaS, lo analizza mediante un modello e utilizza i client SDK del connettore come strumenti per eseguire azioni nel sistema di origine o in un altro servizio SaaS. Questo articolo non descrive in dettaglio il modello di programmazione dell'agente stesso; vedere l'articolo relativo agli agenti serverless per il modello completo.

Relazione con altre opzioni di integrazione Azure

I connettori in Funzioni di Azure sono additivi. La scelta giusta dipende da quanto codice personalizzato richiede il carico di lavoro e dall'ambiente di creazione preferito dal team.

Logic Apps Standard Se il carico di lavoro consiste principalmente nell'orchestrazione tra i connettori e il team preferisce un designer visivo, usa Logic Apps Standard. Logic Apps offre l'esperienza di creazione low-code per lo stesso ecosistema di connettori e rimane il prodotto di riferimento per i flussi di lavoro guidati dal designer. Scegli Logic Apps quando il codice tra i passaggi è minimo e il valore risiede nell'orchestrazione.

Funzioni di Azure con connettori. Se il carico di lavoro è di tipo code-first (logica di diramazione personalizzata, librerie in-process, integrazione con altri binding di Functions o chiamate a modelli di IA tra trigger e azione), usa Functions con i connettori. Sviluppi in .NET, Python o Node.js, mantieni il modello di distribuzione e lo stack di osservabilità di Functions ed eviti di scrivere la logica di integrazione dei webhook e di gestire OAuth per l’edge SaaS.

Trigger HTTP con gli SDK di servizio Se non esiste alcun connettore gestito per il sistema di destinazione, oppure se hai bisogno di un controllo a livello di protocollo che l'astrazione del connettore nasconde, continua a usare una funzione con trigger HTTP che chiama direttamente l’SDK del servizio. Questo approccio ti lascia la responsabilità della gestione dell'autenticazione, dei tentativi di ritrasmissione e della convalida dei webhook, ma non ha alcuna dipendenza dal Connector Namespace.

Una singola app per le funzioni può combinare tutti e tre i modelli. È possibile aggiungere un trigger del connettore a un'app HTTP-trigger esistente e adottare i client SDK in modo incrementale.

Passaggi successivi

  • Last updated on