Azure Blob Storage-Trigger für Azure Functions

Der Blobspeichertrigger startet eine Funktion, wenn ein neues oder aktualisiertes Blob erkannt wird. Der Blobinhalt wird als Eingabe für die Funktion bereitgestellt.

Tipp

Es gibt mehrere Möglichkeiten, den Funktionscode basierend auf Änderungen an Blobs in einem Speichercontainer auszuführen. Wenn Sie sich für die Verwendung des Blob storage-Triggers entscheiden, beachten Sie, dass zwei Implementierungen angeboten werden: eine abfragebasierte (in diesem Artikel referenziert) und eine ereignisbasierte. Es wird empfohlen, die ereignisbasierte Implementierung zu verwenden, da sie niedrigere Latenz als die andere hat. Außerdem unterstützt der Flex-Verbrauchsplan nur den ereignisbasierten Blob-Speichertrigger.

Ausführliche Informationen zu den Unterschieden zwischen den beiden Implementierungen des BLOB-Speichertriggers sowie zu anderen Triggeroptionen finden Sie unter Arbeiten mit Blobs.

Informationen zu Setup- und Konfigurationsdetails finden Sie in der Übersicht.

Wichtig

In diesem Artikel werden Registerkarten verwendet, um mehrere Versionen des Node.js-Programmiermodells zu unterstützen. Das v4-Modell ist allgemein verfügbar und bietet JavaScript- und TypeScript-Entwicklern eine flexiblere und intuitivere Erfahrung. Weitere Informationen zur Funktionsweise des v4-Modells finden Sie im Azure Functions Node.js-Entwicklerhandbuch. Weitere Informationen zu den Unterschieden zwischen v3 und v4 finden Sie im Migrationshandbuch.

Azure Functions unterstützt zwei Programmiermodelle für Python. Wie Sie Ihre Bindung definieren, hängt vom gewählten Python-Programmiermodell ab.

v2

Mit dem Python v2-Programmiermodell können Sie Bindungen mithilfe von Decorators direkt im Python-Funktionscode definieren. Weitere Informationen finden Sie im Python Developer-Leitfaden.

v1

Für das Python v1-Programmiermodell müssen Sie Bindungen in einer separaten function.json-Datei im Funktionsordner definieren. Weitere Informationen finden Sie im Python Developer-Leitfaden.

In diesem Artikel werden beide Programmiermodelle unterstützt.

Beispiel

Eine C#-Funktion kann mit einem der folgenden C#-Modi erstellt werden:

• Isoliertes Workermodell: Kompilierte C#-Funktion, die in einem Workerprozess ausgeführt wird, der von der Runtime isoliert ist. Ein isolierter Workerprozess ist erforderlich, um C#-Funktionen zu unterstützen, die in LTS- und Nicht-LTS-Versionen von .NET und .NET Framework ausgeführt werden. Erweiterungen für isolierte Workerprozessfunktionen verwenden Microsoft.Azure.Functions.Worker.Extensions.*-Namespaces.
• In-Process-Modell: Kompilierte C#-Funktion, die im gleichen Prozess wie die Functions-Runtime ausgeführt wird. In einer Variante dieses Modells kann Functions mithilfe von C#-Skripts ausgeführt werden. Dies wird hauptsächlich für die Bearbeitung im C#-Portal unterstützt. Erweiterungen für In-Process-Funktionen verwenden Microsoft.Azure.WebJobs.Extensions.*-Namespaces.

Wichtig

Die Unterstützung für das In-Process-Modell endet am 10. November 2026. Es wird dringend empfohlen, Ihre Apps zum isolierten Workermodell zu migrieren, um den vollständigen Support zu ermöglichen.

Isoliertes Workermodell

Das folgende Beispiel ist eine C#-Funktion, die in einem isolierten Workerprozess ausgeführt wird und einen Blobtrigger mit Blobbindungen für Blobeingabe und -ausgabe verwendet. Die Funktion wird durch die Erstellung eines Blobs im Container test-samples-trigger ausgelöst. Sie liest eine Textdatei aus dem Container test-samples-input und erstellt basierend auf dem Namen der ausgelösten Datei eine neue Textdatei in einem Ausgabecontainer.

public static class BlobFunction
{
    [Function(nameof(BlobFunction))]
    [BlobOutput("test-samples-output/{name}-output.txt")]
    public static string Run(
        [BlobTrigger("test-samples-trigger/{name}")] string myTriggerItem,
        [BlobInput("test-samples-input/sample1.txt")] string myBlob,
        FunctionContext context)
    {
        var logger = context.GetLogger("BlobFunction");
        logger.LogInformation("Triggered Item = {myTriggerItem}", myTriggerItem);
        logger.LogInformation("Input Item = {myBlob}", myBlob);

        // Blob Output
        return "blob-output content";
    }
}

In-Process-Modell

Mit der C#-Funktion im folgenden Beispiel wird ein Protokoll geschrieben, wenn im Container samples-workitems ein Blob hinzugefügt oder aktualisiert wird.

[FunctionName("BlobTriggerCSharp")]        
public static void Run([BlobTrigger("samples-workitems/{name}")] Stream myBlob, string name, ILogger log)
{
    log.LogInformation($"C# Blob trigger function Processed blob\n Name:{name} \n Size: {myBlob.Length} Bytes");
}

Die Zeichenfolge {name} im Blobtriggerpfad samples-workitems/{name} erstellt einen {name}, den Sie im Funktionscode verwenden können, um auf den Dateinamen des auslösenden Blobs zuzugreifen. Weitere Informationen finden Sie unter Blobnamensmuster weiter unten in diesem Artikel.

