Skip to content
Permalink
Branch: master
Find file Copy path
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
590 lines (446 sloc) 30.5 KB
title description services documentationcenter author manager keywords ms.service ms.devlang ms.topic ms.date ms.author ms.custom ms.openlocfilehash ms.sourcegitcommit ms.translationtype ms.contentlocale ms.lasthandoff ms.locfileid
Azure Queue Storage-Bindungen für Azure Functions
Hier erfahren Sie, wie Sie den Azure Queue Storage-Trigger und die entsprechende Ausgabebindung in Azure Functions verwenden.
functions
na
craigshoemaker
gwallace
Azure Functions, Funktionen, Ereignisverarbeitung, dynamisches Compute, serverlose Architektur
azure-functions
multiple
reference
09/03/2018
cshoe
cc996988-fb4f-47
9604ef276625d1fcc9164a9b75b94ebc22cb51e1
9b80d1e560b02f74d2237489fa1c6eb7eca5ee10
HT
de-DE
07/01/2019
67480143

Azure Queue Storage-Bindungen für Azure Functions

In diesem Artikel erfahren Sie, wie Sie Azure Queue Storage-Bindungen in Azure Functions verwenden. Azure Functions unterstützt Trigger- und Ausgabebindungen für Warteschlangen.

[!INCLUDE intro]

Pakete: Functions 1.x

Die Warteschlangenspeicher-Bindungen werden im NuGet-Paket Microsoft.Azure.WebJobs, Version 2.x bereitgestellt. Den Quellcode für das Paket finden Sie im GitHub-Repository azure-webjobs-sdk.

[!INCLUDE functions-package-auto]

[!INCLUDE functions-storage-sdk-version]

Pakete: Functions 2.x

Die Warteschlangenspeicher-Bindungen werden im NuGet-Paket Microsoft.Azure.WebJobs.Extensions.Storage, Version 3.x bereitgestellt. Den Quellcode für das Paket finden Sie im GitHub-Repository azure-webjobs-sdk.

[!INCLUDE functions-package-v2]

Codieren

Funktionen erwarten eine Base64-codierte Zeichenfolge. Alle Anpassungen am Codierungstyp (um Daten als Base64-codierte Zeichenfolge vorzubereiten) müssen im aufrufenden Dienst implementiert werden.

Trigger

Verwenden Sie den Warteschlangentrigger, um eine Funktion zu starten, wenn bei einer Warteschlange ein neues Element eingeht. Die Warteschlangennachricht wird als Eingabe für die Funktion bereitgestellt.

Trigger: Beispiel

Sehen Sie sich das sprachspezifische Beispiel an:

Trigger: C#-Beispiel

Die C#-Funktion des folgenden Beispiels fragt die Warteschlange myqueue-items ab und schreibt ein Protokoll, sobald ein neues Warteschlangenelement verarbeitet wird.

public static class QueueFunctions
{
    [FunctionName("QueueTrigger")]
    public static void QueueTrigger(
        [QueueTrigger("myqueue-items")] string myQueueItem, 
        ILogger log)
    {
        log.LogInformation($"C# function processed: {myQueueItem}");
    }
}

Trigger: C#-Skriptbeispiel

Das folgende Beispiel enthält eine Warteschlangentrigger-Bindung in einer Datei vom Typ function.json sowie Code vom Typ C#-Skript (.csx), in dem die Bindung verwendet wird. Die Funktion fragt die Warteschlange myqueue-items ab und schreibt ein Protokoll, sobald ein Warteschlangenelement verarbeitet wird.

Die Datei function.json sieht wie folgt aus:

{
    "disabled": false,
    "bindings": [
        {
            "type": "queueTrigger",
            "direction": "in",
            "name": "myQueueItem",
            "queueName": "myqueue-items",
            "connection":"MyStorageConnectionAppSetting"
        }
    ]
}

Weitere Informationen zu diesen Eigenschaften finden Sie im Abschnitt Konfiguration.

Der C#-Skriptcode sieht wie folgt aus:

#r "Microsoft.WindowsAzure.Storage"

using Microsoft.Extensions.Logging;
using Microsoft.WindowsAzure.Storage.Queue;
using System;

