Partilhar via

Implementar o back-end do Microsoft Fabric

  • Artigo

Este repositório de exemplo de desenvolvimento de carga de trabalho do Microsoft Fabric é um ponto de partida para a criação de aplicativos que exigem integração com vários serviços e para integração com a arquitetura lakehouse. Este artigo ajuda você a configurar o ambiente e configurar os componentes necessários para começar. O artigo descreve os principais componentes e suas funções na arquitetura.

Front-end

O frontend é onde você gerencia a experiência do usuário (UX) e o comportamento. Ele se comunica com o portal de frontend do Fabric por meio de um iFrame para facilitar a interação perfeita.

Para obter mais informações, consulte Front-end do Microsoft Fabric Workload Development Kit.

Back-end

O back-end armazena dados e metadados. Ele usa operações de criação, leitura, atualização e exclusão (CRUD) para criar itens de carga de trabalho e metadados e executa trabalhos para preencher dados no armazenamento. A comunicação entre o frontend e o backend é estabelecida por meio de APIs públicas.

Azure Relay e DevGateway

O Azure Relay permite a comunicação entre o ambiente de desenvolvimento local e o back-end do Fabric no modo de desenvolvedor. No modo de desenvolvedor, a carga de trabalho opera na máquina do desenvolvedor.

O utilitário DevGateway tem duas funções:

  • Ele lida com o lado da carga de trabalho do canal de Retransmissão do Azure e gerencia o registro da instância local da carga de trabalho com o Fabric no contexto de uma capacidade específica. O DevGateway torna a carga de trabalho acessível em todos os espaços de trabalho atribuídos a essa capacidade. O utilitário lida com o cancelamento de registro quando o canal para.
  • Ele funciona com o Azure Relay para canalizar chamadas de API de carga de trabalho do Fabric para a carga de trabalho.

As chamadas da API de controle de carga de trabalho são feitas diretamente da carga de trabalho para a malha. O canal de Retransmissão do Azure não é necessário para as chamadas.

Integração Lakehouse

A arquitetura do kit de desenvolvimento de carga de trabalho integra-se perfeitamente com uma arquitetura lakehouse para operações como salvar, ler e buscar dados. A interação é facilitada por meio do Azure Relay e do SDK do Fabric para ajudar a garantir uma comunicação segura e autenticada. Para obter mais informações, consulte Trabalhando com dados do cliente.

Autenticação e segurança

O Microsoft Entra ID é usado para autenticação segura, garantindo que todas as interações dentro da arquitetura sejam autorizadas e seguras.

A visão geral do kit de desenvolvimento fornece um vislumbre de nossa arquitetura. Para obter mais informações sobre como os projetos são configurados, para diretrizes de autenticação e para começar, consulte os seguintes artigos:

Diagrama mostrando como o SDK do Fabric se integra ao Fabric.

O frontend estabelece comunicação com o portal frontend do Fabric através de um iFrame. O portal, por sua vez, interage com o back-end do Fabric fazendo chamadas para suas APIs públicas expostas.

Para interações entre a caixa de desenvolvimento de back-end e o back-end de malha, o Azure Relay serve como um canal. Além disso, a caixa de desenvolvimento de back-end integra-se perfeitamente com Lakehouse. A comunicação é facilitada usando o Azure Relay e o SDK (Software Development Kit) de malha instalado na caixa de desenvolvimento de back-end.

A autenticação para toda a comunicação dentro destes componentes é assegurada através do Microsoft Entra. O Microsoft Entra fornece um ambiente seguro e autenticado para as interações entre front-end, back-end, Azure Relay, Fabric SDK e Lakehouse.

Pré-requisitos

Verifique se o Gerenciador de Pacotes NuGet está integrado à sua instalação do Visual Studio. Esta ferramenta é necessária para uma gestão simplificada de bibliotecas externas e pacotes essenciais para o nosso projeto.

Gerenciamento de pacotes NuGet

  • <NuspecFile>Packages\manifest\ManifestPackageDebug.nuspec</NuspecFile> e <NuspecFile>Packages\manifest\ManifestPackageRelease.nuspec</NuspecFile>: Essas propriedades especificam o caminho para os arquivos NuSpec usados para criar o pacote NuGet para os modos de depuração e versão. O arquivo NuSpec contém metadados sobre o pacote, como sua ID, versão, dependências e outras informações relevantes.

  • <GeneratePackageOnBuild>true</GeneratePackageOnBuild>: Quando definida como true, essa propriedade instrui o processo de compilação a gerar automaticamente um pacote NuGet durante cada compilação. Esta propriedade é útil para garantir que o pacote esteja sempre atualizado com as últimas alterações no projeto.

  • <IsPackable>true</IsPackable>: Quando definida como true, essa propriedade indica que o projeto pode ser empacotado em um pacote NuGet. Ser empacotável é uma propriedade essencial para projetos que se destinam a produzir pacotes NuGet durante o processo de compilação.

O pacote NuGet gerado para o modo de depuração está localizado no diretório src\bin\Debug após o processo de compilação.

Quando você trabalha no modo de nuvem, você pode alterar a configuração de compilação do Visual Studio para Release e compilar seu pacote. O pacote gerado está localizado no src\bin\Release diretório. Para obter mais informações, consulte Guia de trabalho no modo de nuvem.

Dependências

  • O exemplo Boilerplate de back-end depende dos seguintes pacotes do SDK do Azure:

    • Azure.Core
    • Azure.Identity
    • Azure.Storage.Files.DataLake
    • O pacote Microsoft Identity

Para configurar o Gerenciador de Pacotes NuGet, especifique o caminho na seção Códigos-fonte do pacote antes de iniciar o processo de compilação.

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

Começar agora

Para configurar o projeto de exemplo de carga de trabalho em sua máquina local:

  1. Clone o repositório: Executar git clone https://github.com/microsoft/Microsoft-Fabric-workload-development-sample.git.

  2. No Visual Studio 2022, abra a solução.

  3. Configure um registro de aplicativo seguindo as instruções no tutorial de autenticação. Certifique-se de que seus projetos de frontend e backend tenham a configuração necessária descrita no artigo. O Microsoft Entra é usado para autenticação segura para ajudar a garantir que todas as interações dentro da arquitetura sejam autorizadas e seguras.

  4. Atualize a URL base do Microsoft OneLake DFS. Dependendo do seu ambiente de malha, você poderá atualizar o valor para OneLakeDFSBaseURL na pasta src\Constants . O padrão é onelake.dfs.fabric.microsoft.com, mas você pode atualizar a URL para refletir seu ambiente. Para obter mais informações sobre caminhos DFS, consulte a documentação do OneLake.

  5. Configure a configuração da carga de trabalho.

    1. Copie workload-dev-mode.json de src/Config para C:.
    2. No arquivo workload-dev-mode.json, atualize os seguintes campos para corresponder à sua configuração:
      • WorkspaceGuid: seu ID de espaço de trabalho. Você pode encontrar esse valor na URL do navegador ao selecionar um espaço de trabalho no Fabric. Por exemplo, https://app.powerbi.com/groups/<WorkspaceID>/.
      • ManifestPackageFilePath: O local do pacote de manifesto. Quando você cria a solução, ela salva o pacote de manifesto em src\bin\Debug. Mais informações sobre o pacote de manifesto são fornecidas mais adiante no artigo.
      • WorkloadEndpointURL: A URL do ponto de extremidade da carga de trabalho.
    3. No arquivo Packages/manifest/WorkloadManifest.xml, atualize os seguintes campos para corresponder à sua configuração:
      • <AppId>: A ID do cliente (ID do aplicativo) da carga de trabalho do aplicativo Microsoft Entra.
      • <RedirectUri>: Os URIs de redirecionamento. Pode encontrar este valor no registo da aplicação que criou, em Autenticação.
      • <ResourceId>: O público dos tokens de entrada do Microsoft Entra. Você pode encontrar essas informações no registro do aplicativo que criou, em Expor uma API.
    4. No arquivo src/appsettings.json, atualize os seguintes campos para corresponder à sua configuração:
      • PublisherTenantId: A ID do locatário do editor de carga de trabalho.
      • ClientId: A ID do cliente (ID do aplicativo) da carga de trabalho do aplicativo Microsoft Entra.
      • ClientSecret: O segredo para a carga de trabalho do aplicativo Microsoft Entra.
      • Público: o público dos tokens de entrada do Microsoft Entra. Você pode encontrar essas informações no registro do aplicativo que criou, em Expor uma API. Essa configuração também é chamada de URI de ID do aplicativo.

  6. Gere um pacote de manifesto.

    Para gerar um arquivo de pacote de manifesto, compile Fabric_Extension_BE_Boilerplate. A compilação é um processo de três etapas que gera o arquivo de pacote de manifesto. Ele executa estas etapas:

    1. Aciona ManifestValidator.ps1 em WorkloadManifest.xml em Packages\manifest/ e aciona ItemManifestValidator.ps1 em todos os itens XMLs (por exemplo, Item1.xml) em Packages\manifest/. Se a validação falhar, um arquivo de erro será gerado. Você pode exibir os scripts de validação em ValidationScripts/.
    2. Se existir um arquivo de erro, a compilação falhará com o erro Erros de validação com valores manifestos ou padrão. Para ver o arquivo de erro no Visual Studio, clique duas vezes no erro nos resultados da validação.
    3. Após a validação bem-sucedida, empacote os arquivos WorkloadManifest.xml e Item1.xml em ManifestPackage.1.0.0.nupkg. O pacote resultante está em src\bin\Debug.

    Copie o arquivo ManifestPackage.1.0.0.nupkg para o caminho definido no arquivo de configuração workload-dev-mode.json.

  7. Program.cs é o ponto de entrada e o script de inicialização para seu aplicativo. Neste arquivo, você pode configurar vários serviços, inicializar o aplicativo e iniciar o host da web.

  8. Crie para garantir que seu projeto possa acessar as dependências necessárias para compilação e execução.

  9. Baixe o DevGateway do Centro de Download da Microsoft

  10. Execute o aplicativo Microsoft.Fabric.Workload.DevGateway.exe e entre com um usuário que tenha privilégios de administrador de espaço de trabalho para o espaço de trabalho especificado no WorkspaceGuid campo de workload-dev-mode.json.

    Captura de ecrã da página de início de sessão da Microsoft.

    Após a autenticação, as cargas de trabalho externas estabelecem comunicação com o back-end do Fabric por meio do Azure Relay. Esse processo envolve o registro de retransmissão e o gerenciamento de comunicação que é facilitado por um nó proxy designado. O pacote que contém o manifesto da carga de trabalho é carregado e publicado.

    Nesta etapa, o Fabric deteta a carga de trabalho e incorpora sua capacidade alocada.

    Você pode monitorar possíveis erros no console.

    Se nenhum erro for mostrado, a conexão será estabelecida, o registro será executado com êxito e o manifesto da carga de trabalho será carregado sistematicamente.

    Captura de ecrã do carregamento da ligação sem erros.

  11. No Visual Studio, altere seu projeto de inicialização para o projeto Boilerplate e selecione Executar.

    Captura de tela da interface do usuário para projeto de inicialização no Visual Studio.

Trabalhar com o projeto de amostra Boilerplate

Geração de código

Usamos o exemplo de carga de trabalho Boilerplate C# ASP.NET Core para demonstrar como criar uma carga de trabalho usando APIs REST. O exemplo começa com a geração de stubs de servidor e classes de contrato com base na especificação Workload API Swagger. Você pode gerar o código usando qualquer uma das várias ferramentas de geração de código Swagger. A amostra Boilerplate usa NSwag. O exemplo contém o script de linha de comando GenerateServerStub.cmd , que encapsula o gerador de código NSwag. O script usa um único parâmetro, que é um caminho completo para o diretório de instalação do NSwag. Ele também verifica o arquivo de definição Swagger (swagger.json) e o arquivo de configuração (nswag.json) na pasta.