Weitere Informationen zum Attribut BlobTrigger finden Sie unter Attribute.

Diese Funktion schreibt ein Protokoll, wenn im myblob-Container ein Blob hinzugefügt oder aktualisiert wird.

@FunctionName("blobprocessor")
public void run(
  @BlobTrigger(name = "file",
               dataType = "binary",
               path = "myblob/{name}",
               connection = "MyStorageAccountAppSetting") byte[] content,
  @BindingName("name") String filename,
  final ExecutionContext context
) {
  context.getLogger().info("Name: " + filename + " Size: " + content.length + " bytes");
}

Modell v4

Das folgende Beispiel zeigt den TypeScript-Code für einen Blobtrigger. Die Funktion schreibt ein Protokoll, wenn im Container samples-workitems ein Blob hinzugefügt oder aktualisiert wird.

Die Zeichenfolge {name} im Blobtriggerpfad samples-workitems/{name} erstellt einen {name}, den Sie im Funktionscode verwenden können, um auf den Dateinamen des auslösenden Blobs zuzugreifen. Weitere Informationen finden Sie unter Blobnamensmuster weiter unten in diesem Artikel.

import { app, InvocationContext } from '@azure/functions';

export async function storageBlobTrigger1(blob: Buffer, context: InvocationContext): Promise<void> {
    context.log(
        `Storage blob function processed blob "${context.triggerMetadata.name}" with size ${blob.length} bytes`
    );
}

app.storageBlob('storageBlobTrigger1', {
    path: 'samples-workitems/{name}',
    connection: 'MyStorageAccountAppSetting',
    handler: storageBlobTrigger1,
});

Modell v3

TypeScript-Beispiele sind für Modell v3 nicht dokumentiert.

Modell v4

Das folgende Beispiel zeigt den JavaScript-Code für einen Blobtrigger. Die Funktion schreibt ein Protokoll, wenn im Container samples-workitems ein Blob hinzugefügt oder aktualisiert wird.

Die Zeichenfolge {name} im Blobtriggerpfad samples-workitems/{name} erstellt einen {name}, den Sie im Funktionscode verwenden können, um auf den Dateinamen des auslösenden Blobs zuzugreifen. Weitere Informationen finden Sie unter Blobnamensmuster weiter unten in diesem Artikel.

const { app } = require('@azure/functions');

app.storageBlob('storageBlobTrigger1', {
    path: 'samples-workitems/{name}',
    connection: 'MyStorageAccountAppSetting',
    handler: (blob, context) => {
        context.log(
            `Storage blob function processed blob "${context.triggerMetadata.name}" with size ${blob.length} bytes`
        );
    },
});

Modell v3

Das folgende Beispiel zeigt eine Blobtriggerbindung in einer Datei function.json und JavaScript-Code, der die Bindung verwendet. Die Funktion schreibt ein Protokoll, wenn im Container samples-workitems ein Blob hinzugefügt oder aktualisiert wird.

Die Datei function.json sieht wie folgt aus:

{
    "disabled": false,
    "bindings": [
        {
            "name": "myBlob",
            "type": "blobTrigger",
            "direction": "in",
            "path": "samples-workitems/{name}",
            "connection":"MyStorageAccountAppSetting"
        }
    ]
}

Die Zeichenfolge {name} im Blobtriggerpfad samples-workitems/{name} erstellt einen {name}, den Sie im Funktionscode verwenden können, um auf den Dateinamen des auslösenden Blobs zuzugreifen. Weitere Informationen finden Sie unter Blobnamensmuster weiter unten in diesem Artikel.

Weitere Informationen zu den Dateieigenschaften von function.json finden Sie im Abschnitt Konfiguration, in dem diese Eigenschaften erläutert werden.

Der JavaScript-Code sieht wie folgt aus:

module.exports = async function(context) {
    context.log('Node.js Blob trigger function processed', context.bindings.myBlob);
};

Das folgende Beispiel veranschaulicht, wie Sie eine Funktion erstellen, die ausgeführt wird, wenn dem Blobspeichercontainer source eine Datei hinzugefügt wird.

Die Funktionskonfigurationsdatei (function.json) enthält eine Bindung mit blobTrigger als type, bei der direction auf in festgelegt ist.

{
  "bindings": [
    {
      "name": "InputBlob",
      "type": "blobTrigger",
      "direction": "in",
      "path": "source/{name}",
      "connection": "MyStorageAccountConnectionString"
    }
  ]
}

Hier sehen Sie den zugehörigen Code für die Datei run.ps1.

param([byte[]] $InputBlob, $TriggerMetadata)

Write-Host "PowerShell Blob trigger: Name: $($TriggerMetadata.Name) Size: $($InputBlob.Length) bytes"

v2

In diesem Beispiel werden SDK-Typen verwendet, um direkt auf das zugrunde liegende BlobClient Objekt zuzugreifen, das vom Blob Storage-Trigger bereitgestellt wird:

import logging

import azure.functions as func
import azurefunctions.extensions.bindings.blob as blob

app = func.FunctionApp(http_auth_level=func.AuthLevel.ANONYMOUS)
@app.blob_trigger(
    arg_name="client", path="PATH/TO/BLOB", connection="AzureWebJobsStorage"
)
def blob_trigger(client: blob.BlobClient):
    logging.info(
        f"Python blob trigger function processed blob \n"
        f"Properties: {client.get_blob_properties()}\n"
        f"Blob content head: {client.download_blob().read(size=1)}"
    )

Beispiele für die Verwendung anderer SDK-Typen finden Sie in den ContainerClient Und StorageStreamDownloader Beispielen.

Weitere Informationen, einschließlich der Aktivierung von SDK-Typbindungen in Ihrem Projekt, finden Sie unter SDK-Typbindungen.

In diesem Beispiel werden Informationen aus den eingehenden BLOB-Metadaten protokolliert.

import logging
import azure.functions as func

app = func.FunctionApp()

@app.function_name(name="BlobTrigger1")
@app.blob_trigger(arg_name="myblob", 
                  path="PATH/TO/BLOB",
                  connection="CONNECTION_SETTING")
def test_function(myblob: func.InputStream):
   logging.info(f"Python blob trigger function processed blob \n"
                f"Name: {myblob.name}\n"
                f"Blob Size: {myblob.length} bytes")

v1

Die Funktion schreibt ein Protokoll, wenn im samples-workitems-Container ein Blob hinzugefügt oder aktualisiert wird. Die Datei function.json sieht wie folgt aus:

{
    "scriptFile": "__init__.py",
    "disabled": false,
    "bindings": [
        {
            "name": "myblob",
            "type": "blobTrigger",
            "direction": "in",
            "path": "samples-workitems/{name}",
            "connection":"MyStorageAccountAppSetting"
        }
    ]
}

Die Zeichenfolge {name} im Blobtriggerpfad samples-workitems/{name} erstellt einen {name}, den Sie im Funktionscode verwenden können, um auf den Dateinamen des auslösenden Blobs zuzugreifen. Weitere Informationen finden Sie unter Blobnamensmuster weiter unten in diesem Artikel.

Weitere Informationen zu den Dateieigenschaften von function.json finden Sie im Abschnitt Konfiguration, in dem diese Eigenschaften erläutert werden.

Dies ist der Python-Code:

import logging
import azure.functions as func


def main(myblob: func.InputStream):
    logging.info('Python Blob trigger function processed %s', myblob.name)

---

Attribute

Sowohl von C#-Bibliotheken vom Typ In-Process als auch von C#-Bibliotheken vom Typ Isolierter Workerprozess wird BlobAttribute verwendet, um die Funktion zu definieren. Das C#-Skript verwendet stattdessen eine Konfigurationsdatei function.json, wie im C#-Skript-Handbuch beschrieben.

Vom Konstruktor des Attributs werden folgende Parameter akzeptiert:

Parameter	BESCHREIBUNG
BlobPath	Der Pfad des Blobs.
Connection	Der Name einer App-Einstellung oder -Einstellungssammlung, die angibt, wie eine Verbindung mit Azure Blobs hergestellt wird. Siehe Verbindungen.
zugreifen	Gibt an, ob Sie einen Lesevorgang oder einen Schreibvorgang ausführen möchten.
Quelle	Legt die Quelle des auslösenden Ereignisses fest. Verwenden Sie BlobTriggerSource.EventGrid für einen Event Grid-basierten Blobtrigger, der eine viel geringere Latenz bietet. Der Standardwert ist BlobTriggerSource.LogsAndContainerScan – dieser verwendet den Standardabrufmechanismus, um Änderungen im Container zu erkennen.

Isoliertes Workermodell

Dies ist ein BlobTrigger-Attribut in einer Methodensignatur:

[Function(nameof(BlobFunction))]
[BlobOutput("test-samples-output/{name}-output.txt")]
public static string Run(
    [BlobTrigger("test-samples-trigger/{name}")] string myTriggerItem,
    [BlobInput("test-samples-input/sample1.txt")] string myBlob,
    FunctionContext context)

In-Process-Modell

In C#-Klassenbibliotheken akzeptiert der Konstruktor des Attributs eine Pfadzeichenfolge, die den zu überwachenden Container angibt, und optional ein Blobnamensmuster. Hier sehen Sie ein Beispiel:

[FunctionName("ResizeImage")]
public static void Run(
  [BlobTrigger("sample-images/{name}")] Stream image,
  [Blob("sample-images-md/{name}", FileAccess.Write)] Stream imageSmall)
{
  ....
}

