C#-klassebibliotheekfuncties ontwikkelen met behulp van Azure Functions

Dit artikel is een inleiding tot het ontwikkelen van Azure Functions met behulp van C# in .NET-klassebibliotheken.

Als C#-ontwikkelaar bent u mogelijk ook geïnteresseerd in een van de volgende artikelen:

Azure Functions ondersteunt C#- en C#-scriptprogrammeertaal. Als u op zoek bent naar richtlijnen voor het gebruik van C# inde Azure Portal, zie C#-script (.csx) developer reference ( Naslag voor ontwikkelaars van C#-scripts (.csx).

Ondersteunde versies

Versies van de Functions-runtime werken met specifieke versies van .NET. Zie overzicht van runtime-versies voor meer Azure Functions over Functions-versies. Versieondersteuning is afhankelijk van of uw functies worden uitgevoerd in-process of out-of-process (geïsoleerd).

In de volgende tabel ziet u het hoogste niveau van .NET Core of .NET Framework kunnen worden gebruikt met een specifieke versie van Functions.

¹ Voor het buildproces is ook .NET Core 3.1 SDK vereist.
² Zie Overwegingen voor Functions v2.x voor meer informatie.

Voor het laatste nieuws over Azure Functions releases, waaronder het verwijderen van specifieke oudere secundaire versies, controleert u de Azure App Service aankondigingen.

Overwegingen voor Functions v2.x

Functie-apps die zijn gericht op de nieuwste versie van 2.x ( ) worden automatisch bijgewerkt om te ~2 worden uitgevoerd op .NET Core 3.1. Vanwege belangrijke wijzigingen tussen .NET Core-versies kunnen niet alle apps die zijn ontwikkeld en gecompileerd voor .NET Core 2.2 veilig worden geüpgraded naar .NET Core 3.1. U kunt zich voor deze upgrade uit- en uit- door uw functie-app vast te maken aan ~2.0 . Functions detecteert ook incompatibele API's en kan uw app vastmaken aan om onjuiste ~2.0 uitvoering op .NET Core 3.1 te voorkomen.

Functie-apps die ~2.0 zijn gericht op blijven worden uitgevoerd op .NET Core 2.2. Deze versie van .NET Core ontvangt geen beveiligings- en andere onderhoudsupdates meer. Zie deze aankondigingspagina voor meer informatie.

U moet ervoor zorgen dat uw functies zo snel mogelijk compatibel zijn met .NET Core 3.1. Nadat u deze problemen hebt opgelost, wijzigt u uw versie weer in ~2 of upgradet u naar ~3 . Zie Voor meer informatie over doelversies van de Functions-runtime How to target Azure Functions runtime versions.

Wanneer u linux gebruikt in een Premium- of toegewezen abonnement (App Service), kunt u uw versie vastmaken door in plaats daarvan een specifieke afbeelding te richten door de site-configuratie-instelling in te stellen op Voor meer informatie over het instellen van , zie Handmatige versie-updates op linuxFxVersion DOCKER|mcr.microsoft.com/azure-functions/dotnet:2.0.14786-appservice linuxFxVersion Linux.

Functions-klassebibliotheekproject

In Visual Studio maakt de Azure Functions een C#-klassebibliotheekproject dat de volgende bestanden bevat:

• host.js: slaat configuratie-instellingen op die van invloed zijn op alle functies in het project wanneer deze lokaal of in Azure worden uitgevoerd.
• local.settings.js: slaat app-instellingen en verbindingsreeksen op die worden gebruikt wanneer deze lokaal worden uitgevoerd. Dit bestand bevat geheimen en wordt niet gepubliceerd naar uw functie-app in Azure. Voeg in plaats daarvan app-instellingen toe aan uw functie-app.

Wanneer u het project bouwt, wordt er een mapstructuur gegenereerd die lijkt op het volgende voorbeeld in de uitvoermap van de build:

<framework.version>
 | - bin
 | - MyFirstFunction
 | | - function.json
 | - MySecondFunction
 | | - function.json
 | - host.json

