Pianificare la migrazione di report con estensione rdl a Power BI

  • Articolo

SI APPLICA A: Power BI Report Builder Power BI Desktop Server di report di Power BI 2022 SQL Server 2022 Reporting Services

Questo articolo è destinato agli autori di report di Power BI e agli autori di report di SQL Server Reporting Services (SSRS) e agli amministratori di Power BI. Fornisce informazioni per la migrazione dei report RDL (Report Definition Language) in Power BI.

Diagramma che mostra la migrazione dei report con estensione .rdl dall'ambiente locale al servizio Power BI.

Il diagramma di flusso mostra il percorso di migrazione dei report con estensione .rdl locali ai report impaginati del servizio Power BI.

Nota

In Power BI i report .rdl sono detti report impaginati.

Le informazioni sono suddivise in quattro fasi. Prima di eseguire la migrazione dei report, è consigliabile leggere l'intero articolo.

  1. Prima di iniziare
  2. Fase pre-migrazione
  3. Fase di migrazione
  4. Fase post-migrazione

È possibile ottenere la migrazione senza tempi di inattività nei server di report o interruzioni per gli utenti del report. È importante comprendere che non è necessario rimuovere dati o report. È quindi possibile mantenere attivo l'ambiente corrente fino a quando non si è pronti per ritirarlo.

Prima di iniziare

Prima di avviare la migrazione, verificare che l'ambiente soddisfi determinati prerequisiti. Verranno descritti questi prerequisiti e verrà inoltre presentato un utile strumento di migrazione.

Preparazione alla migrazione

Quando ci si prepara a eseguire la migrazione dei report a Power BI, verificare prima di tutto di avere una licenza Power BI Pro o Premium per utente per caricare il contenuto nell'area di lavoro di destinazione.

Versioni supportate

È possibile eseguire la migrazione delle istanze del server di report in esecuzione in locale o in macchine virtuali ospitate da provider di servizi cloud come Azure.

L'elenco seguente descrive le versioni di SQL Server Reporting Services supportate per la migrazione a Power BI:

  • SQL Server Reporting Services 2012
  • SQL Server Reporting Services 2014
  • SQL Server Reporting Services 2016
  • SQL Server Reporting Services 2017
  • SQL Server Reporting Services 2019
  • SQL Server Reporting Services 2022

È anche possibile eseguire la migrazione di file con estensione .rdl dal server di report di Power BI.

Strumento di migrazione per Server di report di Power BI e SQL Server Reporting Services 2017+

Se si usa il server di report di Power BI o SQL Server Reporting Services dopo SQL Server 2016, è disponibile uno strumento predefinito per pubblicare i report in Power BI. Per altre informazioni, vedere Pubblicare file con estensione .rdl in Power BI.

Strumento di migrazione per le versioni precedenti di SQL Server

Per le versioni precedenti di SQL Server Reporting Services, è consigliabile usare lo strumento di migrazione .rdl per preparare ed eseguire la migrazione dei report. Questo strumento è stato sviluppato da Microsoft per aiutare i clienti a eseguire la migrazione dei report .rdl dai server SSRS in Power BI. È disponibile in GitHub e documenta una procedura dettagliata end-to-end dello scenario di migrazione.

Lo strumento automatizza le attività seguenti:

  • Controllo della presenza di origini dati non supportate e funzionalità dei report non supportate.
  • Conversione delle risorse condivise in risorse incorporate:
    • Le origini dati condivise diventano origini dati incorporate.
    • I set di dati condivisi diventano set di dati incorporati.
  • Pubblica report che superano i controlli come report impaginati, in un'area di lavoro di Power BI specificata.

I report esistenti non vengono modificati né rimossi. Al termine, lo strumento restituisce un riepilogo di tutte le azioni completate, con esito positivo o negativo.

Nel corso del tempo, Microsoft può migliorare lo strumento. La community è invitata a contribuire al suo miglioramento.

Fase pre-migrazione

Dopo aver verificato che l'organizzazione soddisfa i prerequisiti, è possibile iniziare la fase pre-migrazione. Questa fase è costituita a sua volta da tre fasi:

  1. Discover
  2. Valutazione
  3. Preparazione

Rilevazione

L'obiettivo della fase di individuazione è identificare le istanze del server di report esistenti. Questo processo comporta l'analisi della rete per identificare tutte le istanze del server di report nell'organizzazione.

È possibile usare Microsoft Assessment and Planning Toolkit. Il "MAP Toolkit" individua e segnala le istanze, le versioni e le funzionalità installate del server di report. Si tratta di un potente strumento di inventario, valutazione e report che consente di semplificare il processo di pianificazione della migrazione.

Le organizzazioni possono avere centinaia di report di SQL Server Reporting Services (SSRS). Alcuni di questi report possono diventare obsoleti a causa della mancanza di utilizzo. L'articolo Trovare e ritirare i report inutilizzati consente di individuare i report inutilizzati e come creare una cadenza per la pulizia.

Valutazione

Dopo aver individuato le istanze del server di report, l'obiettivo della fase di valutazione consiste nel comprendere i report con estensione .rdl o gli elementi del server di cui non è possibile eseguire la migrazione.

È possibile eseguire la migrazione dei report con estensione .rdl dai server di report a Power BI. Ogni report con estensione .rdl migrato diventa un report impaginato di Power BI.

I tipi di elemento del server di report seguenti, tuttavia, non possono essere migrati in Power BI:

  • Origini dati condivise e set di dati condivisi: lo strumento di migrazione .rdl converte automaticamente origini dati condivise e set di dati condivisi in origini dati e set di dati incorporati, purché usino origini dati supportate.
  • Risorse, ad esempio i file di immagine.
  • Report collegati eseguire la migrazione, indipendentemente dal fatto che il report padre collegato sia selezionato o meno per la migrazione. Nel servizio Power BI sono normali report con estensione .rdl.
  • Indicatori KPI: solo Server di report di Power BI o Reporting Services 2016 o versione successiva.
  • Report per dispositivi mobili: solo Server di report di Power BI o Reporting Services 2016 o versione successiva.
  • Modelli di report: deprecati.
  • Parti di report: deprecate.

Se i report con estensione .rdl si basano su funzionalità non ancora supportate dai report impaginati di Power BI, è possibile pianificarli come report di Power BI, quando ha senso.

Per altre informazioni sulle origini dati supportate per i report impaginati nel servizio Power BI, vedere Origini dati supportate per i report impaginati di Power BI.

In genere, i report impaginati di Power BI sono ottimizzati per la stampa o la generazione di PDF. I report di Power BI sono ottimizzati per esplorazione e interattività. Per altre informazioni, vedere Quando usare report impaginati in Power BI.

Il file DLL di riferimento del codice personalizzato all'interno di un report non è supportato.

Le differenze nell'output PDF si verificano più spesso quando si utilizza un tipo di carattere che non supporta caratteri non latini in un report nel quale vengono successivamente aggiunti caratteri non latini. Testare l'output di rendering PDF sia nel server di report che nei computer client per verificare che il rendering del report sia corretto.

Preparazione

L'obiettivo della fase di preparazione è quello di preparare tutti gli elementi. Illustra la configurazione dell'ambiente Power BI, la pianificazione della sicurezza e la pubblicazione dei report e le idee per la riqualifica degli elementi del server di report che non verranno migrati.

  1. Verificare il supporto per le origini dati dei report e configurare un'istanza di Power BI Gateway per consentire la connettività con le origini dati locali.
  2. Acquisire familiarità con la sicurezza di Power BI e pianificare come riprodurre le cartelle e le autorizzazioni del server di report con le aree di lavoro di Power BI.
  3. Acquisire familiarità con la condivisione di Power BI e stabilire come verrà distribuito il contenuto mediante la pubblicazione di app Power BI.
  4. È consigliabile usare modelli semantici di Power BI condivisi al posto delle origini dati condivise del server di report.
  5. Usare Power BI Desktop per sviluppare report ottimizzati per dispositivi mobili, possibilmente usando l'oggetto visivo personalizzato di Power KPI al posto dei report per dispositivi mobili e degli indicatori KPI del server di report.
  6. Rivalutare l'uso del campo predefinito ID utente nei report. Se si fa affidamento sull'ID utente per proteggere i dati dei report, è necessario comprendere che per i report impaginati (se ospitati nel servizio Power BI) viene restituito il nome dell'entità utente (UPN, User Principal Name). Invece di restituire il nome dell'account NT, ad esempio AW\adelev, il campo predefinito restituisce un valore simile a adelev@adventureworks.com. È necessario rivedere le definizioni del set di dati ed eventualmente i dati di origine. Dopo la revisione e la pubblicazione, è consigliabile testare accuratamente i report per verificare che le autorizzazioni per i dati funzionino come previsto.
  7. Rivalutare l'uso del campo predefinito ExecutionTime nei report. Per i report impaginati (se ospitati nel servizio Power BI), il campo predefinito restituisce la data e l'ora nell'ora UTC. Questo può influire sui valori predefiniti dei parametri dei report e sulle etichette dell'ora di esecuzione dei report, aggiunte in genere nel piè di pagina dei report.
  8. Se l'origine dati è SQL Server (locale), verificare che i report non usino visualizzazioni mappa. La visualizzazione mappa dipende dai tipi di dati spaziali di SQL Server e questi non sono supportati dal gateway. Per altre informazioni, vedere Linee guida per il recupero dei dati per i report impaginati (tipi di dati complessi di SQL Server).
  9. Per i parametri a catena, tenere presente che i parametri vengono valutati in sequenza. Provare prima a pre-aggregare i dati del report. Per altre informazioni, vedere Usare i parametri a cascata nei report impaginati.
  10. Assicurarsi che gli autori di report abbiano installato il Power BI Report Builder e che sia possibile distribuire facilmente le versioni successive in tutta l'organizzazione.
  11. Utilizzare la documentazione sulla pianificazione della capacità per i report impaginati.

