Ontwikkelaarshandleiding voor Azure Functions

  • Artikel

In Azure Functions delen specifieke functies enkele belangrijke technische concepten en onderdelen, ongeacht de taal of binding die u gebruikt. Voordat u details leert die specifiek zijn voor een bepaalde taal of binding, moet u dit overzicht lezen dat op alle talen van toepassing is.

In dit artikel wordt ervan uitgegaan dat u het overzicht van de Azure Functions al hebt gelezen.

Functiecode

Een functie is het primaire concept in Azure Functions. Een functie bevat twee belangrijke onderdelen: uw code, die in verschillende talen kan worden geschreven, en een configuratie, het bestand function.json. Voor gecompileerde talen wordt dit configuratiebestand automatisch gegenereerd op basis van aantekeningen in uw code. Voor scripttalen moet u het configuratiebestand zelf opgeven.

Het bestand function.json definieert de trigger, bindingen en andere configuratie-instellingen van de functie. Elke functie kan slechts één trigger hebben. De runtime gebruikt dit configuratiebestand om te bepalen welke gebeurtenissen moeten worden bewaakt en hoe gegevens moeten worden doorgegeven aan en geretourneerd van een functie-uitvoering. Hier volgt een voorbeeld van het bestand function.json.

{
    "disabled":false,
    "bindings":[
        // ... bindings here
        {
            "type": "bindingType",
            "direction": "in",
            "name": "myParamName",
            // ... more depending on binding
        }
    ]
}

Zie concepten voor Azure Functions triggers en bindingen voor meer informatie.

De bindings eigenschap is waar u zowel triggers als bindingen configureert. Elke binding deelt een aantal algemene instellingen en enkele instellingen, die specifiek zijn voor een bepaald type binding. Voor elke binding zijn de volgende instellingen vereist:

Eigenschap Waarden Type Opmerkingen
type Naam van binding.

Bijvoorbeeld queueTrigger.		 tekenreeks
richting in, out tekenreeks Geeft aan of de binding bedoeld is voor het ontvangen van gegevens in de functie of het verzenden van gegevens van de functie.
naam Functie-id.

Bijvoorbeeld myQueue.		 tekenreeks De naam die wordt gebruikt voor de afhankelijke gegevens in de functie. Voor C# is dit een argumentnaam; voor JavaScript is dit de sleutel in een sleutel-/waardelijst.

Functie-app

Een functie-app biedt een uitvoeringscontext in Azure waarin uw functies worden uitgevoerd. Als zodanig is het de eenheid voor implementatie en beheer voor uw functies. Een functie-app bestaat uit een of meer afzonderlijke functies die samen worden beheerd, geïmplementeerd en geschaald. Alle functies in een functie-app delen hetzelfde prijsplan, dezelfde implementatiemethode en dezelfde runtime-versie. U kunt een functie-app beschouwen als een manier om uw functies te organiseren en collectief te beheren. Zie Een functie-app beheren voor meer informatie.

Notitie

Alle functies in een functie-app moeten in dezelfde taal worden geschreven. In eerdere versies van de Azure Functions runtime was dit niet vereist.

Mapstructuur

De code voor alle functies in een specifieke functie-app bevindt zich in een hoofdprojectmap die een hostconfiguratiebestand bevat. Het bestand host.json bevat runtimespecifieke configuraties en bevindt zich in de hoofdmap van de functie-app. Een bin-map bevat pakketten en andere bibliotheekbestanden die de functie-app nodig heeft. Specifieke mapstructuren die vereist zijn voor de functie-app, zijn afhankelijk van de taal:

In versie 2.x en hoger van de Functions-runtime moeten alle functies in de functie-app dezelfde taalstack delen.

Het bovenstaande is de standaardmapstructuur (en aanbevolen) voor een Functie-app. Als u de bestandslocatie van de code van een functie wilt wijzigen, wijzigt u de scriptFile sectie van het bestand function.json . We raden u ook aan pakketimplementatie te gebruiken om uw project te implementeren in uw functie-app in Azure. U kunt ook bestaande hulpprogramma's gebruiken, zoals continue integratie en implementatie en Azure DevOps.

Notitie

Als u een pakket handmatig implementeert, moet u ervoor zorgen dat u uw host.json-bestands - en functiemappen rechtstreeks in de wwwroot map implementeert. Neem de wwwroot map niet op in uw implementaties. Anders krijgt wwwroot\wwwroot u mappen.

Lokale hulpprogramma's en publiceren gebruiken

Functie-apps kunnen worden gemaakt en gepubliceerd met behulp van verschillende hulpprogramma's, waaronder Visual Studio, Visual Studio Code, IntelliJ, Eclipse en de Azure Functions Core Tools. Zie Code and test Azure Functions local (Lokaal coden en testen) voor meer informatie.

Functies bewerken in de Azure Portal

Met de functions-editor die is ingebouwd in de Azure Portal kunt u uw code en het bestand function.json rechtstreeks inline bijwerken. Dit wordt alleen aanbevolen voor kleine wijzigingen of bewijs van concept. De best practice is om een lokaal ontwikkelhulpprogramma zoals VS Code te gebruiken.

Parallelle uitvoering

Wanneer meerdere triggergebeurtenissen sneller optreden dan een functieruntime met één thread kan verwerken, kan de runtime de functie meerdere keren parallel aanroepen. Als een functie-app gebruikmaakt van het hostingabonnement Verbruik, kan de functie-app automatisch worden uitgeschaald. Elk exemplaar van de functie-app, ongeacht of de app wordt uitgevoerd op het hostingabonnement Verbruik of een normaal App Service hostingabonnement, kan gelijktijdige functieaanroepen parallel verwerken met behulp van meerdere threads. Het maximum aantal gelijktijdige functieaanroepen in elk functie-app-exemplaar is afhankelijk van het type trigger dat wordt gebruikt en de resources die door andere functies in de functie-app worden gebruikt.

Versiebeheer voor Functions-runtime

U kunt de versie van de Functions-runtime configureren met behulp van de FUNCTIONS_EXTENSION_VERSION app-instelling. De waarde ~3 geeft bijvoorbeeld aan dat uw functie-app 3.x als primaire versie gebruikt. Functie-apps worden bijgewerkt naar elke nieuwe secundaire versie zodra ze worden uitgebracht. Zie How to target Azure Functions runtime versions (Doelen Azure Functions runtimeversies) voor meer informatie, waaronder het weergeven van de exacte versie van uw functie-app.

Opslagplaatsen

De code voor Azure Functions wordt open source en opgeslagen in GitHub-opslagplaatsen:

Bindingen

Hier volgt een tabel met alle ondersteunde bindingen.

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

Type 1.x 2.x en hoger1 Trigger Invoer Uitvoer
Blob Storage ✔ ✔ ✔ ✔ ✔
Azure Cosmos DB ✔ ✔ ✔ ✔ ✔
Azure SQL ✔ ✔ ✔ ✔
Dapr3 ✔ ✔ ✔ ✔
Event Grid ✔ ✔ ✔ ✔
Event Hubs ✔ ✔ ✔ ✔
HTTP-webhooks & ✔ ✔ ✔ ✔
IoT Hub ✔ ✔ ✔
Kafka2 ✔ ✔ ✔
Mobile Apps ✔ ✔ ✔
Notification Hubs ✔ ✔
Queue Storage ✔ ✔ ✔ ✔
RabbitMQ2 ✔ ✔ ✔
SendGrid ✔ ✔ ✔
Service Bus ✔ ✔ ✔ ✔
SignalR ✔ ✔ ✔ ✔
Table Storage ✔ ✔ ✔ ✔
Timer ✔ ✔ ✔
Twilio ✔ ✔ ✔

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

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

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

Ondervindt u problemen met fouten die afkomstig zijn van de bindingen? Raadpleeg de documentatie Azure Functions Binding Error Codes.

Verbindingen

Uw functieproject verwijst naar verbindingsgegevens op naam van de configuratieprovider. De verbindingsgegevens worden niet rechtstreeks geaccepteerd, zodat deze in verschillende omgevingen kunnen worden gewijzigd. Een triggerdefinitie kan bijvoorbeeld een connection eigenschap bevatten. Dit kan verwijzen naar een connection string, maar u kunt de connection string niet rechtstreeks in een function.jsoninstellen. In plaats daarvan stelt connection u in op de naam van een omgevingsvariabele die de connection string bevat.

De standaardconfiguratieprovider maakt gebruik van omgevingsvariabelen. Deze kunnen worden ingesteld door Toepassingsinstellingen wanneer deze worden uitgevoerd in de Azure Functions-service, of vanuit het bestand met lokale instellingen bij het lokaal ontwikkelen.

Verbindingswaarden

Wanneer de naam van de verbinding wordt omgezet in één exacte waarde, identificeert de runtime de waarde als een connection string, die meestal een geheim bevat. De details van een connection string worden gedefinieerd door de service waarmee u verbinding wilt maken.

Een verbindingsnaam kan echter ook verwijzen naar een verzameling van meerdere configuratie-items, die handig zijn voor het configureren van op identiteit gebaseerde verbindingen. Omgevingsvariabelen kunnen worden behandeld als een verzameling met behulp van een gedeeld voorvoegsel dat eindigt op dubbele onderstrepingstekens __. Vervolgens kan naar de groep worden verwezen door de naam van de verbinding in te stellen op dit voorvoegsel.

De eigenschap voor een Definitie van een Azure Blob-trigger kan bijvoorbeeld connection 'Storage1' zijn. Zolang er geen enkele tekenreekswaarde is geconfigureerd door een omgevingsvariabele met de naam Storage1, kan een omgevingsvariabele met de naam Storage1__blobServiceUri worden gebruikt om de blobServiceUri eigenschap van de verbinding te informeren. De verbindingseigenschappen zijn voor elke service verschillend. Raadpleeg de documentatie voor het onderdeel dat gebruikmaakt van de verbinding.

Notitie

Wanneer u Azure App Configuration of Key Vault gebruikt om instellingen voor beheerde identiteit-verbindingen op te geven, moeten instellingsnamen een geldig sleutelscheidingsteken gebruiken, zoals : of / in plaats van de__, om ervoor te zorgen dat namen correct worden omgezet.

Bijvoorbeeld Storage1:blobServiceUri.

Een op identiteit gebaseerde verbinding configureren

Sommige verbindingen in Azure Functions kunnen worden geconfigureerd om een identiteit te gebruiken in plaats van een geheim. Ondersteuning is afhankelijk van de extensie die de verbinding gebruikt. In sommige gevallen is er mogelijk nog steeds een connection string vereist in Functions, ook al ondersteunt de service waarmee u verbinding maakt verbindingen op basis van identiteiten. Zie de zelfstudie Een functie-app maken met op identiteit gebaseerde verbindingen voor een zelfstudie over het configureren van uw functie-apps met beheerde identiteiten.

De volgende onderdelen ondersteunen verbindingen op basis van identiteit:

Verbindingsbron Ondersteunde abonnementen Lees meer
Azure Blobs-triggers en -bindingen Alles Azure Blobs-extensie versie 5.0.0 of hoger,
Uitbreidingsbundel 3.3.0 of hoger
Azure Queues-triggers en -bindingen Alles Azure Queues-extensie versie 5.0.0 of hoger,
Uitbreidingsbundel 3.3.0 of hoger
Azure Tables (bij gebruik van Azure Storage) Alles Azure Tables-extensie versie 1.0.0 of hoger,
Uitbreidingsbundel 3.3.0 of hoger
Azure SQL Database Alles Een functie-app verbinden met Azure SQL met beheerde identiteit en SQL-bindingen
Azure Event Hubs triggers en bindingen Alles Azure Event Hubs extensie versie 5.0.0 of hoger,
Uitbreidingsbundel 3.3.0 of hoger
Azure Service Bus triggers en bindingen Alles Azure Service Bus extensie versie 5.0.0 of hoger,
Uitbreidingsbundel 3.3.0 of hoger
Azure Cosmos DB-triggers en -bindingen Alles Azure Cosmos DB-extensie versie 4.0.0 of hoger,
Uitbreidingsbundel 4.0.2 of hoger
Azure SignalR-triggers en -bindingen Alles Azure SignalR-extensie versie 1.7.0 of hoger
Uitbreidingsbundel 3.6.1 of hoger
Durable Functions-opslagprovider (Azure Storage) Alles Durable Functions extensie versie 2.7.0 of hoger,
Uitbreidingsbundel 3.3.0 of hoger
Host-vereiste opslag ('AzureWebJobsStorage') Alles Verbinding maken met hostopslag met een identiteit

Wanneer verbindingen op basis van identiteiten worden gehost in de Azure Functions-service, wordt een beheerde identiteit gebruikt. De door het systeem toegewezen identiteit wordt standaard gebruikt, hoewel een door de gebruiker toegewezen identiteit kan worden opgegeven met de credential eigenschappen en clientID . Het configureren van een door de gebruiker toegewezen identiteit met een resource-id wordt niet ondersteund. Bij uitvoering in andere contexten, zoals lokale ontwikkeling, wordt in plaats daarvan uw ontwikkelaarsidentiteit gebruikt, hoewel deze kan worden aangepast. Zie Lokale ontwikkeling met op identiteit gebaseerde verbindingen.