Deze map wordt geïmplementeerd in uw functie-app in Azure. De bindingsextensies die zijn vereist in versie 2.x van de Functions-runtime, worden als NuGet-pakkettentoegevoegd aan het project.

Methoden die worden herkend als functies

In een klassebibliotheek is een functie een statische methode met een en een FunctionName triggerkenmerk, zoals wordt weergegeven in het volgende voorbeeld:

public static class SimpleExample
{
    [FunctionName("QueueTrigger")]
    public static void Run(
        [QueueTrigger("myqueue-items")] string myQueueItem, 
        ILogger log)
    {
        log.LogInformation($"C# function processed: {myQueueItem}");
    }
} 

Het FunctionName kenmerk markeert de methode als een functie-ingangspunt. De naam moet uniek zijn binnen een project, beginnen met een letter en alleen letters, cijfers en , maximaal _ - 127 tekens lang bevatten. Project maken vaak een methode met de naam , maar de naam van de methode Run kan elke geldige C#-methodenaam zijn.

Het triggerkenmerk geeft het triggertype op en verbindt invoergegevens met een methodeparameter. De voorbeeldfunctie wordt geactiveerd door een wachtrijbericht en het wachtrijbericht wordt doorgegeven aan de methode in de myQueueItem parameter .

Handtekeningparameters voor methode

De methodehandtekening kan andere parameters bevatten dan de parameters die worden gebruikt met het triggerkenmerk. Hier ziet u enkele van de andere parameters die u kunt opnemen:

• Invoer- en uitvoerbindingen die als zodanig zijn gemarkeerd door ze te voorzien van kenmerken.
• Een ILogger parameter of ( versie TraceWriter 1.x-only) voor logboekregistratie.
• Een CancellationToken parameter voor het netjes afsluitenvan .
• Bindingexpressieparameters om metagegevens van de trigger op te halen.

De volgorde van parameters in de functiehandtekening maakt niet uit. U kunt bijvoorbeeld triggerparameters vóór of na andere bindingen zetten en u kunt de loggerparameter vóór of na trigger- of bindingsparameters zetten.

Uitvoerbindingen

Een functie kan nul of één uitvoerbinding hebben gedefinieerd met behulp van uitvoerparameters.

In het volgende voorbeeld wordt het voorgaande voorbeeld wijzigt door het toevoegen van een uitvoerwachtrijbinding met de naam myQueueItemCopy . De functie schrijft de inhoud van het bericht dat de functie activeert naar een nieuw bericht in een andere wachtrij.

public static class SimpleExampleWithOutput
{
    [FunctionName("CopyQueueMessage")]
    public static void Run(
        [QueueTrigger("myqueue-items-source")] string myQueueItem, 
        [Queue("myqueue-items-destination")] out string myQueueItemCopy,
        ILogger log)
    {
        log.LogInformation($"CopyQueueMessage function processed: {myQueueItem}");
        myQueueItemCopy = myQueueItem;
    }
}

Waarden die zijn toegewezen aan uitvoerbindingen worden geschreven wanneer de functie wordt afgesloten. U kunt meer dan één uitvoerbinding in een functie gebruiken door simpelweg waarden toe te wijzen aan meerdere uitvoerparameters.

In de bindingverwijzingsartikelen(Storagewachtrijen) wordt uitgelegd welke parametertypen u kunt gebruiken met trigger-, invoer- of uitvoerbindingskenmerken.

Voorbeeld van bindingexpressie

Met de volgende code wordt de naam van de wachtrij die moet worden bewaakt, opgevraagd bij een app-instelling en wordt de aanmaaktijd van het wachtrijbericht in de insertionTime parameter opgevraagd.

public static class BindingExpressionsExample
{
    [FunctionName("LogQueueMessage")]
    public static void Run(
        [QueueTrigger("%queueappsetting%")] string myQueueItem,
        DateTimeOffset insertionTime,
        ILogger log)
    {
        log.LogInformation($"Message content: {myQueueItem}");
        log.LogInformation($"Created at: {insertionTime}");
    }
}

Automatisch gegenereerde function.jsop

Tijdens het buildproces wordtfunction.js bestand gemaakt in een functiemap in de map build. Zoals eerder vermeld, is dit bestand niet bedoeld om rechtstreeks te worden bewerkt. U kunt de bindingsconfiguratie niet wijzigen of de functie uitschakelen door dit bestand te bewerken.

Het doel van dit bestand is het verstrekken van informatie aan de schaalcontroller om te gebruiken voor het schalen van beslissingen over het verbruiksplan. Daarom bevat het bestand alleen triggergegevens, geen invoer-/uitvoerbindingen.

De gegenereerdefunction.jsin het bestand bevat een eigenschap die de runtime vertelt dat .NET-kenmerken voor bindingen moeten worden gebruikt, in plaats vanfunction.jsconfigurationSource bij de configuratie. Hier volgt een voorbeeld:

{
  "generatedBy": "Microsoft.NET.Sdk.Functions-1.0.0.0",
  "configurationSource": "attributes",
  "bindings": [
    {
      "type": "queueTrigger",
      "queueName": "%input-queue-name%",
      "name": "myQueueItem"
    }
  ],
  "disabled": false,
  "scriptFile": "..\\bin\\FunctionApp1.dll",
  "entryPoint": "FunctionApp1.QueueTrigger.Run"
}

Microsoft .NET.Sdk.Functions

De function.jsvoor het genereren van bestanden wordt uitgevoerd door het NuGet-pakket Microsoft NET . . Sdk . Functions.

Hetzelfde pakket wordt gebruikt voor zowel versie 1.x als 2.x van de Functions-runtime. Het doel-framework is wat een 1.x-project onderscheidt van een 2.x-project. Hier zijn de relevante onderdelen van .csproj-bestanden, met verschillende doel-frameworks met hetzelfde Sdk pakket:

<PropertyGroup>
  <TargetFramework>netcoreapp2.1</TargetFramework>
  <AzureFunctionsVersion>v2</AzureFunctionsVersion>
</PropertyGroup>
<ItemGroup>
  <PackageReference Include="Microsoft.NET.Sdk.Functions" Version="1.0.8" />
</ItemGroup>

<PropertyGroup>
  <TargetFramework>net461</TargetFramework>
</PropertyGroup>
<ItemGroup>
  <PackageReference Include="Microsoft.NET.Sdk.Functions" Version="1.0.8" />
</ItemGroup>

Onder de Sdk pakketafhankelijkheden zijn triggers en bindingen. Een 1.x-project verwijst naar 1.x-triggers en -bindingen omdat deze triggers en bindingen zijn gericht op de .NET Framework, terwijl 2.x triggers en bindingen zijn gericht op .NET Core.

Het pakket is ook afhankelijk vanNewtonsoft.Js, en indirect Sdk op WindowsAzure.Storage. Deze afhankelijkheden zorgen ervoor dat uw project gebruikmaakt van de versies van die pakketten die werken met de Functions-runtimeversie die het project als doel heeft. Heeft bijvoorbeeld versie Newtonsoft.Json 11 voor .NET Framework 4.6.1, maar de Functions-runtime die is gericht op .NET Framework 4.6.1 is alleen compatibel met Newtonsoft.Json 9.0.1. Uw functiecode in dat project moet dus ook Newtonsoft.Json 9.0.1 gebruiken.

De broncode voor Microsoft.NET.Sdk.Functions is beschikbaar in de GitHub-repo azure functions vs build - - - - sdk.

Lokale runtimeversie

Visual Studio maakt gebruik van Azure Functions Core Tools om Functions-projecten uit te voeren op uw lokale computer. De Core Tools is een opdrachtregelinterface voor de Functions-runtime.

Als u de Core Tools installeert met behulp van het MSI-pakket (Windows Installer) of npm, heeft dit geen invloed op de Core Tools-versie die wordt gebruikt door Visual Studio. Voor versie 1.x van de Functions-runtime slaat Visual Studio Core Tools-versies op in %USERPROFILE%\AppData\Local\Azure.Functions.Cli en wordt de nieuwste versie gebruikt die daar is opgeslagen. Voor Functions 2.x zijn de Core Tools opgenomen in de extensie Azure Functions en Web Jobs Tools. Voor zowel 1.x als 2.x kunt u zien welke versie wordt gebruikt in de console-uitvoer wanneer u een Functions-project uitvoert:

[3/1/2018 9:59:53 AM] Starting Host (HostId=contoso2-1518597420, Version=2.0.11353.0, ProcessId=22020, Debug=False, Attempt=0, FunctionsExtensionVersion=)

ReadyToRun

U kunt uw functie-app compileren als binaire ReadyToRun-bestanden. ReadyToRun is een vorm van compilatie van tevoren die de opstartprestaties kan verbeteren om de impact van koude start bij het uitvoeren in een verbruiksplan te verminderen.

ReadyToRun is beschikbaar in .NET 3.0 en vereist versie 3.0 van Azure Functions runtime.

Als u uw project wilt compileren als ReadyToRun, moet u het projectbestand bijwerken door de <PublishReadyToRun> elementen en toe te <RuntimeIdentifier> voegen. Hier volgt de configuratie voor het publiceren naar een Windows 32-bits functie-app.

<PropertyGroup>
  <TargetFramework>netcoreapp3.1</TargetFramework>
  <AzureFunctionsVersion>v3</AzureFunctionsVersion>
  <PublishReadyToRun>true</PublishReadyToRun>
  <RuntimeIdentifier>win-x86</RuntimeIdentifier>
</PropertyGroup>

U kunt uw app ook bouwen met ReadyToRun vanaf de opdrachtregel. Zie de optie -p:PublishReadyToRun=true in voor meer dotnet publish informatie.

Ondersteunde typen voor bindingen

Elke binding heeft zijn eigen ondersteunde typen; Een blobtriggerkenmerk kan bijvoorbeeld worden toegepast op een tekenreeksparameter, een POCO-parameter, een parameter of een van de CloudBlockBlob verschillende andere ondersteunde typen. Het naslagartikel over bindingen voor blobbindingen bevat een lijst met alle ondersteunde parametertypen. Zie Triggers en bindingen en de documentatie voor bindingsverwijzingen voor elk bindingstype voor meer informatie.

Binding met retourwaarde van methode

U kunt een retourwaarde van de methode gebruiken voor een uitvoerbinding door het kenmerk toe te passen op de retourwaarde van de methode. Zie Triggers en bindingen voor voorbeelden.

Gebruik de retourwaarde alleen als een geslaagde functie-uitvoering altijd resulteert in een retourwaarde om door te geven aan de uitvoerbinding. Gebruik anders ICollector of , zoals wordt weergegeven in de volgende IAsyncCollector sectie.

Meerdere uitvoerwaarden schrijven

Als u meerdere waarden naar een uitvoerbinding wilt schrijven of als een geslaagde functie-aanroep mogelijk niet tot gevolg heeft dat er iets aan de uitvoerbinding wordt doorgeven, gebruikt u de ICollector typen IAsyncCollector of . Deze typen zijn alleen-schrijven verzamelingen die naar de uitvoerbinding worden geschreven wanneer de methode is voltooid.

In dit voorbeeld worden meerdere wachtrijberichten naar dezelfde wachtrij schrijft met behulp van ICollector :

public static class ICollectorExample
{
    [FunctionName("CopyQueueMessageICollector")]
    public static void Run(
        [QueueTrigger("myqueue-items-source-3")] string myQueueItem,
        [Queue("myqueue-items-destination")] ICollector<string> myDestinationQueue,
        ILogger log)
    {
        log.LogInformation($"C# function processed: {myQueueItem}");
        myDestinationQueue.Add($"Copy 1: {myQueueItem}");
        myDestinationQueue.Add($"Copy 2: {myQueueItem}");
    }
}

Async

Als u een functie asynchroon wilt maken,gebruikt u het async trefwoord en retournt u een Task -object.

public static class AsyncExample
{
    [FunctionName("BlobCopy")]
    public static async Task RunAsync(
        [BlobTrigger("sample-images/{blobName}")] Stream blobInput,
        [Blob("sample-images-copies/{blobName}", FileAccess.Write)] Stream blobOutput,
        CancellationToken token,
        ILogger log)
    {
        log.LogInformation($"BlobCopy function processed.");
        await blobInput.CopyToAsync(blobOutput, 4096, token);
    }
}

U kunt geen out parameters gebruiken in asyntische functies. Voor uitvoerbindingen gebruikt u in plaats daarvan de retourwaarde van de functie of een collector-object.

Annuleringstokens

Een functie kan een cancellationtoken-parameter accepteren, waarmee het besturingssysteem uw code kan waarschuwen wanneer de functie op het punt staat te worden beëindigd. U kunt deze melding gebruiken om ervoor te zorgen dat de functie niet onverwacht wordt beëindigd op een manier die gegevens in een inconsistente status laat staan.

In het volgende voorbeeld ziet u hoe u kunt controleren op aanstaande functiebeëindiging.

public static class CancellationTokenExample
{
    public static void Run(
        [QueueTrigger("inputqueue")] 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);
        }
    }
}

Logboekregistratie

In uw functiecode kunt u uitvoer schrijven naar logboeken die worden weergegeven als traceringen in Application Insights. De aanbevolen manier om naar de logboeken te schrijven, is door een parameter van het type ILoggerop te nemen, die doorgaans de naam log heeft. Versie 1.x van de Functions-runtime gebruikt , die ook naar Application Insights schrijft, maar geen ondersteuning biedt TraceWriter voor gestructureerde logboekregistratie. Gebruik niet om Console.Write uw logboeken te schrijven, omdat deze gegevens niet worden vastgelegd door Application Insights.

ILogger

Neem in uw functiedefinitie een ILogger-parameter op die gestructureerde logboekregistratie ondersteunt.

Met een ILogger -object roept u Log<level> extensiemethoden op ILogger aan om logboeken te maken. De volgende code schrijft Information logboeken met categorie Function.<YOUR_FUNCTION_NAME>.User. :

