Del via


Implementer Microsoft Fabric-backend

Dette lager med eksempler på udvikling af Microsoft Fabric-arbejdsbelastninger er et udgangspunkt for oprettelse af programmer, der kræver integration med forskellige tjenester og integration med lakehouse-arkitektur. Denne artikel hjælper dig med at konfigurere miljøet og konfigurere de nødvendige komponenter for at komme i gang. I artiklen beskrives nøglekomponenter og deres roller i arkitekturen.

Frontend

I frontend kan du administrere brugeroplevelsen (UX) og funktionsmåden. Den kommunikerer med Fabric-frontendportalen via en iFrame for at lette problemfri interaktion.

Du kan få flere oplysninger under Frontend til Microsoft Fabric Workload Development Kit.

Backend

Backend gemmer både data og metadata. Den bruger handlingerne Create, Read, Update og Delete (CRUD) til at oprette arbejdsbelastningselementer og metadata, og den udfører job for at udfylde data i lageret. Kommunikationen mellem frontend og backend etableres via offentlige API'er.

Azure Relay og DevGateway

Azure Relay muliggør kommunikation mellem det lokale udviklingsmiljø og Fabric-backend i udviklertilstand. I udviklertilstand fungerer arbejdsbelastningen på udviklerens maskine.

Værktøjet DevGateway har to roller:

  • Den håndterer arbejdsbelastningens side af Azure Relay-kanalen og administrerer registreringen af den lokale forekomst af arbejdsbelastningen med Fabric i forbindelse med et bestemt arbejdsområde. Værktøjet håndterer afledning, når kanalen afbryder forbindelsen.
  • Det fungerer sammen med Azure Relay til at kanalarbejdsbelastnings-API-kald fra Fabric til arbejdsbelastningen.

API-kald til Styring af arbejdsbelastning foretages direkte fra arbejdsbelastningen til Fabric. Azure Relay-kanalen er ikke påkrævet til opkaldene.

Integration af Lakehouse

Arkitekturen af arbejdsbelastningsudviklingspakken integreres problemfrit med en lakehouse-arkitektur til handlinger som lagring, læsning og hentning af data. Interaktionen lettes via Azure Relay og Fabric SDK for at sikre sikker og godkendt kommunikation. Du kan få flere oplysninger under Arbejde med kundedata.

Godkendelse og sikkerhed

Microsoft Entra ID bruges til sikker godkendelse, der sikrer, at alle interaktioner i arkitekturen er godkendt og sikre.

Oversigten over udviklingssæt giver et indblik i vores arkitektur. Du kan få flere oplysninger om, hvordan projekter konfigureres, om retningslinjer for godkendelse og om at komme i gang i følgende artikler:

Diagram, der viser, hvordan Fabric SDK kan integreres med Fabric.

Frontend etablerer kommunikation med Fabric-frontendportalen via en iFrame. Portalen interagerer igen med Fabric-backend ved at foretage kald til dens synlige offentlige API'er.

I forbindelse med interaktioner mellem backendudviklingsfeltet og Fabric-backend fungerer Azure Relay som en kanal. Derudover kan backend-udviklingsboksen integreres problemfrit med Lakehouse. Kommunikationen lettes ved hjælp af Azure Relay og Fabric Software Development Kit (SDK), der er installeret på backend-udviklingsfeltet.

Godkendelsen af al kommunikation i disse komponenter sikres via Microsoft Entra. Microsoft Entra leverer et sikkert og godkendt miljø til interaktionerne mellem frontend, backend, Azure Relay, Fabric SDK og Lakehouse.

Forudsætninger

Sørg for, at NuGet-Pakkestyring er integreret i din Visual Studio-installation. Dette værktøj er påkrævet til strømlinet administration af eksterne biblioteker og pakker, der er vigtige for vores projekt.

Administration af NuGet-pakke

  • <NuspecFile>Packages\manifest\ManifestPackageDebug.nuspec</NuspecFile> og <NuspecFile>Packages\manifest\ManifestPackageRelease.nuspec</NuspecFile>: Disse egenskaber angiver stien til de NuSpec-filer, der bruges til at oprette NuGet-pakken til fejlfindings- og udgivelsestilstande. NuSpec-filen indeholder metadata om pakken, f.eks. id, version, afhængigheder og andre relevante oplysninger.

  • <GeneratePackageOnBuild>true</GeneratePackageOnBuild>: Når den er angivet til true, instruerer denne egenskab buildprocessen om automatisk at generere en NuGet-pakke under hvert build. Denne egenskab er nyttig for at sikre, at pakken altid er opdateret med de seneste ændringer i projektet.

  • <IsPackable>true</IsPackable>: Når den er angivet til true, angiver denne egenskab, at projektet kan pakkes ind i en NuGet-pakke. At kunne pakkes er en vigtig egenskab for projekter, der er beregnet til at producere NuGet-pakker under buildprocessen.

Den genererede NuGet-pakke til fejlfindingstilstand er placeret i mappen src\bin\Debug efter buildprocessen.

Når du arbejder i cloudtilstand, kan du ændre konfigurationen af Visual Studio-buildet til Udgivelse og oprettelse af din pakke. Den genererede pakke er placeret i src\bin\Release mappen. Du kan få flere oplysninger i Vejledning til arbejde i cloudtilstand.

Afhængigheder

  • Eksemplet på backend-standardskabelonen afhænger af følgende Azure SDK-pakker:

    • Azure.Core
    • Azure.Identity
    • Azure.Storage.Files.DataLake
    • Microsoft Identity-pakken

Hvis du vil konfigurere NuGet Pakkestyring, skal du angive stien i afsnittet Pakkekilder, før du starter buildprocessen.

<Project Sdk="Microsoft.NET.Sdk.Web">

  <PropertyGroup>
    <TargetFramework>net7.0</TargetFramework>
    <AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
    <BuildDependsOn>PreBuild</BuildDependsOn>
    <GeneratePackageOnBuild>true</GeneratePackageOnBuild>
    <IsPackable>true</IsPackable>
  </PropertyGroup>
  
  <PropertyGroup Condition="'$(Configuration)' == 'Release'">
    <NuspecFile>Packages\manifest\ManifestPackageRelease.nuspec</NuspecFile>
  </PropertyGroup>

  <PropertyGroup Condition="'$(Configuration)' == 'Debug'">
    <NuspecFile>Packages\manifest\ManifestPackageDebug.nuspec</NuspecFile>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Azure.Core" Version="1.38.0" />
    <PackageReference Include="Azure.Identity" Version="1.11.0" />
    <PackageReference Include="Azure.Storage.Files.DataLake" Version="12.14.0" />
    <PackageReference Include="Microsoft.AspNet.WebApi.Client" Version="5.2.9" />
    <PackageReference Include="Microsoft.AspNetCore.Mvc.NewtonsoftJson" Version="7.0.5" />
    <PackageReference Include="Microsoft.Extensions.Logging.Debug" Version="7.0.0" />
    <PackageReference Include="Microsoft.Identity.Client" Version="4.60.3" />
    <PackageReference Include="Microsoft.IdentityModel.Protocols" Version="6.30.1" />
    <PackageReference Include="Microsoft.IdentityModel.Protocols.OpenIdConnect" Version="6.30.1" />
    <PackageReference Include="Microsoft.IdentityModel.Tokens" Version="6.30.1" />
    <PackageReference Include="Swashbuckle.AspNetCore" Version="6.5.0" />
  </ItemGroup>

  <ItemGroup>
    <Folder Include="Properties\ServiceDependencies\" />
  </ItemGroup>

  <Target Name="PreBuild" BeforeTargets="PreBuildEvent">
    <Exec Command="powershell.exe -ExecutionPolicy Bypass -File ValidationScripts\RemoveErrorFile.ps1 -outputDirectory ValidationScripts\" />
    <Exec Command="powershell.exe -ExecutionPolicy Bypass -File ValidationScripts\ManifestValidator.ps1 -inputDirectory .\Packages\manifest\ -inputXml WorkloadManifest.xml -inputXsd WorkloadDefinition.xsd -outputDirectory ValidationScripts\" />
    <Exec Command="powershell.exe -ExecutionPolicy Bypass -File ValidationScripts\ItemManifestValidator.ps1 -inputDirectory .\Packages\manifest\ -inputXsd ItemDefinition.xsd -outputDirectory ValidationScripts\" />
    <Exec Command="powershell.exe -ExecutionPolicy Bypass -File ValidationScripts\ValidateNoDefaults.ps1 -outputDirectory ValidationScripts\" />
    <Error Condition="Exists('ValidationScripts\ValidationErrors.txt')" Text="Validation errors with either manifests or default values" File="ValidationScripts\ValidationErrors.txt" />
  </Target>

