Domande frequenti sugli strumenti di gestione del ciclo di vita di Fabric

La gestione del ciclo di vita include due parti: l'integrazione e la distribuzione. Per informazioni sull'integrazione in Fabric, vedere la panoramica dell'integrazione Git. Per comprendere cosa siano le pipeline di distribuzione in Fabric, consulta la panoramica delle pipeline di distribuzione.

Per una breve spiegazione dell'integrazione Git, vedere la Panoramica dell'integrazione Git. Risposta multilinea o formattata alla domanda. Usare qualsiasi formattazione di Markdown desiderata, purché si mantenga l'indentazione nelle righe successive al carattere "|".

Per una breve spiegazione delle pipeline di distribuzione, vedere la Panoramica delle pipeline di distribuzione.

Per informazioni sulle licenze, vedere Fabric licenze.

Tutte le aree di lavoro devono essere assegnate a una licenza Fabric. Tuttavia, è possibile usare diversi tipi di capacità per aree di lavoro diverse.

Per informazioni sui tipi di capacità, vedere Capacità e SKU.

Il modello delle autorizzazioni delle pipeline di distribuzione è descritto nella sezione permessi.

Per configurare le regole di distribuzione nelle pipeline di distribuzione, è necessario essere il proprietario del modello semantico.

Se la capacità dell'area di lavoro si trova in una posizione geografica mentre il repository Azure DevOps si trova in un'altra posizione, l'amministratore Fabric può decidere se abilitare le esportazioni tra aree geografiche. Per altre informazioni , vedere la sezione Gli utenti possono esportare gli elementi dalle repository Git ad altre posizioni geografiche.

Introduzione all'integrazione Git con le istruzioni introduttive.

Potrebbero esserci diversi motivi per cui un elemento è stato rimosso dall'area di lavoro.

• Se non è stato eseguito il commit dell'elemento e lo stesso è stato selezionato in un'azione di annullamento, l'elemento viene rimosso dall'area di lavoro.
• Se è stato eseguito il commit dell'elemento, esso potrebbe essere rimosso se vengono cambiati i rami e l'elemento non esiste nel nuovo ramo.

Le considerazioni seguenti sono importanti da tenere presente:

• Limitazioni delle regole di distribuzione
• Origini dati supportate per il flusso di dati e regole del modello semantico
• Aggiornamento incrementale
• automazione

È possibile assegnare un'area di lavoro alla pipeline e distribuirla nella pipeline, oppure assegnare un'area di lavoro diversa a ogni fase della pipeline. Per maggiori informazioni, vedere Assegnare un'area di lavoro a una pipeline di distribuzione.

I set di dati che utilizzano la modalità di connettività DirectQuery o Composita e che hanno tabelle con variazioni o data/ora automatica non sono supportati nelle pipeline di distribuzione. Se la distribuzione ha esito negativo e si ritiene che si tratti di un set di dati con una tabella di varianti, è possibile cercare la proprietà varianti nelle colonne della tabella. È possibile usare uno dei metodi seguenti per modificare il modello semantico, in modo tale che funzioni nelle pipeline di distribuzione.

• Nel set di dati, anziché usare la modalità DirectQuery o Composita, usare la modalità di importazione.

• Rimuovere le tabelle di data/ora automatica dal modello semantico. Se necessario, eliminare eventuali varianti rimanenti da tutte le colonne nelle tabelle. L'eliminazione di una variante può invalidare misure create dall'utente, colonne calcolate e tabelle calcolate. Usare questo metodo solo se si comprende il funzionamento del proprio modello semantico, poiché può danneggiare i dati nelle visualizzazioni.

Quando si aggiunge un riquadro a un dashboard, se il riquadro si basa su un elemento non supportato (qualsiasi elemento non incluso nell'elenco non è supportato) o su un elemento che non si dispone delle autorizzazioni per la distribuzione, dopo aver distribuito il dashboard non viene eseguito il rendering. Ad esempio, se si crea un riquadro da un report che si basa su un modello semantico per cui non si è amministratori, quando si distribuisce il report, verrà visualizzato un avviso di errore. Tuttavia, quando si distribuisce la dashboard con il riquadro, non si riceve un messaggio di errore, la distribuzione avrà esito positivo, ma il riquadro non visualizzerà alcuna informazione.

Il proprietario di un report impaginato distribuito è l'utente che ha distribuito il report. Quando si distribuisce un report impaginato per la prima volta, si diventa il proprietario del report.

Se si distribuisce un report impaginato in una fase che contiene già una copia di quel report, si sovrascrive il report precedente e se ne diventa il proprietario, anziché il precedente proprietario. In questi casi, occorrono credenziali per l'origine dati sottostante, per utilizzare i dati nel report paginato.

I sotto-report del report impaginato vengono mantenuti nella stessa cartella che contiene il report impaginato. Per evitare problemi di rendering, quando si usa la copia selettiva per copiare un report impaginato con sottoreport, selezionare sia il report principale che i sottoreport.

Le regole del report impaginato possono essere create se si vuole rimandare il report impaginato al modello semantico nella stessa fase. Quando si crea una regola di distribuzione per un report impaginato, è necessario selezionare un database e un server.

Se si imposta una regola di distribuzione per un report impaginato che non dispone di un modello semantico Fabric, perché l'origine dati di destinazione è esterna, è necessario specificare sia il server che il database.

Tuttavia, i report impaginati che usano un modello semantico Fabric usano un modello semantico interno. In questi casi, non è possibile basarsi sul nome dell'origine dati per identificare il modello semantico Fabric a cui ci si connette. Il nome dell'origine dati non cambia quando lo si aggiorna nella fase di destinazione, creando una regola per l'origine dati o chiamando l'API aggiorna origine dati. Quando si imposta una regola di distribuzione, è necessario mantenere il formato del database e sostituire l'ID oggetto del modello semantico nel campo del database. Poiché il modello semantico è interno, il server rimane invariato.

• Database : il formato del database per un report impaginato con un modello semantico Fabric è sobe_wowvirtualserver-<dataset ID>. Ad esempio: sobe_wowvirtualserver-d51fd26e-9124-467f-919c-0c48a99a1d63. Sostituire <dataset ID> con l'ID del set di dati. È possibile ottenere l'ID del set di dati dall'URL selezionando il GUID che viene dopo datasets/ e prima della barra successiva.

  

• Server: server che ospita il database. Mantenere il server esistente così come è.

Dopo una distribuzione, se si scarica il codice RDL del report impaginato, potrebbe non essere aggiornato con la versione più recente che è possibile visualizzare in servizio Power BI.

Quando si dispone di un flusso di dati che contiene modelli semantici configurati con l'aggiornamento incrementale, i criteri di aggiornamento non vengono copiati né sovrascritti durante la distribuzione. Dopo aver distribuito un flusso di dati che include un modello semantico con aggiornamento incrementale a una fase che non include questo flusso di dati, se si dispone di un criterio di aggiornamento, sarà necessario riconfigurarlo nella fase di destinazione. Se si distribuisce un flusso di dati con aggiornamento incrementale in una fase in cui è già presente, i criteri di aggiornamento incrementale non vengono copiati. In questi casi, se si desidera aggiornare la politica di aggiornamento nello stage di destinazione, è necessario farlo manualmente.

Contenuto correlato

• Nozioni di base sull'integrazione Git
• Iniziare a usare le pipeline di distribuzione