Questions autour de la version 2 du module Business Intelligence (BI)

Cette page regroupe les questions fréquentes sur la version 2 du module Business Intelligence (BI).

 

Voir aussi

Le module de business intelligence en version 2

https://forterro-fwe.atlassian.net/wiki/spaces/S9KB/pages/704643340

Vous utilisiez déjà la version 1 du module…

Est-ce que les modélisations existantes continueront de fonctionner ?

Oui, la nouvelle version apporte son lot de nouveautés qui restent pleinement compatibles avec l’existant.

Quel est l’impact sur le tarif ?

La version 2 et ses nouvelles fonctionnalités d’ensemble de données à la demande s’accompagnent d'une facturation à la consommation en cloud sur les données stockées dans le datawarehouse et dans la mémoire de QuickSight (le SPICE).

Afin de laisser à nos clients déjà en version 1 le temps de s’adapter à ce nouveau mode de facturation, nous avons souhaité ne pas impacter votre commande courante. Les nouvelles règles de facturation s’appliqueront à partir de la date anniversaire de votre souscription.

D’ici là, vous bénéficiez d’un espace de données dans votre datawarehouse et votre SPICE QuickSight équivalent à votre consommation actuelle + 20%. Les données d’analyse présentes dans la nouvelle version du datawarehouse vous permette un suivi précis de ces consommations (cf. https://forterro-fwe.atlassian.net/wiki/spaces/S9KB/pages/708837392/Informations+de+suivi+et+d+historique+sur+les+ex+cutions+de+l+ETL+-+module+BI#Suivi-mensuel-des-consommations-du-datawarehouse-et-du-SPICE---vue-%E2%80%9C_monthly_consumption_monitoring%E2%80%9D).

N’hésitez pas à contacter votre commercial pour plus de précision.

Quelles sont les modifications de comportement introduites par la version 2 ?

Même si l’objectif lors de la mise en place de la version 2 était de ne pas avoir d’impact concernant les traitements de la version 1, des comportements ont tout de même été modifiés :

Désactivation des vues V1

Historiquement le module BI V1 mettait à disposition un ensemble de vues. Mais ces vues pouvaient provoquer des risques techniques non maitrisables sur leur génération.

Ces vues ne sont plus proposées dans le cadre des nouvelles installations mais restent toutefois présentes pour des raisons de compatibilité pour les installations déjà existantes. En revanche, un mécanisme a été mis en place pour les désactiver automatiquement si elles dépassent une certaine limite en nombre de champs (1600). Cette limite peut être atteinte si un trop grand nombre d’attributs supplémentaires est transféré vers l’outil de reporting.

Une vue désactivée automatiquement ne peut plus être réactivée.

Refonte du mécanisme de rafraichissement du “SPICE” des “datasets”

Le mécanisme de rafraichissement du “SPICE” des “datasets” possède maintenant une file d’attente. Au maximum deux “datasets” peuvent être mis à jour en parallèle et c’est uniquement lorsque l’un des deux est terminé qu’un nouveau peut se lancer.

De plus, comme évoqué dans les vidéos de présentation, les “datasets” peuvent être mis à jour en cascade, ce qui peut donner lieu à un plus grand nombre de “datasets” éligibles à être mis à jour lors du passage dans la version 2.

La durée maximale de l’ETL est désormais bornée (6h maximum en contexte Cloud)

Nous avons fixé une durée maximale d’ETL à 6h. Au delà de ce temps, les traitements sont stoppés et ils sont marqués en “Time out”.

Cette limite est rendu nécessaire du fait du mode de fonctionnement du cette version 2 où le nombre de requêtes d’extraction est variable et nécessite une limite.


Dans tous les cas, voici une série de questions sur le fonctionnement…

Quels sont les apports majeurs de la version 2 du module ?

Les 2 principales fonctionnalités adressent la constitution des ensembles de données et la facilité d’usage dans QuickSight :

  • Une requête du système d’information peut être déclarée comme ensemble de données dans le datawarehouse. Tous les données accessibles depuis le système d’information sont concernées : entités standard, supplémentaires et spécifiques, attributs standards et attributs supplémentaires. La requête doit remplir quelques conditions pour être éligibles (pas de filtres, pas d’attributs experts).

  • Une requête du système d’information déclarée comme ensemble de données dans le datawarehouse est disponible en tant que dataset dans QuickSight, en conservant le libellé et l’organisation de la requête d’origine.

De plus, des informations présentes dans le datawarehouse permettent de suivre l'état de rafraichissement de ces données afin de s’assurer que les données sont bien à jour. Ces informations sont présentées également sous la forme de tableau de bord standard QuickSight.

Quelles sont les limites fonctionnelles du module BI V2 ?

Au niveau de la définition de la requête du système d’information

Raison / Solution

Lors de l'étape 1 de la création d’une requête du système d’information, la sélection directe d’une entité n’est pas autorisé.

image-20241029-132332.png

Il est nécessaire de sélectionner directement les champs que l’on désire exporter pour cette entité.

image-20241029-132442.png

Le libellé d’un attribut pour une requête du système d’information :

  • doit être unique,

  • doit respecter un certain formalisme : pas de libellé vide, pas de mot clef réservé SQL, pas le libellé commençant par un chiffre.

Ces libellés sont directement utilisés pour générer des colonnes dans une table du datawarehouse. Cela permet d’avoir des noms de colonnes explicites lors de l’interrogation des données et évite d’avoir deux colonnes ayant le même nom (ce qui est techniquement impossible).

Les attributs experts ne sont pas autorisés.

Les traitements doivent être réalisés directement dans l’environnement décisionnel.

Lors de l'étape 2 de la création d’une requête du système d’information, les critères, les tris ainsi que les options sont ignorés par la requête d’extraction.

Une requête d’extraction exporte de la donnée brute vers le datawarehouse.

Les opérations de tris, de filtres, de calcul ou d’agrégation doivent être réalisées dans l’environnement décisionnel.

Lors de la sauvegarde d’une requête du système d’information, il peut être nécessaire de régénérer les données en relation avec celle ci dans le datawarehouse (notion de régénération nécessaire).

Cela se produit lors de modifications structurelles ou importantes de la requête du système d’information. Par exemple :

  • ajout de nouveau(x) lien(s) (jointures) devant être pris en compte dans la détermination de l’identifiant unique d’une ligne dans le datawarehouse,

  • ajout de colonnes trop important (>5) sur une requête déjà existante (nécessitant de mettre à jour l’ensemble des données dans le datawarehouse sans allotissement).

Au niveau du traitement ETL

 

Sur les environnements Cloud, la durée d’exécution maximale est fixée à 6 heures. Au delà, les traitements sont stoppés en “TimeOut”.

Cette limite a pour objectif de permettre aux traitements de pouvoir s’exécuter durant la nuit sans empiéter sur les heures de travail “classique”.

Des options permettant d’augmenter la puissance de l’environnement décisionnel sont disponibles afin de pouvoir réaliser plus de traitements dans le délai imparti.

En phase de construction du reporting, est-il possible d'exécuter l'ETL plus fréquemment ?

Période de mise à jour des données - Comment fonctionne la mise à jour des données hors de cette période ?

Comment est organisé le datawarehouse ?

Comment savoir si mes données sont bien à jour dans le datawarehouse ?

Comment connaitre ma consommation de données ?