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 no Fabric, consulte a visão geral dos pipelines de implantação.

Para obter uma breve explicação da integração do Git, consulte a Visão geral da integração do Git. Uma resposta formatada ou de várias linhas para a pergunta. Use qualquer formatação Markdown desejada, desde que você mantenha o recuo nas linhas após os caracteres | (barra vertical).

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 do Fabric.

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 os tipos de capacidade, consulte Capacidade e SKUs.

O modelo de permissões de pipelines de implantação é descrito na seção 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 do Fabric poderá decidir se habilitará as exportações entre regiões geográficas. Para obter mais informações, consulte Usuários podem exportar itens para repositórios Git em outras localizações geográficas.

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 tiver sido confirmado e você o tiver selecionado em uma ação desfazer, o item será removido do espaço de trabalho.
• Se o item foi confirmado, ele poderá ser removido se você alternar entre as ramificações e o item não existir na nova ramificação.

Veja alguns pontos importantes a serem lembrados:

• Limitações das regras de implantação
• Fontes de dados com suporte para fluxo de dados e regras de modelo semântico
• 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 seu pipeline e implantá-lo em todo o pipeline ou atribuir um espaço de trabalho diferente a cada estágio do pipeline. Para obter mais informações, confira Atribuir um workspace a um pipeline de implantação.

Conjuntos de dados que usam o modo de conectividade DirectQuery ou Composite e têm variação ou tabelas de data/hora automática não têm suporte em pipelines de implantação. Se a implantação falhar e você achar que é porque você 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.

• Em seu conjunto de dados, em vez de usar o modo DirectQuery ou Composite, use o modo de importação.

• Remova as tabelas automáticas de data/hora do modelo semântico. Se necessário, exclua todas as variações restantes de todas as colunas em suas tabelas. Excluir uma variação pode invalidar medidas criadas pelo usuário, colunas calculadas e tabelas calculadas. Use esse método somente se você entender como o modelo semântico funciona, pois isso pode resultar em corrupção de dados em seus visuais.

Quando você fixa um bloco a um dashboard, se o bloco depender de um item sem suporte (qualquer item fora desta lista é considerado sem suporte) ou de um item para o qual você não tem permissões para implantar, depois de implantar o dashboard, 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 do qual você 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. Quando você implantar um relatório paginado pela primeira vez, passará a ser o proprietário do relatório.

Se estiver implantando um relatório paginado em um estágio que já contenha uma cópia desse relatório paginado, você 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 do relatório paginado são mantidos na mesma pasta que contém o relatório paginado. Para evitar problemas de renderização, ao usar a 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 paginados poderão 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ê precisará 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 tem um modelo semântico do Fabric, porque a fonte de dados de destino é externa, você precisa especificar o servidor e o banco de dados.

Entretanto, os relatórios paginados que usam um modelo semântico do Fabric usam um modelo semântico interno. Nesses casos, não é possível confiar no nome da fonte de dados para identificar o modelo semântico do Fabric ao qual você 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 a ID do objeto de modelo semântico no campo de 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 do Fabric é sobe_wowvirtualserver-<dataset ID>. Por exemplo, sobe_wowvirtualserver-d51fd26e-9124-467f-919c-0c48a99a1d63. Substitua o <dataset ID> pela ID do conjunto de dados. Você pode obter a ID do conjunto de dados da URL, selecionando o GUID que vem após datasets/ e antes da próxima barra.

  

• Servidor – o servidor que hospeda o banco de dados. Mantenha o servidor existente como está.

Após uma implantação, se você baixar o RDL do relatório paginado, talvez ele não seja 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 em 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 em que 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, será necessário fazê-lo manualmente.

Os pipelines de implantação não exibem conjuntos de dados que pertencem a datamarts nos estágios do pipeline. Ao implantar um datamart, seu conjunto de dados também será implantado. Você pode exibir o conjunto de dados do datamart no workspace do estágio em que ele está.

Conteúdo relacionado

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