Power BI & HADR 2/2 - S'assurer une haute disponibilité des rapports clés via les API Power BI et SQL Database

Assurer la haute disponiblité des rapports Power BI

Suite à notre première partie concernant la reprise d'activité sur Power BI, l'idée de cet article est de proposer une méthode pour rendre les rapports Power BI disponibles au maximum pour les utilisateurs clé de l'entreprise. Deux situations s'offrent à nous : un rapport en Direct Query ou Live Connection, sur une base qui aurait subit un dommage, une corruption ou une mise à jour négligée. L'autre situation concerne un rapport sur un dataset en mode Import, lui aussi corrompu ou ayant subit une regression.

Changer la datasource d'un rapport Power BI via API :

Pour illustrer mon propos, je vais déployer un rapport connecté à une base hébergée sur Azure SQL Database, qui, lors du déploiement d'une nouvelle version, verra une table clé du modèle disparaître. L'idée est alors d'être capable de redéployer cette base au plus vite, et de changer la datasource du raport vers la nouvelle base.

Voici l'état de notre rapport avant notre simulation :

Une regression est déployée pa erreur sur le modèle, mais les analyses ne peuvent pas être arrêtées. Voici le rapport en l'état :

Côté Azure :

Nous allons alors redéployer la base SQL via API, grâce aux point in time restore : pour y arriver, il sera nécessaire de définir au sein de la souscription le nouveau nom de la base de données de bascule. Via l'API suivante, on peut alors restaurer la base : Restore a database from a backup - Azure SQL Database & SQL Managed Instance | Microsoft Docs

Côté Power BI :

Dans un article écrit au début de l'année, j'avais détaillé la logique permettant de s'authentifier, d'identifier le dataset et ses datasources, et ainsi d'être capable de mettre à jour ces informations par API. La logique sera ici la même : par API toujours, nous allons mettre à jour la datasource du dataset :

Une fois la datasource mise à jour, il faudra renseigner les credentials, toujours par API :

Maintenant, le rapport pointe alors vers la nouvelle base de données. On peut à nouveau consulter le rapport, pendant que le bug est résolu :

Cette méthode, basée sur les API SQL Database et Power BI, nous donne une manière de réduire grandement le downtime d'un rapport, et ainsi assurer la continuité du service.

Changer le dataset sur lequel un rapport Power BI se source via API :

L'idée cette fois ci est de changer la source du rapport lui même. Notre situation est la suivante : un développeur a cette fois-ci déployé non pas une erreur dans la base de données source, mais directement dans le Dataset Power BI. Les rapports, eux sont restés tels que.

Comme vu dans la première partie de l'article, nous procédons alors à la restauration du dataset :

On observe dans le workspace l'apparition du nouveau Dataset :

Via API, on va relier le rapport au nouveau Dataset, le temps de corriger le dataset KO : Reports - Rebind Report - REST API (Power BI Power BI REST APIs) | Microsoft Docs

A nouveau, le rapport est disponible, les utilisateurs clés peuvent continuer leurs analyses, et le temps d'indisponibilité du service est grandement diminué. Par ce biais, le Recovery Time Objective est inférieur à la minute.