Powiązania dla rozszerzenia Durable Functions (Azure Functions)

  • Artykuł

Rozszerzenie Durable Functions wprowadza trzy powiązania wyzwalacza, które kontrolują wykonywanie funkcji orkiestratora, jednostki i działania. Wprowadzono również powiązanie wyjściowe, które działa jako klient środowiska uruchomieniowego Durable Functions.

Pamiętaj, aby wybrać język programowania durable functions w górnej części artykułu.

Ważne

Ten artykuł obsługuje zarówno modele programowania Python v1, jak i Python v2 dla rozszerzenia Durable Functions.

Model programowania w języku Python w wersji 2

Rozszerzenie Durable Functions jest obsługiwane w nowym modelu programowania w języku Python w wersji 2. Aby użyć modelu w wersji 2, należy zainstalować zestaw Durable Functions SDK, który jest pakietem azure-functions-durablePyPI, wersją 1.2.2 lub nowszą wersją. Należy również host.json upewnić się, że aplikacja odwołuje się do pakietów rozszerzeń w wersji 4.x, aby używać modelu w wersji 2 z rozszerzeniem Durable Functions.

Możesz przekazać opinię i sugestie w repozytorium Durable Functions SDK dla języka Python.

Wyzwalacz orkiestracji

Wyzwalacz orkiestracji umożliwia tworzenie trwałych funkcji orkiestratora. Ten wyzwalacz jest wykonywany po zaplanowaniu nowego wystąpienia orkiestracji i odebraniu zdarzenia przez istniejące wystąpienie orkiestracji. Przykłady zdarzeń, które mogą wyzwalać funkcje orkiestratora, to trwałe wygaśnięcia czasomierza, odpowiedzi funkcji działania i zdarzenia zgłaszane przez klientów zewnętrznych.

Podczas tworzenia funkcji na platformie .NET wyzwalacz aranżacji jest konfigurowany przy użyciu atrybutu OrchestrationTriggerAttribute .NET.

W przypadku języka Java adnotacja @DurableOrchestrationTrigger służy do konfigurowania wyzwalacza aranżacji.

Podczas pisania funkcji orkiestratora wyzwalacz orkiestracji jest definiowany przez następujący obiekt JSON w bindings tablicy pliku function.json :

{
    "name": "<Name of input parameter in function signature>",
    "orchestration": "<Optional - name of the orchestration>",
    "type": "orchestrationTrigger",
    "direction": "in"
}
  • orchestration to nazwa orkiestracji, której klienci muszą używać, gdy chcą uruchomić nowe wystąpienia tej funkcji orkiestratora. Ta właściwość jest opcjonalna. Jeśli nie zostanie określona, zostanie użyta nazwa funkcji.

Usługa Azure Functions obsługuje dwa modele programowania dla języka Python. Sposób definiowania wyzwalacza aranżacji zależy od wybranego modelu programowania.

Model programowania w języku Python w wersji 2 umożliwia zdefiniowanie wyzwalacza orkiestracji przy użyciu dekoratora orchestration_trigger bezpośrednio w kodzie funkcji języka Python.

W modelu w wersji 2 wyzwalacze i powiązania rozszerzenia Durable Functions są dostępne z wystąpienia DFAppklasy , która jest podklasą FunctionApp , która dodatkowo eksportuje dekoratory specyficzne dla rozszerzenia Durable Functions.

Wewnętrznie to powiązanie wyzwalacza sonduje skonfigurowany trwały magazyn dla nowych zdarzeń orkiestracji, takich jak zdarzenia rozpoczęcia aranżacji, zdarzenia wygaśnięcia czasomierza trwałe, zdarzenia odpowiedzi funkcji działania i zdarzenia zewnętrzne zgłaszane przez inne funkcje.

Zachowanie wyzwalacza

Oto kilka uwag dotyczących wyzwalacza aranżacji:

  • Jednowątkowy — pojedynczy wątek dyspozytora jest używany do wykonywania wszystkich funkcji orkiestratora w jednym wystąpieniu hosta. Z tego powodu ważne jest, aby upewnić się, że kod funkcji orkiestratora jest wydajny i nie wykonuje żadnych operacji we/wy. Ważne jest również, aby upewnić się, że ten wątek nie wykonuje żadnej asynchronicznego działania, z wyjątkiem sytuacji, w których oczekuje się na typy zadań specyficznych dla rozszerzenia Durable Functions.
  • Obsługa komunikatów zatrutych — nie ma obsługi komunikatów trucizny w wyzwalaczach orkiestracji.
  • Widoczność komunikatów — komunikaty wyzwalacza orkiestracji są odsłonięty i niewidoczne przez konfigurowalny czas trwania. Widoczność tych komunikatów jest odnawiana automatycznie, o ile aplikacja funkcji jest uruchomiona i jest w dobrej kondycji.
  • Wartości zwracane — wartości zwracane są serializowane do formatu JSON i utrwalane w tabeli historii aranżacji w usłudze Azure Table Storage. Te wartości zwracane mogą być odpytywane przez powiązanie klienta aranżacji opisane w dalszej części.

Ostrzeżenie

Funkcje programu Orchestrator nigdy nie powinny używać żadnych powiązań wejściowych lub wyjściowych innych niż powiązanie wyzwalacza aranżacji. Może to spowodować problemy z rozszerzeniem Durable Task, ponieważ te powiązania mogą nie przestrzegać reguł we/wy pojedynczego wątku. Jeśli chcesz użyć innych powiązań, dodaj je do funkcji działania wywoływanej z funkcji orkiestratora. Aby uzyskać więcej informacji na temat ograniczeń kodowania funkcji orkiestratora, zobacz dokumentację ograniczeń kodu funkcji programu Orchestrator.

Ostrzeżenie

Funkcje programu Orchestrator nigdy nie powinny być deklarowane async.

Użycie wyzwalacza

Powiązanie wyzwalacza aranżacji obsługuje zarówno dane wejściowe, jak i wyjściowe. Oto kilka rzeczy, które należy wiedzieć o obsłudze danych wejściowych i wyjściowych:

  • inputs — wyzwalacze orkiestracji mogą być wywoływane z danymi wejściowymi, do których uzyskuje się dostęp za pośrednictwem obiektu wejściowego kontekstu. Wszystkie dane wejściowe muszą być serializowalne w formacie JSON.
  • outputs — wyzwalacze orkiestracji obsługują wartości wyjściowe, a także dane wejściowe. Zwracana wartość funkcji służy do przypisywania wartości wyjściowej i musi być serializowalne w formacie JSON.

Przykład wyzwalacza

Poniższy przykładowy kod pokazuje, jak może wyglądać najprostsza funkcja orkiestratora "Hello World". Należy pamiętać, że ten przykładowy koordynator nie planuje żadnych zadań.

Określony atrybut używany do definiowania wyzwalacza zależy od tego, czy uruchamiasz funkcje języka C# w procesie przetwarzania, czy w izolowanym procesie roboczym.

[FunctionName("HelloWorld")]
public static string Run([OrchestrationTrigger] IDurableOrchestrationContext context)
{
    string name = context.GetInput<string>();
    return $"Hello {name}!";
}

Uwaga

Poprzedni kod jest przeznaczony dla rozszerzenia Durable Functions 2.x. W przypadku rozszerzenia Durable Functions 1.x należy użyć funkcji DurableOrchestrationContextIDurableOrchestrationContextzamiast . Aby uzyskać więcej informacji na temat różnic między wersjami, zobacz artykuł Durable Functions Versions (Wersje rozszerzenia Durable Functions).

const df = require("durable-functions");

module.exports = df.orchestrator(function*(context) {
    const name = context.df.getInput();
    return `Hello ${name}!`;
});

Uwaga

Biblioteka durable-functions zajmuje się wywoływanie metody synchronicznej context.done , gdy funkcja generatora kończy działanie.

import azure.functions as func
import azure.durable_functions as df

myApp = df.DFApp(http_auth_level=func.AuthLevel.ANONYMOUS)

@myApp.orchestration_trigger(context_name="context")
def my_orchestrator(context):
    result = yield context.call_activity("Hello", "Tokyo")
    return result

param($Context)

$InputData = $Context.Input
$InputData

@FunctionName("HelloWorldOrchestration")
public String helloWorldOrchestration(
        @DurableOrchestrationTrigger(name = "ctx") TaskOrchestrationContext ctx) {
    return String.format("Hello %s!", ctx.getInput(String.class));
}

Większość funkcji orkiestratora wywołuje funkcje działania, więc oto przykład "Hello World", który pokazuje, jak wywołać funkcję działania:

[FunctionName("HelloWorld")]
public static async Task<string> Run(
    [OrchestrationTrigger] IDurableOrchestrationContext context)
{
    string name = context.GetInput<string>();
    string result = await context.CallActivityAsync<string>("SayHello", name);
    return result;
}

Uwaga

Poprzedni kod jest przeznaczony dla rozszerzenia Durable Functions 2.x. W przypadku rozszerzenia Durable Functions 1.x należy użyć funkcji DurableOrchestrationContextIDurableOrchestrationContextzamiast . Aby uzyskać więcej informacji na temat różnic między wersjami, zobacz artykuł Wersje rozszerzenia Durable Functions.

const df = require("durable-functions");

module.exports = df.orchestrator(function*(context) {
    const name = context.df.getInput();
    const result = yield context.df.callActivity("SayHello", name);
    return result;
});

@FunctionName("HelloWorld")
public String helloWorldOrchestration(
        @DurableOrchestrationTrigger(name = "ctx") TaskOrchestrationContext ctx) {
    String input = ctx.getInput(String.class);
    String result = ctx.callActivity("SayHello", input, String.class).await();
    return result;
}

Wyzwalacz działania

Wyzwalacz działania umożliwia tworzenie funkcji wywoływanych przez funkcje orkiestratora, znane jako funkcje działania.

Wyzwalacz działania jest konfigurowany przy użyciu atrybutu ActivityTriggerAttribute .NET.

Wyzwalacz działania jest konfigurowany przy użyciu adnotacji @DurableActivityTrigger .

Wyzwalacz działania jest definiowany przez następujący obiekt JSON w bindings tablicy function.json:

{
    "name": "<Name of input parameter in function signature>",
    "activity": "<Optional - name of the activity>",
    "type": "activityTrigger",
    "direction": "in"
}
  • activity to nazwa działania. Ta wartość jest nazwą używaną przez funkcje orkiestratora do wywoływania tej funkcji działania. Ta właściwość jest opcjonalna. Jeśli nie zostanie określona, zostanie użyta nazwa funkcji.

Sposób definiowania wyzwalacza działania zależy od wybranego modelu programowania.

Używanie dekoratora activity_trigger bezpośrednio w kodzie funkcji języka Python.

Wewnętrznie to powiązanie wyzwalacza sonduje skonfigurowany trwały magazyn dla nowych zdarzeń wykonywania działań.

Zachowanie wyzwalacza

Oto kilka notatek dotyczących wyzwalacza działania:

  • Wątkowanie — w przeciwieństwie do wyzwalacza orkiestracji wyzwalacze działań nie mają żadnych ograniczeń dotyczących wątkowania ani we/wy. Mogą być traktowane jak zwykłe funkcje.
  • Obsługa komunikatów zatrutych — nie ma obsługi komunikatów trucizny w wyzwalaczach aktywności.
  • Widoczność komunikatów — komunikaty wyzwalacza aktywności są w kolejce i są niewidoczne przez konfigurowalny czas trwania. Widoczność tych komunikatów jest odnawiana automatycznie, o ile aplikacja funkcji jest uruchomiona i jest w dobrej kondycji.
  • Wartości zwracane — wartości zwracane są serializowane do formatu JSON i utrwalane w skonfigurowanym magazynie trwałym.

Użycie wyzwalacza

Powiązanie wyzwalacza działania obsługuje zarówno dane wejściowe, jak i wyjściowe, podobnie jak wyzwalacz aranżacji. Oto kilka rzeczy, które należy wiedzieć o obsłudze danych wejściowych i wyjściowych:

  • inputs — wyzwalacze działania mogą być wywoływane z danymi wejściowymi z funkcji orkiestratora. Wszystkie dane wejściowe muszą być serializowalne w formacie JSON.
  • outputs — funkcje działania obsługują wartości wyjściowe, a także dane wejściowe. Zwracana wartość funkcji służy do przypisywania wartości wyjściowej i musi być serializowalne w formacie JSON.
  • metadata — funkcje działania platformy .NET mogą wiązać się z parametrem string instanceId w celu uzyskania identyfikatora wystąpienia wywołującej aranżacji.

Przykład wyzwalacza

Poniższy przykładowy kod pokazuje, jak może wyglądać prosta SayHello funkcja działania.

[FunctionName("SayHello")]
public static string SayHello([ActivityTrigger] IDurableActivityContext helloContext)
{
    string name = helloContext.GetInput<string>();
    return $"Hello {name}!";
}

Domyślnym typem parametru powiązania platformy .NET ActivityTriggerAttribute jest IDurableActivityContext (lub DurableActivityContext for Durable Functions v1). Jednak wyzwalacze działań platformy .NET obsługują również powiązanie bezpośrednio z typami serializowalnymi w formacie JSON (w tym typami pierwotnymi), dzięki czemu ta sama funkcja może zostać uproszczona w następujący sposób:

[FunctionName("SayHello")]
public static string SayHello([ActivityTrigger] string name)
{
    return $"Hello {name}!";
}

module.exports = async function(context) {
    return `Hello ${context.bindings.name}!`;
};

Powiązania języka JavaScript można również przekazać jako dodatkowe parametry, więc tę samą funkcję można uprościć w następujący sposób:

module.exports = async function(context, name) {
    return `Hello ${name}!`;
};

import azure.functions as func
import azure.durable_functions as df

myApp = df.DFApp(http_auth_level=func.AuthLevel.ANONYMOUS)

@myApp.activity_trigger(input_name="myInput")
def my_activity(myInput: str):
    return "Hello " + myInput

param($name)

"Hello $name!"

@FunctionName("SayHello")
public String sayHello(@DurableActivityTrigger(name = "name") String name) {
    return String.format("Hello %s!", name);
}

Używanie powiązań wejściowych i wyjściowych

Oprócz powiązania wyzwalacza działania można używać zwykłych powiązań wejściowych i wyjściowych.

Możesz na przykład przekazać dane wejściowe do powiązania działania i wysłać komunikat do centrum zdarzeń przy użyciu powiązania wyjściowego usługi Event Hubs:

{
  "bindings": [
    {
      "name": "message",
      "type": "activityTrigger",
      "direction": "in"
    },
    {
      "type": "eventHub",
      "name": "outputEventHubMessage",
      "connection": "EventhubConnectionSetting",
      "eventHubName": "eh_messages",
      "direction": "out"
  }
  ]
}

module.exports = async function (context) {
    context.bindings.outputEventHubMessage = context.bindings.message;
};

Klient orkiestracji

Powiązanie klienta orkiestracji umożliwia pisanie funkcji współdziałających z funkcjami orkiestratora. Te funkcje są często określane jako funkcje klienta. Na przykład możesz wykonywać działania na wystąpieniach orkiestracji w następujący sposób:

  • Uruchom je.
  • Wykonywanie zapytań o ich stan.
  • Zakończ je.
  • Wysyłaj do nich zdarzenia, gdy są uruchomione.
  • Przeczyść historię wystąpienia.

Można powiązać z klientem aranżacji przy użyciu atrybutu DurableClientAttribute (OrchestrationClientAttribute w rozszerzeniu Durable Functions w wersji 1.x).

Możesz powiązać z klientem aranżacji przy użyciu adnotacji @DurableClientInput .

Trwały wyzwalacz klienta jest definiowany przez następujący obiekt JSON w bindings tablicy function.json:

{
    "name": "<Name of input parameter in function signature>",
    "taskHub": "<Optional - name of the task hub>",
    "connectionName": "<Optional - name of the connection string app setting>",
    "type": "orchestrationClient",
    "direction": "in"
}
  • taskHub — Używane w scenariuszach, w których wiele aplikacji funkcji współużytkuje to samo konto magazynu, ale musi być odizolowane od siebie. Jeśli nie zostanie określona, zostanie użyta wartość domyślna.host.json Ta wartość musi być zgodna z wartością używaną przez funkcje orkiestratora docelowego.
  • connectionName— nazwa ustawienia aplikacji zawierającego konto magazynu parametry połączenia. Konto magazynu reprezentowane przez tę parametry połączenia musi być tym samym kontem używanym przez funkcje koordynatora docelowego. Jeśli nie zostanie określony, zostanie użyte domyślne konto magazynu parametry połączenia dla aplikacji funkcji.

Uwaga

W większości przypadków zalecamy pominięcie tych właściwości i poleganie na zachowaniu domyślnym.

Sposób definiowania trwałego wyzwalacza klienta zależy od wybranego modelu programowania.

Używanie dekoratora durable_client_input bezpośrednio w kodzie funkcji języka Python.

Użycie klienta

Zazwyczaj wiążesz się z elementem IDurableClient (DurableOrchestrationClient w rozszerzeniu Durable Functions w wersji 1.x), co zapewnia pełny dostęp do wszystkich interfejsów API klienta aranżacji obsługiwanych przez rozszerzenie Durable Functions.

Zazwyczaj wiążesz się z klasą DurableClientContext .

Aby uzyskać dostęp do obiektu klienta, musisz użyć zestawu SDK specyficznego dla języka.

