Tip SAP BO XI R4.1 : Bien utiliser les tableaux croisés sans indicateurs

Imaginez que vous vouliez afficher les différentes traductions d’un article en sachant que le nombre de traduction disponibles n’est pas fixe; Soit vous affichez un tableau simple avec la liste des articles et des traductions soit vous faites un tableau croisé à la manière d’Excel.
Allez, du concret:
Tout d’abord voyons les données de base:

le résultat d’une requête nous renvoie 4 dimensions

capture

Si l’on crée un tableau simple, voilà  ce que l’on récupère:

capture2

Ce qui n’est pas vraiment exploitable.

On va donc créer un Tableau croisé :

sans-titre

Puis on va intégrer les dimensions qui vont intervenir dans les axes . Lorsque  l’on dépose un tableau croisé dans un rapport, un menu contextuel apparaît pour permettre de choisir les axes :

capture3

Ce que l’on voudrait, c’est avoir la liste des articles ( en ligne)  et leurs traductions en colonne ainsi que les traductions en tant que « corps » :

capture3

et voilà  le résultat : capture4

Sauf que l’on remarque que les lignes sont dédoublées selon le nombre de traduction; pas glop !

Pour éviter d’avoir des doublons on va utiliser une fonction très pratique : « Première »  qui renvoie la première valeur d’un ensemble de données:

capture6

Et du coup, les lignes ne sont plus dédoublées.

SAP BO XIR4 SP4: Requêtes SQL à la carte inutilisables !

Avec le service Pack 4 de SAP BO XIR4, SAP a eu la bonne idée de réintroduire les requêtes à la carte; sauf que cette fonctionnalité qui existait en XIR2 et qui était très utile ne fonctionne pas (ou mal ) !
Bref, on s’engouffre tous dans cette fonctionnalité en migrant les anciens rapports et là c’est la cata :

Message d’erreur impossible d’obtenir la première page encours Vérifiez la validité de votre rapport (ERR WU 20003)

erreur_hsql

Si vous avez construit un rapport complexe, vous pouvez mettre à  la poubelle vos heures de travail…

En fait cette erreur apparaît quand vous modifiez la requête, une fois le rapport créé.

Il faut donc veiller à  ne plus modifier la requête dès lors qu’elle est utilisée dans un rapport.

Il y a quand même deux options de secours :

  • option 1:  dans le même rapport, recréez une nouvelle  requête et débranchez le rapport de l’ancienne requête.
  • option2:  passez au service pack 7 patch 1 qui règle définitivement l’erreur

 

Et vous avez-vous eu ce type d’erreur?

n’hésitez pas à  réagir

Tip SAP BO XI R4.1: mettre en place des filtres de type date sans problème de conversion

Qui a déjà essayé de mettre des filtres de date sans problème de conversion ?

Souvent ce qui arrive c’est ça :

t3

alors que le filtre indique une date  :

t4

En fait, lorsque l’on regarde la requête , on voit que BO traduit la date en date + les heures minutes et secondes :

t5

Pour forcer BO à  convertir la date rentrée au format dd/mm/yyyy, il faut lui indiquer dans la couche de gestion le format le type date pour la dimension, puis aller dans l’onglet Avancé pour remplir le format de date  (dd/mm/yyyy)  dans le cartouche Format de la base de données:

t7

Une fois fait, la requête a une meilleure gueule :

t8

Il ne reste plus qu’à publier l’univers pour faire bénéficier les utilisateurs de cette avancée majeure de l’informatique décisionnelle !

 

Erreur SAP BO XI R4.1: impossible de se connecter avec Web Intelligence Rich Client en mode Entreprise

Encore un bug de SAP BO XI R4.1!
il arrive que lorsque vous essayez de vous connecter à votre serveur BO en mode Entreprise au travers du Web Intelligence Rich Client, voilà ce qui peut arriver:

erreur_blog1

un joli message :  « Échec de connexion ».

Cela est dû au fichier de connexion local qui est corrompu.

Pour  résoudre cela, vous devez aller dans    Documents\My SAP BusinessObjects Documents\LocData

si vous ne voyez pas les extensions des fichiers , cliquez dans « organiser » puis choisissez « Options des dossiers et de recherche »

enfin décochez « Masquer les extensions des fichiers dont le type est connu »

t t2

Ensuite, supprimez ou renommez en .OLD, par exemple, tous les fichiers avec l’extension *.LSI

Puis, vous pouvez vous reconnecter.

SAP BO va recréer de lui même les fichiers de connexion locaux.

Tip PENTAHO: comment modifier les traductions de l’interface Jpivot?