</Project>

Kom i gang

Sådan konfigurerer du arbejdsbelastningseksempelprojektet på din lokale computer:

  1. Klon lageret: Kør git clone https://github.com/microsoft/Microsoft-Fabric-workload-development-sample.git.

  2. Åbn løsningen i Visual Studio 2022.

  3. Konfigurer en appregistrering ved at følge vejledningen i godkendelses selvstudiet. Sørg for, at både dine frontend- og backendprojekter har den nødvendige konfiguration, der er beskrevet i artiklen. Microsoft Entra bruges til sikker godkendelse for at sikre, at alle interaktioner i arkitekturen er godkendt og sikre.

  4. Opdater Microsoft OneLake DFS-basis-URL-adressen. Afhængigt af dit Fabric-miljø kan du muligvis opdatere værdien for OneLakeDFSBaseURL i mappen src\Constants . Standarden er onelake.dfs.fabric.microsoft.com, men du kan opdatere URL-adressen, så den afspejler dit miljø. Du kan få flere oplysninger om DFS-stier i dokumentationen til OneLake.

  5. Konfigurer konfigurationen af arbejdsbelastningen.

    1. Kopiér workload-dev-mode.json fra src/Config til C:.
    2. Opdater følgende felter i workload-dev-mode.json-filen, så de stemmer overens med konfigurationen:
      • WorkspaceGuid: Dit arbejdsområde-id. Du kan finde denne værdi i browserens URL-adresse, når du vælger et arbejdsområde i Fabric. F.eks., https://app.powerbi.com/groups/<WorkspaceID>/.
      • ManifestPackageFilePath: Placeringen af manifestpakken. Når du opretter løsningen, gemmes manifestpakken i src\bin\Debug. Du kan få flere oplysninger om manifestpakken senere i artiklen.
      • WorkloadEndpointURL: URL-adressen til arbejdsbelastningens slutpunkt.
    3. Opdater følgende felter i filen Packages/manifest/WorkloadManifest.xml , så de stemmer overens med konfigurationen:
      • <AppId>: Klient-id'et (program-id) for Microsoft Entra-applikationens arbejdsbelastning.
      • <RedirectUri>: Omdirigerings-URI'erne. Du kan finde denne værdi i den appregistrering, du har oprettet, under Godkendelse.
      • <ResourceId>: Målgruppen for de indgående Microsoft Entra-tokens. Du kan finde disse oplysninger i den appregistrering, du har oprettet, under Vis en API.
    4. Opdater følgende felter i filen src/appsettings.json , så de stemmer overens med konfigurationen:
      • PublisherTenantId: Id'et for lejeren af arbejdsbelastningsudgiveren.
      • ClientId: Klient-id'et (program-id) for Microsoft Entra-applikationens arbejdsbelastning.
      • ClientSecret: Hemmeligheden for arbejdsbelastningen i Microsoft Entra-programmet.
      • Målgruppe: Målgruppen for de indgående Microsoft Entra-tokens. Du kan finde disse oplysninger i den appregistrering, du har oprettet, under Vis en API. Denne indstilling kaldes også program-id-URI'en.
  6. Opret en manifestpakke.

    Hvis du vil oprette en manifestpakkefil, skal du bygge Fabric_Extension_BE_Boilerplate. Buildet er en proces med tre trin, der genererer manifestpakkefilen. Den kører disse trin:

    1. Udløser ManifestValidator.ps1WorkloadManifest.xml i Packages\manifest/ og udløser ItemManifestValidator.ps1 på alle elementer XMLs (f.eks. Item1.xml) i Packages\manifest/. Hvis valideringen mislykkes, oprettes der en fejlfil. Du kan få vist valideringsscripts i ValidationScripts/.
    2. Hvis der findes en fejlfil, mislykkes buildet med fejlvalideringsfejl med enten manifester eller standardværdier. Hvis du vil se fejlfilen i Visual Studio, skal du dobbeltklikke på fejlen i valideringsresultaterne.
    3. Når valideringen er fuldført, skal du pakke filerne WorkloadManifest.xml og Item1.xml til ManifestPackage.1.0.0.nupkg. Den resulterende pakke er i src\bin\Debug.

    Kopiér filen ManifestPackage.1.0.0.nupkg til den sti, der er defineret i workload-dev-mode.json konfigurationsfilen.

  7. Program.cs er indgangspunktet og startscriptet for dit program. I denne fil kan du konfigurere forskellige tjenester, initialisere programmet og starte webværten.

  8. Opret for at sikre, at dit projekt kan få adgang til de påkrævede afhængigheder til kompilering og udførelse.

  9. Download DevGateway fra Microsofts Download Center

  10. Kør Microsoft.Fabric.Workload.DevGateway.exe-programmet, og log på med en bruger, der har administratorrettigheder til arbejdsområdet for det WorkspaceGuid arbejdsområde, der er angivet i feltet workload-dev-mode.json.

    Skærmbillede af Microsoft-logonsiden.

    Efter godkendelse etablerer eksterne arbejdsbelastninger kommunikation med Fabric-backend via Azure Relay. Denne proces omfatter relæregistrering og kommunikationsstyring, der faciliteres af en angivet proxynode. Den pakke, der indeholder arbejdsbelastningsmanifestet, uploades og publiceres.

    På dette tidspunkt registrerer Fabric arbejdsbelastningen og inkorporerer den tildelte kapacitet.

    Du kan overvåge potentielle fejl i konsollen.

    Hvis der ikke vises nogen fejl, oprettes forbindelsen, registreringen udføres korrekt, og arbejdsbelastningsmanifestet uploades systematisk.

    Skærmbillede af indlæsning af forbindelse uden fejl.

  11. I Visual Studio skal du ændre dit startprojekt til standardprojektet og vælge Kør.

    Skærmbillede af brugergrænsefladen til startprojekt i Visual Studio.

Arbejd med standardeksemplet

Kodeoprettelse

Vi bruger arbejdsbelastningen Standardskabelon C# ASP.NET Core-eksempel til at demonstrere, hvordan du opretter en arbejdsbelastning ved hjælp af REST API'er. Eksemplet starter med generering af serverstubbe og kontraktklasser baseret på Swagger-specifikationen for Arbejdsbelastnings-API'en. Du kan generere koden ved hjælp af et af flere Swagger-kodegenereringsværktøjer. Standardprøven bruger NSwag. Eksemplet indeholder det GenerateServerStub.cmd kommandolinjescript, som ombryder NSwag-kodegeneratoren. Scriptet bruger en enkelt parameter, som er en komplet sti til NSwag-installationsmappen. Den søger også efter Swagger-definitionsfilen (swagger.json) og konfigurationsfilen (nswag.json) i mappen.

Udførelse af dette script opretter en C#-fil med navnet WorkloadAPI_Generated.cs. Indholdet af denne fil kan logisk opdeles i tre dele, som forklaret i de næste afsnit.

ASP.NET Core-stubcontrollere

ItemLifecycleController og JobsController klasser er tynde implementeringer af ASP.NET Core-controllere for to undersæt af Arbejdsbelastnings-API'en: administration af elementlivscyklus og job. Disse klasser er sluttet til http-pipelinen ASP.NET Core. De fungerer som indgangspunkter for de API-metoder, der er defineret i Swagger-specifikationen. Klasserne videresender kald til den "rigtige" implementering, der leveres af arbejdsbelastningen.

Her er et eksempel på CreateItem metoden:

/// <summary>
/// Called by Microsoft Fabric for creating a new item.
/// </summary>
/// <remarks>
/// Upon item creation Fabric performs some basic validations, creates the item with 'provisioning' state and calls this API to notify the workload. The workload is expected to perform required validations, store the item metadata, allocate required resources, and update the Fabric item metadata cache with item relations and ETag. To learn more see [Microsoft Fabric item update flow](https://updateflow).
/// <br/>
/// <br/>This API should accept [SubjectAndApp authentication](https://subjectandappauthentication).
/// <br/>
/// <br/>##Permissions
/// <br/>Permissions are checked by Microsoft Fabric.
/// </remarks>
/// <param name="workspaceId">The workspace ID.</param>
/// <param name="itemType">The item type.</param>
/// <param name="itemId">The item ID.</param>
/// <param name="createItemRequest">The item creation request.</param>
/// <returns>Successfully created.</returns>
[Microsoft.AspNetCore.Mvc.HttpPost, Microsoft.AspNetCore.Mvc.Route("workspaces/{workspaceId}/items/{itemType}/{itemId}")]
public System.Threading.Tasks.Task CreateItem(System.Guid workspaceId, string itemType, System.Guid itemId, [Microsoft.AspNetCore.Mvc.FromBody] CreateItemRequest createItemRequest)
{

 return _implementation.CreateItemAsync(workspaceId, itemType, itemId, createItemRequest);
}

Grænseflader til implementering af arbejdsbelastninger

IItemLifecycleController og IJobsController er grænseflader for de tidligere nævnte "reelle" implementeringer. De definerer de samme metoder, som controllerne implementerer.

Definition af kontraktklasser

C# kontraktklasser er klasser, som API'erne bruger.

Implementering

Det næste trin, efter at du har genereret kode, er implementering af IItemLifecycleController grænsefladerne og IJobsController . I standardeksemplet skal ItemLifecycleControllerImpl du JobsControllerImpl implementere disse grænseflader.

Denne kode er f.eks. implementeringen af CreateItem-API'en:

/// <inheritdoc/>
public async Task CreateItemAsync(Guid workspaceId, string itemType, Guid itemId, CreateItemRequest createItemRequest)
{
 var authorizationContext = await _authenticationService.AuthenticateControlPlaneCall(_httpContextAccessor.HttpContext);
 var item = _itemFactory.CreateItem(itemType, authorizationContext);
 await item.Create(workspaceId, itemId, createItemRequest);
}

Håndter en nyttedata for et element

Flere API-metoder accepterer forskellige typer "nyttedata" som en del af anmodningens brødtekst, eller de returnerer nyttedata som en del af svaret. Har CreateItemRequest f.ekscreationPayload. egenskaben .

"CreateItemRequest": {
 "description": "Create item request content.",
 "type": "object",
 "additionalProperties": false,
 "required": [ "displayName" ],
 "properties": {
 "displayName": {
  "description": "The item display name.",
  "type": "string",
  "readOnly": false
 },
 "description": {
  "description": "The item description.",
  "type": "string",
  "readOnly": false
 },
 "creationPayload": {
  "description": "Creation payload specific to the workload and item type, passed by the item editor or as Fabric Automation API parameter.",
  "$ref": "#/definitions/CreateItemPayload",
  "readOnly": false
 }
 }
}

Typerne for disse nyttedataegenskaber er defineret i Swagger-specifikationen. Der er en dedikeret type til alle typer nyttedata. Disse typer definerer ikke nogen specifikke egenskaber, og de tillader, at en egenskab medtages.

Her er et eksempel på typen CreateItemPayload :

"CreateItemPayload": {
 "description": "Creation payload specific to the workload and item type.",
 "type": "object",
 "additionalProperties": true
}

De genererede C#-kontraktklasser er defineret som partial. De har defineret en ordbog med egenskaber.

Her er et eksempel:

/// <summary>
/// Creation payload specific to the workload and item type.
/// </summary>
[System.CodeDom.Compiler.GeneratedCode("NJsonSchema", "13.20.0.0 (NJsonSchema v10.9.0.0 (Newtonsoft.Json v13.0.0.0))")]
public partial class CreateItemPayload
{
 private System.Collections.Generic.IDictionary<string, object> _additionalProperties;

 [Newtonsoft.Json.JsonExtensionData]
 public System.Collections.Generic.IDictionary<string, object> AdditionalProperties
 {
  get { return _additionalProperties ?? (_additionalProperties = new System.Collections.Generic.Dictionary<string, object>()); }
  set { _additionalProperties = value; }
 }
}

Koden kan bruge denne ordbog til at læse og returnere egenskaber. En bedre tilgang er dog at definere specifikke egenskaber ved hjælp af tilsvarende typer og navne. Du kan bruge erklæringen på partial de genererede klasser til effektivt at definere egenskaber.

Den CreateItemPayload.cs fil indeholder f.eks. en supplerende definition af CreateItemPayload klassen.

I dette eksempel tilføjer Item1Metadata definitionen egenskaben:

namespace Fabric_Extension_BE_Boilerplate.Contracts.FabricAPI.Workload
{
    /// <summary>
    /// Extend the generated class by adding item-type-specific fields.
    /// In this sample every type will have a dedicated property. Alternatively, polymorphic serialization could be used.
    /// </summary>
    public partial class CreateItemPayload
    {
        [Newtonsoft.Json.JsonProperty("item1Metadata", Required = Newtonsoft.Json.Required.Default, NullValueHandling = Newtonsoft.Json.NullValueHandling.Ignore)]
        public Item1Metadata Item1Metadata { get; init; }
    }
}

Men hvis arbejdsbelastningen understøtter flere elementtyper, CreateItemPayload skal klassen kunne håndtere forskellige typer oprettelsesnyttedata med én pr. elementtype. Du har to muligheder. Den enklere måde, der bruges i standardskabeloneksemplet, er at definere flere valgfri egenskaber, der hver især repræsenterer oprettelsesnyttedata for en anden elementtype. Hver anmodning har derefter kun et af disse sæt egenskaber i henhold til den elementtype, der oprettes. Du kan også implementere polymorf serialisering, men denne indstilling vises ikke i eksemplet, fordi indstillingen ikke giver nogen betydelige fordele.

Hvis du f.eks. vil understøtte to elementtyper, skal klassedefinitionen udvides som i følgende eksempel:

namespace Fabric_Extension_BE_Boilerplate.Contracts.FabricAPI.Workload
{
    public partial class CreateItemPayload
    {
        [Newtonsoft.Json.JsonProperty("item1Metadata", Required = Newtonsoft.Json.Required.Default, NullValueHandling = Newtonsoft.Json.NullValueHandling.Ignore)]
        public Item1Metadata Item1Metadata { get; init; }

        [Newtonsoft.Json.JsonProperty("item2Metadata", Required = Newtonsoft.Json.Required.Default, NullValueHandling = Newtonsoft.Json.NullValueHandling.Ignore)]
        public Item2Metadata Item2Metadata { get; init; }
    } 
}

Bemærk

Den nyttedata, der sendes til arbejdsbelastningen, genereres af klienten. Det kan være elementeditoren iFrame eller Fabric Automation REST-API'en. Klienten er ansvarlig for at sende den korrekte nyttedata og matche elementtypen. Arbejdsbelastningen er ansvarlig for bekræftelse. Fabric behandler denne nyttelast som et uigennemsigtigt objekt og overfører den kun fra klienten til arbejdsbelastningen. På samme måde er det arbejdsbelastningens og klientens ansvar at håndtere nyttedataene korrekt for en nyttedata, der returneres af arbejdsbelastningen til klienten.

Denne kode viser f.eks., hvordan standardeksempelelement1-implementeringen håndterer nyttedataene:

protected override void SetDefinition(CreateItemPayload payload)
{
 if (payload == null)
 {
  Logger.LogInformation("No payload is provided for {0}, objectId={1}", ItemType, ItemObjectId);
  _metadata = Item1Metadata.Default.Clone();
  return;
 }

 if (payload.Item1Metadata == null)
 {
  throw new InvalidItemPayloadException(ItemType, ItemObjectId);
 }

 if (payload.Item1Metadata.Lakehouse == null)
 {
  throw new InvalidItemPayloadException(ItemType, ItemObjectId)
   .WithDetail(ErrorCodes.ItemPayload.MissingLakehouseReference, "Missing Lakehouse reference");
 }

 _metadata = payload.Item1Metadata.Clone();
}

Foretag fejlfinding og fejlfinding

I de næste afsnit beskrives det, hvordan du kan foretage fejlfinding og foretage fejlfinding af installationen.

Kendte problemer og løsninger

Få oplysninger om kendte problemer og måder at løse dem på.

Manglende klienthemmelighed

Fejl:

Microsoft.Identity.Client.MsalServiceException: Et konfigurationsproblem forhindrer godkendelse. Du kan finde flere oplysninger i fejlmeddelelsen fra serveren. Du kan ændre konfigurationen i programregistreringsportalen. Se https://aka.ms/msal-net-invalid-client for at få flere oplysninger.

Oprindelig undtagelse: AADSTS7000215: Der blev angivet en ugyldig klienthemmelighed. Sørg for, at den hemmelighed, der sendes i anmodningen, er værdien for klienthemmeligheden og ikke klienthemmeligheds-id'et for en hemmelighed, der føjes til appindstillingen app_guid .

Løsning: Sørg for, at du har defineret den korrekte klienthemmelighed i appsettings.json.

Fejl:

Microsoft.Identity.Client.MsalUiRequiredException: AADSTS65001: Brugeren eller administratoren gav ikke samtykke til at bruge programmet med id .<example ID> Send en interaktiv godkendelsesanmodning for denne bruger og ressource.

Løsning:

  1. I elementeditoren skal du gå til bunden af smerten og vælge Naviger til godkendelsesside.

  2. Under Områder skal du angive .default og derefter vælge Hent adgang-token.

  3. I dialogboksen skal du godkende revisionen.

Oprettelsen af elementet mislykkes på grund af valg af kapacitet

Fejl:

PriorityPlacement: Der er ingen kernetjenester tilgængelige til prioritetsplacering. Kun name, guidog workload-name er tilgængelige.

Løsning:

Som bruger har du muligvis kun adgang til prøvekapaciteten. Sørg for, at du bruger en kapacitet, du har adgang til.

Fejl ved oprettelse af fil med 404-fejl (NotFound)

Fejl:

Oprettelse af en ny fil mislykkedes for filePath: 'workspace-id'/'lakehouse-id'/Files/data.json. Svarstatuskoden angiver ikke, om det lykkedes: 404 (NotFound).

Løsning:

Sørg for, at du arbejder med den OneLake DFS-URL-adresse, der passer til dit miljø. Hvis du f.eks. arbejder med et PPE-miljø, skal du ændre EnvironmentConstants.OneLakeDFSBaseUrlConstants.cs til den relevante URL-adresse.

Fejlfind

Når du foretager fejlfinding af forskellige handlinger, kan du angive pausepunkter i koden for at analysere og foretage fejlfinding af funktionsmåden. Følg disse trin for effektiv fejlfinding:

  1. Åbn koden i dit udviklingsmiljø.
  2. Gå til den relevante handlingshandlerfunktion (f.eks OnCreateFabricItemAsync . for CRUD-handlinger eller et slutpunkt i en controller for execute handlinger).
  3. Placer pausepunkter på bestemte linjer, hvor du vil undersøge koden.
  4. Kør programmet i fejlfindingstilstand.
  5. Udløs handlingen fra den frontend, du vil foretage fejlfinding af.

Fejlfindingsprogrammet afbryder udførelsen midlertidigt ved de angivne pausepunkter, så du kan undersøge variabler, gennemgå koden og identificere problemer.

Skærmbillede af eksempelprogram med pausepunkter til fejlfinding.

Arbejdsområde

Hvis du er en, der opretter forbindelse mellem en backend og eksempelarbejdsbelastningsprojektet, skal dit element tilhøre et arbejdsområde, der er knyttet til en kapacitet. Arbejdsområdet Mit arbejdsområde er som standard ikke knyttet til en kapacitet. Ellers får du muligvis vist den fejl, der vises på følgende skærmbillede:

Skærmbillede af brugergrænsefladen til navngivning af et eksempel på et arbejdsbelastningselement.

  1. Skift til et navngivet arbejdsområde. Behold standardarbejdsområdets navn Mit arbejdsområde.

  2. Indlæs eksempelarbejdsbelastningen fra det korrekte arbejdsområde, og fortsæt med testene:

Bidrag

Vi glæder os over bidrag til dette projekt. Hvis du finder problemer eller vil tilføje nye funktioner, skal du følge disse trin:

  1. Kopiér lageret.
  2. Opret en ny forgrening til din funktion eller fejlrettelse.
  3. Foretag dine ændringer, og bekræft dem derefter.
  4. Send dine ændringer til dit kopierede lager.
  5. Opret en pullanmodning, der indeholder en tydelig beskrivelse af dine ændringer.