En quoi un dataware complète idéalement les applicatifs Oracle EPM Cloud ? - RETEX Dalkia

Contenu

Dans ce troisième article sur notre retour d’expérience technologique de notre projet Dalkia, nous faisons un focus sur la partie intégration dans les SI à travers un complément qui se révèle indispensable : une base de données relationnelle.

La technologie de la plateforme EPM Cloud est exclusivement basée sur le moteur Essbase, stockage multidimensionnel, excluant la mise à disposition de technologies relationnelles dans la souscription. Dans les architectures BI classiques, Essbase et base relationnelle cohabitaient en tant que “DataWare” et “Datamart” avec des liens natifs et performants. Ces termes semblent désormais “vintage” à l’heure du Big Data mais les usages demeurent.

Le projet Dalkia nous a montré que pour répondre aux multiples usages d’un projet d’ampleur, il semble indispensable de compléter la plateforme Oracle EPM d’une technologie complémentaire relationnelle. Tour d’horizon de ces usages clefs pour le troisième volet de notre retour d’expérience du projet Dalkia.

 

Intégration avec le SI client : La base relationnelle comme point d’ancrage de l’EPM Cloud

Le prérequis le plus simple et naturel pour ancrer un applicatif EPM dans le cloud au sein d’un système d’information passe par la mise à disposition d’un serveur interne, qui va se transformer en “véritable hub”. Accompagné de l’utilitaire EPM Automate (ou des API équivalentes), il va permettre d’harmoniser les méthodes d’envoi, de facilité la maintenance, ainsi que la sécurité des données avant envoi.

Ce serveur Intermédiaire que l’on nommera dans le contexte STID (Serveur de Transfert des Informations et Données) contient aussi une base de données relationnelle Microsoft SQL Server que l’on utilise pour la base de données, ainsi que l’ETL SSIS, et la partie planning de l’agent SQL. Choix technologique classique, pouvant être Cloud via Azure ou On Premise.

 

Volumétrie & EPM : Des solutions applicatives

L’EPM Cloud n’a plus peur des fortes volumétries. Comme décrit dans les premiers épisodes de ce RETEX Dalkia, l’architecture BSO/ASO répond aux problématiques de finesse d’analyse et de construction des données. La granularité est donc la même entre notre base relationnelle et l’EPM Cloud.

 

Faire vivre le référentiel

Néanmoins, les opérations de gestion de référentiel, très variable et dynamique quotidiennement sur la dimension “Projet” nécessita une approche des processus de mise à jour industrialisée ou la base de données relationnelle sera la clef de voute.

Pour information, la dimension Projet contient :

  • 5 hiérarchies dont une hiérarchie dite « Technique »,
  • 54.000 membres de niveau fin répartie sur 8 applications,
  • 69.600 membres pour la plus grosse hiérarchie,
  • 81.800 membres pour la plus grosse application hors Corporate qui a 235.000 membres avec une hiérarchie en moins

 

Image_Oracle_EPM_Cloud_1

 

 

Faire vivre quotidiennement cette dimension, en interaction directe avec les utilisateurs a été un défi pour inventer des usages, au-delà des standards d’EPM Cloud. Ainsi, la mise à jour de cette dimension est alimentée par plusieurs fichiers, qui contient plusieurs hiérarchies et qui doit rester dynamique (changement d’affectation avec conservation des données).

L’intérêt de la base de données permet ici de centraliser tous les fichiers puis de réaliser différentes opérations par un traitement nocturne planifié :

  • Vérifier certaines règles de gestion du type unicité des membres dans chaque hiérarchie, unicité des alias...
  • Rapprocher les différents éléments venant de fichiers différents pour permettre la création de la dimension avec ses hiérarchies et ses attributs,
  • Alimenter les dimensions d’attribut rattaché à la dimension Projet,
  • Créer les différentes hiérarchies de la dimension Projet (avec des informations de type date pour des visions de type “pro forma”)
  • Mettre à jour les différentes applications découpées en 8 Régions,
  • Alimenter la dimension projet en 3 étapes, pour garantir la stabilité du modèle :
    • Mise à jour du niveau 0 avec les attributs,
    • Suppression des hiérarchies secondaires
    • Créations des hiérarchies de la dimension en reprenant la sécurité existante sur la dimension

 

Intégrer les données en garantissant leur qualité

Classiquement, plusieurs sources de données sont à intégrer dans EPM Cloud, avec la contrainte suivante d’avoir un fichier source pour 8 applications cibles, avec la subtilité que le critère discriminant n’était pas dans le fichier mais dans le référentiel Projet. Notre base de données devient ainsi la “gare de triage” de la donnée.

En plus de cette répartition, la base de données enrichit l’interface par des vérifications de cohérence de toutes les dimensions avant de lancer l’importation dans les différentes applications. Cette méthode permet d’uniformiser les interfaces, de réduire la maintenance (fichier de log énumérant les membres manquants par exemple).

 