Oto przykładowa funkcja wyzwalana przez kolejkę, która uruchamia orkiestrację "HelloWorld".

[FunctionName("QueueStart")]
public static Task Run(
    [QueueTrigger("durable-function-trigger")] string input,
    [DurableClient] IDurableOrchestrationClient starter)
{
    // Orchestration input comes from the queue message content.
    return starter.StartNewAsync<string>("HelloWorld", input);
}

Uwaga

Poprzedni kod języka C# jest przeznaczony dla rozszerzenia Durable Functions 2.x. W przypadku rozszerzenia Durable Functions 1.x należy użyć OrchestrationClient atrybutu zamiast atrybutu DurableClient i należy użyć typu parametru DurableOrchestrationClientIDurableOrchestrationClientzamiast . Aby uzyskać więcej informacji na temat różnic między wersjami, zobacz artykuł Durable Functions Versions (Wersje rozszerzenia Durable Functions).

function.json

{
  "bindings": [
    {
      "name": "input",
      "type": "queueTrigger",
      "queueName": "durable-function-trigger",
      "direction": "in"
    },
    {
      "name": "starter",
      "type": "durableClient",
      "direction": "in"
    }
  ]
}

index.js

const df = require("durable-functions");

module.exports = async function (context) {
    const client = df.getClient(context);
    return instanceId = await client.startNew("HelloWorld", undefined, context.bindings.input);
};

run.ps1

param([string] $input, $TriggerMetadata)

$InstanceId = Start-DurableOrchestration -FunctionName $FunctionName -Input $input

import azure.functions as func
import azure.durable_functions as df

myApp = df.DFApp(http_auth_level=func.AuthLevel.ANONYMOUS)

@myApp.route(route="orchestrators/{functionName}")
@myApp.durable_client_input(client_name="client")
async def durable_trigger(req: func.HttpRequest, client):
    function_name = req.route_params.get('functionName')
    instance_id = await client.start_new(function_name)
    response = client.create_check_status_response(req, instance_id)
    return response

function.json

{
  "bindings": [
    {
      "name": "input",
      "type": "queueTrigger",
      "queueName": "durable-function-trigger",
      "direction": "in"
    },
    {
      "name": "starter",
      "type": "durableClient",
      "direction": "in"
    }
  ]
}

run.ps1

param([string]$InputData, $TriggerMetadata)

$InstanceId = Start-DurableOrchestration -FunctionName 'HelloWorld' -Input $InputData

@FunctionName("QueueStart")
public void queueStart(
        @QueueTrigger(name = "input", queueName = "durable-function-trigger", connection = "Storage") String input,
        @DurableClientInput(name = "durableContext") DurableClientContext durableContext) {
    // Orchestration input comes from the queue message content.
    durableContext.getClient().scheduleNewOrchestrationInstance("HelloWorld", input);
}

Więcej informacji na temat uruchamiania wystąpień można znaleźć w temacie Zarządzanie wystąpieniami.

Wyzwalacz jednostki

Wyzwalacze jednostek umożliwiają tworzenie funkcji jednostki. Ten wyzwalacz obsługuje przetwarzanie zdarzeń dla określonego wystąpienia jednostki.

Uwaga

Wyzwalacze jednostek są dostępne od wersji Durable Functions 2.x.

Wewnętrznie to powiązanie wyzwalacza sonduje skonfigurowany trwały magazyn dla nowych operacji jednostki, które należy wykonać.

Wyzwalacz jednostki jest konfigurowany przy użyciu atrybutu EntityTriggerAttribute .NET.

Wyzwalacz jednostki jest definiowany przez następujący obiekt JSON w bindings tablicy function.json:

{
    "name": "<Name of input parameter in function signature>",
    "entityName": "<Optional - name of the entity>",
    "type": "entityTrigger",
    "direction": "in"
}

Domyślnie nazwa jednostki jest nazwą funkcji.

Uwaga

Wyzwalacze jednostek nie są jeszcze obsługiwane dla języka Java.

Sposób definiowania wyzwalacza jednostki zależy od wybranego modelu programowania.

Używanie dekoratora entity_trigger bezpośrednio w kodzie funkcji języka Python.

Zachowanie wyzwalacza

Oto kilka uwag dotyczących wyzwalacza jednostki:

  • Jednowątkowy: pojedynczy wątek dyspozytora służy do przetwarzania operacji dla określonej jednostki. Jeśli wiele komunikatów jest wysyłanych jednocześnie do jednej jednostki, operacje zostaną przetworzone pojedynczo.
  • Obsługa komunikatów zatrutych — nie ma obsługi komunikatów trucizny w wyzwalaczach jednostek.
  • Widoczność komunikatów — komunikaty wyzwalacza jednostki są odsłonięty i niewidoczne przez konfigurowalny czas trwania. Widoczność tych komunikatów jest odnawiana automatycznie, o ile aplikacja funkcji jest uruchomiona i jest w dobrej kondycji.
  • Wartości zwracane — funkcje jednostki nie obsługują wartości zwracanych. Istnieją określone interfejsy API, których można użyć do zapisania stanu lub przekazania wartości z powrotem do aranżacji.

Wszelkie zmiany stanu wprowadzone w jednostce podczas wykonywania zostaną automatycznie utrwalone po zakończeniu wykonywania.

Aby uzyskać więcej informacji i przykładów dotyczących definiowania wyzwalaczy jednostek i interakcji z nimi, zobacz dokumentację durable entities .

Klient jednostki

Powiązanie klienta jednostki umożliwia asynchroniczne wyzwalanie funkcji jednostki. Te funkcje są czasami określane jako funkcje klienta.

Można powiązać z klientem jednostki przy użyciu atrybutu DurableClientAttribute .NET w funkcjach biblioteki klas platformy .NET.

Uwaga

Można [DurableClientAttribute] go również użyć do powiązania z klientem aranżacji.

Klient jednostki jest definiowany przez następujący obiekt JSON w bindings tablicy function.json:

{
    "name": "<Name of input parameter in function signature>",
    "taskHub": "<Optional - name of the task hub>",
    "connectionName": "<Optional - name of the connection string app setting>",
    "type": "durableClient",
    "direction": "in"
}
  • taskHub — Używane w scenariuszach, w których wiele aplikacji funkcji współużytkuje to samo konto magazynu, ale musi być odizolowane od siebie. Jeśli nie zostanie określona, zostanie użyta wartość domyślna.host.json Ta wartość musi być zgodna z wartością używaną przez funkcje jednostki docelowej.
  • connectionName— nazwa ustawienia aplikacji zawierającego konto magazynu parametry połączenia. Konto magazynu reprezentowane przez tę parametry połączenia musi być takie samo, które jest używane przez funkcje jednostki docelowej. Jeśli nie zostanie określony, zostanie użyte domyślne konto magazynu parametry połączenia dla aplikacji funkcji.

Uwaga

W większości przypadków zalecamy pominięcie opcjonalnych właściwości i poleganie na zachowaniu domyślnym.

Sposób definiowania klienta jednostki zależy od wybranego modelu programowania.

Używanie dekoratora durable_client_input bezpośrednio w kodzie funkcji języka Python.

Uwaga

Klienci jednostek nie są jeszcze obsługiwani dla języka Java.

Aby uzyskać więcej informacji i przykładów dotyczących interakcji z jednostkami jako klientem, zobacz dokumentację jednostek trwałych .

ustawienia host.json

Ustawienia konfiguracji rozszerzenia Durable Functions.

Uwaga

Wszystkie główne wersje rozszerzenia Durable Functions są obsługiwane we wszystkich wersjach środowiska uruchomieniowego usługi Azure Functions. Jednak schemat konfiguracji host.json jest nieco inny w zależności od wersji środowiska uruchomieniowego usługi Azure Functions i używanej wersji rozszerzenia Durable Functions. Poniższe przykłady służą do użycia z usługami Azure Functions 2.0 i 3.0. W obu przykładach, jeśli używasz usługi Azure Functions 1.0, dostępne ustawienia są takie same, ale sekcja "durableTask" host.json powinna znajdować się w katalogu głównym konfiguracji host.json zamiast jako pola w obszarze "rozszerzenia".

{
 "extensions": {
  "durableTask": {
    "hubName": "MyTaskHub",
    "storageProvider": {
      "connectionStringName": "AzureWebJobsStorage",
      "controlQueueBatchSize": 32,
      "controlQueueBufferThreshold": 256,
      "controlQueueVisibilityTimeout": "00:05:00",
      "maxQueuePollingInterval": "00:00:30",
      "partitionCount": 4,
      "trackingStoreConnectionStringName": "TrackingStorage",
      "trackingStoreNamePrefix": "DurableTask",
      "useLegacyPartitionManagement": true,
      "useTablePartitionManagement": false,
      "workItemQueueVisibilityTimeout": "00:05:00",
    },
    "tracing": {
      "traceInputsAndOutputs": false,
      "traceReplayEvents": false,
    },
    "notifications": {
      "eventGrid": {
        "topicEndpoint": "https://topic_name.westus2-1.eventgrid.azure.net/api/events",
        "keySettingName": "EventGridKey",
        "publishRetryCount": 3,
        "publishRetryInterval": "00:00:30",
        "publishEventTypes": [
          "Started",
          "Completed",
          "Failed",
          "Terminated"
        ]
      }
    },
    "maxConcurrentActivityFunctions": 10,
    "maxConcurrentOrchestratorFunctions": 10,
    "extendedSessionsEnabled": false,
    "extendedSessionIdleTimeoutInSeconds": 30,
    "useAppLease": true,
    "useGracefulShutdown": false,
    "maxEntityOperationBatchSize": 50,
    "storeInputsInOrchestrationHistory": false
  }
 }
}

Nazwy centrum zadań muszą zaczynać się literą i składać się tylko z liter i cyfr. Jeśli nie zostanie określona, domyślna nazwa centrum zadań dla aplikacji funkcji to TestHubName. Aby uzyskać więcej informacji, zobacz Centra zadań.