public static async Task<HttpResponseMessage> Run(HttpRequestMessage req, ILogger logger)
{
    logger.LogInformation("Request for item with key={itemKey}.", id);

Zie Telemetriegegevens verzamelen voor meer informatie over hoe Functions ILogger implementeert. Bij categorieën met het Function voorvoegsel wordt ervan uitgenomen dat u een instantie ILogger gebruikt. Als u in plaats daarvan een ILogger<T> gebruikt, is de categorienaam mogelijk gebaseerd op T .

Gestructureerde logboekregistratie

De volgorde van tijdelijke aanduidingen, niet de namen, bepaalt welke parameters worden gebruikt in het logboekbericht. Stel dat u de volgende code hebt:

string partitionKey = "partitionKey";
string rowKey = "rowKey";
logger.LogInformation("partitionKey={partitionKey}, rowKey={rowKey}", partitionKey, rowKey);

Als u dezelfde berichtreeks bewaarde en de volgorde van de parameters omkeert, bevat de resulterende berichttekst de waarden op de verkeerde plaatsen.

Tijdelijke aanduidingen worden op deze manier verwerkt, zodat u gestructureerde logboekregistratie kunt maken. Application Insights slaat de parameternaam-waardeparen en de berichtreeks op. Het resultaat is dat de berichtargumenten velden worden die u kunt opvragen.

Als de aanroep van uw loggermethode lijkt op het vorige voorbeeld, kunt u een query uitvoeren op het veld customDimensions.prop__rowKey . Het voorvoegsel wordt toegevoegd om ervoor te zorgen dat er geen verschillen zijn tussen velden die door de runtime worden toegevoegd prop__ en velden die door uw functiecode worden toegevoegd.

U kunt ook een query uitvoeren op de oorspronkelijke berichttekenreeks door te verwijzen naar het veld customDimensions.prop__{OriginalFormat} .

Hier is een voorbeeld van een JSON-weergave van customDimensions gegevens:

{
  "customDimensions": {
    "prop__{OriginalFormat}":"C# Queue trigger function processed: {message}",
    "Category":"Function",
    "LogLevel":"Information",
    "prop__message":"c9519cbf-b1e6-4b9b-bf24-cb7d10b1bb89"
  }
}

Aangepaste telemetrie voor logboeken

Er is een Functions-specifieke versie van de Application Insights SDK die u kunt gebruiken om aangepaste telemetriegegevens van uw functies te verzenden naar Application Insights: Microsoft.Azure.WebJobs.Logging.ApplicationInsights. Gebruik de volgende opdracht vanaf de opdrachtprompt om dit pakket te installeren:

dotnet add package Microsoft.Azure.WebJobs.Logging.ApplicationInsights --version <VERSION>

Install-Package Microsoft.Azure.WebJobs.Logging.ApplicationInsights -Version <VERSION>

Vervang in deze opdracht door een versie van dit pakket die ondersteuning biedt voor uw <VERSION> geïnstalleerde versie van Microsoft.Azure.WebJobs.

In de volgende C#-voorbeelden wordt de aangepaste telemetrie-API gebruikt. Het voorbeeld is voor een .NET-klassebibliotheek, maar de Application Insights-code is hetzelfde voor C#-script.

using System;
using System.Threading.Tasks;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Azure.WebJobs;
using Microsoft.Azure.WebJobs.Extensions.Http;
using Microsoft.AspNetCore.Http;
using Microsoft.Extensions.Logging;

using Microsoft.ApplicationInsights;
using Microsoft.ApplicationInsights.DataContracts;
using Microsoft.ApplicationInsights.Extensibility;
using System.Linq;

namespace functionapp0915
{
    public class HttpTrigger2
    {
        private readonly TelemetryClient telemetryClient;

        /// Using dependency injection will guarantee that you use the same configuration for telemetry collected automatically and manually.
        public HttpTrigger2(TelemetryConfiguration telemetryConfiguration)
        {
            this.telemetryClient = new TelemetryClient(telemetryConfiguration);
        }

        [FunctionName("HttpTrigger2")]
        public Task<IActionResult> Run(
            [HttpTrigger(AuthorizationLevel.Anonymous, "get", Route = null)]
            HttpRequest req, ExecutionContext context, ILogger log)
        {
            log.LogInformation("C# HTTP trigger function processed a request.");
            DateTime start = DateTime.UtcNow;

            // Parse query parameter
            string name = req.Query
                .FirstOrDefault(q => string.Compare(q.Key, "name", true) == 0)
                .Value;

            // Write an event to the customEvents table.
            var evt = new EventTelemetry("Function called");
            evt.Context.User.Id = name;
            this.telemetryClient.TrackEvent(evt);

            // Generate a custom metric, in this case let's use ContentLength.
            this.telemetryClient.GetMetric("contentLength").TrackValue(req.ContentLength);

            // Log a custom dependency in the dependencies table.
            var dependency = new DependencyTelemetry
            {
                Name = "GET api/planets/1/",
                Target = "swapi.co",
                Data = "https://swapi.co/api/planets/1/",
                Timestamp = start,
                Duration = DateTime.UtcNow - start,
                Success = true
            };
            dependency.Context.User.Id = name;
            this.telemetryClient.TrackDependency(dependency);

            return Task.FromResult<IActionResult>(new OkResult());
        }
    }
}

using System;
using System.Net;
using Microsoft.ApplicationInsights;
using Microsoft.ApplicationInsights.DataContracts;
using Microsoft.ApplicationInsights.Extensibility;
using Microsoft.Azure.WebJobs;
using System.Net.Http;
using System.Threading.Tasks;
using Microsoft.Azure.WebJobs.Extensions.Http;
using Microsoft.Extensions.Logging;
using System.Linq;

namespace functionapp0915
{
    public static class HttpTrigger2
    {
        private static string key = TelemetryConfiguration.Active.InstrumentationKey = 
            System.Environment.GetEnvironmentVariable(
                "APPINSIGHTS_INSTRUMENTATIONKEY", EnvironmentVariableTarget.Process);

        private static TelemetryClient telemetryClient = 
            new TelemetryClient() { InstrumentationKey = key };

        [FunctionName("HttpTrigger2")]
        public static async Task<HttpResponseMessage> Run(
            [HttpTrigger(AuthorizationLevel.Anonymous, "get", "post", Route = null)]
            HttpRequestMessage req, ExecutionContext context, ILogger log)
        {
            log.LogInformation("C# HTTP trigger function processed a request.");
            DateTime start = DateTime.UtcNow;

            // Parse query parameter
            string name = req.GetQueryNameValuePairs()
                .FirstOrDefault(q => string.Compare(q.Key, "name", true) == 0)
                .Value;

            // Get request body
            dynamic data = await req.Content.ReadAsAsync<object>();

            // Set name to query string or body data
            name = name ?? data?.name;
         
            // Track an Event
            var evt = new EventTelemetry("Function called");
            UpdateTelemetryContext(evt.Context, context, name);
            telemetryClient.TrackEvent(evt);
            
            // Track a Metric
            var metric = new MetricTelemetry("Test Metric", DateTime.Now.Millisecond);
            UpdateTelemetryContext(metric.Context, context, name);
            telemetryClient.TrackMetric(metric);
            
            // Track a Dependency
            var dependency = new DependencyTelemetry
            {
                Name = "GET api/planets/1/",
                Target = "swapi.co",
                Data = "https://swapi.co/api/planets/1/",
                Timestamp = start,
                Duration = DateTime.UtcNow - start,
                Success = true
            };
            UpdateTelemetryContext(dependency.Context, context, name);
            telemetryClient.TrackDependency(dependency);
        }
        
        // Correlate all telemetry with the current Function invocation
        private static void UpdateTelemetryContext(TelemetryContext context, ExecutionContext functionContext, string userName)
        {
            context.Operation.Id = functionContext.InvocationId.ToString();
            context.Operation.ParentId = functionContext.InvocationId.ToString();
            context.Operation.Name = functionContext.FunctionName;
            context.User.Id = userName;
        }
    }    
}

Roep niet aan of omdat u dubbele aanvragen TrackRequest voor een functie-aanroep StartOperation<RequestTelemetry> ziet. De Functions-runtime houdt aanvragen automatisch bij.

Stel niet telemetryClient.Context.Operation.Id in. Deze globale instelling veroorzaakt een onjuiste correlatie wanneer veel functies gelijktijdig worden uitgevoerd. Maak in plaats daarvan een nieuw telemetrie-exemplaar ( DependencyTelemetry , ) en wijzig de eigenschap EventTelemetry Context ervan. Geef vervolgens het telemetrie-exemplaar door aan de Track bijbehorende methode op TelemetryClient ( , TrackDependency() , TrackEvent() TrackMetric() ). Deze methode zorgt ervoor dat de telemetrie de juiste correlatiedetails heeft voor de huidige functie-aanroep.

Omgevingsvariabelen

Als u een omgevingsvariabele of een app-instellingswaarde wilt op halen, gebruikt System.Environment.GetEnvironmentVariable u , zoals wordt weergegeven in het volgende codevoorbeeld:

public static class EnvironmentVariablesExample
{
    [FunctionName("GetEnvironmentVariables")]
    public static void Run([TimerTrigger("0 */5 * * * *")]TimerInfo myTimer, ILogger log)
    {
        log.LogInformation($"C# Timer trigger function executed at: {DateTime.Now}");
        log.LogInformation(GetEnvironmentVariable("AzureWebJobsStorage"));
        log.LogInformation(GetEnvironmentVariable("WEBSITE_SITE_NAME"));
    }

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

App-instellingen kunnen worden gelezen uit omgevingsvariabelen, zowel bij het lokaal ontwikkelen als bij het uitvoeren in Azure. Bij het lokaal ontwikkelen zijn app-instellingen afkomstig uit Values de verzameling inlocal.settings.js on file. In beide omgevingen, lokaal en Azure, wordt de waarde van de GetEnvironmentVariable("<app setting name>") benoemde app-instelling opgehaald. Als u bijvoorbeeld lokaal wordt uitgevoerd, wordt 'Mijn sitenaam' geretourneerd als uwlocal.settings.js bestand { "Values": { "WEBSITE_SITE_NAME": "My Site Name" } } bevat.

De System.Configuration.ConfigurationManager.AppSettings is een alternatieve API voor het verkrijgen van waarden voor app-instellingen, maar we raden u aan om te gebruiken zoals hier GetEnvironmentVariable wordt weergegeven.

Binding tijdens runtime

In C# en andere .NET-talen kunt u een imperatieve bindingspatroon gebruiken, in tegenstelling tot de declaratieve bindingen in kenmerken. Imperatieve binding is handig wanneer bindingsparameters tijdens runtime moeten worden berekend in plaats van de ontwerptijd. Met dit patroon kunt u on-the-fly in uw functiecode een binding maken met ondersteunde invoer- en uitvoerbindingen.

Definieer als volgt een imperatieve binding:

• Neem geen kenmerk op in de functiehandtekening voor de gewenste imperatieve bindingen.

• Geef een invoerparameter Binder binder of IBinder binder door.

• Gebruik het volgende C#-patroon om de gegevensbinding uit te voeren.

  using (var output = await binder.BindAsync<T>(new BindingTypeAttribute(...)))
  {
      ...
  }
  

  BindingTypeAttribute is het .NET-kenmerk dat uw binding definieert en een invoer- of uitvoertype is dat wordt T ondersteund door dat bindingstype. T kan geen out parametertype zijn (zoals out JObject ). De uitvoerbinding Mobile Apps tabel ondersteunt bijvoorbeeld zes uitvoertypen, maar u kunt ICollector <T> of <T> IAsyncCollector alleen gebruiken met imperatieve binding.

Voorbeeld van één kenmerk

Met de volgende voorbeeldcode wordt een Storage blob-uitvoerbinding gemaakt met een blobpad dat tijdens run time is gedefinieerd en schrijft vervolgens een tekenreeks naar de blob.

public static class IBinderExample
{
    [FunctionName("CreateBlobUsingBinder")]
    public static void Run(
        [QueueTrigger("myqueue-items-source-4")] string myQueueItem,
        IBinder binder,
        ILogger log)
    {
        log.LogInformation($"CreateBlobUsingBinder function processed: {myQueueItem}");
        using (var writer = binder.Bind<TextWriter>(new BlobAttribute(
                    $"samples-output/{myQueueItem}", FileAccess.Write)))
        {
            writer.Write("Hello World!");
        };
    }
}

BlobAttribute definieert de Storage blob-invoer- of uitvoerbinding en TextWriter is een ondersteund type uitvoerbinding.

Voorbeeld van meerdere kenmerken

In het voorgaande voorbeeld wordt de app-instelling voor het hoofdaccount van de functie-app Storage de connection string (dit is AzureWebJobsStorage ). U kunt een aangepaste app-instelling opgeven voor het Storage-account door storageAccountAttribute toe te voegen en de kenmerk matrix door te geven aan BindAsync<T>() . Gebruik een Binder parameter, niet IBinder . Bijvoorbeeld:

public static class IBinderExampleMultipleAttributes
{
    [FunctionName("CreateBlobInDifferentStorageAccount")]
    public async static Task RunAsync(
            [QueueTrigger("myqueue-items-source-binder2")] string myQueueItem,
            Binder binder,
            ILogger log)
    {
        log.LogInformation($"CreateBlobInDifferentStorageAccount function processed: {myQueueItem}");
        var attributes = new Attribute[]
        {
        new BlobAttribute($"samples-output/{myQueueItem}", FileAccess.Write),
        new StorageAccountAttribute("MyStorageAccount")
        };
        using (var writer = await binder.BindAsync<TextWriter>(attributes))
        {
            await writer.WriteAsync("Hello World!!");
        }
    }
}

Triggers en bindingen

Dit tabel geeft de bindingen weer die worden ondersteund in de belangrijkste versies van de Azure Functions-runtime:

¹ Vanaf de rumtime 2.x moeten alle bindingen, behalve HTTP en Timer, worden geregistreerd. Raadpleeg Bindingextensies registreren.

² Triggers worden niet ondersteund in het Consumption-abonnement. Vereist runtime-gestuurde triggers.

³ Alleen ondersteund in Kubernetes, IoT Edge en andere zelf-gehoste modi.

Volgende stappen