Compreender a associação de dependências na implementação entre espaços de trabalho

Quando implementas itens Fabric em vários espaços de trabalho (por exemplo, de Desenvolvimento a Teste e Produção), as dependências entre itens podem quebrar-se. Alguns itens armazenam referências às suas dependências como IDs de objeto (GUIDs específicos do espaço de trabalho), enquanto outros usam IDs lógicos (identificadores portáteis entre espaços de trabalho armazenados no .platform ficheiro).

Itens que usam IDs lógicos nas suas definições associam-se corretamente ao item correspondente no workspace de destino. Os itens que usam IDs de objeto permanecem apontados para o espaço de trabalho de origem, o que quebra a implementação.

Este artigo mapeia quais os tipos de itens do Fabric que suportam a ligação de dependências através de IDs lógicos quando usas integração com o Git, e quais não. Para saber mais sobre IDs lógicos e como os itens são representados no controlo de versão, consulte ID Lógico no Fabric.

Conceitos-chave

  • ID lógico: Um identificador multi-espaço de trabalho gerado automaticamente no .platform ficheiro. Itens com o mesmo ID lógico são tratados como o mesmo item em vários espaços de trabalho.
  • ID de Objeto: Um GUID específico do espaço de trabalho que identifica uma instância específica. Os IDs de objetos não sobrevivem à implementação entre espaços de trabalho sem intervenção manual ou parametrização.
  • Ligação de dependências (Git): Quando sincroniza um ramo Git para um novo espaço de trabalho, o Fabric resolve referências de dependências usando IDs lógicos, apontando automaticamente para o item correto no espaço de trabalho alvo.
  • Por nome ou por URI: Alguns itens referenciam dependências por nome de exibição ou URI em vez de por ID. Estas referências podem ou não ser resolvidas corretamente, dependendo das convenções de nomenclatura nos vários espaços de trabalho.

Como funciona a vinculação de dependências

Dentro de um espaço de trabalho, os itens referenciam as suas dependências usando IDs de objetos. Quando o Fabric exporta um item para o Git, substitui alguns desses IDs de objeto por IDs lógicos do .platform ficheiro. Quando sincronizas o ramo Git para um workspace diferente, o Fabric resolve esses IDs lógicos de volta para os IDs de objetos corretos no workspace de destino. É isto que faz a ligação de dependências funcionar.

No entanto, nem todas as referências de dependência são substituídas por IDs lógicos durante a exportação. Os itens que mantêm os IDs dos objetos na sua representação Git continuam a apontar para o espaço de trabalho original após a sincronização, e precisas de os atualizar manualmente ou através da parametrização.

Importante

A ligação de dependências aplica-se apenas a referências entre itens Fabric dentro do mesmo espaço de trabalho. Se um item referenciar um item Fabric num espaço de trabalho diferente, essa referência usa um ID de objeto e não se associa automaticamente. As referências a Ligações (conexões de fonte de dados, gateways) também não se vinculam automaticamente. Use Bibliotecas de Variáveis com conjuntos de valores específicos do ambiente para gerir referências de ligação entre ambientes.

Compatibilidade de vinculação de dependências

As tabelas seguintes mostram se as dependências de cada tipo de item Fabric se vinculam corretamente quando se implementa entre espaços de trabalho. Atualmente, este artigo aborda o comportamento de integração do Git . Como a binding é determinada pela forma como cada item armazena as suas referências de dependência na sua definição, o mesmo comportamento aplica-se a outros mecanismos de implementação que reutilizam essas definições, como pipelines de implementação e as APIs de importação (em massa).

Estas tabelas assumem que a dependência é outro item no mesmo espaço de trabalho que o item de origem. Uma referência a um item num espaço de trabalho diferente nunca se vincula automaticamente. Permanece fixado ao ID do objeto de origem independentemente do valor mostrado na tabela.

A coluna Auto-bind in Git indica:

  • Sim: A definição do item no Git armazena a referência de dependência como um ID lógico. Quando sincronizas o ramo para um novo espaço de trabalho, a referência associa-se automaticamente ao item correspondente nesse espaço de trabalho.
  • Não: A definição do item no Git armazena a referência da dependência como um ID de objeto (GUID específico do espaço de trabalho). A referência continua a apontar para o espaço de trabalho de origem após a sincronização. É necessário atualizá-lo manualmente ou parametrizá-lo para implementação entre espaços de trabalho.
  • Parcial: O item resolve a dependência por nome ou URI, o que pode funcionar se a nomeação for consistente entre os espaços de trabalho.

