Condividi tramite

Trigger di Archiviazione BLOB di Azure per Funzioni di Azure

  • Articolo

Il trigger di archiviazione BLOB avvia una funzione quando viene rilevato un BLOB nuovo o aggiornato. Il contenuto del BLOB viene fornito come input per la funzione.

Suggerimento

Esistono diversi modi per eseguire il codice della funzione in base alle modifiche apportate ai BLOB in un contenitore di archiviazione. Se si sceglie di usare il trigger di archiviazione BLOB, si noti che sono disponibili due implementazioni: una basata sul polling (a cui si fa riferimento in questo articolo) e una basata su eventi. È consigliabile usare l'implementazione basata su eventi perché ha una latenza inferiore rispetto all'altra. Inoltre, il piano Flex Consumption supporta solo il trigger di archiviazione BLOB basato su eventi.

Per informazioni dettagliate sulle differenze tra le due implementazioni del trigger di archiviazione BLOB e altre opzioni di attivazione, vedere Uso dei BLOB.

Per informazioni sui dettagli di impostazione e configurazione, vedere la panoramica.

Importante

Questo articolo usa schede per supportare le versioni diverse del modello di programmazione Node.js. Il modello v4 è disponibile a livello generale ed è progettato per offrire un'esperienza più flessibile e intuitiva per gli sviluppatori JavaScript e TypeScript. Per altre informazioni sul funzionamento del modello v4, vedere la guida per gli sviluppatori di Node.js per Funzioni di Azure. Altre informazioni sulle differenze tra i modelli v3 e v4 sono disponibili nella guida alla migrazione.

Funzioni di Azure supporta due modelli di programmazione per Python. Il modo in cui si definiscono le associazioni dipende dal modello di programmazione scelto.

Il modello di programmazione Python v2 consente di definire associazioni usando elementi Decorator direttamente nel codice della funzione Python. Per altre informazioni, vedere la Guida per sviluppatori Python.

Questo articolo supporta entrambi i modelli di programmazione.

Esempio

È possibile creare una funzione C# usando una delle modalità C# seguenti:

  • Modello di lavoro isolato: funzione C# compilata eseguita in un processo di lavoro isolato dal runtime. Il processo di lavoro isolato è necessario per supportare le funzioni C# in esecuzione in LTS e versioni non LTS .NET e .NET Framework. Le estensioni per le funzioni del processo di lavoro isolato usano Microsoft.Azure.Functions.Worker.Extensions.* spazi dei nomi.
  • Modello in-process: funzione C# compilata eseguita nello stesso processo del runtime di Funzioni. In una variante di questo modello, le funzioni possono essere eseguite usando script C#, che è supportato principalmente per la modifica del portale C#. Le estensioni per le funzioni in-process usano Microsoft.Azure.WebJobs.Extensions.* spazi dei nomi.

Importante

Il supporto terminerà per il modello in-process il 10 novembre 2026. È consigliabile eseguire la migrazione delle app al modello di lavoro isolato per il supporto completo.

L'esempio seguente è una funzione C# che viene eseguita in un processo di lavoro isolato e usa un trigger BLOB con associazioni BLOB di input e BLOB di output BLOB. La funzione viene attivata dalla creazione di un BLOB nel contenitore test-samples-trigger . Legge un file di testo dal contenitore test-samples-input e crea un nuovo file di testo in un contenitore di output in base al nome del file attivato.

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

Questa funzione scrive un log quando un BLOB viene aggiunto o aggiornato nel myblob contenitore.

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

L'esempio seguente mostra un codice TypeScript del trigger BLOB. La funzione scrive un log quando viene aggiunto o aggiornato un BLOB nel contenitore samples-workitems.

La stringa {name} nel percorso del trigger di BLOB samples-workitems/{name} crea un'espressione di associazione che può essere usata nel codice della funzione per accedere al nome file del BLOB di attivazione. Per altre informazioni, vedere Modelli di nome dei BLOB più avanti in questo articolo.

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

L'esempio seguente mostra un codice JavaScript trigger BLOB. La funzione scrive un log quando viene aggiunto o aggiornato un BLOB nel contenitore samples-workitems.

La stringa {name} nel percorso del trigger di BLOB samples-workitems/{name} crea un'espressione di associazione che può essere usata nel codice della funzione per accedere al nome file del BLOB di attivazione. Per altre informazioni, vedere Modelli di nome dei BLOB più avanti in questo articolo.

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

Nell'esempio seguente viene illustrato come creare una funzione eseguita quando un file viene aggiunto al source contenitore di archiviazione BLOB.

Il file di configurazione della funzione (function.json) include un'associazione blobTrigger type con e direction impostata su in.

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

Ecco il codice associato per il file run.ps1 .

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

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

Questo esempio usa i tipi SDK per accedere direttamente all'oggetto sottostante BlobClient fornito dal trigger di archiviazione BLOB:

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

Per esempi di uso di altri tipi di SDK, vedere gli ContainerClient esempi e StorageStreamDownloader .

Per altre informazioni, tra cui come abilitare le associazioni dei tipi di SDK nel progetto, vedere Associazioni dei tipi di SDK.

Questo esempio registra le informazioni dai metadati del BLOB in ingresso.

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")

Attributi

Sia le librerie C# in-process che il processo di lavoro isolato usano l'attributo BlobAttribute per definire la funzione. Lo script C# usa invece un file di configurazione function.json come descritto nella guida per gli script C#.

Il costruttore dell'attributo accetta i parametri seguenti:

Parametro Descrizione
BlobPath Percorso del BLOB.
Connessione Nome di un'impostazione o di una raccolta di impostazioni dell'app che specifica come connettersi ai BLOB di Azure. Vedere Connessioni.
Accesso Indica se eseguire la lettura o la scrittura.
Origine Imposta l'origine dell'evento di attivazione. Usare BlobTriggerSource.EventGrid per un trigger BLOB basato su Griglia di eventi, che offre una latenza molto inferiore. Il valore predefinito è BlobTriggerSource.LogsAndContainerScan, che usa il meccanismo di polling standard per rilevare le modifiche nel contenitore.

Di seguito è mostrato un attributo BlobTrigger in una firma del metodo:

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

Quando si sviluppa in locale, aggiungere le impostazioni dell'applicazione nel file local.settings.json nella Values raccolta.

Elementi Decorator

Si applica solo al modello di programmazione Python v2.

Per le funzioni Python v2 definite tramite decorator, le proprietà seguenti nell'elemento blob_trigger Decorator definiscono il trigger di archiviazione BLOB:

Proprietà Descrizione
arg_name Dichiara il nome del parametro nella firma della funzione. Quando la funzione viene attivata, il valore di questo parametro contiene il contenuto del messaggio della coda.
path Contenitore da monitorare. Può essere un modello di nome per il BLOB.
connection La stringa di connessione dell'account di archiviazione.
source Imposta l'origine dell'evento di attivazione. Usare EventGrid per un trigger BLOB basato su Griglia di eventi, che offre una latenza molto inferiore. Il valore predefinito è LogsAndContainerScan, che usa il meccanismo di polling standard per rilevare le modifiche nel contenitore.

Per le funzioni Python definite tramite function.json, vedere la sezione Configurazione .

Annotazioni

L'attributo @BlobTrigger viene usato per concedere l'accesso al BLOB che ha attivato la funzione. Per informazioni dettagliate, vedere l'esempio di trigger. Utilizzare la source proprietà per impostare l'origine dell'evento di attivazione. Usare EventGrid per un trigger BLOB basato su Griglia di eventi, che offre una latenza molto inferiore. Il valore predefinito è LogsAndContainerScan, che usa il meccanismo di polling standard per rilevare le modifiche nel contenitore. |

Impostazione

Si applica solo al modello di programmazione Python v1.

Nella tabella seguente vengono illustrate le proprietà che è possibile impostare sull'oggetto options passato al app.storageBlob() metodo .

Proprietà Descrizione
path Contenitore da monitorare. Può essere un modello di nome per il BLOB.
connection Nome di un'impostazione o di una raccolta di impostazioni dell'app che specifica come connettersi ai BLOB di Azure. Vedere Connessioni.
source Imposta l'origine dell'evento di attivazione. Usare EventGrid per un trigger BLOB basato su Griglia di eventi, che offre una latenza molto inferiore. Il valore predefinito è LogsAndContainerScan, che usa il meccanismo di polling standard per rilevare le modifiche nel contenitore.