Machtiging verlenen aan de identiteit

De identiteit die wordt gebruikt, moet machtigingen hebben om de beoogde acties uit te voeren. Voor de meeste Azure-services betekent dit dat u een rol in Azure RBAC moet toewijzen, met behulp van ingebouwde of aangepaste rollen die deze machtigingen bieden.

Belangrijk

Sommige machtigingen worden mogelijk weergegeven door de doelservice die niet nodig zijn voor alle contexten. Houd u waar mogelijk aan het principe van minimale bevoegdheden, waarbij u de identiteit alleen vereiste bevoegdheden verleent. Als de app bijvoorbeeld alleen uit een gegevensbron hoeft te kunnen lezen, gebruikt u een rol die alleen is gemachtigd om te lezen. Het zou ongepast zijn om een rol toe te wijzen waarmee ook naar die service kan worden geschreven, omdat dit overmatige machtigingen voor een leesbewerking zou zijn. Op dezelfde manier wilt u ervoor zorgen dat de roltoewijzing alleen betrekking heeft op de resources die moeten worden gelezen.

Kies hieronder een tabblad voor meer informatie over machtigingen voor elk onderdeel:

U moet een roltoewijzing maken die tijdens runtime toegang biedt tot uw blobcontainer. Beheerrollen zoals Eigenaar zijn niet voldoende. De volgende tabel bevat ingebouwde rollen die worden aanbevolen bij het gebruik van de Blob Storage-extensie in normale werking. Voor uw toepassing zijn mogelijk verdere machtigingen vereist op basis van de code die u schrijft.

Bindingstype Voorbeeld van ingebouwde rollen
Trigger Eigenaar van opslagblobgegevensenInzender voor opslagwachtrijgegevens1

Er moeten ook extra machtigingen worden verleend aan de AzureWebJobsStorage-verbinding. 2
Invoerbinding Lezer voor opslagblobgegevens
Uitvoerbinding Eigenaar van opslagblobgegevens

1 De blobtrigger verwerkt fouten in meerdere nieuwe pogingen door gif-blobs te schrijven naar een wachtrij in het opslagaccount dat is opgegeven door de verbinding.

2 De AzureWebJobsStorage-verbinding wordt intern gebruikt voor blobs en wachtrijen die de trigger mogelijk maken. Als deze is geconfigureerd voor het gebruik van een op identiteit gebaseerde verbinding, zijn extra machtigingen nodig dan de standaardvereiste. De vereiste machtigingen worden gedekt door de rollen Eigenaar van opslagblobgegevens, Inzender voor opslagwachtrijgegevens en Inzender voor opslagaccounts . Zie Verbinding maken met hostopslag met een identiteit voor meer informatie.

Algemene eigenschappen voor op identiteit gebaseerde verbindingen

Een op identiteit gebaseerde verbinding voor een Azure-service accepteert de volgende algemene eigenschappen, waarbij <CONNECTION_NAME_PREFIX> de waarde van uw connection eigenschap in de trigger- of bindingsdefinitie is:

Eigenschap Sjabloon voor omgevingsvariabelen Description
Tokenreferentie <CONNECTION_NAME_PREFIX>__credential Definieert hoe een token moet worden verkregen voor de verbinding. Deze instelling wordt alleen aanbevolen bij het opgeven van een door de gebruiker toegewezen identiteit, wanneer deze moet worden ingesteld op 'managedidentity'. Deze waarde is alleen geldig wanneer deze wordt gehost in de Azure Functions-service.
Client-id <CONNECTION_NAME_PREFIX>__clientId Wanneer credential is ingesteld op 'managedidentity', geeft deze eigenschap de door de gebruiker toegewezen identiteit op die moet worden gebruikt bij het verkrijgen van een token. De eigenschap accepteert een client-id die overeenkomt met een door de gebruiker toegewezen identiteit die is toegewezen aan de toepassing. Als dit niet is opgegeven, wordt de door het systeem toegewezen identiteit gebruikt. Deze eigenschap wordt anders gebruikt in lokale ontwikkelingsscenario's, wanneer credential niet moet worden ingesteld.

Aanvullende opties kunnen worden ondersteund voor een bepaald verbindingstype. Raadpleeg de documentatie voor het onderdeel dat de verbinding maakt.

Lokale ontwikkeling met op identiteit gebaseerde verbindingen

Notitie

Voor lokale ontwikkeling met op identiteit gebaseerde verbindingen zijn bijgewerkte versies van de Azure Functions Core Tools vereist. U kunt uw momenteel geïnstalleerde versie controleren door uit te voeren func -v. Gebruik versie 3.0.3904 of hoger voor Functions v3. Gebruik versie 4.0.3904 of hoger voor Functions v4.

Wanneer u uw functieproject lokaal uitvoert, geeft de bovenstaande configuratie aan dat de runtime uw lokale ontwikkelaarsidentiteit moet gebruiken. De verbinding probeert een token op te halen van de volgende locaties, in volgorde:

  • Een lokale cache die wordt gedeeld tussen Microsoft-toepassingen
  • De huidige gebruikerscontext in Visual Studio
  • De huidige gebruikerscontext in Visual Studio Code
  • De huidige gebruikerscontext in de Azure CLI

Als geen van deze opties lukt, treedt er een fout op.

Uw identiteit heeft mogelijk al enkele roltoewijzingen voor Azure-resources die worden gebruikt voor ontwikkeling, maar deze rollen bieden mogelijk niet de benodigde gegevenstoegang. Beheerrollen zoals Eigenaar zijn niet voldoende. Controleer nog eens welke machtigingen vereist zijn voor verbindingen voor elk onderdeel en zorg ervoor dat u deze aan uzelf hebt toegewezen.

In sommige gevallen kunt u het gebruik van een andere identiteit opgeven. U kunt configuratie-eigenschappen voor de verbinding toevoegen die verwijzen naar de alternatieve identiteit op basis van een client-id en clientgeheim voor een Azure Active Directory-service-principal. Deze configuratieoptie wordt niet ondersteund wanneer deze wordt gehost in de Azure Functions-service. Als u een id en geheim op uw lokale computer wilt gebruiken, definieert u de verbinding met de volgende aanvullende eigenschappen:

Eigenschap Sjabloon voor omgevingsvariabelen Description
Tenant-id <CONNECTION_NAME_PREFIX>__tenantId De tenant-id (directory) van Azure Active Directory.
Client-id <CONNECTION_NAME_PREFIX>__clientId De client-id (toepassing) van een app-registratie in de tenant.
Clientgeheim <CONNECTION_NAME_PREFIX>__clientSecret Een clientgeheim dat is gegenereerd voor de app-registratie.

Hier volgt een voorbeeld van local.settings.json eigenschappen die vereist zijn voor een verbinding op basis van identiteit met Azure Blobs:

{
  "IsEncrypted": false,
  "Values": {
    "<CONNECTION_NAME_PREFIX>__blobServiceUri": "<blobServiceUri>",
    "<CONNECTION_NAME_PREFIX>__queueServiceUri": "<queueServiceUri>",
    "<CONNECTION_NAME_PREFIX>__tenantId": "<tenantId>",
    "<CONNECTION_NAME_PREFIX>__clientId": "<clientId>",
    "<CONNECTION_NAME_PREFIX>__clientSecret": "<clientSecret>"
  }
}

Verbinding maken met hostopslag met een identiteit

De Azure Functions host gebruikt de verbinding 'AzureWebJobsStorage' voor kerngedrag, zoals het coördineren van singleton-uitvoering van timertriggers en standaardopslag van app-sleutels. Dit kan ook worden geconfigureerd om gebruik te maken van een identiteit.

Waarschuwing

Andere onderdelen in Functions zijn voor standaardgedrag afhankelijk van 'AzureWebJobsStorage'. Verplaats deze niet naar een op identiteit gebaseerde verbinding als u oudere versies van extensies gebruikt die dit type verbinding niet ondersteunen, inclusief triggers en bindingen voor Azure Blobs, Event Hubs en Durable Functions. Op dezelfde manier AzureWebJobsStorage wordt gebruikt voor implementatieartefacten wanneer u build aan de serverzijde gebruikt in Linux-verbruik. Als u dit inschakelt, moet u implementeren via een extern implementatiepakket.

Daarnaast gebruiken sommige apps 'AzureWebJobsStorage' voor andere opslagverbindingen in hun triggers, bindingen en/of functiecode. Zorg ervoor dat alle toepassingen van 'AzureWebJobsStorage' de indeling van de op identiteit gebaseerde verbinding kunnen gebruiken voordat u deze verbinding wijzigt van een connection string.

Als u een op identiteit gebaseerde verbinding wilt gebruiken voor 'AzureWebJobsStorage', configureert u de volgende app-instellingen:

Instelling Beschrijving Voorbeeldwaarde
AzureWebJobsStorage__blobServiceUri De gegevensvlak-URI van de blobservice van het opslagaccount, met behulp van het HTTPS-schema. <https:// storage_account_name.blob.core.windows.net>
AzureWebJobsStorage__queueServiceUri De gegevensvlak-URI van de wachtrijservice van het opslagaccount, met behulp van het HTTPS-schema. <https:// storage_account_name.queue.core.windows.net>
AzureWebJobsStorage__tableServiceUri De gegevensvlak-URI van een tabelservice van het opslagaccount, met behulp van het HTTPS-schema. <https:// storage_account_name.table.core.windows.net>

Algemene eigenschappen voor op identiteit gebaseerde verbindingen kunnen ook worden ingesteld.

Als u 'AzureWebJobsStorage' configureert met behulp van een opslagaccount dat gebruikmaakt van het standaard-DNS-achtervoegsel en de servicenaam voor globale Azure, volgens de https://<accountName>.blob/queue/file/table.core.windows.net indeling, kunt u in plaats daarvan instellen AzureWebJobsStorage__accountName op de naam van uw opslagaccount. De eindpunten voor elke opslagservice worden voor dit account afgeleid. Dit werkt niet als het opslagaccount zich in een onafhankelijke cloud bevindt of een aangepaste DNS heeft.

Instelling Beschrijving Voorbeeldwaarde
AzureWebJobsStorage__accountName De accountnaam van een opslagaccount, alleen geldig als het account zich niet in een onafhankelijke cloud bevindt en geen aangepaste DNS heeft. Deze syntaxis is uniek voor 'AzureWebJobsStorage' en kan niet worden gebruikt voor andere identiteitsgebaseerde verbindingen. <storage_account_name>

U moet tijdens runtime een roltoewijzing maken die toegang biedt tot het opslagaccount voor 'AzureWebJobsStorage'. Beheerrollen zoals Eigenaar zijn niet voldoende. De rol Eigenaar van opslagblobgegevens dekt de basisbehoeften van de Functions-hostopslag: de runtime heeft zowel lees- als schrijftoegang tot blobs nodig en de mogelijkheid om containers te maken. Verschillende extensies gebruiken deze verbinding als standaardlocatie voor blobs, wachtrijen en tabellen, en deze toepassingen kunnen vereisten toevoegen, zoals vermeld in de onderstaande tabel. Mogelijk hebt u aanvullende machtigingen nodig als u 'AzureWebJobsStorage' voor andere doeleinden gebruikt.

Extensie Vereiste rollen Uitleg
Geen extensie (alleen host) Eigenaar van opslagblobgegevens Wordt gebruikt voor algemene coördinatie, standaardsleutelarchief
Azure-blobs (alleen trigger) Alles van:
Inzender voor opslagaccounts,
Eigenaar van opslagblobgegevens,
Inzender voor opslagwachtrijgegevens		 De blobtrigger maakt intern gebruik van Azure Queues en schrijft blob-ontvangstbewijzen. Hiervoor wordt AzureWebJobsStorage gebruikt, ongeacht de verbinding die is geconfigureerd voor de trigger.
Azure Event Hubs (alleen trigger) (geen wijziging van de standaardvereiste)
Eigenaar van opslagblobgegevens		 Controlepunten blijven behouden in blobs met behulp van de AzureWebJobsStorage-verbinding.
Timertrigger (geen wijziging van de standaardvereiste)
Eigenaar van opslagblobgegevens		 Om ervoor te zorgen dat één uitvoering per gebeurtenis wordt uitgevoerd, worden vergrendelingen uitgevoerd met blobs met behulp van de AzureWebJobsStorage-verbinding.
Durable Functions Alles van:
Inzender voor opslagblobgegevens,
Inzender voor opslagwachtrijgegevens,
Inzender voor opslagtabelgegevens		 Durable Functions maakt gebruik van blobs, wachtrijen en tabellen om activiteitsfuncties te coördineren en de indelingsstatus te behouden. Hiervoor wordt standaard de AzureWebJobsStorage-verbinding gebruikt, maar u kunt een andere verbinding opgeven in de configuratie van de Durable Functions-extensie.

Problemen melden

Item Beschrijving Koppeling
Runtime Scripthost, Triggers-bindingen & , taalondersteuning Een probleem melden
Sjablonen Codeprobleem met aanmaaksjabloon Een probleem melden
Portal Probleem met de gebruikersinterface of -ervaring Een probleem melden

Volgende stappen

Zie de volgende resources voor meer informatie: