Bonnes pratiques B.O

L’objectif de cet article est de fournir une description des bonnes pratiques lors de développement des applications utilisant la technologie Business Objects. L’idée est par ailleurs de décrire le raisonnement derrière les suggestions et de classifier les normes et les règles.

Bonnes pratiques: module Designer

Source de données
Paramètres de l’univers
  • Mettre le paramètre de l’univers JOIN_BY_SQL à « Yes » pour déplacer le processus du serveur BO à la base de données
  • Limiter la taille du jeu de résultats : permet de limiter le nombre de lignes qu’une requête simple retourne. Cela empêchera les requêtes de saturer le réseau. La valeur utilisée doit idéalement dépendre du nombre de lignes contenu dans un rapport type
  • Limiter le temps d’exécution : permet de définir la durée maximale e secondes d’une requête utilisateur, afin d’éviter une consommation des ressources sur le serveur trop importantes
Structure des données
  • Vérifier régulièrement l’intégrité de l’univers
  • Actualiser la structure à chaque modification de la structure de la base de données
  • Vérifier les cardinalités définies par la détection automatique des cardinalités. Celles suggérées par BO sont souvent erronées.
  • Eviter d’avoir des tables qui sont jointes à aucune autre table. Une table isolée pourrait produire un produit cartésien.
  • Créer des index sur les jointures créés dans l’univers
  • Utiliser des contextes si l’univers possède plusieurs tables de faits, ceci afin d’avoir des mesures fiables.
  • Les boucles doivent toujours être résolues afin d’éviter les produits cartésiens et les données incorrectes. En fonction des cas, on peut utiliser soit des alias, soit des contextes pour résoudre ces boucles
  • Utiliser des tables dérivées
    • pour réduire la complexité de certaines requêtes
    • pour définir des mesures dépendantes de plusieurs tables de faits
  • Un univers doit correspondre à un environnement métier
  • Utiliser les raccourcis jointures au maximum, afin de réduire le nombre de tables utilisées au sein d’une même requête
Objets et classes
  • Définir des règles de nommage concernant chaque objet (ex : pour les libellés, commencer par Lib.)
  • Les noms des classes et des objets doivent être proche du langage métier
  • Il convient d’homogénéiser le nombre d’objets par classe pour faciliter la recherche d’information par l’utilisateur (entre 10 et 15 objets)
  • Limiter le nombre de sous-classes
  • Créer une classe « Indicateurs »
  • Le nom des classes et des objets doivent être unique
  • Ne pas centrer la création des classes et des objets sur la structure des tables de la base de données, mais uniquement sur les besoins utilisateurs. Les objets d’une même classe peuvent provenir de tables différentes.
  • Il est conseillé de construire les conditions au niveau de l’univers, plutôt qu’au niveau des rapports
  • Formater les objets dans l’univers pour que l’utilisateur final n’ait pas à le faire (dates et devises par exemple)
  • Ne pas utiliser la clause WHERE dans la définition d’un objet, elle pourrait retourner des résultats incorrects. Il est préférable d’utiliser l’instruction CASE
  • Limiter les listes de valeurs (il vaut mieux toutes les enlever et les rajouter au fur et à mesure des besoins)

 

Bonnes pratiques: Module Web Intelligence

Requêtes
  • Il est préférable de créer une requête globale permettant de rapatrier l’ensemble des données à traiter dans le document plutôt que d’adopter le mauvais réflexe : un tableau = une requête.
  • Lorsque les volumes de données ne peuvent pas être extraits par une seule requête parce que la source est différente, ou les critères de filtre ne permettant pas un croisement, il faut alors passer par la création d’une nouvelle requête
  • Il est recommandé de ne pas utiliser plus de 15 fournisseurs de données dans un document webi. La durée d’actualisation des données et les performances du serveur peuvent être fortement impactées.
Document
  • Définir une charte graphique et un template
  • Chaque variable qui contient un calcul comportant une division doit avoir une condition SI dénominateur <> 0 Alors Objet. Cela permet d’éviter l’affichage de #DIV/0.
  • Utiliser un préfixe pour chaque variable afin de rapidement les identifier dans le document. Exemple var_ ou v_ ou v
  • Purger tous les fournisseurs de données avant de publier le rapport sur le serveur
  • Utiliser le mode structure pour manipuler les rapports complexes ou contenant beaucoup de données

Add a Comment

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *