Partager via

Informations de référence pour les développeurs de scripts C# (.csx) Azure Functions

  • Article

Cet article est une introduction au développement d’Azure Functions à l’aide de scripts C# ( .csx).

Important

Le script C# est pris en charge principalement pour fournir une expérience pratique dans le portail pour vous aider à commencer rapidement à créer et à exécuter des fonctions C#. Pour les applications de qualité de production, vous devez développer vos fonctions C# localement en tant que projet de bibliothèque de classes C# compilé. Pour savoir comment migrer un projet de script C# vers un projet de bibliothèque de classes C# (worker isolé), consultez Convertir une application de script C# en projet C#.

Azure Functions vous permet de développer des fonctions à l’aide de C# de l’une des façons suivantes :

Type Processus d’exécution Extension de code Environnement de développement Informations de référence
Script C# in-process .csx Portail
Core Tools		 Cet article
Bibliothèque de classes C# (worker isolé) processus Worker isolé .cs Visual Studio
Visual Studio Code
Core Tools		 Fonctions de processus Worker isolés .NET
Bibliothèque de classes C# (in-process) in-process .cs Visual Studio
Visual Studio Code
Core Tools		 Fonctions de la bibliothèque de classes C# In-process

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é.

Fonctionnement de .csx

Les données circulent dans votre fonction C# via des arguments de méthode. Les noms d’argument sont spécifiés dans un fichier function.json, et il existe des noms prédéfinis pour accéder à des éléments tels que l’enregistreur de fonctions et les jetons d’annulation.

Le format .csx vous permet d’écrire de façon moins « réutilisable » et de vous concentrer uniquement sur l’écriture d’une fonction C#. Au lieu de tout encapsuler dans un espace de noms et une classe, définissez simplement une méthode Run. Ajoutez les éventuels références d’assemblys et espaces de noms au début du fichier, comme d’habitude.

Les fichiers .csx d’une application de fonction sont compilés quand une instance est initialisée. Cette étape de compilation signifie que des opérations telles qu’un démarrage à froid peuvent être plus longues à effectuer pour les fonctions de script C# par rapport aux bibliothèques de classes C#. C’est également la raison pour laquelle les fonctions de script C# sont modifiables dans le Portail Azure, alors que les bibliothèques de classes C# ne le sont pas.

Structure de dossiers

La structure de dossiers pour un projet de script C# est similaire à l’exemple suivant :

FunctionsProject
 | - MyFirstFunction
 | | - run.csx
 | | - function.json
 | | - function.proj
 | - MySecondFunction
 | | - run.csx
 | | - function.json
 | | - function.proj
 | - host.json
 | - extensions.csproj
 | - bin

Il existe un fichier host.json partagé que vous pouvez utiliser pour configurer l’application de fonction. Chaque fonction a son propre fichier de code (.csx) et un fichier de configuration de liaison (function.json).

Les extensions de liaison nécessaires dans la version 2.x et ultérieure du runtime Functions sont définies dans le fichier extensions.csproj, les fichiers de bibliothèque proprement dits se trouvant dans le dossier bin. Quand vous développez localement, vous devez inscrire les extensions de liaison. Quand vous développez des fonctions dans le Portail Azure, cet inscription est effectuée pour vous.

Liaison aux arguments

Les données d’entrée ou de sortie sont liées à un paramètre de fonction de script C# via la propriété name du fichier de configuration function.json. L’exemple suivant montre un fichier function.json et un fichier run.csx pour une fonction déclenchée par une file d’attente. Le paramètre qui reçoit les données du message de file d’attente s’appelle myQueueItem, car il s’agit de la valeur de la propriété name.

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

#r "Microsoft.WindowsAzure.Storage"

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

public static void Run(CloudQueueMessage myQueueItem, ILogger log)
{
    log.LogInformation($"C# Queue trigger function processed: {myQueueItem.AsString}");
}

L’instruction #r est expliquée plus loin dans cet article.

Types pris en charge pour les liaisons

Chaque liaison possède ses propres types pris en charge. Par exemple, un déclencheur d’objet blob peut être utilisé avec un paramètre de chaîne, un paramètre OCT, un paramètre CloudBlockBlob ou l’un des autres types pris en charge. L’article sur les références de liaison pour les liaisons d’objets blob répertorie tous les types de paramètre pris en charge pour les déclencheurs d’objet blob. Pour plus d’informations, consultez Déclencheurs et liaisons, ainsi que les documents sur les références de liaison pour chaque type de liaison.

Conseil

Si vous envisagez d’utiliser les liaisons HTTP ou WebHook, prévoyez d’éviter l’épuisement du port qui peut résulter d’une instanciation incorrecte de HttpClient. Pour plus d’informations, consultez How to manage connections in Azure Functions (Comment gérer des connexions dans Azure Functions).

Référencement de classes personnalisées

Si vous souhaitez utiliser une classe d’objet CLR traditionnel (OCT) personnalisée, vous pouvez inclure la définition de classe dans le même fichier ou la placer dans un fichier distinct.

L’exemple de fichier run.csx suivant inclut une définition de classe OCT.

public static void Run(string myBlob, out MyClass myQueueItem)
{
    log.Verbose($"C# Blob trigger function processed: {myBlob}");
    myQueueItem = new MyClass() { Id = "myid" };
}

public class MyClass
{
    public string Id { get; set; }
}

Des méthodes getter et setter doivent être définies pour chaque propriété d’une classe OCT.

Réutilisation du code .csx

Vous pouvez utiliser des classes et des méthodes définies dans d’autres fichiers .csx au sein de votre fichier run.csx. Pour ce faire, utilisez les directives #load dans votre fichier run.csx. Dans l’exemple suivant, une routine de journalisation nommée MyLogger est partagée dans myLogger.csx et chargés dans run.csx à l’aide de la directive#load :

Exemple run.csx:

#load "mylogger.csx"

using Microsoft.Extensions.Logging;

public static void Run(TimerInfo myTimer, ILogger log)
{
    log.LogInformation($"Log by run.csx: {DateTime.Now}");
    MyLogger(log, $"Log by MyLogger: {DateTime.Now}");
}

Exemple mylogger.csx:

public static void MyLogger(ILogger log, string logtext)
{
    log.LogInformation(logtext);
}

L’utilisation d’un fichier .csx partagé est un cas de figure courant quand vous souhaitez typer fortement les données transmises entre les fonctions à l’aide d’un objet OCT. Dans l’exemple simplifié suivant, un déclencheur HTTP et un déclencheur de file d’attente partagent un objet OCT nommé Order pour typer fortement les données de commande :

Exemple avec run.csx pour un déclencheur HTTP :

#load "..\shared\order.csx"

using System.Net;
using Microsoft.Extensions.Logging;

public static async Task<HttpResponseMessage> Run(Order req, IAsyncCollector<Order> outputQueueItem, ILogger log)
{
    log.LogInformation("C# HTTP trigger function received an order.");
    log.LogInformation(req.ToString());
    log.LogInformation("Submitting to processing queue.");

    if (req.orderId == null)
    {
        return new HttpResponseMessage(HttpStatusCode.BadRequest);
    }
    else
    {
        await outputQueueItem.AddAsync(req);
        return new HttpResponseMessage(HttpStatusCode.OK);
    }
}

Exemple avec run.csx pour un déclencheur de file d’attente :

#load "..\shared\order.csx"

using System;
using Microsoft.Extensions.Logging;

public static void Run(Order myQueueItem, out Order outputQueueItem, ILogger log)
{
    log.LogInformation($"C# Queue trigger function processed order...");
    log.LogInformation(myQueueItem.ToString());

    outputQueueItem = myQueueItem;
}

Exemple avec order.csx :

public class Order
{
    public string orderId {get; set; }
    public string custName {get; set;}
    public string custAddress {get; set;}
    public string custEmail {get; set;}
    public string cartId {get; set; }

    public override String ToString()
    {
        return "\n{\n\torderId : " + orderId +
                  "\n\tcustName : " + custName +
                  "\n\tcustAddress : " + custAddress +
                  "\n\tcustEmail : " + custEmail +
                  "\n\tcartId : " + cartId + "\n}";
    }
}

Vous pouvez utiliser un chemin d’accès relatif avec la directive #load :

  • #load "mylogger.csx" charge un fichier situé dans le dossier de la fonction.
  • #load "loadedfiles\mylogger.csx" charge un fichier situé dans un dossier du dossier de la fonction.
  • #load "..\shared\mylogger.csx" charge un fichier situé dans un dossier situé au même niveau que le dossier de la fonction, c’est-à-dire directement sous wwwroot.

La directive #load ne fonctionne qu’avec des fichiers .csx, et non avec des fichiers .cs.

Liaison à une valeur renvoyée par la méthode

Vous pouvez utiliser une valeur renvoyée par la méthode pour une liaison de sortie, en utilisant le nom $return dans function.json.

{
    "name": "$return",
    "type": "blob",
    "direction": "out",
    "path": "output-container/{id}"
}

Voici le code d’un script C# utilisant la valeur renvoyée, suivi d’un exemple asynchrone :

public static string Run(WorkItem input, ILogger log)
{
    string json = string.Format("{{ \"id\": \"{0}\" }}", input.Id);
    log.LogInformation($"C# script processed queue message. Item={json}");
    return json;
}

public static Task<string> Run(WorkItem input, ILogger log)
{
    string json = string.Format("{{ \"id\": \"{0}\" }}", input.Id);
    log.LogInformation($"C# script processed queue message. Item={json}");
    return Task.FromResult(json);
}

Utilisez la valeur de retour seulement si une exécution réussie de la fonction aboutit toujours à une valeur de retour à passer à la liaison de sortie. Sinon, utilisez ICollector ou IAsyncCollector, comme illustré dans la section suivante.

Écrire plusieurs valeurs de sortie

Pour écrire plusieurs valeurs dans une liaison de sortie, ou si un appel de fonction réussi n’aboutit pas nécessairement à quelque chose à passer à la liaison de sortie, utilisez les types ICollector ou IAsyncCollector. Ces types sont des collections en écriture seule, écrites dans la liaison de sortie à la fin de la méthode.

Cet exemple écrit plusieurs messages de file d’attente dans la même file d’attente à l’aide de ICollector :

public static void Run(ICollector<string> myQueue, ILogger log)
{
    myQueue.Add("Hello");
    myQueue.Add("World!");
}

Journalisation

Pour consigner la sortie dans vos journaux d’activité de streaming en C#, ajoutez un argument de type ILogger. Nous vous recommandons de le nommer log. Évitez d’utiliser Console.Write dans Azure Functions.

public static void Run(string myBlob, ILogger log)
{
    log.LogInformation($"C# Blob trigger function processed: {myBlob}");
}

Notes

Pour plus d’informations sur un framework de journalisation plus récent que vous pouvez utiliser au lieu de TraceWriter, consultez la documentation ILogger dans le Guide du développeur de la bibliothèque de classes .NET.

Journalisation des métriques personnalisées

Vous pouvez utiliser la méthode d’extension LogMetric sur ILogger pour créer des métriques personnalisées dans Application Insights. Voici un exemple d’appel de méthode :

logger.LogMetric("TestMetric", 1234);

Ce code est une alternative à l’appel de TrackMetric à l’aide de l’API Application Insights pour .NET.

Asynchrone

Pour rendre une fonction asynchrone, utilisez le mot clé async et retournez un objet Task.

public async static Task ProcessQueueMessageAsync(
        string blobName,
        Stream blobInput,
        Stream blobOutput)
{
    await blobInput.CopyToAsync(blobOutput, 4096);
}

Vous ne pouvez pas utiliser de paramètres out dans des fonctions asynchrones. Pour les liaisons de sortie, utilisez la valeur de retour de fonction ou un objet collecteur à la place.

Jetons d’annulation

Une fonction peut accepter un paramètre CancellationToken qui permet au système d’exploitation de notifier votre code quand la fonction est sur le point de se terminer. Vous pouvez utiliser cette notification pour vous assurer que la fonction ne s’arrête pas de manière inattendue et laisse les données dans un état incohérent.

L’exemple suivant montre comment vérifier l’arrêt imminent d’une fonction.

using System;
using System.IO;
using System.Threading;

public static void Run(
    string inputText,
    TextWriter logger,
    CancellationToken token)
{
    for (int i = 0; i < 100; i++)
    {
        if (token.IsCancellationRequested)
        {
            logger.WriteLine("Function was cancelled at iteration {0}", i);
            break;
        }
        Thread.Sleep(5000);
        logger.WriteLine("Normal processing for queue message={0}", inputText);
    }
}

Importation des espaces de noms

Si vous avez besoin d’importer des espaces de noms, vous pouvez le faire comme vous en avez l’habitude à l’aide de la clause using .

using System.Net;
using System.Threading.Tasks;
using Microsoft.Extensions.Logging;

public static Task<HttpResponseMessage> Run(HttpRequestMessage req, ILogger log)

Les espaces de noms suivants sont automatiquement importés et sont donc facultatifs :

  • System
  • System.Collections.Generic
  • System.IO
  • System.Linq
  • System.Net.Http
  • System.Threading.Tasks
  • Microsoft.Azure.WebJobs
  • Microsoft.Azure.WebJobs.Host

Référencement des assemblys externes

Pour les assemblys de framework, ajoutez des références à l’aide de la directive #r "AssemblyName" .

#r "System.Web.Http"

using System.Net;
using System.Net.Http;
using System.Threading.Tasks;
using Microsoft.Extensions.Logging;

public static Task<HttpResponseMessage> Run(HttpRequestMessage req, ILogger log)

Les assemblys suivants sont ajoutés automatiquement par l’environnement hébergeant Azure Functions :

  • mscorlib
  • System
  • System.Core
  • System.Xml
  • System.Net.Http
  • Microsoft.Azure.WebJobs
  • Microsoft.Azure.WebJobs.Host
  • Microsoft.Azure.WebJobs.Extensions
  • System.Web.Http
  • System.Net.Http.Formatting

Les assemblys suivants peuvent être référencés par nom simple, par version du runtime :

  • Newtonsoft.Json
  • Microsoft.WindowsAzure.Storage*

*Supprimé dans la version 4.x du runtime.

Dans le code, les assemblys sont référencés comme dans l’exemple suivant :

#r "AssemblyName"

Référencer des assemblys personnalisés

Pour référencer un assembly personnalisé, vous pouvez utiliser soit un assembly partagé, soit un assembly privé :

  • Les assemblys partagés sont communs à toutes les fonctions d’une application de fonction. Pour référencer un assembly personnalisé, chargez-le dans un dossier nommé bin dans le dossier racine (wwwroot) de votre application de fonction.

  • Les assemblys privés font partie du contexte d’une fonction donnée et sont compatibles avec le chargement indépendant de versions différentes. Les assemblys privés doivent être chargés dans un dossier bin du répertoire de la fonction. Référencez les assemblys avec le nom de fichier, par exemple #r "MyAssembly.dll".

Pour plus d’informations sur le téléchargement de fichiers vers votre conteneur de fonctions, consultez la section sur la gestion des packages.

Répertoires surveillés

Le répertoire qui contient le fichier de script de la fonction est automatiquement surveillé pour détecter les modifications apportées aux assemblys. Pour surveiller les modifications des assemblys dans d’autres répertoires, ajoutez-les à la liste watchDirectories dans host.json.

