Partage via

Déclencheur Stockage Blob Azure pour Azure Functions

  • Article

Le déclencheur de stockage Blob démarre une fonction lors de la détection d’un objet blob nouveau ou mis à jour. Le contenu du blob est fourni comme entrée de la fonction.

Conseil

Il existe plusieurs façons d’exécuter votre code de fonction selon les modifications apportées aux objets blob dans un conteneur de stockage. Si vous choisissez d’utiliser le déclencheur de stockage Blob, notez qu’il existe deux implémentations proposées : une implémentation basée sur une interrogation (référencée dans cet article) et une implémentation basée sur des événements. Il est recommandé d’utiliser l’implémentation basée sur les événements, car elle a une latence inférieure à l’autre. En outre, le plan Flex Consumption prend uniquement en charge le déclencheur de stockage Blob basé sur les événements.

Pour plus d’informations sur les différences entre les deux implémentations du déclencheur de stockage d’objets blob, ainsi que d’autres options de déclenchement, consultez Utilisation des objets blob.

Pour plus d’informations sur les détails d’installation et de configuration, consultez la vue d’ensemble.

Important

Cet article utilise des onglets pour prendre en charge plusieurs versions du modèle de programmation Node.js. Le modèle v4 est en disponibilité générale. Il est conçu pour offrir une expérience plus flexible et intuitive aux développeurs JavaScript et TypeScript. Pour plus d’informations sur le fonctionnement du modèle v4, reportez-vous au guide du développeur Azure Functions Node.js. Pour plus d’informations sur les différences entre v3 et v4, consultez le guide de migration.

Azure Functions prend en charge deux modèles de programmation pour Python. La façon dont vous définissez vos liaisons dépend du modèle de programmation choisi.

Le modèle de programmation Python v2 vous permet de définir des liaisons à l'aide d’éléments décoratifs directement dans le code de votre fonction Python. Pour plus d’informations, consultez le guide des développeurs Python.

Cet article prend en compte les deux modèles de programmation.

Exemple

Une fonction C# peut être créée à l’aide de l’un des modes C# suivants :

  • Modèle worker isolé : fonction C# compilée exécutée dans un processus worker isolé du runtime. Le processus Worker isolé est requis pour prendre en charge les fonctions C# exécutées sur les versions LTS et non-LTS de .NET et de .NET Framework. Les extensions pour les fonctions de processus de travail isolés utilisent des espaces de noms Microsoft.Azure.Functions.Worker.Extensions.*.
  • Modèle In-process : fonction C# compilée exécutée dans le même processus que le runtime Functions. Dans une variation de ce modèle, Functions peut être exécuté à l’aide de scripts C#, principalement pris en charge pour la modification du portail C#. Les extensions pour les fonctions in-process utilisent des espaces de noms Microsoft.Azure.WebJobs.Extensions.*.

Important

La prise en charge du modèle in-process prendra fin le 10 novembre 2026. Pour continuer à bénéficier d’une prise en charge complète, nous vous recommandons vivement de migrer vos applications vers le modèle worker isolé.

L’exemple suivant est une fonction C# qui s’exécute dans un processus worker isolé et utilise un déclencheur Blob avec des liaisons blob en entrée et en sortie. La fonction est déclenchée par la création d’un objet blob dans le conteneur test-samples-trigger. Elle lit un fichier texte à partir du conteneur test-samples-input et crée un nouveau fichier texte dans un conteneur de sortie en fonction du nom du fichier déclenché.

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

Cette fonction enregistre un journal lorsqu’un objet blob est ajouté ou mis à jour dans le conteneur myblob.

@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’exemple suivant montre le code TypeScript d’un déclencheur d’objet blob. La fonction écrit un journal lorsqu’un objet blob est ajouté ou mis à jour dans le conteneur samples-workitems.

La chaîne {name} dans le chemin d’accès du déclencheur d’objet blob samples-workitems/{name} crée une {name} que vous pouvez utiliser dans le code de fonction pour accéder au nom de fichier de l’objet blob déclencheur. Pour plus d’informations, consultez la section Modèles de nom d’objet blob dans la suite de cet article.

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’exemple suivant montre le code JavaScript d’un déclencheur d’objet blob. La fonction écrit un journal lorsqu’un objet blob est ajouté ou mis à jour dans le conteneur samples-workitems.

