Perguntas frequentes sobre as ferramentas de gestão do ciclo de vida do Fabric

O gerenciamento do ciclo de vida tem duas partes, integração e implantação. Para compreender o que é integração em Fabric, consulte a visão geral da integração Git. Para compreender o que são os pipelines de implementação no Fabric, consulte a visão geral de pipelines de implementação.

Para obter uma breve explicação sobre a integração do Git, consulte a visão geral da integração do Git. Uma resposta multilinha ou formatada para a pergunta. Use qualquer formatação de Markdown desejada, desde que mantenha o recuo nas linhas após o | caracteres.

Para uma breve explicação dos pipelines de implantação, consulte a visão geral dos pipelines de implantação.

Para informações sobre licenças, consulte licenças Fabric.

Todos os espaços de trabalho devem ser atribuídos a uma licença Fabric. No entanto, você pode usar diferentes tipos de capacidade para diferentes espaços de trabalho.

Para obter informações sobre tipos de capacidade, consulte Capacidade e SKUs.

O modelo de permissões dos pipelines de implantação é descrito na seção de permissões.

Para configurar regras de implantação em pipelines de implantação, você deve ser o proprietário do modelo semântico.

Se a capacidade do espaço de trabalho estiver numa localização geográfica enquanto o repositório Azure DevOps estiver noutra localização, o administrador do Fabric pode decidir se ativa as exportações entre geolocalizações. Para obter mais informações, consulte Os usuários podem exportar itens para repositórios Git em outros locais geográficos.

Comece a usar a integração do Git usando as instruções de início.

Pode haver vários motivos pelos quais um item foi removido do espaço de trabalho.

• Caso o item não tenha sido confirmado e o utilizador o selecione em uma ação , o item será removido do espaço de trabalho.
• Se o item for confirmado, ele pode ser removido se mudar de ramo e o item não existir no novo ramo.

É importante ter em mente as seguintes considerações:

• Limitações da regra de implantação
• Fontes de dados suportadas para regras de modelo semântico e de fluxo de dados
• Atualização incremental
• Automação

Você pode atribuir um espaço de trabalho ao seu pipeline e implantá-lo em todas as etapas do pipeline, ou atribuir um espaço de trabalho diferente a cada estágio do pipeline. Para obter mais informações, consulte atribuir um espaço de trabalho a um pipeline de implantação.

Os conjuntos de dados que usam o modo de conectividade DirectQuery ou Composite e têm variação ou tabelas de data/hora automáticas não são compatíveis com os pipelines de implantação. Se a implantação falhar e achar que é porque tem um conjunto de dados com uma tabela de variações, poderá procurar a propriedade variations nas colunas da sua tabela. Você pode usar um dos seguintes métodos para editar seu modelo semântico para que ele funcione em pipelines de implantação.

• No conjunto de dados, em vez de usar o DirectQuery ou o modo Composto, use o modo de importação .

• Remova as tabelas automáticas de data/hora do seu modelo semântico. Se necessário, exclua as variações restantes de todas as colunas das tabelas. A exclusão de uma variação pode invalidar medidas criadas pelo usuário, colunas calculadas e tabelas calculadas. Use este método somente se entender como o seu modelo semântico funciona, pois pode resultar em danos nos dados nas suas visualizações.

Quando fixas um tile num dashboard, se o tile depender de um item não suportado (qualquer item que não esteja nesta lista não é suportado), ou num item para o qual não tens permissões para implementar, depois de implementares o dashboard o tile deixa de ser renderizado. Por exemplo, se você criar um bloco a partir de um relatório que depende de um modelo semântico no qual não é administrador, ao implantar o relatório, você receberá um aviso de erro. No entanto, ao implantar o painel com o bloco, você não recebe uma mensagem de erro, a implantação será bem-sucedida, mas o bloco não exibirá nenhuma informação.

O proprietário de um relatório paginado implantado é o usuário que implantou o relatório. Ao implantar um relatório paginado pela primeira vez, você se torna o proprietário do relatório.

Se estiver a implantar um relatório paginado num estágio que já contém uma cópia desse relatório paginado, substituirá o relatório anterior e tornar-se-á o seu proprietário, em vez do proprietário anterior. Nesses casos, você precisa de credenciais para a fonte de dados subjacente, para que os dados possam ser usados no relatório paginado.

Os sub-relatórios de relatório paginados são mantidos na mesma pasta que contém o relatório paginado. Para evitar problemas de renderização, quando você estiver usando uma cópia seletiva para copiar um relatório paginado com sub-relatórios, selecione o relatório pai e os sub-relatórios.

As regras de relatório paginado podem ser criadas se você quiser apontar o relatório paginado para o modelo semântico no mesmo estágio. Ao criar uma regra de implantação para um relatório paginado, você precisa selecionar um banco de dados e um servidor.

Se estiveres a definir uma regra de deployment para um relatório paginado que não tem um modelo semântico Fabric, porque a fonte de dados alvo é externa, precisas de especificar tanto o servidor como a base de dados.

No entanto, relatórios paginados que utilizam um modelo semântico Fabric utilizam um modelo semântico interno. Nesses casos, não pode confiar no nome da fonte de dados para identificar o modelo semântico Fabric ao qual está a ligar-se. O nome da fonte de dados não é alterado ao atualizá-lo no estágio de destino, criando uma regra de fonte de dados ou chamando a API update datasource. Ao definir uma regra de implantação, você precisa manter o formato do banco de dados e substituir o ID do objeto do modelo semântico no campo do banco de dados. Como o modelo semântico é interno, o servidor permanece o mesmo.

• Database - O formato de base de dados para um relatório paginado com um modelo semântico Fabric é sobe_wowvirtualserver-<dataset ID>. Por exemplo, sobe_wowvirtualserver-d51fd26e-9124-467f-919c-0c48a99a1d63. Substitua o <dataset ID> pelo ID do seu conjunto de dados. Você pode obter o ID do conjunto de dados da URL, selecionando o GUID que vem depois datasets/ e antes da próxima barra.

  

• Servidor - O servidor que hospeda seu banco de dados. Mantenha o servidor existente como está.

Após uma implementação, se descarregar o RDL do relatório paginado, pode não ser atualizado com a versão mais recente que pode ver no Power BI service.

Quando você tem um fluxo de dados que contém modelos semânticos configurados com atualização incremental, a política de atualização não é copiada ou substituída durante a implantação. Depois de implantar um fluxo de dados que inclui um modelo semântico com atualização incremental para um estágio que não inclui esse fluxo de dados, se você tiver uma política de atualização, precisará reconfigurá-la no estágio de destino. Se você estiver implantando um fluxo de dados com atualização incremental em um estágio onde ele já reside, a política de atualização incremental não será copiada. Nesses casos, se você deseja atualizar a política de atualização no estágio de destino, você precisa fazê-lo manualmente.

Conteúdos relacionados

• Introdução à integração com o Git
• Comece com os pipelines de implantação