Používejte spravované konektory v Azure Functions

Díky použití spravovaných konektorů mohou vaše funkce reagovat na události a volání v službách jako Microsoft 365, Microsoft Teams, SharePoint a mnoha systémech třetích stran bez nutnosti psát webhook setup code nebo spravovat OAuth tokeny. Azure Functions se integruje se službou Azure Connector Namespace a poskytuje aktivační událost a sadu SDK, které vám umožní soustředit se na obchodní logiku, zatímco Azure Connector Namespace zajišťuje webhooky, ověřování a opakované pokusy.

Note

Integrace Azure Connector Namespace pro Azure Functions je momentálně ve veřejném náhledu. Funkce, názvy konfigurací a podpora specifických spravovaných konektorů se mohou měnit ještě před obecnou dostupností (GA). Použití této funkce podléhá supplementálními podmínkami použití pro verze preview Microsoft Azure.

V současnosti jsou podporovány pouze jazykové zásobníky C#, Node.jsa Python.

Jak konektory zlepšují funkce

Jmenný prostor konektoru přidává do programovacího modelu Functions dvě funkce:

  • Konektorové spouště
    Funkce se spustí, když dojde k události v externí službě, například při přijetí nového e-mailu v Microsoft 365, souboru přidaném do SharePoint nebo zprávy zveřejněné v Teams. Runtime odhaluje connectorTrigger vazbu, která přijímá zpětné volání webhooku z jmenného prostoru konektoru.
  • Akce SDK konektoru
    Kód vaší funkce volá operace konektorů prostřednictvím klientů SDK. SDK pokrývá spravované konektory jako Microsoft 365 Outlook, Microsoft 365 Users, Teams, SharePoint a OneDrive. Spravované konektory, které ještě nemají modely SDK, je možné volat jako HTTP endpointy.

Můžete používat spravované konektory spolu s klasickými spouštěči a vazbami Functions, jako jsou HTTP, časovač, fronta, Service Bus, Event Grid a Durable Functions.

Náhled dostupnosti

Dimension Dostupnost
Region jmenného prostoru konektoru Jakýkoli region, kde je podporován Connector Namespace .
Jazyky .NET 10 (izolovaný model), Python 3.13+, Node.js 22+ (JS/TS). Java, PowerShell a Go nejsou podporovány.
Plány na pořádání Flex Consumption (doporučeno), Premium, Dedicated a kontejnerové aplikace.
cen Ceny standardních funkcí: Bez dalších poplatků za aktivační událost konektoru/SDK ve verzi Preview.
Connector Namespace má samostatné účtování.

Kdy použít konektory

Používejte konektory, když vaše funkce potřebují hlavně interagovat s externími službami, místo aby spouštěly složitou vlastní logiku. Zvažte tyto způsoby, jak používat spravované konektory ve vašich funkčních aplikacích:

  • Reakce na vnější události
    Vaše aplikace musí zpracovávat události vyvolávané externě propojenými službami (nové e-maily, pozvánky do kalendáře, soubory, položky seznamu, aktivity Teams), ale nechcete se vynakládat na kódování registrací webhooků, ověřování handshake a obnovování OAuth. Představte si situaci, kdy je vaše funkce spuštěna ke zpracování nových e-mailů doručených do monitorované složky Outlooku v Office 365, klasifikuje zprávu, volá konektor Office 365 za účelem obohacení a e-mail označí příznakem nebo přesune. Veškerou tuto distribuovanou práci vykonává vaše aplikace, aniž byste se museli starat o obnovovací tokeny, které řeší váš konektorový jmenný prostor.

  • Nahrazení klientů pro zakázkové služby
    Váš funkční kód už volá Microsoft 365 nebo API třetích stran pomocí vlastních HTTP klientů, což vyžaduje správu tajemství, rozsahů a politiky opakovaných pokusů napříč mnoha připojeními, což se může rychle stát údržbovou zátěží. Místo toho můžete použít zapsané klienty v konektorových SDK přímo ve svém funkčním kódu a nechat spravované konektory spravovat sama připojení.

  • Využijte existující nasazení aplikace
    Již jste vytvořili projekt aplikace funkcí řízené událostmi s kanálem nasazení a monitorovacími nástroji. Můžete použít spravované konektory k přidání nové funkce založené na spouštění externích služeb ve stejném projektu a využít tak stávající infrastrukturu. Například funkční aplikace, která dříve spoléhala na fronty zpráv nebo Logické aplikace, nyní může reagovat přímo na aktivitu v Teams a připojit se k Office 365 pro kontrolu v organizaci a vyhledávání manažera.

  • Pracovní postupy agentů
    Vytváříte pracovní postupy, ve kterých funkce přijme událost, využije AI model k vyhodnocení a poté provede akci v externí službě prostřednictvím operace konektoru. Můžete využít dovednosti hostované v Azure Functions k programování vašeho agentického workflow a zároveň využívat spouštěče založené na spravovaných konektorech a SDK spravovaných konektorů.

  • Řízení založené na kódu s řízenou integrací
    Chcete spravované konektory, které zjednoduší příchozí a odchozí komunikaci s externí službou, ale preferujete programovací model zaměřený na kód a plnou kontrolu nad orchestrací, včetně větvení, správy autentizace mezi kroky a opětovného využití stávajících knihoven.

    Tip

    Když je pracovní zátěž čistě orchestrací napříč konektory bez vlastního kódu, zůstává Logic Apps Standard nejjednodušší volbou. Pro více informací viz Vztah k ostatním možnostem integrace Azure.