Voilà une astuce qui va être utile pour les développeurs et administrateurs de pentaho qui ont mis en place les pivots jpivot.
Vous avez surement remarqué   comme les traductions étaient des fois limites? Par exemple, la fonction dans la barre des outils de jpivot qui permet de supprimer les lignes vides a été traduite en « Opprimer les lignes blanches »:
Pas très compréhensible tout ça…
Et bien, il y a un moyen pour y remédier, c’est de faire sa propre traduction.
Pour cela, il va falloir modifier directement la librairie jpivot:
Allez dans biserver-ce/tomcat/webapps/pentaho/WEB-INF/lib et choisissez le fichier jpivot-XXX.jar
Ouvrez-le  avec votre gestionnaire d’archives préféré , puis allez dans le répertoire
com/tonbeller/jpivot/toolbar/resources
Là dedans vous allez trouver l’ensemble des fichiers de ressource qui servent à  l’affichage des tooltips dans la barre des outils. Ouvrez le fichier resources_fr.properties
nano resources_fr.properties
puis modifiez la ligne suivante :
toolb.non.empty=Opprimer lignes blanches
par :
toolb.non.empty=Supprimer lignes vides
Il n’y a plus qu’à  enregistrer le fichier de propriétés dans le jar et redémarrer PENTAHO et le tour est joué.

PENTAHO/JPIVOT: erreur à l’export Excel ou PDF

Maintenant que votre pivot est affiché, vous avez peut-être envie de l’exporter sous Excel pour retravailler les données.
Pour cela vous utilisez le bouton bien connu :

Sauf qu’au lieu de récupérer l’export vous êtes confronté à une erreur   du style :

mai 25, 2005 12:26:18 PM org.apache.catalina.core.ApplicationContext log
SEVERE: StandardWrapper.Throwable
java.lang.NoClassDefFoundError: org/apache/fop/configuration/Configuration
at com.tonbeller.jpivot.print.PrintServlet.init(PrintServlet.java:71)
at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1173)
at org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:809)
../..
Caused by: java.lang.ClassNotFoundException: org.apache.fop.configuration.Configuration
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1645)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1491)
... 14 more
Tout cela est dû au problème de compatibilité descendante entre les dernières version de PENTAHO et jpivot.
Alors que PENTAHO intègre la dernière version de la librairie apache FOP, jpivot ( qui n’est plus maintenu depuis des lustres) utilise une version, disons-le, très ancienne.
Or, cette version ancienne version utilisait une classe (org.apache.fop.configuration.Configuration) qui n’existe plus dans la dernière version de FOP.
Il suffit alors de récupérer la version 0.20.5 sur un site ( maven par exemple)  et la copier dans
biserver-ce/tomcat/webapps/pentaho/WEB-INF/lib/:
cd biserver-ce/tomcat/webapps/pentaho/WEB-INF/lib/
wget http://mirrors.ibiblio.org/pub/mirrors/maven/fop/jars/fop-0.20.5.jar
Le bug a été référencé sur le JIRA de PENTAHO :
http://jira.pentaho.com/browse/BISERVER-7286
Ah oui, dernière chose,  n’oubliez pas de déplacer ou supprimer la librairie (fop-0.9XX.jar )fournie par PENTAHO.

Tip MySQL: "innodb_file_per_table" ou comment utiliser des fichiers de table séparés pour éviter le manque d’espace disque!!

Bon,
je suis pas très fier de ce que j’ai fait mais je vous relate mes erreurs et comment je suis arrivé à les résoudre pour vous éviter de faire pareil…

Situation

J’installe Mysql sur mon nouveau serveur dédié, monstre de calcul (8 cpu « machin » bridge) et d’espace disque ( 1To). Je configure ma base de données au format  Innodb ( le format qui permet les contraintes externes, etc.); je configure les capacités de mémoire, l’espace disque temporaire;
bref, je crois avoir tout passé en revue…

Puis j’alimente ma base avec des données provenant de réseaux sociaux – autant dire que la volumétrie est importante.

Out of space

Au bout de quelques semaines, je m’aperçoit que le fichier ibdata qui est dans le répertoire de données grossit mais ne rétrécit jamais , y compris lorsque je supprime des tables de plusieurs centaines de GigaOctets.
Finalement j’atteins la taille limite de mon disque et là je suis mal surtout que je dois produire des rapports d’analyse pour avant hier.

L’option de la mort qui tue

C’est là  que je m’aperçoit que par défaut à  l’installation,  MySQL et configuré pour gérer toutes les tables et leurs index dans un seul et même fichier –  le fameux « ibdata » et que ce fichier  est voué a grossir –  jamais à  réduire !
Il aurait fallu utiliser l’option « innodb_file_per_table » dans le fichier de configuration (my.cnf) pour que chaque table utilise son propre fichier de stockage des données et d’index.
Ok, je l’ai pas fait; mais alors comment faire pour rattraper ma bourde ?

Play it like a barbarian

Oui, je dirais qu’il faut y aller « à  la barbare » c’est à  dire faire une réinstallation des bases!
Première chose, faire une sauvegarde complète des bases : 

mysqldump -R -q -p --all-databases > 20120402_mysql_all.sql

Ensuite, arrêter MySQL et supprimer tous les fichiers du répertoire des bases de données( moi, je fais un move sur un support de sauvegarde):

service mysql stop
mv  /home/mysql/* /home/backup/mysql_old_dir

Redémarrer Mysql :

service mysql start

Enfin, restaurer les tables :

mysql -u root  < 20120402_mysql_all.sql

Je vous cache pas qu’il faut aimer avoir des sueurs froides dans le dos pendant quelques longues minutes.

N’hésitez pas à  commenter ce post si vous avez été dans le même cas !