Bindungen für Durable Functions (Azure Functions)

  • Artikel

Mit der Erweiterung Durable Functions (Langlebige Funktionen) werden drei neue Triggerbindungen eingeführt, mit denen die Ausführung von Orchestrator-, Entitäts- und Aktivitätsfunktionen gesteuert wird. Außerdem wird eine Ausgabebindung eingeführt, die als Client für die Laufzeit von Durable Functions dient.

Stellen Sie sicher, dass Sie oben im Artikel Ihre Durable Functions-Programmiersprache auswählen.

Wichtig

In diesem Artikel werden sowohl Python v1- als auch Python v2-Programmiermodelle für Durable Functions unterstützt.

Python v2-Programmiermodell

Durable Functions wird im neuen Python v2-Programmiermodell unterstützt. Um das v2-Modell verwenden zu können, müssen Sie das Durable Functions SDK installieren, wobei es sich um das PyPI-Paketazure-functions-durable, Version 1.2.2 oder eine höhere Version handelt. Sie müssen auch host.json überprüfen, um sicherzustellen, dass Ihre App auf Version 4.x des Erweiterungsbundles verweist, sodass das v2-Modell mit Durable Functions verwendet wird.

Sie können Feedback und Vorschläge im Repository des Durable Functions SDK für Python bereitstellen.

Orchestrierungstrigger

Mit einem Orchestrierungstrigger können Sie langlebige Orchestratorfunktionen erstellen. Dieser Trigger wird ausgeführt, wenn eine neue Orchestrierungsinstanz geplant ist und eine vorhandene Orchestrierungsinstanz ein Ereignis empfängt. Beispiele für Ereignisse, die Orchestratorfunktionen auslösen können, sind dauerhafte Timerablauf, Aktivitätsfunktionsantworten und Ereignisse, die von externen Clients ausgelöst werden.

Wenn Sie Funktionen in .NET erstellen, wird der Orchestrierungstrigger mit dem OrchestrationTriggerAttribute .NET-Attribut konfiguriert.

Bei Java wird die @DurableOrchestrationTrigger-Anmerkung zum Konfigurieren des Orchestrierungstriggers verwendet.

Wenn Sie Orchestratorfunktionen schreiben, wird der Orchestrierungstrigger mit dem folgenden JSON-Objekt im bindings-Array der Datei function.json definiert:

{
    "name": "<Name of input parameter in function signature>",
    "orchestration": "<Optional - name of the orchestration>",
    "type": "orchestrationTrigger",
    "direction": "in"
}
  • orchestration ist der Name der Orchestrierung, den Clients verwenden müssen, wenn sie neue Instanzen dieser Orchestratorfunktion starten möchten. Diese Eigenschaft ist optional. Wenn sie nicht angegeben ist, wird der Name der Funktion verwendet.

Azure Functions unterstützt zwei Programmiermodelle für Python. Die Art und Weise, wie Sie einen Orchestrierungstrigger definieren, hängt vom gewählten Programmiermodell ab.

Mit dem Python v2-Programmiermodell können Sie einen Orchestrierungstrigger mit dem orchestration_trigger-Decorator direkt in Ihrem Python-Funktionscode definieren.

Im v2-Modell kann auf die Durable Functions-Trigger und -Bindungen von einer Instanz von DFApp zugegriffen werden, d. h. einer Unterklasse von FunctionApp, die zusätzlich für Durable Functions spezifische Decorator-Elemente exportiert.

Intern wird der konfigurierte permanente Speicher von dieser Triggerbindung nach neuen Orchestrierungsereignissen wie Orchestrierungsstartereignissen, dauerhaften Ablaufereignissen für Timer, Aktivitätsfunktionsantwortereignissen und externen Ereignissen, die von anderen Funktionen ausgelöst werden, abruft.

Triggerverhalten

Hier sind einige Hinweise zum Orchestrierungstrigger angegeben:

  • Single-Threading: Ein einzelner Verteilerthread wird für die gesamte Ausführung von Orchestratorfunktionen auf einer einzelnen Hostinstanz verwendet. Daher sollten Sie unbedingt sicherstellen, dass der Orchestratorfunktionscode effizient ist und keine E/A-Vorgänge durchführt. Außerdem sollten Sie sicherstellen, dass dieser Thread nur dann asynchrone Arbeitsschritte ausführt, wenn auf Aufgabentypen gewartet wird, die sich auf Durable Functions beziehen.
  • Behandlung von nicht verarbeitbaren Nachrichten: Orchestrierungstrigger weisen keine Unterstützung für nicht verarbeitbare Nachrichten auf.
  • Sichtbarkeit von Nachrichten: Nachrichten des Orchestrierungstriggers werden aus der Warteschlange entfernt und bleiben für eine konfigurierbare Dauer unsichtbar. Die Sichtbarkeit dieser Nachrichten wird automatisch erneuert, solange die Funktionen-App ausgeführt wird und fehlerfrei ist.
  • Rückgabewerte: Rückgabewerte werden in JSON-Code serialisiert und in der Tabelle mit dem Orchestrierungsverlauf im Azure-Tabellenspeicher beibehalten. Diese Rückgabewerte können von der Orchestrierungsclientbindung abgefragt werden, die weiter unten beschrieben wird.

Warnung

Für Orchestratorfunktionen sollten niemals andere Eingabe- oder Ausgabebindungen als die Orchestrierungstriggerbindung verwendet werden. Wenn dies nicht beachtet wird, können sich unter Umständen Probleme mit der Erweiterung für langlebige Aufgaben ergeben, da sich diese Bindungen ggf. nicht an die Regeln für Single-Threading und E/A-Abläufe halten. Wenn Sie andere Bindungen verwenden möchten, fügen Sie diese einer Aktivitätsfunktion hinzu, die von der Orchestratorfunktion aufgerufen wird. Weitere Informationen zu Codeeinschränkungen für Orchestratorfunktionen finden Sie im Thema Codeeinschränkungen für Orchestratorfunktionen.

Warnung

Orchestratorfunktionen sollten niemals als async deklariert werden.

Triggerverwendung

Die Orchestrierungstriggerbindung unterstützt sowohl Ein- als auch Ausgaben. Hier sind einige Dinge aufgeführt, die Sie in Bezug auf die Eingabe- und Ausgabeverarbeitung wissen sollten:

  • Eingaben: Orchestrierungstrigger können mit Eingaben aufgerufen werden, auf die über das Kontexteingabeobjekt zugegriffen wird. Alle Eingaben müssen JSON-serialisierbar sein.
  • Ausgaben: Orchestrierungstrigger unterstützen sowohl Ausgabewerte als auch Eingaben. Der Rückgabewert der Funktion wird verwendet, um den Ausgabewert zuzuweisen, und er muss per JSON serialisierbar sein.

Triggerbeispiel

Der folgende Beispielcode zeigt, wie eine sehr einfache Orchestratorfunktion vom Typ „Hello World“ aussehen könnte. Beachten Sie, dass dieser Beispielorchestrator keine Vorgänge plant.

Welches spezifische Attribut zum Definieren des Triggers verwendet wird, hängt davon ab, ob Ihre C#-Funktionen prozessintern oder in einem isolierten Arbeitsprozess ausgeführt werden.

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

Hinweis

Der vorherige Code ist für Durable Functions 2.x vorgesehen. Für Durable Functions 1.x müssen Sie DurableOrchestrationContext anstelle von IDurableOrchestrationContext verwenden. Weitere Informationen zu den Unterschieden zwischen den Versionen finden Sie im Artikel Durable Functions-Versionen.

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

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

Hinweis

Die durable-functions-Bibliothek übernimmt den Aufruf der synchronen context.done-Methode, wenn die Generatorfunktion beendet wird.

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

Die meisten Orchestratorfunktionen rufen Aktivitätsfunktionen auf. In diesem „Hello World“-Beispiel wird veranschaulicht, wie eine Aktivitätsfunktion aufgerufen wird:

[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;
}

Hinweis

Der vorherige Code ist für Durable Functions 2.x vorgesehen. Für Durable Functions 1.x müssen Sie DurableOrchestrationContext anstelle von IDurableOrchestrationContext verwenden. Weitere Informationen zu den Unterschieden zwischen den Versionen finden Sie im Artikel Durable Functions-Versionen.

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

Aktivitätstrigger

Mit dem Aktivitätstrigger können Sie Funktionen erstellen, die von Orchestratorfunktionen aufgerufen werden, die als Aktivitätsfunktionen bezeichnet werden.

Der Aktivitätstrigger wird mit dem .NET-Attribut ActvityTriggerAttribute konfiguriert.

Der Aktivitätstrigger wird mithilfe der Anmerkung @DurableActivityTrigger konfiguriert.

Ein Aktivitätstrigger wird durch das folgende JSON-Objekt im bindings-Array von function.json definiert:

{
    "name": "<Name of input parameter in function signature>",
    "activity": "<Optional - name of the activity>",
    "type": "activityTrigger",
    "direction": "in"
}
  • activity ist der Name der Aktivität. Dieser Wert ist der Name, der von Orchestratorfunktionen verwendet wird, um diese Aktivitätsfunktion aufzurufen. Diese Eigenschaft ist optional. Wenn sie nicht angegeben ist, wird der Name der Funktion verwendet.

Die Art und Weise, wie Sie einen Aktivitätstrigger definieren, hängt vom gewählten Programmiermodell ab.

Verwenden Sie den activity_trigger-Decorator direkt in Ihrem Python-Funktionscode.

Intern werden mit dieser Triggerbindung neue Aktivitätsausführungsereignisse vom konfigurierten permanenten Speicher abgefragt.

Triggerverhalten

Hier sind einige Hinweise zum Aktivitätstrigger aufgeführt:

  • Threading: Im Gegensatz zum Orchestrierungstrigger gelten für Aktivitätstrigger keine Einschränkungen in Bezug auf das Threading oder den E/A-Ablauf. Sie können wie reguläre Funktionen behandelt werden.
  • Behandlung von nicht verarbeitbaren Nachrichten: Aktivitätstrigger weisen keine Unterstützung für nicht verarbeitbare Nachrichten auf.
  • Sichtbarkeit von Nachrichten: Nachrichten des Aktivitätstriggers werden aus der Warteschlange entfernt und bleiben für eine konfigurierbare Dauer unsichtbar. Die Sichtbarkeit dieser Nachrichten wird automatisch erneuert, solange die Funktionen-App ausgeführt wird und fehlerfrei ist.
  • Rückgabewerte: Rückgabewerte werden in JSON-Code serialisiert und im konfigurierten Orchestrierungsverlauf beibehalten.

Triggerverwendung

Die Aktivitätstriggerbindung unterstützt sowohl Ein- als auch Ausgaben – genau wie der Orchestrierungstrigger. Hier sind einige Dinge aufgeführt, die Sie in Bezug auf die Eingabe- und Ausgabeverarbeitung wissen sollten:

  • Eingaben: Aktivitätstrigger können mit Eingaben aus einer Orchestratorfunktion aufgerufen werden. Alle Eingaben müssen JSON-serialisierbar sein.
  • Ausgaben: Aktivitätsfunktionen unterstützen sowohl Ausgabewerte als auch Eingaben. Der Rückgabewert der Funktion wird verwendet, um den Ausgabewert zuzuweisen, und er muss per JSON serialisierbar sein.
  • Metadaten: .NET-Aktivitätsfunktionen können an einen string instanceId-Parameter gebunden werden, um die Instanz-ID der aufrufenden Orchestrierung abzurufen.

Triggerbeispiel

Der folgende Beispielcode zeigt, wie eine sehr einfache Aktivitätsfunktion SayHello aussehen könnte.

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

Der Standardparametertyp für die .NET-Bindung ActivityTriggerAttribute ist IDurableActivityContext (oder DurableActivityContext für Durable Functions v1). .NET-Aktivitätstrigger unterstützen aber auch die direkte Bindung an JSON-serialisierbare Typen (z. B. primitive Typen). Die gleiche Funktion kann daher wie folgt vereinfacht werden:

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

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

JavaScript-Bindungen können auch als zusätzliche Parameter übergeben werden. Die gleiche Funktion kann daher wie folgt vereinfacht werden:

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

Verwenden von Eingabe- und Ausgabebindungen

Sie können neben der Aktivitätstriggerbindung auch reguläre Eingabe- und Ausgabebindungen verwenden.

Beispielsweise können Sie die Eingabe in die Aktivitätsbindung verwenden und eine Nachricht mithilfe der Event Hub-Ausgabebindung an Event Hubs senden:

{
  "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;
};

Orchestrierungsclient

Mit der Bindung des Orchestrierungsclients können Sie Funktionen schreiben, die mit Orchestratorfunktionen interagieren. Diese Funktionen werden oft als Client-Funktionen bezeichnet. Beispielsweise können Sie für Orchestrierungsinstanzen folgende Aktionen durchführen:

  • Starten
  • Abfragen des Status
  • Beenden
  • Senden von Ereignissen an die Instanzen während der Ausführung
  • Löschen des Instanzverlaufs

Sie können mithilfe des Attributs DurableClientAttribute (OrchestrationClientAttribute in Durable Functions v1.x) eine Bindung an den Orchestrierungsclient herstellen.

Mithilfe der @DurableClientInput-Anmerkung können Sie eine Bindung an den Orchestrierungsclient herstellen.

Ein dauerhafter Clienttrigger wird durch das folgende JSON-Objekt im bindings-Array von function.json definiert:

{
    "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: Wird in Szenarien verwendet, in denen mehrere Funktionen-Apps dasselbe Speicherkonto nutzen, aber voneinander isoliert werden müssen. Wenn Sie hier nichts angeben, wird der Standardwert aus host.json verwendet. Dieser Wert muss mit dem Wert übereinstimmen, der von den Zielorchestratorfunktionen verwendet wird.
  • connectionName: Der Name einer App-Einstellung, die eine Speicherkonto-Verbindungszeichenfolge enthält. Das Speicherkonto, für das diese Verbindungszeichenfolge steht, muss dem Speicherkonto entsprechen, das von den Zielorchestratorfunktionen verwendet wird. Wenn nichts angegeben ist, wird die Speicherkonto-Standardverbindungszeichenfolge für die Funktionen-App verwendet.

Hinweis

In den meisten Fällen ist es empfehlenswert, diese Eigenschaften wegzulassen und das Standardverhalten zu nutzen.

Die Art und Weise, wie Sie einen dauerhaften Clienttrigger definieren, hängt vom gewählten Programmiermodell ab.

Verwenden Sie den durable_client_input-Decorator direkt in Ihrem Python-Funktionscode.

Clientnutzung

Sie richten normalerweise eine Bindung an IDurableClient (DurableOrchestrationClient in Durable Functions v1.x) ein, sodass Sie Vollzugriff auf alle Orchestrierungsclient-APIs erhalten, die von Durable Functions unterstützt werden.

Die Bindung wird in der Regel mit der DurableClientContext-Klasse hergestellt.

Sie müssen das sprachspezifische SDK verwenden, um Zugriff auf ein Clientobjekt zu erhalten.

Hier ist ein Beispiel für eine per Warteschlange ausgelöste Funktion angegeben, mit der eine „HelloWorld“-Orchestrierung gestartet wird.

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

Hinweis

Der vorherige C#-Code ist für Durable Functions 2.x vorgesehen. Für Durable Functions 1.x müssen Sie das OrchestrationClient-Attribut anstelle des DurableClient-Attributs verwenden, und Sie müssen den DurableOrchestrationClient-Parametertyp anstelle von IDurableOrchestrationClient verwenden. Weitere Informationen zu den Unterschieden zwischen den Versionen finden Sie im Artikel Durable Functions-Versionen.

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

Weitere Informationen zum Starten von Instanzen finden Sie unter Instanzverwaltung.

Entitätstrigger

Entitätstrigger ermöglichen es Ihnen, Entitätsfunktionen zu erstellen. Dieser Trigger unterstützt die Verarbeitung von Ereignissen für eine bestimmte Entitätsinstanz.

Hinweis

Entitätstrigger sind ab Durable Functions 2.x verfügbar.

Intern werden mit dieser Triggerbindung neue Entitätsvorgänge, die ausgeführt werden müssen, vom konfigurierten permanenten Speicher abgefragt.

Der Entitätstrigger wird mit dem .NET-Attribut EntityTriggerAttribute konfiguriert.

Der Entitätstrigger wird durch das folgende JSON-Objekt im bindings-Array von function.json definiert:

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

Standardmäßig ist der Name einer Entität der Name der Funktion.

Hinweis

Entitätstrigger werden für Java noch nicht unterstützt.

Die Art und Weise, wie Sie einen Entitätstrigger definieren, hängt vom gewählten Programmiermodell ab.

Verwenden Sie den entity_trigger-Decorator direkt in Ihrem Python-Funktionscode.

Triggerverhalten

Hier sind einige Hinweise zum Entitätstrigger aufgeführt:

  • Singlethread: Ein einzelner Verteilerthread wird zum Verarbeiten von Vorgängen für eine bestimmte Entität verwendet. Wenn mehrere Nachrichten gleichzeitig an eine einzelne Entität gesendet werden, werden die Vorgänge einzeln verarbeitet.
  • Behandlung von nicht verarbeitbaren Nachrichten: Entitätstrigger weisen keine Unterstützung für nicht verarbeitbare Nachrichten auf.
  • Sichtbarkeit von Nachrichten: Nachrichten des Entitätstriggers werden aus der Warteschlange entfernt und bleiben für eine konfigurierbare Dauer unsichtbar. Die Sichtbarkeit dieser Nachrichten wird automatisch erneuert, solange die Funktionen-App ausgeführt wird und fehlerfrei ist.
  • Rückgabewerte: Entitätsfunktionen unterstützen keine Rückgabewerte. Es gibt bestimmte APIs, die zum Speichern des Zustands oder zum Zurückgeben von Werten an Orchestrierungen verwendet werden können.

Alle Zustandsänderungen, die während der Ausführung an einer Entität vorgenommen werden, werden nach Abschluss der Ausführung automatisch persistent gespeichert.

Weitere Informationen und Beispiele zum Definieren und Interagieren mit Entitätstriggern finden Sie in der Dokumentation zu dauerhaften Entitäten.

Entitätsclient

Die Entitätsclientbindung ermöglicht es Ihnen, Entitätsfunktionen asynchron auszulösen. Diese Funktionen werden manchmal auch als Clientfunktionenbezeichnet.

Sie können eine Bindung mit dem Client der Entität herstellen, indem Sie das .NET-Attribut DurableClientAttribute in .NET-Klassenbibliotheksfunktionen verwenden.

Hinweis

[DurableClientAttribute] kann auch verwendet werden, um eine Bindung mit dem Orchestrierungsclient herzustellen.

Der Entitätsclient wird durch das folgende JSON-Objekt im bindings-Array von function.json definiert:

{
    "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: Wird in Szenarien verwendet, in denen mehrere Funktionen-Apps dasselbe Speicherkonto nutzen, aber voneinander isoliert werden müssen. Wenn Sie hier nichts angeben, wird der Standardwert aus host.json verwendet. Dieser Wert muss mit dem Wert übereinstimmen, der von den Zielentitätsfunktionen verwendet wird.
  • connectionName: Der Name einer App-Einstellung, die eine Speicherkonto-Verbindungszeichenfolge enthält. Das Speicherkonto, für das diese Verbindungszeichenfolge steht, muss dem Speicherkonto entsprechen, das von den Zielentitätsfunktionen verwendet wird. Wenn nichts angegeben ist, wird die Speicherkonto-Standardverbindungszeichenfolge für die Funktionen-App verwendet.

Hinweis

In den meisten Fällen ist es empfehlenswert, die optionalen Eigenschaften nicht zu verwenden und das Standardverhalten zu nutzen.

Die Art und Weise, wie Sie einen Entitätsclient definieren, hängt vom gewählten Programmiermodell ab.

Verwenden Sie den durable_client_input-Decorator direkt in Ihrem Python-Funktionscode.

Hinweis

Entitätsclients werden für Java noch nicht unterstützt.

Weitere Informationen und Beispiele zur Interaktion mit Entitäten als Client finden Sie in der Dokumentation zu Dauerhaften Entitäten.

Einstellungen für „host.json“

Konfigurationseinstellungen für Durable Functions.

Hinweis

Alle Hauptversionen von Durable Functions werden für alle Versionen der Azure Functions-Runtime unterstützt. Das Schema der host.json-Konfiguration unterscheidet sich jedoch abhängig geringfügig, abhängig von der verwendeten Version der Azure Functions-Runtime und Durable Functions-Erweiterung. Die folgenden Beispiele sind für die Verwendung mit Azure Functions 2.0 und 3.0 vorgesehen. Wenn Sie Azure Functions 1.0 verwenden, sind in beiden Beispielen die verfügbaren Einstellungen gleich. Der Abschnitt „durableTask“ von „host.json“ muss jedoch in den Stamm der host.json-Konfiguration und nicht als Feld unterhalb von „extensions“ eingefügt werden.

{
 "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
  }
 }
}

Aufgabenhubnamen müssen mit einem Buchstaben beginnen und bestehen nur aus Buchstaben und Ziffern. Wenn nicht angegeben, lautet der standardmäßige Aufgabenhubname für eine Funktions-App TestHubName. Weitere Informationen finden Sie unter Aufgabenhubs in Durable Functions (Azure Functions).

Eigenschaft Standard BESCHREIBUNG
hubName TestHubName (DurableFunctionsHub unter Verwendung von Durable Functions 1.x) Alternative Namen für Aufgabenhubs können zum Isolieren von mehreren Durable Functions-Anwendungen verwendet werden, auch wenn sie dasselbe Speicher-Back-End verwenden.
controlQueueBatchSize 32 Die Anzahl der aus der Steuerelement-Warteschlange jeweils abzurufenden Nachrichten.
controlQueueBufferThreshold Verbrauchstarif für Python: 32
Verbrauchstarif für JavaScript und C#: 128
Dedicated-/Premium-Plan: 256		 Die Anzahl der Steuerelement-Warteschlangen Nachrichten, die gleichzeitig im Arbeitsspeicher gepuffert werden können. Zu diesem Zeitpunkt wartet der Verteiler, bevor zusätzliche Nachrichten aus der Warteschlange entfernt werden.
partitionCount 4 Die Anzahl der Partitionen für die Steuerelement-Warteschlange. Kann ein positiver Integerwert zwischen 1 und 16 sein.
controlQueueVisibilityTimeout 5 Minuten Das Sichtbarkeitstimeout von aus der Steuerelement-Warteschlange entfernten Nachrichten.
workItemQueueVisibilityTimeout 5 Minuten Das Sichtbarkeitstimeout von aus der Warteschlange für Arbeitselemente entfernten Nachrichten.
maxConcurrentActivityFunctions Verbrauchsplan: 10
Dedicated-/Premium-Plan: 10-fache Anzahl von Prozessoren auf dem aktuellen Computer		 Die maximale Anzahl von Aktivitätsfunktionen, die gleichzeitig auf einer einzelnen Hostinstanz verarbeitet werden können.
maxConcurrentOrchestratorFunctions Verbrauchsplan: 5
Dedicated-/Premium-Plan: 10-fache Anzahl von Prozessoren auf dem aktuellen Computer		 Die maximale Anzahl von Orchestratorfunktionen, die gleichzeitig auf einer einzelnen Hostinstanz verarbeitet werden können.
maxQueuePollingInterval 30 Sekunden Das maximale Abrufintervall der Steuerelement- und Arbeitselement-Warteschlangen im Format hh:mm:ss. Höhere Werte können zu höherer Latenz bei der Nachrichtenverarbeitung führen. Niedrigere Werte können aufgrund verstärkter Speichertransaktionen zu höheren Speicherkosten führen.
connectionName (2.7.0 und höher)
connectionStringName (2.x)
azureStorageConnectionStringName (1.x)		 AzureWebJobsStorage Der Name einer App-Einstellung oder -Einstellungssammlung, die angibt, wie eine Verbindung mit den zugrunde liegenden Azure Storage-Ressourcen hergestellt werden soll. Wenn eine einzelne App-Einstellung bereitgestellt wird, sollte es sich um eine Azure Speicherverbindungszeichenfolge handeln.
trackingStoreConnectionName (2.7.0 und höher)
trackingStoreConnectionStringName		 Der Name einer App-Einstellung oder Einstellungssammlung, die angibt, wie eine Verbindung mit den Verlaufs-und Instanztabellen hergestellt wird. Wenn eine einzelne App-Einstellung bereitgestellt wird, sollte es sich um eine Azure Speicherverbindungszeichenfolge handeln. Wird kein Wert angegeben, wird die Verbindung connectionStringName (Durable 2.x) oder azureStorageConnectionStringName (Durable 1.x) verwendet.
trackingStoreNamePrefix Das für die Verlaufs- und Instanzentabellen zu verwendende Präfix, wenn trackingStoreConnectionStringName angegeben ist. Wenn diese Eigenschaft nicht festgelegt ist, wird DurableTask als Standardwert für das Präfix verwendet. Wenn trackingStoreConnectionStringName nicht angegeben ist, wird in den Verlaufs- und Instanzentabellen der Wert hubName als Präfix verwendet und jede Einstellung für trackingStoreNamePrefix wird ignoriert.
traceInputsAndOutputs false Ein Wert, der angibt, ob die Eingaben und Ausgaben von Funktionsaufrufen nachverfolgt werden. Das Standardverhalten beim Nachverfolgen von Ereignissen zur Funktionsausführung besteht darin, die Anzahl der Bytes in die serialisierten Eingaben und Ausgaben für Funktionsaufrufe einzuschließen. Dieses Verhalten ermöglicht minimale Informationen zu den Eingaben und Ausgaben, ohne die Protokolle zu überfrachten oder irrtümlich vertrauliche Informationen verfügbar zu machen. Wenn diese Eigenschaft auf TRUE festgelegt wird, werden bei der standardmäßigen Funktionsprotokollierung die gesamten Inhalte der Eingaben und Ausgaben der Funktionen protokolliert.
traceReplayEvents false Ein Wert, der angibt, ob Orchestrierungswiedergabeereignisse in Application Insights geschrieben werden.
eventGridTopicEndpoint Die URL eines benutzerdefinierten Azure Event Grid-Themenendpunkts. Wenn diese Eigenschaft festgelegt ist, werden Benachrichtigungsereignisse zum Orchestrierungslebenszyklus an diesem Endpunkt veröffentlicht. Diese Eigenschaft unterstützt die Auflösung von App-Einstellungen.
eventGridKeySettingName Der Name der App-Einstellung, die den Schlüssel für die Authentifizierung mit dem benutzerdefinierten Azure Event Grid-Thema unter EventGridTopicEndpoint enthält.
eventGridPublishRetryCount 0 Die Anzahl der Wiederholungsversuche, wenn bei der Veröffentlichung im Event Grid-Thema Fehler auftreten.
eventGridPublishRetryInterval 5 Minuten Das Wiederholungsintervall der Event Grid-Veröffentlichung im Format hh:mm:ss.
eventGridPublishEventTypes Eine Liste von Ereignistypen, die in Event Grid veröffentlicht werden sollen. Wenn diese Eigenschaft nicht angegeben ist, werden alle Ereignistypen veröffentlicht. Zulässige Werte sind Started, Completed, Failed und Terminated.
useAppLease true Wird diese Einstellung auf true festgelegt, müssen Apps vor der Verarbeitung von Aufgabenhubnachrichten eine Bloblease auf App-Ebene abrufen. Weitere Informationen finden Sie in der Dokumentation zur Notfallwiederherstellung und geografischen Verteilung. Verfügbar ab v2.3.0
useLegacyPartitionManagement false Wenn diese Einstellung auf false festgelegt wird, wird ein Partitionsverwaltungsalgorithmus verwendet, der bei der horizontalen Skalierung die Wahrscheinlichkeit einer doppelten Funktionsausführung reduziert. Diese Funktion ist ab Version 2.3.0 verfügbar.
useTablePartitionManagement false Verwendet bei Festlegung auf true einen Partitionsverwaltungsalgorithmus, der zum Senken von Kosten für Azure Storage V2-Konten entwickelt wurde. Verfügbar ab v2.10.0. Dieses Feature befindet sich derzeit in der Vorschauphase und ist noch nicht mit dem Verbrauchsplan kompatibel.
useGracefulShutdown false (Preview) Ordnungsgemäßes Herunterfahren aktivieren, um die Wahrscheinlichkeit zu verringern, dass beim Herunterfahren von Hosts Funktionsausführungen in Prozessen fehlschlagen.
maxEntityOperationBatchSize(2.6.1) Verbrauchsplan: 50
Dedicated-/Premium-Plan:: 5000		 Die maximale Anzahl von Entitätsvorgängen, die als Batch verarbeitet werden. Wird der Wert auf „1“ festgelegt, ist die Batchverarbeitung deaktiviert, und jede Vorgangsmeldung wird von einem separaten Funktionsaufruf verarbeitet.
storeInputsInOrchestrationHistory false Wenn dieser Wert auf true festgelegt ist, wird das Durable Task Framework aufgefordert, Aktivitätseingaben in der Verlaufstabelle zu speichern. Dies ermöglicht die Anzeige von Aktivitätsfunktionseingaben beim Abfragen des Orchestrierungsverlaufs.

Viele dieser Einstellungen werden zur Optimierung der Leistung verwendet. Weitere Informationen finden Sie unter Leistung und Skalierbarkeit.

Nächste Schritte

Integrierte in HTTP API-Referenz für Instanzverwaltung