Quelle utilité me direz-vous?

Nous nous sommes posé la question lorsqu'un de nos clients a voulu lancer des mises à jour du DataWarehouse selon son grès. En effet, le client avait notamment besoin lors des périodes comptables, de faire de fréquentes mises à jour du DataWarehouse depuis ses bases SAP, afin d'intégrer les nouvelles écritures.

La solution dans notre cas, présentée ci-dessous, est envisageable car le remplissage SSIS du DataWarehouse est de très courte durée(de l'ordre de la minute). Les bases de données sources SAP et celles du Datawarehouse sont peu sollicitées, l'utilisateur lambda n'y voit que du feu. 

Fini les nombreux appels téléphoniques, afin de mettre à jour le DataWarehouse!

Première étape, il faut créer un job sur SQL SERVER afin de planifier le lancement du paquet SSIS de remplissage du DataWarehouse. Je ne m'étendrai pas sur la création d'un job exécutant un paquet SSIS qui fait l'objet d'un autre billet.

Une fois le job créé, que je nommerai dans notre exemple «DWRemplissage FR», je développe une procédure stockée sur le DataWarehouse, ici nommée «Update_bdd_reporting_FR», qui fait appel à ce job comme suit:

Maintenant la dernière étape consiste à créer un report qui, au niveau des données, appelle la procédure stockée «Update_bdd_reporting_FR» précédemment créée, puis de publier le report sur le portail web.

Il faut bien sûr restreindre l'accès à ce report, aux personnes susceptibles de lancer la procédure stockée.

C'est tout pour aujourd'hui!

Pour un tableau simple sans regroupements, c est très simple, il suffit de sélectionner la ligne de détail du tableau, et mettre dans la propriété BackgroudColor le code suivant:

=iif(RowNumber(Nothing) mod 2, « couleur1 », « couleur2 » )

Le résultat en image:

Sur ce billet, je vais vous présenter l'outil « Reporting Services Scripter », développé en .NET Windows Forms, qui permet entre autre de récupérer tous les fichiers .rdl, les sources de données et les rôles d'un serveur de reports. Il permet aussi de les déployer sur un autre serveur. 

Cet outil, développé par Jasper Smith, est compatible SQL SERVER 2000, 2005,2008, sur les plateformes Windows 2000, XP, Vista, Windows Server 2003 et 2008. Le programme nécessite l'installation du framework .NET 1.1.

Fini la perte de temps, à déployer un par un les reports et à rattacher la bonne source de données sur chacun d'entre eux. Une fois l'archive décompressée, éditer le fichier servers.xml, et ajouter l'url du webservice du serveur de reports source et du serveur de destination comme suit: 

Sauvegarder et fermer le fichier de configuration XML.

Lancer l'application RSScripter.exe, cliquer sur le bouton OPTIONS, dans l'onglet GLOBAL sélectionner « Sript Only » (pour récupérer les fichiers en local) ou « Script and Transfer » (pour récupérer les fichiers d'un serveur et les transférer sur un autre).  

Sélectionner le répertoire de destination dans Output en bas de la fenêtre.

Sélectionner le serveur de rapport source et cliquer sur le bouton Get Catalog.

Choisir les éléments à récupérer, ici j'ai des fichiers .rdl, une source de données et les roles du serveur de report puis cliquer sur le bouton Script. Et voilà, en quelques clics, on peut récupérer l'ensemble des reports d'un serveur.

Dans le cas où vous transférez les reports vers un serveur de destination, il est conseillé de faire une sauvegarde des bases de données ReportServer et ReportServerTempDb.

Pour de plus amples informations je vous invite à visiter le site du développeur :

http://www.sqldbatips.com/showarticle.asp?ID=62

Il peut arriver que lors de l'export Excel d'un report, on ait des colonnes supplémentaires « parasites », ceci est dû à la position d'une zone de texte qui fait office de titre au dessus du tableau comme le montre l'image suivante:

Pour éviter ce problème, il faut ajouter une ligne d'entête au tableau et fusionner les cellules comme suit:   

Et voici le résultat en image, terminé les colonnes parasites!