public static void Run(CloudQueueMessage myQueueItem, 
    DateTimeOffset expirationTime, 
    DateTimeOffset insertionTime, 
    DateTimeOffset nextVisibleTime,
    string queueTrigger,
    string id,
    string popReceipt,
    int dequeueCount,
    ILogger log)
{
    log.LogInformation($"C# Queue trigger function processed: {myQueueItem.AsString}\n" +
        $"queueTrigger={queueTrigger}\n" +
        $"expirationTime={expirationTime}\n" +
        $"insertionTime={insertionTime}\n" +
        $"nextVisibleTime={nextVisibleTime}\n" +
        $"id={id}\n" +
        $"popReceipt={popReceipt}\n" + 
        $"dequeueCount={dequeueCount}");
}

Im Abschnitt Verwendung finden Sie weitere Informationen zu myQueueItem (benannt durch die Eigenschaft name in „function.json“). Alle anderen gezeigten Variablen werden im Abschnitt Nachrichtenmetadaten erläutert.

Trigger: JavaScript-Beispiel

Das folgende Beispiel enthält eine Warteschlangentrigger-Bindung in einer Datei function.json sowie eine JavaScript-Funktion, die die Bindung verwendet. Die Funktion fragt die Warteschlange myqueue-items ab und schreibt ein Protokoll, sobald ein Warteschlangenelement verarbeitet wird.

Die Datei function.json sieht wie folgt aus:

{
    "disabled": false,
    "bindings": [
        {
            "type": "queueTrigger",
            "direction": "in",
            "name": "myQueueItem",
            "queueName": "myqueue-items",
            "connection":"MyStorageConnectionAppSetting"
        }
    ]
}

Weitere Informationen zu diesen Eigenschaften finden Sie im Abschnitt Konfiguration.

[!NOTE] Der Namensparameter wird als context.bindings.<name> im JavaScript-Code wiedergegeben, der die Nutzlast des Warteschlangenelements enthält. Diese Nutzlast wird der Funktion außerdem als zweiter Parameter übergeben.

Der JavaScript-Code sieht wie folgt aus:

module.exports = async function (context, message) {
    context.log('Node.js queue trigger function processed work item', message);
    // OR access using context.bindings.<name>
    // context.log('Node.js queue trigger function processed work item', context.bindings.myQueueItem);
    context.log('expirationTime =', context.bindingData.expirationTime);
    context.log('insertionTime =', context.bindingData.insertionTime);
    context.log('nextVisibleTime =', context.bindingData.nextVisibleTime);
    context.log('id =', context.bindingData.id);
    context.log('popReceipt =', context.bindingData.popReceipt);
    context.log('dequeueCount =', context.bindingData.dequeueCount);
    context.done();
};

Im Abschnitt Verwendung finden Sie weitere Informationen zu myQueueItem (benannt durch die Eigenschaft name in „function.json“). Alle anderen gezeigten Variablen werden im Abschnitt Nachrichtenmetadaten erläutert.

Trigger: Java-Beispiel

Das folgende Java-Beispiel zeigt eine Funktion für einen Storage-Warteschlangentrigger, mit der die ausgelöste Nachricht, die in Warteschlange myqueuename abgelegt ist, protokolliert wird.

@FunctionName("queueprocessor")
public void run(
   @QueueTrigger(name = "msg",
                  queueName = "myqueuename",
                  connection = "myconnvarname") String message,
    final ExecutionContext context
) {
    context.getLogger().info(message);
}

Trigger: Attribute

Verwenden Sie in C#-Klassenbibliotheken die folgenden Attribute, um einen Warteschlangentrigger zu konfigurieren:

  • QueueTriggerAttribute

    Der Konstruktor des Attributs akzeptiert den Namen der zu überwachenden Warteschlange, wie im folgenden Beispiel zu sehen:

    [FunctionName("QueueTrigger")]
    public static void Run(
        [QueueTrigger("myqueue-items")] string myQueueItem, 
        ILogger log)
    {
        ...
    }

    Durch Festlegen der Eigenschaft Connection können Sie das zu verwendende Speicherkonto angeben, wie im folgenden Beispiel zu sehen:

    [FunctionName("QueueTrigger")]
    public static void Run(
        [QueueTrigger("myqueue-items", Connection = "StorageConnectionAppSetting")] string myQueueItem, 
        ILogger log)
    {
        ....
    }

    Ein vollständiges Beispiel finden Sie unter Trigger: C#-Beispiel.

  • StorageAccountAttribute

    Eine weitere Möglichkeit zum Angeben des zu verwendenden Speicherkontos. Der Konstruktor akzeptiert den Namen einer App-Einstellung mit einer Speicherverbindungszeichenfolge. Das Attribut kann auf Parameter-, Methoden- oder Klassenebene angewendet werden. Das folgende Beispiel zeigt die Anwendung auf Klassen- und Methodenebene:

    [StorageAccount("ClassLevelStorageAppSetting")]
    public static class AzureFunctions
    {
        [FunctionName("QueueTrigger")]
        [StorageAccount("FunctionLevelStorageAppSetting")]
        public static void Run( //...
    {
        ...
    }

Das zu verwendende Speicherkonto wird anhand von Folgendem bestimmt (in der angegebenen Reihenfolge):

  • Die Eigenschaft Connection des Attributs QueueTrigger.
  • Das Attribut StorageAccount, das auf den gleichen Parameter angewendet wird wie das Attribut QueueTrigger.
  • Das Attribut StorageAccount, das auf die Funktion angewendet wird.
  • Das Attribut StorageAccount, das auf die Klasse angewendet wird.
  • Die App-Einstellung „AzureWebJobsStorage“.

Trigger: Konfiguration

Die folgende Tabelle gibt Aufschluss über die Bindungskonfigurationseigenschaften, die Sie in der Datei function.json und im Attribut QueueTrigger festlegen:

Eigenschaft von „function.json“ Attributeigenschaft BESCHREIBUNG
type Muss auf queueTrigger festgelegt sein. Diese Eigenschaft wird automatisch festgelegt, wenn Sie den Trigger im Azure Portal erstellen.
direction Nur in der Datei function.json. Muss auf in festgelegt sein. Diese Eigenschaft wird automatisch festgelegt, wenn Sie den Trigger im Azure Portal erstellen.
name Der Name der Variablen, die die Nutzlast des Warteschlangenelements im Funktionscode enthält.
queueName QueueName Der Name der abzufragenden Warteschlange.
Verbindung Connection Der Name einer App-Einstellung, die die Storage-Verbindungszeichenfolge für diese Bindung enthält. Falls der Name der App-Einstellung mit „AzureWebJobs“ beginnt, können Sie hier nur den Rest des Namens angeben. Wenn Sie connection also beispielsweise auf „MyStorage“ festlegen, sucht die Functions-Laufzeit nach einer App-Einstellung namens „AzureWebJobsMyStorage“. Ohne Angabe für connection verwendet die Functions-Laufzeit die standardmäßige Storage-Verbindungszeichenfolge aus der App-Einstellung AzureWebJobsStorage.

[!INCLUDE app settings to local.settings.json]

Trigger: Verwendung

Verwenden Sie in C# und C#-Skripts einen Methodenparameter wie string paramName, um auf die Nachrichtendaten zuzugreifen. In C#-Skripts ist paramName der Wert, der in der Eigenschaft name von function.json angegeben ist. Eine Bindung kann mit folgenden Typen erstellt werden:

  • Objekt – Die Functions-Runtime deserialisiert eine JSON-Nutzlast in eine Instanz einer beliebigen Klasse, die in Ihrem Code definiert ist.
  • string
  • byte[]
  • CloudQueueMessage

Wenn Sie versuchen, eine Bindung an CloudQueueMessage herzustellen, und eine Fehlermeldung erhalten, stellen Sie sicher, dass ein Verweis auf die richtige Storage SDK-Version vorliegt.

Verwenden Sie in JavaScript context.bindings.<name>, um auf die Nutzlast des Warteschlangenelements zuzugreifen. Falls es sich um eine JSON-Nutzlast handelt, wird sie in ein Objekt deserialisiert.

Trigger: Nachrichtenmetadaten

Der Warteschlangentrigger stellt mehrere Metadateneigenschaften bereit. Diese Eigenschaften können als Teil der Bindungsausdrücke in anderen Bindungen oder als Parameter im Code verwendet werden. Im Folgenden werden Eigenschaften der CloudQueueMessage-Klasse aufgeführt:

Eigenschaft Typ BESCHREIBUNG
QueueTrigger string Die Warteschlangennutzlast (bei einer gültigen Zeichenfolge). Handelt es sich bei der Warteschlangennutzlast um eine Zeichenfolge, hat QueueTrigger den gleichen Wert wie die Variable, die durch die Eigenschaft name in function.json benannt wird.
DequeueCount int Gibt an, wie oft diese Nachricht aus der Warteschlange entfernt wurde.
ExpirationTime DateTimeOffset Die Zeit, zu der die Nachricht abläuft.
Id string ID der Warteschlangennachricht
InsertionTime DateTimeOffset Die Zeit, zu der die Nachricht der Warteschlange hinzugefügt wurde.
NextVisibleTime DateTimeOffset Die Zeit, zu der die Nachricht als Nächstes sichtbar wird.
PopReceipt string Die POP-Bestätigung der Nachricht.

Trigger: Nicht verarbeitbare Nachrichten

Falls eine Funktion des Warteschlangentriggers nicht erfolgreich ausgeführt werden kann, versucht Azure Functions für eine bestimmte Warteschlangennachricht bis zu fünf Mal (einschließlich des ersten Versuchs), die Funktion auszuführen. Sind alle fünf Versuche nicht erfolgreich, fügt die Functions-Laufzeit einer Warteschlange namens <Name der Originalwarteschlange>-poison eine Nachricht hinzu. Sie können eine Funktion schreiben, um Nachrichten aus der Warteschlange für nicht verarbeitete Nachrichten zu verarbeiten, indem Sie diese protokollieren oder eine Benachrichtigung senden, dass ein manueller Eingriff erforderlich ist.

Überprüfen Sie zur manuellen Behandlung nicht verarbeitbarer Nachrichten den Wert dequeueCount der Warteschlangennachricht.

Trigger: Abrufalgorithmus

Der Warteschlangentrigger implementiert einen zufälligen exponentiellen Backoffalgorithmus, um die Auswirkungen des Abfragens von Warteschlangen im Leerlauf auf Speichertransaktionskosten zu reduzieren. Wenn eine Nachricht gefunden wird, wartet die Runtime zwei Sekunden und prüft dann, ob eine andere Meldung vorhanden ist. Wenn keine Nachricht gefunden wird, wartet sie ungefähr vier Sekunden vor dem erneuten Versuch. Nach aufeinander folgenden fehlgeschlagenen Versuchen, eine Warteschlangennachricht abzurufen, erhöht sich die Wartezeit immer mehr, bis die maximale Wartezeit, standardmäßig eine Minute, erreicht ist. Die maximale Wartezeit kann über die maxPollingInterval-Eigenschaft in der Datei host.json konfiguriert werden.

Trigger: Parallelität

Wenn mehrere Warteschlangennachrichten warten, ruft der Warteschlangentrigger einen Batch mit Nachrichten ab und ruft parallel Funktionsinstanzen zur Verarbeitung auf. Standardmäßig ist die Batchgröße 16. Wenn die zu verarbeitende Anzahl 8 erreicht, ruft die Runtime einen weiteren Batch ab und beginnt mit der Verarbeitung dieser Nachrichten. Aus diesem Grund beträgt die maximale Anzahl der pro Funktion auf einem virtuellen Computer verarbeiteten parallelen Nachrichten 24. Dieser Grenzwert gilt separat für jede durch Warteschlangen ausgelöste Funktion auf jedem virtuellen Computer. Wenn die Funktions-App horizontal auf mehrere virtuelle Computer hochskaliert wird, wartet jeder virtuelle Computer auf Trigger und versucht, Funktionen auszuführen. Beispiel: Wenn eine Funktions-App auf drei virtuelle Computer horizontal hochskaliert wird, beträgt die standardmäßige maximale Anzahl von parallelen Instanzen einer durch Warteschlangen ausgelösten Funktion 72.

Die Batchgröße und der Schwellenwert für das Abrufen eines neuen Batches können in der Datei host.json konfiguriert werden. Sie können die Batchgröße auf 1 festlegen, wenn Sie die parallele Ausführung von durch Warteschlangen ausgelösten Funktionen in einer Funktions-App minimieren möchten. Diese Einstellung verhindert Parallelität nur so lange, wie Ihre Funktions-App auf einem einzelnen virtuellen Computer ausgeführt wird.

Mit dem Warteschlangentrigger wird automatisch verhindert, dass eine Funktion Warteschlangennachrichten mehrfach verarbeitet. Daher müssen keine idempotenten Funktionen geschrieben werden.

Trigger: Eigenschaften von „host.json“

Die Datei host.json enthält Einstellungen, mit denen das Verhalten des Warteschlangentriggers gesteuert werden kann. Informationen zu verfügbaren Einstellungen finden Sie im Abschnitt Einstellungen für „host.json“.

Output

Verwenden Sie die Azure Queue Storage-Ausgabebindung, um Nachrichten in eine Warteschlange zu schreiben.

Ausgabe: Beispiel

Sehen Sie sich das sprachspezifische Beispiel an:

Ausgabe: C#-Beispiel

Die C#-Funktion des folgenden Beispiels erstellt eine Warteschlangennachricht für jede empfangene HTTP-Anforderung.

[StorageAccount("AzureWebJobsStorage")]
public static class QueueFunctions
{
    [FunctionName("QueueOutput")]
    [return: Queue("myqueue-items")]
    public static string QueueOutput([HttpTrigger] dynamic input,  ILogger log)
    {
        log.LogInformation($"C# function processed: {input.Text}");
        return input.Text;
    }
}

Ausgabe: C#-Skriptbeispiel

Das folgende Beispiel enthält eine HTTP-Triggerbindung in einer Datei vom Typ function.json sowie Code vom Typ C#-Skript (.csx), in dem die Bindung verwendet wird. Die Funktion erstellt ein Warteschlangenelement mit einer CustomQueueMessage-Objektnutzlast für jede empfangene HTTP-Anforderung.

Die Datei function.json sieht wie folgt aus:

{
  "bindings": [
    {
      "type": "httpTrigger",
      "direction": "in",
      "authLevel": "function",
      "name": "input"
    },
    {
      "type": "http",
      "direction": "out",
      "name": "return"
    },
    {
      "type": "queue",
      "direction": "out",
      "name": "$return",
      "queueName": "outqueue",
      "connection": "MyStorageConnectionAppSetting"
    }
  ]
}

Weitere Informationen zu diesen Eigenschaften finden Sie im Abschnitt Konfiguration.

Der folgende C#-Skriptcode erstellt eine einzelne Warteschlangennachricht:

public class CustomQueueMessage
{
    public string PersonName { get; set; }
    public string Title { get; set; }
}

public static CustomQueueMessage Run(CustomQueueMessage input, ILogger log)
{
    return input;
}

Mithilfe eines Parameters vom Typ ICollector oder IAsyncCollector können mehrere Nachrichten gleichzeitig gesendet werden. Der folgende C#-Skriptcode sendet mehrere Nachrichten – eine mit den HTTP-Anforderungsdaten und eine mit hartcodierten Werten:

public static void Run(
    CustomQueueMessage input, 
    ICollector<CustomQueueMessage> myQueueItems, 
    ILogger log)
{
    myQueueItems.Add(input);
    myQueueItems.Add(new CustomQueueMessage { PersonName = "You", Title = "None" });
}

Ausgabe: JavaScript-Beispiel

Das folgende Beispiel enthält eine HTTP-Triggerbindung in einer Datei function.json sowie eine JavaScript-Funktion, die die Bindung verwendet. Die Funktion erstellt ein Warteschlangenelement für jede empfangene HTTP-Anforderung.

Die Datei function.json sieht wie folgt aus:

{
  "bindings": [
    {
      "type": "httpTrigger",
      "direction": "in",
      "authLevel": "function",
      "name": "input"
    },
    {
      "type": "http",
      "direction": "out",
      "name": "return"
    },
    {
      "type": "queue",
      "direction": "out",
      "name": "$return",
      "queueName": "outqueue",
      "connection": "MyStorageConnectionAppSetting"
    }
  ]
}

Weitere Informationen zu diesen Eigenschaften finden Sie im Abschnitt Konfiguration.

Der JavaScript-Code sieht wie folgt aus:

module.exports = function (context, input) {
    context.done(null, input.body);
};

Wenn Sie mehrere Nachrichten gleichzeitig senden möchten, können Sie ein Nachrichtenarray für die Ausgabebindung myQueueItem definieren. Der folgende JavaScript-Code sendet zwei Warteschlangennachrichten mit hartcodierten Werten für jede empfangene HTTP-Anforderung.

module.exports = function(context) {
    context.bindings.myQueueItem = ["message 1","message 2"];
    context.done();
};

Ausgabe: Java-Beispiel

Die Java-Funktion des folgenden Beispiels erstellt eine Warteschlangennachricht bei Auslösung durch eine HTTP-Anforderung.

@FunctionName("httpToQueue")
@QueueOutput(name = "item", queueName = "myqueue-items", connection = "AzureWebJobsStorage")
 public String pushToQueue(
     @HttpTrigger(name = "request", methods = {HttpMethod.POST}, authLevel = AuthorizationLevel.ANONYMOUS)
     final String message,
     @HttpOutput(name = "response") final OutputBinding&lt;String&gt; result) {
       result.setValue(message + " has been added.");
       return message;
 }

Verwenden Sie die @QueueOutput-Anmerkung in der Laufzeitbibliothek für Java-Funktionen für Parameter, deren Wert in Queue Storage geschrieben wird. Der Parametertyp sollte OutputBinding<T> lauten, wobei „T“ für einen beliebigen nativen Java-Typ eines POJO steht.

Ausgabe: Attribute

In C#-Klassenbibliotheken verwenden Sie die QueueAttribute.

Das Attribut gilt für einen Parameter vom Typ out oder für den Rückgabewert der Funktion. Der Konstruktor des Attributs akzeptiert den Namen der Warteschlange, wie im folgenden Beispiel zu sehen:

[FunctionName("QueueOutput")]
[return: Queue("myqueue-items")]
public static string Run([HttpTrigger] dynamic input,  ILogger log)
{
    ...
}

Durch Festlegen der Eigenschaft Connection können Sie das zu verwendende Speicherkonto angeben, wie im folgenden Beispiel zu sehen:

[FunctionName("QueueOutput")]
[return: Queue("myqueue-items", Connection = "StorageConnectionAppSetting")]
public static string Run([HttpTrigger] dynamic input,  ILogger log)
{
    ...
}

Ein vollständiges Beispiel finden Sie unter Ausgabe: C#-Beispiel.

Mit dem Attribut StorageAccount können Sie das Speicherkonto auf Klassen-, Methoden- oder Parameterebene angeben. Weitere Informationen finden Sie unter „Trigger: Attribute“.

Ausgabe: Konfiguration

Die folgende Tabelle gibt Aufschluss über die Bindungskonfigurationseigenschaften, die Sie in der Datei function.json und im Attribut Queue festlegen:

Eigenschaft von „function.json“ Attributeigenschaft BESCHREIBUNG
type Muss auf queue festgelegt sein. Diese Eigenschaft wird automatisch festgelegt, wenn Sie den Trigger im Azure Portal erstellen.
direction Muss auf out festgelegt sein. Diese Eigenschaft wird automatisch festgelegt, wenn Sie den Trigger im Azure Portal erstellen.
name Der Name der Variablen, die die Warteschlange im Funktionscode darstellt. Legen Sie diesen Wert auf $return fest, um auf den Rückgabewert der Funktion zu verweisen.
queueName QueueName Der Name der Warteschlange.
Verbindung Connection Der Name einer App-Einstellung, die die Storage-Verbindungszeichenfolge für diese Bindung enthält. Falls der Name der App-Einstellung mit „AzureWebJobs“ beginnt, können Sie hier nur den Rest des Namens angeben. Wenn Sie connection also beispielsweise auf „MyStorage“ festlegen, sucht die Functions-Laufzeit nach einer App-Einstellung namens „AzureWebJobsMyStorage“. Ohne Angabe für connection verwendet die Functions-Laufzeit die standardmäßige Storage-Verbindungszeichenfolge aus der App-Einstellung AzureWebJobsStorage.

[!INCLUDE app settings to local.settings.json]

Ausgabe: Verwendung

Verwenden Sie in C# und C#-Skripts einen Methodenparameter wie out T paramName, um eine einzelne Warteschlangennachricht zu schreiben. In C#-Skripts ist paramName der Wert, der in der Eigenschaft name von function.json angegeben ist. Anstelle eines Parameters vom Typ out können Sie den Rückgabetyp der Methode verwenden, und T kann einer der folgenden Typen sein:

Wenn Sie versuchen, eine Bindung an CloudQueueMessage herzustellen, und eine Fehlermeldung erhalten, stellen Sie sicher, dass ein Verweis auf die richtige Storage SDK-Version vorliegt.

Verwenden Sie einen der folgenden Typen, um in C# und C#-Skripts mehrere Warteschlangennachrichten zu schreiben:

  • ICollector<T> oder IAsyncCollector<T>
  • CloudQueue

Verwenden Sie in JavaScript-Funktionen context.bindings.<name>, um auf die Ausgabewarteschlangennachricht zuzugreifen. Für die Nutzlast des Warteschlangenelements kann eine Zeichenfolge oder ein JSON-serialisierbares Objekt verwendet werden.

Ausnahmen und Rückgabecodes

Bindung Verweis
Warteschlange Warteschlangen-Fehlercodes
Blob, Tabelle, Warteschlange Speicherfehlercodes
Blob, Tabelle, Warteschlange Problembehandlung

Einstellungen für „host.json“

In diesem Abschnitt werden die verfügbaren globalen Konfigurationseinstellungen für diese Bindung in Version 2.x beschrieben. Die nachfolgende Beispieldatei „host.json“ enthält nur die Einstellungen für Version 2.x für diese Bindung. Weitere Informationen zu globalen Konfigurationseinstellungen in Version 2.x finden Sie unter host.json-Referenz für Azure Functions 2.x.

[!NOTE] Eine Referenz für „host.json“ in Functions 1.x finden Sie unter host.json-Referenz für Azure Functions 1.x.

{
    "version": "2.0",
    "extensions": {
        "queues": {
            "maxPollingInterval": "00:00:02",
            "visibilityTimeout" : "00:00:30",
            "batchSize": 16,
            "maxDequeueCount": 5,
            "newBatchThreshold": 8
        }
    }
}
Eigenschaft Standard BESCHREIBUNG
maxPollingInterval 00:00:01 Das maximale Intervall zwischen Warteschlangenabfragen. Der Mindestwert lautet 00:00:00.100 (100 ms), er wird bis auf 00:01:00 (1 Min.) erhöht.
visibilityTimeout 00:00:00 Das Zeitintervall zwischen Wiederholungsversuchen, wenn bei der Verarbeitung einer Nachricht ein Fehler auftritt.
batchSize 16 Die Anzahl der Warteschlangennachrichten, die die Functions-Runtime gleichzeitig abruft und parallel verarbeitet. Wenn die zu verarbeitende Anzahl newBatchThreshold erreicht, ruft die Runtime einen weiteren Batch ab und beginnt mit der Verarbeitung dieser Nachrichten. Aus diesem Grund beträgt die maximale Anzahl der pro Funktion verarbeiteten Nachrichten batchSize plus newBatchThreshold. Dieser Grenzwert gilt separat für jede Funktion, die durch die Warteschlange ausgelöst wird.

Wenn Sie eine parallele Ausführung für in einer Warteschlange empfangene Nachrichten vermeiden möchten, können Sie batchSize auf „1“ festlegen. Diese Einstellung verhindert Parallelität jedoch nur so lange, wie Ihre Funktions-App auf einem einzelnen virtuellen Computer (VM) ausgeführt wird. Wenn die Funktions-App horizontal auf mehrere virtuelle Computer hochskaliert wird, kann jeder virtuelle Computer eine Instanz jeder durch die Warteschlange ausgelösten Funktion ausführen.

Die maximale batchSize beträgt 32.
maxDequeueCount 5 Die Anzahl der Versuche zum Verarbeiten einer Nachricht, bevor diese in die Warteschlange für nicht verarbeitete Nachrichten verschoben wird.
newBatchThreshold batchSize/2 Wenn die Anzahl der gleichzeitig verarbeiteten Nachrichten auf diesen Wert sinkt, ruft die Runtime einen weiteren Batch ab.

Nächste Schritte

[!div class="nextstepaction"] Hinzufügen von Meldungen in die Warteschlange von Azure Storage mithilfe von Functions

You can’t perform that action at this time.