Extrait de l’intégration des data vers EPM Cloud avec l’ETL SSIS :

Image_Schéma_Oracle_EPM_Cloud

Extrait des batchs d'intégration des données

 

 

Image_Schéma_Oracle_EPM_Cloud_2

 

Inventer de nouveaux usages : la saisie de masse

Pour aller au-delà des fonctionnalités standards de la suite EPM Cloud, nous y avons ajouté une application web permettant aux utilisateurs de déposer des fichiers sur le serveur pour être intégrés dans EPM Cloud pour une “saisie de masse”. Notre base de données sert d’instance de dialogue entre cet applicatif, assez basique, et EPM Cloud pour respecter une cohérence d’ensemble :

  • Récupération de la sécurité EPM Cloud rattachée à la hiérarchie projet pour être utilisée par l’application web (usage combiné des ETL SSIS et de l’utilitaire EPM automate)
  • Récupération dans la base de données des différentes dimensions,
  • Traitement pour prendre en compte les fichiers déposés par les utilisateurs par l’intermédiaire de l’application web :
    • Validation de la conformité du format du fichier,
    • Vérification de certaines conditions concernant le contenu du fichier,
    • Vérification de l’existence des membres pour chaque dimension,
    • Vérification des droits d’accès suivant la sécurité EPM CLOUD liés aux projets,
    • Vérification des comptes si la saisie est acceptable suivant une liste de compte, présent dans la base
  • Lancement de l’intégration du fichier suivant le retour des contrôle et envoi de mail validant les contrôles et/ou remontant le/les raisons du rejet du fichier à l’utilisateur ayant déposé le fichier

La base de données avec l’aide de l’ETL SSIS a permis de réaliser toutes ses opérations sans surcharge du serveur cloud.

 

 

Image_Oracle_EPM_Cloud_2

Application Web permettant de déposer des fichiers ou de récupérer des fichiers sur le serveur STID

 

 

Arborescence de l’application web sur le serveur pour le dépôt des fichiers avec un dossier par étape :

  • Etape 1 dépôt du fichier mis dans le dossier en attente
  • Etape 2 fichier pris en compte par le job de saisie de masse dossier Pris en compte
  • Etape 3 fichier intégré (dossier traité) ou fichier rejeté (dossier erreur)

 

Image_Oracle_EPM_Cloud_3

 

 

 

Image_Oracle_EPM_Cloud_4

Exemple de mail partie Excel de fichier rejeté

 

 

Exporter la donnée après l'avoir travaillée

Les fonctions de consommation de la donnée sont tout aussi classiquement exportés des applicatifs EPM Cloud (usage complémentaire de BI, Big Data, échange avec la consolidation …)

L’utilisation de STID a été donc requise pour extraire la masse de données à requêter sur des formats particuliers.

 Pour réaliser le traitement, des jobs ont été construits et ordonnancés :

  • Extraction de masse des données EPM Cloud avec Data Management,
  • Récupération des données pour être traitées dans la base de données,
  • Utilisation des informations dans la base de données pour générer le rapport,
  • Génération des rapports suivant la sécurité de EPM Cloud,
  • Mise à disposition du rapport dans l’application web

 

 

Image_Oracle_EPM_Cloud_5

Arborescence de l’application web sur le serveur correspondant à une hiérarchie de la dimension projet pour les 2 niveaux le plus haut ou on met les fichiers générés :

 

 

 

Image_Oracle_EPM_Cloud_6

Extrait d’un rapport généré au format csv et mis à disposition des outils tiers.

 

 

Maintenir l'applicatif

Dernier usage, orienté back-office, nous avons optimisé la maintenance applicative pour une application stable et constante dans le temps. Sous EPM Cloud, la planification des tâches de maintenance est aisée, mais paramétrer une dépendance n’est pas natif dans ses diverses actions (restructuration, reset application, règle de calcul…).

En utilisant le serveur STID, les tâches de maintenance sont lancées de façon séquentielles, sous condition de réussite ou de paramètres particuliers.

La réalisation de ce flux permet de planifier l’heure de lancement et le job réalise les différentes tâches paramétrées (en semaine 14 actions réalisées sur les 8 applications).

 

Image_Oracle_EPM_Cloud_7

 

 

Cet article clôt notre retour d’expérience sur le projet Dalkia.

 

Pour répondre aux enjeux d’un projet comme SELENE chez Dalkia, avec ses applicatifs utilisés quotidiennement par des milliers d’utilisateurs, les équipes de Klee ont su dépasser les cas d’usage standard, pour offrir des solutions pragmatiques, dans le prolongement des fonctionnalités d’EPM Cloud.

La base de données a été la clef de voûte de ces solutions innovantes et a permis de répondre à tous les usages. Pour les projets de toute échelle, ces usages sont réplicables aisément afin de pleinement satisfaire les utilisateurs métiers.

 

CTA_Article_Blog_RETEX_Dalkia_Groovy

 

Tags
#oracle
#EPM
#Cloud