La chaîne {name} dans le chemin d’accès du déclencheur d’objet blob samples-workitems/{name} crée une {name} que vous pouvez utiliser dans le code de fonction pour accéder au nom de fichier de l’objet blob déclencheur. Pour plus d’informations, consultez la section Modèles de nom d’objet blob dans la suite de cet article.

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

L’exemple suivant montre comment créer une fonction qui s’exécute lorsqu’un fichier est ajouté au conteneur de stockage BLOB source.

Le fichier config de la fonction (function.json) comprend une liaison avec le type de blobTrigger et direction défini sur in.

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

Voici le code associé pour le fichier run.ps1.

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

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

Cet exemple utilise des types de SDK pour accéder directement à l’objet sous-jacent BlobClient fourni par le déclencheur de stockage 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)}"
    )

Pour obtenir des exemples d’utilisation d’autres types de SDK, consultez les exemples et StorageStreamDownloader les ContainerClient exemples.

Pour en savoir plus, notamment sur l’activation des liaisons de type sdk dans votre projet, consultez les liaisons de type sdk.

Cet exemple enregistre des informations à partir des métadonnées d’objet blob entrantes.

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

Attributs

Les bibliothèques C# in-process et de processus worker isolés utilisent l’attribut BlobAttribute pour définir la fonction. Le script C# utilise à la place un fichier de configuration function.json comme décrit dans le guide de script C#.

Le constructeur de l’attribut accepte les paramètres suivants :

Paramètre Description
BlobPath Chemin de l’objet blob.
Connection Nom d’un paramètre d’application ou d’une collection de paramètres d’application qui spécifie la façon de se connecter à des objets blob Azure. Consultez Connexions.
y accéder Indique si vous lirez ou écrirez.
Source Définit la source de l’événement de déclenchement. Utilisez BlobTriggerSource.EventGrid pour un déclencheur d’objet blob basé sur Event Grid qui offre une latence beaucoup plus faible. La valeur par défaut est BlobTriggerSource.LogsAndContainerScan, ce qui signifie que le mécanisme d’interrogation standard est utilisé pour détecter les modifications dans le conteneur.

Voici un attribut BlobTrigger dans une signature de méthode :

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

Lorsque vous développez en local, ajoutez vos paramètres d’application dans le fichier local.settings.json de la collection Values.

Décorateurs

S’applique uniquement au modèle de programmation Python v2.

Pour les fonctions Python v2 définies à l’aide de décorateurs, les propriétés suivantes du décorateur blob_trigger définissent le déclencheur Stockage Blob :

Propriété Description
arg_name Déclare le nom du paramètre dans la signature de la fonction. Quand la fonction est déclenchée, la valeur de ce paramètre a le contenu du message de la file d’attente.
path Conteneur à superviser. Peut être un modèle de nom d’objet blob.
connection La chaîne de connexion de compte de stockage.
source Définit la source de l’événement de déclenchement. Utilisez EventGrid pour un déclencheur d’objet blob basé sur Event Grid qui offre une latence beaucoup plus faible. La valeur par défaut est LogsAndContainerScan, ce qui signifie que le mécanisme d’interrogation standard est utilisé pour détecter les modifications dans le conteneur.

Pour les fonctions Python définies à l’aide de function.json, consultez la section Configuration.

Annotations

L'attribut @BlobTrigger est utilisé pour vous permettre d’accéder à l’objet blob qui a déclenché la fonction. Reportez-vous à l’exemple de déclencheur pour plus d'informations. Utilisez la propriété source pour définir la source de l’événement de déclenchement. Utilisez EventGrid pour un déclencheur d’objet blob basé sur Event Grid qui offre une latence beaucoup plus faible. La valeur par défaut est LogsAndContainerScan, ce qui signifie que le mécanisme d’interrogation standard est utilisé pour détecter les modifications dans le conteneur. |

Configuration

S’applique uniquement au modèle de programmation Python v1.

Le tableau suivant explique les propriétés que vous pouvez définir pour l’objet options passé à la méthode app.storageBlob().