Nella tabella seguente sono illustrate le proprietà di configurazione dell'associazione impostate nel file function.json.

Proprietà di function.json Descrizione
type Deve essere impostato su blobTrigger. Questa proprietà viene impostata automaticamente quando si crea il trigger nel portale di Azure.
direction Deve essere impostato su in. Questa proprietà viene impostata automaticamente quando si crea il trigger nel portale di Azure. Le eccezioni sono indicate nella sezione usage.
name Nome della variabile che rappresenta il BLOB nel codice della funzione.
path Contenitore da monitorare. Può essere un modello di nome per il BLOB.
connection Nome di un'impostazione o di una raccolta di impostazioni dell'app che specifica come connettersi ai BLOB di Azure. Vedere Connessioni.
source Imposta l'origine dell'evento di attivazione. Usare EventGrid per un trigger BLOB basato su Griglia di eventi, che offre una latenza molto inferiore. Il valore predefinito è LogsAndContainerScan, che usa il meccanismo di polling standard per rilevare le modifiche nel contenitore.

Per esempi completi, vedere la sezione di esempio.

Metadati UFX

Il trigger del BLOB contiene diverse proprietà di metadati. Queste proprietà possono essere usate come parte delle espressioni di associazione in altre associazioni o come parametri nel codice. Questi valori hanno la stessa semantica del tipo CloudBlob .

Proprietà Type Descrizione
BlobTrigger string Percorso del BLOB trigger.
Uri System.Uri L'URI del BLOB per la posizione primaria.
Properties BlobProperties Le proprietà di sistema del BLOB.
Metadata IDictionary<string,string> I metadati definiti dall'utente per il BLOB.

L'esempio seguente registra il percorso del BLOB di attivazione, incluso il contenitore:

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

Metadati UFX

Il trigger del BLOB contiene diverse proprietà di metadati. Queste proprietà possono essere usate come parte delle espressioni di associazione in altre associazioni o come parametri nel codice.

Proprietà Descrizione
blobTrigger Percorso del BLOB trigger.
uri L'URI del BLOB per la posizione primaria.
properties Le proprietà di sistema del BLOB.
metadata I metadati definiti dall'utente per il BLOB.

I metadati possono essere ottenuti dalla triggerMetadata proprietà dell'oggetto fornito context , come illustrato nell'esempio seguente, che registra il percorso del BLOB di attivazione (blobTrigger), incluso il contenitore:

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

Metadati UFX

I metadati sono disponibili tramite il $TriggerMetadata parametro .

Utilizzo

I tipi di associazione supportati dal trigger BLOB dipendono dalla versione del pacchetto di estensione e dalla modalità C# usata nell'app per le funzioni.

Il trigger BLOB può essere associato ai tipi seguenti:

Tipo Descrizione
string Contenuto del BLOB come stringa. Usare quando il contenuto del BLOB è testo semplice.
byte[] Byte del contenuto del BLOB.
Tipi serializzabili JSON Quando un BLOB contiene dati JSON, Funzioni tenta di deserializzare i dati JSON in un tipo POCO (Plain-Old CLR Object).
Flusso1 Flusso di input del contenuto del BLOB.
BlobClient1,
BlockBlobClient1,
PageBlobClient1,
AppendBlobClient1,
BlobBaseClient1		 Un client connesso al BLOB. Questo set di tipi offre il maggior controllo per l'elaborazione del BLOB e può essere usato per eseguire il writeback nel BLOB se la connessione dispone di autorizzazioni sufficienti.

1 Per usare questi tipi, è necessario fare riferimento a Microsoft.Azure.Functions.Worker.Extensions.Storage.Blobs 6.0.0 o versione successiva e alle dipendenze comuni per le associazioni di tipi SDK.

L'associazione a stringo Byte[] è consigliata solo quando le dimensioni del BLOB sono ridotte. Questa operazione è consigliata perché l'intero contenuto del BLOB viene caricato in memoria. Per la maggior parte dei BLOB, usare un Stream tipo o BlobClient . Per altre informazioni, vedere Concorrenza e utilizzo della memoria.