Notebooks

Dependência Vinculação automática no Git Notes
Lakehouse Yes Requer a ativação de "Lakehouse Auto-Binding in Git" nas definições do bloco de notas. Quando ativado, o ID do objeto é substituído por um ID lógico em notebook-settings.json. Esta definição está desativada por predefinição. Para mais informações, consulte Lakehouse auto-binding no Git.
Environment Yes
Base de Dados Espelhada Não

Note

A ligação Notebook to Lakehouse não está ativada por defeito. Tens de ativar a opção "Lakehouse Auto-Binding in Git" nas definições de cada caderno. Para mais informações, consulte controlo de origem e implementação do Notebook.

Reports

Dependência Vinculação automática no Git Notes
Modelo Semântico (do relatório Power BI) Partial O relatório refere o modelo através de uma referência relativa byPath em definition.pbir, e não de um ID lógico explícito. Resolve corretamente quando o modelo é implementado na mesma localização relativa no espaço de trabalho de destino, mas não se vincula através de um ID lógico. Para mais informações, consulte a pasta de relatórios de projetos do Power BI Desktop.
Modelo Semântico (do relatório paginado) Não A cadeia de ligação do relatório faz referência ao modelo semântico através de um identificador específico da área de trabalho que não é reescrito na implantação, pelo que continua a apontar para o modelo de origem. Precisa de atualizar esta referência para a implementação entre espaços de trabalho. (Relatórios elaborados no Report Builder que fazem referência ao modelo pelo nome podem, em vez disso, ser resolvidos pelo nome de apresentação, que é parcial.)

Gasoduto

Dependência Vinculação automática no Git Notes
Gasoduto Yes
Notebook Yes
Fluxo de dados Gen2 Yes
Base de Dados SQL Yes
Definição de trabalho do Spark Não A atividade SparkJobDefinition refere-se à Definição de Trabalho Spark pelo ID do objeto, não pelo ID lógico, por isso permanece apontada para o item de origem após a implementação. É necessário parametrizar este valor para a implementação em vários espaços de trabalho.
Lakehouse Yes
Modelo semântico Não A atividade PBISemanticModelRefresh refere-se ao modelo semântico pelo ID do item, não pelo ID lógico. É necessário parametrizar este valor para a implementação em vários espaços de trabalho.
Armazém Não O armazém artifactId é resolvido através do ID lógico e é novamente associado, mas o linkedService também armazena o SQL endpoint do espaço de trabalho de origem, que não é reescrito. Parametrizar o endpoint para implementação entre espaços de trabalho.

Modelos semânticos

Dependência Vinculação automática no Git Notes
Modelo semântico Partial As referências de modelos encadeados ou compostos utilizam cadeias de conexão por nome.
SQL Analytics Endpoint (lakehouse) Não A cadeia de ligação do Direct Lake em TMDL expressions.tmdl contém um URL de ponto final específico do espaço de trabalho e o GUID da base de dados. É necessário substituir estes parâmetros para a implementação entre espaços de trabalho.
Base de dados KQL Não A cadeia de ligação com um URI de cluster nas expressões TMDL contém valores específicos da área de trabalho.
base de dados SQL Não A cadeia de ligação nas expressões TMDL contém valores específicos do espaço de trabalho.
Armazém Não A ligação ao endpoint de análise SQL do armazém utiliza uma URL específica do espaço de trabalho.

Casas dos lagos

Dependência Vinculação automática no Git Notes
Casa do Lago (atalho) Yes Os atalhos internos do OneLake que apontam para outro item do Fabric, como um lakehouse ou armazém, são armazenados como um identificador lógico e vinculam-se novamente ao item da área de trabalho de destino. Atalhos para fontes externas, como o Azure Data Lake Storage Gen2 ou o Amazon S3, apontam para fora do Fabric e incluem uma referência de ligação, pelo que não estão sujeitos à vinculação ao ID lógico. Para consultar a lista completa dos destinos dos atalhos, veja Atalhos do OneLake. Para o comportamento da implementação, consulte integração do Git no Lakehouse e pipelines de implementação.

Fluxos de dados (Gen2)

