Simulation avec Web Intelligence

Simulation d'un prêt immobilier avec Web Intelligence

L'objectif de cet article est de montrer une fonctionnalité bien cachée de Web Intelligence. Il ne s'agit pas d'une simulation au sens large comme le font les outils spécialisés, mais plutôt d'une possibilité de faire plusieurs scénarios en jouant sur des paramètres variables.

Pour illustrer notre exemple, nous allons nous basons sur une simulation que tout le monde connaît. Il s'agit de la simulation d'un prêt immobilier.
A partir de cet exemple, vous pouvez vous inspirer pour explorer d'autres simulations.

Pour faire notre simulation nous allons utiliser la formule suivante :

Avec :
K : Le montant emprunté en €
t : Le Taux Effectif Global annuel
n : La durée de l'emprunte en mois (nombre de mensualités)
m : La mensualité à payer en €
Les frais de dossier et d'assurance ne seront pas pris en compte.

Pour faire cette simulation dans Web Intelligence, nous allons utiliser les contrôles d'entrée (input control) disponibles à partir de la version BO XI.

Création des variables : 
Nous allons d'abord commencer par créer les variables qui permettront de faire les différents calculs.
Les variables à créer sont :

Avec :
Capital : montant emprunté, peut être initialisée à 200 000 par exemple :

Durée : durée du prêt en années, peut être initialisée à 12 par exemple :

Taux : TEG annuel, peut être initialisée à 4% par exemple (c'est 4 et non pas 0,04) :

v_Durée_mois : pour convertir la durée en nombre de mois :

v_Taux_Pourcentage : pour convertir le taux en décimales (0,04) :

Mensualité : la mensualité calculée selon la formule citée ci-dessus :

Intérêts : calculés comme suit :

Avec ces variables nous obtenons le résultat suivant :

Maintenant nous allons créer les contrôles d'entrée qui nous permettront de modifier les paramètres Capital, Durée et Taux et de calculer la mensualité et les intérêts.

Les contrôles d'entrée à créer sont de type curseur simple :

Contrôle d'entrée sur la variable Capital :

Contrôle d'entrée sur la variable Durée :

Contrôle d'entrée sur la variable Taux:

Et voici le résultat :

Si l'on modifie le capital :

Et si l'on modifie la durée :

Et si l'on modifie le taux :

Et voilà, vous êtes prêts maintenant à aller demander un prêt à votre banque :)

SAP BO Web Intelligence : Nouveautés (SAP BI4) et bonnes pratiques

A propos de SAP BO Web Intelligence :

SAP BO Web Intelligence est un outil de reporting permettant aux utilisateurs d’extraire et d’analyser des données de bases de données ou de cubes OLAP sans avoir à connaître de langage informatique. C’est un outil orienté ‘métier’, il a été créé de manière à ce que l’utilisateur n’ait besoin que de la connaissance de son métier pour accéder aux données. Ainsi, l’utilisateur peut définir lui-même ses requêtes à l’aide d’une structure (univers) s’approchant au plus près de son langage métier, à condition bien sûr que cette structure soit bien conçue et définie.

Les données peuvent provenir de plusieurs sources (dans la version BI4) : d’univers sur des bases de données relationnelles ou OLAP, de fournisseurs de données personnelles tels que des fichiers csv ou Excel, de requêtes reposant sur des SAP InfoCubes ou de services Web.

Il est également possible de se connecter à la source de données HANA afin de profiter des avantages du calcul en mémoire.

Les fonctionnalités de reporting et d’analyse sont très variées : Tableaux, graphiques, filtre, tri, palmarès, exploration des données, mise en forme conditionnelle, interactivité entre les composants du même rapport ou entre les rapports.

Les nouveautés de Web Intelligence dans la suite SAP BI 4.0 par rapport à la version XI :

La suite SAP BI4 est venue avec plusieurs nouveautés par rapport aux versions précédentes. Nous allons nous limiter aux nouveautés apportées sans Web Intelligence. Voici quelques-unes.

Nouvelles sources de données

-          Intégration avec SAP BW :

-          Fichiers Excel et texte :

-          Sans source de données :

Volet de prévisualisation du résultat de la requête :

Dans l’éditeur de création des requêtes, un nouveau volet est ajouté qui permet de prévisualiser les résultats de la requête :

             

Nouvelle ergonomie :

3 modes d’utilisation :

Structure à onglet :

Nouveaux graphiques et mise en relation d’éléments :

          

Accès aux fournisseurs de données :

               

Propriétés :

Les propriétés des objets d’un document (tableau, section, graphique, cellule) ont été améliorées. Il est maintenant plus facile de modifier l’apparence et le comportement de ces objets.

Exemples :

Propriétés d’un tableau :
                      

Propriétés d’un graphique :
                     

Autres : 

        Copier/Coller :

        Il est possible de copier un élément d’un document vers un autre document, même les fournisseurs de           données

        Masquer les colonnes :

        Il est possible de masquer les colonnes d’une manière simple ou selon une condition

        Plier / Déplier :

        La possibilité de plier/déplier horizontal qui n’était disponible que dans Deski mais pas seulement en               Rich Internet Application (pas en mode html)

        Création des open doc :

        Une nouvelle interface a été ajoutée pour simplifier la création des open doc

Les nouveautés de Web Intelligence dans la suite SAP BI 4.0 par rapport à la version 4.0 :

Figer les entêtes : 

Les Entêtes de tableaux, lignes et colonnes peuvent être figés :

Personnalisation des palettes de couleurs :

Il est possible de personnaliser les palettes de couleurs et des les assigner dans les graphiques 

Fusion des dimensions :

Les dimensions peuvent être fusionnées directement via le panneau des objets disponibles.

Plier/Déplier en mode html :

Maintenant il est possible de plier/déplier un tableau en mode html :

Graphes Cascades :

Ce type de graphe permet de représenter l’évolution d’un indicateur dans le temps, en analysant les facteurs positifs et négatifs qui impactent cette évolution.

Autres :

• Possibilité d'afficher la liste de valeurs d'un objet sélectionné dans l'éditeur de formule
• Possibilité de n'actualiser qu'une seule requête dans l'éditeur de requête
• Query stripping est supporté pour les sources de données relationnelles (dans 4.0 ce n'était possible que pour les requêtes Bex)

Bonnes pratiques :

Nous allons aborder quelques bonnes pratiques à respecter dans la création d'un document Web Intelligence.

Charte graphique : 

une charte graphique est indispensable pour créer des documents cohérents et respectant la charte de l'entreprise. Avant de démarrer les développements il faut toujours la demander. Si aucune charte graphique n'a été définie il faut dans ce cas proposer une.

Règles de nommage :

Document : 
Donner un nom significatif au document et à tous les onglets le composant. Ce nom doit être défini avec et validé par la MOA.
Exemple de règle : AAA_BBBB_Description

• AAA : Abréviation définissant le nom du domaine ou du projet
• BBBB : Abréviation définissant la catégorie du document (Exemple : CA pour le chiffre d'affaires, CLI pour client...)
• Description : Zone libre pour nommage du document (mais doit être significatif)

La taille maximum du nom : 50 caractères pour éviter l'affichage de noms trop longs sur le portail)

Fournisseurs de données : 
Chaque fournisseur de données doit avoir un nom qui reflète l'utilisation des données qu'il récupère.

Variables : 
Utiliser un préfixe pour chaque variable. Exemple var_ ou v_ ou v.
Cela permettra d'identifier rapidement les variables créées dans le rapport et de les différencier des objets de l'univers.

Les objets du document : 
Chaque objet du document (tableau, graphique, ..) doit avoir un nom significatif. Ceci facilitera la manipulation de ces objets (dans le positionnement relatif par exemple).
Préfixer le nom de l'objet par son type, Exemples : t. pour les tableaux, g. pour les graphiques.

Propriétés du document : 

Utiliser les propriétés du document pour donner plus d'informations : 
                 Description : peut contenir une description synthétique du document
                 Mots clés : les mots clés importants pour faciliter la recherche

Page d'accueil : 

Avoir une page d'accueil (un onglet accueil) qui explique le document.
Cette page d'accueil est principalement utile pour les documents complexes.
Le contenu de cette page est à définir et valider avec la MOA
Cette page peut contenir : 
- Le nom, la description, la version du document
- Le nom de l'auteur
- Des règles de gestion
- Les univers utilisés
- Les filtres et les invites
...

Template : 

Il est recommandé de définir un template avant de démarrer les développements.
Il est possible de définir plusieurs templates. Chaque template répond à un mode de reporting donné. Exemple : on peut définir un template pour le format paysage et un autre pour le format portrait.
On peut aussi y appliquer tous les éléments de la charte graphique.
Tous les rapports doivent se baser ensuite sur ces templates.
Ceci permettra 
- De respecter la charte graphique
- D'avoir une cohérence globale dans tous les rapports
- De gagner en temps de développement.

Format des cellules : 

Nombre : 

- Le format du nombre doit être défini et pas laissé en format standard(affichage en milliers ou sans, séparateur et nombre de décimales). 

- Le format doit être en cohérence avec la langue (pour le séparateur de décimales par exemple).

- Eviter le format standard et choisir un format personnalisé. ça marche mieux après un export vers Excel.

Date : préciser le format des dates. ce format doit être en adéquation avec le format utilisé dans l'entreprise. idem pour les date/time.

Alignement : bien définir l'alignement des différents types de données

Exemple : les nombres doivent avoir un alignement à droite tandis que les textes doivent avoir un alignement  à gauche.

Pourcentage : 

- Le nombre de décimales doit être défini

- Le symbole % doit être affiché (au niveau de l'entête de la colonne par exemple)

Points divers : 

• Sélectionner les objets de telle façon que le SQL généré donne un ordre hiérarchique des tables. Cela facilitera l'optimisation de la requête.
• Eviter de ramener des objets qui ne seront pas utilisés dans le rapport. Chaque objet inutilisé est une perte de performance.
• 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.
• Eviter de faire des calculs imbriqués sur plusieurs lignes dans une variable. Avant de créer une usine à gaz, il vaut mieux voir avec le designer de l'univers s'il n'y a pas moyen de faire plus simple dans l'univers (ou dans l'alimentation de la table).
• Penser à cocher l'actualisation du rapport à l'ouverture dans les propriétés du document
• Penser à cocher l'affichage des doublons dans les propriétés d'un tableau. Ceci permet de ne pas masquer les erreurs de doublons.
• Utiliser le mode structure pour manipuler les rapports complexes ou contenant beaucoup de données
• Cocher 'fusionner automatiquement les dimensions' dans les propriétés du document
• Eviter de cocher 'suppression des doublons' dans les propriétés du document. Si l'option est cochée cela générera un disctinct dans le SQL, ce qui n'est pas bon pour les performances. S'il faut supprimer des doublons, c'est dans l'alimentation qu'il faut le faire et non pas dans le rapport.
• Purger tous les fournisseurs de données avant de publier le rapport sur le serveur.

Information Design Tool de SAP BI4 : Astuces et bonnes pratiques

A propos de Information Design Tool (IDT) :

Information Design Tool (ou outil de conception de l'information en français) est un le nouvel outil de SAP Business Objects destiné aux concepteurs pour créer les univers dans la suite BI4.

Les nouveautés de l'IDT :

L'IDT permet de tirer parti des nouvelles et importantes fonctionnalités de conception d'univers, parmi lesquelles :

• Univers dimensionnels prenant en charge les hiérarchies et les dimensions OLAP
• Univers à sources multiples fédérant plusieurs sources de données relationnelles
• Environnement de conception facilitant le travail d'équipe des créateurs et le partage des ressources d'univers
• Editeur de sécurité pour les métadonnées et les données d'univers
• Gestion étendue des connexions
• Gestion plus aisée des ressources de référentiel

Les composants de l'IDT :

L'IDT permet un développement structuré et organisé de ses univers.

Cette structuration passe par les composants suivants :

• Projet : Un projet est un espace de travail local nommé qui contient les ressources utilisées pour créer un ou plusieurs univers. Un projet peut contenir un nombre quelconque de ressources indépendantes; des fondations de données, des couches de gestion et des connexions, par exemple. Toutes les ressources contenues dans un projet peuvent être utilisées de façon interchangeable ; une connexion peut être utilisée par plusieurs fondations de données dans le même projet, par exemple.
• Connexion : c'est l'ensemble nommé de paramètres qui définissent la façon dont un univers peut accéder à une base de données relationnelle ou OLAP.
• Une connexion est une ressource indépendante qui peut être utilisée par plusieurs univers. Il est possible de créer des univers à sources multiples qui référencent une ou plusieurs connexions relationnelles.
• Fondation de données : Une fondation de données est un schéma définissant les tables et jointures pertinentes dans une ou plusieurs bases de données relationnelles. Elle devient la base d'une ou de plusieurs couches de gestion.
• Couche de gestion : Une couche de gestion est un ensemble d'objets de métadonnées fournissant une abstraction des entités de bases de données relationnelles ou des cubes OLAP, compréhensible par un utilisateur professionnel. Ces objets incluent les dimensions, hiérarchies, indicateurs, attributs et conditions prédéfinies. La couche de gestion désigne l'univers en construction et, lorsque la couche de gestion est terminée, elle est compilée avec les connexions ou raccourcis de connexion et la fondation de données, publiée et déployée sous forme d'univers.

Avec ces composants, il est donc possible de créer un seul projet (Projet entreprise) contenant toutes les connexions vers les différentes sources de l'entreprise, une fondation de données contenant ces connexions, et plusieurs couches de gestion (une couche de gestion par métier/domaine) comme illustré dans le schéma suivant :

Les bonnes pratiques

Nous allons organiser ces bonnes pratiques selon 3 catégories :

• Focus Utilisateur : Pour apporter une valeur ajoutée au métier
• Focus Développement: Pour construire une solution solide techniquement avec quelques astuces pour aller plus vite dans les développements.
• Focus Performance : Pour assurer de bonnes performances

Focus Utilisateur :

Important :

Toutes les règles et bonnes pratiques de ce paragraphe doivent être définies et validées en étroite collaboration avec le métier.

Organisation des classes et objets :

L'organisation de l'univers (classes, objets, noms , descriptions) doit être pertinente pour le métier :

• Respecter dans la mesure du possible un processus métier (on peut s'inspirer des applications opérationnelles).
• Limiter le nombre de sous-classes ( pas plus de 4)
• Limiter le nombre d'objets par classe (20-25)
• Organiser les classes dans l'ordre suivant :
• Dimensions (référentiels)
• Indicateurs (à organiser par thème/domaine métier)
• Paramètres (s'il y en a)
• Ajouter une classe cachée pour les objets obsolètes (les supprimer peut rendre certaines rapports incorrects)

Règles de nommage :

Les règles de nommage permettent de garantir la cohérence et la stabilité des univers au sein de l'entreprise.

Ces règles doivent être universelles (au sein de l'entreprise) en utilisant le plus possible des termes du métier (pour que ces règles aient du sens).

Ces règles doivent être respectées dans tous les univers.

Elles peuvent concerner :

• Le nom de l'univers : un nom métier clair et précis
• Les noms des classes : 
• En plus d'un nom métier compréhensible, il est très utile d'utiliser des préfixes (3 lettres par exemple) (*). 
• Ne pas dépasser 60 caractères.
• Les noms des objets : 
• idem que les classes. 
• Il est possible de s'inspirer des applications opérationnelles (au moins pour garder le même nom). 
• Préfixer avec le même préfixe que sa classe.
• Le nom doit être unique.
• Les filtres prédéfinis: 
• Le nom du filtre prédéfinie doit contenir la condition en question
• Les invites : 
• Ajouter '?' pour montrer qu'il s'agit d'une invite (et surtout différencier avec les filtres prédéfinis)
• Les descriptions (des classes et des objets) : 
• Tous les objets doivent avoir une description
• Elles doivent être compréhensibles et apporter une vraie aide à l'utilisateur

(*) point sur les préfixes : l'utilisation des préfixes apporte une vraie valeur ajoutée lors de la création/modification des rapports surtout quand l'univers est assez conséquent avec plusieurs classes et des centaines d'objets. En effet, ils permettent :

• De ne pas mélanger les objets dans le fournisseur de données
• Un affichage ordonné des objets dans le rapport (volet gauche)
• L'unicité du nom sans besoin d'avoir un nom très long qui peut ne pas s'afficher en entier (dans l'éditeur des fournisseurs de données)
• De trouver, en se basant sur le préfixe, la classe de chaque objet
• La simplification de la recherche d'un objet dans l'univers (surtout en cas de modification)

Listes de valeurs :

Penser à personnaliser les listes de valeurs pour ajouter toutes les informations qui faciliteront le choix de la valeur (en plus du code, ajouter le nom/le libellé, pour un objet appartenant à une hiérarchie ajouter tous les niveaux supérieurs, ajouter un tri ...)

Format des objets

Définir le format des objets dans l'univers permet d'éviter de le faire dans chaque rapport. Il est à définir principalement pour :

• Les dates : définir le format qui sera utilisé dans tous les rapports
• Les objets date (comme l'année, le trimestre…) : pour par exemple éviter l'affichage par défaut des séparateurs de milliers.
• Les nombres : Attention au nombre de décimales. La définition du nombre de décimales dans l'univers peut engendrer un problème d'arrondi dans les rapports.

Focus Développement:

Connexion

Connectivité native : 

Toujours utiliser la connectivité native de l'éditeur

Eviter les drivers génériques comme ODBC pour Oracle

Nom de la connexion : 

Bien nommer la connexion (afin d'identifier facilement la base de données source)

Dans un univers multi-source, le nom de la connexion est utilisée dans la définition SQL des objets (@catalog('Nom_connexion')), il faut donc choisir un nom générique indépendant de l'environnement (développement, test, recette, production).

Connection pool mode : 

Il existe 3 modes de connexion à la base :

• Déconnecter après chaque transaction

• Conserver la connexion active pendant une durée à fixer

• Conserver la connexion active pendant toute la durée de la session

Le processus de création d'une connexion de base de données est assez cher en temps, il est donc préférable de garder la connexion ouverte plus longtemps. Mais les connexions ouvertes consomment des ressources sur le serveur de base de données, il faut donc limiter le nombre de connexion au minimum.

Il faut donc trouver le mode optimum en fonction de l’utilisation

Fondation de données

Préférences : 
Paramétrer, dans les préférences, le mode d'affichage des jointures pour avoir une meilleure visibilité (opter pour lignes droites) : 

Bien organiser la structure :

Tables de faits au centre

Tables de dimensions à gauche et à droite

Les tables de dimensions qui sont liées entre elles doivent être du même côté

Disposer les tables de telle sorte que les cardinalités 1-n soient de gauche à droite
Ajouter des commentaires

Les familles et les vues:

Utiliser les familles et les vues pour bien organiser la fondation de données

Créer une famille par thème/axe d'analyse/table de faits/Tables dérivées…
Ajouter une légende pour les couleurs

Créer une vue par contexte

Exemple d'utilisation de ces deux points :  

Pas de table isolée :

Toute table utilisée ne doit pas être isolée. Il faut éviter les produits cartésiens

Les jointures doivent se faire sur des indexs :

S’assurer que toutes les jointures implémentées dans l’univers ont des indexs correspondants.

Dans les jointures éviter :

Les jointures externes

les formules

les jointures avec Or

les jointures n-n

les jointures 1-1

Une modélisation bien faite est donc nécessaire avant de développer l’univers.

Jointure isolée :

Eviter les jointures ne faisant partie d’aucun contexte

Cardinalités :

Les cardinalités doivent être toujours définies

Ne pas détecter automatiquement

Pas de génération automatiques des jointures :

Il vaut mieux les faire manuellement

Les contextes :

Créer un contexte par table de faits

Donner un nom métier au contexte

SQL options :

Ne pas autoriser les produits cartésiens

Cocher plusieurs SQL pour chaque contexte

Quelques astuces :

Ajout d'une jointure :

Bien choisir le sens de la jointure (de la table contenant la clé primaire vers celle qui contient la clé étrangère) quand on déssine le trait correspondant

Lorsqu'on ajoute une jointure il faut s'assurer qu'elle ne reste pas neutre, il faut l'inclure dans les contextes correspondants et l'exclure des autres.

Le fait de laisser une jointure neutre (pour 1 ou plusieurs contextes) peut générer des problèmes de boucles , de produit cartésien ou d'incompatibilité

Suppression d'une jointure :

Pour supprimer une jointure il faut s'assurer que cette jointure est neutre (par rapport à tous les contextes) avant la suppression, il faut donc vérifier tous les contextes pour la rendre neutre.

La suppression d'une jointure inclue ou exclue d'un contexte supprimera aussi ce contexte (mais on est alerté).

Modification d'une table dans une jointure :

Pour modifier une jointure (remplacer l'une des tables par une autre), il suffit d'ouvrir la jointure et de la modifier dans la fenêtre affichée (modifier la table, puis choisir les colonnes). Pas besoin de la supprimer et de créer une nouvelle.

Ceci fonctionnera même si on veut remplacer toutes les tables de la jointure.

Et la jointure reste dans tous les contextes (ça nous évite donc de supprimer/ajouter une jointure et de parcourir tous les contextes pour ajouter la nouvelle jointure).

Couche de gestion

Options de requêtes : 

• Plusieurs SQL pour chaque mesure : éviter de cocher cette option. Le fait de cocher cette option générera une requête SQL par indicateurs (même si plusieurs indicateurs sont dans la même table). Cette règle (ne pas cocher cette option) sous-entend une modélisation bien faite (pas de problème de doublons, contextes bien définis...).
• Garder les autres options cochées
• Les limites : les limites sont à paramétrer en fonction de la taille de la base et des rapports. Pour éviter les mauvaises surprises ( résultats partiels, arrêt de la requête, ...) ne pas cocher ces limites.

Description : 
Utiliser le champ description pour décrire fonctionnellement l'univers

Commentaires : 
Utiliser ce champ pour le versionning avec description de chaque modification

Les indicateurs :

- Donner un nom unique en respectant les règles de nommage
- Toujours donner une description fonctionnelle de l'indicateur à définir avec le métier. Préciser s'il y a des spécificités particulières
- La fonction SQL d'agrégat doit être définie dans la clause SELECT.
- Eviter, dans la mesure du possible, de renseigner les clauses WHERE. Si besoin utiliser la fonction decode (IfElse) dans la clause SELECT.
- Définir la fonction de projection.

Les dimensions :

- Donner un nom unique en respectant les règles de nommage
- Toujours donner une description fonctionnelle de l'indicateur à définir avec le métier. Préciser s'il y a des spécificités particulières
- Eviter, dans la mesure du possible, de renseigner les clauses WHERE.

La fonction @Select :
La fonction @select permet de simplifier: 
- Les SQL complexes
- La maintenance des objets s'ils sont liés entre eux


Requêtes : 
Utiliser systématiquement les requêtes SQL pour tester

Vérifier l'intégrité : 
à faire systématiquement, surtout avant chaque publication

HTML : 
Utiliser les balises HTML pour donner des couleurs à la description de l'objet : 

Focus Performance :

Tables dérivées :

À éviter dans la mesure du possible. À la place créer des tables ou des vues matérialisées.

Raccourci jointure :

Utiliser les raccourcis jointures dans la mesure du possible pour réduire le nombre de tables dans la requête

Nombre de lignes :

Toujours afficher le nombre de lignes de chaque table. Principalement pour deux raisons :

Repérer facilement les tables avec des données manquantes

Pour vérifier l’intégrité des cardinalités des jointures

Affichage du nombre de lignes : 

Les indexs :

Le but des indexs est de substituer les Identifiants aux descriptions afin de gagner en performance.

Les indexs permettent d’éliminer certains jointures et d’utiliser les clés étrangères.

À utiliser principalement sur des objets description sur lesquels il y a des filtres.

L’index remplace le filtre sur la description par un filtre sur l’Identifiant.

Les clés primaires et les clés étrangères doivent être définies pour chaque objet qu’on veut remplacer par un index :

Aggregate Awareness :

-La fonction Aggregate Awareness permet de choisir le chemin optimal en fonction du niveau de détail demandé dans la requête
-Les étapes nécessaires :
-Définir les tables d’agrégats
-Définir l’objet avec la fonction @Aggregate_Aware
-Définir les incompatibilités des classes/objets avec les tables d’agrégats

Univers mono vs multi-source :

Préférer l'univers mono-source en raison de la générative native du SQL

Array Fetch Size : 
Cette option définit le nombre de lignes ramenées à chaque extraction. La valeur par défaut est 10, mais elle peut être augmentée jusqu'à 1000 pour de meilleurs performances mais cela nécessite plus de mémoire.
Il faut tester plusieurs valeurs jusqu'à trouver le bon équilibre avec le transfert réseau.


A utiliser sans modération :)