Introdução a cargas de trabalho

Este capítulo apresenta os principais componentes do nosso sistema e fornece uma visão geral da arquitetura. Esses componentes trabalham juntos para criar uma plataforma robusta e flexível para suas necessidades de desenvolvimento. Vamos nos aprofundar nesses componentes e em suas funções dentro da nossa arquitetura.

Arquitetura da carga de trabalho do Fabric

Alguns dos principais aspectos da arquitetura de carga de trabalho do Fabric são os seguintes:

• Lida com o processamento, armazenamento e gerenciamento de dados. Valida os tokens de ID do Microsoft Entra antes de processá-los e interage com serviços externos do Azure, como o Lakehouse.

• O front-end (FE) de carga de trabalho oferece uma interface de usuário para criação, criação, gerenciamento e execução de trabalhos.

• As interações do usuário por meio do FE iniciam solicitações ao BE, direta ou indiretamente, por meio do back-end do Fabric (BE do Fabric).

Para obter diagramas mais detalhados que descrevem a comunicação e a autenticação dos vários componentes, consulte a Visão geral de autenticação e autorização de back-end e os diagramas de visão geral de autenticação.

Front-end (FE)

O front-end serve como base da experiência do usuário (UX) e comportamento, operando dentro de um iframe no portal dp Fabric. Ele fornece ao parceiro do Fabric uma experiência de interface de usuário específica, incluindo um editor de itens. O SDK do cliente de extensão equipa as interfaces, as APIs e as funções de inicialização necessárias para transformar um aplicativo Web comum em um micro-aplicativo Web front-end que opera perfeitamente no portal do Fabric.

Back-end (BE)

O back-end é a potência para o processamento de dados e o armazenamento de metadados. Ele emprega operações CRUD para criar e gerenciar itens de carga de trabalho juntamente com metadados e executa trabalhos para preencher os dados no armazenamento. A ponte de comunicação entre o front-end e o back-end é estabelecida por meio de APIs públicas.

As cargas de trabalho podem ser executadas em dois ambientes: local e nuvem. No local (devmode), a carga de trabalho é executada na máquina do desenvolvedor, com chamadas de API gerenciadas pelo utilitário DevGateway. Esse utilitário também lida com o registro de cargas de trabalho no Fabric. No modo de nuvem, a carga de trabalho é executada nos serviços do parceiro, com chamadas de API feitas diretamente para um ponto de extremidade HTTPS.

Ambiente de desenvolvimento

• Pacote de carga de trabalho do modo de desenvolvimento: ao criar a solução de back-end no Visual Studio, use a configuração de compilação de depuração para criar um pacote BE NuGet, que pode ser carregado no locatário do Fabric usando o aplicativo DevGateway.

• Pacote de carga de trabalho em modo Nuvem: Ao criar a solução BE no Visual Studio, use a configuração de build de Versão para criar um pacote de carga de trabalho independente (BE e FE). Esse pacote pode ser carregado diretamente no locatário.

• Para obter mais detalhes sobre as configurações de build de Depuração e Versão, confira alterar a configuração de build

Estrutura do pacote NuGet de carga de trabalho

A carga de trabalho é empacotada como um pacote NuGet, combinando componentes de back-end e de front-end. A estrutura segue convenções de nomenclatura específicas e é imposta pelo Fabric para garantir consistência entre os cenários de upload. O pacote NuGet desenhado para representar cargas de trabalho é estruturado para incluir componentes de back-end e de front-end.

Estrutura de back-end

O segmento de back-end compreende os arquivos .xml que definem a carga de trabalho e os itens associados, que são essenciais para o registro com o Fabric.

Principais componentes

• WorkloadManifest.xml - O arquivo de configuração de carga de trabalho, precisa ter esse nome exato para verificação do Fabric.
• Item1.xml, Item2.xml, ... - Manifestos de itens individuais com nomenclatura flexível, seguindo o formato XML.

Estrutura de front-end

A seção de front-end contém arquivos .json detalhando o produto e os itens para o front-end, juntamente com um diretório 'assets' para ícones.

Principais componentes

• Product.json - O manifesto principal para o front-end do seu produto, que deve ter o nome exato para verificação do Fabric.
• Item1.json, Item2.json, ... - Manifestos para itens individuais com nomenclatura flexível, seguindo o formato JSON. Cada json corresponde a um manifesto de back-end (por exemplo, Item1.json para Item1.xml).
• A pasta assets - Armazena todos os ícones icon1.jpg, icon2.png, ... usados pelo front-end.

Conformidade de estrutura obrigatória

A estrutura, incluindo nomes de subpastas específicos ('BE', 'FE', 'assets'), é obrigatória e é imposta pelo Fabric a todos os cenários de upload, incluindo pacotes de teste e desenvolvimento. A estrutura é especificada nos arquivos .nuspec localizados no repositório no diretório Backend/src/Packages/manifest.

Limites

Os seguintes limites se aplicam a todos os tipos de pacotes NuGet, tanto no modo de desenvolvimento quanto no modo de nuvem:

• Só é permitido ter subpastas BE e FE. Quaisquer outras subpastas ou arquivos localizados fora dessas pastas resultam em um erro de upload.
• A pasta BE só aceita arquivos .xml. Qualquer outro tipo de arquivo resulta em um erro de upload.
• É permitido ter até 10 arquivos de item, o que significa que a pasta BE pode conter um WorkloadManifest.xml e até 10 arquivos Item.xml. Ter mais de 10 arquivos de item na pasta resulta em um erro de upload.
• A subpasta Assets deve residir na pasta FE. Ela pode conter até 15 arquivos e cada arquivo não pode ser maior que 1,5 MB.
• Somente os seguintes tipos de arquivo são permitidos na subpasta Assets: .jpeg, .jpg, .png.
• A pasta FE pode conter no máximo 10 arquivos de itens mais um arquivo product.json.
• Cada ativo dentro da pasta Assets deve ser referenciado nos arquivos de itens. Qualquer ativo referenciado de um arquivo de itens ausente na pasta Assets resultará em um erro de upload.
• Os nomes de arquivo para itens devem ser exclusivos. Nomes de arquivos duplicados resultam em um erro de upload.
• Os nomes de arquivo devem conter apenas caracteres alfanuméricos (inglês) ou hifens e não podem ter mais de 32 caracteres. Usar outros caracteres ou exceder esse comprimento resulta em um erro de upload.
• O tamanho total do pacote não deve exceder 20 MB.
• Consulte o manifesto da carga de trabalho para conhecer as limitações específicas do manifesto.

Modo de desenvolvimento local (devmode)

O back-end (BE) de carga de trabalho opera na máquina do desenvolvedor. As chamadas de API de carga de trabalho são transmitidas por meio da Retransmissão do Azure, com o lado da carga de trabalho do canal de Retransmissão do Azure gerenciado por um utilitário de linha de comando especializado, o DevGateway. As chamadas da API de controle de carga de trabalho são enviadas diretamente da carga de trabalho para o Fabric, ignorando o canal do Azure Relay. A utilidade DevGateway também supervisiona o registro da instância de desenvolvimento local da carga de trabalho com Fabric, dentro do contexto de um espaço de trabalho específico. Após o término do utilitário DevGateway, o registro da instância de carga de trabalho é automaticamente suspenso. Para obter mais informações, consulte Guia de implementação do back-end.

Esquema BE de DevMode

Modo de desenvolvimento na nuvem (modo de nuvem)

O back-end (BE) de carga de trabalho opera dentro dos serviços do parceiro. As chamadas de API de carga de trabalho são feitas diretamente ao ponto de extremidade HTTPS, conforme especificado no manifesto da carga de trabalho. Nesse cenário, o utilitário DevGateway não é necessário. O registro da carga de trabalho no Fabric é realizado carregando o pacote NuGet de carga de trabalho no Fabric e, posteriormente, ativando a carga de trabalho para o locatário. Para obter mais informações, confira Gerenciar uma carga de trabalho no Fabric.

Esquema BE do modo de nuvem

Conteúdo relacionado

• Ciclo de vida do item
• Configure seu ambiente
• Gerenciar uma carga de trabalho no Fabric