Freigeben über

Bindungen für dauerhafte Funktionen (Azure-Funktionen)

Die Erweiterung "Durable Functions " führt drei Triggerbindungen ein, die die Ausführung von Orchestrator-, Entitäts- und Aktivitätsfunktionen steuern. Außerdem wird eine Ausgabebindung eingeführt, die als Client für die Durable Functions-Laufzeit fungiert.

Stellen Sie sicher, dass Sie ihre Entwicklungssprache für dauerhafte Funktionen oben im Artikel auswählen.

Von Bedeutung

Dieser Artikel unterstützt sowohl Python v1- als auch Python v2-Programmiermodelle für dauerhafte Funktionen.

Python v2-Programmiermodell

Dauerhafte Funktionen werden im neuen Python v2-Programmiermodell unterstützt. Um das v2-Modell zu verwenden, müssen Sie das Durable Functions SDK installieren, bei dem es sich um das PyPI-Paket azure-functions-durable, die 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 Durable Functions SDK für Python-Repository bereitstellen.

Orchestrierungstrigger

Mit dem Orchestrierungstrigger können Sie dauerhafte Orchestratorfunktionen erstellen. Dieser Trigger wird ausgeführt, wenn eine neue Orchestrierungsinstanz geplant wird 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 mithilfe des OrchestrationTriggerAttribute .NET-Attributs konfiguriert.

Für Java wird die @DurableOrchestrationTrigger Anmerkung verwendet, um den Orchestrierungstrigger zu konfigurieren.

Wenn Sie Orchestratorfunktionen schreiben, wird der Orchestrierungstrigger durch das folgende JSON-Objekt im bindings Array der function.json Datei 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, die Clients verwenden müssen, wenn sie neue Instanzen dieser Orchestratorfunktion starten möchten. Diese Eigenschaft ist optional. Wenn nicht angegeben, 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 mithilfe des orchestration_trigger Dekorators 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 Notizen zum Orchestrierungsauslöser:

  • Single-Threading – Ein einzelner Dispatcherthread wird für die Ausführung aller Orchestratorfunktionen in einer einzigen Hostinstanz verwendet. Aus diesem Grund ist es wichtig, sicherzustellen, dass der Orchestrator-Funktionscode effizient ist und keine Eingabe/Ausgabe durchführt. Es ist auch wichtig, sicherzustellen, dass dieser Thread keine asynchrone Arbeit abnimmt, außer wenn auf dauerhafte Funktionen spezifische Aufgabentypen gewartet wird.
  • 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 verlängert, solange die Funktions-App ausgeführt und fehlerfrei ist.
  • Rückgabewerte – Rückgabewerte werden in JSON serialisiert und in der Orchestrierungsverlaufstabelle im Azure-Tabellenspeicher beibehalten. Diese Rückgabewerte können von der Orchestrierungsclientbindung abgefragt werden, die später beschrieben wird.

Warnung

Orchestratorfunktionen sollten niemals andere Eingabe- oder Ausgabebindungen als die Orchestrierungstriggerbindung verwenden. 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 sie zu einer Aktivitätsfunktion hinzu, die von Ihrer Orchestratorfunktion aufgerufen wird. Weitere Informationen zum Codieren von Einschränkungen für Orchestratorfunktionen finden Sie in der Dokumentation zu Orchestrator-Funktionscodeeinschränkungen .

Warnung

Orchestrator-Funktionen sollten niemals deklariert asyncwerden.

Triggerverwendung

Die Orchestrierungstriggerbindung unterstützt sowohl Ein- als auch Ausgaben. Hier sind einige Informationen zur Eingabe- und Ausgabebehandlung:

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

Triggerbeispiel

Der folgende Beispielcode zeigt, wie die einfachste "Hello World"-Orchestratorfunktion aussehen könnte. In diesem Beispiel orchestrator werden keine Vorgänge geplant.

Das spezifische Attribut, das zum Definieren des Triggers verwendet wird, hängt davon ab, ob Sie Ihre C# -Funktionen im Prozess oder in einem isolierten Arbeitsprozess ausführen.

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

Hinweis

Der vorherige Code gilt für dauerhafte Funktionen 2.x. 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 Versions".

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 das Aufrufen 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. Hier ist also ein Beispiel für "Hello World", das 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 gilt für dauerhafte Funktionen 2.x. 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ätsauslöser

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

Der Aktivitätstrigger wird mithilfe des ActivityTriggerAttribute .NET-Attributs konfiguriert.

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

Der Aktivitätsauslöser wird durch das folgende JSON-Objekt im bindings Array von function.jsondefiniert:

{
    "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, den Orchestratorfunktionen zum Aufrufen dieser Aktivitätsfunktion verwenden. Diese Eigenschaft ist optional. Wenn nicht angegeben, wird der Name der Funktion verwendet.

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

Verwenden sie den activity_trigger Dekorierer 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ätsauslöser:

  • Threading – Im Gegensatz zum Orchestrierungstrigger haben Aktivitätstrigger keine Einschränkungen hinsichtlich Threading oder E/A. Sie können wie normale Funktionen behandelt werden.
  • Umgang mit Giftnachrichten – Es gibt keine Unterstützung für Giftnachrichten in Aktivitätsauslösern.
  • 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 verlängert, solange die Funktions-App ausgeführt und fehlerfrei ist.
  • Rückgabewerte – Rückgabewerte werden in JSON serialisiert und im konfigurierten dauerhaften Speicher beibehalten.

Triggerverwendung

Die Aktivitätstriggerbindung unterstützt sowohl Eingaben als auch Ausgaben, genau wie der Orchestrierungstrigger. Hier sind einige Informationen zur Eingabe- und Ausgabebehandlung:

  • Eingaben – Aktivitätstrigger können mit Eingaben aus einer Orchestratorfunktion aufgerufen werden. Alle Eingaben müssen JSON-serialisierbar sein.
  • Outputs – Aktivitätsfunktionen unterstützen sowohl Ausgabe- als auch Eingabewerte. Der Rückgabewert der Funktion wird verwendet, um den Ausgabewert zuzuweisen, und muss 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 einfache SayHello Aktivitätsfunktion aussehen kann.

[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 dauerhafte Funktionen v1). .NET-Aktivitätsauslöser unterstützen jedoch auch die direkte Bindung an JSON-serialisierbare Typen (einschließlich primitiver Typen), sodass die gleiche Funktion wie folgt vereinfacht werden kann:

[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, sodass die gleiche Funktion wie folgt vereinfacht werden kann:

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.

Sie können z. B. die Eingabe an Ihre Aktivitätsbindung übernehmen und eine Nachricht mithilfe der Ausgabebindung "Event Hubs" an einen Event Hub 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 Orchestrierungsclientbindung können Sie Funktionen schreiben, die mit Orchestratorfunktionen interagieren. Diese Funktionen werden häufig als Clientfunktionen bezeichnet. Sie können beispielsweise auf Orchestrierungsinstanzen in den folgenden Weisen reagieren:

  • Starten
  • Fragen Sie ihren Status ab.
  • Eliminieren Sie sie.
  • Senden von Ereignissen an die Instanzen während der Ausführung
  • Löschen des Instanzverlaufs

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

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

Der dauerhafte Clienttrigger wird durch das folgende JSON-Objekt im bindings Array von function.jsondefiniert:

{
    "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 Funktions-Apps dasselbe Speicherkonto gemeinsam nutzen, aber voneinander isoliert werden müssen. Wenn nicht angegeben, wird der Standardwert host.json verwendet. Dieser Wert muss mit dem Wert übereinstimmen, der von den Ziel-Orchestratorfunktionen verwendet wird.
  • connectionName – Der Name einer App-Einstellung, die eine Verbindungszeichenfolge für Speicherkonten enthält. Das in dieser Verbindungszeichenfolge angegebene Speicherkonto muss dasselbe sein, das von den Ziel-Orchestratorfunktionen verwendet wird. Wenn nichts angegeben ist, wird die Speicherkonto-Standardverbindungszeichenfolge für die Funktionen-App verwendet.

Hinweis

In den meisten Fällen wird empfohlen, diese Eigenschaften wegzulassen und das Standardverhalten zu verwenden.

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

Verwenden sie den durable_client_input Dekorierer direkt in Ihrem Python-Funktionscode.

Kundennutzung

In der Regel binden Sie an IDurableClient (DurableOrchestrationClient in Durable Functions v1.x), wodurch Sie vollständigen Zugriff auf alle Von Durable Functions unterstützten Orchestrierungsclient-APIs erhalten.

Sie binden in der Regel an die DurableClientContext Klasse.

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 gilt für dauerhafte Funktionen 2.x. 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 Versions".

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 Details zum Starten von Instanzen finden Sie in der 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 mithilfe des EntityTriggerAttribute .NET-Attributs konfiguriert.

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

{
    "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 Dekorierer direkt in Ihrem Python-Funktionscode.

Triggerverhalten

Hier sind einige Hinweise zum Entitätsauslöser:

  • Single-Threaded: Ein einzelner Dispatcherthread wird verwendet, um Vorgänge für eine bestimmte Entität zu verarbeiten. Wenn mehrere Nachrichten gleichzeitig an eine einzelne Entität gesendet werden, werden die Vorgänge einzeln verarbeitet.
  • Behandlung von Giftnachrichten – Es gibt keine Unterstützung für Giftnachrichten in Entitätstriggern.
  • 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 verlängert, solange die Funktions-App ausgeführt und fehlerfrei ist.
  • Rückgabewerte – Entitätsfunktionen unterstützen keine Rückgabewerte. Es gibt bestimmte APIs, die verwendet werden können, um Status zu speichern oder Werte zurück an Orchestrierungen zu übergeben.

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

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

Entitäts-Client

Mit der Entitätsclientbindung können Sie Entitätsfunktionen asynchron auslösen. Diese Funktionen werden manchmal als Clientfunktionen bezeichnet.

Sie können eine Bindung an den Entitätsclient mithilfe des DurableClientAttribute .NET-Attributs in .NET-Klassenbibliotheksfunktionen herstellen.

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.jsondefiniert:

{
    "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 Funktions-Apps dasselbe Speicherkonto gemeinsam nutzen, aber voneinander isoliert werden müssen. Wenn nicht angegeben, wird der Standardwert 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 Verbindungszeichenfolge für Speicherkonten enthält. Das Speicherkonto, das durch diese Verbindungszeichenfolge repräsentiert wird, muss dasselbe sein, 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 wird empfohlen, die optionalen Eigenschaften wegzulassen und das Standardverhalten zu verwenden.

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

Verwenden sie den durable_client_input Dekorierer direkt in Ihrem Python-Funktionscode.

Hinweis

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

Weitere Informationen und Beispiele für die 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 geringfügig, abhängig von der verwendeten Version der Azure Functions-Runtime sowie der Durable Functions-Erweiterung. Die folgenden Beispiele sind für die Verwendung mit Azure Functions 2.0 und 3.0 vorgesehen. In beiden Beispielen, wenn Sie Azure Functions 1.0 verwenden, sind die verfügbaren Einstellungen identisch, der Abschnitt "durableTask" des host.json sollte jedoch im Stammverzeichnis der host.json-Konfiguration anstelle eines Felds unter "Erweiterungen" stehen.

{
 "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": false,
      "useTablePartitionManagement": true,
      "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,
    "maxConcurrentEntityFunctions": 10,
    "extendedSessionsEnabled": false,
    "extendedSessionIdleTimeoutInSeconds": 30,
    "useAppLease": true,
    "useGracefulShutdown": false,
    "maxEntityOperationBatchSize": 50,
    "maxOrchestrationActions": 100000,
    "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 Task Hubs.

Eigentum 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
Verbrauchsplan für andere Sprachen: 128
Dedicated-/Premium-Plan: 256		 Die Anzahl der Steuerelement-Warteschlangennachrichten, die gleichzeitig im Arbeitsspeicher gepuffert werden können. Zu diesem Zeitpunkt wartet der Verteiler, bevor zusätzliche Nachrichten aus der Warteschlange entfernt werden. In einigen Fällen kann die Verringerung dieses Werts die Arbeitsspeicherauslastung erheblich reduzieren.
partitionCount 4 Die Anzahl der Partitionen für die Steuerelement-Warteschlange. Kann ein positiver Integerwert zwischen 1 und 16 sein. Zum Ändern dieses Werts muss ein neuer Aufgabenhub konfiguriert werden.
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.
maxConcurrentEntityFunctions Verbrauchsplan: 5
Dedicated-/Premium-Plan: 10-fache Anzahl von Prozessoren auf dem aktuellen Computer		 Die maximale Anzahl von Entitätsfunktionen, die gleichzeitig in einer einzelnen Hostinstanz verarbeitet werden können. Diese Einstellung gilt nur bei Verwendung des dauerhaften Aufgabenplaners. Ansonsten ist die maximale Anzahl an gleichzeitigen Entitätsausführungen auf maxConcurrentOrchestratorFunctions beschränkt.
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, verwenden die Tabellen "Verlauf" und "Instanzen" den hubName Wert als Präfix, und alle Einstellungen für trackingStoreNamePrefix werden ignoriert.
traceInputsAndOutputs Falsch 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 Falsch Ein Wert, der angibt, ob Orchestrationswiedergabeereignisse 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 Event Grid veröffentlicht das Wiederholungsintervall 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 Wahr 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
VerwendenSieLegacyPartitionManagement Falsch 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. Das Festlegen dieses Werts auf true wird nicht empfohlen.
useTablePartitionManagement true in v3.x-Erweiterungsversionen
false in v2.x-Erweiterungsversionen		 Verwendet bei Festlegung auf true einen Partitionsverwaltungsalgorithmus, der zum Senken von Kosten für Azure Storage V2-Konten entwickelt wurde. Verfügbar ab WebJobs.Extensions.DurableTask v2.10.0. Die Verwendung dieser Einstellung mit verwalteter Identität erfordert WebJobs.Extensions.DurableTask v3.x oder höher oder Worker.Extensions.DurableTask-Versionen vor v1.2.x oder höher.
useGracefulShutdown Falsch (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- oder 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.
Eingaben in der Orchestrierungshistorie speichern Falsch 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.
maxGrpcMessageSizeInBytes 4194304 Ein ganzzahliger Wert, der die maximale Größe in Bytes von Nachrichten festlegt, die der gRPC-Client für DurableTaskClient empfangen kann. Dies gilt für dauerhafte Funktionen .NET Isolated und Java.
grpcHttpClientTimeout 100 Sekunden Legt das Timeout für den HTTP-Client fest, der vom gRPC-Client in durable Functions verwendet wird, der derzeit für .NET isolierte Apps (.NET 6 und höhere Versionen) und für Java unterstützt wird.

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

Nächste Schritte

Integrierte HTTP-API-Referenz für die Instanzverwaltung