Se viene visualizzato un messaggio di errore quando si tenta di eseguire l'associazione a uno dei tipi di Storage SDK, assicurarsi di avere un riferimento alla versione corretta di Storage SDK.

È anche possibile usare StorageAccountAttribute per specificare l'account di archiviazione da usare. Questa operazione può essere eseguita quando è necessario usare un account di archiviazione diverso da altre funzioni della libreria. Il costruttore accetta il nome di un'impostazione dell'app che contiene una stringa di connessione di archiviazione. L'attributo può essere applicato a livello di parametro, metodo o classe. L'esempio seguente illustra il livello classe e il livello metodo:

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

L'account di archiviazione da usare è determinato nell'ordine seguente:

  • La proprietà Connection dell'attributo BlobTrigger.
  • L'attributo StorageAccount applicato allo stesso parametro dell'attributo BlobTrigger.
  • L'attributo StorageAccount applicato alla funzione.
  • L'attributo StorageAccount applicato alla classe.
  • L'account di archiviazione predefinito per l'app per le funzioni, definito nell'impostazione dell'applicazione AzureWebJobsStorage .

L'attributo @BlobTrigger viene usato per concedere l'accesso al BLOB che ha attivato la funzione. Per informazioni dettagliate, vedere l'esempio di trigger.

Accedere ai dati BLOB come primo argomento alla funzione.

Accedere ai dati DEL BLOB tramite un parametro che corrisponde al nome designato dal parametro name dell'associazione nel file function.json .

Accedere ai dati BLOB tramite il parametro digitato come InputStream. Per informazioni dettagliate, vedere l'esempio di trigger.

Funzioni supporta anche i binding dei tipi di PYTHON SDK per l'archiviazione BLOB di Azure, che consente di usare i dati BLOB usando questi tipi di SDK sottostanti:

Importante

Il supporto dei tipi SDK per Python è attualmente disponibile in anteprima ed è supportato solo per il modello di programmazione Python v2. Per altre informazioni, vedere Tipi di SDK in Python.

Connessioni

La connection proprietà è un riferimento alla configurazione dell'ambiente che specifica come l'app deve connettersi ai BLOB di Azure. Può specificare:

Se il valore configurato è sia una corrispondenza esatta per una singola impostazione che una corrispondenza di prefisso per altre impostazioni, viene usata la corrispondenza esatta.

Stringa di connessione

Per ottenere una stringa di connessione, seguire la procedura descritta in Gestire le chiavi di accesso dell’account di archiviazione. La stringa di connessione deve essere relativa a un account di archiviazione di uso generico, non a un account di archiviazione BLOB.

Questo stringa di connessione deve essere archiviato in un'impostazione dell'applicazione con un nome corrispondente al valore specificato dalla connection proprietà della configurazione dell'associazione.

Se il nome dell'impostazione dell'app inizia con "AzureWebJobs", è possibile specificare solo il resto del nome. Ad esempio, se si imposta connection su "MyStorage", il runtime di Funzioni cerca un'impostazione dell'app denominata "AzureWebJobsMyStorage". Se si lascia vuoto connection, il runtime di Funzioni di Azure usa la stringa di connessione di archiviazione predefinita nell'impostazione dell'app denominata AzureWebJobsStorage.

Connessioni basate su identità

Se si usa la versione 5.x o successiva dell'estensione (bundle 3.x o versione successiva per gli stack di linguaggi non-.NET), anziché usare un stringa di connessione con un segreto, è possibile che l'app usi un'identità di Microsoft Entra. Per usare un'identità, definire le impostazioni con un prefisso comune che esegue il connection mapping alla proprietà nella configurazione del trigger e dell'associazione.

Se si imposta connection su "AzureWebJobsStorage", vedere Connessione all'archiviazione host con un'identità. Per tutte le altre connessioni, l'estensione richiede le proprietà seguenti:

Proprietà Modello di variabile di ambiente Descrizione Valore di esempio
URI del servizio BLOB <CONNECTION_NAME_PREFIX>__serviceUri1 URI del piano dati del servizio BLOB a cui ci si connette usando lo schema HTTPS. https://<storage_account_name>.blob.core.windows.net

1 <CONNECTION_NAME_PREFIX>__blobServiceUri può essere usato come alias. Se la configurazione della connessione verrà usata da un trigger BLOB, blobServiceUri deve essere accompagnata anche da queueServiceUri. Vedere di seguito.

Il serviceUri modulo non può essere usato quando la configurazione di connessione complessiva deve essere usata tra BLOB, code e/o tabelle. L'URI può designare solo il servizio BLOB. In alternativa, è possibile fornire un URI specifico per ogni servizio, consentendo l'uso di una singola connessione. Se vengono fornite entrambe le versioni, viene utilizzato il modulo multiservizio. Per configurare la connessione per più servizi, invece di <CONNECTION_NAME_PREFIX>__serviceUri, impostare:

Proprietà Modello di variabile di ambiente Descrizione Valore di esempio
URI del servizio BLOB <CONNECTION_NAME_PREFIX>__blobServiceUri URI del piano dati del servizio BLOB a cui ci si connette usando lo schema HTTPS. https://<storage_account_name>.blob.core.windows.net
URI del servizio di accodamento (obbligatorio per itrigger BLOB 2) <CONNECTION_NAME_PREFIX>__queueServiceUri URI del piano dati di un servizio di accodamento, usando lo schema HTTPS. Questo valore è necessario solo per i trigger BLOB. https://<storage_account_name>.queue.core.windows.net

2 Il trigger blob gestisce l'errore tra più tentativi scrivendo BLOB non elaborabili in una coda. serviceUri Nel modulo viene utilizzata la AzureWebJobsStorage connessione. Tuttavia, quando si specifica , è necessario specificare blobServiceUrianche un URI del servizio di accodamento con queueServiceUri. È consigliabile usare il servizio dallo stesso account di archiviazione del servizio BLOB. È anche necessario assicurarsi che il trigger possa leggere e scrivere messaggi nel servizio di accodamento configurato assegnando un ruolo come Collaboratore ai dati della coda di archiviazione.

È possibile impostare altre proprietà per personalizzare la connessione. Vedere Proprietà comuni per le connessioni basate su identità.

Quando sono ospitate nel servizio Azure Functions, le connessioni basate su identità usano una identità gestita. Per impostazione predefinita, viene usata l’identità assegnata a livello di sistema, ma è comunque possibile specificare un’identità assegnata dall’utente a cui siano associate le proprietà credential e clientID. Si noti che la configurazione di un'identità assegnata dall'utente con un ID risorsa non è supportata. Quando viene eseguita in altri contesti, ad esempio lo sviluppo locale, viene usata l'identità dello sviluppatore, anche se può essere personalizzata. Vedere Sviluppo locale con connessioni basate su identità.

Concedere l'autorizzazione all'identità

Qualsiasi identità usata deve avere le autorizzazioni necessarie per eseguire le azioni previste. Per la maggior parte dei servizi di Azure, questo significa che è necessario assegnare un ruolo nel controllo degli accessi in base al ruolo di Azure, usando ruoli predefiniti o personalizzati che forniscono tali autorizzazioni.

Importante

È possibile che alcune autorizzazioni esposte dal servizio di destinazione non siano necessarie per tutti i contesti. Laddove possibile, rispettare il principio dei privilegi minimi e concedere all’identità solo i privilegi necessari. Ad esempio, se l'app deve essere in grado di leggere solo da un'origine dati, usare un ruolo che disponga solo dell'autorizzazione per la lettura. Sarebbe inappropriato assegnare un ruolo che consenta anche la scrittura in tale servizio, in quanto sarebbe eccessiva l'autorizzazione per un'operazione di lettura. Analogamente, è consigliabile assicurarsi che l'assegnazione di ruolo sia con ambito solo sulle risorse che devono essere lette.

È necessario creare un'assegnazione di ruolo che fornisca l'accesso al contenitore BLOB in fase di esecuzione. I ruoli di gestione come Proprietario non sono sufficienti. Nella tabella seguente vengono illustrati i ruoli predefiniti consigliati quando si usa l'estensione Archiviazione BLOB in condizioni di normale funzionamento. L'applicazione potrebbe richiedere ulteriori autorizzazioni in base al codice scritto.