Utiliser des packages NuGet

La façon dont les packages d’extension de liaison et d’autres packages NuGet sont ajoutés à votre application de fonction dépend de la version ciblée du runtime Functions.

Par défaut, l’ensemble pris en charge de packages NuGet d’extensions Functions est mis à la disposition de votre application de fonction de script C# à l’aide de bundles d’extensions. Pour plus d’informations, voir Offres groupées d’extension.

Si, pour une raison quelconque, vous ne pouvez pas utiliser de bundles d’extensions dans votre projet, vous pouvez également utiliser Azure Functions Core Tools pour installer des extensions basées sur des liaisons définies dans les fichiers function.json de votre application. Lorsque vous utilisez Core Tools pour inscrire des extensions, veillez à utiliser l’option --csx. Pour plus d’informations, consultez la section func extensions install.

Par défaut, Core Tools lit les fichiers function.json et ajoute les packages requis à un fichier projet de bibliothèque de classes C# extensions.csproj à la racine du système de fichiers de l’application de fonction (wwwroot). Étant donné que Core Tools utilise dotnet.exe, vous pouvez l’utiliser pour ajouter n’importe quelle référence de package NuGet à ce fichier d’extensions. Pendant l’installation, Core Tools génère le fichier extensions.csproj pour installer les bibliothèques requises. Voici un exemple de fichier extensions.csproj qui ajoute une référence à Microsoft.ProjectOxford.Face version 1.1.0 :

<Project Sdk="Microsoft.NET.Sdk">
    <PropertyGroup>
        <TargetFramework>netstandard2.0</TargetFramework>
    </PropertyGroup>
    <ItemGroup>
        <PackageReference Include="Microsoft.ProjectOxford.Face" Version="1.1.0" />
    </ItemGroup>
</Project>

Notes

Pour le script C# (.csx), vous devez affecter la valeur netstandard2.0 à TargetFramework. Les autres infrastructures cibles, telles que net6.0, ne sont pas prises en charge.

Pour utiliser un flux NuGet personnalisé, spécifiez-le dans un fichier Nuget.Config dans le répertoire racine de l’application de fonction. Pour plus d’informations, consultez la page Configurer le comportement de NuGet.

Si vous travaillez uniquement sur votre projet dans le portail, vous devez créer manuellement le fichier extensions.csproj ou un fichier Nuget.Config directement dans le site. Pour en savoir plus, consultez Installer manuellement des extensions.

Variables d'environnement

Pour obtenir une variable d’environnement ou une valeur de paramètre d’application, utilisez System.Environment.GetEnvironmentVariable, comme illustré dans l’exemple de code suivant :

public static void Run(TimerInfo myTimer, ILogger log)
{
    log.LogInformation($"C# Timer trigger function executed at: {DateTime.Now}");
    log.LogInformation(GetEnvironmentVariable("AzureWebJobsStorage"));
    log.LogInformation(GetEnvironmentVariable("WEBSITE_SITE_NAME"));
}

public static string GetEnvironmentVariable(string name)
{
    return name + ": " +
        System.Environment.GetEnvironmentVariable(name, EnvironmentVariableTarget.Process);
}

Stratégies de nouvelle tentative

Functions prend en charge deux stratégies de nouvelle tentative intégrées. Pour plus d’informations, consultez Stratégies de relance.

Voici la stratégie de nouvelles tentatives dans le fichier function.json :

{
    "disabled": false,
    "bindings": [
        {
            ....
        }
    ],
    "retry": {
        "strategy": "fixedDelay",
        "maxRetryCount": 4,
        "delayInterval": "00:00:10"
    }
}
Propriété function.json Description
stratégie Utilisez fixedDelay.
maxRetryCount Obligatoire. Nombre maximal de nouvelles tentatives autorisées par exécution de fonction. -1 signifie qu’il faut effectuer ces nouvelles tentatives indéfiniment.
delayInterval Délai utilisé entre les nouvelles tentatives. Spécifiez-le sous forme de chaîne au format HH:mm:ss.

Liaison au runtime

Avec C# et d’autres langages .NET, vous pouvez utiliser un schéma de liaison impératif, par opposition aux liaisons déclaratives dans function.json. La liaison impérative est utile lorsque les paramètres de liaison doivent être calculés au moment du runtime plutôt que lors de la conception. Avec ce modèle, vous pouvez effectuer une liaison à la volée avec une liaison d’entrée et de sortie prise en charge dans le code de votre fonction.

Définissez une liaison impérative comme suit :

  • N’incluez pas d’entrée dans function.json pour les liaisons impératives souhaitées.
  • Transmettez un paramètre d’entrée Binder binder ou IBinder binder.
  • Utilisez le modèle en C# suivant pour effectuer la liaison de données.
using (var output = await binder.BindAsync<T>(new BindingTypeAttribute(...)))
{
    ...
}

BindingTypeAttribute est l’attribut .NET qui définit votre liaison et T est le type d’entrée ou de sortie pris en charge par ce type de liaison. T ne peut pas être un type de paramètre out (comme out JObject). Par exemple, la liaison de sortie de la table Mobile Apps prend en charge six types de sortie, mais vous pouvez uniquement utiliser ICollector<T> ou IAsyncCollector<T> pour T.

Exemple d’attribut unique

L’exemple de code suivant crée une liaison de sortie d’objet blob de stockage avec un chemin d’objet blob défini au moment de l’exécution, puis écrit une chaîne vers l’objet blob.

using Microsoft.Azure.WebJobs;
using Microsoft.Azure.WebJobs.Host.Bindings.Runtime;

public static async Task Run(string input, Binder binder)
{
    using (var writer = await binder.BindAsync<TextWriter>(new BlobAttribute("samples-output/path")))
    {
        writer.Write("Hello World!!");
    }
}

BlobAttribute définit la liaison d’entrée ou de sortie de l’objet blob de stockage, et TextWriter est un type de liaison de sortie pris en charge.

Exemple d’attributs multiples

L’exemple précédent obtient le paramètre d’application pour la chaîne de connexion du compte de stockage principal de l’application de fonction (à savoir AzureWebJobsStorage). Vous pouvez spécifier un paramètre d’application personnalisé à utiliser pour le compte de stockage en ajoutant l’attribut StorageAccountAttribute et en transmettant le tableau d’attributs dans BindAsync<T>(). Utilisez un paramètre Binder, et non IBinder. Par exemple :

using Microsoft.Azure.WebJobs;
using Microsoft.Azure.WebJobs.Host.Bindings.Runtime;

public static async Task Run(string input, Binder binder)
{
    var attributes = new Attribute[]
    {
        new BlobAttribute("samples-output/path"),
        new StorageAccountAttribute("MyStorageAccount")
    };

    using (var writer = await binder.BindAsync<TextWriter>(attributes))
    {
        writer.Write("Hello World!");
    }
}

Le tableau suivant répertorie les attributs .NET pour chaque type de liaison et les packages dans lesquels ils sont définis.

Liaison Attribut Ajouter la référence
Azure Cosmos DB Microsoft.Azure.WebJobs.DocumentDBAttribute #r "Microsoft.Azure.WebJobs.Extensions.CosmosDB"
Event Hubs Microsoft.Azure.WebJobs.ServiceBus.EventHubAttribute, Microsoft.Azure.WebJobs.ServiceBusAccountAttribute #r "Microsoft.Azure.Jobs.ServiceBus"
Mobile Apps Microsoft.Azure.WebJobs.MobileTableAttribute #r "Microsoft.Azure.WebJobs.Extensions.MobileApps"
Notification Hubs Microsoft.Azure.WebJobs.NotificationHubAttribute #r "Microsoft.Azure.WebJobs.Extensions.NotificationHubs"
Service Bus Microsoft.Azure.WebJobs.ServiceBusAttribute, Microsoft.Azure.WebJobs.ServiceBusAccountAttribute #r "Microsoft.Azure.WebJobs.ServiceBus"
File d’attente de stockage Microsoft.Azure.WebJobs.QueueAttribute, Microsoft.Azure.WebJobs.StorageAccountAttribute
Objet blob de stockage Microsoft.Azure.WebJobs.BlobAttribute, Microsoft.Azure.WebJobs.StorageAccountAttribute
Table de stockage Microsoft.Azure.WebJobs.TableAttribute, Microsoft.Azure.WebJobs.StorageAccountAttribute
Twilio Microsoft.Azure.WebJobs.TwilioSmsAttribute #r "Microsoft.Azure.WebJobs.Extensions.Twilio"

Convertir une application de script C# en projet C#

Le moyen le plus simple de convertir une application de fonction script C# en un projet de bibliothèque de classes C# compilé consiste à démarrer avec un nouveau projet. Vous pouvez ensuite, pour chaque fonction, migrer le code et la configuration de chaque fichier run.csx et function.json dans un dossier de fonction vers un nouveau fichier de code de bibliothèque de classes .cs unique. Par exemple, lorsque vous avez une fonction de script C# nommée HelloWorld, vous avez deux fichiers : HelloWorld/run.csx et HelloWorld/function.json. Pour cette fonction, vous créez un fichier de code nommé HelloWorld.cs dans votre nouveau projet de bibliothèque de classes.

Si vous utilisez un script C# pour la modification du portail, vous pouvez télécharger le contenu de l’application sur votre ordinateur local. Choisissez l’option Contenu du site plutôt que Contenu et projet Visual Studio. Vous n’avez pas besoin de générer un projet et n’incluez pas de paramètres d’application dans le téléchargement. Vous définissez un nouvel environnement de développement qui ne doit pas avoir les mêmes autorisations que votre environnement d’application hébergée.

