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

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

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/S5KB/pages/712900831/Informations+de+suivi+et+d+historique+sur+les+ex+cutions+de+l+ETL+-+module+BI#Statut-de-mise-%C3%A0-jour-des-requ%C3%AAtes-d%E2%80%99extractions-lors-du-dernier-ETL-(vue-_info_history_last_executions) ).

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

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.

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.

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.

Non, cela n'est pas possible, c'est une des limites actuelle de notre solution.

La fonctionnalité de prévisualisation des données permet en partie de répondre à ce besoin en permettant de visualiser le futur format des données dans le Datawarehouse et de mieux se projeter sur leur future utilisation.

Cette limite est toutefois identifiée et est éligible aux futures évolutions majeures de ce module.

Le paramétrage de la période de mise à jour des données est réalisable directement depuis la requête d’extraction et une aide contextuelle en décrit le fonctionnement.

Concernant les données présentes hors de cette période de mise à jour, plusieurs cas sont possibles…
Pour pouvoir décrire ces différents cas il est nécessaire de comprendre comment sont identifiés les enregistrements dans le “datawarehouse”, à savoir, pour chaque ligne:

• Un identifiant unique est généré : cet identifiant unique est généré en se basant sur les entités qui composent la requête du système d'information de manière à s’assurer de l'unicité de la donnée.

• Une date de mise à jour de la donnée est calculée : cette date de mise à jour, contrairement à la règle de détermination de l’identifiant unique tient compte de l’ensemble des entités présentes dans la requête.

Les cas possibles en termes de mise à jour concernant les données présentes dans le datawarehouse hors période de mise à jour sont donc les suivants :

• L’identifiant unique généré est toujours le même : dans le cas où des données sont modifiées sans changer l’identifiant unique généré, lors de la détection d’une modification, l’ETL est capable de mettre à jour ces données anciennes.

• L’identifiant unique est altéré ou un lien est supprimé : dans ce cas ces modifications ne peuvent pas être détectées par les traitements ETL et il en résulte la présence de l’ancien enregistrement dans le datawarehouse.

Pour contrer ce mécanisme, deux options sont possibles :

• Adapter la période de mise à jour des données pour qu’elle couvre une période de temps suffisamment grande pour que des modifications sur des données anciennes soient marginales.

• Utiliser les informations de suivi pour détecter quelles sont les requêtes d’extraction qui possèdent des écarts en termes de nombre de données entre le datawarehouse et l’ERP (la vue “info_history_last_executions” ou la table “_info_query_history” via les champs “source_row_number” et “dwh_row_number”) et, en cas d’écart, utiliser la fonctionnalité de “Forcer la régénération complète des données” depuis l’ERP sur la requête d’extraction.

Les données présentes dans le datawarehouse sont réparties à travers différents schémas (au sens base de données) :

• Schémas “nomClient_Société_Domaine” : un schéma par domaine fonctionnel qui contient l’ensemble des tables qui sont générées par les traitements du module BI V1.

• Schéma “nomClient” : contient les tables d'historique d’exécution de l’ETL et des datasets dans QuickSight.

• Schéma “nomClient_Société” : contient les tables extraites du module BI V2 ainsi que les tables de suivi et d’historique du module BI V2.

Module BI V1 société MONO

Module BI V1 société MULTI

Module BI V2 société MONO et MULTI

Le détail des tables d’historisation et de suivi est décrit dans la page Informations de suivi et d’historique sur les exécutions de l’ETL - module BI .

Plusieurs méthodes offrant différents niveau de visibilité sont possibles. Elles sont fournies par le biais des Informations de suivi et d’historique sur les exécutions de l’ETL.

Une vue dédiée (vue “_monthly_consumption_monitoring”) est proposée dans le datawarehouse afin de fournir ces informations.