Tipo di associazione Ruoli predefiniti di esempio
Trigger Proprietario dei dati del BLOB di archiviazione e Collaboratore ai dati della coda di archiviazione1

È necessario concedere autorizzazioni aggiuntive anche alla connessione AzureWebJobsStorage.2
Associazione di input Lettore dei dati del BLOB di archiviazione
Associazione di output Proprietario dei dati del BLOB di archiviazione

1 Il trigger BLOB gestisce l'errore tra più tentativi scrivendo BLOB non elaborabili in una coda nell'account di archiviazione specificato dalla connessione.

2 La connessione AzureWebJobsStorage viene usata internamente per BLOB e code che abilitano il trigger. Se è configurato per l'uso di una connessione basata su identità, sono necessarie autorizzazioni aggiuntive oltre il requisito predefinito. Le autorizzazioni necessarie sono coperte dai ruoli Proprietario dei dati del BLOB di archiviazione, Collaboratore ai dati della coda di archiviazione e Collaboratore dell'account di archiviazione. Per altre informazioni, vedere Connessione all'archiviazione host con un'identità.

Modelli di nome BLOB

È possibile specificare un modello di nome di BLOB nella proprietà path in function.json o nel costruttore dell'attributo BlobTrigger. Il modello di nome può essere un'espressione di filtro o di associazione. Le sezioni seguenti forniscono esempi.

Suggerimento

Un nome di contenitore non può contenere un resolver nel modello di nome.

Ottenere l'estensione e il nome del file

L'esempio seguente illustra come associare il nome e l'estensione del file BLOB separatamente:

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

Se il BLOB è denominato original-Blob1.txt, i valori delle variabili blobname e blobextension nel codice della funzione saranno original-Blob1 e txt.

Filtrare in base al nome del BLOB

L'esempio seguente attiva un trigger solo per i BLOB nel contenitore input che iniziano con la stringa "original-":

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

Se il nome del BLOB è original-Blob1.txt, il valore della variabile name nel codice della funzione sarà Blob1.txt.

Filtrare in base al tipo di file

L'esempio seguente attiva un trigger solo per i file con estensione png:

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

Filtrare in base alle parentesi graffe nei nomi dei file

Per cercare le parentesi graffe nei nomi dei file, raddoppiare le parentesi graffe per eseguirne l'escape. L'esempio seguente filtra i BLOB che contengono parentesi graffe nel nome:

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

Se il BLOB è denominato {20140101}-soundfile.mp3, il valore della variabile name nel codice della funzione sarà soundfile.mp3.

Polling e latenza

Il polling funziona come ibrido tra l'ispezione dei log e l'esecuzione di analisi periodiche dei contenitori. I BLOB vengono analizzati in gruppi di 10.000 alla volta con un token di continuazione usato tra intervalli. Se l'app per le funzioni è inclusa nel piano a consumo, è possibile che si verifichi un ritardo di un massimo di 10 minuti per l'elaborazione di nuovi BLOB in caso di inattività di un'app per le funzioni.

Avviso

I log di archiviazione vengono creati su base "best effort". Non è garantito che tutti gli eventi vengano acquisiti. In alcune condizioni, l'acquisizione dei log può non riuscire.

Se è necessaria un'elaborazione BLOB più veloce o affidabile, è consigliabile passare all'hosting per usare un piano di servizio app con Always On abilitato, con conseguente aumento dei costi. È anche possibile prendere in considerazione l'uso di un trigger diverso dal trigger BLOB di polling classico. Per altre informazioni e un confronto delle varie opzioni di attivazione per i contenitori di archiviazione BLOB, vedere Trigger in un contenitore BLOB.

Conferme di BLOB

Il runtime di Funzioni di Azure verifica che nessuna funzione trigger di BLOB venga chiamata più volte per lo stesso BLOB nuovo o aggiornato. Gestisce conferme di BLOB per determinare se una versione di BLOB specifica è stata elaborata.

