Configureer verbindingen met remote services in Azure Functions

Dit artikel is de primaire referentie voor hoe Azure Functions verbinding maakt met externe diensten. Het biedt specifieke richtlijnen op basis van verbindingstype en authenticatiemethode.

Important

Gebruik waar mogelijk beheerde identiteiten met Microsoft Entra ID. Deze authenticatiemethode elimineert geheimen en biedt de hoogste beveiliging.

Verbindingscategorieën

Azure Functions-verbindingen vallen in deze basiscategorieën:

  • Host vereist: Verbindingen die de Functions-host nodig heeft om te functioneren, zoals opslag en monitoring.
  • Bindings: Verbindingen die de host beheert voor je triggers en bindings.
  • Client SDK: Verbindingen die je zelf maakt en beheert in je functiecode.

Tip

Functions ondersteunt ook beheerde connectors (in preview), waarmee je verbinding kunt maken met diensten zoals Office 365, Teams en SharePoint met ingebouwde OAuth en webhook-afhandeling via een Connector Namespace. Voor meer informatie, zie Gebruik connectoren in Azure Functions.

De Functions-host vereist dat je app deze specifieke benoemde verbindingen heeft, die zowel functie-uitvoeringen als logging ondersteunen:

Verificatiemethoden

Important

Gebruik indien mogelijk beheerde identiteiten voor je connecties. Deze aanpak elimineert geheimen volledig. Wanneer de doeldienst geen Microsoft Entra ID-authenticatie ondersteunt, gebruik dan Azure Key Vault om geheimen centraal te beheren. Gebruik shared secrets alleen direct in de app-instellingen als laatste redmiddel.

Functions ondersteunt deze authenticatiemethoden bij verbinding met externe diensten:

Verificatiemethode Security Wanneer gebruiken
beheerde identiteiten Hoogste De Target-service ondersteunt Microsoft Entra ID. Geen geheimen om te beheren.
Azure Key Vault Hoog De dienst ondersteunt geen beheerde identiteiten, of je hebt gecentraliseerd geheimbeheer nodig met rotatie.
Gedeeld geheim Laag Verouderde standaardinstelling. Migrer zo snel mogelijk naar beheerde identiteiten of Key Vault.

Kies je voorkeursauthenticatiemethode bovenaan het artikel om gedetailleerde configuratierichtlijnen te zien.

Definieer verbindingen

Tijdens runtime raadpleegt je functie-app verbindingsinformatie als omgevingsvariabelen vanaf deze locaties:

Milieu Waar instellingen worden opgeslagen
Azure Applicatie-instellingen (versleuteld in rust)
Lokale ontwikkeling local.settings.json (optioneel versleuteld)

In beide omgevingen worden instellingen blootgesteld aan je code als omgevingsvariabelen. De specifieke instellingen die je nodig hebt, hangen af van zowel het verbindingstype als de gekozen authenticatiemethode .

Wanneer je Microsoft Entra-authenticatie gebruikt om verbinding te maken met een Azure-dienst, hangen de specifieke app-instellingen die je gebruikt af van de verbonden dienst en of je een systeem- of door de gebruiker toegewezen identiteit gebruikt om de verbinding te authenticeren.

De identiteiten die je gebruikt voor je verbindingen moeten rechten hebben om de bedoelde acties uit te voeren. Voor de meeste Azure-diensten betekent deze eis dat je een rol moet toewijzen in Azure RBAC, met ingebouwde of aangepaste rollen die die rechten bieden. Voor meer informatie, zie Verlenen van rechten aan een identiteit.

Houd deze overwegingen in gedachten bij het gebruik van identiteitsgebaseerde verbindingen:

  • In een door Functions gehoste app gebruiken identiteitsgebaseerde verbindingen een beheerde identiteit. De door het systeem toegewezen identiteit, die specifiek is voor je app, wordt standaard gebruikt. Gebruikerstoegewezen identiteiten, die ook de *__credential en *__clientID eigenschappen vereisen, zijn echter flexibeler en aanbevolen worden.

  • Wanneer je app in andere contexten draait, zoals lokale ontwikkeling, wordt je ontwikkelaarsidentiteit gebruikt. Voor meer informatie, zie het artikel over lokale ontwikkeling .

  • Identiteitsgebaseerde verbindingen worden alleen ondersteund vanaf versie 4.x en later van de Functions-runtime. Als je een legacy C#-app draait op versie 1.x van de Functions-runtime, moet je eerst migreren naar versie 4.x.

Je kunt je functie-app zo instellen dat deze een identiteit gebruikt in plaats van een verbindingsreeks wanneer je verbinding maakt met het standaard opslagaccount (AzureWebJobsStorage) en andere door de host vereiste verbindingen.

Managed identity-ondersteuning voor AzureWebJobsStorage varieert per hostingplan:

Hostingabonnement MI voor hostopslag Azure Files-vereiste Aanbeveling
Flexverbruik Volledig ondersteuning Geen (geen Azure Files) Aanbevolen voor MI
Toegewezen (App Service) Volledig ondersteuning Geen (geen dynamische schaalverdeling) Volledige MI, geen oplossing nodig
Verbruik Blobs, wachtrijen, tabellen Key Vault of verwijder Azure Files Bewaar WEBSITE_AZUREFILESCONNECTIONSTRING in Key Vault
Elastische premie Blobs, wachtrijen, tabellen Key Vault of verwijder Azure Files Bewaar WEBSITE_AZUREFILESCONNECTIONSTRING in Key Vault

Voordat u beheerde identiteiten gebruikt voor door de host vereiste verbindingen, overweeg deze beperkingen:

  • Voor Consumption- en Premium-abonnementen implementeer je een van deze workarounds voor Azure Files:

    • Sla alleen de WEBSITE_AZUREFILESCONNECTIONSTRING verbindingsreeks op in Key Vault, wat de op één na veiligste optie is.
    • Maak een Consumption- of Premium-abonnement aan die zonder Azure Files draait. Er zijn prestatieproblemen als je zonder Azure Files draait. Zie Maak een app zonder Azure Files voor meer informatie.
  • Deze triggers zijn afhankelijk van AzureWebJobsStorage om correct te werken:

    • Azure Blob Storage (opslagdienst van Azure)
    • Azure Event Hubs
    • Durable Functions (standaard)
    • Timer

    Als je app een van deze extensies gebruikt, zorg er dan voor dat de versie ook managed identitys ondersteunt.

  • AzureWebJobsStorage behoudt implementatieartefacten in server-sidebuilds (externe builds) in een Linux Consumption-plan. In dit scenario moet je je app uitrollen en uitvoeren vanuit een extern deploymentpakket.

  • Andere componenten van je functie-app kunnen de AzureWebJobsStorage verbinding hergebruiken, waaronder storage binding-extensies of storage-clients die zijn gemaakt met de Azure SDK. Bij het gebruik van beheerde identiteiten maak je nieuwe applicatie-instellingen aan voor deze niet-hostcomponenten, zelfs als ze beheerde identiteiten ondersteunen.

Deze specifieke app-instellingen definiëren identiteitsgebaseerde verbindingen met zowel AzureWebJobsStorage als APPLICATIONINSIGHTS_CONNECTION_STRING:

Configuratie Description
AzureWebJobsStorage__blobServiceUri De URI voor Blob Storage in het standaard opslagaccount. Vereist voor soevereine clouds of een aangepaste opslag-DNS, zoals: https://mystorageaccount.blob.contoso.com. HTTPS is vereist.
AzureWebJobsStorage__queueServiceUri De URI voor Queue Storage in het standaard opslagaccount. Vereist voor soevereine clouds of een aangepaste opslag-DNS, zoals: https://mystorageaccount.queue.contoso.com. HTTPS is vereist.
AzureWebJobsStorage__tableServiceUri De URI voor Table Storage in het standaard opslagaccount. Vereist voor soevereine clouds of een aangepaste opslag-DNS, zoals: https://mystorageaccount.table.contoso.com. HTTPS is vereist.
AzureWebJobsStorage__credential Stel in op managedidentity om beheerde identiteitsauthenticatie te gebruiken. Er moet een beheerde identiteit beschikbaar zijn in de hostingomgeving.
AzureWebJobsStorage__clientId of
AzureWebJobsStorage__managedIdentityResourceId
Geeft een specifieke door de gebruiker toegewezen identiteit terug die wordt gebruikt om een toegangstoken te verkrijgen voor beheerde identiteitsauthenticatie. Wanneer geen van beide is ingesteld, wordt de systeem-toegewezen identiteit van de applicatie gebruikt.
APPLICATIONINSIGHTS_AUTHENTICATION_STRING Maakt verbindingen mogelijk met Application Insights via Microsoft Entra-authenticatie. Stel in op ofwel Authorization=AAD (systeem-toegewezen) of ClientId=<YOUR_CLIENT_ID>;Authorization=AAD (door de gebruiker toegewezen).