Fase di migrazione

Dopo aver preparato l'ambiente Power BI e i report, si è pronti per la fase di migrazione.

Sono disponibili due opzioni di migrazione: manuale e automatica. La migrazione manuale è indicata per un numero ridotto di report o per i report che richiedono modifiche prima della migrazione. La migrazione automatica è adatta in presenza di un numero elevato di report.

Migrazione manuale

Chiunque disponga dell'autorizzazione per accedere all'istanza del server di report e l'area di lavoro di Power BI può eseguire manualmente la migrazione dei report a Power BI. Ecco i passaggi da seguire:

  1. Aprire il portale del server di report che contiene i report di cui si vuole eseguire la migrazione.
  2. Scaricare ogni definizione di report, salvando i file RDL in locale.
  3. Aprire la versione più recente di Power BI Report Builder e connettersi al servizio Power BI usando l'ID Microsoft Entra (precedentemente noto come Azure Active Directory).
  4. Aprire ogni report in Power BI Report Builder e quindi:
    1. Verificare che tutte le origini dati e i set di dati siano incorporati nella definizione di report e che si tratti di origini dati supportate.
    2. Visualizzare in anteprima il report per assicurarsi che il rendering venga eseguito correttamente.
    3. Selezionare Pubblica e quindi selezionare servizio Power BI.
    4. Selezionare l'area di lavoro in cui si vuole salvare il report.
    5. Verificare che il report venga salvato. Se alcune funzionalità nella progettazione del report non sono ancora supportate, l'azione di salvataggio ha esito negativo. Si riceve una notifica dei motivi. Sarà quindi necessario modificare la progettazione del report e riprovare a salvare.

Migrazione automatica

Sono disponibili tre opzioni per la migrazione automatizzata. Puoi usare:

È anche possibile usare le API power BI, Reporting Services e Power BI disponibili pubblicamente per automatizzare la migrazione del contenuto. Sebbene lo strumento di migrazione RDL usi già queste API, è possibile sviluppare uno strumento personalizzato per rispondere ai propri requisiti specifici.

Per altre informazioni sulle API, vedere:

Fase post-migrazione

Dopo aver completato la migrazione, si è pronti per la fase post-migrazione. Questa fase prevede l'esecuzione di una serie di attività post-migrazione per garantire che tutto funzioni correttamente e in modo efficiente.

Impostazione del timeout della query per i set di dati incorporati

È possibile specificare i valori di timeout delle query durante la creazione di report quando si definisce un set di dati incorporato. Il valore di timeout viene archiviato con il report nell'elemento Timeout della definizione del report.

Configurare le origini dati

Dopo aver eseguito la migrazione dei report in Power BI, è necessario verificare che le origini dati siano configurate correttamente. Può essere necessario eseguire l'assegnazione alle origini dati del gateway e archiviare in modo sicuro le credenziali delle origini dati. Queste operazioni non vengono eseguite dallo strumento di migrazione RDL.

Esaminare le prestazioni dei report

È consigliabile completare le operazioni seguenti per garantire la migliore esperienza utente possibile per i report:

  1. Testare i report in ogni browser supportato da Power BI per verificare che il rendering venga eseguito correttamente.
  2. Eseguire test per confrontare i tempi di rendering dei report nel server di report e nel servizio Power BI. Verificare che il rendering dei report di Power BI venga eseguito in un tempo accettabile.
  3. Per i report con tempi di rendering lunghi, è consigliabile impostare Power BI per recapitarli agli utenti come sottoscrizioni di posta elettronica con report allegati.
  4. Per i report di Power BI basati su modelli semantici di Power BI, esaminare le progettazioni dei modelli per assicurarsi che siano completamente ottimizzate.

Risolvere i problemi

La fase post-migrazione è fondamentale per risolvere eventuali problemi e aspetti relativi alle prestazioni. L'aggiunta del carico di lavoro Report impaginati a una capacità può contribuire a rallentare le prestazioni, per i report impaginati e altri contenuti archiviati nella capacità.

Contenuto correlato

Per altre informazioni su questo articolo, consultare le risorse seguenti:

Sono disponibili partner Power BI per aiutare l'organizzazione a svolgere con successo il processo di migrazione. Per collaborare con un partner Power BI, visitare il portale dei partner Power BI.