Les extensions SYNTELL pour pallier à un irritant majeur avec Reporting Services

Chez SYNTELL inc., l’approche utilisée pour nos tableaux de bord est de permettre à l’utilisateur de faire plusieurs changements de valeurs dans les paramètres et de ne lancer la génération qu’une fois qu’il applique ses changements en cliquant sur un bouton.

Un des problèmees avec Reporting Services, c’est qu’à chaque changement de paramètre, il y a un délai de 1 à 4 secondes pour rafraîchir la zone des paramètres.

Ce serait acceptable pour les cas où une sélection (ex. catégorie), impacte la liste des valeurs acceptées par un autre paramètre (ex. sous-catégorie). Mais pas lorsque le paramètre n’a pas d’impact sur les autres.

Comme je le disais dans une entrée précédente, Reporting Services ne fait pas de magie pour détecter la dépendance entre les paramètres d’un rapport.

Lorsque vos rapports sont basés sur une source SQL et que vous utilisez la mécanique @paramname au sein de votre énoncé SQL, il est capable de détecter automatiquement les dépendances.

Mais dès que votre source de données est Analysis Services (SSAS) et que les paramètres sont alimentés par un énoncé MDX construit dynamiquement via une expression, SSRS ne peut pas comprendre les dépendances.

En utilisant le service Web ReportService2006.ReportingService2006 il est possible d’obtenir la définition complète des paramètres via la méthode GetReportParameters. Et c’est à ce moment qu’on se rend compte qu’il place tous les paramètres précédents comme dépendance, ce qui est faux 99% du temps.

Microsoft aurait dû nous offrir une manière de définir les dépendances entre paramètres de manière explicite. Cela aurait permis d’optimiser le rafraîchissement de la zone des paramètres. et ainsi améliorer considérablement l’expérience utilisateur.

SYNTELL inc. vient compléter l’offre de Microsoft en offrant des extensions qui permettent d’ajouter des fonctionnalités ou augmenter la productivité des utilisateurs.

C’est ainsi que nous avons développé un gestionnaire de dépendances explicites. Celui-ci stocke l’information en JSON dans les “Custom Properties” du rapport ce qui est tout à fait légal selon la norme RDL. Notre feature SharePoint va dynamiquement modifier la page HTML généré par Reporting Services afin de rafraîchir la zone des paramètres uniquement lorsque c’est nécessaire.

image

Aussi, une option au niveau du site SharePoint permet de conserver le rapport affiché lors d’un changement de paramètre plutôt que de remplacer celui-ci par:

image

Puisque nos tableaux de bord affichent toujours la sélection courante (pratique pour l’impression), l’utilisateur voit bien pour quelles valeurs de paramètres ont été appliquées aux données.

De plus, nos applications mobiles peuvent profiter de cette information stockée à même les RDLs des rapports afin d’offrir une intelligence similaire à l’utilisateur lors de la saisie de paramètres.

Et vous, est-ce que cet irritant de Reporting Services vous cause problèmes auprès de vos utilisateurs?

Publicités

Présentation de notre outil de déploiement de rapports SSRS

Cet article fait suite aux précédents qui traitent de nos extensions à la plate-forme BI de Microsoft.

Description

Cette fois-ci, il s’agit d’un outil hybride (mode console et mode graphique) qui permet de déployer un projet de rapports vers un portail SharePoint sans avoir à utiliser BIDS (Microsoft Business Intelligence Development Studio).

L’outil s’appelle Syntell SSRS SharePoint Deployment Tool et en voici un aperçu:

image

image

clip_image002

Raison d’être

Mais pourquoi développer un outil?

  1. Parce BIDS n’est pas toujours installé dans l’environnement de destination (ex. Production) et que le développeur ne peut déployer à partir de son poste.
  2. Si l’outil Syntell Report Builder a été utilisé pour développer les rapports, il faut déployer les rapports avec celui-ci ou avec Syntell SSRS SharePoint Deployment Tool afin de profiter de ses fonctionnalités (ex. configuration, extensions SWS-RS etc.)
  3. Si le déploiement est effectué par un pilote de système, celui-ci préfère peut-être intégrer le déploiement des rapports dans un script existant (*.bat, PowerShell etc).
  4. Lorsqu’on redéploie un rapport dans SharePoint avec un changement au niveau des paramètres, il y a parfois des problèmes (ex. le type ne change pas). L’idéal c’est de le détruire avant.
  5. Parce qu’il y a d’autres problématiques reliées au déploiement de rapports. Par exemple, on veut peut-être désactiver le site SharePoint pendant le déploiement de ceux-ci ou même lorsque la chaîne ETL s’exécute.
  6. La gestion des chaînes de connexion (une fois les rapports déployés) peut devenir complexe. Avec une hiérarchie de sites avec chacun une série de connexions à configurer, il peut être facile d’en oublier.

