Utvecklarguide för Azure Functions
I Azure Functions delar alla funktioner några viktiga tekniska begrepp och komponenter, oavsett vilket språk eller din utvecklingsmiljö du föredrar. Den här artikeln är språkspecifik. Välj önskat språk överst i artikeln.
Den här artikeln förutsätter att du redan har läst översikten över Azure Functions.
Om du föredrar att hoppa direkt kan du slutföra en snabbstartsguide med hjälp av Visual Studio, Visual Studio Code eller från kommandotolken.
Om du föredrar att hoppa direkt kan du slutföra en snabbstartsguide med Maven (kommandorad), Eclipse, IntelliJ IDEA, Gradle, Quarkus, Spring Cloud eller Visual Studio Code.
Om du föredrar att hoppa direkt kan du slutföra en snabbstartsguide med hjälp av Visual Studio Code eller från kommandotolken.
Om du föredrar att hoppa direkt kan du slutföra en snabbstartsguide med hjälp av Visual Studio Code eller från kommandotolken.
Om du föredrar att hoppa direkt kan du slutföra en snabbstartsguide med hjälp av Visual Studio Code eller från kommandotolken.
Om du föredrar att hoppa direkt kan du slutföra en snabbstartsguide med hjälp av Visual Studio Code eller från kommandotolken.
Kodprojekt
Kärnan i Azure Functions är ett språkspecifikt kodprojekt som implementerar en eller flera kodkörningsenheter som kallas funktioner. Funktioner är helt enkelt metoder som körs i Azure-molnet baserat på händelser, som svar på HTTP-begäranden eller enligt ett schema. Tänk på ditt Azure Functions-kodprojekt som en mekanism för att organisera, distribuera och gemensamt hantera dina enskilda funktioner i projektet när de körs i Azure. Mer information finns i Ordna dina funktioner.
Hur du utformar kodprojektet och hur du anger vilka metoder i projektet som är funktioner beror på projektets utvecklingsspråk. Detaljerad språkspecifik vägledning finns i C#-utvecklarguiden.
Hur du utformar kodprojektet och hur du anger vilka metoder i projektet som är funktioner beror på projektets utvecklingsspråk. Språkspecifik vägledning finns i guiden för Java-utvecklare.
Hur du utformar kodprojektet och hur du anger vilka metoder i projektet som är funktioner beror på projektets utvecklingsspråk. Språkspecifik vägledning finns i guiden Node.js utvecklare.
Hur du utformar kodprojektet och hur du anger vilka metoder i projektet som är funktioner beror på projektets utvecklingsspråk. Språkspecifik vägledning finns i guiden för PowerShell-utvecklare.
Hur du utformar kodprojektet och hur du anger vilka metoder i projektet som är funktioner beror på projektets utvecklingsspråk. Språkspecifik vägledning finns i guiden för Python-utvecklare.
Alla funktioner måste ha en utlösare som definierar hur funktionen startar och kan ge indata till funktionen. Dina funktioner kan också definiera indata- och utdatabindningar. Dessa bindningar förenklar anslutningar till andra tjänster utan att du behöver arbeta med klient-SDK:er. Mer information finns i Utlösare och bindningar i Azure Functions.
Azure Functions tillhandahåller en uppsättning språkspecifika projekt- och funktionsmallar som gör det enkelt att skapa nya kodprojekt och lägga till funktioner i projektet. Du kan använda något av de verktyg som stöder Azure Functions-utveckling för att generera nya appar och funktioner med hjälp av dessa mallar.
Utvecklingsverktyg
Följande verktyg ger en integrerad utvecklings- och publiceringsupplevelse för Azure Functions på önskat språk:
Azure Functions Core Tools (kommandotolk)
De här verktygen integreras med Azure Functions Core Tools så att du kan köra och felsöka på din lokala dator med hjälp av Functions-körningen. Mer information finns i Koda och testa Azure Functions lokalt.
Det finns också en redigerare i Azure Portal som gör att du kan uppdatera din kod och din function.json definitionsfil direkt i portalen. Du bör bara använda den här redigeraren för små ändringar eller för att skapa konceptbevisfunktioner. Du bör alltid utveckla dina funktioner lokalt, när det är möjligt. Mer information finns i Skapa din första funktion i Azure Portal.
Portalredigering stöds endast för Node.js version 3, som använder function.json-filen.
Distribution
När du publicerar kodprojektet i Azure distribuerar du i princip projektet till en befintlig funktionsappresurs. En funktionsapp tillhandahåller en körningskontext i Azure där dina funktioner körs. Därför är det distributions- och hanteringsenheten för dina funktioner. Ur ett Azure-resursperspektiv motsvarar en funktionsapp en webbplatsresurs (Microsoft.Web/sites
) i Azure App Service, vilket motsvarar en webbapp.
En funktionsapp består av en eller flera enskilda funktioner som hanteras, distribueras och skalas tillsammans. Alla funktioner i en funktionsapp delar samma prisplan, distributionsmetod och körningsversion. Mer information finns i Hantera en funktionsapp.
När funktionsappen och andra nödvändiga resurser inte redan finns i Azure måste du först skapa dessa resurser innan du kan distribuera dina projektfiler. Du kan skapa dessa resurser på något av följande sätt:
Använda Visual Studio Code
Programmatiskt med hjälp av Azure CLI, Azure PowerShell, ARM-mallar eller Bicep-mallar
Förutom verktygsbaserad publicering har Functions stöd för andra tekniker för att distribuera källkod till en befintlig funktionsapp. Mer information finns i Distributionstekniker i Azure Functions.
Ansluta till tjänster
Ett stort krav för alla molnbaserade beräkningstjänster är att läsa data från och skriva data till andra molntjänster. Functions tillhandahåller en omfattande uppsättning bindningar som gör det enklare för dig att ansluta till tjänster utan att behöva arbeta med klient-SDK:er.
Oavsett om du använder bindningstilläggen som tillhandahålls av Functions eller om du arbetar direkt med klient-SDK:er lagrar du anslutningsdata på ett säkert sätt och inkluderar dem inte i koden. Mer information finns i Anslutningar.
Bindningar
Functions tillhandahåller bindningar för många Azure-tjänster och några tjänster från tredje part som implementeras som tillägg. Mer information finns i den fullständiga listan över bindningar som stöds.
Bindningstillägg kan stödja både indata och utdata, och många utlösare fungerar också som indatabindningar. Med bindningar kan du konfigurera anslutningen till tjänster så att Functions-värden kan hantera dataåtkomsten åt dig. Mer information finns i Utlösare och bindningar i Azure Functions.
Om du har problem med fel som kommer från bindningar kan du läsa dokumentationen om Azure Functions-bindningsfelkoder .
Klient-SDK: er
Även om Functions tillhandahåller bindningar för att förenkla dataåtkomsten i funktionskoden kan du fortfarande använda en klient-SDK i projektet för att få direkt åtkomst till en viss tjänst, om du vill. Du kan behöva använda klient-SDK:er direkt om dina funktioner kräver en funktion i den underliggande SDK som inte stöds av bindningstillägget.
När du använder klient-SDK:er bör du använda samma process för att lagra och komma åt anslutningssträng som används av bindningstillägg.
När du skapar en klient-SDK-instans i dina funktioner bör du få den anslutningsinformation som krävs av klienten från miljövariabler.
När du skapar en klient-SDK-instans i dina funktioner bör du få den anslutningsinformation som krävs av klienten från miljövariabler.
När du skapar en klient-SDK-instans i dina funktioner bör du få den anslutningsinformation som krävs av klienten från miljövariabler.
När du skapar en klient-SDK-instans i dina funktioner bör du få den anslutningsinformation som krävs av klienten från miljövariabler.
När du skapar en klient-SDK-instans i dina funktioner bör du få den anslutningsinformation som krävs av klienten från miljövariabler.
anslutningar
Som bästa säkerhet kan Azure Functions dra nytta av funktionerna för programinställningar i Azure App Service för att hjälpa dig att lagra strängar, nycklar och andra token som krävs för att ansluta till andra tjänster på ett säkrare sätt. Programinställningarna i Azure lagras krypterade och kan nås vid körning av din app som miljövariabelpar name
value
. För utlösare och bindningar som kräver en anslutningsegenskap anger du namnet på programinställningen i stället för den faktiska anslutningssträng. Du kan inte konfigurera en bindning direkt med en anslutningssträng eller nyckel.
Överväg till exempel en utlösardefinition som har en connection
egenskap. I stället för anslutningssträng anger connection
du namnet på en miljövariabel som innehåller anslutningssträng. Med hjälp av den här strategin för åtkomst till hemligheter blir både dina appar säkrare och gör det enklare för dig att ändra anslutningar mellan miljöer. För ännu mer säkerhet kan du använda identitetsbaserade anslutningar.
Standardkonfigurationsprovidern använder miljövariabler. Dessa variabler definieras i programinställningar när de körs i Azure och i filen för lokala inställningar när du utvecklar lokalt.
Anslutningsvärden
När anslutningsnamnet matchas till ett enda exakt värde identifierar körningen värdet som en anslutningssträng, vilket vanligtvis innehåller en hemlighet. Informationen om en anslutningssträng beror på vilken tjänst du ansluter till.
Ett anslutningsnamn kan dock också referera till en samling med flera konfigurationsobjekt, som är användbara för att konfigurera identitetsbaserade anslutningar. Miljövariabler kan behandlas som en samling med hjälp av ett delat prefix som slutar med dubbla understreck __
. Gruppen kan sedan refereras genom att ange anslutningsnamnet till det här prefixet.
Egenskapen för en Azure Blob-utlösardefinition kan till exempel connection
vara Storage1
. Så länge det inte finns något enda strängvärde som konfigurerats av en miljövariabel med namnet Storage1
kan en miljövariabel med namnet Storage1__blobServiceUri
användas för att informera blobServiceUri
anslutningens egenskap. Anslutningsegenskaperna skiljer sig åt för varje tjänst. Se dokumentationen för komponenten som använder anslutningen.
Kommentar
När du använder Azure App Configuration eller Key Vault för att ange inställningar för hanterade identitetsanslutningar bör inställningsnamn använda en giltig nyckelavgränsare, till exempel :
eller /
i stället __
för att säkerställa att namnen matchas korrekt.
Exempel: Storage1:blobServiceUri
Konfigurera en identitetsbaserad anslutning
Vissa anslutningar i Azure Functions kan konfigureras för att använda en identitet i stället för en hemlighet. Supporten beror på körningsversionen och tillägget med hjälp av anslutningen. I vissa fall kan en anslutningssträng fortfarande krävas i Functions även om tjänsten som du ansluter till stöder identitetsbaserade anslutningar. En självstudiekurs om hur du konfigurerar dina funktionsappar med hanterade identiteter finns i självstudien skapa en funktionsapp med identitetsbaserade anslutningar.
Kommentar
När du kör ett förbruknings- eller Elastic Premium-abonnemang använder din app inställningarna och WEBSITE_CONTENTSHARE
när du WEBSITE_AZUREFILESCONNECTIONSTRING
ansluter till Azure Files på det lagringskonto som används av funktionsappen. Azure Files stöder inte användning av hanterad identitet vid åtkomst till filresursen. Mer information finns i autentiseringsscenarier som stöds av Azure Files
Identitetsbaserade anslutningar stöds bara på Functions 4.x. Om du använder version 1.x måste du först migrera till version 4.x.
Följande komponenter stöder identitetsbaserade anslutningar:
När identitetsbaserade anslutningar finns i Azure Functions-tjänsten använder de en hanterad identitet. Den systemtilldelade identiteten används som standard, även om en användartilldelad identitet kan anges med credential
egenskaperna och clientID
. Observera att det inte går att konfigurera en användartilldelad identitet med ett resurs-ID. När den körs i andra sammanhang, till exempel lokal utveckling, används utvecklaridentiteten i stället, även om den kan anpassas. Se Lokal utveckling med identitetsbaserade anslutningar.
Bevilja behörighet till identiteten
Den identitet som används måste ha behörighet att utföra de avsedda åtgärderna. För de flesta Azure-tjänster innebär det att du måste tilldela en roll i Azure RBAC med hjälp av antingen inbyggda eller anpassade roller som ger dessa behörigheter.
Viktigt!
Vissa behörigheter kan exponeras av måltjänsten som inte är nödvändiga för alla kontexter. Om möjligt följer du principen om minsta behörighet och beviljar identiteten endast nödvändiga privilegier. Om appen till exempel bara behöver kunna läsa från en datakälla använder du en roll som bara har behörighet att läsa. Det skulle vara olämpligt att tilldela en roll som också tillåter skrivning till tjänsten, eftersom detta skulle vara överdriven behörighet för en läsåtgärd. På samma sätt vill du se till att rolltilldelningen endast är begränsad till de resurser som behöver läsas.
Välj någon av de här flikarna om du vill veta mer om behörigheter för varje komponent:
- Azure Blobs-tillägg
- Azure Queues-tillägg
- Azure Tables-tillägg
- Event Hubs-tillägg
- Service Bus-tillägg
- Event Grid-tillägg
- Azure Cosmos DB-tillägg
- Azure SignalR-tillägg
- Durable Functions-lagringsprovider
- Functions-värdlagring
Du måste skapa en rolltilldelning som ger åtkomst till din blobcontainer vid körning. Hanteringsroller som Ägare räcker inte. I följande tabell visas inbyggda roller som rekommenderas när du använder Blob Storage-tillägget i normal drift. Ditt program kan kräva ytterligare behörigheter baserat på den kod du skriver.
Bindningstyp | Exempel på inbyggda roller |
---|---|
Utlösare | Lagringsblobdataägare och lagringsködatadeltagare1 Extra behörigheter måste också beviljas till AzureWebJobsStorage-anslutningen.2 |
Indatabindning | Storage Blob Data-läsare |
Utdatabindning | Storage Blob Data-ägare |
1 Blobutlösaren hanterar fel i flera återförsök genom att skriva giftblobar till en kö på det lagringskonto som anges av anslutningen.
2 AzureWebJobsStorage-anslutningen används internt för blobar och köer som aktiverar utlösaren. Om den har konfigurerats för att använda en identitetsbaserad anslutning behöver den extra behörigheter utöver standardkravet. De behörigheter som krävs omfattas av rollerna Storage Blob Data Owner, Storage Queue Data Contributor och Storage Account Contributor . Mer information finns i Ansluta till värdlagring med en identitet.
Vanliga egenskaper för identitetsbaserade anslutningar
En identitetsbaserad anslutning för en Azure-tjänst accepterar följande vanliga egenskaper, där <CONNECTION_NAME_PREFIX>
är värdet för din connection
egenskap i utlösar- eller bindningsdefinitionen:
Property | Miljövariabelmall | beskrivning |
---|---|---|
Tokenautentiseringsuppgifter | <CONNECTION_NAME_PREFIX>__credential |
Definierar hur en token ska hämtas för anslutningen. Den här inställningen ska anges till managedidentity om din distribuerade Azure-funktion avser att använda hanterad identitetsautentisering. Det här värdet är endast giltigt när en hanterad identitet är tillgänglig i värdmiljön. |
Client ID | <CONNECTION_NAME_PREFIX>__clientId |
När credential är inställt på managedidentity kan den här egenskapen anges för att ange den användartilldelade identitet som ska användas när du hämtar en token. Egenskapen accepterar ett klient-ID som motsvarar en användartilldelad identitet som tilldelats programmet. Det är ogiltigt att ange både ett resurs-ID och ett klient-ID. Om det inte anges används den systemtilldelade identiteten. Den här egenskapen används på olika sätt i lokala utvecklingsscenarier, när credential bör inte anges. |
Resurs-ID | <CONNECTION_NAME_PREFIX>__managedIdentityResourceId |
När credential är inställt på managedidentity kan den här egenskapen anges för att ange den resursidentifierare som ska användas när du hämtar en token. Egenskapen accepterar en resursidentifierare som motsvarar resurs-ID:t för den användardefinierade hanterade identiteten. Det är ogiltigt att ange både ett resurs-ID och ett klient-ID. Om ingen av dem anges används den systemtilldelade identiteten. Den här egenskapen används på olika sätt i lokala utvecklingsscenarier, när credential bör inte anges. |
Andra alternativ kan stödjas för en viss anslutningstyp. Se dokumentationen för komponenten som upprättar anslutningen.
Azure SDK-miljövariabler
Varning
Användning av Azure SDK:s EnvironmentCredential
miljövariabler rekommenderas inte på grund av den potentiellt oavsiktliga påverkan på andra anslutningar. De stöds inte heller fullt ut när de distribueras till Azure Functions.
Miljövariablerna som är associerade med Azure SDK:erna EnvironmentCredential
kan också anges, men de bearbetas inte av Functions-tjänsten för skalning i förbrukningsplaner. Dessa miljövariabler är inte specifika för en enda anslutning och tillämpas som standard om inte en motsvarande egenskap inte har angetts för en viss anslutning. Om AZURE_CLIENT_ID
det till exempel har angetts används detta som om <CONNECTION_NAME_PREFIX>__clientId
det hade konfigurerats. Den här standardinställningen <CONNECTION_NAME_PREFIX>__clientId
åsidosätts uttryckligen.
Lokal utveckling med identitetsbaserade anslutningar
Kommentar
Lokal utveckling med identitetsbaserade anslutningar kräver version 4.0.3904
av Azure Functions Core Tools eller en senare version.
När du kör funktionsprojektet lokalt instruerar konfigurationen ovan körningen att använda din lokala utvecklaridentitet. Anslutningen försöker hämta en token från följande platser i ordning:
- En lokal cache som delas mellan Microsoft-program
- Den aktuella användarkontexten i Visual Studio
- Den aktuella användarkontexten i Visual Studio Code
- Den aktuella användarkontexten i Azure CLI
Om inget av dessa alternativ lyckas uppstår ett fel.
Din identitet kanske redan har vissa rolltilldelningar mot Azure-resurser som används för utveckling, men dessa roller kanske inte ger nödvändig dataåtkomst. Hanteringsroller som Ägare räcker inte. Dubbelkolla vilka behörigheter som krävs för anslutningar för varje komponent och se till att du har tilldelat dem till dig själv.
I vissa fall kanske du vill ange användning av en annan identitet. Du kan lägga till konfigurationsegenskaper för anslutningen som pekar på den alternativa identiteten baserat på ett klient-ID och en klienthemlighet för ett Microsoft Entra-tjänsthuvudnamn. Det här konfigurationsalternativet stöds inte när det finns i Azure Functions-tjänsten. Om du vill använda ett ID och en hemlighet på den lokala datorn definierar du anslutningen med följande extra egenskaper:
Property | Miljövariabelmall | beskrivning |
---|---|---|
Klientorganisations-ID | <CONNECTION_NAME_PREFIX>__tenantId |
Microsoft Entra-klientorganisationens (katalog)-ID. |
Client ID | <CONNECTION_NAME_PREFIX>__clientId |
Klientens (programmets) ID för en appregistrering i klientorganisationen. |
Klienthemlighet | <CONNECTION_NAME_PREFIX>__clientSecret |
En klienthemlighet som genererades för appregistreringen. |
Här är ett exempel på local.settings.json
egenskaper som krävs för identitetsbaserad anslutning till 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>"
}
}
Ansluta till värdlagring med en identitet
Azure Functions-värden använder lagringsanslutningen som angetts för AzureWebJobsStorage
att aktivera kärnbeteenden, till exempel samordning av singleton-körning av timerutlösare och standardlagring av appnycklar. Den här anslutningen kan också konfigureras för att använda en identitet.
Varning
Andra komponenter i Functions förlitar sig på AzureWebJobsStorage
för standardbeteenden. Du bör inte flytta den till en identitetsbaserad anslutning om du använder äldre versioner av tillägg som inte stöder den här typen av anslutning, inklusive utlösare och bindningar för Azure Blobs, Event Hubs och Durable Functions. På samma sätt används för distributionsartefakter när du använder version på serversidan i Linux-förbrukning, och om du aktiverar detta måste du distribuera via ett externt AzureWebJobsStorage
distributionspaket.
Dessutom kan funktionsappen återanvändas AzureWebJobsStorage
för andra lagringsanslutningar i utlösare, bindningar och/eller funktionskod. Kontrollera att alla användningsområden AzureWebJobsStorage
för kan använda det identitetsbaserade anslutningsformatet innan du ändrar anslutningen från en anslutningssträng.
Om du vill använda en identitetsbaserad anslutning för AzureWebJobsStorage
konfigurerar du följande appinställningar:
Inställning | beskrivning | Exempelvärde |
---|---|---|
AzureWebJobsStorage__blobServiceUri |
Dataplanets URI för blobtjänsten för lagringskontot med hjälp av HTTPS-schemat. | <https:// storage_account_name.blob.core.windows.net> |
AzureWebJobsStorage__queueServiceUri |
Dataplanets URI för kötjänsten för lagringskontot med hjälp av HTTPS-schemat. | <https:// storage_account_name.queue.core.windows.net> |
AzureWebJobsStorage__tableServiceUri |
Dataplanets URI för en tabelltjänst för lagringskontot med hjälp av HTTPS-schemat. | <https:// storage_account_name.table.core.windows.net> |
Vanliga egenskaper för identitetsbaserade anslutningar kan också anges.
Om du konfigurerar AzureWebJobsStorage
med ett lagringskonto som använder standard-DNS-suffixet och tjänstnamnet för globala Azure kan du i https://<accountName>.[blob|queue|file|table].core.windows.net
stället ange AzureWebJobsStorage__accountName
namnet på ditt lagringskonto efter formatet. Slutpunkterna för varje lagringstjänst härleds för det här kontot. Detta fungerar inte när lagringskontot finns i ett nationellt moln eller har en anpassad DNS.
Inställning | beskrivning | Exempelvärde |
---|---|---|
AzureWebJobsStorage__accountName |
Kontonamnet för ett lagringskonto är endast giltigt om kontot inte finns i ett nationellt moln och inte har en anpassad DNS. Den här syntaxen är unik för AzureWebJobsStorage och kan inte användas för andra identitetsbaserade anslutningar. |
<storage_account_name> |
Du måste skapa en rolltilldelning som ger åtkomst till lagringskontot för "AzureWebJobsStorage" vid körning. Hanteringsroller som Ägare räcker inte. Rollen Lagringsblobdataägare täcker de grundläggande behoven för Functions-värdlagring – körningen behöver både läs- och skrivåtkomst till blobar och möjligheten att skapa containrar. Flera tillägg använder den här anslutningen som standardplats för blobar, köer och tabeller, och dessa användningsområden kan lägga till krav som anges i tabellen nedan. Du kan behöva ytterligare behörigheter om du använder "AzureWebJobsStorage" för andra ändamål.
Anknytning | Roller som krävs | Förklaring |
---|---|---|
Inget tillägg (endast värd) | Storage Blob Data-ägare | Används för allmän samordning, standardnyckelarkiv |
Azure Blobs (endast utlösare) | Alla från: Lagringskontodeltagare, Lagringsblobdataägare, Lagringsködatadeltagare |
Blobutlösaren använder azure-köer internt och skriver blobkvitton. Den använder AzureWebJobsStorage för dessa, oavsett vilken anslutning som konfigurerats för utlösaren. |
Azure Event Hubs (endast utlösare) | (ingen ändring från standardkravet) Storage Blob Data-ägare |
Kontrollpunkter sparas i blobar med hjälp av AzureWebJobsStorage-anslutningen. |
Timerutlösare | (ingen ändring från standardkravet) Storage Blob Data-ägare |
För att säkerställa en körning per händelse låss med blobar med hjälp av AzureWebJobsStorage-anslutningen. |
Bestående funktioner | Alla från: Storage Blob Data-deltagare, Lagringsködatadeltagare, Storage Table Data-deltagare |
Durable Functions använder blobar, köer och tabeller för att samordna aktivitetsfunktioner och upprätthålla orkestreringstillstånd. Den använder AzureWebJobsStorage-anslutningen för alla dessa som standard, men du kan ange en annan anslutning i durable functions-tilläggskonfigurationen. |
Rapporteringsproblem
Objekt | beskrivning | Länka |
---|---|---|
Körmiljö | Skriptvärd, utlösare och bindningar, språkstöd | Skapa ett problem |
Mallar | Kodproblem med skapandemall | Skapa ett problem |
Portalen | Problem med användargränssnitt eller upplevelse | Skapa ett problem |
Lagringsplatser med öppen källkod
Koden för Azure Functions är öppen källkod och du hittar viktiga komponenter i dessa GitHub-lagringsplatser:
Nästa steg
Mer information finns i följande resurser: