Planifier la migration des rapports .rdl vers Power BI

  • Article

S’APPLIQUE À : Power BI Report Builder Power BI Desktop Power BI 2022 Report Server SQL Server 2022 Reporting Services

Cet article s’adresse aux auteurs de rapports Power BI Report Server et SQL Server Reporting Services (SSRS), ainsi qu’aux administrateurs Power BI. Il vous fournit des conseils concernant la migration de vos rapports Report Definition Language (.rdl) vers Power BI.

Diagramme montrant la migration de rapports .rdl d’un emplacement local vers le service Power BI.

Diagramme de flux montrant le chemin de migration des rapports .rdl locaux vers des rapports paginés dans le service Power BI.

Notes

Dans Power BI, les rapports .rdl sont appelés rapports paginés.

Ces conseils sont répartis selon quatre étapes. Nous vous recommandons de lire l’article dans son intégralité avant d’effectuer la migration de vos rapports.

  1. Avant de commencer
  2. Étape de prémigration
  3. Étape de migration
  4. Étape de post-migration

Vous pouvez effectuer la migration sans arrêter vos serveurs de rapports ni perturber les utilisateurs de vos rapports. Il est important de savoir qu’il n’est pas nécessaire de supprimer des données ou des rapports. Cela signifie que vous pouvez conserver votre environnement actuel jusqu’à sa mise hors service.

Avant de commencer

Avant de commencer la migration, vérifiez que votre environnement répond à certains prérequis. Nous décrirons ces prérequis, puis nous vous présenterons un outil de migration.

Préparation à la migration

Lorsque vous vous préparez à migrer vos rapports vers Power BI, vérifiez d’abord que vous disposez d’une licence Power BI Pro ou Premium par utilisateur pour charger du contenu dans l’espace de travail cible.

Versions prises en charge

Vous pouvez migrer des instances de serveur de rapports qui sont exécutées localement ou sur des machines virtuelles hébergées par des fournisseurs cloud, comme Azure.

La liste suivante indique les versions de SQL Server Reporting Services qui sont prises en charge pour la migration vers 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

Vous pouvez également migrer des fichiers .rdl à partir de Power BI Report Server.

Outil de migration pour Power BI Report Server et SQL Server Reporting Services 2017+

Si vous utilisez Power BI Report Server ou SQL Server Reporting Services post-SQL Server 2016, un outil intégré permet de publier ses rapports dans Power BI. Pour plus d’informations, consultez Publier des fichiers .rdl dans Power BI.

Outil de migration pour les versions précédentes de SQL Server

Pour les versions antérieures de SQL Server Reporting Services, nous vous recommandons d’utiliser l’outil de migration RDL pour préparer et migrer vos rapports. Cet outil a été développé par Microsoft pour aider les utilisateurs à effectuer la migration des rapports.rdl entre leurs serveurs SSRS et Power BI. Il est disponible sur GitHub et fournit une procédure complète pour un scénario de migration.

L’outil automatise les tâches suivantes :

  • La recherche des sources de données non prises en charge et des fonctionnalités de rapport non prises en charge.
  • La conversion de toutes les ressources partagées en ressources incorporées :
    • Les sources de données partagées deviennent des sources de données incorporées.
    • Les jeux de données partagés deviennent des jeux de données incorporés.
  • La publication des rapports qui ont été validés sous forme de rapports paginés dans un espace de travail Power BI spécifié.

L’outil ne modifie pas et ne supprime pas vos rapports existants. À l’issue de l’opération, il génère un récapitulatif de toutes les actions effectuées, réussies ou non.

Microsoft apportera probablement des améliorations à l’outil au fil du temps. La communauté est également encouragée à apporter sa contribution en vue de l’améliorer.

Étape de prémigration

Lorsque vous avez vérifié que votre organisation répond bien aux prérequis, vous pouvez passer à l’étape de prémigration. Cette étape comporte trois phases :

  1. Découvrez
  2. Évaluer
  3. Préparation

Découvrez

L’objectif de la phase de découverte est d’identifier vos instances de serveur de rapports existantes. Ce processus implique l’analyse du réseau dans le but d’identifier toutes les instances de serveur de rapports au sein de votre organisation.

Vous pouvez utiliser Microsoft Assessment and Planning Toolkit. Le « MAP Toolkit » découvre et génère des rapports sur vos instances de serveur de rapports, vos versions et vos fonctionnalités installées. Il s’agit d’un outil puissant pour l’inventaire, l’évaluation et la création de rapports, qui peut simplifier la planification de votre migration.

Les organisations peuvent avoir des centaines de rapports SQL Server Reporting Services (SSRS). Certains de ces rapports peuvent devenir obsolètes en raison d’un manque d’utilisation. L’article Rechercher et mettre hors service des rapports inutilisés peut vous aider à découvrir des rapports inutilisés et à instaurer une cadence de nettoyage.

Évaluer

Après la découverte de vos instances de serveur de rapports, l’objectif de la phase d’évaluation est de comprendre les rapports .rdl (ou les éléments de serveur) qui ne peuvent pas faire l’objet d’une migration.

Vos rapports .rdl peuvent faire l’objet d’une migration entre vos serveurs de rapports et Power BI. Après leur migration, les rapports .rdl deviennent des rapports paginés Power BI.

Toutefois, les types d’éléments de serveur de rapports suivants ne peuvent pas faire l’objet d’une migration vers Power BI :

  • Sources de données partagées et jeux de données partagés : l’outil de migration RDL convertit automatiquement les sources de données et jeux de données partagés en sources de données et jeux de données incorporés, à condition qu’ils utilisent des sources de données prises en charge.
  • Ressources telles que les fichiers image
  • Rapports liés : ceux-ci sont migrés que le rapport parent qui les lie soit sélectionné pour la migration ou non. Dans le service Power BI, il s’agit de rapports .rdl normaux.
  • Indicateurs de performance clés : Power BI Report Server ou Reporting Services 2016 ou version ultérieure, Édition Entreprise uniquement
  • Rapports mobiles : Power BI Report Server ou Reporting Services 2016 ou version ultérieure, Édition Entreprise uniquement
  • Modèles de rapport : dépréciés
  • Parties de rapport : dépréciées

Si vos rapports .rdl s’appuient sur des fonctionnalités qui ne sont pas encore prises en charge par les rapports paginés Power BI, vous pouvez envisager de les redévelopper comme des rapports Power BI, quand cela vous paraît judicieux.

Pour plus d’informations sur les sources de données prises en charge pour les rapports paginés dans le service Power BI, consultez Sources de données prises en charge pour les rapports paginés Power BI.

En général, les rapports paginés Power BI sont optimisés pour l’impression et la génération de PDF. Les rapports Power BI sont optimisés pour l’exploration et l’interactivité. Pour plus d’informations, consultez Quand utiliser des rapports paginés dans Power BI.

Le référencement de fichiers DLL de code personnalisé dans un rapport n’est pas pris en charge.

Des différences de sortie PDF se produisent le plus souvent lorsqu’une police qui ne prend pas en charge les caractères non-latins est utilisée dans un rapport et que ces caractères non-latins sont ensuite ajoutés au rapport. Vous devez contrôler la sortie de rendu PDF à la fois sur le serveur de rapports et les ordinateurs clients pour vous assurer que le rendu du rapport est conforme.

Préparation

L’objectif de la phase de préparation consiste à s’assurer que tout est prêt. Il comprend la configuration de l’environnement Power BI, la planification de la sécurisation et de la publication de vos rapports, ainsi que des idées de redéveloppement des éléments de serveur de rapports qui n’ont pas fait l’objet d’une migration.

  1. Vérifiez la prise en charge des sources de données de votre rapport et configurez une instance de Power BI Gateway pour permettre la connectivité à toutes les sources de données locales.
  2. Familiarisez-vous avec la sécurité Power BI et planifiez la reproduction de vos dossiers et de vos autorisations de serveur de rapports avec des espaces de travail Power BI.
  3. Familiarisez-vous avec le partage Power BI et planifiez la façon dont vous allez distribuer le contenu en publiant des applications Power BI.
  4. Vous pouvez utiliser des modèles sémantiques Power BI partagés à la place de vos sources de données partagées du serveur de rapports.
  5. Utilisez Power BI Desktop pour développer des rapports optimisés pour les appareils mobiles (par exemple à l’aide du visuel personnalisé Power KPI) au lieu de vos rapports mobiles et de vos indicateurs de performance clés de serveur de rapports.
  6. Réévaluez l’utilisation du champ prédéfini UserID dans vos rapports. Si vous vous fiez à UserID pour sécuriser les données des rapports, sachez que, pour les rapports paginés (lorsqu’ils sont hébergés dans le service Power BI), il retourne le nom d’utilisateur principal (UPN). Ainsi, au lieu de retourner le nom du compte NT (par exemple, AW\adelev), le champ intégré retourne un résultat du type adelev@adventureworks.com. Vous devrez réviser vos définitions de jeu de données, et éventuellement les données sources. Après révision et publication, nous vous recommandons de bien vérifier que les autorisations de données fonctionnent comme prévu dans vos rapports.
  7. Réévaluez l’utilisation du champ prédéfini ExecutionTime dans vos rapports. Pour les rapports paginés (lorsqu’ils sont hébergés dans le service Power BI), le champ prédéfini retourne la date/heure au format UTC (temps universel coordonné). Cela peut avoir un impact sur les valeurs par défaut des paramètres et les étiquettes de durée d’exécution des rapports (généralement ajoutées aux pieds de page des rapports).
  8. Si votre source de données est SQL Server (au niveau local), vérifiez que les rapports n’utilisent pas de visualisations de carte. La visualisation de carte repose sur des types de données spatiales SQL Server qui ne sont pas pris en charge par la passerelle. Pour plus d’informations, consultez l’aide sur l’extraction de données pour les rapports paginés (types de données SQL Server complexes).
  9. Pour des paramètres en cascade, n’oubliez pas que les paramètres sont évalués de manière séquentielle. Essayez d’abord de pré-agréger les données du rapport. Pour plus d’informations, voir Utiliser des paramètres en cascade dans les rapports paginés.
  10. Vérifiez que vos auteurs de rapports ont installé le Générateur de rapports Power BI et que vous pouvez facilement distribuer les versions ultérieures dans l’ensemble de votre organisation.
  11. Utilisez la documentation sur la planification de la capacité pour les rapports paginés.

