Archives de catégorie : Non classé

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

par

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 !

par

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

par

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

par

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 MySQL: "innodb_file_per_table" ou comment utiliser des fichiers de table séparés pour éviter le manque d’espace disque!!

par

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 !