Introduction
Avec l’ouverture récente d’une cellule SAP BW au sein de DeciVision, vous retrouverez désormais régulièrement des articles autour de cette solution. Après un premier article pour vous présenter SAP BW, celui-ci a pour objectif de vous présenter quelques recommandations concernant le développement des requêtes BEx pour le reporting Web Intelligence.
Toutes les fonctionnalités de Web intelligence (Webi cf. figure 1.1) sont disponibles avec les requêtes BEx avec des avantages et des contraintes inhérents à la modélisation OLAP.
La requête BEx
Les avantages
- Un modèle OLAP dans BW est plus performant au rafraîchissement sur de grosses volumétries, que le modèle relationnel d’une base de données classique. Donc déléguer autant que possible les traitements dans BW.
- Les hiérarchies mises à disposition dans les requêtes BEx sont plus simples d’utilisation (cf. figure 1.2), l’activation de l’ « exploration » nécessaire dans le cas des univers est inutile avec les requêtes BEx
- Les variables utilisées dans les requêtes BEx sont reprises par Webi. Si ces variables sont pré-remplies en fonction du profil de l’utilisateur dans BW, Webi peut reprendre ces valeurs par défaut si la variable est optionnelle et vidée dans l’éditeur de requête.
- Le « Query Stripping », rendant inactifs les objets inutilisés d’une requête, est activé par défaut pour toutes requêtes BEx. Dans les cas des univers cette option doit être activé dans les propriétés du document WebI et de l’univers.
Les contraintes
La modélisation réalisée en amont dans BW peut empêcher certaines transformations de données dans Webi.
Voici les erreurs fréquemment rencontrées lors de transformations (agrégation, filtre, sélection, top, …) :
#MULTIVALUE : si après l’ajout d’une fonction d’agrégation (somme, moyenne, max, min, nombre) le problème persiste, votre contexte de formule est incorrect. Il faut alors le modifier à l’aide des fonctions Pourchaque(), Pourtout(), Dans() ou Aucunfiltre().
#TO_REFRESH : l’indicateur mis à disposition dans la requête BEx est réalisé à l’aide d’exception d’agrégation. Ces exceptions sont déléguées à BW par Webi, elles requièrent donc un rafraîchissement à chaque modification du niveau d’agrégation.
Si votre rapport est « statique » vous serez simplement gêné lors du développement.
Par contre si votre rapport final doit être « interactif », l’expérience utilisateur en sera impactée. Toutes interactions à l’aide d’éléments dynamiques : contrôles d’entrée, drill-down, plier-déplier ou autres, vont obliger l’utilisateur à rafraîchir le rapport à chaque fois.
#UNAVAILABLE : l’indicateur utilisé est certainement un ratio-calculé dans la requête BEx. Un ratio-calculé est un indicateur qui a été obtenu par formule de calcul dans BW.
Une simple somme ne posera pas de problème par contre toute autre formule plus complexe telle que des divisions, pourcentages ou multiplications va générer des erreurs dans Webi. Les ratio-calculés sont calculés et stockés dans BW puis envoyés lors du rafraîchissement à Webi. Donc tant que vous souhaitez seulement de l’affichage sans transformation, vous pourrez éviter l’erreur.
Pour contourner les erreurs #TO_REFRESH et #UNAVAILABLE, il sera nécessaire de déléguer les exceptions d’agrégations et les ratio-calculés à Webi. Ce qui entraîne la révision de la requête BEx voir de la modélisation en amont dans BW pour mettre à disposition les objets nécessaires à la transformation de la donnée.
Vous pouvez potentiellement y perdre en performance et également en « réemployabilité » de votre référentiel BW. En effet la suppression de ces règles d’affichage et de calcul dans BW vous oblige à les reproduire dans chaque document Webi.
Enfin ce rapatriement des règles de calculs et d’agrégation dans Webi va requérir de bonnes connaissances de la part du développeur (niveau 2) pour gérer les contextes de calcul.
Remarques
Développer un document Webi sur une requête BEx va donc régulièrement vous demander de créer une nouvelle requête BEx dédiée.
Les BEx déjà existantes sont optimisées pour l’analyse dans BW et ne fonctionneront certainement pas dans Webi surtout dans le cas de Dashboards avancés avec des éléments dynamiques.
Il va falloir trouver le juste milieu entre :
- les traitements réalisés dans BW pour des raisons de performance et de construction d’un référentiel
- les traitements délégués à Webi pour des raisons d’incompatibilités.
Dans la mesure du possible on optimisera la requête BEx pour que tout soit fait dans BW dans le cas de rapport statique. Et à l’inverse, on sera obligé de déléguer à Webi certaines transformations qui seront dynamiques dans le document.
Recommandations de développement des requêtes BEx et limitations pour Webi
Certaines Best Practices, pour le développement de requête BEx dans un environnement full-BW, vont poser problème dans Webi.
Ces optimisations de requêtes, pour répondre aux contraintes de performance et de lisibilité, vont devoir être abandonnées dans les requêtes dédiées à Webi comme ces exemples : limiter le nombre d’attributs de navigation, utiliser des variables, limiter la taille des hiérarchies, réduire le nombre de metadata, …
Voici quelques règles de développement simples pour rendre fonctionnelles les requêtes BEx dans Webi :
Généralités
La première chose à faire est de cocher « Autoriser l’accès extérieur de la requête » au niveau des propriétés de la requête.
La requête BEX doit être construite sur un multi ou composite provider.
L’idéal est de calculer un maximum d’éléments côté BEx afin d’emporter le moins de complexité et de calculs dans Webi, un changement de règle de gestion pourrait alors se régler sur la requête BEx (le GUID d’un ratio calculé ne change pas)
Les structures ainsi que les valeurs par défaut de l’écran de variables fonctionnent bien dans Webi
Un InfoProvider sans aucune requête n’est pas visible dans Webi, il faut en créer au moins une pour le rendre visible
Ce qui ne fonctionne pas ou mérite attention :
- En général tous les paramètres d’affichage des requêtes BEx ne sont pas pris en compte dans Webi et doivent être reproduits dans le document avec la mise en forme ou le formatage conditionnel
- Les filtres appliqués dans la requête doivent être présents dans la zone de filtre (cf. figure 3.1). Tous autres types de filtres absents de cette zone seront ignorés par Webi.
- Les conditions et exceptions de la query BEx ne fonctionnent pas dans webi
- Les cellules calculées BEx cells ne fonctionnent pas dans Webi
- Les tris, les formats des objets de la requête BEx ne sont pas repris
- Les select-options variables, il faut les échanger par des sélections ou intervalles
Organisation pour les développements
- Convenir d’une nomenclature qui sera mise en commun sur un document partagé entre développeurs BEx et Webi
- Utiliser les noms techniques des variables plutôt que les textes
- Donner une copie d’écran de la BEx aux équipes Webi pour
- montrer qu’elle fonctionne
- avoir des résultats à comparer avec Webi
- pas de temps perdu pour trouver la donnée du cas de test (numéro de commande existant etc..)
Recommandations concernant les caractéristiques
- Mettre toutes les caractéristiques dans la section “Caractéristiques libres”
- Envisager, lors de modélisation, la possibilité que tous les attributs d’affichage puissent devenir des attributs de navigation pour pouvoir en disposer comme une dimension dans Webi. (Pour permettre notamment de filtrer dès l’éditeur de requête et faciliter les fusions dans Webi)
- L’attribut de navigation possède plusieurs attributs d’affichage dans Webi et par défaut une clé et une description
- Pour améliorer la compréhension des objets, ajouter une description. En particulier sur les attributs de navigation
- Dans le document Webi, la valeur de l’attribut de navigation correspond à sa description par défaut et si cette dernière est nulle, elle correspond à sa clé. Tout changement du paramétrage d’affichage par défaut sera ignoré par Webi
- Vérifier que les caractéristiques n’utilisent pas 2 fois la même description sinon Webi affiche le nom technique en plus de la description
- Les valeurs de caractéristiques qui remontent la valeur « X » génèrent une erreur dans Webi, il faut transformer la sortie en 1 ou 0
- Les attributs composés seront affichés composés dans Webi sauf en utilisant des formules pour séparer les clés
- Il faut essayer d’anticiper les drill-down et la nécessité de regrouper des caractéristiques hiérarchiques entre elles. Exemple sur l’axe temps entre année et mois
Recommandations concernant les indicateurs
- Ne jamais créer de descriptions variables, Webi va prendre le texte au moment de la première exécution et le conserver comme texte figé
- Pour tous les indicateurs restreints qui doivent être calculés dans Webi, il faut mettre à disposition les caractéristiques et les indicateurs utilisés pour reproduire le filtre dans Webi.
- Les éléments de calcul qui ne servent qu’aux calculs doivent être en affichage « toujours masqués » sur la requête BEx
- Les fonctions d’arrondis, les valeurs cumulées sont à faire côté Webi
- Attention aux ratios signés négatifs mis entre parenthèses
- Il faut éviter les formules avec SUMGT, SUMCT, SUMRT ainsi que les fonctions mathématiques au niveau des ratios calculés
- Les exceptions d’agrégation risquent de forcer des rafraîchissements multiples dans le rapport Webi. Si elles doivent être abandonnées, les caractéristiques nécessaires à l’exception doivent être mises à disposition. De plus, il faut signaler aux développeurs Webi la caractéristique utilisée pour l’exception
- Le type de jointure (« JOIN » ou « unique JOIN Columns ») d’un composite provider peut entrainer des résultats incohérents dans Webi. La seconde jointure se paramètre via la transaction RSLIMO.
Points avec impact sur les performances
- Limiter au maximum le nombre d’enregistrements passé par défaut à Webi
- Placer un maximum de caractéristiques en caractéristiques libres au lieu de les placer en ligne ou en colonne (cf. figure 2.1)
- Réduire le volume de données en rendant obligatoire des variables sur l’écran de variables
- Restreindre la caractéristique temps à la valeur temps actuelle
- Changer la propriété de lecture de la requête en mode X « Lecture des données pendant la navigation »
- Toujours supprimer les lignes de total de toutes les caractéristiques (cf. figure 2.1)
- Anticiper la volumétrie par rapport aux listes déroulantes de valeurs, aux graphiques, au nombre de lignes pouvant apparaitre en résultat (une limitation du nombre de valeur toujours positionnée au maximum touche aux performances)
- Lors de l’usage de hiérarchies, ne pas oublier d’enlever les noeux non assignés en RSH1
- Côté Webi, cocher « Query Stripping » pour optimiser le fetch de la query
- Côté BEx, définir les ratios calculés au niveau de l’InfoProvider au lieu de le faire sur la requête
- Limiter les caractéristiques navigationnelles aux besoins métier car chacune nécessite des jointures de table supplémentaire
- Pour de meilleures performances dans Webi, déclarer les variables dans la BEx plutôt que dans Webi
- Pour les gros volumes de données, cocher l’option « Sélection des membres de la structure » en RSRT, améliore les performances quand de nombreux ratios sont présents
- Eviter les exclusions au niveau des ratios calculés, filtres et sélections. Seules les inclusions utilisent les index
- Privilégier de multiples valeurs simples plutôt que les valeurs multiples (= à la place de IN), de plus le select-option sera interprété comme un intervalle dans Webi
- Test des exits de variables (vérifier leur bon fonctionnement et voir pour les optimiser)
Incompatibilités détaillées
Pour consulter toutes les compatibilités avec tous les outils de la suite BusinessObjects (Design Studio, Lumira, …), rendez-vous sur la SAP note suivante : https://launchpad.support.sap.com/#/notes/1869560
CONCLUSION DE L’EXPERT
Ce article a été rédigé pour tenter de faire prendre en compte l’ensemble des spécificités ou exigences de Web Intelligence dès le début du développement d’une requête BEx pour la meilleure compatibilité sous Webi.
Ces exigences sont généralement celles rencontrées et peuvent varier en fonction des différentes versions de BW et des différentes versions de Webi utilisées.
Bon nombre des points avec impact sur les performances cités dans ce document sont aussi valables pour les seules requêtes BEx.
Merci à Alexandre HABART pour la contribution à cet article