Właściwości Domyślny opis
hubName TestHubName (DurableFunctionsHub, jeśli używasz rozszerzenia Durable Functions 1.x) Alternatywne nazwy centrum zadań mogą służyć do izolowania wielu aplikacji Durable Functions od siebie, nawet jeśli używają tego samego zaplecza magazynu.
controlQueueBatchSize 32 Liczba komunikatów do ściągnięcia z kolejki sterowania jednocześnie.
controlQueueBufferThreshold Plan zużycia dla języka Python: 32
Plan zużycia dla języków JavaScript i C#: 128
Plan dedykowany/Premium: 256		 Liczba komunikatów kolejki sterowania, które mogą być buforowane w pamięci w danym momencie, w tym momencie dyspozytor będzie czekać przed usunięciem z kolejki wszelkich dodatkowych komunikatów.
partitionCount 100 Liczba partycji dla kolejki sterowania. Może być dodatnią liczbą całkowitą z zakresu od 1 do 16.
controlQueueVisibilityTimeout 5 min Limit czasu widoczności komunikatów kolejki w kolejce.
workItemQueueVisibilityTimeout 5 min Limit czasu widoczności komunikatów kolejki elementów roboczych w kolejce w kolejce.
maxConcurrentActivityFunctions Plan zużycia: 10
Plan dedykowany/Premium: 10X liczba procesorów na bieżącej maszynie		 Maksymalna liczba funkcji działań, które mogą być przetwarzane współbieżnie w jednym wystąpieniu hosta.
maxConcurrentOrchestratorFunctions Plan zużycia: 5
Plan dedykowany/Premium: 10X liczba procesorów na bieżącej maszynie		 Maksymalna liczba funkcji orkiestratora, które mogą być przetwarzane współbieżnie w jednym wystąpieniu hosta.
maxQueuePollingInterval 30 sekund Maksymalny interwał sondowania kolejki kontrolek i elementów roboczych w formacie hh:mm:ss . Wyższe wartości mogą spowodować większe opóźnienia przetwarzania komunikatów. Niższe wartości mogą spowodować wyższe koszty magazynowania z powodu zwiększonych transakcji magazynu.
connectionName (2.7.0 i nowsze)
connectionStringName (2.x)
azureStorage Połączenie ionStringName (1.x)		 AzureWebJobsStorage Nazwa ustawienia aplikacji lub kolekcji ustawień, która określa sposób nawiązywania połączenia z bazowymi zasobami usługi Azure Storage. Po podaniu pojedynczego ustawienia aplikacji powinno to być parametry połączenia usługi Azure Storage.
trackingStore Połączenie ionName (2.7.0 i nowsze)
trackingStore Połączenie ionStringName		 Nazwa ustawienia aplikacji lub kolekcji ustawień, która określa sposób nawiązywania połączenia z tabelami Historia i wystąpienia. Po podaniu pojedynczego ustawienia aplikacji powinno to być parametry połączenia usługi Azure Storage. Jeśli nie zostanie określony, connectionStringName zostanie użyte połączenie (Durable 2.x) lub azureStorageConnectionStringName (Durable 1.x).
trackingStoreNamePrefix Prefiks używany dla tabel Historia i Wystąpienia, gdy trackingStoreConnectionStringName jest określony. Jeśli nie zostanie ustawiona, domyślną wartością prefiksu będzie DurableTask. Jeśli trackingStoreConnectionStringName nie zostanie określony, tabele Historia i wystąpienia będą używać wartości jako prefiksu hubName , a każde ustawienie dla trackingStoreNamePrefix elementu zostanie zignorowane.
traceInputsAndOutputs fałsz Wartość wskazująca, czy śledzić dane wejściowe i wyjściowe wywołań funkcji. Zachowaniem domyślnym podczas śledzenia zdarzeń wykonywania funkcji jest uwzględnienie liczby bajtów w serializowanych danych wejściowych i wyjściowych dla wywołań funkcji. To zachowanie zapewnia minimalne informacje o tym, jak wyglądają dane wejściowe i wyjściowe bez wzdęcia dzienników lub przypadkowo uwidaczniania poufnych informacji. Ustawienie tej właściwości na true powoduje, że domyślne rejestrowanie funkcji w celu rejestrowania całej zawartości danych wejściowych i wyjściowych funkcji.
traceReplayEvents fałsz Wartość wskazująca, czy zapisywać zdarzenia replay orkiestracji do aplikacji Szczegółowe informacje.
eventGridTopicEndpoint Adres URL niestandardowego punktu końcowego tematu usługi Azure Event Grid. Po ustawieniu tej właściwości zdarzenia powiadomień cyklu życia orkiestracji są publikowane w tym punkcie końcowym. Ta właściwość obsługuje rozpoznawanie Ustawienia aplikacji.
eventGridKeySettingName Nazwa ustawienia aplikacji zawierającego klucz używany do uwierzytelniania za pomocą tematu niestandardowego usługi Azure Event Grid pod adresem EventGridTopicEndpoint.
eventGridPublishRetryCount 0 Liczba ponownych prób w przypadku niepowodzenia publikowania w temacie usługi Event Grid.
eventGridPublishRetryInterval 5 min Usługa Event Grid publikuje interwał ponawiania prób w formacie hh:mm:ss .
eventGridPublishEventTypes Lista typów zdarzeń do opublikowania w usłudze Event Grid. Jeśli nie zostanie określony, wszystkie typy zdarzeń zostaną opublikowane. Dozwolone wartości to Started, , FailedCompleted, Terminated.
useAppLease prawda Po ustawieniu wartości trueaplikacje będą wymagać uzyskania dzierżawy obiektów blob na poziomie aplikacji przed przetworzeniem komunikatów centrum zadań. Aby uzyskać więcej informacji, zobacz dokumentację odzyskiwania po awarii i dystrybucji geograficznej. Dostępne od wersji 2.3.0.
useLegacyPartitionManagement fałsz W przypadku ustawienia na falsewartość program używa algorytmu zarządzania partycjami, który zmniejsza możliwość zduplikowania wykonywania funkcji podczas skalowania w górę. Dostępne od wersji 2.3.0.
useTablePartitionManagement fałsz W przypadku ustawienia na truewartość użyje algorytmu zarządzania partycjami zaprojektowanego w celu zmniejszenia kosztów kont usługi Azure Storage w wersji 2. Dostępne od wersji 2.10.0. Ta funkcja jest obecnie w wersji zapoznawczej i nie jest jeszcze zgodna z planem Zużycie.
useGracefulShutdown fałsz (Wersja zapoznawcza) Włącz bezproblemowe zamykanie, aby zmniejszyć prawdopodobieństwo zamknięcia hosta zakończonych niepowodzeniem wykonywania funkcji w procesie.
maxEntityOperationBatchSize(2.6.1) Plan zużycia: 50
Plan dedykowany/Premium: 5000		 Maksymalna liczba operacji jednostki przetwarzanych jako partia. Jeśli ustawiono wartość 1, przetwarzanie wsadowe jest wyłączone, a każdy komunikat operacji jest przetwarzany przez osobne wywołanie funkcji.
storeInputsInOrchestrationHistory fałsz Gdy jest ustawiona wartość true, informuje rozszerzenie Durable Task Framework o zapisaniu danych wejściowych działań w tabeli historii. Umożliwia to wyświetlanie danych wejściowych funkcji działania podczas wykonywania zapytań dotyczących historii aranżacji.

Wiele z tych ustawień jest przeznaczonych do optymalizacji wydajności. Aby uzyskać więcej informacji, zobacz Wydajność i skala.

Następne kroki

Wbudowana dokumentacja interfejsu API PROTOKOŁU HTTP na potrzeby zarządzania wystąpieniami