Poznámka:
Přístup k této stránce vyžaduje autorizaci. Můžete se zkusit přihlásit nebo změnit adresáře.
Přístup k této stránce vyžaduje autorizaci. Můžete zkusit změnit adresáře.
Durable Functions má několik funkcí, které usnadňují začlenění trvalých orchestrací a entit do pracovních postupů HTTP. Tento článek podrobně popisuje některé z těchto funkcí.
Zveřejnění rozhraní HTTP API
Orchestrace a entity je možné vyvolat a spravovat pomocí požadavků HTTP. Rozšíření Durable Functions zveřejňuje integrovaná rozhraní API HTTP. Poskytuje také rozhraní API pro interakci s orchestracemi a entitami z funkcí spuštěných protokolem HTTP.
Integrovaná rozhraní API HTTP
Rozšíření Durable Functions automaticky přidá sadu rozhraní HTTP API do hostitele Azure Functions. Pomocí těchto rozhraní API můžete interagovat s orchestracemi a entitami a spravovat je bez psaní kódu.
Podporují se následující integrovaná rozhraní API HTTP.
- Zahájení nové orchestrace
- Orchestrace instance dotazu
- Ukončení instance orchestrace
- Odeslání externí události do orchestrace
- Vyčistit historii orchestrace
- Odeslání události operace do entity
- Získání stavu entity
- Dotazování na seznam entit
Úplný popis všech integrovaných rozhraní API HTTP vystavených rozšířením Durable Functions najdete v článku HTTP API.
Zjišťování adres URL rozhraní HTTP API
Vazba orchestračního klienta poskytuje rozhraní API, která mohou generovat praktické části odpovědi HTTP. Může například vytvořit odpověď obsahující odkazy na rozhraní API pro správu pro konkrétní instanci orchestrace. Následující příklady ukazují funkci triggeru HTTP, která ukazuje použití tohoto rozhraní API pro novou instanci orchestrace:
// 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);
}
}
}
Návod
Pokud máte ve stejné aplikaci funkcí několik počátečních funkcí aktivovaných protokolem HTTP, nakonfigurujte pro každou funkci jedinečnou route možnost, aby nedocházelo ke konfliktům tras. Použití parametrizované trasy jako orchestrators/{functionName} (jak je znázorněno v několika předchozích příkladech) umožňuje, aby jedna počáteční funkce HTTP spustila jakýkoli orchestrátor podle názvu, což je často nejjednodušší přístup.
Spuštění funkce orchestrátoru pomocí dříve zobrazených funkcí triggeru HTTP je možné provést pomocí libovolného klienta HTTP. Následující příkaz cURL spustí funkci orchestrátoru s názvem DoWork:
curl -X POST https://localhost:7071/orchestrators/DoWork -H "Content-Length: 0" -i
Další je příklad odpovědi pro orchestraci, která má abc123 jako ID. Kvůli přehlednosti byly odebrány některé podrobnosti.
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"
}
V předchozím příkladu každé z polí končících na Uri odpovídá integrovanému rozhraní HTTP API. Tato rozhraní API můžete použít ke správě cílové instance orchestrace.
Poznámka:
Formát adres URL webhooku závisí na tom, jakou verzi Azure Functions hostitele používáte. Předchozí příklad je pro hostitele Azure Functions 2.0.
Popis všech integrovaných rozhraní API HTTP najdete v referenčních informacích k rozhraní HTTP API.
Sledování asynchronních operací
Výše uvedená odpověď HTTP je navržená tak, aby pomohla implementovat dlouhotrvající asynchronní rozhraní API HTTP s Durable Functions. Tento vzor se někdy označuje jako model příjemce dotazování. Tok klienta nebo serveru funguje takto:
- Klient vydá požadavek HTTP na spuštění dlouhotrvajícího procesu, jako je funkce orchestrátoru.
- Cílová HTTP aktivace vrátí odpověď HTTP 202 se záhlavím Location, které má hodnotu "statusQueryGetUri".
- Klient se dotazuje na adresu URL v hlavičce Umístění. Klient stále vidí odpovědi HTTP 202 s hlavičkou Location.
- Po dokončení nebo selhání instance koncový bod v hlavičce umístění vrátí HTTP 200.
Tento protokol umožňuje koordinaci dlouhotrvajících procesů s externími klienty nebo službami, které můžou dotazovat koncový bod HTTP a postupovat podle hlavičky Umístění. Implementace tohoto modelu klienta i serveru jsou integrovány do Durable Functions rozhraní API HTTP.
Poznámka:
Ve výchozím nastavení podporují všechny akce založené na protokolu HTTP poskytované Azure Logic Apps standardní vzor asynchronní operace. Tato funkce umožňuje vložit dlouho běžící odolnou funkci jako součást pracovního postupu Logic Apps. Podrobnější informace o podpoře Logic Apps pro asynchronní vzory HTTP naleznete v dokumentaci k akcím a triggerům pro pracovní postupy Azure Logic Apps.
Poznámka:
Interakce s orchestracemi je možné provádět z libovolného typu funkce, ne jenom funkcí aktivovaných protokolem HTTP.
Další informace o správě orchestrací a entit pomocí klientských rozhraní API najdete v článku Správa instancí.
Využívání HTTP API
Jak je popsáno v omezeních kódu orchestrátoru, funkce orchestrátoru nemůžou přímo provádět vstupně-výstupní operace. Místo toho obvykle volají aktivity, které provádějí vstupně-výstupní operace.
Počínaje verzí Durable Functions 2.0 můžou orchestrace nativně využívat rozhraní HTTP API pomocí vazby spouštěče orchestration.
Následující příklad kódu ukazuje funkci orchestrátoru, která vytváří odchozí požadavek HTTP:
[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
}
}
Poznámka:
Možná vás zajímá, proč tato funkce používá DurableHttpRequest a DurableHttpResponse místo předdefinovaných typů .NET HttpRequestMessage a HttpResponseMessage.
Tato volba návrhu je úmyslná. Hlavním důvodem je, že vlastní typy pomáhají zajistit, aby uživatelé nepředpokládá nesprávné předpoklady o podporovaném chování interního klienta HTTP. Typy specifické pro Durable Functions také umožňují zjednodušit návrh rozhraní API. Můžou také snadněji zpřístupnit speciální funkce, jako je integrace spravované identity a model příjemce dotazování.
Pomocí akce volat HTTP můžete ve funkcích orchestrátoru provést následující akce:
- Volejte rozhraní API HTTP přímo z funkcí orchestrace s určitými omezeními, která jsou zmíněna později.
- Automaticky podporuje vzory dotazování na stav HTTP 202 na straně klienta.
- Pomocí Azure spravovaných identit můžete provádět autorizovaná volání HTTP do jiných koncových bodů Azure.
Možnost využívat rozhraní HTTP API přímo z funkcí orchestrátoru je určená jako pohodlí pro určitou sadu běžných scénářů. Všechny tyto funkce můžete implementovat sami pomocí funkcí aktivit. V mnoha případech vám funkce aktivit můžou poskytnout větší flexibilitu.
Zpracování PROTOKOLU HTTP 202 (pouze .NET)
Rozhraní API pro volání HTTP může automaticky implementovat klientskou část vzoru spotřebitele dotazování. Pokud volané rozhraní API vrátí odpověď se stavem HTTP 202 a hlavičkou Umístění, funkce orchestrátoru automaticky opakovaně kontroluje prostředek na umístění, dokud neobdrží jinou odpověď než 202. Tato odpověď bude odpověď vrácená kódu funkce orchestrátoru.
[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);
}
Poznámka:
- Funkce orchestratoru také nativně podporují model cyklického dotazování na straně serveru, jak je popsáno ve sledování asynchronních operací. Tato podpora znamená, že orchestrace v jedné aplikaci funkcí můžou snadno koordinovat funkce orchestrátoru v jiných aplikacích funkcí. Podobá se konceptu dílčí orchestrace, ale podporuje komunikaci mezi aplikacemi. Tato podpora je užitečná zejména pro vývoj aplikací ve stylu mikroslužeb.
- Předdefinovaný vzor dotazování HTTP je aktuálně k dispozici pouze v hostiteli .NET.
- Dotazovací vzor je ve výchozím nastavení povolený v .NET In-process, ale ve výchozím nastavení je zakázán v .NET Isolated. Pokud ho chcete povolit v .NET Izolované, projděte si vzorový kód a nastavte asynchronní argumentPatternEnabled na hodnotu true.
- Model automatického dotazování HTTP je podporován v izolovaném prostředí Durable Functions .NET od verze v1.5.0 nebo novější.
Spravované identity
Durable Functions nativně podporuje volání rozhraní API, která přijímají tokeny Microsoft Entra pro autorizaci. Tato podpora používá k získání těchto tokenů spravované identity Azure.
Následující kód je příkladem funkce orchestrátoru. Funkce provádí ověřená volání k restartování virtuálního počítače pomocí rozhraní REST API Azure Resource Manager virtual machines.
[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}");
}
}
V předchozím příkladu je parametr tokenSource nakonfigurovaný tak, aby získal tokeny Microsoft Entra pro Azure Resource Manager. Tokeny jsou identifikovány identifikátorem URI https://management.core.windows.net/.defaultprostředku . Příklad předpokládá, že aktuální aplikace funkcí běží místně nebo byla nasazena jako aplikace funkcí se spravovanou identitou. Předpokládá se, že místní identita nebo spravovaná identita mají oprávnění ke správě virtuálních počítačů v zadané skupině myRGprostředků.
Za běhu nakonfigurovaný zdroj tokenu automaticky vrátí přístupový token OAuth 2.0. Zdroj pak token přidá jako nosný token do autorizační hlavičky odchozího požadavku. Tento model je vylepšením ručního přidávání autorizačních hlaviček do požadavků HTTP z následujících důvodů:
- Aktualizace tokenu se zpracovává automaticky. Nemusíte se starat o tokeny s vypršenou platností.
- Tokeny se nikdy neukládají ve stavu trvalé orchestrace.
- Ke správě získávání tokenů nemusíte psát žádný kód.
Úplnější příklad najdete v předkompilované ukázce C# RestartVMs.
Spravované identity nejsou omezené na správu prostředků Azure. Spravované identity můžete použít pro přístup k libovolnému rozhraní API, které přijímá Microsoft Entra nosné tokeny, včetně Azure služeb od Microsoftu a webových aplikací od partnerů. Webová aplikace partnera může být dokonce jinou funkční aplikací. Seznam služeb Azure od Microsoftu, které podporují ověřování pomocí Microsoft Entra ID, najdete v tématu Azure služby, které podporují ověřování Microsoft Entra.
Omezení
Integrovaná podpora volání rozhraní HTTP API je funkce usnadnění. Není vhodné pro všechny scénáře.
Požadavky HTTP odeslané funkcemi orchestrátoru a jejich odpovědi jsou serializované a trvalé jako zprávy ve zprostředkovateli úložiště Durable Functions. Toto trvalé chování při řízení front zajišťuje, že volání HTTP jsou spolehlivá a bezpečná pro přehrání orchestrace. Trvalé chování front však má svá omezení:
- Každý požadavek HTTP zahrnuje další latenci ve srovnání s nativním klientem HTTP.
- V závislosti na nakonfigurovaných poskytovatelích úložiště můžou velké zprávy požadavků nebo odpovědí výrazně snížit výkon orchestrace. Například při použití Azure Storage jsou datové části HTTP, které jsou příliš velké, aby se vešly do zpráv Azure Queue, komprimovány a uloženy v Azure Blob úložišti.
- Streamování, blokované a binární datové části se nepodporují.
- Schopnost přizpůsobit chování klienta HTTP je omezená.
Pokud některá z těchto omezení může mít vliv na váš případ použití, zvažte místo toho použití funkce aktivit a klientské knihovny HTTP specifické pro jazyk k odchozím voláním HTTP.
Rozšiřitelnost (pouze .NET v procesu)
Přizpůsobení chování interního HTTP klienta orchestrace je možné pomocí dependency injection Azure Functions .NET pro pracovníka, který běží v procesu. Tato schopnost může být užitečná při provádění malých změn chování. Může být také užitečné pro testování jednotek klienta HTTP vložením napodobených objektů.
Následující příklad ukazuje použití injektáže závislostí k zakázání ověřování certifikátů TLS/SSL pro funkce orchestrátoru, které volají externí koncové body HTTP.
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,
};
}
}