Del via


Implementere Microsoft Fabric-serverdel

Dette eksempelrepositoriet for microsoft Fabric-arbeidsbelastningsutvikling er et utgangspunkt for å bygge programmer som krever integrering med ulike tjenester og for integrering med lakehouse-arkitektur. Denne artikkelen hjelper deg med å konfigurere miljøet og konfigurere de nødvendige komponentene for å komme i gang. Artikkelen beskriver viktige komponenter og deres roller i arkitekturen.

Frontend

Frontend er der du administrerer brukeropplevelsen (UX) og virkemåten. Den kommuniserer med Fabric frontend-portalen via en iFrame for å legge til rette for sømløs samhandling.

Hvis du vil ha mer informasjon, kan du se Microsoft Fabric Workload Development Kit frontend.

Serverdel

Serverdel lagrer både data og metadata. Den bruker operasjonene Opprett, Les, Oppdater og Slett (CRUD) til å opprette arbeidsbelastningselementer og metadata, og den utfører jobber for å fylle ut data på lager. Kommunikasjon mellom frontend og backend etableres gjennom offentlige API-er.

Azure Relay og DevGateway

Azure Relay muliggjør kommunikasjon mellom det lokale utviklingsmiljøet og Fabric-serverdel i utviklermodus. I utviklermodus fungerer arbeidsbelastningen på utviklerens maskin.

DevGateway-verktøyet har to roller:

  • Den håndterer arbeidsbelastningens side av Azure Relay-kanalen og administrerer registreringen av den lokale arbeidsbelastningsforekomsten med Fabric i sammenheng med et bestemt arbeidsområde. Verktøyet håndterer avregistrering når kanalen kobles fra.
  • Det fungerer med Azure Relay for å kanalisere arbeidsbelastnings-API-anrop fra Fabric til arbeidsbelastningen.

API-kall for arbeidsbelastningskontroll foretas direkte fra arbeidsbelastningen til Fabric. Azure Relay-kanalen er ikke nødvendig for samtalene.

Lakehouse-integrering

Arkitekturen for arbeidsbelastningsutviklingspakken integreres sømløst med en lakehouse-arkitektur for operasjoner som lagring, lesing og henting av data. Samhandlingen legges til rette gjennom Azure Relay og Fabric SDK for å sikre sikker og godkjent kommunikasjon. Hvis du vil ha mer informasjon, kan du se arbeide med kundedata.

Godkjenning og sikkerhet

Microsoft Entra ID brukes til sikker godkjenning, slik at alle samhandlinger i arkitekturen er autoriserte og sikre.

Oversikten over utviklingspakken gir et glimt inn i arkitekturen vår. Hvis du vil ha mer informasjon om hvordan prosjekter konfigureres, for retningslinjer for godkjenning og for å komme i gang, kan du se følgende artikler:

Diagram som viser hvordan Fabric SDK integreres med Fabric.

Frontend etablerer kommunikasjon med Fabric frontend-portalen via en iFrame. Portalen i sin tur samhandler med Fabric backend ved å ringe til sine eksponerte offentlige API-er.

For samhandlinger mellom bakdelutviklingsboksen og Fabric-serverdel, fungerer Azure Relay som en kanal. I tillegg integreres bakdelutviklingsboksen sømløst med Lakehouse. Kommunikasjonen er tilrettelagt ved hjelp av Azure Relay og Fabric Software Development Kit (SDK) installert på bakdelutviklingsboksen.

Godkjenningen for all kommunikasjon i disse komponentene sikres via Microsoft Entra. Microsoft Entra tilbyr et sikkert og godkjent miljø for samhandlingene mellom frontend, backend, Azure Relay, Fabric SDK og Lakehouse.

Forutsetning

Kontroller at NuGet-Pakkebehandling er integrert i Visual Studio-installasjonen. Dette verktøyet er nødvendig for strømlinjeformet administrasjon av eksterne biblioteker og pakker som er avgjørende for prosjektet vårt.

NuGet-pakkeadministrasjon

  • <NuspecFile>Packages\manifest\ManifestPackageDebug.nuspec</NuspecFile> og <NuspecFile>Packages\manifest\ManifestPackageRelease.nuspec</NuspecFile>: Disse egenskapene angir banen til NuSpec-filene som brukes til å opprette NuGet-pakken for feilsøkings- og utgivelsesmoduser. NuSpec-filen inneholder metadata om pakken, for eksempel ID, versjon, avhengigheter og annen relevant informasjon.

  • <GeneratePackageOnBuild>true</GeneratePackageOnBuild>: Når den er satt til true, instruerer denne egenskapen byggeprosessen til automatisk å generere en NuGet-pakke under hvert bygg. Denne egenskapen er nyttig for å sikre at pakken alltid er oppdatert med de siste endringene i prosjektet.

  • <IsPackable>true</IsPackable>: Når den er satt til true, angir denne egenskapen at prosjektet kan pakkes inn i en NuGet-pakke. Å være pakkebar er en viktig egenskap for prosjekter som er ment å produsere NuGet-pakker under byggprosessen.

Den genererte NuGet-pakken for feilsøkingsmodus er plassert i src\bin\Debug-katalogen etter build-prosessen.

Når du arbeider i skymodus, kan du endre konfigurasjonen for Visual Studio-bygg til Utgivelse og bygg pakken. Den genererte pakken er plassert i katalogen src\bin\Release . Hvis du vil ha mer informasjon, kan du se Veiledning for arbeid i skymodus.

Avhengigheter

  • Serverdeleksemplet avhenger av følgende Azure SDK-pakker:

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

Hvis du vil konfigurere NuGet Pakkebehandling, angir du banen i pakkekilder-delen før du starter byggeprosessen.

<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

Slik konfigurerer du eksempelprosjektet for arbeidsbelastning på den lokale maskinen:

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

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

  3. Konfigurer en appregistrering ved å følge instruksjonene i godkjenningsopplæringen. Kontroller at både frontend- og backend-prosjektene har det nødvendige oppsettet som er beskrevet i artikkelen. Microsoft Entra brukes til sikker godkjenning for å sikre at alle samhandlinger i arkitekturen er autoriserte og sikre.

  4. Oppdater url-adressen for Microsoft OneLake DFS-grunnadressen. Avhengig av stoffmiljøet kan du kanskje oppdatere verdien for OneLakeDFSBaseURL i src\Constants-mappen . Standardverdien er onelake.dfs.fabric.microsoft.com, men du kan oppdatere nettadressen for å gjenspeile miljøet. Hvis du vil ha mer informasjon om DFS-baner, kan du se OneLake-dokumentasjonen.

  5. Konfigurer konfigurasjonen av arbeidsbelastningen.

    1. Kopier workload-dev-mode.json fra src/Config til C:.
    2. Oppdater følgende felt i workload-dev-mode.json-filen for å samsvare med konfigurasjonen:
      • WorkspaceGuid: ID-en for arbeidsområdet. Du finner denne verdien i nettadressen for nettleseren når du velger et arbeidsområde i Fabric. Eksempel: https://app.powerbi.com/groups/<WorkspaceID>/.
      • ManifestPackageFilePath: Plasseringen av manifestpakken. Når du bygger løsningen, lagres manifestpakken i src\bin\Debug. Du finner mer informasjon om manifestpakken senere i artikkelen.
      • WorkloadEndpointURL: URL-adressen for arbeidsbelastningsendepunktet.
    3. Oppdater følgende felt i pakkene/manifestet/WorkloadManifest.xml-filen for å samsvare med konfigurasjonen:
      • <AppId>: Klient-ID -en (program-ID) for arbeidsbelastningen Microsoft Entra-programmet.
      • <RedirectUri>: Omadresserings-URIene. Du finner denne verdien i appregistreringen du opprettet, under Godkjenning.
      • <ResourceId>: Målgruppen for innkommende Microsoft Entra-tokener. Du finner denne informasjonen i appregistreringen du opprettet, under Vis en API.
    4. Oppdater følgende felt i src/appsettings.json-filen for å samsvare med konfigurasjonen:
      • PublisherTenantId: ID-en til arbeidsbelastningsutgiverleieren.
      • ClientId: Klient-ID -en (program-ID) for arbeidsbelastningen Microsoft Entra-programmet.
      • ClientSecret: Hemmeligheten bak arbeidsbelastningen Microsoft Entra-programmet.
      • Målgruppe: Målgruppen for innkommende Microsoft Entra-tokener. Du finner denne informasjonen i appregistreringen du opprettet, under Vis en API. Denne innstillingen kalles også program-ID URI.
  6. Generer en manifestpakke.

    Hvis du vil generere en manifestpakkefil, bygger du Fabric_Extension_BE_Boilerplate. Bygget er en tretrinnsprosess som genererer manifestpakkefilen. Den kjører disse trinnene:

    1. Utløser ManifestValidator.ps1WorkloadManifest.xml i Pakker\manifest/ og utløser ItemManifestValidator.ps1 på alle elementer XMLs (for eksempel Item1.xml) i Pakker\manifest/. Hvis valideringen mislykkes, genereres en feilfil. Du kan vise valideringsskriptene i ValidationScripts/.
    2. Hvis det finnes en feilfil, mislykkes bygget med feilvalideringsfeilene med manifester eller standardverdier. Hvis du vil se feilfilen i Visual Studio, dobbeltklikker du feilen i valideringsresultatene.
    3. Etter vellykket validering pakker du WorkloadManifest.xml og Item1.xml filer i ManifestPackage.1.0.0.nupkg. Den resulterende pakken er i src\bin\Debug.

    Kopier ManifestPackage.1.0.0.nupkg-filen til banen som er definert i workload-dev-mode.json konfigurasjonsfilen.

  7. Program.cs er inngangspunktet og oppstartsskriptet for programmet. I denne filen kan du konfigurere ulike tjenester, initialisere programmet og starte webverten.

  8. Bygg for å sikre at prosjektet har tilgang til de nødvendige avhengighetene for kompilering og kjøring.

  9. Last ned DevGateway fra Microsofts nedlastingssenter

  10. Kjør Microsoft.Fabric.Workload.DevGateway.exe-programmet, og logg på med en bruker som har administratorrettigheter for arbeidsområdet for arbeidsområdet som er angitt i WorkspaceGuid feltet workload-dev-mode.json.

    Skjermbilde av Påloggingssiden for Microsoft.

    Etter godkjenning etablerer eksterne arbeidsbelastninger kommunikasjon med Fabric-serverdel via Azure Relay. Denne prosessen innebærer videresending av registrering og kommunikasjonsadministrasjon som er tilrettelagt av en angitt proxy-node. Pakken som inneholder arbeidsbelastningsmanifestet, lastes opp og publiseres.

    På dette stadiet oppdager Fabric arbeidsbelastningen og inkorporerer den tildelte kapasiteten.

    Du kan overvåke for potensielle feil i konsollen.

    Hvis det ikke vises noen feil, opprettes tilkoblingen, registreringen kjøres, og arbeidsbelastningsmanifestet lastes systematisk opp.

    Skjermbilde av innlasting av tilkobling uten feil.

  11. Endre oppstartsprosjektet til Boilerplate-prosjektet i Visual Studio, og velg Kjør.

    Skjermbilde av brukergrensesnittet for oppstartsprosjekt i Visual Studio.

Arbeide med standardeksempelprosjektet

Kodegenerasjon

Vi bruker arbeidsbelastningen Boilerplate C# ASP.NET Core-eksemplet til å demonstrere hvordan du bygger en arbeidsbelastning ved hjelp av REST-API-er. Eksemplet starter med generering av serverstubben og kontraktsklasser basert på API Swagger-spesifikasjonen for arbeidsbelastning. Du kan generere koden ved hjelp av flere Swagger-kodegenereringsverktøy. Standardeksemplet bruker NSwag. Eksemplet inneholder GenerateServerStub.cmd kommandolinjeskript, som bryter NSwag-kodegeneratoren. Skriptet tar én parameter, som er en fullstendig bane til NSwag-installasjonskatalogen. Den ser også etter Swagger-definisjonsfilen (swagger.json) og konfigurasjonsfilen (nswag.json) i mappen.

Kjøring av dette skriptet produserer en C#-fil med navnet WorkloadAPI_Generated.cs. Innholdet i denne filen kan være logisk delt inn i tre deler som forklart i de neste inndelingene.

ASP.NET Core stub-kontrollere

ItemLifecycleController og JobsController klasser er tynne implementeringer av ASP.NET Core-kontrollere for to delsett av API-en for arbeidsbelastning: administrasjon av elementlivssyklus og jobber. Disse klassene kobles til ASP.NET Core HTTP-datasamlebåndet. De fungerer som inngangspunkter for API-metodene som er definert i Swagger-spesifikasjonen. Klassene videresender samtalene til den «virkelige» implementeringen som leveres av arbeidsbelastningen.

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);
}

Grensesnitt for implementering av arbeidsbelastning

IItemLifecycleController og IJobsController er grensesnitt for tidligere nevnte «reelle» implementeringer. De definerer de samme metodene som kontrollørene implementerer.

Definisjon av kontraktsklasser

C# kontraktklasser er klasser som API-ene bruker.

Implementering

Neste trinn etter generering av IItemLifecycleController kode implementerer og IJobsController grensesnittene. I standardeksempelet, ItemLifecycleControllerImpl og JobsControllerImpl implementer disse grensesnittene.

Denne koden er for eksempel implementeringen av 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åndtere en varenyttelast

Flere API-metoder godtar ulike typer «nyttelast» som en del av forespørselsteksten, eller de returnerer nyttelaster som en del av svaret. Har for eksempel CreateItemRequest egenskapen creationPayload .

"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
 }
 }
}

Typene for disse nyttelastegenskapene er definert i Swagger-spesifikasjonen. Det finnes en egen type for alle typer nyttelaster. Disse typene definerer ingen spesifikke egenskaper, og de tillater at alle egenskaper inkluderes.

Her er et eksempel på CreateItemPayload typen:

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

De genererte C#-kontraktklassene er definert som partial. De har en ordliste med definerte egenskaper.

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 bruke denne ordlisten til å lese og returnere egenskaper. En bedre fremgangsmåte er imidlertid å definere bestemte egenskaper ved hjelp av tilsvarende typer og navn. Du kan bruke deklarasjonen partial på de genererte klassene til effektivt å definere egenskaper.

Den CreateItemPayload.cs filen inneholder for eksempel en komplementær definisjon for CreateItemPayload klassen.

I dette eksemplet legger definisjonen til Item1Metadata egenskapen:

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; }
    }
}

Hvis arbeidsbelastningen støtter flere elementtyper, CreateItemPayload må klassen imidlertid kunne håndtere ulike typer nyttelast for oppretting med én per elementtype. Du har to alternativer. Den enklere måten, som brukes i standardeksempelet, er å definere flere valgfrie egenskaper, som hver representerer opprettingsnyttelasten for en annen elementtype. Hver forespørsel har da bare ett av disse settene med egenskaper, i henhold til elementtypen som opprettes. Alternativt kan du implementere polymorf serialisering, men dette alternativet vises ikke i eksemplet fordi alternativet ikke gir noen betydelige fordeler.

Hvis du for eksempel vil støtte to elementtyper, må klassedefinisjonen utvides 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; }
    } 
}

Merk

Nyttelasten som sendes til arbeidsbelastningen, genereres av klienten. Det kan være elementredigeringsprogrammet iFrame eller REST-API-en for stoffautomatisering. Klienten er ansvarlig for å sende riktig nyttelast og samsvare med elementtypen. Arbeidsbelastningen er ansvarlig for bekreftelse. Fabric behandler denne nyttelasten som et ugjennomsiktig objekt og overfører den bare fra klienten til arbeidsbelastningen. På samme måte, for en nyttelast som returneres av arbeidsbelastningen til klienten, er det arbeidsbelastningens og klientens ansvar å håndtere nyttelasten riktig.

Denne koden viser for eksempel hvordan standardeksempelelement1-implementeringen håndterer nyttelasten:

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();
}

Feilsøke og feilsøke

De neste inndelingene beskriver hvordan du feilsøker og feilsøker distribusjonen.

Kjente problemer og løsninger

Få informasjon om kjente problemer og måter å løse dem på.

Manglende klienthemmelighet

Feil:

Microsoft.Identity.Client.MsalServiceException: Et konfigurasjonsproblem hindrer godkjenning. Se feilmeldingen fra serveren for mer informasjon. Du kan endre konfigurasjonen i programregistreringsportalen. Se https://aka.ms/msal-net-invalid-client for mer informasjon.

Opprinnelig unntak: AADSTS7000215: Det ble angitt en ugyldig klienthemmelighet. Kontroller at hemmeligheten som sendes i forespørselen, er klienthemmelighetsverdien og ikke klienthemmelighets-ID-en for en hemmelighet som er lagt til appinnstillingen app_guid .

Løsning: Kontroller at du har riktig klienthemmelighet definert i appsettings.json.

Feil:

Microsoft.Identity.Client.MsalUiRequiredException: AADSTS65001: Brukeren eller administratoren samtykket ikke i å bruke programmet med ID <example ID>. Send en interaktiv godkjenningsforespørsel for denne brukeren og ressursen.

Løsning.

  1. Gå til bunnen av smerten i elementredigeringsprogrammet, og velg Naviger til godkjenningsside.

  2. Skriv inn .default under Omfang, og velg deretter Hent Tilgang-token.

  3. Godkjenn revisjonen i dialogboksen.

Oppretting av element mislykkes på grunn av kapasitetsvalg

Feil:

PriorityPlacement: Ingen kjernetjenester er tilgjengelige for prioritert plassering. Bare name, guidog workload-name er tilgjengelige.

Løsning.

Som bruker har du kanskje bare tilgang til prøveversjonskapasitet. Kontroller at du bruker en kapasitet du har tilgang til.

Filopprettingsfeil med 404 (NotFound)-feil

Feil:

Oppretting av en ny fil mislyktes for filePath: 'workspace-id'/'lakehouse-id'/Files/data.json. Svarstatuskoden angir ikke vellykket: 404 (NotFound).

Løsning.

Kontroller at du arbeider med ONELake DFS-nettadressen som passer til miljøet ditt. Hvis du for eksempel arbeider med et PPE-miljø, kan du endre EnvironmentConstants.OneLakeDFSBaseUrl i Constants.cs til den aktuelle nettadressen.

Feilsøking

Når du feilsøker ulike operasjoner, kan du angi bruddpunkter i koden for å analysere og feilsøke virkemåten. Følg disse trinnene for effektiv feilsøking:

  1. Åpne koden i utviklingsmiljøet.
  2. Gå til den relevante operasjonsbehandlingsfunksjonen (for eksempel OnCreateFabricItemAsync for CRUD-operasjoner eller et endepunkt i en kontroller for execute operasjoner).
  3. Plasser breakpoints på bestemte linjer der du vil undersøke koden.
  4. Kjør programmet i feilsøkingsmodus.
  5. Utløs operasjonen fra frontend som du vil feilsøke.

Feilsøkingsprogrammet stanser kjøringen midlertidig på de angitte punktene, slik at du kan undersøke variabler, gå gjennom koden og identifisere problemer.

Skjermbilde av eksempelprogram med breakpoints for feilsøking.

Arbeidsområde

Hvis du kobler en serverdel til eksempelarbeidsbelastningsprosjektet, må elementet tilhøre et arbeidsområde som er knyttet til en kapasitet. Arbeidsområdet Mitt arbeidsområde er som standard ikke knyttet til en kapasitet. Ellers kan du få feilen som vises i følgende skjermbilde:

Skjermbilde av brukergrensesnittet for navngivning av et eksempel på arbeidsbelastningselement.

  1. Bytt til et navngitt arbeidsområde. Forlat standard arbeidsområdenavn Mitt arbeidsområde.

    Skjermbilde av brukergrensesnittet for å opprette eksempelarbeidsbelastning.

  2. Last inn eksempelarbeidsbelastningen fra riktig arbeidsområde, og fortsett med testene:

    Skjermbilde av brukergrensesnittet for å opprette eksempel på arbeidsbelastningselement.

Bidra

Vi ønsker velkommen bidrag til dette prosjektet. Hvis du finner problemer eller ønsker å legge til nye funksjoner, følger du disse trinnene:

  1. Forgren repositoriet.
  2. Opprett en ny gren for funksjonen eller feilrettingen.
  3. Gjør endringene, og utfør dem.
  4. Send endringene til det forgrenede repositoriet.
  5. Opprett en pull-forespørsel som har en klar beskrivelse av endringene.