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?

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s