Je vous fais part d’un article qui m’a grandement aidé dans l’implémentation de calculs sur les dimensions temps dans SSAS 2005:
http://www.obs3.com/A%20Different%20Approach%20to%20Time%20Calculations%20in%20SSAS.pdf
La base et la solution permettant de voir la mise en oeuvre des exemples décrits dans le pdf se trouvent ici:
http://www.obs3.com/TimeCalculations.zip
SSIS offre la possibilité de variabiliser et de rendre dynamique les éléments d’un package par le biais d’un fichier de configuration (menu SSIS > configuration du package) :
Or le nom et l’emplacement du fichier de configuration sont stockés en dur dans le code xml du fichier dtsx du lot en question:
Ceci est souvent problématique lorsque les architectures physiques diffèrent entre un serveur de développement et un serveur de production par exemple ; obligeant généralement à conserver les même emplacements physiques de stockage des packages et des fichiers de configuration sur ces deux environnements.
Néanmoins, une autre solution existe pour spécifier l’emplacement du fichier de configuration. Il s’agit de la configuration indirecte.
Elle nécessite de créer une variable d’environnement ayant pour rôle de stocker la chaine de connexion au fichier de configuration:
Il suffit ensuite de fournir le nom de cette variable dans le gestionnaire de configuration du package:
La gestion des emplacements est ainsi centralisée au niveau des variables d’environnement.
L’utilisation de cette méthode est notamment fortement conseillée lorsque plusieurs packages se reposent sur un même fichier de configuration.
Intégrer des rapports SSRS dans MOSS ou WSS, c’est facile… Interroger du contenu Sharepoint depuis un rapport SSRS, c’est une autre histoire. Etrange d’ailleurs que MS ne propose pas de connecteur permettant de le faire nativement.
Le truc consiste donc à interroger les webservices mis à disposition par Sharepoint pour arriver au résultat escompté.
Voici donc la marche à suivre:
Dans les informations d’identifications, seules les options utiliser l’authentification Windows et Ne pas demander les informations d’identification sont utilisables. Il convient donc de s’assurer que l’utilisateur qui exécute le rapport dispose des droits nécessaires pour interroger le contenu Sharepoint.
Voyons en premier lieu comment créer un dataset basé sur cette source de données qui interroge la méthode GetListCollection. Cette dernière permet de lister les bibliothèques de documents disponibles.
<Query> <Method Namespace=”http://schemas.microsoft.com/sharepoint/soap” Name=”GetListCollection” /></Query>
Pour obtenir le détail du contenu d’une de ces listes, c’est la méthode GetListItems qu’il faut interroger. Celle-ci prend en entrée les paramètres listName (guid ou nom d’une liste) et viewName (guid d’une vue, vue par défaut si null). <Query> <Method Namespace=”http://schemas.microsoft.com/sharepoint/soap/” Name=”GetListItems”/><SoapAction>http://schemas.microsoft.com/sharepoint/soap/GetListItems</SoapAction> <Parameters> <Parameter Name=”listName”> <DefaultValue>/</DefaultValue> </Parameter> <Parameter Name=”viewName”> <DefaultValue>/</DefaultValue> </Parameter> </Parameters></Query>Ne pas oublier de créer les deux paramètres correspondant dans le dataset. Si ceux-ci n’existent pas, la requête ne fonctionnera pas.
On peut maintenant tester l’exécution de la requête. On commence par renseigner les valeurs des paramètres.
Et voilà le résultat!
Une question qui revient souvent sur SSRS: comment utiliser des formules différentes dans les lignes de détail et le total d’une matrice ? La réponse se trouve dans l’utilisation de la fonction InScope().
Lors de l’utilisation du bouton d’impression intégré au portail Reporting Services, certains d’entre vous ont peut être eu la désagréable surprise d’obtenir un écran bleu et de devoir rebooter la machine.
Microsoft a sorti un pach qui permet de résoudre ce bug:
http://support.microsoft.com/Default.aspx?kbid=935843
Je vous fais part d’un bug que j’avais constaté chez un client le mois dernier: dans un rapport prenant en entrée un paramètre de type date:
- Aucun souci lorsque l’on consulte celui-ci via le portail RS.
- En utilisant la WebPart “visionneuse de rapport” pour SharePoint, le sélecteur de date renvoyait toujours une date au format US, forçant l’utilisateur à modifier celle-ci manuellement 
Pour faire simple, cela fonctionnait lorsque l’on passait par le répertoire virtuel “Reports” pour attaquer le rapport. Par contre, bug sur le format de date en passant par “ReportServer”.
Et bien, bonne nouvelle, le dernier correctif apporté à SQL Server 2005 résout ce bug:
http://support.microsoft.com/?kbid=936305 
Il n’est pas téléchargeable directement, vous devez passer par le support pour l’obtenir.
Un article très intéressant de nos collègues australiens de chez SSW qui regroupe un ensemble de bonnes pratiques relatives à l’utilisation de Reporting Services 2005: http://www.ssw.com.au/ssw/Standards/Rules/RulesToBetterSQLReportingServices.aspx
Le query designer du Bex permet d’obtenir une hiérarchie de présentation lors de la génération des résultats d’une query:
Le code MDX généré par Reporting Services ne permet pas d’obtenir directement ce type de présentation. Dans ce cas de figure, il faut donc parfois effectuer 2 requêtes:
Dans le query designer du Bex, il est possible de définir des conditions sur des requêtes BW :
Or, le connecteur SAP Reporting Services ne rapatrie pas ce type d’information. Un filtre doit donc être positionné directement au niveau du dataset attaquant la query afin de renvoyer un jeu de données correct :
Le query designer du Bex permet de spécifier une inversion des signes sur les ratios.
Or cette propriété n’est pas récupérée par le connecteur Reporting Services pour SAP BW.
Afin que votre rapport renvoie les même données que la query BW, il faut donc, pour chaque ratio concerné, créer un nouveau champ calculé dans votre dataset RS ayant pour valeur l’inverse de la mesure en question.
Autre possibilité, inverser le signe de l’indicateur lors de chaque appel à celui-ci dans le rapport. C’est vous qui voyez!