Omdat de waarde met een dubbel onderstrepingsteken (__) tijdens runtime als een dubbele punt (:) wordt geïnterpreteerd, wordt de reeks instellingen geïnterpreteerd als eigenschappen van het AzureWebJobsStorage-object. Overweeg bijvoorbeeld deze AzureWebJobsStorage verbindingsinstellingen:

  • AzureWebJobsStorage__blobServiceUri=https://<STORAGE_ACCOUNT_NAME>.blob.core.windows.net
  • AzureWebJobsStorage__queueServiceUri=https://<STORAGE_ACCOUNT_NAME>.queue.core.windows.net
  • AzureWebJobsStorage__tableServiceUri=https://<STORAGE_ACCOUNT_NAME>.table.core.windows.net
  • AzureWebJobsStorage__credential=managedidentity
  • AzureWebJobsStorage__clientId=<MY_USER_ASSIGNED_IDENTITY_ID>

Tijdens runtime interpreteert de host deze instellingen als een complexe AzureWebJobsStorage setting.

"AzureWebJobsStorage":
{
    "blobServiceUri": "https://<STORAGE_ACCOUNT_NAME>.blob.core.windows.net",
    "queueServiceUri": "https://<STORAGE_ACCOUNT_NAME>.queue.core.windows.net",
    "tableServiceUri": "https://<STORAGE_ACCOUNT_NAME>.table.core.windows.net",
    "credential": "managedidentity",
    "clientId": "<MY_USER_ASSIGNED_IDENTITY_ID>"
}

Je moet ook rechten verlenen voor de identiteit in het standaard opslagaccount zodat de host met voldoende rechten kan verbinden om de vereiste taken uit te voeren. Om te leren hoe, zie Verlenen van rechten aan een identiteit.

Verleen rechten aan een identiteit

Wanneer je beheerde identiteiten gebruikt met Microsoft Entra ID-authenticatie, moet je specifiek rechten toewijzen aan de identiteit die je app gebruikt bij het maken van verbindingen met de externe dienst. De makkelijkste manier om least-privilege rechten aan je app toe te kennen is door ingebouwde rollen toe te wijzen.

Houd deze aanbevelingen in gedachten bij het verlenen van RBAC-rechten aan de identiteiten van je app:

  • Houd je waar mogelijk aan het principe van het minste privilege door de identiteit alleen de minimaal vereiste privileges te geven. Als de app bijvoorbeeld alleen uit een databron hoeft te lezen, gebruik dan een rol die alleen toestemming heeft om te lezen en niet om data te schrijven.
  • Gebruik geen brede ingebouwde rollen zoals Eigenaar, zelfs niet alleen om de app aan de praat te krijgen.
  • Nadat je een roltoewijzing hebt gemaakt of aangepast, kan het tot 10 minuten duren voordat de wijziging doorwerkt. In deze periode kan uw functie autorisatiefouten (403) ontvangen, ook al is de rol correct toegewezen. Als je direct na het aanmaken van een roltoewijzing fouten tegenkomt, wacht dan een paar minuten en probeer het opnieuw.
  • Wanneer meerdere verbindingen rechten voor dezelfde dienst vereisen, gebruik dan de rol die de minimale deelverzameling van de rechten is voor alle verbindingen met die dienst.
  • Verschillende bindings vereisen bredere rechten in je opslagaccount dan wat vereist is door de AzureWebJobsStorage verbinding.
  • Om toegang te krijgen tot sleutels in Key Vault met beheerde identiteiten, wijs je je app toe aan de rol Key Vault Secrets User. Je kunt ook een Key Vault-toegangsbeleid gebruiken om de Get Secrets-toestemming toe te wijzen aan de beheerde identiteit. Voor meer informatie, zie een identiteit in je app toegang geven tot je sleutelkluis.
  • Dit artikel verwijst alleen naar ingebouwde rollen die minimale rechten bieden. Afhankelijk van de vereisten van je app moet je mogelijk in plaats daarvan je eigen aangepaste rollen aanmaken.