Propriété Description
path Conteneur à superviser. Peut être un modèle de nom d’objet blob.
connection Nom d’un paramètre d’application ou d’une collection de paramètres d’application qui spécifie la façon de se connecter à des objets blob Azure. Consultez Connexions.
source Définit la source de l’événement de déclenchement. Utilisez EventGrid pour un déclencheur d’objet blob basé sur Event Grid qui offre une latence beaucoup plus faible. La valeur par défaut est LogsAndContainerScan, ce qui signifie que le mécanisme d’interrogation standard est utilisé pour détecter les modifications dans le conteneur.

Le tableau suivant décrit les propriétés de configuration de liaison que vous définissez dans le fichier function.json.

Propriété function.json Description
type Cette propriété doit être définie sur blobTrigger. Cette propriété est définie automatiquement lorsque vous créez le déclencheur dans le portail Azure.
direction Cette propriété doit être définie sur in. Cette propriété est définie automatiquement lorsque vous créez le déclencheur dans le portail Azure. Les exceptions sont notées à la section utilisation.
name Nom de la variable qui représente l’objet blob dans le code de la fonction.
path Conteneur à superviser. Peut être un modèle de nom d’objet blob.
connection Nom d’un paramètre d’application ou d’une collection de paramètres d’application qui spécifie la façon de se connecter à des objets blob Azure. Consultez Connexions.
source Définit la source de l’événement de déclenchement. Utilisez EventGrid pour un déclencheur d’objet blob basé sur Event Grid qui offre une latence beaucoup plus faible. La valeur par défaut est LogsAndContainerScan, ce qui signifie que le mécanisme d’interrogation standard est utilisé pour détecter les modifications dans le conteneur.

Pour obtenir des exemples complets, consultez la section Exemple.

Métadonnées

Le déclencheur d’objet blob fournit plusieurs propriétés de métadonnées. Ces propriétés peuvent être utilisées dans les expressions de liaison dans d’autres liaisons ou en tant que paramètres dans votre code. Ces valeurs ont la même sémantique que le type CloudBlob.

Propriété Type Description
BlobTrigger string Chemin de l’objet blob déclencheur.
Uri System.Uri URI de l’objet blob pour l’emplacement principal.
Properties BlobProperties Propriétés système de l’objet blob.
Metadata IDictionary<string,string> Métadonnées définies par l’utilisateur pour l’objet blob.

L’exemple suivant consigne le chemin d’accès au blob déclencheur, y compris le conteneur :

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

Métadonnées

Le déclencheur d’objet blob fournit plusieurs propriétés de métadonnées. Ces propriétés peuvent être utilisées dans les expressions de liaison dans d’autres liaisons ou en tant que paramètres dans votre code.

Propriété Description
blobTrigger Chemin de l’objet blob déclencheur.
uri URI de l’objet blob pour l’emplacement principal.
properties Propriétés système de l’objet blob.
metadata Métadonnées définies par l’utilisateur pour l’objet blob.

Les métadonnées peuvent être obtenues à partir de la propriété triggerMetadata de l’objet context fourni, comme illustré dans l’exemple suivant, qui consigne le chemin d’accès au blob déclencheur (blobTrigger), y compris le conteneur :

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

Métadonnées

Les métadonnées sont disponibles via le paramètre $TriggerMetadata.

Utilisation

Les types de liaisons pris en charge par le déclencheur blob dépendent de la version du package d’extension et de la modalité C# utilisée dans votre application de fonction.

Le déclencheur d’objet blob peut être lié aux types suivants :

Type Description
string Contenu de l’objet blob en tant que chaîne. À utiliser quand le contenu de l’objet blob est un texte simple.
byte[] Octets du contenu de l’objet blob.
Types sérialisables JSON Quand un objet blob contient des données JSON, Functions tente de désérialiser les données JSON dans un type d’objet POCO (Plain-Old CLR Object).
Stream1 Flux d’entrée du contenu de l’objet blob.
BlobClient1,
BlockBlobClient1,
PageBlobClient1,
AppendBlobClient1,
BlobBaseClient1		 Client connecté à l’objet blob. Cet ensemble de types offre le meilleur contrôle pour le traitement de l’objet blob et peut être utilisé pour réécrire dans celui-ci, si la connexion dispose des autorisations suffisantes.

1 Pour utiliser ces types, vous devez référencer Microsoft.Azure.Functions.Worker.Extensions.Storage.Blobs 6.0.0 ou version ultérieure et les dépendances courantes pour les liaisons de type kit de développement logiciel (SDK).

La liaison avec string ou Byte[] n’est recommandée que lorsque l’objet Blob est de petite taille. Cette recommandation est d’application, car l’ensemble du contenu des objets Blob est chargé dans la mémoire. Pour la plupart des objets Blob, utilisez un type Stream ou BlobClient. Pour plus d’informations, consultez Concurrence et utilisation de la mémoire.

Si un message d'erreur s’affiche lorsque vous essayez d’effectuer la liaison à un des types de SDK Stockage, vérifiez que vous avez une référence à la bonne version du SDK Stockage.

Vous pouvez également utiliser StorageAccountAttribute pour spécifier le compte de stockage à utiliser. Vous pouvez le faire lorsque vous avez besoin d’utiliser un compte de stockage différent de celui utilisé par les autres fonctions de la bibliothèque. Le constructeur prend le nom d’un paramètre d’application comportant une chaîne de connexion de stockage. L’attribut peut être appliqué au niveau du paramètre, de la méthode ou de la classe. L’exemple suivant montre le niveau de la classe et celui de la méthode :

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

Le compte de stockage à utiliser est déterminé dans l’ordre suivant :

  • La propriété Connection de l’attribut BlobTrigger.
  • L’attribut StorageAccount appliqué au même paramètre que l’attribut BlobTrigger.
  • L’attribut StorageAccount appliqué à la fonction.
  • L’attribut StorageAccount appliqué à la classe.
  • Compte de stockage par défaut pour l’application de fonction, lequel est défini dans le paramètre d’application AzureWebJobsStorage.

L'attribut @BlobTrigger est utilisé pour vous permettre d’accéder à l’objet blob qui a déclenché la fonction. Reportez-vous à l’exemple de déclencheur pour plus d'informations.

Utilisez le premier argument de votre fonction pour accéder aux données des objets blob.

Accédez aux données BLOB via un paramètre qui correspond au nom désigné par le paramètre Nom de la liaison dans le fichier function.json.

Accédez aux données blob via le paramètre de type InputStream. Reportez-vous à l’exemple de déclencheur pour plus d'informations.

Functions prend également en charge les liaisons de types de sdk Python pour le stockage Blob Azure, ce qui vous permet d’utiliser les données blob à l’aide de ces types de SDK sous-jacents :

Important

La prise en charge des types sdk pour Python est actuellement en préversion et est prise en charge uniquement pour le modèle de programmation Python v2. Pour plus d’informations, consultez les types de SDK dans Python.

Connexions

La propriété connection est une référence à la configuration de l’environnement qui spécifie la façon dont l’application doit se connecter aux blobs Azure. Elle peut spécifier :

Si la valeur configurée est à la fois une correspondance exacte pour un paramètre unique et une correspondance de préfixe pour d’autres paramètres, la correspondance exacte est utilisée.

Chaîne de connexion

Pour obtenir une chaîne de connexion, suivez les étapes indiquées à la section Gérer les clés d’accès au compte de stockage. La chaîne de connexion doit être destinée à un compte de stockage à usage général, et non pas à un compte Stockage Blob.

Cette chaîne de connexion doit être stockée dans un paramètre d’application dont le nom correspond à la valeur spécifiée par la propriété connection de la configuration de liaison.

Si le nom du paramètre d’application commence par « AzureWebJobs », vous ne pouvez spécifier que le reste du nom ici. Par exemple, si vous définissez connection sur « MyStorage », le runtime Functions recherche un paramètre d’application nommé « AzureWebJobsMyStorage ». Si vous laissez connection vide, le runtime Functions utilise la chaîne de connexion de stockage par défaut dans le paramètre d’application nommé AzureWebJobsStorage.

Connexions basées sur l’identité

Si vous utilisez la version 5.x ou ultérieure de l’extension (bundle 3.x ou version ultérieure pour les piles linguistiques non-.NET), au lieu d’utiliser un chaîne de connexion avec un secret, vous pouvez faire en sorte que l’application utilise une identité Microsoft Entra. Pour utiliser une identité, vous devez définir les paramètres sous un préfixe commun qui correspond à la propriété connection dans le déclencheur et la configuration de liaison.

Si vous définissez connection sur « AzureWebJobsStorage », consultez la section Connexion au stockage hôte avec une identité. Pour toutes les autres connexions, l’extension nécessite les propriétés suivantes :

Propriété Modèle de variable d’environnement Description Valeur d'exemple
URI du service blob <CONNECTION_NAME_PREFIX>__serviceUri1 URI du plan de données du service blob auquel vous vous connectez, à l’aide du même schéma HTTPS. https://<storage_account_name>.blob.core.windows.net

1 <CONNECTION_NAME_PREFIX>__blobServiceUri peut être utilisé comme alias. Si la configuration de la connexion sera utilisée par un déclencheur d’objet Blob, blobServiceUri doit également être accompagné de queueServiceUri. Voir ci-dessous.

La forme serviceUri ne peut pas être utilisée lorsque la configuration globale de la connexion doit être utilisée sur des objets blob, des files d’attente et/ou des tables. L’URI ne peut désigner que le service d’objets blob. Vous pouvez également fournir un URI spécifique pour chaque service, en autorisant l’utilisation d’une connexion unique. Si les deux versions sont fournies, la forme à plusieurs services est utilisée. Pour configurer la connexion pour plusieurs services, au lieu de <CONNECTION_NAME_PREFIX>__serviceUri, définissez :

Propriété Modèle de variable d’environnement Description Valeur d'exemple
URI du service blob <CONNECTION_NAME_PREFIX>__blobServiceUri URI du plan de données du service blob auquel vous vous connectez, à l’aide du même schéma HTTPS. https://<storage_account_name>.blob.core.windows.net
URI de service de file d’attente (requis pour les déclencheurs Blob2) <CONNECTION_NAME_PREFIX>__queueServiceUri URI du plan de données d’un service de file d’attente, à l’aide du schéma HTTPS. Cette valeur est requise uniquement pour les déclencheurs d’objets Blob. https://<storage_account_name>.queue.core.windows.net

2 Le déclencheur d’objet Blob gère les échecs entre plusieurs tentatives en écrivant des objets Blob incohérents dans une file d’attente. Dans la forme serviceUri, la connexion AzureWebJobsStorage est utilisée. Toutefois, lorsque vous spécifiez blobServiceUri, un URI de service de file d’attente doit également être fourni avec queueServiceUri. Il est recommandé d’utiliser le service à partir du même compte de stockage que le service d’objets blob. Vous devez également vous assurer que le déclencheur peut lire et écrire des messages dans le service de file d’attente configuré en affectant un rôle comme Contributeur aux données en file d’attente du stockage.

D’autres propriétés peuvent être définies pour personnaliser la connexion. Consultez Propriétés communes pour les connexions basées sur l’identité.

Quand elles sont hébergées dans le service Azure Functions, les connexions basées sur une identité utilisent une identité managée. L’identité attribuée par le système est utilisée par défaut, bien qu’une identité attribuée par l’utilisateur puisse être spécifiée avec les propriétés credential et clientID. Notez que la configuration d’une identité affectée par l’utilisateur avec un ID de ressource n’est pas prise en charge. Lors d’une exécution dans d’autres contextes, tels que le développement local, votre identité de développeur est utilisée à la place, même si cela peut être personnalisé. Consultez Développement local avec connexions basées sur une identité.

Accorder l’autorisation à l’identité

Quelle que soit l’identité utilisée, elle doit avoir les autorisations nécessaires pour effectuer les actions prévues. Pour la plupart des services Azure, cela signifie que vous devez attribuer un rôle dans Azure RBAC en utilisant des rôles intégrés ou personnalisés qui fournissent ces autorisations.

Important

Parmi les autorisations exposées par le service cible, certaines ne sont peut-être pas nécessaires pour tous les contextes. Dans la mesure du possible, adhérez au principe du privilège minimum, en accordant à l’identité uniquement les privilèges nécessaires. Par exemple, si l’application a juste besoin de pouvoir lire à partir d’une source de données, utilisez un rôle qui a uniquement l’autorisation de lecture. Il serait inapproprié d’attribuer un rôle qui autorise aussi l’écriture dans ce service, car ce serait une autorisation excessive pour une opération de lecture. De même, vous voudrez vous assurer que l’attribution de rôle est limitée aux seules ressources qui doivent être lues.