Por defeito, o Dataflow Gen2 cria referências absolutas a itens do Fabric: a consulta armazena o ID do espaço de trabalho de origem e o ID de objeto do item, que não são reescritos durante a implementação. Uma referência de origem pode utilizar, em alternativa, uma referência relativa: quando seleciona um item no nó !(Current Workspace) num conector Fabric, a consulta armazena o item pelo nome (sem GUIDs) e este é resolvido para o item correspondente na área de trabalho de destino durante a implementação. Os destinos de saída usam sempre referências absolutas e não são novamente associados. Para os destinos e para qualquer referência absoluta de origem, parametrize os valores para implementação entre áreas de trabalho. Para mais informações, consulte Referências relativas com conectores Fabric em Dataflow Gen2 e Dataflow Gen2 com integração CI/CD e Git.

Referências fonte:

Dependência Vinculação automática no Git Notes
Lakehouse Partial Só volta a associar quando é criado como uma referência relativa (!(Current Workspace)); a referência absoluta predefinida não volta a associar.
Armazém Partial Só volta a associar quando é criado como uma referência relativa (!(Current Workspace)); a referência absoluta predefinida não volta a associar.

Referências de destino:

Dependência Vinculação automática no Git Notes
Lakehouse Não
Armazém Não
Base de Dados SQL Não

Definições de trabalho do Spark

Dependência Vinculação automática no Git Notes
Environment Yes
Lakehouse Não defaultLakehouseArtifactId usa um ID de objeto.

Tarefas de cópia

Dependência Vinculação automática no Git Notes
Lakehouse Yes
Armazém Não O armazém artifactId é resolvido através do ID lógico e é novamente associado, mas o linkedService também armazena o SQL endPoint do espaço de trabalho de origem, que não é reescrito. Parametrizar o endPoint para implementação entre espaços de trabalho.
Base de Dados SQL Yes

GraphQL APIs

Dependência Vinculação automática no Git Notes
SQL Endpoint Yes
Armazém Yes
Base de Dados SQL Yes

Para todas as fontes de dados da API GraphQL, pode ser necessário reconfigurar a ligação e as credenciais após a implementação.

Fluxos de eventos

Dependência Vinculação automática no Git Notes
Lakehouse Yes
Eventhouse Yes Todos os destinos têm suporte total para CI/CD quando os itens estão no mesmo espaço de trabalho. Para o Eventhouse com modo de Ingestão Direta, pode ser necessário reconfigurar manualmente a ligação após a implementação. Para mais informações, consulte Eventstream CI/CD.
Ativador (Reflex) Yes Todos os destinos têm suporte total para CI/CD quando os itens estão no mesmo espaço de trabalho. Para mais informações, consulte Eventstream CI/CD.

Itens de KQL

Dependência Vinculação automática no Git Notes
Base de dados KQL para eventhouse Yes O parentEventhouseItemId em DatabaseProperties.json é um identificador lógico e associa-se à eventhouse de destino. Uma base de dados KQL é implementada como um recurso subordinado da respetiva eventhouse principal.
Conjunto de consultas KQL para a base de dados KQL Partial É resolvido através de clusterUri e databaseName, não do ID do item. A definição inclui um databaseItemId, mas é um ID de objeto que não se reassocia, por isso a resolução depende do URI entre os ambientes.
Painel em tempo real para a base de dados KQL Partial Utiliza um dataSources array com URIs de cluster. Mesmo padrão do conjunto de consultas KQL.

Armazéns

Dependência Vinculação automática no Git Notes
Armazém (referência cruzada) Não Referências a outros armazéns usam IDs de objetos.
SQL Endpoint Não As referências SQL Endpoint utilizam identificadores específicos do espaço de trabalho.

Bibliotecas de variáveis

Dependência Vinculação automática no Git Notes
Itens do Fabric (tipo ItemReference) Não O ItemReference tipo variável armazena workspaceId e itemId como GUIDs brutos. Tem de atualizar manualmente ou substituir estes valores mediante conjuntos de valores por ambiente.

Itens sem dependências

Os seguintes itens não apresentam preocupações de ligação de dependência entre espaços de trabalho:

  • Environment
  • Base de Dados SQL
  • Eventhouse (item de contentor; as bases de dados KQL fazem referência ao mesmo)
  • Base de Dados Espelhada (apenas para configuração de origem externa)

Resumo

Quando implementa itens do Fabric em vários espaços de trabalho, as dependências entre itens podem ser interrompidas se as referências forem armazenadas como IDs de objetos específicos do espaço de trabalho em vez de IDs lógicos portáteis. Nem todos os tipos de itens suportam ligação de dependências através de IDs lógicos. Antes de configurar a implementação entre espaços de trabalho, reveja as tabelas de compatibilidade neste artigo para identificar quais as dependências que se associam automaticamente e quais requerem parametrização manual.

Conteúdo relacionado

  • Last updated on