De permissies die je nodig hebt, hangen af van het type verbinding:

  • AzureWebJobsStorage: De rol Storage Blob Data Owner biedt de minimale opslagaccountrechten voor de door de host vereiste AzureWebJobsStorage verbinding. Deze rol geeft het niveau van opslagtoegang dat de Functions-host nodig heeft, terwijl het principe van het minste privilege wordt gevolgd.

    Voor sommige soorten problemen kan Functions diagnostische gebeurtenissen oproepen om je te helpen bij het oplossen van problemen, zelfs als je app niet kan starten. Je moet ook de rol Storage Table Data Contributor toevoegen, die toegang biedt tot de Table Storage waar die diagnostische gebeurtenissen worden opgeslagen. Zonder deze extra toestemmingen kun je waarschuwingen in je logs zien over het onvermogen om deze gebeurtenissen te schrijven.

    Verschillende andere bindingen vereisen mogelijk dat je een iets bredere rol gebruikt. De kolom Door host vereiste opslag in de tabel op het tabblad Bindings bevat deze rolvereisten.

  • APPLICATIONINSIGHTS_AUTHENTICATION_STRING: De rol Monitoring Metrics Publisher geeft de minimale rechten die de host nodig heeft om verbinding te maken met Application Insights voor het loggen.

Notitie

Wanneer u APPLICATIONINSIGHTS_AUTHENTICATION_STRING gebruikt om verbinding te maken met Application Insights met behulp van Microsoft Entra-verificatie, moet u ook Disable lokale verificatie voor Application Insights. Voor deze configuratie is Microsoft Entra-verificatie vereist om telemetrie in uw werkruimte te verwerken.

Notitie

Gebruik Key Vault alleen voor verbindingen die momenteel geen Microsoft Entra ID ondersteunen met Azure beheerde identiteiten.

Omdat sommige diensten nog geen Microsoft Entra-authenticatie ondersteunen, kan je app in bepaalde gevallen toch geheimen vereisen. Voor deze gevallen kan Azure Key Vault helpen om de beheerslevenscyclus voor geheimen-gebaseerde authenticatie te stroomlijnen. Je app kan Key Vault gebruiken om gedeelde geheimen veiliger op te slaan en toegang te krijgen, inclusief de standaard verbindingsreeks van het opslagaccount. Hoewel verbindingen nog steeds gedeelde geheimen gebruiken, biedt Key Vault een hoger beveiligingsniveau voor je geheimen, inclusief sleutelonderhoud en rotatie. Je app kan verbinding maken met Key Vault door beheerde identiteiten te gebruiken, zelfs als de dienst zelf nog geen beheerde identiteitsgebaseerde verbindingen ondersteunt.

Wanneer je Key Vault gebruikt, maak je je applicatie-instelling voor de verbinding aan door een Key Vault-referentie te gebruiken in plaats van het daadwerkelijke geheim. Voor meer informatie, zie Source app-instellingen vanuit key vault.

Houd deze overwegingen in gedachten bij het onderhouden van verbindingen in Key Vault:

  • Om toegang te krijgen tot sleutels in de vault, moet je een identiteit in je app toegang geven tot je sleutelkluis.

  • Je kunt Key Vault gebruiken om instellingen op te slaan voor je beheerde identiteitsgebaseerde verbindingen. Wanneer je app Key Vault gebruikt, moeten referenties een sleutelseparator van : of /gebruiken, zoals Storage1:blobServiceUri. Wanneer je het reguliere scheidingsteken voor applicatie-instellingen van __ gebruikt, worden referentienamen niet correct herkend.

Je kunt de AzureWebJobsStorage instelling zo instellen dat een Key Vault-referentie terugkomt die de verbindingsreeks bevat in plaats van de verbindingsreeks zelf terug te geven. Zie Key Vault-verwijzingen gebruiken als app-instellingen voor meer informatie.

Azure Files ondersteunt momenteel geen managed identity-verbindingen. Vanwege deze beperking kun je Key Vault gebruiken om de WEBSITE_AZUREFILESCONNECTIONSTRING instelling te beveiligen, die vereist is voor dynamische schaalbaarheid door zowel Consumption- als Premium-abonnementen. Het Flex Consumption-plan is ook een dynamisch plan dat geen gebruik maakt van Azure Files en volledige ondersteuning biedt voor managed identity-verbindingen.

Waarschuwing

