Używaj zarządzanych konektorów w Azure Functions

Dzięki użyciu zarządzanych konektorów Twoje funkcje mogą reagować na zdarzenia i operacje połączeń w usługach takich jak Microsoft 365, Microsoft Teams, SharePoint i wielu systemach firm trzecich bez pisania kodu konfiguracyjnego webhook czy zarządzania tokenami OAuth. Usługa Azure Functions integruje się z usługą Azure Connector Namespace, udostępniając wyzwalacz i zestaw SDK, dzięki którym możesz skupić się na logice biznesowej, podczas gdy usługa Azure Connector Namespace obsługuje webhooki, uwierzytelnianie i ponawianie prób.

Note

Integracja przestrzeni nazw Azure Connector dla usługi Azure Functions jest obecnie dostępna w publicznej wersji zapoznawczej. Funkcje, nazwy konfiguracji oraz wsparcie dla konkretnych złączy zarządzanych mogą się zmieniać przed ogólną dostępnością (GA). Korzystanie z tej funkcji podlega dodatkowym warunkom użytkowania dotyczącym wersji zapoznawczych platformy Microsoft Azure.

Obecnie obsługiwane są tylko stosy językowe C#, Node.jsi Python.

Jak łączniki ulepszają funkcje

Przestrzeń nazw łącząca dodaje dwie możliwości do modelu programowania Functions:

• Spusty konektora
  Funkcja działa, gdy wystąpi zdarzenie w usłudze zewnętrznej, na przykład nowy e-mail w Microsoft 365, plik dodany do SharePoint lub wiadomość opublikowana w Teams. Środowisko uruchomieniowe udostępnia powiązanie connectorTrigger, które odbiera wywołania zwrotne webhooka z przestrzeni nazw łącznika.
• Akcje SDK konektora
  Kod funkcji wywołuje operacje konektora za pośrednictwem klientów SDK. SDK obejmuje zarządzane konektory takie jak Microsoft 365 Outlook, Microsoft 365 Users, Teams, SharePoint i OneDrive. Zarządzane konektory, które nie mają jeszcze modeli SDK, są wywoływane jako punkty końcowe HTTP.

Możesz używać zarządzanych konektorów obok klasycznych wyzwalaczy i wiązań Functions, takich jak HTTP, timer, queue, Service Bus, Event Grid i Durable Functions.

Dostępność wersji zapoznawczej

Dimension	Availability
Region przestrzeni nazw konektora	West Central US (westcentralus). Aplikacja Function może być dostępna w dowolnym obsługiwanym regionie.
Języki	.NET 10/.NET 8 izolowany, Python 3,13+, Node.js 22+ (JS/TS). Java, PowerShell i Go nie są obsługiwane.
Plany hostingowe	Flex Consumption (zalecane), Premium, dedykowane i kontenerowe aplikacje.
Ceny	Cennik funkcji standardowych: Brak dodatkowych opłat za wyzwalacz łącznika/SDK w okresie wersji zapoznawczej. Connector Namespace podlega oddzielnemu rozliczeniu.

Kiedy należy używać łączników

Używaj konektorów, gdy twoje funkcje muszą głównie współpracować z zewnętrznymi usługami, a nie uruchamiać złożoną logikę niestandardową. Rozważ następujące sposoby wykorzystania zarządzanych konektorów w aplikacjach funkcyjnych:

• Reaguj na zdarzenia zewnętrzne
  Twoja aplikacja musi obsługiwać zdarzenia wywoływane przez zewnętrzne usługi (nowe e-maile, zaproszenia do kalendarza, pliki, elementy listy, aktywność Teams), ale nie chcesz poświęcać wysiłku na kodowanie rejestracji webhooków, walidacji handshake i odświeżania OAuth. Rozważmy przypadek, w którym Twoja funkcja uruchamia się, aby przetwarzać nowe wiadomości e-mail dostarczane do monitorowanego folderu programu Outlook w usłudze Office 365, klasyfikuje wiadomość, wywołuje łącznik Office 365 w celu wzbogacenia danych oraz oznacza wiadomość e-mail flagą lub przenosi ją. Cała ta rozproszona obsługa jest realizowana przez twoją aplikację bez konieczności przejmowania się tokenami odświeżającymi, ponieważ zajmuje się tym przestrzeń nazw twojego łącznika.

• Zastąpienie klientów usług niestandardowych
  Twój kod funkcji już wywołuje interfejsy API platformy Microsoft 365 lub firm trzecich przy użyciu niestandardowych klientów HTTP, co wymaga zarządzania sekretami, zakresami i zasadami ponawiania prób w wielu połączeniach, a to może szybko stać się obciążeniem związanym z utrzymaniem. Możesz zamiast tego używać typowanych klientów w SDK złącza bezpośrednio w kodzie funkcyjnym i pozwolić zarządzanym konektorom samodzielnie zajmować się połączeniami.

• Wykorzystaj istniejące wdrożenie aplikacji
  Już zbudowałeś projekt aplikacji funkcjonalnej opartej na zdarzeniach z pipeline'em wdrożeniowym i narzędziami do monitorowania. Możesz użyć zarządzanych konektorów, aby dodać nową funkcję wyzwalającą usługi zewnętrzne w tym samym projekcie i skorzystać z istniejącej infrastruktury. Na przykład aplikacja funkcjonalna, która wcześniej opierała się na kolejkach wiadomości lub Logic Apps, teraz może bezpośrednio reagować na aktywność Teams i łączyć się z Office 365 do kontroli organizacyjnych i wyszukiwań menedżerów.

• Przepływy pracy agentów
  Budujesz workflow, w których funkcja otrzymuje zdarzenie, uzasadnia się modelem AI, a następnie działa z powrotem do zewnętrznej usługi poprzez operację łączącą. Możesz wykorzystać umiejętności hostowane w Azure Functions do programowania pracy agentów, jednocześnie korzystając z triggerów opartych na zarządzanych konektorach i SDK z zarządzanymi konektorami.

• Sterowanie oparte na kodzie z zarządzaną integracją
  Chcesz zarządzanych konektorów, które uproszczą komunikację przychodzącą i wychodzącą z usługami zewnętrznymi, ale wolisz model programowania oparty na kodzie i pełną kontrolę nad orkiestracją, w tym rozgałęzieniami, zarządzaniem uwierzytelnianiem między krokami oraz ponownym wykorzystaniem istniejących bibliotek.

  Wskazówka

  Gdy obciążenie to czysta orkiestracja między konektorami bez własnego kodu, Logic Apps Standard pozostaje najprostszym wyborem. Więcej informacji można znaleźć w artykule Relacje z innymi opcjami integracji Azure.

Relacja z innymi opcjami integracji Azure

Zarządzane konektory w Azure Functions są addytywne. Właściwy wybór zależy od tego, ile niestandardowego kodu wymaga zadanie i czy zespół woli projektanta wizualnego czy kod.

Option	Najlepsze dla...	Dostajesz...
Logic Apps Standard	Orkiestracja przepływu pracy między złączami; zespół preferuje projektanta wizualnego; Trochę niestandardowego kodu między krokami.	Projektant low-code dla tego samego ekosystemu złączy.
Azure Functions z zarządzanymi konektorami	Doświadczenia z kodem na pierwszym miejscu, w tym niestandardowe rozgałęzienia, biblioteki w trakcie procesu, inne powiązania oraz wywołania modeli AI między wyzwalaniem a akcją.	tworzenie w .NET, Python lub Node.js; wdrażanie i monitorowanie usługi Functions; bez kodu webhooków ani OAuth dla usług zewnętrznych.
Wyzwalacze HTTP za pomocą SDK serwisu	Przypadki, gdy nie istnieje zarządzany konektor dla usługi docelowej lub potrzebujesz kontroli na poziomie protokołu, które nie są dostarczane przez sam konektor.	Pełna kontrola nad uwierzytelnianiem, ponawianiem prób i weryfikacją webhooków; bez wymagań dotyczących przestrzeni nazw złącza.

Jedna aplikacja funkcji może łączyć wszystkie trzy wzorce. Do istniejącej aplikacji wyzwalanej przez HTTP można dodać wyzwalacz łącznika i stopniowo wdrażać klientów SDK.

Pakiety i wymagania wstępne

Każdy obsługiwany język obejmuje niewielki zestaw pakietów zawierających powiązania wyzwalaczy i klientów SDK łączników.

Pakiet rozszerzenia procesu roboczego zawiera powiązanie wyzwalacza łącznika. Pakiety Azure.Connectors.Sdk.* (po jednym dla każdego konektora) zawierają typowane payloady i klientów SDK.

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

W przypadku izolowanego workera platformy .NET wybierz net8.0 lub net10.0 oraz najnowszą wersję workera Functions.

Python używa pakietu rozszerzeń w wersji zapoznawczej do załadowania powiązania wyzwalacza i pakietu azurefunctions-extensions-connectors dla typowanych modeli Office 365. Dodaj pakiet do host.json:

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

Zainstaluj pakiety środowiska uruchomieniowego i rozszerzenia:

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

Dekorator @app.connector_trigger działa dla wszystkich typów zarządzanych złączy. Typowane modele ładunku są aktywnie rozwijane i dodawane w pakiecie azurefunctions-extensions-connectors. W przypadku zarządzanych konektorów bez modeli typowanych traktuj ładunek danych jako ciąg znaków.

Node.js używa pakietu rozszerzenia eksperymentalnego do załadowania powiązania wyzwalacza. Dodaj pakiet do host.json:

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

Zainstaluj bibliotekę usługi Functions i pakiety łączników:

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

Używaj typowanych punktów wejścia w ( @azure/functions-extensions-connectors na przykład connectors.office365.onNewEmail), gdy istnieją modele typowane. Użyj app.connectorTrigger z @azure/functions dla dowolnego zarządzanego łącznika, gdy potrzebujesz surowej zawartości ładunku.

Java i program PowerShell nie są obsługiwane w publicznej wersji zapoznawczej. Zobacz dostępność podglądową dla aktualnej listy obsługiwanych środowisk uruchomieniowych.

Wyzwalacze oparte na łącznikach

Wyzwalacz oparty na zarządzanym złączu uruchamia Twoją funkcję, gdy w usłudze połączonej wystąpi zdarzenie. Przestrzeń nazw łącznika dostarcza zdarzenie do Twojej aplikacji funkcji przez protokół HTTPS za pomocą punktu końcowego webhooka rozszerzenia łącznika:

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

{FunctionName} musi być zgodne z nazwą w atrybucie [Function]. {connector_extension_key} to wartość klucza systemowego, który pobierasz przez uruchomienie:

{FunctionName} odpowiada nazwie w twoim dekoratorze @app.function_name. {connector_extension_key} to wartość klucza systemowego, który pobierasz przez uruchomienie:

{FunctionName} musi odpowiadać nazwie w rejestracji wyzwalacza. {connector_extension_key} to wartość klucza systemowego, który pobierasz przez uruchomienie:

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

Konfiguracja wyzwalacza w przestrzeni nazw twojego łącznika przechowuje ten adres URL wywołania zwrotnego i dołącza klucz systemowy do każdego wywołania zwrotnego. Środowisko uruchomieniowe usługi Functions weryfikuje klucz, zanim uruchomi funkcję. Dla konfiguracji bez współdzielonych sekretów możesz umieścić wbudowaną uwierzytelnianie App Service przed aplikacją funkcyjną i zweryfikować zarządzany token tożsamości z przestrzeni nazw łącznika. Zobacz przykład platformy .NET: wbudowane uwierzytelnianie przy użyciu tożsamości zarządzanej, aby zobaczyć pełny wzorzec.

Wskazówka

Użyj planu Flex Consumption dla funkcji wyzwalanych przez łączniki w wersji zapoznawczej. Rozwiązanie Flex Consumption zapewnia obsługę skalowania poszczególnych wystąpień i tożsamości zarządzanej, która jest zgodna z modelem uwierzytelniania platformy łącznika.

Ładunki żądań niosą treść zdarzenia oraz zestaw nagłówków x-ms-* identyfikujących konfigurację wyzwalacza, połączenie, typ zdarzenia i identyfikator korelacji. Gdy zarządzane złącze ma model SDK, środowisko uruchomieniowe deserializuje ładunek danych bezpośrednio do tego modelu. Dla zarządzanych konektorów bez SDK klienta funkcja otrzymuje surowy korpus JSON.

W poniższym przykładzie pokazano funkcję, która jest uruchamiana po nadejściu nowej wiadomości e-mail w skrzynce pocztowej Office 365 Outlook. Rejestracja wyzwalacza jest wykonywana w zależności od języka; konfiguracja wyzwalacza w przestrzeni nazw złącza jest taka sama we wszystkich przypadkach.

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

Model Office365OnNewEmailTriggerPayload i inne typy ładunków operacji pochodzą z Azure.Connectors.Sdk.Office365.Models. Aby zobaczyć pełne mapowanie operacji do ładunku, zobacz Mapowanie sygnatur operacji do usługi Azure Functions.

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

W przypadku konkretnie operacji Office 365 OnNewEmailV3 można użyć typizowanego dekoratora z 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}'.`,
            );
        }
    },
});

W przypadku każdego konektora, który nie ma jeszcze typowanego punktu wejścia, użyj ogólnego app.connectorTrigger z @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}`);
        }
    },
});

Wyzwalacz łącznika nie jest dostępny w tym języku w publicznej wersji zapoznawczej.

Konfigurację wyzwalacza tworzysz w przestrzeni nazw konektora, używając Azure CLI, ARM lub Bicep. Ten etap jest częścią platformy łączników i został opisany w zestawie dokumentacji łączników. Usługa Functions nie dostarcza własnych poleceń konfiguracji na potrzeby rejestracji wyzwalacza.

Uwierzytelnij swoje funkcje w przestrzeni nazw konektora

Note

Ta sekcja dotyczy uwierzytelniania między przestrzenią nazw łącznika a aplikacją funkcyjną. Informacje o tym, jak przestrzeń nazw łącznika uwierzytelnia się wobec usług nadrzędnych (Microsoft 365, Teams, SharePoint), można znaleźć w artykule Omówienie łączników platformy Azure.

Domyślny model uwierzytelniania wykorzystuje wspólny klucz systemowy (connector_extension), który przestrzeń nazw łącznika prezentuje przy każdym callbacku. Jednak współdzielone klucze nie mogą być ograniczone do poszczególnych wyzwalaczy i wymagają skoordynowanej rotacji między aplikacją funkcji a przestrzenią nazw łącznika. W przypadku obciążeń produkcyjnych zamiast tego użyj wbudowanego uwierzytelniania usługi App Service (nazywanego również Easy Auth) z tożsamością zarządzaną.

W tym wzorcu przestrzeń nazw łącząca używa własnej systemowo przypisanej lub przez użytkownika zarządzanej tożsamości, aby żądać tokena Entra ID dla każdego callbacka. Aplikacja funkcji Azure weryfikuje ten token, w tym jego odbiorcę, wystawcę i identyfikator obiektu wywołującego, zanim jakiekolwiek żądanie dotrze do hosta usługi Azure Functions. Żadnych kluczy współdzielonych, żadnych kluczy tajnych klienta, nigdzie.

Aby zobaczyć kompletny działający przykład, zajrzyj do tego repozytorium: functions-connectors-net-builtinauth.

Konfiguracja aplikacji funkcjonalnej

Wbudowane uwierzytelnianie odbywa się na granicy procesu roboczego usługi App Service, zanim żądanie dotrze do środowiska uruchomieniowego usługi Functions. Konfigurujesz go za pomocą authsettingsV2 właściwości ARM lub jej odpowiednika w języku Bicep.

Setting	Purpose
requireAuthentication: true	Odrzuca wszelkie żądania bez prawidłowego tokenu (zwraca wartość 401).
identityProviders.azureActiveDirectory.enabled: true	Weryfikuje tokeny Entra ID.
registration.clientId	Identyfikator aplikacji (klienta) w rejestracji aplikacji Entra, względem którego wbudowane uwierzytelnianie weryfikuje tokeny.
registration.openIdIssuer	Adres URL emitenta dla dzierżawcy: https://login.microsoftonline.com/{tenantId}/v2.0.
validation.allowedAudiences	Identyfikator klienta i identyfikator URI aplikacji Entra. Tokeny muszą mieć jedną z tych grup odbiorców w oświadczeniu aud .
validation.defaultAuthorizationPolicy.allowedPrincipals.identities	Identyfikatory obiektów (podmiotu zabezpieczeń) tożsamości zarządzanych mogą wywoływać funkcję. Tutaj powinna być wymieniona tylko zarządzana tożsamość przestrzeni nazw złącza. Każdy token z innym claimem oid zwraca kod 403.

Aplikacja funkcji wymaga również tożsamości zarządzanej przypisanej przez użytkownika sfederowanej z rejestracją aplikacji Entra. Wbudowane uwierzytelnianie wykorzystuje to poświadczenie tożsamości federacyjnej (FIC) do generowania asercji klienta dla aplikacji Entra bez przechowywania sekretu klienta. Szablon Bicep ustawia clientSecretSettingName jako ustawienie aplikacji przechowujące identyfikator klienta tożsamości zarządzanej przypisanej przez użytkownika, co powoduje, że wbudowane uwierzytelnianie używa FIC zamiast klucza tajnego.

Ponieważ wbudowana autentyzacja już waliduje każde żądanie, możesz wyłączyć redundantne sprawdzanie klucza systemowego w host.json, które wyglądałoby jak ten fragment JSON:

{
    ...
    "extensions": {
        "connector": {
            "system": {
                "webhookAuthorizationLevel": "Anonymous"
            }
        }
    }
}

Konfiguracja przestrzeni nazw dla złącza

Twoja przestrzeń nazw łącznika musi mieć włączoną i dołączoną przez system lub przez użytkownika tożsamość zarządzaną. Gdy tworzysz konfigurację wyzwalacza, określ authentication.type = ManagedServiceIdentity i authentication.identity = <resource-id-of-managed-identity> dla tożsamości przypisanej przez użytkownika lub pomiń identity dla tożsamości przypisanej systemowi. Określ także authentication.audience = <entra-app-client-id>, aby środowisko uruchomieniowe łącznika wiedziało, o jakiego odbiorcę poprosić w tokenie.

Środowisko uruchomieniowe łącznika używa tej zarządzanej tożsamości do generowania tokenu Entra ID przy każdym wywołaniu zwrotnym. W tym tokenie iss (emitent) jest Twoim dzierżawcą, aud (odbiorcą) identyfikatorem klienta aplikacji Entra, a oid (ID obiektu) głównym identyfikatorem tożsamości. Wbudowane uwierzytelnianie weryfikuje wszystkie trzy.

Zasób przestrzeni nazw łącznika również wymaga dostępu do połączenia, takiego jak połączenie office365. Udziel tego dostępu poprzez politykę dostępu, która zawiera główny identyfikator zarządzanej tożsamości. Przykładowy plik Bicep przedstawia pełną konfigurację zarówno tożsamości przestrzeni nazw, jak i zasad dostępu do połączenia.

Co jest wymuszane

Wbudowane uwierzytelnianie weryfikuje tokeny w kolejności:

1. Obecność tokenu — brak tokenu lub wygasły → 401
2. Signature — weryfikowany względem zestawu JWKS wystawcy dla Twojej dzierżawy
3. iss (wystawca) — musi być zgodna openIdIssuer
4. aud (odbiorcy) — musi znajdować się w allowedAudiences
5. oid (object/principal ID) - musi odpowiadać jednej z tożsamości w allowedPrincipals.identities. Dowolny inny identyfikator → 403

Ponieważ to sprawdzenie odbywa się w warstwie brzegowej usługi App Service, kod Twojej funkcji nigdy nie otrzymuje żądania, które nie pochodzi z zarządzanej tożsamości przestrzeni nazw łącznika. Do sprawdzania dostępu nie potrzebujesz żadnego kodu aplikacji.

Przepływ uwierzytelniania

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

Treści powiązane

• Uwierzytelnianie i autoryzacja w usłudze aplikacji Azure i funkcjach Azure
• Konfigurowanie aplikacji App Service lub Azure Functions do korzystania z logowania w usłudze Microsoft Entra
• Konfiguracja oparta na plikach w uwierzytelnianiu usługi Azure App Service
• Federacja tożsamości obciążeń roboczych w Microsoft Entra ID
• Tożsamości zarządzane dla zasobów platformy Azure

Używanie łączników w kodzie

SDK konektora umożliwia Twojej funkcji wywoływanie operacji łącznikowych jako akcji wychodzących. Powierzchnia klienta korzysta z tego samego podstawowego zarządzanego złącza w przestrzeni nazw złącza, który wywołuje użycie, więc pojedynczy zarządzany konektor może zasilać zarówno wyzwalacze przychodzących, jak i wychodzące dla tego samego konta usługi.

W .NET każdy łącznik dostarcza typizowanego klienta (na przykład Office365Client, Office365UsersClient, TeamsClient) w Azure.Connectors.Sdk.{Service}. Konstruktor klienta jako argumenty przyjmuje adres URL połączenia używany w czasie wykonywania oraz dane uwierzytelniające.

Poniższy wzorzec pochodzi z kompleksowego przykładu Teams do wyszukiwania użytkowników poczty e-mail:

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

Ustawienia *_CONNECTION_RUNTIME_URL wskazują punkt końcowy środowiska uruchomieniowego dla każdego połączenia w przestrzeni nazw łącznika. Wstrzyknij klienty do funkcji i wywołaj metody typowane, takie jak UserProfileAsync, GetEmailsAsync lub FlagAsync. Można również wywoływać klientów SDK z wyzwalaczy niebędących łącznikami (na przykład wyzwalacza HTTP, który wysyła wpis do aplikacji Teams).

W Python zainstaluj azure-connectors dla wpisanych klientów (na przykład office365, teams, office365Users). Klienci przyjmują adres URL środowiska uruchomieniowego dla każdego połączenia oraz poświadczenie. Zasięg działań SDK się rozszerza.

W Node.js zainstaluj @azure/connectors dla klientów typowanych (na przykład office365, teams, office365Users). Klienci przyjmują adres URL środowiska uruchomieniowego dla każdego połączenia oraz poświadczenie. Zasięg działań SDK się rozszerza.

Zestaw SDK łącznika nie jest dostępny w tych językach w ramach publicznej wersji zapoznawczej.

Artykuły pokrewne

• Przykłady dotyczące łączników usługi Azure Functions (indeks kanoniczny)
• Kompleksowy przykład platformy .NET: wiadomość e-mail → wyszukiwanie użytkownika → Teams
• przykład .NET: wbudowane uwierzytelnianie przy użyciu tożsamości zarządzanej
• Repozytorium rozszerzenia łącznika usługi Azure Functions
• Mapowanie operacji na sygnatury usługi Azure Functions
• omówienie łączników Azure
• Co to jest przestrzeń nazw łącznika Azure?
• Umiejętności hostowane w Azure Functions