Perguntas frequentes sobre as ferramentas de gerenciamento do ciclo de vida do Fabric

O gerenciamento do ciclo de vida tem duas partes, integração e implantação. Para entender o que é integração no Fabric, consulte a visão geral da integração do Git. Para entender o que são pipelines de implantação na malha, consulte a visão geral dos pipelines de implantaçã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 com várias linhas ou formatada à pergunta. Use qualquer formatação de Markdown desejada, desde que mantenha o recuo nas linhas após o | caracteres.

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

Para obter informações sobre licenças, consulte Licenças de malha.

Todos os espaços de trabalho devem ser atribuídos a uma licença do 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 de 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 em um local geográfico enquanto o repositório de DevOps do Azure estiver em outro local, o administrador da Malha poderá decidir se deseja habilitar as exportações geográficas cruzadas. 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 introdução.

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

• Se o item não foi confirmado e você o selecionou em uma ação de desfazer , o item será removido do espaço de trabalho.
• Se o item foi confirmado, ele pode ser removido se você alternar ramificações e o item não existir na nova ramificação.

Estas são algumas considerações importantes a ter em mente:

• 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* Os pipelines de implantação não podem ser usados para implantar itens em um espaço de trabalho que esteja em uma região diferente.

Você pode atribuir um espaço de trabalho ao pipeline e implantá-lo no 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 tabelas de data/hora de variação ou automáticas não são suportados em pipelines de implantação. Se a implantação falhar e você achar que é porque tem um conjunto de dados com uma tabela de variação, poderá procurar a propriedade variations nas colunas da tabela. Você pode usar um dos métodos listados abaixo 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 esse método somente se você entender como seu modelo de modelo semântico funciona, pois isso pode resultar em corrupção de dados em seus visuais.

Quando você fixa um bloco em um painel, se o bloco depender de um item sem suporte (qualquer item que não esteja nesta lista não é suportado) ou de um item que você não tem permissões para implantar, depois de implantar o painel, o bloco não 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 você estiver implantando um relatório paginado em um estágio que já contém uma cópia desse relatório paginado, substituirá o relatório anterior e se tornará 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 você estiver definindo uma regra de implantação para um relatório paginado que não tenha um modelo semântico de malha, porque a fonte de dados de destino é externa, será necessário especificar o servidor e o banco de dados.

No entanto, os relatórios paginados que usam um modelo semântico de malha usam um modelo semântico interno. Nesses casos, você não pode confiar no nome da fonte de dados para identificar o modelo semântico de malha ao qual está se conectando. O nome da fonte de dados não é alterado quando você o atualiza no estágio de destino, criando uma regra de fonte de dados ou chamando a API de fonte de dados de atualização. 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.

• Banco de dados - O formato de banco de dados para um relatório paginado com um modelo semântico de malha é 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 para frente.

  

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

Após uma implantação, se você baixar a RDL do relatório paginado, ele pode não ser atualizado com a versão mais recente que você pode ver no serviço do Power BI.

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.

Os pipelines de implantação não exibem conjuntos de dados que pertencem a datamarts nos estágios de pipeline. Quando você está implantando um datamart, seu conjunto de dados também é implantado. Você pode visualizar o conjunto de dados do seu datamart no espaço de trabalho do estágio em que ele está.

Conteúdos relacionados

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