A execução desse script produz um arquivo C# chamado WorkloadAPI_Generated.cs. O conteúdo deste arquivo pode ser logicamente dividido em três partes, conforme explicado nas próximas seções.

ASP.NET Controladores de stub Core

ItemLifecycleController e JobsController classes são implementações finas de controladores ASP.NET Core para dois subconjuntos da API de carga de trabalho: gerenciamento do ciclo de vida do item e trabalhos. Essas classes se conectam ao pipeline HTTP ASP.NET Core. Eles servem como os pontos de entrada para os métodos de API que são definidos na especificação Swagger. As classes encaminham as chamadas para a implementação "real" fornecida pela carga de trabalho.

Aqui está um exemplo do CreateItem método:

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

Interfaces para implementação de carga de trabalho

IItemLifecycleController e IJobsController são interfaces para as implementações "reais" mencionadas anteriormente. Eles definem os mesmos métodos, que os controladores implementam.

Definição de classes contratuais

As classes de contrato C# são classes que as APIs usam.

Implementação

O próximo passo após a geração de código é implementar as IItemLifecycleController interfaces e IJobsController . No exemplo ItemLifecycleControllerImpl Boilerplate e implemente JobsControllerImpl essas interfaces.

Por exemplo, este código é a implementação da API CreateItem:

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

Manipular uma carga útil de item

Vários métodos de API aceitam vários tipos de "carga útil" como parte do corpo da solicitação ou retornam cargas como parte da resposta. Por exemplo, CreateItemRequest tem a creationPayload propriedade.

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

Os tipos para essas propriedades de carga útil são definidos na especificação Swagger. Existe um tipo dedicado para cada tipo de carga útil. Esses tipos não definem nenhuma propriedade específica e permitem que qualquer propriedade seja incluída.

Aqui está um exemplo do CreateItemPayload tipo:

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

As classes de contrato C# geradas são definidas como partial. Eles têm um dicionário com propriedades definidas.

Eis um exemplo:

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

O código pode usar este dicionário para ler e retornar propriedades. No entanto, uma abordagem melhor é definir propriedades específicas usando tipos e nomes correspondentes. Você pode usar a partial declaração nas classes geradas para definir propriedades de forma eficiente.

Por exemplo, o arquivo CreateItemPayload.cs contém uma definição complementar para a CreateItemPayload classe.

Neste exemplo, a definição adiciona a Item1Metadata propriedade:

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

No entanto, se a carga de trabalho suportar vários tipos de item, a CreateItemPayload classe deve ser capaz de lidar com diferentes tipos de carga útil de criação em um por tipo de item. Você tem duas opções. A maneira mais simples, usada no exemplo Boilerplate, é definir várias propriedades opcionais, cada uma representando a carga útil de criação para um tipo de item diferente. Cada solicitação tem apenas um desses conjuntos de propriedades, de acordo com o tipo de item que está sendo criado. Como alternativa, você pode implementar a serialização polimórfica, mas essa opção não é demonstrada no exemplo porque a opção não fornece benefícios significativos.

Por exemplo, para dar suporte a dois tipos de item, a definição de classe deve ser estendida como no exemplo a seguir:

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

Nota

A carga útil enviada para a carga de trabalho é gerada pelo cliente. Pode ser o editor de itens iFrame ou a API REST do Fabric Automation. O cliente é responsável por enviar a carga correta e corresponder ao tipo de item. A carga de trabalho é responsável pela verificação. O Fabric trata essa carga como um objeto opaco e apenas a transfere do cliente para a carga de trabalho. Da mesma forma, para uma carga que é retornada pela carga de trabalho ao cliente, é responsabilidade da carga de trabalho e do cliente lidar com a carga útil corretamente.

Por exemplo, este código mostra como a implementação do item de exemplo Boilerplate lida com a carga útil:

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

Solução de problemas e depuração

As próximas seções descrevem como solucionar problemas e depurar sua implantação.

Problemas conhecidos e resoluções

Obtenha informações sobre problemas conhecidos e formas de os resolver.

Segredo do cliente ausente

Erro:

Microsoft.Identity.Client.MsalServiceException: um problema de configuração está impedindo a autenticação. Verifique a mensagem de erro do servidor para obter detalhes. Você pode modificar a configuração no portal de registro do aplicativo. Consulte https://aka.ms/msal-net-invalid-client para obter detalhes.

Exceção original: AADSTS7000215: Um segredo de cliente inválido foi fornecido. Verifique se o segredo enviado na solicitação é o valor do segredo do cliente e não a ID do segredo do cliente para um segredo adicionado à configuração do aplicativo app_guid .

Resolução: certifique-se de ter o segredo do cliente correto definido em appsettings.json.

Erro:

Microsoft.Identity.Client.MsalUiRequiredException: AADSTS65001: O usuário ou administrador não consentiu em usar o aplicativo com ID <example ID>. Envie uma solicitação de autorização interativa para este usuário e recurso.

Resolução:

  1. No editor de itens, vá para a parte inferior da pasta e selecione Navegar até a página de autenticação.

  2. Em Escopos, digite .default e selecione Obter token de acesso.

  3. Na caixa de diálogo, aprove a revisão.

A criação de itens falha devido à seleção de capacidade

Erro:

PriorityPlacement: Nenhum serviço principal está disponível para colocação prioritária. Apenas name, guid, e workload-name estão disponíveis.

Resolução:

Como usuário, você pode ter acesso apenas à capacidade de avaliação. Certifique-se de que utiliza uma capacidade a que tem acesso.

Falha na criação de arquivo com erro 404 (NotFound)

Erro:

Falha ao criar um novo arquivo para filePath: 'workspace-id'/'lakehouse-id'/Files/data.json. O código de status da resposta não indica sucesso: 404 (NotFound).

Resolução:

Certifique-se de que está a trabalhar com o URL DFS do OneLake que se adapta ao seu ambiente. Por exemplo, se você trabalha com um ambiente de EPI, altere EnvironmentConstants.OneLakeDFSBaseUrl o Constants.cs para a URL apropriada.

Depurar

Ao solucionar problemas de várias operações, você pode definir pontos de interrupção no código para analisar e depurar o comportamento. Siga estas etapas para uma depuração eficaz:

  1. Abra o código em seu ambiente de desenvolvimento.
  2. Vá para a função de manipulador de operação relevante (por exemplo, OnCreateFabricItemAsync para operações CRUD ou um ponto de extremidade em um controlador para execute operações).
  3. Coloque pontos de interrupção em linhas específicas onde você deseja inspecionar o código.
  4. Execute o aplicativo no modo de depuração.
  5. Acione a operação a partir do frontend que você deseja depurar.

O depurador pausa a execução nos pontos de interrupção especificados para que você possa examinar variáveis, percorrer o código e identificar problemas.

Captura de tela do programa de exemplo com pontos de interrupção para depuração.

Área de trabalho

Se você estiver conectando um back-end ao projeto de carga de trabalho de exemplo, seu item deverá pertencer a um espaço de trabalho associado a uma capacidade. Por padrão, o espaço de trabalho Meu Espaço de Trabalho não está associado a uma capacidade. Caso contrário, você pode obter o erro mostrado na captura de tela a seguir:

Captura de tela da interface do usuário para nomear um item de carga de trabalho de exemplo.

  1. Alterne para um espaço de trabalho nomeado. Deixe o nome padrão do espaço de trabalho Meu espaço de trabalho.

    Captura de tela da interface do usuário para criar uma carga de trabalho de exemplo.

  2. No espaço de trabalho correto, carregue a carga de trabalho de amostra e prossiga com os testes:

    Captura de tela da interface do usuário para criar um item de carga de trabalho de exemplo.

Contribuir

Congratulamo-nos com as contribuições para este projeto. Se você encontrar algum problema ou quiser adicionar novos recursos, siga estas etapas:

  1. Fork o repositório.
  2. Crie uma nova ramificação para seu recurso ou correção de bug.
  3. Faça as alterações e confirme-as.
  4. Envie suas alterações para o repositório bifurcado.
  5. Crie uma solicitação pull que tenha uma descrição clara de suas alterações.

Conteúdos relacionados