Funzioni di Azure archivia le conferme di BLOB in un contenitore denominato azure-webjobs-hosts nell'account di archiviazione di Azure per l'app per le funzioni, specificato dall'impostazione app AzureWebJobsStorage. Una conferma di BLOB contiene le seguenti informazioni:

  • Funzione attivata (<FUNCTION_APP_NAME>.Functions.<FUNCTION_NAME>ad esempio: MyFunctionApp.Functions.CopyBlob)
  • Il nome del contenitore
  • Tipo di BLOB (BlockBlob o PageBlob)
  • Il nome del BLOB
  • ETag (identificatore di versione del BLOB, ad esempio: 0x8D1DC6E70A277EF)

Per forzare la rielaborazione di un BLOB è possibile eliminare manualmente la conferma del BLOB dal contenitore azure-webjobs-hosts. Anche se la rielaborazione potrebbe non verificarsi immediatamente, è garantito che si verifichi in un secondo momento. Per rielaborare immediatamente, è possibile aggiornare il BLOB scaninfo in azure-webjobs-hosts/blobscaninfo . Tutti i BLOB con un timestamp dell'ultima modifica dopo che la LatestScan proprietà verrà analizzata di nuovo.

BLOB non elaborabili

Quando una funzione trigger BLOB ha esito negativo per un determinato BLOB, Funzioni di Azure ritenta che funzionano per impostazione predefinita per un totale di cinque volte.

Se tutti i 5 tentativi non riescono, Funzioni di Azure aggiunge un messaggio a una coda di archiviazione denominata webjobs-blobtrigger-poison. Il numero massimo di tentativi è configurabile. La stessa impostazione MaxDequeueCount viene usata per la gestione dei BLOB non elaborabili e per la gestione dei messaggi della coda non elaborabile. Il messaggio di coda per i BLOB non elaborabili è un oggetto JSON che contiene le seguenti proprietà:

  • FunctionId (nel formato <FUNCTION_APP_NAME>.Functions.<FUNCTION_NAME>)
  • BlobType (BlockBlob o PageBlob)
  • ContainerName
  • BlobName
  • ETag (identificatore di versione del BLOB, ad esempio: 0x8D1DC6E70A277EF)

Utilizzo e concorrenza della memoria

Quando si esegue l'associazione a un tipo di output che non supporta lo streaming, ad esempio string, o Byte[], il runtime deve caricare l'intero BLOB in memoria più di una volta durante l'elaborazione. Ciò può comportare un utilizzo di memoria superiore al previsto durante l'elaborazione dei BLOB. Quando possibile, usare un tipo di supporto del flusso. Il supporto dei tipi dipende dalla modalità C# e dalla versione dell'estensione. Per altre informazioni, vedere Tipi di associazione.

Al momento, il runtime deve caricare l'intero BLOB in memoria più di una volta durante l'elaborazione. Ciò può comportare un utilizzo di memoria superiore al previsto durante l'elaborazione dei BLOB.

L'utilizzo della memoria può essere ulteriormente influenzato quando più istanze di funzione elaborano contemporaneamente i dati BLOB. Se si verificano problemi di memoria usando un trigger BLOB, è consigliabile ridurre il numero di esecuzioni simultanee consentite. Naturalmente, la riduzione della concorrenza può avere l'effetto collaterale dell'aumento del backlog dei BLOB in attesa di elaborazione. I limiti di memoria dell'app per le funzioni dipendono dal piano. Per altre informazioni, vedere Limiti del servizio.

Il modo in cui è possibile controllare il numero di esecuzioni simultanee dipende dalla versione dell'estensione di archiviazione in uso.

Quando si usa la versione 5.0.0 dell'estensione di archiviazione o una versione successiva, è possibile controllare la concorrenza dei trigger usando l'impostazione maxDegreeOfParallelism nella configurazione dei BLOB in host.json.

I limiti si applicano separatamente a ogni funzione che usa un trigger BLOB.

Proprietà di host.json

Il file host.json contiene impostazioni che controllano il comportamento del trigger BLOB. Per informazioni dettagliate sulle impostazioni disponibili, vedere la sezione impostazioni host.json .

Passaggi successivi