Vermijd direct werken met gedeelde geheimen. Gebruik waar mogelijk een veiligere authenticatiemethode voor je verbindingen.

Beperk de mogelijke nadelige risico's van verloren of gecompromitteerde geheimen door beheerde identiteiten te gebruiken met Microsoft Entra ID-authenticatie. Als de externe dienst geen beheerde identiteiten ondersteunt, gebruik dan in ieder geval Azure Key Vault, dat gedeelde geheimen veiliger bijhoudt.

Als je om wat voor reden dan ook geen veiligere authenticatiemethode kunt gebruiken, versleutelt het platform gegevens in je applicatie-instellingen terwijl het in rust is. Migreer je apps zo snel mogelijk van het gebruik van gedeelde geheimen naar een veiligere authenticatiemethode.

Stel de verbindingsreeks in voor het standaard opslagaccount in de AzureWebJobsStorage instelling. Deze instelling is het standaard verbindingsgedrag wanneer je je functie-app aanmaakt.

Beheer SDK-clientverbindingen

Wanneer je in de functiecode je eigen client-SDK-verbindingen maakt, hergebruik dan altijd dezelfde clientinstanties tussen aanroepen in plaats van nieuwe aan te maken. Deze best practice op alle hostingplannen vermindert de latentie, voorkomt socket-uitputting en verbetert de efficiëntie van hulpbronnen.

Hergebruik client-instanties

Volg deze richtlijnen bij het gebruik van een service-specifieke client in een Azure Functions-applicatie:

  • Maak niet bij elke functie-aanroep een nieuwe client aan.
  • Maak wel één enkele, gedeelde client aan die elke functie-aanroep kan hergebruiken.
  • Overweeg om een enkele, gedeelde client te maken in een helperklasse als verschillende functies dezelfde service gebruiken.

De aanbevolen aanpak hangt af van je taal:

Gebruik dependency injection om singleton- of scoped clients te registreren.

Zie voorbeelden van clientcode voor volledige patronen in elke taal.

Verbindingslimieten in een consumptieplan

Notitie

De in deze sectie beschreven harde verbindingslimieten gelden alleen voor het legacy Consumption-plan. Het Flex Consumption-plan draait niet in dezelfde sandbox-omgeving en legt deze limieten niet op. Toch wordt het nog steeds aanbevolen om clients te hergebruiken bij alle abonnementen voor optimale prestaties.

In het legacy Consumption-plan draaien functie-apps in een sandbox-omgeving die het aantal uitgaande verbindingen beperkt tot 600 actieve (in totaal 1.200) per instantie. Wanneer je deze limiet bereikt, schrijft de Functions-host het volgende bericht naar de logs: Host thresholds exceeded: Connections. Zie de servicelimieten van Functions voor meer informatie.

Deze limiet is per exemplaar. Wanneer de schaalcontroller functie-app-exemplaren toevoegt om meer aanvragen te verwerken, heeft elk exemplaar een onafhankelijke verbindingslimiet. Dat betekent dat er geen globale verbindingslimiet is, en je kunt meer dan 600 actieve verbindingen hebben in alle actieve instanties.

Zorg er bij het oplossen van verbindingsproblemen voor dat Application Insights is ingeschakeld voor je functie-app. Met Application Insights kunt u metrische gegevens voor uw functie-apps bekijken, zoals uitvoeringen. Zie Telemetrie weergeven in Application Insights voor meer informatie.

Voorbeelden van clientcode

In deze sectie ziet u de aanbevolen procedures voor het maken en gebruiken van clients op basis van uw functiecode.

HTTP-verzoeken

Registreer een gedeelde HttpClient door gebruik te maken van afhankelijkheidsinjectie zodat alle functieaanroepen dezelfde instantie hergebruiken. In dit geval hoef je de client niet te verwijderen omdat de runtime zijn levensduur beheert.

using Microsoft.Azure.Functions.Extensions.DependencyInjection;
using Microsoft.Extensions.DependencyInjection;

[assembly: FunctionsStartup(typeof(MyNamespace.Startup))]

namespace MyNamespace;

public class Startup : FunctionsStartup
{
    public override void Configure(IFunctionsHostBuilder builder)
    {
        builder.Services.AddHttpClient();
    }
}

Voeg vervolgens IHttpClientFactory of HttpClient toe aan je functieklasse:

using Microsoft.Azure.Functions.Worker;
using Microsoft.Extensions.Logging;

namespace MyNamespace;

public class MyFunction(HttpClient httpClient, ILogger<MyFunction> logger)
{
    [Function("MyFunction")]
    public async Task Run([TimerTrigger("0 */5 * * * *")] TimerInfo timer)
    {
        var response = await httpClient.GetAsync("https://example.com");
        logger.LogInformation("Response status: {Status}", response.StatusCode);
    }
}

Azure Cosmos DB clients

Registreer een singleton CosmosClient in je startup zodat alle functies één verbinding delen. De documentatie van Azure Cosmos DB raadt aan om een singleton-client te gebruiken gedurende de levensduur van je applicatie.

using Microsoft.Azure.Cosmos;
using Microsoft.Azure.Functions.Extensions.DependencyInjection;
using Microsoft.Extensions.DependencyInjection;

[assembly: FunctionsStartup(typeof(MyNamespace.Startup))]

namespace MyNamespace;

public class Startup : FunctionsStartup
{
    public override void Configure(IFunctionsHostBuilder builder)
    {
        builder.Services.AddSingleton(_ =>
        {
            var connectionString = Environment.GetEnvironmentVariable("CosmosDBConnection");
            return new CosmosClient(connectionString);
        });
    }
}

Voeg dan je functieklasse in:CosmosClient

using Microsoft.Azure.Cosmos;
using Microsoft.Azure.Functions.Worker;
using Microsoft.Extensions.Logging;

namespace MyNamespace;

public class MyCosmosFunction(CosmosClient cosmosClient, ILogger<MyCosmosFunction> logger)
{
    private readonly Container _container = cosmosClient.GetContainer("mydb", "mycontainer");

    [Function("MyCosmosFunction")]
    public async Task Run([TimerTrigger("0 */5 * * * *")] TimerInfo timer)
    {
        var item = new { id = "myId", partitionKey = "myPartitionKey", data = "example" };
        await _container.UpsertItemAsync(item, new PartitionKey("myPartitionKey"));
        logger.LogInformation("Item upserted");
    }
}

SqlClient-verbindingen

Uw functiecode kan de .NET Framework-gegevensprovider voor SQL Server (SqlClient) gebruiken om verbindingen te maken met een relationele SQL-database. Deze provider is ook de onderliggende aanbieder van dataframeworks die afhankelijk zijn van ADO.NET, zoals Entity Framework. In tegenstelling tot HttpClient- en DocumentClient-verbindingen implementeert ADO.NET standaard groepsgewijze verbindingen. Maar omdat u nog steeds geen verbindingen meer hebt, moet u verbindingen met de database optimaliseren. Zie SQL Server Connection Pooling (ADO.NET) voor meer informatie.

Tip

Sommige gegevensframeworks, zoals Entity Framework, krijgen doorgaans verbindingsreeks s uit de sectie ConnectionStrings van een configuratiebestand. In dit geval moet u expliciet SQL-database-verbindingsreeks s toevoegen aan de verzameling verbindingsreeksen van uw functie-app-instellingen en in het local.settings.json-bestand in uw lokale project. Als je een instantie van SqlConnection maakt in je functiecode, sla dan de verbindingsreeks-waarde op in de applicatie-instellingen samen met je andere verbindingen.

Azure App Configuration (Configuratie van Azure-apps)

Azure App Configuration is een Azure-dienst die je kunt gebruiken om applicatie-instellingen centraal te beheren. App Configuration ondersteunt hiërarchische sleutel-waardeparen en versiebeheer, en integreert met Azure Key Vault voor veiliger geheimbeheer. Voor meer informatie, zie Wat is Azure App Configuration?

Voor verbeterde beveiliging gebruikt je functie-app beheerde identiteiten met Microsoft Entra-authenticatie om instellingen in een Application Store te openen. Raadpleeg voor meer informatie App Configuration-verwijzingen gebruiken voor Azure Functions.

Notitie

Bij het gebruik van Azure App Configuration om instellingen voor beheerde identiteitsgebaseerde verbindingen op te slaan, moeten referenties een sleutelscheider van : of / in het formaat <CONNECTION_NAME_PREFIX>:fullyQualifiedNamespacegebruiken. Wanneer je het reguliere scheidingsteken voor applicatie-instellingen van __ gebruikt, worden referentienamen niet correct herkend.