Während das Attribut eine Connection-Eigenschaft annimmt, können Sie auch Connection verwenden, um eine Speicherkontoverbindung anzugeben. Sie können so vorgehen, wenn Sie ein anderes Speicherkonto als andere Funktionen in der Bibliothek verwenden müssen. 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("StorageTrigger")]
    [StorageAccount("FunctionLevelStorageAppSetting")]
    public static void Run( //...
{
    ...
}

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

• Die Connection-Eigenschaft des Triggers oder Bindungsattributs.
• Das StorageAccount-Attribut, das auf den gleichen Parameter wie der Trigger oder das Bindungsattribut angewendet wird.
• Das Attribut StorageAccount, das auf die Funktion angewendet wird.
• Das Attribut StorageAccount, das auf die Klasse angewendet wird.
• Das Standardspeicherkonto für die Funktions-App, das in der AzureWebJobsStorage-Anwendungseinstellung definiert ist.

Wenn Sie die Entwicklung lokal ausführen, fügen Sie Ihre Anwendungseinstellungen in der Datei local.settings.json in der Values-Sammlung hinzu.

Decorator-Elemente

Gilt nur für das Python v2-Programmiermodell.

Für Python v2-Funktionen, die mithilfe von Decorators definiert wurden, definieren die folgenden Eigenschaften auf dem Decorator blob_trigger den Blob Storage-Trigger:

Eigenschaft	BESCHREIBUNG
arg_name	Deklariert den Parameternamen in der Funktionssignatur. Wenn die Funktion ausgelöst wird, enthält der Wert dieses Parameters den Inhalt der Warteschlangennachricht.
path	Der zu überwachende Container. Kann ein Blobnamensmuster sein.
connection	Die Verbindungszeichenfolge für das Speicherkonto.
source	Legt die Quelle des auslösenden Ereignisses fest. Verwenden Sie EventGrid für einen Event Grid-basierten Blobtrigger, der eine viel geringere Latenz bietet. Der Standardwert ist LogsAndContainerScan – dieser verwendet den Standardabrufmechanismus, um Änderungen im Container zu erkennen.

Informationen zu Python-Funktionen, die mithilfe von function.json definiert wurden, finden Sie im Abschnitt Konfiguration.

Anmerkungen

Das @BlobTrigger-Attribut wird verwendet, um Ihnen Zugriff auf das Blob zu gewähren, das die Funktion ausgelöst hat. Weitere Detailinformationen finden Sie im Triggerbeispiel. Verwenden Sie die Eigenschaft source, um die Quelle des auslösenden Ereignisses festzulegen. Verwenden Sie EventGrid für einen Event Grid-basierten Blobtrigger, der eine viel geringere Latenz bietet. Der Standardwert ist LogsAndContainerScan – dieser verwendet den Standardabrufmechanismus, um Änderungen im Container zu erkennen. |

Konfiguration

Gilt nur für das Python v1-Programmiermodell.

Modell v4

In der folgenden Tabelle werden die Eigenschaften erläutert, die Sie für das options-Objekt festlegen können, das an die app.storageBlob()-Methode übergeben wurde.

Eigenschaft	Beschreibung
path	Der zu überwachende Container. Kann ein Blobnamensmuster sein.
connection	Der Name einer App-Einstellung oder -Einstellungssammlung, die angibt, wie eine Verbindung mit Azure Blobs hergestellt wird. Siehe Verbindungen.
Quelle	Legt die Quelle des auslösenden Ereignisses fest. Verwenden Sie EventGrid für einen Event Grid-basierten Blobtrigger, der eine viel geringere Latenz bietet. Der Standardwert ist LogsAndContainerScan – dieser verwendet den Standardabrufmechanismus, um Änderungen im Container zu erkennen.

Modell v3

Die folgende Tabelle gibt Aufschluss über die Bindungskonfigurationseigenschaften, die Sie in der Datei function.json festlegen.

Eigenschaft	Beschreibung des Dataflows
type	Muss auf blobTrigger festgelegt sein. Diese Eigenschaft wird automatisch festgelegt, wenn Sie den Trigger im Azure Portal erstellen.
direction	Muss auf in festgelegt sein. Diese Eigenschaft wird automatisch festgelegt, wenn Sie den Trigger im Azure Portal erstellen. Ausnahmen sind im Abschnitt Verwendung angegeben.
name	Der Name der Variablen, die das Blob im Funktionscode darstellt.
path	Der zu überwachende Container. Kann ein Blobnamensmuster sein.
connection	Der Name einer App-Einstellung oder -Einstellungssammlung, die angibt, wie eine Verbindung mit Azure Blobs hergestellt wird. Siehe Verbindungen.
Quelle	Legt die Quelle des auslösenden Ereignisses fest. Verwenden Sie EventGrid für einen Event Grid-basierten Blobtrigger, der eine viel geringere Latenz bietet. Der Standardwert ist LogsAndContainerScan – dieser verwendet den Standardabrufmechanismus, um Änderungen im Container zu erkennen.

Die folgende Tabelle gibt Aufschluss über die Bindungskonfigurationseigenschaften, die Sie in der Datei function.json festlegen.

function.json-Eigenschaft	BESCHREIBUNG
type	Muss auf blobTrigger festgelegt sein. Diese Eigenschaft wird automatisch festgelegt, wenn Sie den Trigger im Azure Portal erstellen.
direction	Muss auf in festgelegt sein. Diese Eigenschaft wird automatisch festgelegt, wenn Sie den Trigger im Azure Portal erstellen. Ausnahmen sind im Abschnitt Verwendung angegeben.
name	Der Name der Variablen, die das Blob im Funktionscode darstellt.
path	Der zu überwachende Container. Kann ein Blobnamensmuster sein.
connection	Der Name einer App-Einstellung oder -Einstellungssammlung, die angibt, wie eine Verbindung mit Azure Blobs hergestellt wird. Siehe Verbindungen.
Quelle	Legt die Quelle des auslösenden Ereignisses fest. Verwenden Sie EventGrid für einen Event Grid-basierten Blobtrigger, der eine viel geringere Latenz bietet. Der Standardwert ist LogsAndContainerScan – dieser verwendet den Standardabrufmechanismus, um Änderungen im Container zu erkennen.

Vollständige Beispiele finden Sie im Abschnitt „Beispiele“.

Metadaten

Der Blobtrigger stellt mehrere Metadateneigenschaften bereit. Diese Eigenschaften können als Teil der Bindungsausdrücke in anderen Bindungen oder als Parameter im Code verwendet werden. Diese Werte haben die gleiche Semantik wie der Typ CloudBlob.

Eigenschaft	Typ	Beschreibung
BlobTrigger	string	Der Pfad des auslösenden Blobs.
Uri	System.Uri	Der Blob-URI für den primären Speicherort
Properties	BlobProperties	Die Systemeigenschaften des Blobs
Metadata	IDictionary<string,string>	Die benutzerdefinierten Metadaten für das Blob

Im folgenden Beispiel wird der Pfad zum auslösenden Blob einschließlich des Containers protokolliert:

public static void Run(string myBlob, string blobTrigger, ILogger log)
{
    log.LogInformation($"Full blob path: {blobTrigger}");
} 

Metadaten

Der Blobtrigger stellt mehrere Metadateneigenschaften bereit. Diese Eigenschaften können als Teil der Bindungsausdrücke in anderen Bindungen oder als Parameter im Code verwendet werden.

Eigenschaft	Beschreibung
blobTrigger	Der Pfad des auslösenden Blobs.
uri	Der Blob-URI für den primären Speicherort
properties	Die Systemeigenschaften des Blobs
metadata	Die benutzerdefinierten Metadaten für das Blob

Modell v4

Metadaten können aus der Eigenschaft triggerMetadata des angegebenen Objekts vom Typ context abgerufen werden, wie im folgenden Beispiel zu sehen. In diesem Beispiel wird der Pfad zum auslösenden Blob (blobTrigger) einschließlich des Containers protokolliert:

context.log(`Full blob path: ${context.triggerMetadata.blobTrigger}`);

Modell v3

Metadaten können aus der Eigenschaft bindingData des angegebenen Objekts vom Typ context abgerufen werden, wie im folgenden Beispiel zu sehen. In diesem Beispiel wird der Pfad zum auslösenden Blob (blobTrigger) einschließlich des Containers protokolliert:

module.exports = async function (context, myBlob) {
    context.log("Full blob path:", context.bindingData.blobTrigger);
};

Metadaten

Metadaten sind über den Parameter $TriggerMetadata verfügbar.

Verwendung

Die vom Blobtrigger unterstützten Bindungstypen hängen von der Version des Erweiterungspakets und der C#-Modalität ab, die in Ihrer Funktions-App verwendet wird.

Isoliertes Workermodell

Der Blobtrigger kann an die folgenden Typen gebunden werden:

type	BESCHREIBUNG
string	Den Blobinhalt als Zeichenfolge. Verwenden Sie diese Option, wenn der Inhalt des Blobs einfacher Text ist.
byte[]	Die Bytes des Blobinhalts.
Serialisierbare JSON-Typen	Wenn ein Blob JSON-Daten enthält, versucht Functions, die JSON-Daten in einen POCO-Objekttyp (Plain-Old CLR Object) zu deserialisieren.
Stream1	Ein Eingabestream des Blobinhalts.
BlobClient1, BlockBlobClient1, PageBlobClient1, AppendBlobClient1, BlobBaseClient1	Ein Client, der mit dem Blob verbunden ist. Diese Typen bieten die größte Kontrolle für die Verarbeitung des Blobs und können zum Zurückschreiben in das Blob verwendet werden, wenn die Verbindung über ausreichende Berechtigungen verfügt.

¹ Um diese Typen zu verwenden, müssen Sie auf Microsoft.Azure.Functions.Worker.Extensions.Storage.Blobs 6.0.0 oder höher und die gemeinsamen Abhängigkeiten für SDK-Typbindungen verweisen.

In-Process-Modell

Eine Liste der unterstützten Typen finden Sie unter Bindungstypen.

Die Bindung an string oder Byte[] wird nur bei kleinen Blobs empfohlen. Der Grund für diese Empfehlung ist, dass der gesamte Blobinhalt in den Arbeitsspeicher geladen wird. Für die meisten Blobs sollte der Typ Stream oder BlobClient verwendet werden. Weitere Informationen finden Sie unter Parallelität und Arbeitsspeichernutzung.

Wenn beim Versuch, eine Bindung an einen der Storage SDK-Typen einzurichten, ein Fehler auftritt, vergewissern Sie sich, dass Sie über einen Verweis auf die richtige Storage SDK-Version verfügen.

Sie können auch StorageAccountAttribute verwenden, um das zu verwendende Speicherkonto anzugeben. Sie können so vorgehen, wenn Sie ein anderes Speicherkonto als andere Funktionen in der Bibliothek verwenden müssen. 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("BlobTrigger")]
    [StorageAccount("FunctionLevelStorageAppSetting")]
    public static void Run( //...
{
    ....
}

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

• Die Eigenschaft Connection des Attributs BlobTrigger.
• Das Attribut StorageAccount, das auf den gleichen Parameter angewendet wird wie das Attribut BlobTrigger.
• Das Attribut StorageAccount, das auf die Funktion angewendet wird.
• Das Attribut StorageAccount, das auf die Klasse angewendet wird.
• Das Standardspeicherkonto für die Funktions-App, das in der AzureWebJobsStorage-Anwendungseinstellung definiert ist.

Das @BlobTrigger-Attribut wird verwendet, um Ihnen Zugriff auf das Blob zu gewähren, das die Funktion ausgelöst hat. Weitere Detailinformationen finden Sie im Triggerbeispiel.

Modell v4

Greifen Sie auf die Blobdaten als erstes Argument für Ihre Funktion zu.

Modell v3

Greifen Sie über context.bindings.<NAME> auf Blobdaten zu, wobei <NAME> mit dem in context.bindings.<NAME> definierten Wert übereinstimmt.

Greifen Sie auf die Blobdaten über einen Parameter zu, der mit dem Namen übereinstimmt, der durch den name-Parameter der Bindung in der Datei function.json festgelegt ist.

Greifen Sie über den als InputStream typisierten Parameter auf Blob-Daten zu. Weitere Detailinformationen finden Sie im Triggerbeispiel.

Funktionen unterstützen auch Python SDK-Typbindungen für Azure Blob Storage, mit denen Sie mit BLOB-Daten mit diesen zugrunde liegenden SDK-Typen arbeiten können:

• BlobClient
• ContainerClient
• StorageStreamDownloader

Wichtig

Die SDK-Typenunterstützung für Python befindet sich derzeit in der Vorschau und wird nur für das Python v2-Programmiermodell unterstützt. Weitere Informationen finden Sie unter SDK-Typen in Python.

Verbindungen

Die Eigenschaft connection ist ein Verweis auf die Umgebungskonfiguration, die angibt, wie die App eine Verbindung mit Azure-Blobs herstellen soll. Folgendes kann angegeben werden:

• Der Name einer Anwendungseinstellung, die eine Verbindungszeichenfolge enthält
• Der Name eines gemeinsam genutzten Präfixes für mehrere Anwendungseinstellungen, die zusammen eine identitätsbasierte Verbindung definieren.

Wenn der konfigurierte Wert sowohl eine genaue Übereinstimmung für eine einzelne Einstellung als auch eine Präfix-Übereinstimmung für andere Einstellungen ist, wird die genaue Übereinstimmung verwendet.

Verbindungszeichenfolge

Um eine Verbindungszeichenfolge zu erhalten, folgen Sie den Schritten unter Verwaltung der Zugriffsschlüssel für Speicherkonten. Bei der Verbindungszeichenfolge muss es sich um eine Verbindungszeichenfolge für ein allgemeines Speicherkonto (nicht für ein Blobspeicherkonto) handeln.

Diese Verbindungszeichenfolge sollte in einer Anwendungseinstellung mit einem Namen gespeichert werden, der dem in der Eigenschaft connection der Bindungskonfiguration angegebenen Wert entspricht.

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.

Identitätsbasierte Verbindungen

Wenn Sie Version 5.x oder höher der Erweiterung verwenden (Bündel 3.x oder höher für non-.NET Sprachstapel), anstatt einen Verbindungszeichenfolge mit einem geheimen Schlüssel zu verwenden, können Sie die App über eine Microsoft Entra-Identität verfügen. Um eine Identität zu verwenden, definieren Sie Einstellungen unter einem gemeinsamen Präfix, das der Eigenschaft connection in der Trigger- und Bindungskonfiguration zugeordnet ist.

Wenn Sie connection auf „AzureWebJobsStorage“ festlegen, finden Sie weitere Informationen unter Herstellen einer Verbindung zum Hostspeicher mit einer Identität. Für alle anderen Verbindungen erfordert die Erweiterung die folgenden Eigenschaften:

Eigenschaft	Vorlage für Umgebungsvariable	BESCHREIBUNG	Beispielwert
Blob-Dienst-URI	<CONNECTION_NAME_PREFIX>__serviceUri1	Der URI der Datenebene des Blob-Dienstes, mit dem Sie sich mithilfe des HTTPS-Schemas verbinden.	https://<storage_account_name>.blob.core.windows.net

¹ <CONNECTION_NAME_PREFIX>__blobServiceUri kann als Alias verwendet werden. Wenn die Verbindungskonfiguration von einem Blobtrigger verwendet wird, muss blobServiceUri auch von queueServiceUri begleitet werden. Siehe unten.

Das Format serviceUri kann nicht verwendet werden, wenn die gesamte Verbindungskonfiguration über Blobs, Warteschlangen und/oder Tabellen hinweg verwendet werden soll. Der URI kann nur den Blob-Dienst festlegen. Alternativ können Sie einen URI speziell für jeden Dienst bereitstellen, sodass eine einzelne Verbindung verwendet werden kann. Wenn beide Versionen bereitgestellt werden, wird das Format für mehrere Dienste verwendet. Um die Verbindung für mehrere Dienste anstelle von <CONNECTION_NAME_PREFIX>__serviceUri zu konfigurieren, legen Sie Folgendes fest:

Eigenschaft	Vorlage für Umgebungsvariable	BESCHREIBUNG	Beispielwert
Blob-Dienst-URI	<CONNECTION_NAME_PREFIX>__blobServiceUri	Der URI der Datenebene des Blob-Dienstes, mit dem Sie sich mithilfe des HTTPS-Schemas verbinden.	https://<storage_account_name>.blob.core.windows.net
URI des Warteschlangendiensts (für Blobtrigger2 erforderlich)	<CONNECTION_NAME_PREFIX>__queueServiceUri	Der Datenebenen-URI eines Warteschlangendiensts unter Verwendung des HTTPS-Schemas. Dieser Wert wird nur für Blobtrigger benötigt.	https://<Speicherkontoname>.queue.core.windows.net

² Fehler bei mehreren erneuten Versuchen werden vom Blobtrigger durch Schreiben nicht verarbeitbarer Blobs in eine Warteschlange behandelt. Im serviceUri-Formular wird die AzureWebJobsStorage-Verbindung verwendet. Beim Angeben von blobServiceUri muss jedoch auch ein Warteschlangendienst-URI mit queueServiceUri bereitgestellt werden. Es wird empfohlen, den Dienst von demselben Speicherkonto aus zu verwenden wie den Blob-Dienst. Sie müssen ebenfalls sicherstellen, dass der Trigger Nachrichten im konfigurierten Warteschlangendienst lesen und schreiben kann, indem Sie eine Rolle wie Mitwirkender für Storage-Warteschlangendaten zuweisen.

Andere Eigenschaften können festgelegt werden, um die Verbindung anzupassen. Weitere Informationen finden Sie unter Allgemeine Eigenschaften für identitätsbasierte Verbindungen.

Identitätsbasierte Verbindungen verwenden eine verwaltete Identität, wenn sie im Azure Functions-Dienst gehostet werden. Standardmäßig wird eine vom System zugewiesene Identität verwendet, auch wenn mit den Eigenschaften credential und clientID eine vom Benutzer zugewiesene Identität angegeben werden kann. Beachten Sie, dass das Konfigurieren einer benutzerseitig zugewiesenen Identität mit einer Ressourcen-ID nicht unterstützt wird. Bei Ausführung in anderen Kontexten (z. B. bei der lokalen Entwicklung) wird stattdessen Ihre Entwickleridentität verwendet, Dieses Verhalten kann angepasst werden. Weitere Informationen finden Sie unter Lokale Entwicklung mit identitätsbasierten Verbindungen.

Erteilen der Berechtigung für die Identität

Unabhängig davon, welche Identität verwendet wird, muss diese über Berechtigungen zum Ausführen der vorgesehenen Aktionen verfügen. Daher müssen Sie für die meisten Azure-Dienste eine Rolle in Azure RBAC zuweisen, indem Sie entweder integrierte oder benutzerdefinierte Rollen verwenden, die diese Berechtigungen bieten.

Wichtig

Vom Zieldienst werden möglicherweise einige nicht für alle Kontexte erforderliche Berechtigungen verfügbar gemacht. Befolgen Sie nach Möglichkeit das Prinzip der geringsten Berechtigung, und gewähren Sie der Identität nur die erforderlichen Berechtigungen. Wenn die App beispielsweise nur Daten aus einer Datenquelle lesen muss, verwenden Sie eine Rolle, die nur über Leseberechtigungen verfügt. Es wäre nicht angemessen, eine Rolle zu zuweisen, die auch das Schreiben in diesen Dienst zulässt, da dies eine übermäßige Berechtigung für einen Lesevorgang wäre. Ebenso sollten Sie sicherstellen, dass die Rollenzuweisung auf die Ressourcen begrenzt ist, die gelesen werden müssen.

Sie müssen eine Rollenzuweisung erstellen, die zur Laufzeit Zugriff auf Ihren Blob-Container ermöglicht. Verwaltungsrollen wie Besitzer sind nicht ausreichend. Die folgende Tabelle zeigt integrierte Rollen, die für den normalen Betrieb mit der Blob Storage-Erweiterung empfohlen werden. Ihre Anwendung erfordert möglicherweise weitere Berechtigungen basierend auf dem von Ihnen geschriebenen Code.

Bindungstyp	Integrierte Beispielrollen
Trigger	Besitzer von Speicherblobdaten und Mitwirkender an Speicherabfragedaten1 Außerdem müssen der AzureWebJobsStorage-Verbindung zusätzliche Berechtigungen erteilt werden.2
Eingabebindung	Leser von Speicherblobdaten
Ausgabebindung	Besitzer von Speicherblobdaten

¹ Fehler bei mehreren erneuten Versuchen werden vom Blobtrigger durch Schreiben nicht verarbeitbarer Blobs in eine Warteschlange für das durch die Verbindung angegebene Speicherkonto behandelt.

² Die AzureWebJobsStorage-Verbindung wird intern für Blobs und Warteschlangen verwendet, die den Trigger aktivieren. Wenn die Verwendung einer identitätsbasierten Verbindung konfiguriert ist, sind zusätzliche Berechtigungen erforderlich, die über die Standardanforderung hinausgehen. Die erforderlichen Berechtigungen werden durch die Rollen Besitzer von Storage-Blobdaten, Mitwirkender für Storage-Warteschlangendaten und Speicherkontomitwirkender abgedeckt. Weitere Informationen finden Sie unter Herstellen einer Verbindung mit dem Hostspeicher mit einer Identität.

Blobnamensmuster

Ein Blobnamensmuster kann in der Eigenschaft path (in path) oder im Konstruktor des Attributs BlobTrigger angegeben werden. Das Namensmuster kann ein Filter oder Bindungsausdruck sein. Die folgenden Abschnitte enthalten einige Beispiele.

Tipp

Ein Containername darf keine Auflösung im Namensmuster enthalten.

Abrufen von Dateiname und Erweiterung

Das folgende Beispiel zeigt, wie Sie den Blobdateinamen und die Erweiterung separat binden:

"path": "input/{blobname}.{blobextension}",

Wenn das Blob original-Blob1.txt heißt, lauten die Werte der Variablen blobname und blobextension im Funktionscode original-Blob1 und txt.

Filtern nach Blobname

Im folgenden Beispiel wird der Trigger nur für Blobs im Container input ausgelöst, deren Name mit „original-“ beginnt:

"path": "input/original-{name}",

Wenn der Blobname original-Blob1.txt lautet, hat die Variable name im Funktionscode den Wert Blob1.txt.

Filtern nach Dateityp

Im folgenden Beispiel wird der Trigger nur für PNG-Dateien ausgelöst:

"path": "samples/{name}.png",

Filtern nach geschweiften Klammern in Dateinamen

Wenn in Dateinamen nach geschweiften Klammern gesucht werden soll, müssen doppelte Klammern verwendet werden. Im folgenden Beispiel wird nach Blobs gefiltert, deren Name geschweifte Klammern enthält:

"path": "images/{{20140101}}-{name}",

Wenn der Blobname {20140101}-soundfile.mp3 lautet, erhält die Variable name im Funktionscode den Wert soundfile.mp3.

Abfrage und Latenz

Der Abruf funktioniert als Kombination aus dem Überprüfen von Protokollen und dem Ausführen regelmäßiger Containerscans. Blobs werden jeweils in Gruppen von 10.000 gescannt, wobei zwischen den Intervallen ein Fortsetzungstoken verwendet wird. Wenn Ihre Funktions-App im Verbrauchsplan enthalten ist, kann es möglicherweise bis zu 10 Minuten dauern, bis neue Blobs verarbeitet werden, nachdem eine Funktionen-App in den Leerlauf gewechselt ist.

Warnung

Das Erstellen von Storage-Protokollen erfolgt auf bestmögliche Weise. Es gibt keine Garantie, dass alle Ereignisse erfasst werden. Unter bestimmten Umständen können Protokolle fehlen.

Wenn Sie eine schnellere oder zuverlässigere Blob-Verarbeitung benötigen, sollten Sie das Hosting wechseln, um einen App Service-Plan mit aktivierter Always On-Funktion zu verwenden, was zu höheren Kosten führen kann. Sie können auch einen anderen Trigger als den klassischen Abruf-BLOB-Trigger verwenden. Weitere Informationen und einen Vergleich der verschiedenen Triggeroptionen für Blob-Speichercontainer finden Sie unter Trigger für einen BLOB-Container.

BLOB-Zugänge

Die Azure Functions-Runtime stellt sicher, dass Blobtriggerfunktionen für ein neues oder aktualisiertes Blob nicht mehrmals aufgerufen werden. Zu diesem Zweck wird mittels Verwaltung der Blobbelege ermittelt, ob eine bestimmte Blobversion verarbeitet wurde.

Azure Functions speichert Blobbelege in einem Container mit dem Namen azure-webjobs-hosts im Azure Storage-Konto für Ihre Funktions-App (per App-Einstellung AzureWebJobsStorage definiert). Ein Blobbeleg enthält die folgenden Informationen:

• Die ausgelöste Funktion (<FUNCTION_APP_NAME>.Functions.<FUNCTION_NAME>, z. B. MyFunctionApp.Functions.CopyBlob)
• Containername
• Der Blobtyp (BlockBlob oder PageBlob)
• Blobname
• Das ETag (ein Blobversionsbezeichner, z. B. 0x8D1DC6E70A277EF)

Um eine erneute Verarbeitung eines Blobs zu erzwingen, können Sie den Blobbeleg für dieses Blob manuell aus dem Container azure-webjobs-hosts löschen. Auch wenn eine erneute Verarbeitung eventuell nicht sofort ausgeführt wird, erfolgt sie doch garantiert zu einem späteren Zeitpunkt. Für eine sofortige erneute Verarbeitung kann das ScanInfo-Blob in azure-webjobs-hosts/blobscaninfo aktualisiert werden. Alle Blobs mit einem Zeitstempel der letzten Änderung, der nach der LatestScan-Eigenschaft liegt, werden erneut überprüft.

Nicht verarbeitbare Blobs

Wenn bei Ausführung einer Blobtriggerfunktion für ein bestimmtes Blob ein Fehler auftritt, versucht Azure Functions standardmäßig bis zu fünfmal, diese Funktion auszuführen.

Wenn bei allen fünf Versuchen Fehler auftreten, fügt Azure Functions der Storage-Warteschlange webjobs-blobtrigger-poison eine Nachricht hinzu. Die maximale Anzahl von Wiederholungen ist konfigurierbar. Für die Verarbeitung nicht verarbeitbarer Blobs und der dazugehörigen Nachrichtenwarteschlange wird die gleiche MaxDequeueCount-Einstellung verwendet. Die Warteschlangennachricht für nicht verarbeitbare Blobs ist ein JSON-Objekt, das die folgenden Eigenschaften enthält:

• FunctionId (im Format <FUNCTION_APP_NAME>.Functions.<FUNCTION_NAME>)
• BlobType (BlockBlob oder PageBlob)
• ContainerName
• BlobName
• ETag (ein Blobversionsbezeichner, z. B. 0x8D1DC6E70A277EF)

Arbeitsspeicherauslastung und Parallelität

Wenn Sie eine Bindung an einen Ausgabetyp erstellen, der das Streaming nicht unterstützt, z string. B. oder Byte[], muss die Laufzeit das gesamte BLOB während der Verarbeitung mehrmals in den Arbeitsspeicher laden. Dies kann zu einer höheren als erwarteten Speicherauslastung bei der Verarbeitung von Blobs führen. Verwenden Sie nach Möglichkeit einen streamgestützten Typ. Die Typunterstützung hängt vom C#-Modus und der Erweiterungsversion ab. Weitere Informationen finden Sie unter Bindungstypen.

Zurzeit muss die Laufzeit das gesamte BLOB während der Verarbeitung mehrmals in den Arbeitsspeicher laden. Dies kann zu einer höheren als erwarteten Speicherauslastung bei der Verarbeitung von Blobs führen.

Die Speicherauslastung kann weiter beeinträchtigt werden, wenn mehrere Funktionsinstanzen blob-Daten gleichzeitig verarbeiten. Wenn Arbeitsspeicherprobleme mit einem BLOB-Trigger auftreten, sollten Sie die Anzahl der zulässigen gleichzeitigen Ausführungen verringern. Die Reduzierung der Parallelität kann natürlich die Nebenwirkung haben, indem der Backlog von Blobs erhöht wird, die auf die Verarbeitung warten. Die Speicherbeschränkungen Ihrer Funktions-App hängen vom Plan ab. Weitere Informationen finden Sie unter Diensteinschränkungen.

Die Art und Weise, wie Sie die Anzahl der gleichzeitigen Ausführungen steuern können, hängt von der Version der verwendeten Speichererweiterung ab.

Erweiterung 5.x und höher

Bei Verwendung von Version 5.0.0 der Speichererweiterung oder einer höheren Version steuern Sie die Parallelität mithilfe der maxDegreeOfParallelism Einstellung in der Blobs-Konfiguration in host.json.

Vorerweiterung 5.x

Da der Blobtrigger intern eine Warteschlange verwendet, wird die maximale Anzahl gleichzeitiger Funktionsaufrufe durch die Konfiguration der Warteschlangen in host.json gesteuert.

Grenzwerte gelten separat für jede Funktion, die einen Blobtrigger verwendet.

Eigenschaften von „host.json“

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

Nächste Schritte

• Lesen von Blob Storage-Daten, wenn eine Funktion ausgeführt wird
• Schreiben von Blob Storage-Daten aus einer Funktion