Ces instructions vous montrent comment convertir des fonctions de script C# (qui s’exécutent in-process avec l’hôte Functions) en fonctions de bibliothèque de classes C# qui s’exécutent dans un processus Worker isolé.

  1. Terminez la section Créer un projet d’application de fonctions à partir de votre démarrage rapide préféré :

  1. Si votre code de script C# d’origine inclut un fichier extensions.csproj ou des fichiers function.proj, copiez les références de package à partir de ces fichiers et ajoutez-les au fichier du .csproj nouveau projet dans le même ItemGroup que les dépendances principales de Functions.

    Conseil

    La conversion est une bonne occasion de mettre à jour vers les dernières versions de vos dépendances. Cela peut nécessiter des modifications de code supplémentaires dans une étape ultérieure.

  2. Copiez le contenu du fichier host.json d’origine dans le fichier du host.json nouveau projet, à l’exception de la section extensionBundles (les projets C# compilés n’utilisent pas de bundles d’extensions et vous devez ajouter explicitement des références à toutes les extensions utilisées par vos fonctions). Lors de la fusion de fichiers host.json, n’oubliez pas que le schéma host.json est versionné, la plupart des applications utilisant la version 2.0. Le contenu de la section extensions peut différer en fonction des versions spécifiques des extensions de liaison utilisées par vos fonctions. Consultez les articles de référence sur les extensions individuelles pour savoir comment configurer correctement le fichier host.json pour vos versions spécifiques.

  3. Pour tous les fichiers partagés référencés par une directive #load, créez un fichier .cs pour chacune de ces références partagées. Il est plus simple de créer un fichier .cs pour chaque définition de classe partagée. S’il existe des méthodes statiques sans classe, vous devez définir de nouvelles classes pour ces méthodes.

  4. Effectuez les tâches suivantes pour chaque dossier <FUNCTION_NAME> de votre projet d’origine :

    1. Créez un fichier nommé <FUNCTION_NAME>.cs, en remplaçant <FUNCTION_NAME> par le nom du dossier qui a défini votre fonction de script C#. Vous pouvez créer un fichier de code de fonction à partir de l’un des modèles spécifiques au déclencheur de la manière suivante :

      Utiliser la commande func new --name <FUNCTION_NAME> et choisir le modèle de déclencheur approprié à l’invite.

    2. Copiez les instructions using de votre fichier run.csx et ajoutez-les au nouveau fichier. Vous n’avez pas besoin des directives #r.

    3. Pour toute instruction #load dans votre fichier run.csx, ajoutez une nouvelle instruction using à l’espace de noms que vous avez utilisé pour le code partagé.

    4. Dans le nouveau fichier, définissez une classe pour votre fonction sous l’espace de noms que vous utilisez pour le projet.

    5. Créer une méthode nommée RunHandler ou similaire. Cette nouvelle méthode sert de nouveau point d’entrée à la fonction.

    6. Copiez la méthode statique qui représente votre fonction, ainsi que toutes les fonctions qu’elle appelle, à partir de run.csx dans votre nouvelle classe en tant que deuxième méthode. À partir de la nouvelle méthode que vous avez créée à l’étape précédente, appelez cette méthode statique. Cette étape d’indirection est utile pour parcourir les différences lorsque vous poursuivez la mise à niveau. Vous pouvez conserver exactement la même méthode d’origine et simplement contrôler ses entrées à partir du nouveau contexte. Vous devrez peut-être créer des paramètres sur la nouvelle méthode que vous transmettez ensuite à l’appel de méthode statique. Après avoir confirmé que la migration a fonctionné comme prévu, vous pouvez supprimer ce niveau supplémentaire d’indirection.

    7. Pour chaque liaison dans le fichier function.json, ajoutez l’attribut correspondant à votre nouvelle méthode. Pour trouver rapidement des exemples de liaison, consultez Ajouter manuellement des liaisons basées sur des exemples.

    8. Ajoutez les packages d’extension requis par les liaisons à votre projet, si vous ne l’avez pas déjà fait.

  5. Recréez tous les paramètres d’application requis par votre application dans la collection Values du fichier local.settings.json.

  6. Vérifiez que votre projet s’exécute localement :

    Utilisez func start pour exécuter votre application à partir de la ligne de commande. Pour plus d’informations, consultez Exécuter des fonctions localement.

  7. Publiez votre projet sur une nouvelle application de fonction dans Azure :

    Créez vos ressources Azure et déployez le projet de code sur Azure à l’aide de la commande func azure functionapp publish <APP_NAME>. Pour plus d'informations, consultez Déployer des fichiers projet.

Exemple de conversion de fonction

Cette section présente un exemple de migration d’une fonction unique.

La fonction d’origine dans le script C# comporte deux fichiers :

  • HelloWorld/function.json
  • HelloWorld/run.csx

Le contenu de HelloWorld/function.json est présenté ici :

{
  "bindings": [
    {
      "authLevel": "FUNCTION",
      "name": "req",
      "type": "httpTrigger",
      "direction": "in",
      "methods": [
        "get",
        "post"
      ]
    },
    {
      "name": "$return",
      "type": "http",
      "direction": "out"
    }
  ]
}

Le contenu de HelloWorld/run.csx est présenté ici :

#r "Newtonsoft.Json"

using System.Net;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Extensions.Primitives;
using Newtonsoft.Json;

public static async Task<IActionResult> Run(HttpRequest req, ILogger log)
{
    log.LogInformation("C# HTTP trigger function processed a request.");

    string name = req.Query["name"];

    string requestBody = await new StreamReader(req.Body).ReadToEndAsync();
    dynamic data = JsonConvert.DeserializeObject(requestBody);
    name = name ?? data?.name;

    string responseMessage = string.IsNullOrEmpty(name)
        ? "This HTTP triggered function executed successfully. Pass a name in the query string or in the request body for a personalized response."
                : $"Hello, {name}. This HTTP triggered function executed successfully.";

            return new OkObjectResult(responseMessage);
}

Après la migration vers le modèle de travail isolé avec l’intégration ASP.NET Core, ceux-ci sont remplacés par un seul HelloWorld.cs :

using System.Net;
using Microsoft.Azure.Functions.Worker;
using Microsoft.AspNetCore.Http;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Extensions.Logging;
using Microsoft.AspNetCore.Routing;
using Microsoft.Extensions.Primitives;
using Newtonsoft.Json;

namespace MyFunctionApp
{
    public class HelloWorld
    {
        private readonly ILogger _logger;

        public HelloWorld(ILoggerFactory loggerFactory)
        {
            _logger = loggerFactory.CreateLogger<HelloWorld>();
        }

        [Function("HelloWorld")]
        public async Task<IActionResult> RunHandler([HttpTrigger(AuthorizationLevel.Function, "get")] HttpRequest req)
        {
            return await Run(req, _logger);
        }

        // From run.csx
        public static async Task<IActionResult> Run(HttpRequest req, ILogger log)
        {
            log.LogInformation("C# HTTP trigger function processed a request.");

            string name = req.Query["name"];

            string requestBody = await new StreamReader(req.Body).ReadToEndAsync();
            dynamic data = JsonConvert.DeserializeObject(requestBody);
            name = name ?? data?.name;

            string responseMessage = string.IsNullOrEmpty(name)
                ? "This HTTP triggered function executed successfully. Pass a name in the query string or in the request body for a personalized response."
                        : $"Hello, {name}. This HTTP triggered function executed successfully.";

            return new OkObjectResult(responseMessage);
        }
    }
}

Configuration de liaison et exemples

Cette section contient des références et des exemples de définition de déclencheurs et de liaisons dans un script C#.

Déclencheur d’objet blob

Le tableau suivant décrit les propriétés de configuration de liaison pour le script C# 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.
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.

L’exemple suivant montre une définition de déclencheur d’objet blob dans un fichier function.json et un code qui utilise la liaison. La fonction enregistre un journal lorsqu'un objet blob est ajouté ou mis à jour dans le samples-workitems conteneur.

Voici les données de liaison dans le fichier function.json :

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

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 Modèles de noms d'objets blob.

Voici le code Script C# qui lie à Stream :

public static void Run(Stream myBlob, string name, ILogger log)
{
   log.LogInformation($"C# Blob trigger function Processed blob\n Name:{name} \n Size: {myBlob.Length} Bytes");
}

Voici le code Script C# qui lie à CloudBlockBlob :

#r "Microsoft.WindowsAzure.Storage"

using Microsoft.WindowsAzure.Storage.Blob;

public static void Run(CloudBlockBlob myBlob, string name, ILogger log)
{
    log.LogInformation($"C# Blob trigger function Processed blob\n Name:{name}\nURI:{myBlob.StorageUri}");
}

Entrée d’objet blob

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

Propriété function.json Description
type Cette propriété doit être définie sur blob.
direction Cette propriété doit être définie sur in.
name Nom de la variable qui représente l’objet blob dans le code de la fonction.
path 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.

L’exemple suivant montre des liaisons d’entrée et de sortie d’objets blob dans un fichier function.json et du code de script C# qui utilise les liaisons. La fonction effectue une copie d’un objet blob de texte. La fonction est déclenchée par un message de file d’attente qui contient le nom de l’objet blob à copier. Le nouvel objet blob est nommé {originalblobname}-Copy.

Dans le fichier function.json, la propriété de métadonnées queueTrigger est utilisée pour spécifier le nom de l’objet blob dans les propriétés path :

{
  "bindings": [
    {
      "queueName": "myqueue-items",
      "connection": "MyStorageConnectionAppSetting",
      "name": "myQueueItem",
      "type": "queueTrigger",
      "direction": "in"
    },
    {
      "name": "myInputBlob",
      "type": "blob",
      "path": "samples-workitems/{queueTrigger}",
      "connection": "MyStorageConnectionAppSetting",
      "direction": "in"
    },
    {
      "name": "myOutputBlob",
      "type": "blob",
      "path": "samples-workitems/{queueTrigger}-Copy",
      "connection": "MyStorageConnectionAppSetting",
      "direction": "out"
    }
  ],
  "disabled": false
}

Voici le code Script C# :

public static void Run(string myQueueItem, string myInputBlob, out string myOutputBlob, ILogger log)
{
    log.LogInformation($"C# Queue trigger function processed: {myQueueItem}");
    myOutputBlob = myInputBlob;
}

Sortie d’objet blob

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

Propriété function.json Description
type Cette propriété doit être définie sur blob.
direction Cette propriété doit être définie sur out.
name Nom de la variable qui représente l’objet blob dans le code de la fonction.
path 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.

L’exemple suivant montre des liaisons d’entrée et de sortie d’objets blob dans un fichier function.json et du code de script C# qui utilise les liaisons. La fonction effectue une copie d’un objet blob de texte. La fonction est déclenchée par un message de file d’attente qui contient le nom de l’objet blob à copier. Le nouvel objet blob est nommé {originalblobname}-Copy.

Dans le fichier function.json, la propriété de métadonnées queueTrigger est utilisée pour spécifier le nom de l’objet blob dans les propriétés path :

{
  "bindings": [
    {
      "queueName": "myqueue-items",
      "connection": "MyStorageConnectionAppSetting",
      "name": "myQueueItem",
      "type": "queueTrigger",
      "direction": "in"
    },
    {
      "name": "myInputBlob",
      "type": "blob",
      "path": "samples-workitems/{queueTrigger}",
      "connection": "MyStorageConnectionAppSetting",
      "direction": "in"
    },
    {
      "name": "myOutputBlob",
      "type": "blob",
      "path": "samples-workitems/{queueTrigger}-Copy",
      "connection": "MyStorageConnectionAppSetting",
      "direction": "out"
    }
  ],
  "disabled": false
}

Voici le code Script C# :

public static void Run(string myQueueItem, string myInputBlob, out string myOutputBlob, ILogger log)
{
    log.LogInformation($"C# Queue trigger function processed: {myQueueItem}");
    myOutputBlob = myInputBlob;
}

Déclencheur RabbitMQ

L’exemple suivant montre une liaison de déclencheur RabbitMQ dans un fichier function.json et une fonction de script C# qui utilise la liaison. La fonction lit et journalise le message RabbitMQ.

Voici les données de liaison dans le fichier function.json :

{​​
    "bindings": [
        {​​
            "name": "myQueueItem",
            "type": "rabbitMQTrigger",
            "direction": "in",
            "queueName": "queue",
            "connectionStringSetting": "rabbitMQConnectionAppSetting"
        }​​
    ]
}​​

Voici le code Script C# :

using System;

public static void Run(string myQueueItem, ILogger log)
{​​
    log.LogInformation($"C# Script RabbitMQ trigger function processed: {​​myQueueItem}​​");
}​​

Déclencheur de file d’attente

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

Propriété function.json Description
type Cette propriété doit être définie sur queueTrigger. Cette propriété est définie automatiquement lorsque vous créez le déclencheur dans le portail Azure.
direction Dans le fichier function.json uniquement. 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.
name Nom de la variable qui contient la charge utile de l’élément de file d’attente dans le code de fonction.
queueName Nom de la file d’attente à interroger.
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 files d’attente Azure. Consultez Connexions.

L'exemple suivant montre une liaison de déclencheur de file d'attente dans un fichier function.json et un code de script C# qui utilise la liaison. La fonction interroge la file d’attente myqueue-items et écrit un journal chaque fois qu’un élément de la file d’attente est traité.

Voici le fichier function.json :

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

Voici le code Script C# :

#r "Microsoft.WindowsAzure.Storage"

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

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

Sortie de file d’attente

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

Propriété function.json Description
type Cette propriété doit être définie sur queue. 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 out. Cette propriété est définie automatiquement lorsque vous créez le déclencheur dans le portail Azure.
name Nom de la variable qui représente la file d’attente dans le code de la fonction. La valeur doit être $return pour faire référence à la valeur de retour de la fonction.
queueName Nom de la file d'attente.
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 files d’attente Azure. Consultez Connexions.

L'exemple suivant montre une liaison de déclencheur HTTP dans un fichier function.json et un code de script C# qui utilise la liaison. La fonction crée un élément de file d’attente avec une charge utile d’objet CustomQueueMessage pour chaque requête HTTP reçue.

Voici le fichier function.json :

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

Voici le code Script C# qui crée un message de file d’attente unique :

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

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

Vous pouvez envoyer plusieurs messages à la fois en utilisant un paramètre ICollector ou IAsyncCollector. Voici le code Script C# qui envoie plusieurs messages, l’un avec les données de requête HTTP, et l’autre avec des valeurs codées en dur :

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

Entrée de table

Cette section décrit la prise en charge de la version API Tables de l'extension uniquement.

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

Propriété function.json Description
type Cette propriété doit être définie sur table. Cette propriété est définie automatiquement lorsque vous créez la liaison 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 la liaison dans le portail Azure.
name Nom de la variable qui représente la table ou l’entité dans le code de la fonction.
tableName Nom de la table.
partitionKey facultatif. Clé de partition de l’entité de table à lire.
rowKey facultatif. Clé de ligne de l’entité de table à lire. Ne peut pas être utilisé avec take ou filter.
take facultatif. Nombre maximal d’entités à retourner. Impossible à utiliser avec rowKey.
filter facultatif. Expression de filtre OData pour les entités à retourner à partir de la table. Impossible à utiliser avec rowKey.
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 au service de table. Consultez Connexions.

L’exemple suivant montre une liaison d’entrée de table dans un fichier function.json et un code Script C# qui utilise la liaison. La fonction utilise un déclencheur de file d’attente pour lire une seule ligne du tableau.

Le fichier function.json spécifie une propriété partitionKey et une propriété rowKey. La valeur de rowKey{queueTrigger} indique que la clé de ligne provient de la chaîne de message de file d’attente.

{
  "bindings": [
    {
      "queueName": "myqueue-items",
      "connection": "MyStorageConnectionAppSetting",
      "name": "myQueueItem",
      "type": "queueTrigger",
      "direction": "in"
    },
    {
      "name": "personEntity",
      "type": "table",
      "tableName": "Person",
      "partitionKey": "Test",
      "rowKey": "{queueTrigger}",
      "connection": "MyStorageConnectionAppSetting",
      "direction": "in"
    }
  ],
  "disabled": false
}

Voici le code Script C# :

#r "Azure.Data.Tables"
using Microsoft.Extensions.Logging;
using Azure.Data.Tables;

public static void Run(string myQueueItem, Person personEntity, ILogger log)
{
    log.LogInformation($"C# Queue trigger function processed: {myQueueItem}");
    log.LogInformation($"Name in Person entity: {personEntity.Name}");
}

public class Person : ITableEntity
{
    public string Name { get; set; }

    public string PartitionKey { get; set; }
    public string RowKey { get; set; }
    public DateTimeOffset? Timestamp { get; set; }
    public ETag ETag { get; set; }
}

Sortie de table

Cette section décrit la prise en charge de la version API Tables de l'extension uniquement.

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

Propriété function.json Description
type Cette propriété doit être définie sur table. Cette propriété est définie automatiquement lorsque vous créez la liaison dans le portail Azure.
direction Cette propriété doit être définie sur out. Cette propriété est définie automatiquement lorsque vous créez la liaison dans le portail Azure.
name Nom de variable utilisé dans le code de la fonction qui représente la table ou l’entité. La valeur doit être $return pour faire référence à la valeur de retour de la fonction.
tableName Nom de la table dans laquelle écrire.
partitionKey Clé de partition de l’entité de table à écrire.
rowKey Clé de ligne de l’entité de table à écrire.
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 au service de table. Consultez Connexions.

L’exemple suivant montre une liaison de sortie de table dans un fichier function.json et un code Script C# qui utilise la liaison. La fonction écrit plusieurs entités de table.

Voici le fichier function.json :

{
  "bindings": [
    {
      "name": "input",
      "type": "manualTrigger",
      "direction": "in"
    },
    {
      "tableName": "Person",
      "connection": "MyStorageConnectionAppSetting",
      "name": "tableBinding",
      "type": "table",
      "direction": "out"
    }
  ],
  "disabled": false
}

Voici le code Script C# :

public static void Run(string input, ICollector<Person> tableBinding, ILogger log)
{
    for (int i = 1; i < 10; i++)
        {
            log.LogInformation($"Adding Person entity {i}");
            tableBinding.Add(
                new Person() { 
                    PartitionKey = "Test", 
                    RowKey = i.ToString(), 
                    Name = "Name" + i.ToString() }
                );
        }

}

public class Person
{
    public string PartitionKey { get; set; }
    public string RowKey { get; set; }
    public string Name { get; set; }
}

Déclencheur de minuteur

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

Propriété function.json Description
type Cette propriété doit être définie sur timerTrigger. 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.
name Nom de la variable qui représente l’objet de minuteur dans le code de la fonction.
schedule Une expression CRON ou une valeur TimeSpan. TimeSpan peut être utilisé uniquement pour une application de fonction qui s’exécute sur un plan App Service. Vous pouvez placer l’expression de planification dans un paramètre d’application et définir cette propriété selon le nom du paramètre d’application encapsulé dans les signes % , comme sur cet exemple : « %ScheduleAppSetting% ».
runOnStartup Si la valeur est true, la fonction est appelée au démarrage du runtime. Par exemple, le runtime démarre lorsque l’application de fonction sort de veille après une période d’inactivité. Lorsque l’application de fonction redémarre en raison de modifications apportées à la fonction, et lorsque l’application de fonction augmente la taille des instances. À utiliser avec précaution. runOnStartup doit rarement, voire jamais, être défini sur true, en particulier en production.
useMonitor Peut-être défini sur la valeur true ou false pour indiquer si la planification doit être surveillée ou non. La surveillance de planification conserve les occurrences de planification pour garantir la maintenance correcte de cette dernière même en cas de redémarrage des instances de l’application de fonction. Si elle n’est pas définie explicitement, la valeur par défaut est true pour les planifications dont l’intervalle de récurrence est supérieur ou égal à 1 minute. Pour les planifications qui se déclenchent plusieurs fois par minute, la valeur par défaut est false.

L’exemple suivant montre une liaison de déclencheur de minuteur dans un fichier function.json et une fonction de script C# qui utilise la liaison. La fonction écrit un journal indiquant si cet appel de fonction est dû à une occurrence de planification manquée. L’objet TimerInfo est transmis à la fonction.

Voici les données de liaison dans le fichier function.json :

{
    "schedule": "0 */5 * * * *",
    "name": "myTimer",
    "type": "timerTrigger",
    "direction": "in"
}

Voici le code Script C# :

public static void Run(TimerInfo myTimer, ILogger log)
{
    if (myTimer.IsPastDue)
    {
        log.LogInformation("Timer is running late!");
    }
    log.LogInformation($"C# Timer trigger function executed at: {DateTime.Now}" );  
}

Déclencheur HTTP

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

Propriété function.json Description
type Obligatoire : doit être défini sur httpTrigger.
direction Obligatoire : doit être défini sur in.
name Obligatoire : nom de variable utilisé dans le code de la fonction pour la requête ou le corps de la requête.
authLevel Détermine, le cas échéant, les clés qui doivent être présentes dans la requête pour appeler la fonction. Pour les valeurs prises en charge, consultez Niveau d’autorisation.
methods Tableau des méthodes HTTP auxquelles la fonction répond. À défaut de spécification, la fonction répond à toutes les méthodes HTTP. Consultez Personnaliser le point de terminaison HTTP.
route Définit le modèle de routage, en contrôlant les URL de requête auxquelles votre fonction répond. La valeur par défaut est <functionname>. Pour plus d’informations, consultez Personnaliser le point de terminaison HTTP.
webHookType Prise en charge uniquement pour le runtime version 1.x.

Configure le déclencheur HTTP pour qu’il agisse en tant que récepteur de Webhook pour le fournisseur spécifié. Pour les valeurs prises en charge, consultez Type de webhook.

L’exemple suivant montre une liaison de déclencheur dans un fichier function.json et une fonction de script C# qui utilise la liaison. Cette fonction recherche un paramètre name dans la chaîne de requête ou dans le corps de la requête HTTP.

Voici le fichier function.json :

{
    "disabled": false,
    "bindings": [
        {
            "authLevel": "function",
            "name": "req",
            "type": "httpTrigger",
            "direction": "in",
            "methods": [
                "get",
                "post"
            ]
        },
        {
            "name": "$return",
            "type": "http",
            "direction": "out"
        }
    ]
}

Voici le code de script C# qui lie à HttpRequest :

#r "Newtonsoft.Json"

using System.Net;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Extensions.Primitives;
using Newtonsoft.Json;

public static async Task<IActionResult> Run(HttpRequest req, ILogger log)
{
    log.LogInformation("C# HTTP trigger function processed a request.");

    string name = req.Query["name"];
    
    string requestBody = String.Empty;
    using (StreamReader streamReader =  new  StreamReader(req.Body))
    {
        requestBody = await streamReader.ReadToEndAsync();
    }
    dynamic data = JsonConvert.DeserializeObject(requestBody);
    name = name ?? data?.name;
    
    return name != null
        ? (ActionResult)new OkObjectResult($"Hello, {name}")
        : new BadRequestObjectResult("Please pass a name on the query string or in the request body");
}

Vous pouvez lier à un objet personnalisé au lieu de HttpRequest. Cet objet est créé à partir du corps de la requête et analysé en tant que JSON. De même, un type peut être passé à la liaison de sortie de réponse HTTP, et être retourné en tant que corps de la réponse, avec un code d'état 200.

using System.Net;
using System.Threading.Tasks;
using Microsoft.Extensions.Logging;

public static string Run(Person person, ILogger log)
{   
    return person.Name != null
        ? (ActionResult)new OkObjectResult($"Hello, {person.Name}")
        : new BadRequestObjectResult("Please pass an instance of Person.");
}

public class Person {
     public string Name {get; set;}
}

Sortie HTTP

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

Propriété Description
type Cette propriété doit être définie sur http.
direction Cette propriété doit être définie sur out.
name Nom de variable utilisé dans le code de fonction pour la réponse, ou $return pour utiliser la valeur renvoyée.

Déclencheur Event Hubs

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

Propriété function.json Description
type Cette propriété doit être définie sur eventHubTrigger. 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.
name Nom de la variable qui représente l’élément d’événement dans le code de la fonction.
eventHubName Functions 2.x et versions ultérieures. Nom du hub d’événements. Lorsque le nom d’Event Hub est également présent dans la chaîne de connexion, sa valeur remplace cette propriété lors de l’exécution. Peut être référencé via les paramètres d’application %eventHubName%. Dans la version 1.x, cette propriété est nommée path.
consumerGroup Propriété facultative qui définit le groupe de consommateurs utilisé pour l’abonnement à des événements dans le hub. En cas d’omission, le groupe de consommateurs $Default est utilisé.
connection Nom d’un paramètre d’application ou d’une collection de paramètres qui spécifie la façon de se connecter à Event Hubs. Consultez Connexions.

L’exemple suivant illustre une liaison de déclencheur Event Hubs dans un fichier function.json et une fonction de script C# qui utilise la liaison. La fonction consigne le corps du message du déclencheur Event Hubs.

Les exemples suivants montrent des données de liaison Event Hubs dans le fichier function.json pour le runtime Functions version 2.x et versions ultérieures.

{
  "type": "eventHubTrigger",
  "name": "myEventHubMessage",
  "direction": "in",
  "eventHubName": "MyEventHub",
  "connection": "myEventHubReadConnectionAppSetting"
}

Voici le code Script C# :

using System;

public static void Run(string myEventHubMessage, TraceWriter log)
{
    log.Info($"C# function triggered to process a message: {myEventHubMessage}");
}

Pour accéder aux métadonnées d’événement dans le code de la fonction, effectuez une liaison avec l’objet EventData. Vous pouvez également accéder aux mêmes propriétés à l’aide d’expressions de liaison dans la signature de la méthode. L’exemple suivant montre deux façons d’obtenir les mêmes données :

#r "Microsoft.Azure.EventHubs"

using System.Text;
using System;
using Microsoft.ServiceBus.Messaging;
using Microsoft.Azure.EventHubs;

public void Run(EventData myEventHubMessage,
    DateTime enqueuedTimeUtc,
    Int64 sequenceNumber,
    string offset,
    TraceWriter log)
{
    log.Info($"Event: {Encoding.UTF8.GetString(myEventHubMessage.Body)}");
    log.Info($"EnqueuedTimeUtc={myEventHubMessage.SystemProperties.EnqueuedTimeUtc}");
    log.Info($"SequenceNumber={myEventHubMessage.SystemProperties.SequenceNumber}");
    log.Info($"Offset={myEventHubMessage.SystemProperties.Offset}");

    // Metadata accessed by using binding expressions
    log.Info($"EnqueuedTimeUtc={enqueuedTimeUtc}");
    log.Info($"SequenceNumber={sequenceNumber}");
    log.Info($"Offset={offset}");
}

Pour recevoir des événements en lot, transformez string ou EventData en tableau :

public static void Run(string[] eventHubMessages, TraceWriter log)
{
    foreach (var message in eventHubMessages)
    {
        log.Info($"C# function triggered to process a message: {message}");
    }
}

Sortie Event Hubs

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 eventHub.
direction Cette propriété doit être définie sur out. Ce paramètre est défini automatiquement lorsque vous créez la liaison dans le portail Azure.
name Nom de variable utilisé dans le code de la fonction qui représente l’événement.
eventHubName Functions 2.x et versions ultérieures. Nom du hub d’événements. Lorsque le nom d’Event Hub est également présent dans la chaîne de connexion, sa valeur remplace cette propriété lors de l’exécution. Dans Functions 1.x, cette propriété est nommée path.
connection Nom d’un paramètre d’application ou d’une collection de paramètres qui spécifie la façon de se connecter à Event Hubs. Pour en savoir plus, consultez Connexions.

L’exemple suivant illustre une liaison de déclencheur de hub d’événements dans un fichier function.json et une fonction de script C# qui utilise la liaison. La fonction écrit un message dans un hub d’événements.

Les exemples suivants montrent des données de liaison Event Hubs dans le fichier function.json pour le runtime Functions version 2.x et versions ultérieures.

{
    "type": "eventHub",
    "name": "outputEventHubMessage",
    "eventHubName": "myeventhub",
    "connection": "MyEventHubSendAppSetting",
    "direction": "out"
}

Voici le code Script C# qui crée un message :

using System;
using Microsoft.Extensions.Logging;

public static void Run(TimerInfo myTimer, out string outputEventHubMessage, ILogger log)
{
    String msg = $"TimerTriggerCSharp1 executed at: {DateTime.Now}";
    log.LogInformation(msg);   
    outputEventHubMessage = msg;
}

Voici le code de script C# qui crée plusieurs messages :

public static void Run(TimerInfo myTimer, ICollector<string> outputEventHubMessage, ILogger log)
{
    string message = $"Message created at: {DateTime.Now}";
    log.LogInformation(message);
    outputEventHubMessage.Add("1 " + message);
    outputEventHubMessage.Add("2 " + message);
}

Déclencheur Event Grid

Le tableau suivant décrit les propriétés de configuration de liaison pour le script C# que vous définissez dans le fichier function.json. Il n’y a aucun paramètre de constructeur ni aucune propriété à définir dans l’attribut EventGridTrigger.

Propriété function.json Description
type Obligatoire : doit être défini sur eventGridTrigger.
direction Obligatoire : doit être défini sur in.
name Obligatoire : nom de variable utilisé dans le code de fonction pour le paramètre qui reçoit les données de l’événement.

L’exemple suivant montre un déclencheur Event Grid défini dans le fichier function.json.

Voici les données de liaison dans le fichier function.json :

{
  "bindings": [
    {
      "type": "eventGridTrigger",
      "name": "eventGridEvent",
      "direction": "in"
    }
  ],
  "disabled": false
}

Voici un exemple de fonction de script C# qui utilise un paramètre de liaison EventGridEvent :

#r "Azure.Messaging.EventGrid"
using Azure.Messaging.EventGrid;
using Microsoft.Extensions.Logging;

public static void Run(EventGridEvent eventGridEvent, ILogger log)
{
    log.LogInformation(eventGridEvent.Data.ToString());
}

Voici un exemple de fonction de script C# qui utilise un paramètre de liaison JObject :

#r "Newtonsoft.Json"

using Newtonsoft.Json;
using Newtonsoft.Json.Linq;

public static void Run(JObject eventGridEvent, TraceWriter log)
{
    log.Info(eventGridEvent.ToString(Formatting.Indented));
}

Sortie Event Grid

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

Propriété function.json Description
type Cette propriété doit être définie sur eventGrid.
direction Cette propriété doit être définie sur out. Ce paramètre est défini automatiquement lorsque vous créez la liaison dans le portail Azure.
name Nom de variable utilisé dans le code de la fonction qui représente l’événement.
topicEndpointUri Nom d’un paramètre d’application qui contient l’URI pour la rubrique personnalisée, comme MyTopicEndpointUri.
topicKeySetting Nom d’un paramètre d’application qui contient une clé d’accès pour la rubrique personnalisée.

L’exemple suivant montre les données de la liaison de sortie Event Grid dans le fichier function.json.

{
    "type": "eventGrid",
    "name": "outputEvent",
    "topicEndpointUri": "MyEventGridTopicUriSetting",
    "topicKeySetting": "MyEventGridTopicKeySetting",
    "direction": "out"
}

Voici le code du script C# qui crée un événement :

#r "Microsoft.Azure.EventGrid"
using System;
using Microsoft.Azure.EventGrid.Models;
using Microsoft.Extensions.Logging;

public static void Run(TimerInfo myTimer, out EventGridEvent outputEvent, ILogger log)
{
    outputEvent = new EventGridEvent("message-id", "subject-name", "event-data", "event-type", DateTime.UtcNow, "1.0");
}

Voici le code du script C# qui crée plusieurs événements :

#r "Microsoft.Azure.EventGrid"
using System;
using Microsoft.Azure.EventGrid.Models;
using Microsoft.Extensions.Logging;

public static void Run(TimerInfo myTimer, ICollector<EventGridEvent> outputEvent, ILogger log)
{
    outputEvent.Add(new EventGridEvent("message-id-1", "subject-name", "event-data", "event-type", DateTime.UtcNow, "1.0"));
    outputEvent.Add(new EventGridEvent("message-id-2", "subject-name", "event-data", "event-type", DateTime.UtcNow, "1.0"));
}

Déclencheur Service Bus

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 serviceBusTrigger. 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.
name Nom de la variable qui représente le message de la file d’attente ou de la rubrique dans le code de la fonction.
queueName Nom de la file d’attente à surveiller. Défini uniquement en cas de surveillance d’une file d’attente, ne s’applique pas à une rubrique.
topicName Nom de la rubrique à surveiller. Défini uniquement en cas de surveillance d’une rubrique, ne s’applique pas à une file d’attente.
subscriptionName Nom de l’abonnement à surveiller. Défini uniquement en cas de surveillance d’une rubrique, ne s’applique pas à une file d’attente.
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 à Service Bus. Consultez Connexions.
accessRights Droits d’accès de la chaîne de connexion. Les valeurs disponibles sont manage et listen. La valeur par défaut est manage, ce qui indique que connection a l'autorisation manage. Si vous utilisez une chaîne de connexion qui n’a pas l'autorisation Gérer, définissez accessRights sur « écouter ». Sinon, le runtime Functions pourrait échouer à effectuer des opérations qui nécessitent des droits de gestion. Dans Azure Functions versions 2.x et ultérieures, cette propriété n’est pas disponible parce que la version la plus récente du Kit de développement logiciel (SDK) Service Bus ne prend pas en charge les opérations de gestion.
isSessionsEnabled true en cas de connexion à une file d’attente ou à un abonnement true. Sinon false, qui est la valeur par défaut.
autoComplete true si le déclencheur doit terminer l’appel automatiquement après le traitement, ou si le code de la fonction termine manuellement l’appel.

La définition de false est prise en charge uniquement dans C# .

Si la valeur est true, le déclencheur termine automatiquement le message si l’exécution de la fonction se termine correctement et abandonne le message dans le cas contraire.
<br/Lorsque la valeur est false, il vous incombe d’appeler des méthodes ServiceBusReceiver pour terminer, abandonner ou mettre en file d’attente de lettres mortes le message, la session ou le lot. Lorsqu’une exception est levée (et qu’aucune des méthodes ServiceBusReceiver n’est appelée), le verrou reste. Une fois le verrou expiré, le message est de nouveau mis en file d’attente avec DeliveryCount incrémenté, et le verrou est automatiquement renouvelé.

Cette propriété est disponible uniquement dans Azure Functions 2.x et versions ultérieures.

L’exemple suivant montre une liaison de déclencheur Service Bus dans un fichier function.json et une fonction de script C# qui utilise la liaison. La fonction lit les métadonnées du message et consigne un message de la file d’attente Service Bus.

Voici les données de liaison dans le fichier function.json :

{
"bindings": [
    {
    "queueName": "testqueue",
    "connection": "MyServiceBusConnection",
    "name": "myQueueItem",
    "type": "serviceBusTrigger",
    "direction": "in"
    }
],
"disabled": false
}

Voici le code Script C# :

using System;

public static void Run(string myQueueItem,
    Int32 deliveryCount,
    DateTime enqueuedTimeUtc,
    string messageId,
    TraceWriter log)
{
    log.Info($"C# ServiceBus queue trigger function processed message: {myQueueItem}");

    log.Info($"EnqueuedTimeUtc={enqueuedTimeUtc}");
    log.Info($"DeliveryCount={deliveryCount}");
    log.Info($"MessageId={messageId}");
}

sortie Microsoft Azure Service Bus

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 serviceBus. 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 out. Cette propriété est définie automatiquement lorsque vous créez le déclencheur dans le portail Azure.
name Nom de la variable qui représente le message de la file d’attente ou de la rubrique dans le code de la fonction. Défini sur « $return » pour faire référence à la valeur de retour de la fonction.
queueName Nom de la file d’attente. Défini uniquement en cas d’envoi de messages de file d’attente, ne s’applique pas à une rubrique.
topicName Nom de la rubrique. Défini uniquement en cas d’envoi de messages de rubrique, ne s’applique pas à une file d’attente.
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 à Service Bus. Consultez Connexions.
accessRights (v1 uniquement) Droits d’accès de la chaîne de connexion. Les valeurs disponibles sont manage et listen. La valeur par défaut est manage, ce qui indique que connection a l'autorisation manage. Si vous utilisez une chaîne de connexion qui n’a pas l'autorisation Gérer, définissez accessRights sur « écouter ». Sinon, le runtime Functions pourrait échouer à effectuer des opérations qui nécessitent des droits de gestion. Dans Azure Functions versions 2.x et ultérieures, cette propriété n’est pas disponible parce que la version la plus récente du Kit de développement logiciel (SDK) Service Bus ne prend pas en charge les opérations de gestion.

L’exemple suivant montre une liaison de sortie Service Bus dans un fichier function.json et une fonction de script C# qui utilise la liaison. La fonction utilise un déclencheur de minuteur pour envoyer un message de file d’attente toutes les 15 secondes.

Voici les données de liaison dans le fichier function.json :

{
    "bindings": [
        {
            "schedule": "0/15 * * * * *",
            "name": "myTimer",
            "runsOnStartup": true,
            "type": "timerTrigger",
            "direction": "in"
        },
        {
            "name": "outputSbQueue",
            "type": "serviceBus",
            "queueName": "testqueue",
            "connection": "MyServiceBusConnection",
            "direction": "out"
        }
    ],
    "disabled": false
}

Voici le code de script C# qui crée un message unique :

public static void Run(TimerInfo myTimer, ILogger log, out string outputSbQueue)
{
    string message = $"Service Bus queue message created at: {DateTime.Now}";
    log.LogInformation(message); 
    outputSbQueue = message;
}

Voici le code de script C# qui crée plusieurs messages :

public static async Task Run(TimerInfo myTimer, ILogger log, IAsyncCollector<string> outputSbQueue)
{
    string message = $"Service Bus queue messages created at: {DateTime.Now}";
    log.LogInformation(message); 
    await outputSbQueue.AddAsync("1 " + message);
    await outputSbQueue.AddAsync("2 " + message);
}

Déclencheur Azure Cosmos DB v2

Cette section décrit la prise en charge de la version 4.x+ de l'extension uniquement.

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 cosmosDBTrigger.
direction Cette propriété doit être définie sur in. Ce paramètre est défini automatiquement lorsque vous créez le déclencheur dans le portail Azure.
name Nom de variable utilisé dans le code de fonction, qui représente la liste des documents modifiés.
connection Nom d’un paramètre d’application ou d’une collection de paramètres qui spécifie la façon de se connecter au compte Azure Cosmos DB qui est surveillé. Pour plus d’informations, consultez Connexions.
databaseName Nom de la base de données Azure Cosmos DB contenant le conteneur analysé.
containerName Nom du conteneur surveillé.
leaseConnection (Facultatif) Nom d’un paramètre d’application ou d’un conteneur de paramètres qui spécifie la façon de se connecter au compte Azure Cosmos DB qui détient le conteneur de baux.

S’il n’est pas défini, la valeur connection est utilisée. Ce paramètre est automatiquement défini lorsque la liaison est créée dans le portail. La chaîne de connexion du conteneur de baux doit avoir des autorisations en écriture.
leaseDatabaseName (Facultatif) Nom de la base de données contenant le conteneur utilisé pour stocker des baux. S’il n’est pas défini, la valeur du paramètre databaseName est utilisée.
leaseContainerName (Facultatif) Nom du conteneur utilisé pour stocker des baux. S’il n’est pas défini, la valeur leases est utilisée.
createLeaseContainerIfNotExists (Facultatif) Lorsque la valeur est définie sur true, le conteneur de baux est créé automatiquement s’il n’existe pas. La valeur par défaut est false. Lorsque vous utilisez des identités Microsoft Entra, si vous définissez la valeur sur true, la création de conteneurs n’est pas une opération autorisée et votre fonction ne pourra pas démarrer.
leasesContainerThroughput (Facultatif) Définit le nombre d’unités de requête à attribuer lors de la création du conteneur de baux. Ce paramètre est utilisé uniquement quand createLeaseContainerIfNotExists est défini sur true. Ce paramètre est automatiquement défini lors de la création de la liaison à l’aide du portail.
leaseContainerPrefix (Facultatif) Lorsque cette valeur est définie, elle est ajoutée en tant que préfixe aux baux créés dans le conteneur de baux pour cette fonction. L’utilisation d’un préfixe permet à deux fonctions Azure distinctes de partager le même conteneur de baux grâce à des préfixes différents.
feedPollDelay (Facultatif) Durée (en millisecondes) du délai s’écoulant entre le moment où toutes les modifications d’une partition sont purgées du flux et le moment où la partition est interrogée afin d’identifier de nouvelles modifications. La valeur par défaut est 5 000 millisecondes, soit 5 secondes.
leaseAcquireInterval (Facultatif) Quand ce paramètre est défini, il spécifie, en millisecondes, l’intervalle pour déclencher une tâche afin de calculer si les partitions sont réparties uniformément parmi les instances d’hôte connues. La valeur par défaut est 13 000 (13 secondes).
leaseExpirationInterval (Facultatif) Quand ce paramètre est défini, il spécifie, en millisecondes, l’intervalle selon lequel le bail est pris sur un bail représentant une partition. Si le bail n’est pas renouvelé dans cet intervalle, il expire et une autre instance devient propriétaire de la partition. La valeur par défaut est 60 000 (60 secondes).
leaseRenewInterval (Facultatif) Quand ce paramètre est défini, il spécifie, en millisecondes, l’intervalle de renouvellement de tous les baux pour les partitions actuellement détenues par une instance. La valeur par défaut est 17 000 (17 secondes).
maxItemsPerInvocation (Facultatif) Quand cette propriété est définie, elle détermine le nombrer maximal d’éléments reçus par appel de fonction. Si des opérations du conteneur analysé sont effectuées par le biais de procédures stockées, l’étendue de transaction est préservée lors de la lecture des éléments à partir du flux de modification. Par conséquent, le nombre d’éléments reçus pourrait être supérieur à la valeur spécifiée de sorte que les éléments modifiés par la même transaction soient retournés dans le cadre d’un même lot atomique.
startFromBeginning (Facultatif) Cette option indique au déclencheur de lire les modifications depuis le début de l’historique de modifications du conteneur au lieu de commencer à l’heure actuelle. La lecture depuis le début fonctionne uniquement au premier démarrage du déclencheur, car, lors des exécutions suivantes, les points de contrôle sont déjà stockés. La définition de cette option sur true quand des baux ont déjà été créés est sans effet.
startFromTime (Facultatif) Obtient ou définit la date et l’heure à partir desquelles l’opération de lecture du flux de modification doit être initialisée. Le format recommandé est ISO 8601 avec le désignateur UTC, par exemple 2021-02-16T14:19:29Z. Utilisé uniquement pour définir l’état initial du déclencheur. Une fois que le déclencheur a un état de bail, la modification de cette valeur n’a aucun effet.
preferredLocations (Facultatif) Définit les endroits par défaut (régions) des comptes de base de données géorépliqués dans le service Azure Cosmos DB. Les valeurs doivent être séparées par des virgules. Par exemple, « USA Est, USA Centre Sud, Europe Nord ».

L’exemple suivant montre une liaison de déclencheur Azure Cosmos DB dans un fichier function.json et une fonction de script C# qui utilise la liaison. La fonction écrit des messages de journal quand des enregistrements Azure Cosmos DB sont ajoutés ou modifiés.

Voici les données de liaison dans le fichier function.json :

{
    "type": "cosmosDBTrigger",
    "name": "documents",
    "direction": "in",
    "leaseContainerName": "leases",
    "connection": "<connection-app-setting>",
    "databaseName": "Tasks",
    "containerName": "Items",
    "createLeaseContainerIfNotExists": true
}

Voici le code Script C# :

    using System;
    using System.Collections.Generic;
    using Microsoft.Extensions.Logging;

    // Customize the model with your own desired properties
    public class ToDoItem
    {
        public string id { get; set; }
        public string Description { get; set; }
    }

    public static void Run(IReadOnlyList<ToDoItem> documents, ILogger log)
    {
      log.LogInformation("Documents modified " + documents.Count);
      log.LogInformation("First document Id " + documents[0].id);
    }

Entrée Azure Cosmos DB v2

Cette section décrit la prise en charge de la version 4.x+ de l'extension uniquement.

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 cosmosDB.
direction Cette propriété doit être définie sur in.
name Nom de variable utilisé dans le code de fonction, qui représente la liste des documents modifiés.
connection Nom d’un paramètre d’application ou d’un conteneur de paramètres qui spécifie la façon de se connecter au compte Azure Cosmos DB qui est surveillé. Pour plus d’informations, consultez Connexions.
databaseName Nom de la base de données Azure Cosmos DB contenant le conteneur analysé.
containerName Nom du conteneur surveillé.
partitionKey Spécifie la valeur de la clé de partition pour la recherche. Peut inclure des paramètres de liaison. Requis pour les recherches dans les conteneurs partitionnés.
id ID du document à récupérer. Cette propriété prend en charge les expressions de liaison. Ne définissez pas à la fois les propriétés id et sqlQuery. Si vous ne définissez aucun des deux, l’ensemble du conteneur est récupéré.
sqlQuery Requête SQL Azure Cosmos DB utilisée pour récupérer plusieurs documents. La propriété prend en charge les liaisons d’exécution, comme dans cet exemple : SELECT * FROM c where c.departmentId = {departmentId}. Ne définissez pas à la fois les propriétés id et sqlQuery. Si vous ne définissez aucun des deux, l’ensemble du conteneur est récupéré.
preferredLocations (Facultatif) Définit les endroits par défaut (régions) des comptes de base de données géorépliqués dans le service Azure Cosmos DB. Les valeurs doivent être séparées par des virgules. Par exemple : East US,South Central US,North Europe.

Cette section contient les exemples suivants :

Les exemples de déclencheur HTTP font référence à un type ToDoItem simple :

namespace CosmosDBSamplesV2
{
    public class ToDoItem
    {
        public string Id { get; set; }
        public string Description { get; set; }
    }
}

Déclencheur de file d’attente, rechercher l’ID à partir de la chaîne

L’exemple suivant montre une liaison d’entrée Azure Cosmos DB dans un fichier function.json et une fonction de script C# qui utilise la liaison. La fonction lit un document unique et met à jour la valeur texte du document.

Voici les données de liaison dans le fichier function.json :

{
    "name": "inputDocument",
    "type": "cosmosDB",
    "databaseName": "MyDatabase",
    "collectionName": "MyCollection",
    "id" : "{queueTrigger}",
    "partitionKey": "{partition key value}",
    "connectionStringSetting": "MyAccount_COSMOSDB",
    "direction": "in"
}

Voici le code Script C# :

    using System;

    // Change input document contents using Azure Cosmos DB input binding
    public static void Run(string myQueueItem, dynamic inputDocument)
    {
      inputDocument.text = "This has changed.";
    }

Déclencheur de file d’attente, obtenir plusieurs documents, utilisation de SqlQuery

L’exemple suivant montre une liaison d’entrée Azure Cosmos DB dans un fichier function.json et une fonction de script C# qui utilise la liaison. La fonction récupère plusieurs documents spécifiés par une requête SQL, à l’aide d’un déclencheur de file d’attente pour personnaliser les paramètres de requête.

Le déclencheur de file d’attente fournit un paramètre departmentId. Un message de file d’attente de { "departmentId" : "Finance" } retourne tous les enregistrements du service financier.

Voici les données de liaison dans le fichier function.json :

{
    "name": "documents",
    "type": "cosmosDB",
    "direction": "in",
    "databaseName": "MyDb",
    "collectionName": "MyCollection",
    "sqlQuery": "SELECT * from c where c.departmentId = {departmentId}",
    "connectionStringSetting": "CosmosDBConnection"
}

Voici le code Script C# :

    public static void Run(QueuePayload myQueueItem, IEnumerable<dynamic> documents)
    {
        foreach (var doc in documents)
        {
            // operate on each document
        }
    }

    public class QueuePayload
    {
        public string departmentId { get; set; }
    }

Déclencheur HTTP, rechercher l’ID à partir de la chaîne de requête

L’exemple suivant illustre une fonction de script C# qui récupère un document unique. La fonction est déclenchée par une requête HTTP qui utilise une chaîne de requête pour spécifier l’ID et la valeur de clé de partition à rechercher. Cet ID et cette valeur de clé de partition permettent de récupérer un document ToDoItem à partir de la base de données et de la collection spécifiées.

Voici le fichier function.json :

{
  "bindings": [
    {
      "authLevel": "anonymous",
      "name": "req",
      "type": "httpTrigger",
      "direction": "in",
      "methods": [
        "get",
        "post"
      ]
    },
    {
      "name": "$return",
      "type": "http",
      "direction": "out"
    },
    {
      "type": "cosmosDB",
      "name": "toDoItem",
      "databaseName": "ToDoItems",
      "collectionName": "Items",
      "connectionStringSetting": "CosmosDBConnection",
      "direction": "in",
      "Id": "{Query.id}",
      "PartitionKey" : "{Query.partitionKeyValue}"
    }
  ],
  "disabled": false
}

Voici le code Script C# :

using System.Net;
using Microsoft.Extensions.Logging;

public static HttpResponseMessage Run(HttpRequestMessage req, ToDoItem toDoItem, ILogger log)
{
    log.LogInformation("C# HTTP trigger function processed a request.");

    if (toDoItem == null)
    {
         log.LogInformation($"ToDo item not found");
    }
    else
    {
        log.LogInformation($"Found ToDo item, Description={toDoItem.Description}");
    }
    return req.CreateResponse(HttpStatusCode.OK);
}

Déclencheur HTTP, rechercher l’ID à partir des données d’itinéraire

L’exemple suivant illustre une fonction de script C# qui récupère un document unique. La fonction est déclenchée par une requête HTTP qui utilise des données de routage pour spécifier l’ID et la valeur de clé de partition à rechercher. Cet ID et cette valeur de clé de partition permettent de récupérer un document ToDoItem à partir de la base de données et de la collection spécifiées.

Voici le fichier function.json :

{
  "bindings": [
    {
      "authLevel": "anonymous",
      "name": "req",
      "type": "httpTrigger",
      "direction": "in",
      "methods": [
        "get",
        "post"
      ],
      "route":"todoitems/{partitionKeyValue}/{id}"
    },
    {
      "name": "$return",
      "type": "http",
      "direction": "out"
    },
    {
      "type": "cosmosDB",
      "name": "toDoItem",
      "databaseName": "ToDoItems",
      "collectionName": "Items",
      "connectionStringSetting": "CosmosDBConnection",
      "direction": "in",
      "id": "{id}",
      "partitionKey": "{partitionKeyValue}"
    }
  ],
  "disabled": false
}

Voici le code Script C# :

using System.Net;
using Microsoft.Extensions.Logging;

public static HttpResponseMessage Run(HttpRequestMessage req, ToDoItem toDoItem, ILogger log)
{
    log.LogInformation("C# HTTP trigger function processed a request.");

    if (toDoItem == null)
    {
         log.LogInformation($"ToDo item not found");
    }
    else
    {
        log.LogInformation($"Found ToDo item, Description={toDoItem.Description}");
    }
    return req.CreateResponse(HttpStatusCode.OK);
}

Déclencheur HTTP, obtenir plusieurs documents, utilisation de SqlQuery

L’exemple suivant illustre une fonction de script C# qui récupère une liste de documents. Cette fonction est déclenchée par une requête HTTP. La requête est spécifiée dans la propriété d’attribut SqlQuery.

Voici le fichier function.json :

{
  "bindings": [
    {
      "authLevel": "anonymous",
      "name": "req",
      "type": "httpTrigger",
      "direction": "in",
      "methods": [
        "get",
        "post"
      ]
    },
    {
      "name": "$return",
      "type": "http",
      "direction": "out"
    },
    {
      "type": "cosmosDB",
      "name": "toDoItems",
      "databaseName": "ToDoItems",
      "collectionName": "Items",
      "connectionStringSetting": "CosmosDBConnection",
      "direction": "in",
      "sqlQuery": "SELECT top 2 * FROM c order by c._ts desc"
    }
  ],
  "disabled": false
}

Voici le code Script C# :

using System.Net;
using Microsoft.Extensions.Logging;

public static HttpResponseMessage Run(HttpRequestMessage req, IEnumerable<ToDoItem> toDoItems, ILogger log)
{
    log.LogInformation("C# HTTP trigger function processed a request.");

    foreach (ToDoItem toDoItem in toDoItems)
    {
        log.LogInformation(toDoItem.Description);
    }
    return req.CreateResponse(HttpStatusCode.OK);
}

Déclencheur HTTP, obtenir plusieurs documents, utilisation de DocumentClient

L’exemple suivant illustre une fonction de script C# qui récupère une liste de documents. Cette fonction est déclenchée par une requête HTTP. Le code utilise une instance DocumentClient fournie par la liaisonAzure Cosmos DB pour lire une liste de documents. L’instance DocumentClient peut également être utilisée pour les opérations d’écriture.

Voici le fichier function.json :

{
  "bindings": [
    {
      "authLevel": "anonymous",
      "name": "req",
      "type": "httpTrigger",
      "direction": "in",
      "methods": [
        "get",
        "post"
      ]
    },
    {
      "name": "$return",
      "type": "http",
      "direction": "out"
    },
    {
      "type": "cosmosDB",
      "name": "client",
      "databaseName": "ToDoItems",
      "collectionName": "Items",
      "connectionStringSetting": "CosmosDBConnection",
      "direction": "inout"
    }
  ],
  "disabled": false
}

Voici le code Script C# :

#r "Microsoft.Azure.Documents.Client"

using System.Net;
using Microsoft.Azure.Documents.Client;
using Microsoft.Azure.Documents.Linq;
using Microsoft.Extensions.Logging;

public static async Task<HttpResponseMessage> Run(HttpRequestMessage req, DocumentClient client, ILogger log)
{
    log.LogInformation("C# HTTP trigger function processed a request.");

    Uri collectionUri = UriFactory.CreateDocumentCollectionUri("ToDoItems", "Items");
    string searchterm = req.GetQueryNameValuePairs()
        .FirstOrDefault(q => string.Compare(q.Key, "searchterm", true) == 0)
        .Value;

    if (searchterm == null)
    {
        return req.CreateResponse(HttpStatusCode.NotFound);
    }

    log.LogInformation($"Searching for word: {searchterm} using Uri: {collectionUri.ToString()}");
    IDocumentQuery<ToDoItem> query = client.CreateDocumentQuery<ToDoItem>(collectionUri)
        .Where(p => p.Description.Contains(searchterm))
        .AsDocumentQuery();

    while (query.HasMoreResults)
    {
        foreach (ToDoItem result in await query.ExecuteNextAsync())
        {
            log.LogInformation(result.Description);
        }
    }
    return req.CreateResponse(HttpStatusCode.OK);
}

Sortie Azure Cosmos DB v2

Cette section décrit la prise en charge de la version 4.x+ de l'extension uniquement.

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
connection Nom d’un paramètre d’application ou d’une collection de paramètres qui spécifie la façon de se connecter au compte Azure Cosmos DB qui est surveillé. Pour plus d’informations, consultez Connexions.
databaseName Nom de la base de données Azure Cosmos DB contenant le conteneur analysé.
containerName Nom du conteneur surveillé.
createIfNotExists Valeur booléenne indiquant si le conteneur doit être créé s’il n’existe pas encore. La valeur par défaut est false, car les nouveaux conteneurs sont créés avec un débit réservé, ce qui a des conséquences sur la tarification. Pour plus d’informations, consultez la page relative aux prix appliqués.
partitionKey Lorsque createIfNotExists a la valeur true, définit le chemin de la clé de partition pour le conteneur créé. Peut inclure des paramètres de liaison.
containerThroughput Lorsque createIfNotExists a la valeur true, définit le débit du conteneur créé.
preferredLocations (Facultatif) Définit les endroits par défaut (régions) des comptes de base de données géorépliqués dans le service Azure Cosmos DB. Les valeurs doivent être séparées par des virgules. Par exemple : East US,South Central US,North Europe.

Cette section contient les exemples suivants :

Déclencheur de la file d’attente, écriture d’un document

L’exemple suivant montre une liaison de sortie Azure Cosmos DB dans un fichier function.json et une fonction de script C# qui utilise la liaison. La fonction utilise une liaison d’entrée de file d’attente pour une file d’attente qui reçoit le code JSON au format suivant :

{
    "name": "John Henry",
    "employeeId": "123456",
    "address": "A town nearby"
}

La fonction crée des documents Azure Cosmos DB au format suivant pour chaque enregistrement :

{
    "id": "John Henry-123456",
    "name": "John Henry",
    "employeeId": "123456",
    "address": "A town nearby"
}

Voici les données de liaison dans le fichier function.json :

{
    "name": "employeeDocument",
    "type": "cosmosDB",
    "databaseName": "MyDatabase",
    "collectionName": "MyCollection",
    "createIfNotExists": true,
    "connectionStringSetting": "MyAccount_COSMOSDB",
    "direction": "out"
}

Voici le code Script C# :

    #r "Newtonsoft.Json"

    using Microsoft.Azure.WebJobs.Host;
    using Newtonsoft.Json.Linq;
    using Microsoft.Extensions.Logging;

    public static void Run(string myQueueItem, out object employeeDocument, ILogger log)
    {
      log.LogInformation($"C# Queue trigger function processed: {myQueueItem}");

      dynamic employee = JObject.Parse(myQueueItem);

      employeeDocument = new {
        id = employee.name + "-" + employee.employeeId,
        name = employee.name,
        employeeId = employee.employeeId,
        address = employee.address
      };
    }

Déclencheur de la file d’attente, écriture de documents à l’aide d’IAsyncCollector

Pour créer plusieurs documents, vous pouvez vous lier à ICollector<T> ou IAsyncCollector<T> où T est un des types pris en charge.

Cet exemple fait référence à un type simple ToDoItem :

namespace CosmosDBSamplesV2
{
    public class ToDoItem
    {
        public string id { get; set; }
        public string Description { get; set; }
    }
}

Voici le fichier function.json :

{
  "bindings": [
    {
      "name": "toDoItemsIn",
      "type": "queueTrigger",
      "direction": "in",
      "queueName": "todoqueueforwritemulti",
      "connectionStringSetting": "AzureWebJobsStorage"
    },
    {
      "type": "cosmosDB",
      "name": "toDoItemsOut",
      "databaseName": "ToDoItems",
      "collectionName": "Items",
      "connectionStringSetting": "CosmosDBConnection",
      "direction": "out"
    }
  ],
  "disabled": false
}

Voici le code Script C# :

using System;
using Microsoft.Extensions.Logging;

public static async Task Run(ToDoItem[] toDoItemsIn, IAsyncCollector<ToDoItem> toDoItemsOut, ILogger log)
{
    log.LogInformation($"C# Queue trigger function processed {toDoItemsIn?.Length} items");

    foreach (ToDoItem toDoItem in toDoItemsIn)
    {
        log.LogInformation($"Description={toDoItem.Description}");
        await toDoItemsOut.AddAsync(toDoItem);
    }
}

Déclencheur Azure Cosmos DB v1

L’exemple suivant montre une liaison de déclencheur Azure Cosmos DB dans un fichier function.json et une fonction de script C# qui utilise la liaison. La fonction écrit des messages de journal quand des enregistrements Azure Cosmos DB sont modifiés.

Voici les données de liaison dans le fichier function.json :

{
    "type": "cosmosDBTrigger",
    "name": "documents",
    "direction": "in",
    "leaseCollectionName": "leases",
    "connectionStringSetting": "<connection-app-setting>",
    "databaseName": "Tasks",
    "collectionName": "Items",
    "createLeaseCollectionIfNotExists": true
}

Voici le code Script C# :

    #r "Microsoft.Azure.Documents.Client"
    
    using System;
    using Microsoft.Azure.Documents;
    using System.Collections.Generic;
    

    public static void Run(IReadOnlyList<Document> documents, TraceWriter log)
    {
        log.Info("Documents modified " + documents.Count);
        log.Info("First document Id " + documents[0].Id);
    }

Entrée Azure Cosmos DB v1

Cette section contient les exemples suivants :

Les exemples de déclencheur HTTP font référence à un type ToDoItem simple :

namespace CosmosDBSamplesV1
{
    public class ToDoItem
    {
        public string Id { get; set; }
        public string Description { get; set; }
    }
}

Déclencheur de file d’attente, rechercher l’ID à partir de la chaîne

L’exemple suivant montre une liaison d’entrée Azure Cosmos DB dans un fichier function.json et une fonction de script C# qui utilise la liaison. La fonction lit un document unique et met à jour la valeur texte du document.

Voici les données de liaison dans le fichier function.json :

{
    "name": "inputDocument",
    "type": "documentDB",
    "databaseName": "MyDatabase",
    "collectionName": "MyCollection",
    "id" : "{queueTrigger}",
    "partitionKey": "{partition key value}",
    "connection": "MyAccount_COSMOSDB",
    "direction": "in"
}

Voici le code Script C# :

    using System;

    // Change input document contents using Azure Cosmos DB input binding
    public static void Run(string myQueueItem, dynamic inputDocument)
    {
        inputDocument.text = "This has changed.";
    }

Déclencheur de file d’attente, obtenir plusieurs documents, utilisation de SqlQuery

L’exemple suivant montre une liaison d’entrée Azure Cosmos DB dans un fichier function.json et une fonction de script C# qui utilise la liaison. La fonction récupère plusieurs documents spécifiés par une requête SQL, à l’aide d’un déclencheur de file d’attente pour personnaliser les paramètres de requête.

Le déclencheur de file d’attente fournit un paramètre departmentId. Un message de file d’attente de { "departmentId" : "Finance" } retourne tous les enregistrements du service financier.

Voici les données de liaison dans le fichier function.json :

{
    "name": "documents",
    "type": "documentdb",
    "direction": "in",
    "databaseName": "MyDb",
    "collectionName": "MyCollection",
    "sqlQuery": "SELECT * from c where c.departmentId = {departmentId}",
    "connection": "CosmosDBConnection"
}

Voici le code Script C# :

    public static void Run(QueuePayload myQueueItem, IEnumerable<dynamic> documents)
    {
        foreach (var doc in documents)
        {
            // operate on each document
        }
    }

    public class QueuePayload
    {
        public string departmentId { get; set; }
    }

Déclencheur HTTP, rechercher l’ID à partir de la chaîne de requête

L’exemple suivant illustre une fonction de script C# qui récupère un document unique. La fonction est déclenchée par une requête HTTP qui utilise une chaîne de requête pour spécifier l’ID à rechercher. Cet ID est utilisé pour récupérer un document ToDoItem à partir de la base de données et de la collection spécifiées.

Voici le fichier function.json :

{
  "bindings": [
    {
      "authLevel": "anonymous",
      "name": "req",
      "type": "httpTrigger",
      "direction": "in",
      "methods": [
        "get",
        "post"
      ]
    },
    {
      "name": "$return",
      "type": "http",
      "direction": "out"
    },
    {
      "type": "documentDB",
      "name": "toDoItem",
      "databaseName": "ToDoItems",
      "collectionName": "Items",
      "connection": "CosmosDBConnection",
      "direction": "in",
      "Id": "{Query.id}"
    }
  ],
  "disabled": true
}

Voici le code Script C# :

using System.Net;

public static HttpResponseMessage Run(HttpRequestMessage req, ToDoItem toDoItem, TraceWriter log)
{
    log.Info("C# HTTP trigger function processed a request.");

    if (toDoItem == null)
    {
        log.Info($"ToDo item not found");
    }
    else
    {
        log.Info($"Found ToDo item, Description={toDoItem.Description}");
    }
    return req.CreateResponse(HttpStatusCode.OK);
}

Déclencheur HTTP, rechercher l’ID à partir des données d’itinéraire

L’exemple suivant illustre une fonction de script C# qui récupère un document unique. Cette fonction est déclenchée par une requête HTTP qui utilise des données de routage pour spécifier l’ID à rechercher. Cet ID est utilisé pour récupérer un document ToDoItem à partir de la base de données et de la collection spécifiées.

Voici le fichier function.json :

{
  "bindings": [
    {
      "authLevel": "anonymous",
      "name": "req",
      "type": "httpTrigger",
      "direction": "in",
      "methods": [
        "get",
        "post"
      ],
      "route":"todoitems/{id}"
    },
    {
      "name": "$return",
      "type": "http",
      "direction": "out"
    },
    {
      "type": "documentDB",
      "name": "toDoItem",
      "databaseName": "ToDoItems",
      "collectionName": "Items",
      "connection": "CosmosDBConnection",
      "direction": "in",
      "Id": "{id}"
    }
  ],
  "disabled": false
}

Voici le code Script C# :

using System.Net;

public static HttpResponseMessage Run(HttpRequestMessage req, ToDoItem toDoItem, TraceWriter log)
{
    log.Info("C# HTTP trigger function processed a request.");

    if (toDoItem == null)
    {
        log.Info($"ToDo item not found");
    }
    else
    {
        log.Info($"Found ToDo item, Description={toDoItem.Description}");
    }
    return req.CreateResponse(HttpStatusCode.OK);
}

Déclencheur HTTP, obtenir plusieurs documents, utilisation de SqlQuery

L’exemple suivant illustre une fonction de script C# qui récupère une liste de documents. Cette fonction est déclenchée par une requête HTTP. La requête est spécifiée dans la propriété d’attribut SqlQuery.

Voici le fichier function.json :

{
  "bindings": [
    {
      "authLevel": "anonymous",
      "name": "req",
      "type": "httpTrigger",
      "direction": "in",
      "methods": [
        "get",
        "post"
      ]
    },
    {
      "name": "$return",
      "type": "http",
      "direction": "out"
    },
    {
      "type": "documentDB",
      "name": "toDoItems",
      "databaseName": "ToDoItems",
      "collectionName": "Items",
      "connection": "CosmosDBConnection",
      "direction": "in",
      "sqlQuery": "SELECT top 2 * FROM c order by c._ts desc"
    }
  ],
  "disabled": false
}

Voici le code Script C# :

using System.Net;

public static HttpResponseMessage Run(HttpRequestMessage req, IEnumerable<ToDoItem> toDoItems, TraceWriter log)
{
    log.Info("C# HTTP trigger function processed a request.");

    foreach (ToDoItem toDoItem in toDoItems)
    {
        log.Info(toDoItem.Description);
    }
    return req.CreateResponse(HttpStatusCode.OK);
}

Déclencheur HTTP, obtenir plusieurs documents, utilisation de DocumentClient

L’exemple suivant illustre une fonction de script C# qui récupère une liste de documents. Cette fonction est déclenchée par une requête HTTP. Le code utilise une instance DocumentClient fournie par la liaisonAzure Cosmos DB pour lire une liste de documents. L’instance DocumentClient peut également être utilisée pour les opérations d’écriture.

Voici le fichier function.json :

{
  "bindings": [
    {
      "authLevel": "anonymous",
      "name": "req",
      "type": "httpTrigger",
      "direction": "in",
      "methods": [
        "get",
        "post"
      ]
    },
    {
      "name": "$return",
      "type": "http",
      "direction": "out"
    },
    {
      "type": "documentDB",
      "name": "client",
      "databaseName": "ToDoItems",
      "collectionName": "Items",
      "connection": "CosmosDBConnection",
      "direction": "inout"
    }
  ],
  "disabled": false
}

Voici le code Script C# :

#r "Microsoft.Azure.Documents.Client"

using System.Net;
using Microsoft.Azure.Documents.Client;
using Microsoft.Azure.Documents.Linq;

public static async Task<HttpResponseMessage> Run(HttpRequestMessage req, DocumentClient client, TraceWriter log)
{
    log.Info("C# HTTP trigger function processed a request.");

    Uri collectionUri = UriFactory.CreateDocumentCollectionUri("ToDoItems", "Items");
    string searchterm = req.GetQueryNameValuePairs()
        .FirstOrDefault(q => string.Compare(q.Key, "searchterm", true) == 0)
        .Value;

    if (searchterm == null)
    {
        return req.CreateResponse(HttpStatusCode.NotFound);
    }

    log.Info($"Searching for word: {searchterm} using Uri: {collectionUri.ToString()}");
    IDocumentQuery<ToDoItem> query = client.CreateDocumentQuery<ToDoItem>(collectionUri)
        .Where(p => p.Description.Contains(searchterm))
        .AsDocumentQuery();

    while (query.HasMoreResults)
    {
        foreach (ToDoItem result in await query.ExecuteNextAsync())
        {
            log.Info(result.Description);
        }
    }
    return req.CreateResponse(HttpStatusCode.OK);
}

Sortie Azure Cosmos DB v1

Cette section contient les exemples suivants :

  • Déclencheur de la file d’attente, écriture d’un document
  • Déclencheur de file d’attente, écriture d’un document à l’aide de IAsyncCollector

Déclencheur de la file d’attente, écriture d’un document

L’exemple suivant montre une liaison de sortie Azure Cosmos DB dans un fichier function.json et une fonction de script C# qui utilise la liaison. La fonction utilise une liaison d’entrée de file d’attente pour une file d’attente qui reçoit le code JSON au format suivant :

{
    "name": "John Henry",
    "employeeId": "123456",
    "address": "A town nearby"
}

La fonction crée des documents Azure Cosmos DB au format suivant pour chaque enregistrement :

{
    "id": "John Henry-123456",
    "name": "John Henry",
    "employeeId": "123456",
    "address": "A town nearby"
}

Voici les données de liaison dans le fichier function.json :

{
    "name": "employeeDocument",
    "type": "documentDB",
    "databaseName": "MyDatabase",
    "collectionName": "MyCollection",
    "createIfNotExists": true,
    "connection": "MyAccount_COSMOSDB",
    "direction": "out"
}

Voici le code Script C# :

    #r "Newtonsoft.Json"

    using Microsoft.Azure.WebJobs.Host;
    using Newtonsoft.Json.Linq;

    public static void Run(string myQueueItem, out object employeeDocument, TraceWriter log)
    {
        log.Info($"C# Queue trigger function processed: {myQueueItem}");

        dynamic employee = JObject.Parse(myQueueItem);

        employeeDocument = new {
            id = employee.name + "-" + employee.employeeId,
            name = employee.name,
            employeeId = employee.employeeId,
            address = employee.address
        };
    }

Déclencheur de la file d’attente, écriture de documents à l’aide d’IAsyncCollector

Pour créer plusieurs documents, vous pouvez vous lier à ICollector<T> ou IAsyncCollector<T> où T est un des types pris en charge.

Cet exemple fait référence à un type simple ToDoItem :

namespace CosmosDBSamplesV1
{
    public class ToDoItem
    {
        public string Id { get; set; }
        public string Description { get; set; }
    }
}

Voici le fichier function.json :

{
  "bindings": [
    {
      "name": "toDoItemsIn",
      "type": "queueTrigger",
      "direction": "in",
      "queueName": "todoqueueforwritemulti",
      "connection": "AzureWebJobsStorage"
    },
    {
      "type": "documentDB",
      "name": "toDoItemsOut",
      "databaseName": "ToDoItems",
      "collectionName": "Items",
      "connection": "CosmosDBConnection",
      "direction": "out"
    }
  ],
  "disabled": false
}

Voici le code Script C# :

using System;

public static async Task Run(ToDoItem[] toDoItemsIn, IAsyncCollector<ToDoItem> toDoItemsOut, TraceWriter log)
{
    log.Info($"C# Queue trigger function processed {toDoItemsIn?.Length} items");

    foreach (ToDoItem toDoItem in toDoItemsIn)
    {
        log.Info($"Description={toDoItem.Description}");
        await toDoItemsOut.AddAsync(toDoItem);
    }
}

Déclencheur Azure SQL

D’autres exemples du déclencheur Azure SQL sont disponibles dans le dépôt GitHub.

Les exemples font référence à une classe ToDoItem et à une table de base de données correspondante :

namespace AzureSQL.ToDo
{
    public class ToDoItem
    {
        public Guid Id { get; set; }
        public int? order { get; set; }
        public string title { get; set; }
        public string url { get; set; }
        public bool? completed { get; set; }
    }
}

CREATE TABLE dbo.ToDo (
    [Id] UNIQUEIDENTIFIER PRIMARY KEY,
    [order] INT NULL,
    [title] NVARCHAR(200) NOT NULL,
    [url] NVARCHAR(200) NOT NULL,
    [completed] BIT NOT NULL
);

Le suivi des changements est activé sur la base de données et sur la table :

ALTER DATABASE [SampleDatabase]
SET CHANGE_TRACKING = ON
(CHANGE_RETENTION = 2 DAYS, AUTO_CLEANUP = ON);

ALTER TABLE [dbo].[ToDo]
ENABLE CHANGE_TRACKING;

Le déclencheur SQL est lié à un IReadOnlyList<SqlChange<T>>, une liste d’objets SqlChange avec chacun deux propriétés :

  • Item : l’élément qui a changé. Le type de l’élément doit suivre le schéma de table de la classe ToDoItem.
  • Operation : valeur de l’enum SqlChangeOperation. Les valeurs possibles sont : Insert, Update et Delete.

L’exemple suivant montre un déclencheur SQL dans un fichier function.json et une fonction de script C# qui est appelée en cas de changements apportés à la table ToDo :

L’exemple suivant montre une liaison de données dans le fichier function.json :

{
    "name": "todoChanges",
    "type": "sqlTrigger",
    "direction": "in",
    "tableName": "dbo.ToDo",
    "connectionStringSetting": "SqlConnectionString"
}

Voici la fonction de script C# :

#r "Newtonsoft.Json"

using System.Net;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Extensions.Primitives;
using Newtonsoft.Json;

public static void Run(IReadOnlyList<SqlChange<ToDoItem>> todoChanges, ILogger log)
{
    log.LogInformation($"C# SQL trigger function processed a request.");

    foreach (SqlChange<ToDoItem> change in todoChanges)
    {
        ToDoItem toDoItem = change.Item;
        log.LogInformation($"Change operation: {change.Operation}");
        log.LogInformation($"Id: {toDoItem.Id}, Title: {toDoItem.title}, Url: {toDoItem.url}, Completed: {toDoItem.completed}");
    }
}

Entrée Azure SQL

D’autres exemples pour la liaison d’entrée Azure SQL sont disponibles dans le dépôt GitHub.

Cette section contient les exemples suivants :

Les exemples font référence à une classe ToDoItem et à une table de base de données correspondante :

namespace AzureSQL.ToDo
{
    public class ToDoItem
    {
        public Guid Id { get; set; }
        public int? order { get; set; }
        public string title { get; set; }
        public string url { get; set; }
        public bool? completed { get; set; }
    }
}

CREATE TABLE dbo.ToDo (
    [Id] UNIQUEIDENTIFIER PRIMARY KEY,
    [order] INT NULL,
    [title] NVARCHAR(200) NOT NULL,
    [url] NVARCHAR(200) NOT NULL,
    [completed] BIT NOT NULL
);

Déclencheur HTTP, obtenir une ligne par ID à partir de la chaîne de requête

L’exemple suivant montre une liaison d’entrée Azure SQL dans un fichier function.json et une fonction de script C# qui utilise la liaison. La fonction est déclenchée par une requête HTTP qui utilise une chaîne de requête pour spécifier l’ID à rechercher. Cet ID est utilisé pour récupérer un ToDoItemenregistrement avec la requête spécifiée.

Notes

Le paramètre de chaîne de requête HTTP respecte la casse.

Voici les données de liaison dans le fichier function.json :

{
    "authLevel": "anonymous",
    "type": "httpTrigger",
    "direction": "in",
    "name": "req",
    "methods": [
        "get"
    ]
},
{
    "type": "http",
    "direction": "out",
    "name": "res"
},
{
    "name": "todoItem",
    "type": "sql",
    "direction": "in",
    "commandText": "select [Id], [order], [title], [url], [completed] from dbo.ToDo where Id = @Id",
    "commandType": "Text",
    "parameters": "@Id = {Query.id}",
    "connectionStringSetting": "SqlConnectionString"
}

Voici le code Script C# :

#r "Newtonsoft.Json"

using System.Net;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Extensions.Primitives;
using Newtonsoft.Json;
using System.Collections.Generic;

public static IActionResult Run(HttpRequest req, ILogger log, IEnumerable<ToDoItem> todoItem)
{
    return new OkObjectResult(todoItem);
}

déclencheur HTTP, supprimer les lignes

L’exemple suivant montre une liaison d’entrée Azure SQL dans un fichier function.json et une fonction de script C# qui utilise la liaison pour exécuter une procédure stockée avec une entrée à partir du paramètre de requête de la demande HTTP. Dans cet exemple, la procédure stockée supprime un enregistrement unique ou tous les enregistrements en fonction de la valeur du paramètre.

La procédure stockée dbo.DeleteToDo doit être créée sur la base de données SQL.

CREATE PROCEDURE [dbo].[DeleteToDo]
    @Id NVARCHAR(100)
AS
    DECLARE @UID UNIQUEIDENTIFIER = TRY_CAST(@ID AS UNIQUEIDENTIFIER)
    IF @UId IS NOT NULL AND @Id != ''
    BEGIN
        DELETE FROM dbo.ToDo WHERE Id = @UID
    END
    ELSE
    BEGIN
        DELETE FROM dbo.ToDo WHERE @ID = ''
    END

    SELECT [Id], [order], [title], [url], [completed] FROM dbo.ToDo
GO

Voici les données de liaison dans le fichier function.json :

{
    "authLevel": "anonymous",
    "type": "httpTrigger",
    "direction": "in",
    "name": "req",
    "methods": [
        "get"
    ]
},
{
    "type": "http",
    "direction": "out",
    "name": "res"
},
{
    "name": "todoItems",
    "type": "sql",
    "direction": "in",
    "commandText": "DeleteToDo",
    "commandType": "StoredProcedure",
    "parameters": "@Id = {Query.id}",
    "connectionStringSetting": "SqlConnectionString"
}

using System;
using System.Collections.Generic;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Azure.WebJobs;
using Microsoft.Azure.WebJobs.Extensions.Http;
using Microsoft.AspNetCore.Http;
using Microsoft.Extensions.Logging;

namespace AzureSQL.ToDo
{
    public static class DeleteToDo
    {
        // delete all items or a specific item from querystring
        // returns remaining items
        // uses input binding with a stored procedure DeleteToDo to delete items and return remaining items
        [FunctionName("DeleteToDo")]
        public static IActionResult Run(
            [HttpTrigger(AuthorizationLevel.Anonymous, "delete", Route = "DeleteFunction")] HttpRequest req,
            ILogger log,
            [Sql(commandText: "DeleteToDo", commandType: System.Data.CommandType.StoredProcedure, 
                parameters: "@Id={Query.id}", connectionStringSetting: "SqlConnectionString")] 
                IEnumerable<ToDoItem> toDoItems)
        {
            return new OkObjectResult(toDoItems);
        }
    }
}

Voici le code Script C# :

#r "Newtonsoft.Json"

using System.Net;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Extensions.Primitives;
using Newtonsoft.Json;
using System.Collections.Generic;

public static IActionResult Run(HttpRequest req, ILogger log, IEnumerable<ToDoItem> todoItems)
{
    return new OkObjectResult(todoItems);
}

Sortie Azure SQL

D’autres exemples pour la liaison de sortie Azure SQL sont disponibles dans le dépôt GitHub.

Cette section contient les exemples suivants :

Les exemples font référence à une classe ToDoItem et à une table de base de données correspondante :

namespace AzureSQL.ToDo
{
    public class ToDoItem
    {
        public Guid Id { get; set; }
        public int? order { get; set; }
        public string title { get; set; }
        public string url { get; set; }
        public bool? completed { get; set; }
    }
}

CREATE TABLE dbo.ToDo (
    [Id] UNIQUEIDENTIFIER PRIMARY KEY,
    [order] INT NULL,
    [title] NVARCHAR(200) NOT NULL,
    [url] NVARCHAR(200) NOT NULL,
    [completed] BIT NOT NULL
);

Déclencheur HTTP, écriture d’enregistrements dans une table

L’exemple suivant montre une liaison de sortie SQL dans un fichier function.json, ainsi qu’une fonction Script C# qui ajoute des enregistrements dans une table, en utilisant les données fournies dans une requête HTTP POST comme corps JSON.

L’exemple suivant montre une liaison de données dans le fichier function.json :

{
    "authLevel": "anonymous",
    "type": "httpTrigger",
    "direction": "in",
    "name": "req",
    "methods": [
        "post"
    ]
},
{
    "type": "http",
    "direction": "out",
    "name": "res"
},
{
    "name": "todoItem",
    "type": "sql",
    "direction": "out",
    "commandText": "dbo.ToDo",
    "connectionStringSetting": "SqlConnectionString"
}

Voici un exemple de code de script C# :

#r "Newtonsoft.Json"

using System.Net;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Extensions.Primitives;
using Newtonsoft.Json;

public static IActionResult Run(HttpRequest req, ILogger log, out ToDoItem todoItem)
{
    log.LogInformation("C# HTTP trigger function processed a request.");

    string requestBody = new StreamReader(req.Body).ReadToEnd();
    todoItem = JsonConvert.DeserializeObject<ToDoItem>(requestBody);

    return new OkObjectResult(todoItem);
}

Déclencheur HTTP, écriture dans deux tables

L’exemple suivant montre une liaison de sortie SQL dans un fichier function.json, ainsi qu’une fonction Script C# qui ajoute des enregistrements dans deux tables différentes (dbo.ToDo et dbo.RequestLog) d’une base de données, en utilisant les données fournies dans une requête HTTP POST comme corps JSON et plusieurs liaisons de sortie.

La seconde table, dbo.RequestLog, correspond à la définition suivante :

CREATE TABLE dbo.RequestLog (
    Id int identity(1,1) primary key,
    RequestTimeStamp datetime2 not null,
    ItemCount int not null
)

L’exemple suivant montre une liaison de données dans le fichier function.json :

{
    "authLevel": "anonymous",
    "type": "httpTrigger",
    "direction": "in",
    "name": "req",
    "methods": [
        "post"
    ]
},
{
    "type": "http",
    "direction": "out",
    "name": "res"
},
{
    "name": "todoItem",
    "type": "sql",
    "direction": "out",
    "commandText": "dbo.ToDo",
    "connectionStringSetting": "SqlConnectionString"
},
{
    "name": "requestLog",
    "type": "sql",
    "direction": "out",
    "commandText": "dbo.RequestLog",
    "connectionStringSetting": "SqlConnectionString"
}

Voici un exemple de code de script C# :

#r "Newtonsoft.Json"

using System.Net;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Extensions.Primitives;
using Newtonsoft.Json;

public static IActionResult Run(HttpRequest req, ILogger log, out ToDoItem todoItem, out RequestLog requestLog)
{
    log.LogInformation("C# HTTP trigger function processed a request.");

    string requestBody = new StreamReader(req.Body).ReadToEnd();
    todoItem = JsonConvert.DeserializeObject<ToDoItem>(requestBody);

    requestLog = new RequestLog();
    requestLog.RequestTimeStamp = DateTime.Now;
    requestLog.ItemCount = 1;

    return new OkObjectResult(todoItem);
}

public class RequestLog {
    public DateTime RequestTimeStamp { get; set; }
    public int ItemCount { get; set; }
}

Sortie RabbitMQ

L’exemple suivant montre une liaison de sortie RabbitMQ dans un fichier function.json, et une fonction de script C# qui utilise la liaison. La fonction lit le message d’un déclencheur HTTP et l’envoie à la file d’attente RabbitMQ.

Voici les données de liaison dans le fichier function.json :

{
    "bindings": [
        {
            "type": "httpTrigger",
            "direction": "in",
            "authLevel": "function",
            "name": "input",
            "methods": [
                "get",
                "post"
            ]
        },
        {
            "type": "rabbitMQ",
            "name": "outputMessage",
            "queueName": "outputQueue",
            "connectionStringSetting": "rabbitMQConnectionAppSetting",
            "direction": "out"
        }
    ]
}

Voici le code Script C# :

using System;
using Microsoft.Extensions.Logging;

public static void Run(string input, out string outputMessage, ILogger log)
{
    log.LogInformation(input);
    outputMessage = input;
}

Sortie de SendGrid

L’exemple suivant montre une liaison de sortie SendGrid dans un fichier function.json et une fonction de script C# qui utilise la liaison.

Voici les données de liaison dans le fichier function.json :

{
    "bindings": [
        {
          "type": "queueTrigger",
          "name": "mymsg",
          "queueName": "myqueue",
          "connection": "AzureWebJobsStorage",
          "direction": "in"
        },
        {
          "type": "sendGrid",
          "name": "$return",
          "direction": "out",
          "apiKey": "SendGridAPIKeyAsAppSetting",
          "from": "{FromEmail}",
          "to": "{ToEmail}"
        }
    ]
}

Voici le code Script C# :

#r "SendGrid"

using System;
using SendGrid.Helpers.Mail;
using Microsoft.Azure.WebJobs.Host;

public static SendGridMessage Run(Message mymsg, ILogger log)
{
    SendGridMessage message = new SendGridMessage()
    {
        Subject = $"{mymsg.Subject}"
    };
    
    message.AddContent("text/plain", $"{mymsg.Content}");

    return message;
}
public class Message
{
    public string ToEmail { get; set; }
    public string FromEmail { get; set; }
    public string Subject { get; set; }
    public string Content { get; set; }
}

Déclencheur SignalR

Voici un exemple de données de liaison dans le fichier function.json :

{
    "type": "signalRTrigger",
    "name": "invocation",
    "hubName": "SignalRTest",
    "category": "messages",
    "event": "SendMessage",
    "parameterNames": [
        "message"
    ],
    "direction": "in"
}

Voici le code :

#r "Microsoft.Azure.WebJobs.Extensions.SignalRService"
using System;
using Microsoft.Azure.WebJobs.Extensions.SignalRService;
using Microsoft.Extensions.Logging;

public static void Run(InvocationContext invocation, string message, ILogger logger)
{
    logger.LogInformation($"Receive {message} from {invocationContext.ConnectionId}.");
}

Entrée SignalR

L’exemple suivant montre une liaison d’entrée d’informations de connexion SignalR dans un fichier function.json et une fonction de script C# qui utilise la liaison pour retourner les informations de connexion.

Voici les données de liaison dans le fichier function.json :

Exemple de fichier function.json :

{
    "type": "signalRConnectionInfo",
    "name": "connectionInfo",
    "hubName": "chat",
    "connectionStringSetting": "<name of setting containing SignalR Service connection string>",
    "direction": "in"
}

Voici le code de script C# :

#r "Microsoft.Azure.WebJobs.Extensions.SignalRService"
using Microsoft.Azure.WebJobs.Extensions.SignalRService;

public static SignalRConnectionInfo Run(HttpRequest req, SignalRConnectionInfo connectionInfo)
{
    return connectionInfo;
}

Vous pouvez définir la propriété userId de la liaison sur la valeur de l’un des en-têtes à l’aide d’une expression de liaison : {headers.x-ms-client-principal-id} ou {headers.x-ms-client-principal-name}.

Exemple de fichier function.json :

{
    "type": "signalRConnectionInfo",
    "name": "connectionInfo",
    "hubName": "chat",
    "userId": "{headers.x-ms-client-principal-id}",
    "connectionStringSetting": "<name of setting containing SignalR Service connection string>",
    "direction": "in"
}

Voici le code de script C# :

#r "Microsoft.Azure.WebJobs.Extensions.SignalRService"
using Microsoft.Azure.WebJobs.Extensions.SignalRService;

public static SignalRConnectionInfo Run(HttpRequest req, SignalRConnectionInfo connectionInfo)
{
    // connectionInfo contains an access key token with a name identifier
    // claim set to the authenticated user
    return connectionInfo;
}

Sortie SignalR

Voici les données de liaison dans le fichier function.json :

Exemple de fichier function.json :

{
  "type": "signalR",
  "name": "signalRMessages",
  "hubName": "<hub_name>",
  "connectionStringSetting": "<name of setting containing SignalR Service connection string>",
  "direction": "out"
}

Voici le code de script C# :

#r "Microsoft.Azure.WebJobs.Extensions.SignalRService"
using Microsoft.Azure.WebJobs.Extensions.SignalRService;

public static Task Run(
    object message,
    IAsyncCollector<SignalRMessage> signalRMessages)
{
    return signalRMessages.AddAsync(
        new SignalRMessage
        {
            Target = "newMessage",
            Arguments = new [] { message }
        });
}

Vous ne pouvez envoyer un message qu’aux connexions qui ont été authentifiées comme un utilisateur en définissant l’ID d’utilisateur du message SignalR.

Exemple de fichier function.json :

{
  "type": "signalR",
  "name": "signalRMessages",
  "hubName": "<hub_name>",
  "connectionStringSetting": "<name of setting containing SignalR Service connection string>",
  "direction": "out"
}

Voici le code Script C# :

#r "Microsoft.Azure.WebJobs.Extensions.SignalRService"
using Microsoft.Azure.WebJobs.Extensions.SignalRService;

public static Task Run(
    object message,
    IAsyncCollector<SignalRMessage> signalRMessages)
{
    return signalRMessages.AddAsync(
        new SignalRMessage
        {
            // the message will only be sent to this user ID
            UserId = "userId1",
            Target = "newMessage",
            Arguments = new [] { message }
        });
}

Vous ne pouvez envoyer un message qu’aux connexions qui ont été ajoutées à un groupe en définissant le nom de groupe du message SignalR.

Exemple de fichier function.json :

{
  "type": "signalR",
  "name": "signalRMessages",
  "hubName": "<hub_name>",
  "connectionStringSetting": "<name of setting containing SignalR Service connection string>",
  "direction": "out"
}

Voici le code de script C# :

#r "Microsoft.Azure.WebJobs.Extensions.SignalRService"
using Microsoft.Azure.WebJobs.Extensions.SignalRService;

public static Task Run(
    object message,
    IAsyncCollector<SignalRMessage> signalRMessages)
{
    return signalRMessages.AddAsync(
        new SignalRMessage
        {
            // the message will be sent to the group with this name
            GroupName = "myGroup",
            Target = "newMessage",
            Arguments = new [] { message }
        });
}

SignalR Service permet aux utilisateurs ou aux connexions d’être ajoutés à des groupes. Des messages peuvent ensuite être envoyés au groupe. Vous pouvez utiliser la sortie de liaison SignalR pour gérer les groupes.

L’exemple suivant ajoute un utilisateur à un groupe.

Exemple de fichier function.json

{
    "type": "signalR",
    "name": "signalRGroupActions",
    "connectionStringSetting": "<name of setting containing SignalR Service connection string>",
    "hubName": "chat",
    "direction": "out"
}

Run.csx

#r "Microsoft.Azure.WebJobs.Extensions.SignalRService"
using Microsoft.Azure.WebJobs.Extensions.SignalRService;

public static Task Run(
    HttpRequest req,
    ClaimsPrincipal claimsPrincipal,
    IAsyncCollector<SignalRGroupAction> signalRGroupActions)
{
    var userIdClaim = claimsPrincipal.FindFirst(ClaimTypes.NameIdentifier);
    return signalRGroupActions.AddAsync(
        new SignalRGroupAction
        {
            UserId = userIdClaim.Value,
            GroupName = "myGroup",
            Action = GroupAction.Add
        });
}

L’exemple suivant supprime un utilisateur d’un groupe.

Exemple de fichier function.json

{
    "type": "signalR",
    "name": "signalRGroupActions",
    "connectionStringSetting": "<name of setting containing SignalR Service connection string>",
    "hubName": "chat",
    "direction": "out"
}

Run.csx

#r "Microsoft.Azure.WebJobs.Extensions.SignalRService"
using Microsoft.Azure.WebJobs.Extensions.SignalRService;

public static Task Run(
    HttpRequest req,
    ClaimsPrincipal claimsPrincipal,
    IAsyncCollector<SignalRGroupAction> signalRGroupActions)
{
    var userIdClaim = claimsPrincipal.FindFirst(ClaimTypes.NameIdentifier);
    return signalRGroupActions.AddAsync(
        new SignalRGroupAction
        {
            UserId = userIdClaim.Value,
            GroupName = "myGroup",
            Action = GroupAction.Remove
        });
}

Sortie de Twilio

L’exemple suivant montre une liaison de sortie Twilio dans un fichier function.json et une fonction de script C# qui utilise la liaison. La fonction utilise un paramètre out pour envoyer un SMS.

Voici les données de liaison dans le fichier function.json :

Exemple de fichier function.json :

{
  "type": "twilioSms",
  "name": "message",
  "accountSidSetting": "TwilioAccountSid",
  "authTokenSetting": "TwilioAuthToken",
  "from": "+1425XXXXXXX",
  "direction": "out",
  "body": "Azure Functions Testing"
}

Voici le code du script C# :

#r "Newtonsoft.Json"
#r "Twilio"
#r "Microsoft.Azure.WebJobs.Extensions.Twilio"

using System;
using Microsoft.Extensions.Logging;
using Newtonsoft.Json;
using Microsoft.Azure.WebJobs.Extensions.Twilio;
using Twilio.Rest.Api.V2010.Account;
using Twilio.Types;

public static void Run(string myQueueItem, out CreateMessageOptions message,  ILogger log)
{
    log.LogInformation($"C# Queue trigger function processed: {myQueueItem}");

    // In this example the queue item is a JSON string representing an order that contains the name of a
    // customer and a mobile number to send text updates to.
    dynamic order = JsonConvert.DeserializeObject(myQueueItem);
    string msg = "Hello " + order.name + ", thank you for your order.";

    // You must initialize the CreateMessageOptions variable with the "To" phone number.
    message = new CreateMessageOptions(new PhoneNumber("+1704XXXXXXX"));

    // A dynamic message can be set instead of the body in the output binding. In this example, we use
    // the order information to personalize a text message.
    message.Body = msg;
}

Vous ne pouvez pas utiliser de paramètres de sortie dans du code asynchrone. Voici un exemple de code de script C# asynchrone :

#r "Newtonsoft.Json"
#r "Twilio"
#r "Microsoft.Azure.WebJobs.Extensions.Twilio"

using System;
using Microsoft.Extensions.Logging;
using Newtonsoft.Json;
using Microsoft.Azure.WebJobs.Extensions.Twilio;
using Twilio.Rest.Api.V2010.Account;
using Twilio.Types;

public static async Task Run(string myQueueItem, IAsyncCollector<CreateMessageOptions> message,  ILogger log)
{
    log.LogInformation($"C# Queue trigger function processed: {myQueueItem}");

    // In this example the queue item is a JSON string representing an order that contains the name of a
    // customer and a mobile number to send text updates to.
    dynamic order = JsonConvert.DeserializeObject(myQueueItem);
    string msg = "Hello " + order.name + ", thank you for your order.";

    // You must initialize the CreateMessageOptions variable with the "To" phone number.
    CreateMessageOptions smsText = new CreateMessageOptions(new PhoneNumber("+1704XXXXXXX"));

    // A dynamic message can be set instead of the body in the output binding. In this example, we use
    // the order information to personalize a text message.
    smsText.Body = msg;

    await message.AddAsync(smsText);
}

Déclencheur de préchauffage

L’exemple suivant montre un déclencheur de préchauffage dans un fichier function.json et une fonction de script C# qui s’exécute sur chaque nouvelle instance quand elle est ajoutée à votre application.

Non pris en charge pour la version 1.x du runtime Functions.

Voici le fichier function.json :

{
    "bindings": [
        {
            "type": "warmupTrigger",
            "direction": "in",
            "name": "warmupContext"
        }
    ]
}

public static void Run(WarmupContext warmupContext, ILogger log)
{
    log.LogInformation("Function App instance is warm.");  
}

Étapes suivantes

En savoir plus sur les déclencheurs et les liaisons

En savoir plus sur les meilleures pratiques pour Azure Functions