Étape de migration

Une fois que vous avez préparé votre environnement et vos rapports Power BI, vous êtes prêt pour l’étape de migration.

Il existe deux types de migration : manuelle et automatisée. La migration manuelle convient pour un petit nombre de rapports ou pour des rapports nécessitant une modification avant la migration. La migration automatisée convient à la migration d’un grand nombre de rapports.

Migration manuelle

Toute personne autorisée à accéder à l’instance de serveur de rapports et à l’espace de travail Power BI peut procéder manuellement à la migration des rapports vers Power BI. Voici la procédure à suivre :

  1. Ouvrez le portail de serveur de rapports qui contient les rapports devant faire l’objet d’une migration.
  2. Téléchargez chaque définition de rapport, en enregistrant les fichiers .rdl localement.
  3. Ouvrez la dernière version du générateur de rapport Power BI et connectez-vous au service Power BI à l’aide de vos informations d’identification Microsoft Entra ID (précédemment Azure Active Directory).
  4. Ouvrez chaque rapport dans Power BI Report Builder, puis :
    1. Vérifiez que toutes les sources de données et tous les jeux de données sont incorporés dans la définition du rapport, et qu’il s’agit bien de sources de données prises en charge.
    2. Affichez un aperçu du rapport pour vérifier qu’il s’affiche correctement.
    3. Sélectionnez Publier, puis Service Power BI.
    4. Sélectionnez l’espace de travail dans lequel vous souhaitez enregistrer le rapport.
    5. Vérifiez que le rapport a bien été enregistré. Si certaines fonctionnalités de votre rapport ne sont pas encore prises en charge, l’action d’enregistrement échouera. Vous serez informé des raisons de cet échec. Vous devrez alors modifier la conception de votre rapport et retenter l’enregistrement.

Migration automatisée

Il existe trois options pour la migration automatisée. Vous pouvez utiliser :

Vous pouvez également utiliser les API Power BI Report Server, Reporting Services et Power BI disponibles publiquement pour automatiser la migration de votre contenu. Étant donné que l’outil de migration RDL utilise déjà ces API, vous pouvez développer un outil personnalisé adapté à vos besoins.

Pour plus d’informations sur les API, consultez :

Étape de post-migration

Une fois la migration terminée, vous pouvez passer à l’étape de post-migration. Cette étape implique l’utilisation d’une série de tâches de post-migration visant à garantir que tout fonctionne correctement et efficacement.

Définition du délai d’expiration des requêtes pour les jeux de données incorporés

Vous spécifiez les valeurs de délai d’attente des requêtes pendant la création du rapport, lorsque vous définissez un jeu de données incorporé. La valeur de délai d’attente est conservée avec le rapport, dans l’élément Timeout de la définition de rapport.

Configurer des sources de données

Une fois la migration des rapports vers Power BI terminée, vous devez vérifier que leurs sources de données sont correctement configurées. Cela peut impliquer l’affectation à des sources de données de passerelle, ainsi que le stockage sécurisé des informations d’identification de la source de données. Ces actions ne sont pas effectuées par l’outil de migration RDL.

Examiner les performances du rapport

Nous vous recommandons vivement d’effectuer les actions suivantes pour garantir la meilleure expérience possible aux utilisateurs des rapports :

  1. Testez les rapports dans chaque navigateur pris en charge par Power BI pour vérifier que le rendu du rapport est correct.
  2. Exécutez des tests pour comparer les temps de rendu des rapports sur le serveur de rapports et dans le service Power BI. Vérifiez que les rapports Power BI s’affichent dans un délai acceptable.
  3. Pour les rapports qui sont longs à s’afficher, vous pouvez demander à Power BI de les envoyer aux utilisateurs de votre rapport sous la forme d’abonnements e-mail dans lesquels les rapports sont ajoutés en pièces jointes.
  4. Pour les rapports Power BI basés sur des modèles sémantiques Power BI, vérifiez les conceptions des modèles pour être sûr qu’elles sont entièrement optimisées.

Résoudre les problèmes

La phase de post-migration est essentielle pour résoudre les problèmes, notamment au niveau des performances. L’ajout de la charge de travail Rapports paginés à une capacité peut contribuer à ralentir les performances des rapports paginés et des autres types de contenu stockés dans la capacité.

Contenu connexe

Pour plus d’informations sur cet article, consultez les ressources suivantes :

Les partenaires Power BI sont là pour aider votre organisation dans son processus de migration. Pour contacter un partenaire Power BI, accédez au portail des partenaires Power BI.