Vous devez créer une attribution de rôle qui donne accès à votre conteneur de blobs au moment de l’exécution. Les rôles de gestion comme Propriétaire ne sont pas suffisants. Le tableau suivant présente les rôles intégrés qui sont recommandés lors de l’utilisation de l’extension Stockage Blob dans le cadre d’un fonctionnement normal. Il est possible que votre application nécessite des autorisations supplémentaires en fonction du code que vous écrivez.

Type de liaison Exemples de rôles intégrés
Déclencheur Propriétaire des données Blob de stockage et Contributeuraux données de file d’attente de stockage 1

Des autorisations supplémentaires doivent également être accordées à la connexion AzureWebJobsStorage.2
Liaison d’entrée Lecteur des données blob du stockage
Liaison de sortie Propriétaire des données Blob du stockage

1 Le déclencheur Blob gère l’échec sur plusieurs tentatives en écrivant des blobs incohérents dans une file d’attente sur le compte de stockage spécifié par la connexion.

2 La connexion AzureWebJobsStorage est utilisée en interne pour les blobs et les files d’attente qui activent le déclencheur. Si elle est configurée de manière à utiliser une connexion basée sur une identité, elle a besoin d’autorisations supplémentaires au-delà de la spécification par défaut. Ces autorisations requises sont couvertes par les rôles Propriétaire des données Blob du stockage, Contributeur aux données en file d’attente du stockage et Contributeur de compte de stockage. Pour en savoir plus, consultez Connexion au stockage hôte avec une identité.

Modèles de nom de blob

Vous pouvez spécifier un modèle de nom d’objet blob dans la propriété path du fichier path ou dans le constructeur d’attribut BlobTrigger. Le modèle de nom peut être une expression de filtre ou de liaison. Les sections suivantes fournissent des exemples.

Conseil

Un nom de conteneur ne peut pas contenir de programme de résolution dans le modèle de nom.

Obtenir l’extension et le nom de fichier

L’exemple suivant montre comment se lier séparément à l’extension et au nom de fichier de l’objet blob :

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

Si l’objet blob est nommé original-Blob1.txt, les valeurs des variables blobname et blobextension dans le code de la fonction sont original-Blob1 et txt.

Filtrer sur le nom de l’objet blob

L’exemple suivant déclenche uniquement sur les objets blob du conteneur input qui commencent par la chaîne « original- » :

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

Si le nom de l’objet blob est original-Blob1.txt, la valeur de la variable name dans le code de la fonction est Blob1.txt.

Filtrer sur le type de fichier

L’exemple suivant ne déclenche que sur des fichiers .png :

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

Filtrer sur les accolades dans les noms de fichiers

Pour rechercher les accolades dans les noms de fichiers, utilisez une séquence d’échappement sous la forme de deux accolades. L’exemple suivant filtre en recherchant les objets blob qui contiennent des accolades dans le nom :

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

Si l’objet blob est nommé {20140101}-soundfile.mp3, la valeur de la variable name dans le code de la fonction est soundfile.mp3.

Interrogation et latence

L’interrogation fonctionne de façon hybride entre l’inspection des journaux et l’exécution d’analyses régulières des conteneurs. Les objets blob sont analysés dans des groupes de 10 000 à la fois avec un jeton de continuation utilisé entre les intervalles. Si votre application de fonction est dans le plan Consommation, il peut y avoir jusqu’à 10 minutes de délai dans le traitement des nouveaux objets blob si une application de fonction est devenue inactive.

Avertissement

Les journaux de stockage sont créés selon le principe du « meilleur effort ». Il n’existe aucune garantie que tous les événements sont capturés. Dans certaines conditions, des journaux d’activité peuvent être omis.

Si vous avez besoin d’un traitement d’objets blob plus rapide ou plus fiable, vous devez envisager de changer votre hébergement pour utiliser un plan App Service avec Always On activé, ce qui peut entraîner une augmentation des coûts. Vous pouvez également envisager d’utiliser un déclencheur autre que le déclencheur d’objet blob d’interrogation classique. Pour plus d’informations et une comparaison des différentes options de déclenchement pour les conteneurs de stockage d’objets blob, consultez Déclencheur sur un conteneur d’objets blob.

Reçus d’objets blob

Le runtime Azure Functions vérifie qu’aucune fonction de déclencheur d’objet blob n’est appelée plusieurs fois pour un même objet blob, nouveau ou mis à jour. Pour déterminer si la version d’un objet blob donné a été traitée, il gère des reçus d’objet blob.

Azure Functions stocke les reçus d’objet blob dans un conteneur appelé azure-webjobs-hosts dans le compte de stockage Azure de votre application de fonction (définie par le paramètre d’application AzureWebJobsStorage). Un reçu d’objet blob contient les informations suivantes :

  • Fonction déclenchée (<FUNCTION_APP_NAME>.Functions.<FUNCTION_NAME>, par exemple : MyFunctionApp.Functions.CopyBlob)
  • Nom du conteneur
  • Type de blob (BlockBlob ou PageBlob)
  • Nom de l’objet blob
  • Étiquette d’entité (identificateur de la version du BLOB, par exemple : 0x8D1DC6E70A277EF)

Pour forcer le retraitement d’un objet blob, supprimez manuellement le reçu de l’objet blob du conteneur azure-webjobs-hosts. Si le retraitement n’a pas lieu immédiatement, il se produira ultérieurement. Pour effectuer un retraitement immédiatement, le blob ScanInfo dans azure-webjobs-hosts/blobscaninfo peut être mis à jour. Les blobs ayant un timestamp de dernière modification après la propriété LatestScan sont à nouveau analysés.

Blobs incohérents

En cas d’échec d’une fonction de déclencheur pour un blob donné, Azure Functions réessaie cette fonction jusqu’à cinq fois par défaut.

Si les 5 tentatives échouent, Azure Functions ajoute un message à une file d’attente de stockage nommée webjobs-blobtrigger-poison. Vous pouvez configurer le nombre maximal de tentatives. Le paramètre MaxDequeueCount est utilisé à la fois pour la gestion des objets blob incohérents et pour l’administration des messages de la file d’attente de messages incohérents. Le message en file d’attente associé aux objets blob incohérents correspond à un objet JSON, qui contient les propriétés suivantes :

  • FunctionId (au format <FUNCTION_APP_NAME>.Functions.<FUNCTION_NAME>)
  • BlobType (BlockBlob ou PageBlob)
  • ContainerName
  • BlobName
  • ETag (identificateur de la version du BLOB, par exemple : 0x8D1DC6E70A277EF)

Utilisation de la mémoire et concurrence

Lorsque vous effectuez une liaison à un type de sortie qui ne prend pas en charge la diffusion en continu, par stringexemple, ou Byte[]que le runtime doit charger l’intégralité de l’objet blob en mémoire plusieurs fois pendant le traitement. Cela peut entraîner une utilisation de mémoire plus élevée que prévu lors du traitement des objets blob. Si possible, utilisez un type de prise en charge de flux. La prise en charge du type dépend du mode C# et de la version de l’extension. Pour plus d’informations, consultez Types de liaison.

À ce stade, le runtime doit charger l’intégralité de l’objet blob en mémoire plusieurs fois pendant le traitement. Cela peut entraîner une utilisation de mémoire plus élevée que prévu lors du traitement des objets blob.

L’utilisation de la mémoire peut être davantage affectée lorsque plusieurs instances de fonction traitent simultanément les données d’objet blob. Si vous rencontrez des problèmes de mémoire à l’aide d’un déclencheur d’objet blob, envisagez de réduire le nombre d’exécutions simultanées autorisées. Bien sûr, la réduction de l’accès concurrentiel peut avoir l’effet secondaire de l’augmentation du backlog des objets blob en attente de traitement. Les limites de mémoire de votre application de fonction dépendent du plan. Pour plus d’informations, consultez Limites du Service.

La façon dont vous pouvez contrôler le nombre d’exécutions simultanées dépend de la version de l’extension de stockage que vous utilisez.

Lorsque vous utilisez la version 5.0.0 de l’extension de stockage ou une version ultérieure, vous contrôlez la concurrence du déclencheur à l’aide du paramètre dans la maxDegreeOfParallelism configuration des objets blob dans host.json.

Les limites s’appliquent séparément à chaque fonction qui utilise un déclencheur d’objet blob.

Propriétés host.json

Le fichier host.json contient les paramètres qui contrôlent le comportement du déclencheur de blob. Consultez la section Paramètres host.json pour plus d’informations concernant les paramètres disponibles.

Étapes suivantes