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.

Per una breve spiegazione dei piani di dispiegamento, vedi la panoramica del piano di dispiegamento.

Il tipo di elemento del piano di distribuzione viene visualizzato solo dopo che un amministratore di Fabric abilita l'impostazione del tenant. Nel portale amministrativo, sotto Impostazioni> Tenant Microsoft Fabric, abilita Gli utenti possono creare elementi del piano di distribuzione (anteprima), impostare Applica all'intera organizzazione o a un gruppo di sicurezza, e selezionare Applica.

Finché questa impostazione non è attivata, il tipo di oggetto rimane nascosto in ogni spazio di lavoro.

La distribuzione torna al comportamento predefinito. Gli elementi vengono distribuiti senza un ordine specificato e senza azioni preliminari o successive alla distribuzione. Qualsiasi dipendenza che il piano proteggeva, ad esempio una vista del warehouse che legge una tabella del lakehouse popolata da un notebook, torna a non funzionare.

Un piano correttamente ordinato distribuisce i metadati degli elementi nell’ordine in cui li dichiari, ma la distribuzione di un lakehouse non aggiunge righe alle sue tabelle. Una vista del data warehouse che legge una tabella lakehouse non riesce a effettuare il binding a meno che quella tabella non sia stata creata prima da un notebook o da una pipeline di dati. Aggiungi un'azione post-distribuzione tra il lakehouse e il data warehouse che produce la tabella. Un'azione segnala il completamento quando termina l'azione stessa, non quando i servizi che alimenta si sono aggiornati, quindi inserisci qualsiasi controllo della disponibilità nell'ultima cella del notebook o nell'ultima attività della pipeline di dati. Per un esempio, vedi esempi di piano di deployment.

Il campo predefinito della casa sul lago di un quaderno contiene ID che puntano a una specifica casa sul lago in uno spazio di lavoro specifico. Dopo che il notebook arriva in una nuova area di lavoro tramite Git, quegli ID possono comunque puntare all'area di lavoro originale. Imposta il lakehouse predefinito per l'ambiente di destinazione nelle impostazioni del notebook prima dell'esecuzione, oppure consenti al notebook di individuare il proprio lakehouse in fase di esecuzione. Per altre informazioni, vedere Controllo del codice sorgente e distribuzione del notebook.

L'output di esecuzione è visibile dal deployment nel portale. Le esecuzioni dell'azione rimandano alla cronologia di esecuzione dell'elemento sottostante, con i log e i dettagli dei passaggi.

Un deployment fallito non annulla le implementazioni di item completate o le modifiche apportate dalle azioni. Per indicazioni sul recupero, vedi Il dispiegamento interrotto a metà strada.

Non direttamente. Attiva Aggiorna da Git da uno scheduler esterno, ad esempio Azure Pipelines o GitHub Actions, e il piano allegato viene eseguito come parte di questa distribuzione.

Sì, se la pipeline guida il deployment tramite un'API Fabric che supporta l'allegazione di un piano, come l'API di sincronizzazione Git, l'API di distribuzione delle pipeline o l'API di importazione batch. Un deployment guidato dalla CLI di Fabric, il provider Terraform per Fabric, o dalla libreria Python fabric-cicd non può allegare un piano.

No Un piano definisce gli elementi in una distribuzione e le azioni eseguite su di essi. La configurazione a livello di workspace non fa parte di un deployment, quindi impostazioni come l'identità dello workspace, le impostazioni di Spark e la connessione Git non vengono create o aggiornate da un piano.

Configura questi elementi nello spazio di lavoro di destinazione prima di distribuire. Un elemento che dipende dalla configurazione a livello di workspace, come un notebook che si autentica tramite l'identità dello workspace, fallisce a runtime se lo workspace di destinazione non è configurato allo stesso modo della sorgente.

No Un piano di distribuzione segue il modello standard dello spazio di lavoro Fabric. Per ulteriori informazioni, vedi permessi del piano di dispiegamento.

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