APIs de vários workspaces do Microsoft Fabric

O Microsoft Fabric dá suporte a cenários de vários workspaces, como hub de dados, favoritos, linhagem, pesquisa, catálogo do OneLake e outros recursos de governança e descoberta por meio de APIs de vários workspaces. Essas APIs permitem que os usuários acessem metadados simplificados de vários espaços de trabalho que eles podem acessar fora das configurações de rede dos espaços de trabalho. As APIs dão suporte à pesquisa unificada, à organização e à navegação em toda a plataforma sem expor o conteúdo de dados subjacente.

As APIs de múltiplos workspaces nem sempre são expostas como endpoints REST independentes. Em muitos casos, essas APIs são invocadas indiretamente. Por exemplo, eles podem ser invocados como parte de uma chamada REST mais ampla, um processo em segundo plano ou uma operação de portal (como carregar uma página na interface do usuário do Fabric). Independentemente de como eles são acionados, eles são cuidadosamente delimitados para garantir que retornem apenas metadados aos quais um usuário está autorizado a ter acesso.

Categorias de APIs de vários workspaces

As APIs de vários workspaces se enquadram nas duas categorias a seguir. Cada um serve a cenários específicos e impõe o controle de acesso de maneiras distintas.

• APIs de vários workspaces sem filtro somente leitura

  • Projetado para retornar metadados em todos os workspaces acessíveis para o usuário.
  • Não imponha restrições de acesso baseadas em rede.
  • Somente leitura por concepção e sem suporte em conexões de endpoint privado do workspace.
  • Normalmente usado em cenários de agregação global, como indexação ou catalogação em toda a plataforma.

• APIs de vários workspaces filtradas

  • Imponha o controle de acesso com base na origem da rede da solicitação de API.
  • Suporte ao uso seguro do link privado do workspace, link privado de locatário e configurações de rede pública.
  • Retornar metadados somente para os workspaces que podem ser acessados com base no contexto de rede da solicitação.

Essas APIs dão suporte à agregação de metadados em escala e são categorizadas com base em como lidam com o controle de acesso e a segurança de rede. A tabela a seguir resume como diferentes tipos de APIs em um ambiente de vários workspaces retornam metadados com base no tipo de conexão de rede.

Cenário de exemplo

Suponha que um usuário tenha acesso a cinco workspaces do Fabric:

• Os Workspaces 1 e 2 são protegidos com endpoints privados do workspace WSPE 1 e WSPE 2, respectivamente.
• Os workspaces 3, 4 e 5 são acessíveis sobre uma rede pública ou um link privado do locatário.

Neste cenário de exemplo, o usuário deseja chamar a API Get Workspace em várias configurações de rede. A API Get Workspace é uma API de agregação somente leitura e não filtrada que permite que os usuários recuperem metadados sobre todos os workspaces que podem acessar. O comportamento dessa API pode mudar (ou permanecer consistente) entre as configurações de rede no Microsoft Fabric.

Quando o usuário chama a API Get Workspace (não filtrada):

• De uma rede pública: a API retorna todos os cinco workspaces. Nenhuma restrição de rede é imposta e o acesso é baseado apenas em permissões de usuário.
• De um link privado de inquilino: o comportamento é o mesmo de uma rede pública. Todos os cinco espaços de trabalho são retornados. Um link privado de locatário não impõe restrições no nível do workspace em APIs não filtradas.
• De um ponto de extremidade privado do workspace: a chamada à API falha. Não há suporte para APIs não filtradas em um link privado de workspace, pois essas redes isoladas são projetadas para evitar a exposição de dados entre workspaces.

Este cenário ilustra como as APIs de agregação não filtradas se comportam consistentemente em redes abertas, mas são bloqueadas intencionalmente em ambientes privados com escopo de workspace para segurança.

Dados no escopo e uso

• Permissões, propriedade e informações do criador: metadados que incluem campos que identificam quem possui ou gerencia o item, quem o criou ou modificou pela última vez e qual nível de acesso diferentes principais têm. Os exemplos incluem Artifact.CurrentPrincipalPermissions, Artifact.OwnerOrContact, Workspace.PrincipalPermissionse Workspace.OwnerOrContact.
• Detalhes de acesso e modificação: metadados que capturam quando e por quem um item ou workspace foi criado, acessado pela última vez ou modificado. Os exemplos incluem Artifact.CreateAccessModifyTime, Artifact.CreateAccessModifyUser, Workspace.CreateAccessModifyTimee campos relacionados abaixo JobSchedule e InformationProtection.
• Identificadores, tipos e atributos descritivos: metadados que abrangem identificadores exclusivos, nomes de exibição, tipos de artefato, informações de conexão e URLs para localizar ou classificar itens. Os campos podem incluir Artifact.Id, Artifact.TypeOrSubtype, Artifact.NameOrDisplayName, , Artifact.UrlOrConnectionStringe Workspace.TypeOrSubtypeWorkspace.NameOrDisplayName.
• Classificação, rotulagem e marcas de dados: metadados que incluem campos usados para fins de governança e conformidade, como rótulos de proteção de informações, estados de classificação, marcas de conteúdo e restrições de segurança. Os exemplos incluem Artifact.ContentTag, Artifact.InformationProtection.StateOrStatus, Artifact.InformationProtection.Restrictionse Tenant.MipLabel.
• Atributos organizacionais e de plataforma: metadados que refletem onde o item reside dentro da estrutura de plataforma ou locatário mais ampla, incluindo metadados de domínio, capacidade, região e plataforma. Os campos podem incluir Tenant.Domain, Tenant.Capacitye Workspace.StorageInfoWorkspace.SecuritySettings.
• Relações e hierarquias: metadados que indicam como um item ou workspace se relaciona com outros objetos (relações pai/filho, subartifacts, linhagem de trabalho e entidades agrupadas). Ele pode incluir campos como Artifact.RelationToArtifactParentChild, , Artifact.SubArtifact, Workspace.RelationToWorkspaceParentChilde Workspace.SubfolderTenant.Group.

Esse acesso de metadados é somente leitura e é restrito no escopo. Ele não envolve o acesso ao conteúdo de dados subjacente ou às cargas geradas pelo usuário dentro dos artefatos. Ele destina-se a dar suporte a recursos centralizados de descoberta e governança em experiências do Fabric.