Vztah k jiným možnostem integrace Azure

Spravované konektory v Azure Functions jsou aditivní. Správná volba závisí na tom, kolik vlastního kódu pracovní zátěž vyžaduje a zda tým preferuje vizuálního designéra nebo kód.

Option Nejlepší pro... Dostaneš...
Logic Apps Standard Orchestrace pracovního postupu napříč konektory; tým preferuje vizuální návrhář; mezi kroky je jen minimum vlastního kódu. Designér s nízkým kódem pro stejný ekosystém konektorů.
Azure Functions se spravovanými konektory Zkušenosti zaměřené na kód zahrnují vlastní větvení, knihovny během procesu, další vazby a volání AI modelů mezi triggerem a akcí. vytváření v .NET, Pythonu nebo Node.js; nasazení a monitorování funkcí; bez kódu webhooků nebo OAuth pro externí služby.
Azure App Service se spravovanými konektory Přidávání spojovacích událostí a akcí do existující webové aplikace nebo API. Autentizované HTTP callbacky prostřednictvím tras vaší aplikace a stejných klientů sady SDK pro odchozí akce; autentizace přijímající aplikace se konfiguruje odděleně od spouštěče.
HTTP spouštěče pomocí SDK služeb Případy, kdy pro cílovou službu neexistuje žádný spravovaný konektor nebo potřebujete protokolové kontroly, které konektor neposkytuje. Plná kontrola nad autentizací, opětovným pokusem a ověřováním webhooku; Žádné požadavky na jmenný prostor konektoru.

Funkční aplikace může používat spouštěče konektorů a přímé servisní SDK a účastnit se pracovních postupů Logic Apps. Do existující aplikace aktivované triggerem HTTP můžete přidat aktivační událost konektoru a postupně zavádět klienty sady SDK.

Balíčky a požadavky

Každý podporovaný jazyk má malou sadu balíčků, které přinášejí trigger binding a konektorové SDK klienty.

Balíček rozšíření workeru obsahuje vazbu triggeru konektoru. Balíčky Azure.Connectors.Sdk.* (jeden na konektor) doručují typované payloady a SDK klienty.

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

V případě .NET izolovaného pracovního procesu cílte na net8.0 nebo net10.0 a nejnovější pracovní proces Functions.

Python používá balíček rozšíření Preview k načtení aktivační vazby a balíčku azurefunctions-extensions-connectors pro typované modely Office 365. Přidejte balíček do host.json:

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

Nainstalujte balíčky runtime a rozšíření:

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

Dekorátor @app.connector_trigger funguje u všech typů spravovaných konektorů. Typované modely datové části jsou aktivně vyvíjeny a přidávány prostřednictvím balíčku azurefunctions-extensions-connectors. U spravovaných konektorů bez typovaných modelů považujte payload za řetězec.

Node.js používá experimentální balíček rozšíření k načítání aktivační vazby. Přidejte balíček do host.json:

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

Nainstalujte knihovnu Functions a balíčky konektorů:

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

Použijte typované vstupní body v @azure/functions-extensions-connectors (například connectors.office365.onNewEmail), pokud existují typované modely. Použijte app.connectorTrigger z @azure/functions u libovolného spravovaného konektoru, když chcete nezpracovanou datovou část.

Important

Go, Java a PowerShell nejsou ve veřejném náhledu podporovány. Viz dostupnost verze Preview, kde najdete aktuální seznam podporovaných běhových prostředí.

Triggery založené na konektorech

Spouštěč založený na řízeném konektoru spustí vaši funkci, když v připojené službě dojde k události. Obor názvů konektoru doručuje událost do vaší aplikace funkcí přes HTTPS pomocí koncového bodu webhooku rozšíření konektoru:

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

{FunctionName} Odpovídá názvu ve vašem [Function] atributu. {connector_extension_key} je hodnota systémového klíče, který získáte spuštěním:

{FunctionName} odpovídá názvu ve vašem dekorátoru @app.function_name. {connector_extension_key} je hodnota systémového klíče, který získáte spuštěním:

{FunctionName} Odpovídá jménu ve vaší registraci spouštěče. {connector_extension_key} je hodnota systémového klíče, který získáte spuštěním:

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

Konfigurace triggeru ve vašem jmenném prostoru konektoru ukládá tuto callback URL a při každém callbacku zobrazuje systémový klíč. Modul runtime služby Functions ověří klíč před spuštěním vaší funkce. Pro nastavení bez sdílených tajemství můžete dát vestavěnou autentizaci App Service před funkční aplikaci a ověřit spravovaný identitní token z jmenného prostoru konektoru. Viz ukázka .NET: vestavěná autentizace s řízenou identitou pro celý vzor.

Tip

Plán Flex Consumption použijte pro funkce spouštěné konektory během verze Preview. Flex Consumption poskytuje škálování jednotlivých instancí a podporu spravovaných identit v souladu s modelem ověřování platformy konektorů.

Datové části požadavku obsahují tělo události a sadu x-ms-* hlaviček, které identifikují konfiguraci triggeru, připojení, typ události a ID korelace. Když má spravovaný konektor model SDK, modul runtime deserializuje datovou část přímo do tohoto modelu. U spravovaných konektorů bez klientských SDK vaše funkce přijímá surové JSON tělo.

Následující příklad ukazuje funkci, která se aktivuje, když do Office 365 Outlook poštovní schránky přijde nový e-mail. Registrace spouštěče je podle jazyka; konfigurace spouštěče v jmenném prostoru konektoru je ve všech případech stejná.

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 a další typy datové části operace pocházejí z Azure.Connectors.Sdk.Office365.Models. Pro kompletní mapování operace na payload viz Operations to Azure Functions signature mapping.

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

Konkrétně pro operaci Office 365 OnNewEmailV3 můžete použít typovaný dekorátor 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}'.`,
            );
        }
    },
});

