Ça ressemble un peu au manuel d’installation de Datastage d’IBM également, non? 🙂
Page 63 of 65
Un outil pour les développeurs web : le générateur de CSS3
Il est vrai qu’en BI, on n’a pas souvent à faire du CSS. Mais quand on doit, autant utiliser les outils les plus simples, non?.
Bin avec ce générateur de CSS3 en ligne, ça va être difficile de faire plus simple!
Update 06/09/2010 :
On m’informe dans l’oreillette qu’il en existe bien d’autres, dont les meilleurs sont ci-dessous. Par contre je n’ai testé que le CSS3 Generator, je ne sais donc pas ce que ceux là valent. La liste:
- CSS3 maker
- Allez voir les toolbox, c’est pas mal : CSS3 sandbox
- CSS3 please
- Et toujours : CSS3 generator
4 liens rapides pour la semaine (2010-36)
Je vais me la jouer Radar et vous donner 4 liens à aller visiter pour la semaine à venir.
- Le PowerPoint de présentation de la culture d’entreprise chez Netflix, par son CEO Reed Hasting. C’est moche, y’a de la pub, mais c’est un incontournable.
- Un article un peu plus léger, par Dan Shapiro, sur les valeurs d’entreprise. C’est acide, j’aime bien!
- La différence entre ceux qui parlent et ceux qui font, par J.D. Roth, de Get Rich Slowly. C’est un peu en dehors de ses sujets habituels, mais c’est très bon.
- Et après les pavés, le management des conflits en un paragraphe chez 37 Signals. Pour rappel, c’est l’équipe qui est à l’origine de ReWork, le meilleur bouquin business du moment.
Enjoy 🙂
|| Semaine Suivante >>
Reporting Services, des fois je te hais. Vraiment.
Et une journée de perdue, une!
En même temps c’est de ma faute, je n’ai pas vérifié les versions de Visual Studio installées sur les postes des développeurs en arrivant, et ça n’a pas raté, merci les versions d’outre-tombe!
J’ai eu droit au bug catastrophe dans SSRS : les requêtes MDX qui disparaissent dans les datasets des rapports.
Pour faire court, BIDS se mélange parfois les pinceaux dans les RDL. Ce faisant il oublie de fermer les tags qui marquent le fait qu’un dataset SSAS utilise une requête MDX spécifique et pas le designer de base… Ce qui spécifiquement déclenche le bug, je ne saurais pas le dire…
Quand ça arrive, il n’arrive évidemment pas à ouvrir la requête peaufinée aux petits oignons dans son designer tout étriqué, et donc il plante. Et quand il plante, il efface la requête…
Hum, hum…
Et malheureusement, quand ça arrive, ça ne se manifeste que lorsqu’on ouvre un dataset. Si on ne touche pas aux datasets et qu’on ne fait que du design/aperçu, le bug n’apparaît pas!
Hum, hum…
Donc au programme de la journée nous avons:
- Installation du SP1 de Visual Studio sur tous les postes
- Extraction dans NotePad++ des requêtes MDX depuis les RDL ressortis du SVN
- Insertion des requêtes dans tous les rapports, remappage de tous les paramètres (oh joie)
- Allumage d’un cierge en espérant que l’installation du SP1 suffira à régler le problème…
Chouette! ><
Update 05/09/2010 : Le cierge a fait son effet, on a pu se remettre au boulot!
Au final c’était un seul des postes qui était responsable, et pour lui on a été obligé de faire une réinstall complète. Et lors de l’installation du SP3 de SQL Server, un des KB (le KB955706) ne passait pas. On a dû la réinstaller à la main. Passé ça, tout est rentré dans l’ordre.
…et un cube pour les diriger tous!
Chris Webb (pour rappel, l’auteur de la bible des cubes SSAS) reprend la discussion sur la question : faut il monter tous ses groupes de mesures dans un seul gros cube ou dans plein de petits cubes?
Le débat a repris suite à une question posée sur le technet, et Mister Webb fait le point dans cet article.
Je vous donne son avis en version courte, avis auquel j’adhère à 100% :
- Il faut mieux démarrer avec un seul gros cube afin d’accéder à toutes les mesures dans tous les rapports.
- Deux exceptions:
- Dès le départ, si les groupes de mesures sont complétement disjoints (ils n’utilisent que très peu de dimensions en commun), cela ne présente pas d’intérêt de les mélanger,
- Plus tard, en cas de problème de performances, cela a du sens de créer des petits cubes qui feront des zooms sur les sujets critiques.
C’est ce que je pratique et personnellement je n’ai jamais eu de problème!
Ps: Suis-je seul à systématiquement enlever la deuxième syllabe à « cube » dès que je l’entends dans une phrase pour voir si ça devient cochon? Je suis sûr que non… 😉
Accéder aux attributs d’un cube dans SSRS
L’utilisation des attributs de membres d’un cube SSAS dans un rapport SSRS ne se fait pas de manière transparente.
En effet, alors que les attributs sont visibles dans l’éditeur graphique de source de données SSAS de Reporting Services, ils ne sont pas sélectionnables.
Pour y avoir accès dans un rapport, il est nécessaire de basculer en mode Requête MDX, et de modifier sa requête de la manière suivante:
SELECT
NON EMPTY { [Measures].[...]} ON COLUMNS,
NON EMPTY { ([Dimension].[Hierarchy].[Level].ALLMEMBERS * [Dimension].[Hierarhcy].[Level].ALLMEMBERS * ... ) }
DIMENSION PROPERTIES MEMBER_CAPTION, MEMBER_UNIQUE_NAME, [Dimension].[Hierarchy].[Level].[Attribute]
ON ROWS
FROM [Cube]
WHERE ...
Les mots clefs DIMENSION PROPERTIES permettent de passer les valeurs des attributs directement dans le résultat de la requête MDX, les rendant accessibles dans l’onglet mise en page de SSRS.
Ainsi, dans le rapport, la syntaxe à utiliser sera : Fields!######(« Nom de l’attribut »)
Sources:
Blog de Braulio Malaga (Avanade)
MSDN
La BI ça vous gagne! 