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

O gerenciamento do ciclo de vida tem duas partes: integração e implantação. Para entender o que é integração em Fabric, consulte a visão geral da integração do Git. Para entender o que são os 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 Fabric licenses.

Todos os workspaces devem ser associados a uma licença de 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, você deve ser o proprietário do modelo semântico.

Se a capacidade do workspace estiver em uma localização geográfica enquanto o repositório Azure DevOps estiver em outro local, o administrador do Fabric poderá decidir se deseja habilitar as exportações entre áreas 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.

As seguintes considerações são importantes para ter em mente:

• 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

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 a seguir para editar o 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 ele pode resultar em corrupção de dados em seus visuais.

Quando você fixa um bloco em um painel, se o bloco depende de um item não suportado (qualquer item não nesta lista não tem suporte) ou de um item que você não tem permissões para implantar, depois que o painel é implantado, o bloco não é 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 tenha um modelo semântico Fabric, porque a fonte de dados de destino é externa, você precisa especificar o servidor e o banco de dados.

No entanto, relatórios paginados que usam um modelo semântico Fabric usam um modelo semântico interno. Nesses casos, você não pode contar com o nome da fonte de dados para identificar o modelo semântico Fabric 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 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.

• Database - O formato de banco 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> pela ID do conjunto de dados. Você pode obter o identificador do conjunto de dados da URL, selecionando o GUID que aparece após datasets/ e antes da próxima barra inclinada.

  

• 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, ele poderá não ser atualizado com a versão mais recente que você pode ver em 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 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.

Conteúdo relacionado

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