Pro všechny konektory, které ještě nemají zadaný vstupní bod, použijte obecný 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}`);
        }
    },
});

Important

Trigger konektoru není v tomto jazyce dostupný pro verzi Public Preview.

Konfiguraci spouště vytváříte v jmenném prostoru konektoru pomocí Azure CLI, ARM nebo Bicep. Tento krok je součástí platformy pro konektory a je zdokumentován v sadě dokumentace ke konektorům. Funkce nedodává vlastní konfigurační příkazy pro registraci triggerů.

Ověřte své funkce vůči jmennému prostoru konektoru

Note

Tato sekce se zabývá autentizací mezi jmenným prostorem konektoru a vaší funkční aplikací. Informace o tom, jak se obor názvů konektoru ověřuje vůči nadřazeným službám (Microsoft 365, Teams, SharePoint), najdete v článku Přehled konektorů Azure.

Výchozí autentizační model používá sdílený systémový klíč (connector_extension), který konektorový jmenný prostor prezentuje při každém zpětném volání. Sdílené klíče však nelze omezit pro jednotlivé spouštěče a vyžadují koordinovanou rotaci mezi aplikací funkcí a oborem názvů konektoru. Pro produkční pracovní zátěže místo toho použijte vestavěnou autentizaci App Service (také nazývanou Easy Auth) s řízenou identitou.

V tomto vzoru používá obor názvů konektoru svou vlastní systémem přiřazenou identitu nebo spravovanou identitu přiřazenou uživatelem k vyžádání tokenu Entra ID pro každé zpětné volání. Aplikace funkcí ověří token, včetně jeho příjemce, vystavitele a ID objektu volajícího, ještě než jakýkoli požadavek dosáhne hostitele Functions. Žádné sdílené klíče, žádné tajné klíče klienta, nikde.

Kompletní funkční příklad najdete v tomto repozitáři: functions-connectors-net-builtinauth.

Konfigurace funkční aplikace

Vestavěná autentizace běží na hranici pracovního systému App Service, ještě před tím, než runtime Functions obdrží požadavek. Konfigurujete ho přes authsettingsV2 vlastnost ARM nebo její ekvivalent v Bicep.

Setting Purpose
requireAuthentication: true Odmítne všechny požadavky bez platného tokenu (vrátí hodnotu 401).
identityProviders.azureActiveDirectory.enabled: true Ověřuje tokeny Entra ID.
registration.clientId ID aplikace (klienta) registrace aplikace Entra, vůči kterému integrované ověřování ověřuje tokeny.
registration.openIdIssuer Adresa URL vydavatele pro vašeho tenanta: https://login.microsoftonline.com/{tenantId}/v2.0.
validation.allowedAudiences ID klienta a identifikátor URI aplikace Entra. Tokeny musí v atributu aud obsahovat jednu z těchto cílových skupin.
validation.defaultAuthorizationPolicy.allowedPrincipals.identities ID objektů (instančních objektů) spravovaných identit, které mají povoleno volat funkci. Zde by měla být uvedena pouze spravovaná identita jmenného prostoru konektoru. Jakýkoli token s jiným claimem oid vrátí chybu 403.

Aplikace Function App také potřebuje spravovanou identitu přiřazenou uživatelem federovanou s registrací aplikace Entra. Integrované ověřování používá tento přihlašovací údaj federované identity (FIC) k vystavování klientských kontrolních tvrzení pro aplikaci Entra, aniž by bylo nutné ukládat tajný klíč klienta. Šablona Bicep nastaví clientSecretSettingName jako nastavení aplikace, které obsahuje ID klienta spravované identity přiřazené uživatelem, čímž integrovanému ověřování sdělí, aby místo tajného klíče použilo FIC.

Protože vestavěná autentizace už ověřuje každý požadavek, můžete deaktivovat redundantní kontrolu systémového klíče v host.json, která by vypadala jako tento fragment JSON:

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

Konfigurace jmenného prostoru konektoru

Váš konektorový jmenný prostor musí mít systémem nebo uživatelem přiřazenou spravovanou identitu povolenou a připojenou. Při vytváření konfigurace aktivační události zadejte authentication.type = ManagedServiceIdentity a authentication.identity = <resource-id-of-managed-identity> pro identitu přiřazenou uživatelem nebo vynechte identity pro identitu přiřazenou systémem. Zadejte také authentication.audience = <entra-app-client-id>, aby běhové prostředí konektoru vědělo, o kterou cílovou skupinu má v tokenu požádat.

Modul runtime konektoru používá tuto spravovanou identitu ke generování tokenu Entra ID při každém zpětném volání. V tomto tokenu je iss (vydavatel) váš tenant, aud (příjemce) ID klienta aplikace Entra a oid (ID objektu) ID objektu identity. Integrované ověřování ověřuje všechny tři.

Zdroj jmenného prostoru konektoru také potřebuje přístup ke spojení, například office365 k připojení. Tento přístup udělte prostřednictvím přístupové politiky, která uvádí hlavní ID spravované identity. Ukázkový soubor biceps ukazuje kompletní konfiguraci jak pro identitu jmenného prostoru, tak pro politiku přístupu k připojení.

Co se vynucuje

Integrované ověřování ověřuje tokeny v pořadí:

  1. Stav tokenu – Chybějící nebo prošlý token → 401
  2. Podpis – Ověřeno vůči JWKS vydavatele pro vašeho tenanta
  3. iss (vydavatel) - Musí se shodovat s openIdIssuer
  4. aud (publikum) - musí být v allowedAudiences
  5. oid (ID objektu / objektu zabezpečení) - Musí odpovídat jedné z identit v allowedPrincipals.identities. Jakákoli jiná identita → 403

Protože tato kontrola běží na edge App Service, váš kód funkce nikdy nevidí požadavek, který nepocházel ze spravované identity jmenného prostoru konektoru. Pro kontrolu přístupu nepotřebujete žádný aplikační kód.

Průběh ověřování

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

Související obsah

Použití konektorů v kódu

SDK konektoru umožňuje vaší službě volat operace konektoru jako odchozí akce. Klientská plocha používá stejný základní spravovaný konektor v jmenném prostoru konektoru, který spouští používání, takže jeden spravovaný konektor může napájet jak příchozí spouštěče, tak odchozí volání pro stejný servisní účet.

V .NET každý konektor obsahuje typovaného klienta (například Office365Client, Office365UsersClient a TeamsClient) v rámci Azure.Connectors.Sdk.{Service}. Konstruktor klienta přijímá adresu URL připojení za běhu a přihlašovací údaj.

Následující vzor pochází z ukázky Teams pro komplexní vyhledávání uživatelů podle e-mailu:

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

*_CONNECTION_RUNTIME_URL Nastavení odkazují na koncový bod modulu runtime pro každé připojení v oboru názvů konektoru. Vložte klienty do své funkce a volejte typované metody, jako jsou UserProfileAsync, GetEmailsAsync nebo FlagAsync. Klienty sady SDK můžete také volat z triggerů jiných než konektory (například z triggeru HTTP, který odesílá do Teams).

V Python nainstalujte azure-connectors pro typové klienty (například office365, teams, office365Users). Klienti přijímají adresu URL modulu runtime pro jednotlivá připojení a přihlašovací údaj. Pokrytí akcí SDK se rozšiřuje.

V Node.jsnainstalujte @azure/connectors pro typové klienty (například office365, teams, office365Users). Klienti přijímají adresu URL modulu runtime pro jednotlivá připojení a přihlašovací údaj. Pokrytí akcí SDK se rozšiřuje.

Important

SDK konektoru není v těchto jazycích dostupné pro veřejný náhled.

  • Last updated on