Informations de référence pour les développeurs F# sur Azure FunctionsAzure Functions F# Developer Reference

F# for Azure Functions est une solution conçue pour exécuter facilement de petits morceaux de code, ou « fonctions », dans le cloud.F# for Azure Functions is a solution for easily running small pieces of code, or "functions," in the cloud. Les données circulent dans votre fonction F# par le biais d’arguments de fonction.Data flows into your F# function via function arguments. Les noms d’argument sont spécifiés dans 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.Argument names are specified in function.json, and there are predefined names for accessing things like the function logger and cancellation tokens.

Important

Le script F# (.fsx) est pris en charge uniquement par la version 1.x du runtime Azure Functions.F# script (.fsx) is only supported by version 1.x of the Azure Functions runtime. Si vous voulez utiliser F# avec la version 2.x et ultérieure du runtime, vous devez utiliser un projet de bibliothèque de classes F# précompilé (.fs).If you want to use F# with version 2.x and later versions of the runtime, you must use a precompiled F# class library project (.fs). Vous créez, gérez et publiez un projet de bibliothèque de classes F# en utilisant Visual Studio comme vous le feriez pour un projet de bibliothèque de classes C# .You create, manage, and publish an F# class library project using Visual Studio as you would a C# class library project. Pour plus d’informations sur les versions de Functions, consultez Vue d’ensemble des versions du runtime Azure Functions.For more information about Functions versions, see Azure Functions runtime versions overview.

Cet article suppose que vous ayez déjà lu l’article Informations de référence pour les développeurs sur Azure Functions.This article assumes that you've already read the Azure Functions developer reference.

Fonctionnement de .fsxHow .fsx works

Un fichier .fsx est un script F#.An .fsx file is an F# script. Il peut être considéré comme un projet F# contenu dans un seul fichier.It can be thought of as an F# project that's contained in a single file. Ce fichier contient à la fois le code de votre programme (dans ce cas précis, votre fonction Azure) et des directives concernant la gestion des dépendances.The file contains both the code for your program (in this case, your Azure Function) and directives for managing dependencies.

Lorsque vous utilisez un fichier .fsx pour une fonction Azure, les assemblys généralement requis sont automatiquement inclus à votre intention, ce qui vous permet de vous concentrer sur la fonction plutôt que sur le code « réutilisable ».When you use an .fsx for an Azure Function, commonly required assemblies are automatically included for you, allowing you to focus on the function rather than "boilerplate" code.

Structure de dossiersFolder structure

La structure de dossiers pour un projet de script F# est similaire à la structure ci-après :The folder structure for an F# script project looks like the following:

FunctionsProject
 | - MyFirstFunction
 | | - run.fsx
 | | - function.json
 | | - function.proj
 | - MySecondFunction
 | | - run.fsx
 | | - 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.There's a shared host.json file that can be used to configure the function app. Chaque fonction a son propre fichier de code (.fsx) et un fichier de configuration de liaison (function.json).Each function has its own code file (.fsx) and binding configuration file (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.The binding extensions required in version 2.x and later versions of the Functions runtime are defined in the extensions.csproj file, with the actual library files in the bin folder. Quand vous développez localement, vous devez inscrire les extensions de liaison.When developing locally, you must register binding extensions. Quand vous développez des fonctions dans le portail Azure, cet enregistrement est effectué pour vous.When developing functions in the Azure portal, this registration is done for you.

Liaison aux argumentsBinding to arguments

Chaque liaison prend en charge un ensemble spécifique d’arguments, comme décrit en détail dans Informations de référence pour les développeurs sur les déclencheurs et liaisons Azure Functions.Each binding supports some set of arguments, as detailed in the Azure Functions triggers and bindings developer reference. Par exemple, l’une des liaisons d’argument prises en charge par un déclencheur d’objet blob est un objet CLR traditionnel (POCO), qui peut être exprimé à l’aide d’un enregistrement F#.For example, one of the argument bindings a blob trigger supports is a POCO, which can be expressed using an F# record. Par exemple :For example:

type Item = { Id: string }

let Run(blob: string, output: byref<Item>) =
    let item = { Id = "Some ID" }
    output <- item

Votre fonction Azure F# utilisera un ou plusieurs arguments.Your F# Azure Function will take one or more arguments. Quand nous parlons d’arguments Azure Functions, nous faisons référence à des arguments d’entrée et à des arguments de sortie.When we talk about Azure Functions arguments, we refer to input arguments and output arguments. Un argument d’entrée est exactement ce que son nom laisse entendre : une entrée pour votre fonction Azure F#.An input argument is exactly what it sounds like: input to your F# Azure Function. Un argument de sortie correspond à des données mutables ou à un argument byref<> permettant de retransmettre des données hors de votre fonction.An output argument is mutable data or a byref<> argument that serves as a way to pass data back out of your function.

