Freigeben über


HTTP-Features

Durable Functions verfügt über mehrere Features, die die Integration dauerhafter Orchestrierungen und Entitäten in HTTP-Workflows erleichtern. In diesem Artikel werden einige dieser Features ausführlich erläutert.

Verfügbarmachen von HTTP-APIs

Orchestrierungen und Entitäten können mithilfe von HTTP-Anforderungen aufgerufen und verwaltet werden. Die Durable Functions Erweiterung macht integrierte HTTP-APIs verfügbar. Außerdem stellt sie APIs für die Interaktion mit Orchestrierungen und Entitäten aus über HTTP ausgelösten Funktionen heraus bereit.

Integrierte HTTP-APIs

Die Durable Functions Erweiterung fügt dem Azure Functions-Host automatisch eine Reihe von HTTP-APIs hinzu. Diese APIs ermöglichen es Ihnen, mit Orchestrierungen und Entitäten zu interagieren und diese zu verwalten, ohne dass hierfür Programmieraufwand erforderlich ist.

Die folgenden integrierten HTTP-APIs werden unterstützt.

Eine vollständige Beschreibung aller integrierten HTTP-APIs, die von der Durable Functions-Erweiterung verfügbar gemacht werden, finden Sie im Artikel HTTP-APIs.

Ermittlung der HTTP-API-URL

Die Orchestrierungs-Client-Bindung stellt APIs bereit, die praktische HTTP-Antwortnutzlasten generieren können. Sie kann beispielsweise eine Antwort mit Links zu Verwaltungs-APIs für eine bestimmte Orchestrierungsinstanz erstellen. Im Folgenden finden Sie Beispiele für eine HTTP-Triggerfunktion, die zeigt, wie diese API für eine neue Orchestrierungsinstanz verwendet wird:

// Copyright (c) .NET Foundation. All rights reserved.
// Licensed under the MIT License. See LICENSE in the project root for license information.

using System.Net.Http;
using System.Threading.Tasks;
using Microsoft.Azure.WebJobs;
using Microsoft.Azure.WebJobs.Extensions.DurableTask;
using Microsoft.Azure.WebJobs.Extensions.Http;
using Microsoft.Extensions.Logging;

namespace VSSample
{
    public static class HttpStart
    {
        [FunctionName("HttpStart")]
        public static async Task<HttpResponseMessage> Run(
            [HttpTrigger(AuthorizationLevel.Function, methods: "post", Route = "orchestrators/{functionName}")] HttpRequestMessage req,
            [DurableClient] IDurableClient starter,
            string functionName,
            ILogger log)
        {
            // Function input comes from the request content.
            object eventData = await req.Content.ReadAsAsync<object>();
            string instanceId = await starter.StartNewAsync(functionName, eventData);

            log.LogInformation($"Started orchestration with ID = '{instanceId}'.");

            return starter.CreateCheckStatusResponse(req, instanceId);
        }
    }
}

Das Starten einer Orchestratorfunktion mithilfe der oben gezeigten HTTP-Triggerfunktionen kann über einen beliebigen HTTP-Client erfolgen. Der folgende cURL-Befehl startet eine Orchestratorfunktion mit dem Namen DoWork:

curl -X POST https://localhost:7071/orchestrators/DoWork -H "Content-Length: 0" -i

Als Nächstes folgt eine Beispielantwort für eine Orchestrierung, die abc123 als ID hat. Einige Details wurden aus Gründen der Übersichtlichkeit entfernt.

HTTP/1.1 202 Accepted
Content-Type: application/json; charset=utf-8
Location: http://localhost:7071/runtime/webhooks/durabletask/instances/abc123?code=XXX
Retry-After: 10

{
    "id": "abc123",
    "purgeHistoryDeleteUri": "http://localhost:7071/runtime/webhooks/durabletask/instances/abc123?code=XXX",
    "sendEventPostUri": "http://localhost:7071/runtime/webhooks/durabletask/instances/abc123/raiseEvent/{eventName}?code=XXX",
    "statusQueryGetUri": "http://localhost:7071/runtime/webhooks/durabletask/instances/abc123?code=XXX",
    "terminatePostUri": "http://localhost:7071/runtime/webhooks/durabletask/instances/abc123/terminate?reason={text}&code=XXX"
}

Im vorherigen Beispiel entspricht jedes der Felder, die auf Uri enden, einer eingebauten HTTP-API. Sie können diese APIs verwenden, um die Zielorchestrierungsinstanz zu verwalten.

Hinweis

Das Format der Webhook-URLs hängt davon ab, welche Version des Azure Functions Hosts Sie ausführen. Das vorherige Beispiel ist für den Azure Functions 2.0-Host.

Eine Beschreibung aller integrierten HTTP-APIs finden Sie in der HTTP-API-Referenz.

Nachverfolgen von asynchronen Vorgängen

Die zuvor erwähnte HTTP-Antwort dient zur Implementierung lang ausgeführter HTTP-asynchroner APIs mit Durable Functions. Dieses Muster wird manchmal als Polling-Consumer-Muster bezeichnet. Der Client/Server-Datenfluss funktioniert wie folgt:

  1. Der Client übermittelt eine HTTP-Anforderung, um einen Prozess mit langer Ausführungsdauer zu starten, z. B. eine Orchestratorfunktion.
  2. Der HTTP-Zieltrigger gibt eine HTTP 202-Antwort mit einem Location-Header zurück, der den Wert „statusQueryGetUri“ aufweist.
  3. Der Client fragt die URL im Location-Header ab. Der Client erhält weiterhin die HTTP 202-Antworten mit dem Location-Header.
  4. Wenn die Instanz abgeschlossen wurde (oder zu einem Fehler geführt hat), gibt der Endpunkt im Location-Header als Antwort „HTTP 200“ zurück.

Dieses Protokoll ermöglicht die Koordination von Prozessen mit langer Ausführungsdauer mit externen Clients oder Diensten, die einen HTTP-Endpunkt abfragen können und den Location-Header befolgen. Sowohl die Client- als auch die Serverimplementierungen dieses Musters sind in die Durable Functions HTTP-APIs integriert.

Hinweis

Standardmäßig unterstützen alle HTTP-basierten Aktionen, die von Azure Logic Apps bereitgestellt werden, das standardmäßige asynchrone Vorgangsmuster. Diese Funktion ermöglicht das Einbetten eines Durable Functions-Elements als Teil eines Logic Apps-Workflows. Weitere Informationen zur Unterstützung von Logik-Apps für asynchrone HTTP-Muster finden Sie in den Azure Logic Apps Workflowaktionen und Triggerdokumentation.

Hinweis

Die Interaktion mit Orchestrierungen kann von jedem Funktionstyp aus erfolgen, nicht nur durch über HTTP ausgelöste Funktionen.

Weitere Informationen zum Verwalten von Orchestrierungen und Entitäten mithilfe von Client-APIs finden Sie im Artikel zur Instanzverwaltung.

Verarbeiten von HTTP-APIs

Wie in den Orchestrator-Codeeinschränkungen beschrieben, können Orchestratorfunktionen keine direkte E/A-Funktion ausführen. Stattdessen rufen sie normalerweise Aktivitäten auf, die E/A-Vorgänge ausführen.

Ab Durable Functions 2.0 können Orchestrierungen http-APIs mithilfe der orchestration trigger binding nativ nutzen.

Der folgende Beispielcode zeigt eine Orchestratorfunktion, die eine ausgehende HTTP-Anforderung vornimmt:

[FunctionName(nameof(CheckSiteAvailable))]
public static async Task CheckSiteAvailable(
    [OrchestrationTrigger] IDurableOrchestrationContext context)
{
    Uri url = context.GetInput<Uri>();

    // Makes an HTTP GET request to the specified endpoint
    DurableHttpResponse response = 
        await context.CallHttpAsync(HttpMethod.Get, url);

    if (response.StatusCode >= 400)
    {
        // handling of error codes goes here
    }
}

Hinweis

Sie fragen sich vielleicht, warum dieses Feature die Typen DurableHttpRequest und DurableHttpResponse anstelle der integrierten .NET-Typen HttpRequestMessage und HttpResponseMessage verwendet.

Dies ist eine bewusste Entscheidung. In erster Linie stellen benutzerdefinierte Typen sicher, dass Benutzer keine falschen Annahmen über unterstützte Verhaltensweisen des internen HTTP-Clients treffen. Typen, die für Durable Functions spezifisch sind, ermöglichen auch die Vereinfachung des API-Designs. Sie können auch einfacher spezielle Features wie die Integration der verwalteten Identität und das Abfrage-Verbrauchermuster verfügbar machen.

Mit der Aktion „call HTTP“ sind in Ihren Orchestratorfunktionen folgende Aktionen möglich:

  • Direktes Aufrufen von HTTP-APIs aus Orchestrierungsfunktionen mit einigen später beschriebenen Einschränkungen
  • Automatisches Unterstützen clientseitiger HTTP 202-Statusabrufmuster
  • Verwenden Sie Azure Managed Identities, um autorisierte HTTP-Aufrufe an andere Azure Endpunkte zu tätigen.

Die Möglichkeit, HTTP-APIs direkt von Orchestratorfunktionen zu nutzen, ist bei einigen häufigen Szenarien sehr praktisch. Sie können alle diese Features selbst mithilfe von Aktivitätsfunktionen implementieren. In vielen Fällen bieten Ihnen Aktivitätsfunktionen mehr Flexibilität.

HTTP 202-Behandlung (nur .NET)

Die API „call HTTP“ kann die Clientseite des Polling Consumer Pattern automatisch implementieren. Wenn eine aufgerufene API eine HTTP 202-Antwort mit einem Location-Header zurückgibt, ruft die Orchestratorfunktion automatisch die Location-Ressource ab, bis eine Antwort zurückgegeben wird, die nicht 202 ist. Dies ist die Antwort, die an den Orchestratorfunktionscode zurückgegeben wird.

[FunctionName(nameof(CheckSiteAvailabilityWithPolling))]
public static async Task CheckSiteAvailabilityWithPolling(
    [OrchestrationTrigger] IDurableOrchestrationContext context)
{
    Uri url = context.GetInput<Uri>();

    // HTTP automatic polling on 202 response is enabled by default in .NET in-process.
    DurableHttpResponse response = 
        await context.CallHttpAsync(HttpMethod.Get, url);
}

Hinweis

  • Orchestrator-Funktionen unterstützen das serverseitige Abruf-Consumermuster auch nativ, wie in der Async-Vorgangsverfolgung beschrieben. Diese Unterstützung bedeutet, dass Orchestrierungen in einer Funktions-App die Orchestratorfunktionen in anderen Funktions-Apps problemlos koordinieren können. Dies ähnelt dem Sub-Orchestrierungskonzept , aber mit Unterstützung für die appübergreifende Kommunikation. Diese Unterstützung ist insbesondere beim Entwickeln von Apps im Stil von Microservices praktisch.
  • Das integrierte HTTP-Polling-Muster ist derzeit nur im .NET-Host verfügbar.
  • Das Polling-Muster ist standardmäßig in .NET In-Process aktiviert, aber in .NET Isolated deaktiviert. Wenn Sie es in .NET Isolated aktivieren möchten, verweisen Sie auf den Beispielcode, und legen Sie das argument "asynchronousPatternEnabled" auf "true" fest.
  • Das automatische HTTP-Abrufmuster wird in Durable Functions .NET Isolated ab Version v1.5.0 oder höher unterstützt.

Verwaltete Identitäten

Durable Functions unterstützt systemeigene Aufrufe von APIs, die Microsoft Entra Token zur Autorisierung akzeptieren. Diese Unterstützung verwendet Azure verwaltete Identitäten, um diese Token abzurufen.

Der folgende Code ist ein Beispiel für eine .NET-Orchestratorfunktion. Die Funktion führt authentifizierte Aufrufe durch, um einen virtuellen Computer mithilfe der REST-API Azure Resource Manager virtual machines neu zu starten.

[FunctionName("RestartVm")]
public static async Task RunOrchestrator(
    [OrchestrationTrigger] IDurableOrchestrationContext context)
{
    string subscriptionId = "mySubId";
    string resourceGroup = "myRG";
    string vmName = "myVM";
    string apiVersion = "2019-03-01";
    
    // Automatically fetches an Azure AD token for resource = https://management.core.windows.net/.default
    // and attaches it to the outgoing Azure Resource Manager API call.
    var restartRequest = new DurableHttpRequest(
        HttpMethod.Post, 
        new Uri($"https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroup}/providers/Microsoft.Compute/virtualMachines/{vmName}/restart?api-version={apiVersion}"),
        tokenSource: new ManagedIdentityTokenSource("https://management.core.windows.net/.default"));
    DurableHttpResponse restartResponse = await context.CallHttpAsync(restartRequest);
    if (restartResponse.StatusCode != HttpStatusCode.OK)
    {
        throw new ArgumentException($"Failed to restart VM: {restartResponse.StatusCode}: {restartResponse.Content}");
    }
}

Im vorherigen Beispiel ist der Parameter tokenSource so konfiguriert, dass Microsoft Entra Token für Azure Resource Manager erfasst werden. Die Token werden durch den Ressourcen-URI https://management.core.windows.net/.defaultidentifiziert. Im Beispiel wird davon ausgegangen, dass die aktuelle Funktions-App entweder lokal ausgeführt wird oder als eine Funktions-App mit einer verwalteten Identität bereitgestellt wurde. Die lokale Identität oder die verwaltete Identität wird angenommen, dass sie über die Berechtigung zum Verwalten von VMs in der angegebenen Ressourcengruppe myRGverfügt.

