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, fare riferimento alla Panoramica dell'integrazione Git. Per informazioni sulle pipeline di distribuzione in Fabric, vedere 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 Markdown desiderata, purché il rientro venga mantenuto nelle righe dopo il carattere |.

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

Per informazioni sulle licenze, vedere Licenze di Fabric.

Tutte le aree di lavoro devono essere assegnate a una licenza di 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 autorizzazioni.

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 di Azure DevOps si trova in un'altra posizione, l'amministratore di 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.

Occorre tenere a mente le seguenti considerazioni:

• Limitazioni delle regole di distribuzione
• Origini dati supportate per il flusso di dati e regole del modello semantico
• Aggiornamento incrementale
• Automazione* le pipeline di distribuzione non possono essere usate per distribuire elementi in un'area di lavoro che si trova in un'area diversa.

È 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 usano la modalità di connettività DirectQuery o Composita e hanno tabelle di data/ora automatica o di variante, non sono supportate 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 elencati di seguito per modificare il modello semantico in modo 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 le misure create dall'utente, le colonne calcolate e le tabelle calcolate. Usare questo metodo solo se si comprende il funzionamento del modello semantico, in quanto può causare un danneggiamento dei dati negli oggetti visivi.

Quando si fissa un riquadro a una dashboard, se il riquadro si basa su un elemento non supportato (qualsiasi elemento non presente in questo elenco non è supportato), o su un elemento che non si è autorizzati a distribuire, dopo la distribuzione della dashboard, non verrà eseguito il rendering del riquadro. 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 del report impaginato, si diventa proprietari al posto del proprietario precedente e il report precedente si sovrascrive. In questi casi, occorrono credenziali per l'origine dati sottostante, in modo che i dati possano essere usati nel report impaginato.

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 sotto-report, selezionare sia il report padre che i sotto-report.

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 di 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 di Fabric usano un modello semantico interno. In questi casi, non è possibile basarsi sul nome dell'origine dati per identificare il modello semantico di Fabric a cui ci si connette. Il nome dell'origine dati non cambia quando lo si aggiorna nella fase di destinazione, creando una regola dell'origine dati o chiamando l'API dell'origine dati di aggiornamento. 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 di 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 l'RDL (Report Definition Language) del report impaginato, potrebbe non essere aggiornato alla versione più recente che è possibile visualizzare nel 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 il criterio di aggiornamento nella fase di destinazione, è necessario farlo manualmente.

Le pipeline di distribuzione non mostrano set di dati appartenenti ai data mart nelle fasi della pipeline. Quando si distribuisce un data mart, viene distribuito anche il set di dati. È possibile visualizzare il set di dati del data mart nell'area di lavoro della fase in cui si trova.

Contenuto correlato

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