Ce sont là les raisons principales qui ont poussé Syntell à développer un tel outil. Celui-ci est pertinent que Report Builder soit utilisé ou non: il fonctionne avec un projet SSRS vanille.

Utilisateurs

Ainsi, Syntell peut l’offir à ses clients qui ont choisi Reporting Services mais sans les extensions runtime. Plutôt que d’avoir à créer leur propre solution pour le déploiement, ceux-ci peuvent directement utiliser un outil qui a fait ses preuves.

Pour les clients qui utilisent les extensions runtime et design time, cet outil de déploiement doit être utilisé lorsque BIDS avec Report Builder ne peut être utilisé lors du déploiement.

Chez Syntell, on l’utilise pour publier des rapports là où BIDS ou la dernière version de ReportBuilder ne sont pas disponibles. Comme le programme ne nécessite pas d’installation (XCOPY Deployment), il peut être exécuté directement à partir du réseau, d’une clé USB etc.

Fonctionnalités supplémentaires

Une fois l’outil disponible et intégré au processus de développement, il devient possible de lui ajouter des fonctionnalités supplémentaires de type “nice to have”.

C’est pourquoi l’outil permet de désactiver les rapports lors d’une mise à jour une d’une production ETL (exige nos extensions runtime). Ainsi, une personne qui saisit l’hyperlien vers le rapport verra apparaître un message significatif plutôt que de recevoir un message d’erreur sur la connexion. Cette fonctionnalité doit se faire à partir de la ligne de commande

SynSPDeploy /DeactivateSiteSSRS /SiteUrl http://server/site /RedirectUrl http://server/site/NotAvailable.aspx /ExemptedUsers domain\user1,domain\user2

SynSPDeploy /ActivateSiteSSRS /SiteUrl http://server/site

Aussi, l’outil a intégré un gestionnaire de connexions. Il reproduit la même interface graphique que la version Web mais permet de facilement lister les sites SharePoint avec des connexions SSRS d’une collection de sites.

image

image

Il permet aussi de produire des rapports ce qui permet en un coup d’oeil de vérifier s’il n’y a pas d’oubli:

image

image

image

image

Le gestionnaire de connexion permet aussi de naviguer vers l’objet sélectionné :

  1. Collection de sites
  2. Site SharePoint
  3. Librairie de connexions
  4. Connexion SSRS

clip_image002[1]

Conclusion

