Le Azure Functions rappresentano uno dei servizi più efficaci nel panorama cloud quando vogliamo costruire logiche serverless scalabili e reattive agli eventi. Ci permettono di eseguire codice senza preoccuparci dell'infrastruttura, pagando solo per l'effettivo utilizzo e beneficiando di una scalabilità automatica. Questo approccio offre numerosi vantaggi, tra cui rapidità di sviluppo, integrazione nativa con l'ecosistema Azure e un modello fortemente orientato agli eventi.

Tuttavia, uno dei limiti principali delle Functions è sempre stato legato ai trigger disponibili. Sebbene esistano integrazioni con servizi come code, timer o HTTP, collegarsi a sistemi esterni più complessi, come provider email o applicazioni SaaS, richiede spesso codice aggiuntivo per gestire autenticazione, polling e gestione degli eventi.

Per risolvere questo problema, Microsoft ha introdotto i Managed Connectors, una funzionalità che estende il modello di trigger permettendoci di reagire direttamente a eventi provenienti da servizi esterni. In questo modo possiamo sfruttare un approccio simile a quello di Azure Logic Apps, ma restando all'interno del codice delle nostre Functions, riducendo drasticamente la complessità di integrazione.

I Managed Connectors permettono infatti di utilizzare binding avanzati direttamente nel codice. Il vantaggio principale è la rapidità di sviluppo, mentre tra gli svantaggi troviamo una minore flessibilità rispetto a un'integrazione completamente custom.

Vediamo quindi in pratica come ricevere email utilizzando un connector. Il primo passaggio è Program.cs, dove costruiamo l'host della Function e registriamo i client necessari per usare i connector nel resto dell'applicazione. Nell'esempio viene creato un DefaultAzureCredential, utile sia in Azure sia in locale, e poi vengono registrati nel container i client Office365Client e Office365UsersClient, ciascuno inizializzato con il proprio runtime URL preso dalle variabili di ambiente.

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

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

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

    services.AddSingleton(sp => new Office365UsersClient(
        new Uri(RequireSetting("OFFICE365USERS_CONNECTION_RUNTIME_URL")),
        sp.GetRequiredService<TokenCredential>()));
  })
  .Build();

host.Run();

Questo passaggio è importante perché ci fa capire come lavorano i nuovi connector: la Function usa client già pronti che fanno riferimento alla connessione configurata nel connector namespace. In questo modo manteniamo il codice pulito e concentrato sulla logica applicativa, preparando in modo chiaro le connessioni e le relative impostazioni di ambiente.

Dopo la configurazione passiamo al trigger vero e proprio. Nell'esempio reale riceviamo l'evento di una nuova email attraverso ConnectorTrigger senza parametri espliciti nel codice, mentre il payload arriva già tipizzato come Office365OnNewEmailTriggerPayload. Questo significa che gran parte del lavoro di integrazione viene già assorbito dal connector, e noi possiamo concentrarci su ciò che ci interessa davvero, cioè leggere i dati del messaggio e decidere come usarli.

[Function("OnNewImportantEmailReceived")]
public async Task OnNewImportantEmailReceived([ConnectorTrigger()] Office365OnNewEmailTriggerPayload payload)
{
  var email = payload.Body;
  return new OkResult();
}

Il pacchetto NuGet di riferimento è Azure.Connectors.Sdk, che fornisce una base comune per lavorare con i connector namespace e ci permette di usare nel codice elementi già pronti e coerenti con il servizio. Quando aggiungiamo il supporto a Office 365, troviamo infatti client tipizzati come Office365Client e Office365UsersClient, ma anche i tipi che descrivono in modo forte richieste, risposte ed eventi. Questo approccio rende l'SDK particolarmente utile perché non ci limitiamo ad avere un endpoint da chiamare, ma lavoriamo con classi, payload e metodi che rappresentano direttamente le operazioni del connector. Nel caso del trigger per le email, questo si vede molto bene con Office365OnNewEmailTriggerPayload, che ci consegna un oggetto già strutturato e pronto da leggere nella Function. In pratica, configuriamo il progetto, registriamo i client nel Program.cs e poi usiamo nella funzione sia il trigger sia i tipi forniti dall'SDK, ottenendo un flusso più chiaro, leggibile e vicino alla logica reale dell'applicazione.