Zur Laufzeit gibt die konfigurierte Tokenquelle automatisch ein OAuth 2.0-Zugriffstoken zurück. Die Quelle fügt das Token dann als Bearertoken dem Autorisierungsheader der ausgehenden Anforderung hinzu. Dieses Modell ist aus folgenden Gründen besser als das manuelle Hinzufügen eines Autorisierungsheaders zu HTTP-Anforderungen:

  • Die Tokenaktualisierung wird automatisch durchgeführt. Sie müssen sich nicht um abgelaufene Token kümmern.
  • Token werden niemals im Zustand der dauerhaften Orchestrierung gespeichert.
  • Sie müssen keinen Code schreiben, um den Tokenabruf zu verwalten.

Ein vollständiges Beispiel finden Sie im Beispiel precompiled C# RestartVMs.

Verwaltete Identitäten sind nicht auf Azure Ressourcenverwaltung beschränkt. Sie können verwaltete Identitäten verwenden, um auf jede API zuzugreifen, die Microsoft Entra Bearertoken akzeptiert, einschließlich Azure Dienste von Microsoft und Web-Apps von Partnern. Die Web-App eines Partners kann sogar eine andere Funktions-App sein. Eine Liste der Azure Dienste von Microsoft, die die Authentifizierung mit Microsoft Entra ID unterstützen, finden Sie unter Azure Services, die Microsoft Entra Authentifizierung unterstützen.

Einschränkungen

Die integrierte Unterstützung für das Aufrufen von HTTP-APIs ist ein praktisches Feature. Es ist nicht für alle Szenarien geeignet.

HTTP-Anforderungen, die von Orchestratorfunktionen gesendet werden, und ihre Antworten werden als Nachrichten im Durable Functions-Speicheranbieter serialisiert und persistiert. Dieses persistente Warteschlangenverhalten stellt sicher, dass HTTP-Aufrufe für die Orchestrierungswiedergabe zuverlässig und sicher sind. Für das persistente Queuingverhalten gelten jedoch ebenfalls Einschränkungen:

  • Jede HTTP-Anforderung umfasst eine zusätzliche Wartezeit im Vergleich zu einem nativen HTTP-Client.
  • Je nach konfiguriertem Speicheranbieter können große Anforderungs- oder Antwortnachrichten die Orchestrierungsleistung erheblich beeinträchtigen. Wenn Sie beispielsweise Azure Storage verwenden, werden HTTP-Nutzlasten, die zu groß sind, um in Azure-Warteschlangennachrichten zu passen, komprimiert und im Azure Blob-Speicher gespeichert.
  • Streaming und segmentierte und binäre Nutzlasten werden nicht unterstützt.
  • Die Möglichkeit, das Verhalten des HTTP-Clients anzupassen, ist begrenzt.

Wenn Ihr Anwendungsfall durch eine dieser Einschränkungen beeinträchtigt wird, nutzen Sie stattdessen ggf. Aktivitätsfunktionen und sprachspezifische HTTP-Clientbibliotheken, um ausgehende HTTP-Aufrufe vorzunehmen.

Erweiterbarkeit (nur .NET in Bearbeitung)

Das Anpassen des Verhaltens des internen HTTP-Clients der Orchestrierung ist mithilfe von Azure Functions .NET-Abhängigkeits-Injektion für den In-Process-Worker möglich. Diese Funktion kann nützlich sein, um geringfügige Verhaltensänderungen vorzunehmen. Sie kann auch hilfreich sein, um Komponententests für den HTTP-Client durch Einfügen von Pseudoobjekten durchzuführen.

Das folgende Beispiel veranschaulicht die Verwendung der Abhängigkeitsinjektion, um die TLS/SSL-Zertifikatüberprüfung für Orchestratorfunktionen zu deaktivieren, die externe HTTP-Endpunkte aufrufen.

public class Startup : FunctionsStartup
{
    public override void Configure(IFunctionsHostBuilder builder)
    {
        // Register own factory
        builder.Services.AddSingleton<
            IDurableHttpMessageHandlerFactory,
            MyDurableHttpMessageHandlerFactory>();
    }
}

public class MyDurableHttpMessageHandlerFactory : IDurableHttpMessageHandlerFactory
{
    public HttpMessageHandler CreateHttpMessageHandler()
    {
        // Disable TLS/SSL certificate validation (not recommended in production!)
        return new HttpClientHandler
        {
            ServerCertificateCustomValidationCallback =
                HttpClientHandler.DangerousAcceptAnyServerCertificateValidator,
        };
    }
}

Nächste Schritte