L’outil a vu le jour suite à une demande d’un client qui cherchait une solution pour déployer ses rapports dans son environnement de production sans avoir à utiliser BIDS. Comme il n’y avait aucune solution tierce partie acceptable de disponible (Microsoft propose un script C# qu’il faut modifier à chaque fois qu’on ajoute un rapport, une connexion ou une image …), Syntell a développé l’outil.

Avec le temps l’outil a évolué pour proposer plus d’options et même inclure des fonctionnalités connexes.

Si vous avez des questions sur Syntell ou sur nos outils, n’hésitez pas à me contacter.

Nos extensions SSRS design-time et runtime

Syntell existe depuis 1987 et a développée sa propre plate-forme BI  afin de pouvoir livrer des solutions appropriées à ses clients. Cette recette a bien fonctionnée et plusieurs de nos clients utilisent toujours notre plate-forme propriétaire (Axa, Alcan, Hydro Québec etc.).

Cependant, de plus en plus de clients (existants ou potentiels) veulent utiliser une plate-forme grand public (ex. Microsoft) tout en faisant affaire avec Syntell afin de profiter de notre expertise en BI.

La plate-forme qui s’est révélée la plus appropriée pour la réalisation de nos mandats est Microsoft SQL Server 2008. Celle-ci possède un engin de données (tables relationnelles), un serveur de cube (Analysis Services ou SSAS), un engin ETL (Integration Services ou SSIS) et un serveur de présentation (Reporting Services ou SSRS).

C’est de ce dernier qu’il est question dans cette entrée de blogue. Il faut comprendre que Syntell fait bien plus que de modéliser, valider, charger, optimiser les données pour ensuite les visualiser via une collection de rapports SSRS.

Nos tableaux de bord forment une application en soi où le contexte est maintenu d’un rapport à l’autre. Il ne s’agit pas d’avoir un rapport par indicateur et de les regarder un par un. Nous avons plutôt une approche (décrite brièvement ici) où le tableau de bord est une vue de haut niveau avec des alarmes. Celui-ci mêne à des analyses optimisées pour faire ressortir les cas intéressants selon l’indicateur (ex. temps supplémentaire). Ces analyses mènent vers des listes détaillée permettant d’obtenir la liste d’employés, produits, régions etc. qui ont créée cette situation hors norme. Le tout est accompagné par des analyses génériques (ex. top 10, analyse des variations etc.)

Nous avons développé des techniques permettant de produire des rapports techniquement complexes: choix de visions, de croisements et d’indicateurs qui affectent plusieurs zones de données (grilles ou graphiques). Cela évite d’avoir une prolifération de rapports et tout les efforts que cela implique au niveau de la maintenance. Pour plus de détails, voir mon entrée SSRS – Le nerf de la guerre c’est le contrôle de la requête.

La complexité technique pour mettre en place de telles solutions est plutôt élevée. Auparavant nous avions notre propre plate-forme BI et celle-ci avait été développée dans l’optique de créer ce type d’application. Reporting Services est une plate-forme exceptionnelle, développée par une équipe de 100+ personne et elle est plutôt facile à apprendre.

Cependant, pour développer le type de solutions que Syntell est habituée de livrer, Reporting Services a beaucoup de lacunes design-time et runtime.

Design-time

  1. Peu de réutilisation d’objets possible (ex. paramètres, variables, VB.Net etc.). Note: SQL Server 2008 R2 permet de définir des Shared Datasets.
  2. Impossible de mettre une expression pour le libellé des paramètres. Cela empêche la traduction complète des rapports.
  3. L’ordre des paramètres est déterminée par les dépendances entre ceux-ci.
  4. Pas d’assistance pour comparer des objets qui sont sensés être les même d’un rapport à l’autre (ex. fonction VB.Net, paramètre, Dataset etc.)
  5. La définition des actions avec beaucoup de paramètres est fastidieuse. Exemple, si le rapport de destination contient 20 paramètres et que la plupart portent le même nom que ceux du rapport courant il faut quand même tout saisir manuellement. Pas de copier / coller (sauf en allant dans le Xml).
  6. Le déploiement vers plusieurs sites SharePoint (ex. Français et Anglais) doit se faire en autant d’étapes qu’il n’y a de langues.
  7. Pas moyen d’effectuer une configuration spécifique lors du déploiement d’un rapport. Par exemple, supposons qu’une application comporte plusieurs modules et qu’un client ne le prend pas tous, comment déployer les rapports afin de réfléter l’absence de certains modules?

Runtime

  1. Impossible de formater les paramètres (libellé et liste).
  2. Pas de boutons radio pour les paramètres.
  3. Pas d’effet “rollover” sur les grilles. Cet effet est désirable pour regarder la valeur des différentes cellules sur la même ligne.
  4. Pas de contrôle de navigation (ex. menus déroulants).

Les limitations runtime ont été jugées inacceptable par nos concepteurs de produits tandis que la portion design-time relevait surtout du besoin d’obtenir des gains de productivité. Mais une fois qu’on a un outil design-time entre les main, cela ouvre un monde de possibilités.

C’est ainsi que sont né Syntell SSRS Report Builder et Syntell Client Side Extensions (SWS-RS).

Le premier est un add-in à Visual Studio et permet de pallier aux différentes lacunes de Business Intelligence Development Studio (BIDS). Avec le temps, l’outil a ajouté des fonctionnalités permettant la configuration de rapport (ex. via du code C#) sur demande ou lors du déploiement des rapports. Il permet aussi de configurer les paramètres spécifiques à nos extensions runtime.

image

clip_image002

Ce qu’il faut comprendre c’est que cet outil peut être utilisé même si les extensions runtime ne sont pas installées. Le RDL qu’il génère est compatible avec BIDS.

Notre produit runtime prend la forme d’une “feature SharePoint” (WSP) qui peut être activée site par site. Elle permet de faire des choses qui sont impossibles à priori avec la plate-forme de Microsoft.

Par exemple, réordonner et formatter les paramètres, créer des menus de navigation évolués, ajouter un effet “rollover” sur les grilles etc. Elle fonctionne en injectant du JavaScript dans la page afin d’apporter des transformations dynamiques.

Par exemple, un tablix affiché ainsi par SSRS vanille:

clip_image002[4]

Devient ceci via notre transformation de navigation:

clip_image002[6]

Bref, quand vient le temps de réaliser un projet sur la plate-forme de Microsoft, Syntell a des outils qui lui permet de livrer la solution plus rapidement (productivité) et même d’ajouter des fonctionnalités importantes qui ne sont pas offertes directement. Le menu de navigation est un ajout significatif et permet de transformer une série de rapports en une application intégrée.

Si vous avez des questions sur Syntell ou sur nos outils, n’hésitez pas à me contacter.

Présentation de notre outil de test automatisé pour Reporting Services

Tel que promis, voici donc une présentation visuelle de notre outil nommé Syntell QA SQL Server Tester.

Tout d’abord, voici le modèle de données (vision de haut niveau):

image

Bref, un jeu d’essai définit une liste d’hyperliens vers des rapports SSRS. Ceux-ci peuvent provenir d’un ou plusieurs sites SharePoint et être exécutés avec des valeurs spécifiques pour les paramètres.

Lorsqu’on exécute un test, c’est au niveau d’une instance de jeu d’essai. On peut utiliser notre identité Windows ou bien configurer l’instance de manière à utiliser un autre utilisateur.

Une fois l’outil démarré il faut créer une base de données servant à héberger les tables utilisées par l’outil.

image

Il suffit d’entrer le nom de la base de données à créer et l’outil fait le reste.

L’application permet de saisir plusieurs comptes utilisateurs avec lesquels on voudra éventuellement faire des tests. Ces informations sont stockées encryptées dans la base de données (via un mot de passe défini par l’utilisateur et choisi lors de la connexion à la base de données).

image

Il suffit ensuite de créer un jeu d’essai. La manière la plus simple d’ajouter des urls à celui-ci est de les importer directement à partir des journaux de SSRS. Cette journalisation est activée par défaut et elle est stockée dans le base de données choisie lors de la configuration de SSRS (ex. ReportServer). Bref, il suffit de naviguer sur les bons rapports, avec les bons paramètres puis d’utiliser l’outil pour importer!

image

L’outil permet de filtrer par utilisateur, date et contenu. Il est possible de vérifier chacun des liens avant l’import.

Pour exécuter un jeu d’essai, il faut d’abord créer une instance de jeu d’essai et optionnellement entrer de l’information sur l’environnement de test (versions, spécifications matérielles etc.).

image

Même si les hyperliens ont été importés sur le serveur X, il est possible d’effectuer des substitution dynamiques afin de lancer le test ailleurs. Cela pourrait être utilisé à d’autres fins.

image

La console d’exécution permet de choisir l’identité avec laquelle le test doit s’exécuter, déterminer si on doit stocker le résultat ou non et même choisir un délai entre chaque exécution ou un nombre de threads à utiliser pour profiter des tous les cores du serveur!

En tout temps, le statut de l’exécution précédente s’affiche (succès ou échec) et les seuils configurables permettent de colorer la cellule indiquant la durée.

Chaque rapport est exécuté trois fois, une par format: MHTML, TIFF et XML.

image

image

image

image

En cas d’erreur, c’est plutôt le détail de l’exception qui est stocké.

image

Finalement, le programme est une application de type Console qui affiche l’interface graphique uniquement lorsqu’il n’y a aucun paramètre sur la ligne de commande.

Il peut donc être lancé par un script ou par le Windows Task Scheduler. Un fichier XML permet de définir les paramètres du test et indiquer quelle(s) instance(s) de jeu d’essai doivent être lancée(s).

image

Il reste plusieurs volets à développer dans cet outil mais ceci forme la base et permet d’automatiser les tests d’intégrité et même de réaliser une certaine forme de test de charge / performance.

Si vous avez des questions sur Syntell ou sur nos outils, n’hésitez pas à me contacter.

Pourquoi nous avons développé un outil de test automatisé pour Reporting Services

Cet article est le premier d’une série visant à présenter les différents outils développés par Syntell inc. afin d’augmenter notre productivité lors de la réalisation de projets BI sous la plate-forme de Microsoft.

Nous avions besoin d’un outil pour réaliser différents types de test sur la plate-forme Microsoft Reporting Services (SSRS):

  • D’intégrité
    Il n’y a pas d’erreurs lors de l’exécution d’un rapport
  • De non régression
    Ce qui fonctionnait fonctionne toujours (test comparatif)
  • De performance
    Permet d’identifier les rapports trop lents
  • Sécurité applicative et personnalisation
    Chaque utilisateur peut voir quelque chose de différent

Avant d’envisager le développement d’une solution maison, nous avons d’abord demandé à notre ami Google si cela n’existait pas déjà:

SSRS Automated Testing
http://consultingblogs.emc.com/stevewright/archive/2009/08/27/unit-testing-report-within-reporting-services-my-theory.aspx

SSRS unit testing suite
http://rsunit.codeplex.com/
http://www.innosphere.ca/Products/SSRSUnitTestingSuite/tabid/110/Default.aspx

Unit Testing SSRS Reports
http://colinramsay.co.uk/diary/2008/03/12/unit-testing-ssrs-reports/

Reporting Services unit testing
http://andrewbutenko.wordpress.com/2009/08/04/reporting-services-2008-unit-testing/

Les solutions présentées par ces différents blogues ne nous convenaient pas pour plusieurs raisons. Voici les principales:

  1. Les rapports que nous développons sont complexes, ont plusieurs paramètres et forment une application où le contexte est maintenu d’un rapport à l’autre.La création d’un jeu d’essai devait donc pouvoir être réalisée simplement en naviguant dans les rapports et en choisissant les bons paramètres (import à partir des journaux (logs) de Reporting Services.Comme il y a un grand nombre de paramètres, les rapports doivent être lancés en HTTP POST et non en HTTP GET. Lors d’une erreur, le détail n’est pas retourné en mode HTTP POST, l’outil doit donc utiliser les services Web d’exécution de rapport afin d’obtenir le détail de ce qui a échoué.
  2. L’intégration à Visual Studio ne faisait pas de sens pour nous car nous modifions fortement les rapports lors du déploiement (via un outil de déploiement permettant l’application d’une configuration propre à un client).Ce que nous voulons tester c’est le rapport tel que déployé dans SharePoint.
  3. L’outil doit pouvoir tester les performance et la charge. Il doit donc pouvoir lancer plusieurs rapports en parallèle (multithreading).
  4. Après l’exécution d’un jeu d’essai, le QA doit pouvoir consulter le statut de l’exécution de chaque rapport (succès/échec, date et heure, durée de l’exécution avec seuils pour alarmes) ainsi que de voir le résultat (MHTML, TIFF et XML) ou le message d’erreur.
  5. Afin de tester la sécurité applicative ou la personalisation de nos rapports, il faut que l’outil puisse lancer les rapports sous une autre identité configurable …
  6. L’outil doit pouvoir être lancé sur la ligne de commande afin d’automatiser des tests ou réchauffer un serveur avant une démonstration (programme hybride Console / Windows Forms).

Comme les solutions proposées ne pouvaient pas répondre à ces exigences, nous avons développé un outil en .NET 4.0 et LINQ to SQL.

Les cas d’utilisation (use case) principaux étaient les suivants:

Besoin Fonctionnalité de l’outil
Vérifier qu’aucun rapport ne retourne d’erreur  Visualisation du statut de chaque exécution
S’assurer qu’aucun rapport n’est trop lent  Seuils configurables pour mettre en évidence les exécutions plus lentes (2 seuils)
Réchauffer un serveur SSRS avant de faire une démonstration Le programme peut s’exécuter en mode console et prendre ses paramètres dans un fichier XML
Voir comment un serveur réagit à la charge Il y a un mode multithread permettant de bombarder un serveur avec une seule instance du programme.
Utiliser une identité spécifique pour exécuter les rapports L’outil permet de stocker l’information de connexion de plusieurs utilisateurs de manière sécuritaire dans la base de données et de les associer à une instance de jeu d’essai.
Exécuter un jeu d’essai sur un autre serveur que celui où le jeu d’essai a été créé / importé Fonctionnalité de recherche / remplacement dynamique pour les instances de jeu d’essai.
Importer les hyperliens à partir des journaux natifs de SSRS La boîte de dialogue d’import permet de filtrer par utilisateur, date, et texte de l’hyperlien. Définir un jeu d’essai est aussi simple que de naviguer sur l’application SSRS puis importer les hyperliens avec la fonction d’import.
Créer une base de données pour héberger des tests individuels L’outils a une fonction pour créer automatiquement la base de données SQL Server et le schéma. Le processus est le même que pour l’ouverture d’une base de données existante à l’exception près qu’il faut taper le nom de la base de données à créer.
Visualiser le résultat d’une exécution précédente dans différents formats Si l’option pour stocker les résultat est activée, l’outil sauvegarde (et permet de visualiser) les rapports en MHTML, TIFF et XML.

Mon prochain article vous présentera l’outil de manière plus visuelle mais voici toujours une capture d’écran:

clip_image001

Si vous avez des questions sur Syntell ou sur nos outils, n’hésitez pas à me contacter.