Dans l’exemple ci-dessus, blob est un argument d’entrée, tandis que output est un argument de sortie.In the example above, blob is an input argument, and output is an output argument. Notez que nous avons utilisé le type byref<> pour l’argument output (il n’est pas nécessaire d’ajouter l’annotation [<Out>]).Notice that we used byref<> for output (there's no need to add the [<Out>] annotation). L’utilisation d’un type byref<> permet à votre fonction de modifier l’enregistrement ou l’objet auxquels l’argument fait référence.Using a byref<> type allows your function to change which record or object the argument refers to.

Lorsqu’un enregistrement F# est utilisé comme type d’entrée, la définition d’enregistrement doit être indiquée par [<CLIMutable>] pour permettre à l’infrastructure Azure Functions de définir les champs de manière appropriée avant de transmettre l’enregistrement à votre fonction.When an F# record is used as an input type, the record definition must be marked with [<CLIMutable>] in order to allow the Azure Functions framework to set the fields appropriately before passing the record to your function. En arrière-plan, [<CLIMutable>] génère des méthodes setter pour les propriétés d’enregistrement.Under the hood, [<CLIMutable>] generates setters for the record properties. Par exemple :For example:

[<CLIMutable>]
type TestObject =
    { SenderName : string
      Greeting : string }

let Run(req: TestObject, log: ILogger) =
    { req with Greeting = sprintf "Hello, %s" req.SenderName }

Une classe F# est également utilisable pour les arguments d’entrée et de sortie.An F# class can also be used for both in and out arguments. Pour une classe, les propriétés nécessitent généralement des méthodes getter et setter.For a class, properties will usually need getters and setters. Par exemple :For example:

type Item() =
    member val Id = "" with get,set
    member val Text = "" with get,set

let Run(input: string, item: byref<Item>) =
    let result = Item(Id = input, Text = "Hello from F#!")
    item <- result

JournalisationLogging

Pour consigner la sortie dans vos journaux d’activité de streaming en F#, votre fonction doit utiliser un argument de type ILogger.To log output to your streaming logs in F#, your function should take an argument of type ILogger. Par souci de cohérence, nous vous recommandons de nommer cet argument log.For consistency, we recommend this argument is named log. Par exemple :For example:

let Run(blob: string, output: byref<string>, log: ILogger) =
    log.LogInformation(sprintf "F# Azure Function processed a blob: %s" blob)
    output <- input

AsyncAsync

Il est possible d’utiliser le workflow async, mais le résultat doit renvoyer un élément Task.The async workflow can be used, but the result needs to return a Task. Pour ce faire, utilisez Async.StartAsTask. Par exemple :This can be done with Async.StartAsTask, for example:

let Run(req: HttpRequestMessage) =
    async {
        return new HttpResponseMessage(HttpStatusCode.OK)
    } |> Async.StartAsTask

Jeton d’annulationCancellation Token

Si votre fonction doit gérer les arrêts de manière appropriée, vous pouvez lui fournir un argument CancellationToken .If your function needs to handle shutdown gracefully, you can give it a CancellationToken argument. conjointement utilisable avec async. Par exemple :This can be combined with async, for example:

let Run(req: HttpRequestMessage, token: CancellationToken)
    let f = async {
        do! Async.Sleep(10)
        return new HttpResponseMessage(HttpStatusCode.OK)
    }
    Async.StartAsTask(f, token)

Importation des espaces de nomsImporting namespaces

Les espaces de noms peuvent être ouverts de la manière habituelle :Namespaces can be opened in the usual way:

open System.Net
open System.Threading.Tasks
open Microsoft.Extensions.Logging

let Run(req: HttpRequestMessage, log: ILogger) =
    ...

Les espaces de noms ci-après sont ouverts automatiquement :The following namespaces are automatically opened:

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

Référencement des assemblys externesReferencing External Assemblies

De même, les références d’assembly d’infrastructure peuvent être ajoutées avec la directive #r "AssemblyName".Similarly, framework assembly references can be added with the #r "AssemblyName" directive.

#r "System.Web.Http"

open System.Net
open System.Net.Http
open System.Threading.Tasks
open Microsoft.Extensions.Logging

let Run(req: HttpRequestMessage, log: ILogger) =
    ...

Les assemblys suivants sont ajoutés automatiquement par l’environnement hébergeant Azure Functions :The following assemblies are automatically added by the Azure Functions hosting environment:

  • mscorlibmscorlib,
  • 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.System.Net.Http.Formatting.

En outre, les assemblys ci-après ont une casse spécifique et peuvent être référencés par leur nom simple (par exemple, #r "AssemblyName") :In addition, the following assemblies are special cased and may be referenced by simplename (e.g. #r "AssemblyName"):

  • Newtonsoft.Json
  • Microsoft.WindowsAzure.Storage
  • Microsoft.ServiceBus
  • Microsoft.AspNet.WebHooks.Receivers
  • Microsoft.AspNEt.WebHooks.Common.Microsoft.AspNEt.WebHooks.Common.

Si vous avez besoin de référencer un assembly privé, vous pouvez charger le fichier d’assembly dans un dossier bin relatif à votre fonction et le référencer à l’aide du nom de fichier (par exemple, #r "MyAssembly.dll").If you need to reference a private assembly, you can upload the assembly file into a bin folder relative to your function and reference it by using the file name (e.g. #r "MyAssembly.dll"). Pour plus d’informations sur le téléchargement de fichiers vers votre conteneur de fonctions, consultez la section suivante sur la gestion des packages.For information on how to upload files to your function folder, see the following section on package management.

Préambule destiné à l’éditeurEditor Prelude

Un éditeur prenant en charge F# Compiler Services ne reconnaît pas les espaces de noms et les assemblys automatiquement inclus par Azure Functions.An editor that supports F# Compiler Services will not be aware of the namespaces and assemblies that Azure Functions automatically includes. Il peut donc être utile d’insérer un préambule conçu pour permettre à l’éditeur de localiser les assemblys que vous utilisez et d’ouvrir explicitement les espaces de noms.As such, it can be useful to include a prelude that helps the editor find the assemblies you are using, and to explicitly open namespaces. Par exemple :For example:

#if !COMPILED
#I "../../bin/Binaries/WebJobs.Script.Host"
#r "Microsoft.Azure.WebJobs.Host.dll"
#endif

open System
open Microsoft.Azure.WebJobs.Host
open Microsoft.Extensions.Logging

let Run(blob: string, output: byref<string>, log: ILogger) =
    ...

Lorsque la solution Azure Functions exécute votre code, elle traite la source avec l’élément COMPILED défini, de sorte que le préambule destiné à l’éditeur sera ignoré.When Azure Functions executes your code, it processes the source with COMPILED defined, so the editor prelude will be ignored.

Gestion des packagesPackage management

Pour utiliser des packages NuGet dans une fonction F#, ajoutez un fichier project.json au dossier de la fonction dans le système de fichiers de l’application de fonctions.To use NuGet packages in an F# function, add a project.json file to the function's folder in the function app's file system. Voici un exemple de fichier project.json ajoutant une référence de package NuGet à Microsoft.ProjectOxford.Face version 1.1.0 :Here is an example project.json file that adds a NuGet package reference to Microsoft.ProjectOxford.Face version 1.1.0:

{
  "frameworks": {
    "net46":{
      "dependencies": {
        "Microsoft.ProjectOxford.Face": "1.1.0"
      }
    }
   }
}

Seul .NET Framework 4.6 est pris en charge. Par conséquent, assurez-vous que votre fichier project.json spécifie net46 comme indiqué ici.Only the .NET Framework 4.6 is supported, so make sure that your project.json file specifies net46 as shown here.

Lorsque vous chargez un fichier project.json , le runtime obtient les packages et ajoute automatiquement des références aux assemblys de packages.When you upload a project.json file, the runtime gets the packages and automatically adds references to the package assemblies. Vous n’avez pas besoin d’ajouter de directives #r "AssemblyName" .You don't need to add #r "AssemblyName" directives. Il vous suffit d’ajouter les instructions open requises à votre fichier .fsx.Just add the required open statements to your .fsx file.

Si vous le souhaitez, vous pouvez placer automatiquement les assemblys de référence dans votre préambule destiné à l’éditeur, afin d’améliorer l’interaction de votre éditeur avec F# Compile Services.You may wish to put automatically references assemblies in your editor prelude, to improve your editor's interaction with F# Compile Services.

Ajout d’un fichier project.json à votre fonction AzureHow to add a project.json file to your Azure Function

  1. Commencez par vous assurer que votre conteneur de fonctions est en cours d’exécution. Ce que vous pouvez faire en ouvrant votre fonction dans le portail Azure.Begin by making sure your function app is running, which you can do by opening your function in the Azure portal. Il donne également accès aux journaux d’activité de diffusion en continu où le résultat de l’installation du package s’affiche.This also gives access to the streaming logs where package installation output will be displayed.
  2. Pour charger un fichier project.json , utilisez l’une des méthodes décrites dans l’article Comment mettre à jour les fichiers du conteneur de fonctions.To upload a project.json file, use one of the methods described in how to update function app files. Si vous utilisez l’article Déploiement continu pour Azure Functions, vous pouvez ajouter un fichier project.json à votre branche intermédiaire afin de le tester avant de l’ajouter à votre branche de déploiement.If you are using Continuous Deployment for Azure Functions, you can add a project.json file to your staging branch in order to experiment with it before adding it to your deployment branch.
  3. Une fois le fichier project.json ajouté, une sortie semblable à l’exemple ci-après apparaîtra dans le journal de diffusion en continu de votre fonction :After the project.json file is added, you will see output similar to the following example in your function's streaming log:
2016-04-04T19:02:48.745 Restoring packages.
2016-04-04T19:02:48.745 Starting NuGet restore
2016-04-04T19:02:50.183 MSBuild auto-detection: using msbuild version '14.0' from 'D:\Program Files (x86)\MSBuild\14.0\bin'.
2016-04-04T19:02:50.261 Feeds used:
2016-04-04T19:02:50.261 C:\DWASFiles\Sites\facavalfunctest\LocalAppData\NuGet\Cache
2016-04-04T19:02:50.261 https://api.nuget.org/v3/index.json
2016-04-04T19:02:50.261
2016-04-04T19:02:50.511 Restoring packages for D:\home\site\wwwroot\HttpTriggerCSharp1\Project.json...
2016-04-04T19:02:52.800 Installing Newtonsoft.Json 6.0.8.
2016-04-04T19:02:52.800 Installing Microsoft.ProjectOxford.Face 1.1.0.
2016-04-04T19:02:57.095 All packages are compatible with .NETFramework,Version=v4.6.
2016-04-04T19:02:57.189
2016-04-04T19:02:57.189
2016-04-04T19:02:57.455 Packages restored.

Variables d’environnementEnvironment variables

Pour obtenir une variable d’environnement ou une valeur de paramètre d’application, utilisez System.Environment.GetEnvironmentVariable. Par exemple :To get an environment variable or an app setting value, use System.Environment.GetEnvironmentVariable, for example:

open System.Environment
open Microsoft.Extensions.Logging

let Run(timer: TimerInfo, log: ILogger) =
    log.LogInformation("Storage = " + GetEnvironmentVariable("AzureWebJobsStorage"))
    log.LogInformation("Site = " + GetEnvironmentVariable("WEBSITE_SITE_NAME"))

Réutilisation du code .fsxReusing .fsx code

Vous pouvez utiliser le code d’autres fichiers .fsx au moyen d’une directive #load.You can use code from other .fsx files by using a #load directive. Par exemple :For example:

run.fsx

#load "logger.fsx"

let Run(timer: TimerInfo, log: ILogger) =
    mylog log (sprintf "Timer: %s" DateTime.Now.ToString())

logger.fsx

let mylog(log: ILogger, text: string) =
    log.LogInformation(text);

Les chemins d’accès fournis à la directive #load sont relatifs à l’emplacement de votre fichier .fsx.Paths provides to the #load directive are relative to the location of your .fsx file.

  • #load "logger.fsx" charge un fichier situé dans le dossier de la fonction.#load "logger.fsx" loads a file located in the function folder.
  • #load "package\logger.fsx" charge un fichier situé dans le dossier package du dossier de la fonction.#load "package\logger.fsx" loads a file located in the package folder in the function folder.
  • #load "..\shared\mylogger.fsx" charge un fichier situé dans le dossier shared au même niveau que le dossier de la fonction, c’est-à-dire, directement sous wwwroot.#load "..\shared\mylogger.fsx" loads a file located in the shared folder at the same level as the function folder, that is, directly under wwwroot.

La directive #load ne fonctionne qu’avec des fichiers .fsx (script F#), et non avec des fichiers .fs.The #load directive only works with .fsx (F# script) files, and not with .fs files.

Étapes suivantesNext steps

Pour plus d’informations, consultez les ressources suivantes :For more information, see the following resources: