Comment le Groovy peut sauver votre application Oracle Planning EPM ? RETEX Dalkia

La plateforme Oracle EPM innove avec notamment l’intégration de la technologie « Groovy » dans ses versions Enterprise. En quoi cet apport est désormais indispensable pour la réussite de votre projet ou de votre migration EPM ? Performance ou ergonomie détaillées en retour d’expérience de notre projet DALKIA. Article de référence technologique par Hassan Chatir et Nicolas Cuesta, chefs de projet chez Klee Performance.

Comment un langage créé il y dix-huit ans pourrait-il nous permettre d’optimiser les applications (E)PBCS en 2021 ?

En 2003, James Strachan et Bob McWhirter lancent un projet Open Source, nom de code « Groovy ». Langage de script orienté objet qui s'inspire entre autres de Python, Java, Ruby et Smalltalk, il est dynamique, agile avec une syntaxe proche de Java qui lui permet d’être réutilisé dans les librairies de ce dernier. Les domaines d’application sont nombreux et les fonctionnalités « clefs en main » du langage permettent de manipuler du XML, des collections, etc.

Quel est le lien avec Oracle EPM Cloud et PBCS me direz-vous ? Groovy est utilisable dans les applications financières et plus particulièrement dans nos outils EPM Oracle. Son principal intérêt ? Le transfert de données !

Parlons projet, application, temps de calcul… Lorsque nous déployons une application d'allocation Essbase, les résultats sont justes, les traitements rapides et la création de rapports aisée. Les utilisateurs sont satisfaits, tout le monde est content. Au fil des mois, les premiers problèmes apparaissent, les temps de traitements augmentent proportionnellement au volume de la base, les rapports ne s’ouvrent plus aussi vite qu’au premier jour et dans le pire des cas les utilisateurs perdent confiance en l’outils et se tournent vers Excel. L’allocation et le reporting sont deux parties intégrantes de la finance et de la comptabilité, mais les ressources informatiques utilisées peuvent être dissociées. La méthode de stockage BSO (Block Storage Option) est très populaire car première option disponible dans Essbase, elle répond parfaitement aux besoins financiers, mais est limitée par la taille de base. L'ASO (Agregate Storage Option), introduite plus tard, est beaucoup plus rapide pour l’agrégation des données et la création de rapports, mais ses capacités de calcul sont limitées.

Pourquoi ne pas utiliser le meilleur des deux mondes ? La combinaison des deux technologies permettrait-elle aux directions financières de disposer d’une allocation rapide et de rapports robustes ? Le stockage des données sur le cube BSO étant réduit, la création des blocs moindre, les calculs d’allocation seraient plus rapides tout comme l’agrégation déplacée vers l’ASO. Tous ces avantages permettraient aux équipes d’obtenir des données financières plus rapidement et de meilleure qualité. Comment lier ces deux « mondes » ? La réponse est Groovy ! L'un des défis Essbase est la capacité à transférer en temps réel les données entre les applications. En juin 2017 et la sortie de « Groovy Calculations », la possibilité de synchroniser les bases presque instantanément est devenue possible. Lorsqu'un utilisateur soumet ses montants, le résultat agrégé apparait quelques secondes plus tard !

Le script Groovy est le chainon manquant permettant un transfert de données efficient entre les cubes BSO et ASO. Techniquement, le processus se déroule en deux étapes, mais avant allons découvrir ce que PBCS propose pour faire ce transfert :

1. Transfert des données via des SmartPush

Le Smartpush dans PBCS permet d’envoyer des données d’un cube de calcul (BSO : Saisie et calcul au niveau fin) vers un cube de restitution (ASO : données agrégées). Ce transfert demande de définir le périmètre et peut être exécuté de deux manière différentes :

         1.1 A la sauvegarde des données saisies : Périmètre du formulaire seulement

Ce procédé est proposé par PBCS pour envoyer toutes les données qui existent dans le périmètre d’un formulaire de saisie :

                  a. Saisie des données

                 b. Enregistrement des données, lancement d’un calcul de mensualisation et envoi via smartPush
                 

                 c. Résultat : Les données ont été envoyées

Avantage : Envoi rapide du périmètre de saisie.

Inconvénients : 1. Si on veut envoyer un périmètre calculé en dehors du formulaire, ce n'est pas possible | 2. Si on veut envoyer que les cellules modifiées dans le formulaire, ce n'est pas possible.

 1.2 A la sauvegarde des données saisies : Périmètre du formulaire et au-delà

Avec Groovy, on procède de la même manière sur la forme, la saisie est parfaitement pareil, mais à la fin, l’utilisateur fait clic droit et lance un calcul qui :

                  a. Saisie des données

                b. Calcul d'un autre périmètre et envoi des données

                c. Calcul :

• Un calcul a été lancé pour stocker la donnée saisie sur la société du projet.
• Le calcul Groovy : récupère la nouvelle calculée et l’envoi au cube de restitution (affichage en bas de la page)

                d. En arrière-plan le Groovy :

                e. Résultat : les données en dehors du formulaire ont été envoyées au cube de restitution.

Avantage : 1. On peut envoyer n’importe quelle donnée qu’elle soit dans le périmètre du formulaire ou non | 2. Temps d'envoi très rapide.

Inconvénients : 1. Si on veut envoyer une grande quantité de données, on utilise le Grovvy mais pas avec cette méthode, avec la suivante.

2. Transfert des données via des DataMap

La DataMap est le périmètre de données à utiliser pour envoyer les données. Il est utilisé par le smartPush pour envoi d’une quantité de données ne dépassant pas les 250 000 cellules et surtout lié à un formulaire. Le DataMap est lié à l’application et n’a pas de limité de taille de données à envoyer, mais doit être envoyé par un profile administrateur.

Un DataMap par un administrateur s’exécute soit manuellement soir avec une ligne de Groovy :

Pour que se soit transparent pour les utilisateurs qui n’ont pas de profil administrateurs et qui sont amenés à envoyer une grande quantité de données entre deux cubes : Figeage des données à un instant T, par exemple, le Groovy s’en occupe :

Résultat : Tout le périmètre figé des données est envoyé au cube de restitution pour consommation de données par les utilisateurs.

Avantage : Envoi rapide (quelques minutes Vs quelques heures auparavant) de toutes les données pour restitutions.

3. Isolation des données modifiées dans la base source (BSO)

Pour gagner encore plus de temps d’envoi des données saisie, on peut se limiter à l’envoi des seules cellules modifiées dans un formulaire.

Groovy arrive à isoler les données modifiées et créer une liste des seules cellules (membres) modifiées et qui vont être envoyées au cube de restitution ; l’envoi est presque du temps réel.

4. Volumétrie des bases de données BSO

La nouvelle architecture de deux cubes, permet d’avoir une taille beaucoup plus petite des deux cubes d’une application (celui de saisie et celui de restitution), comparée à la taille d’un seul cube de saisie et de restitution combinées.

La différence réside dans l’agrégation des données qui prend énormément d’espace et de temps de calcul est totalement isolée dans un cube ASO, qui a la particularité d’agréger les données nativement sans besoin de calcul. Quant au cube BSO (cube de saisie), il garde les données saisies ou calculées de niveau fin seulement.

Ajouté à cela le Groovy qui transfère les données de niveau fin en un temps rapide, nous gagnons sur tous les niveaux :

• Temps de calcul dans le cube BSO est réduit, vu qu’on calcule que les niveaux fins.
• Temps de transfert des données ultra rapide grâce via Groovy
• Temps d’agrégation des données et de restitutions dans l’ASO

L’exemple de Dalkia est significatif : Volumétrie de l’application (800 MB pour BSO + 929 MB pour l’ASO), comparée à 160 GB pour la même application avant refonte. 

Un régime minceur radical d’efficacité !

5. Performance de l'application

Avec cette architecture basée sur deux cubes séparés, la performance de chacun est optimisée au maximum :

• Temps de calculs rapide sur le cube BSO : Qui dit données de niveaux seulement, dit nombre de bloc maitrisé dans le cube BSO (moins de 2 millions de blocks)
• Une densité des blocks de données optimisée au maximum, vu que les données ne sont pas agrégées et ni dispersées.
• Les tâches de maintenance tournent rapidement, grâce à la taille maitrisée :
  • Suppression des blocks vides (en cas de fausse saisie)
  • Restructuration de l’application, pour remettre à un niveau optimal après plusieurs jours de saisie et de calcul
  • Suppression de 0 dans le cube de restitution, afin de n’avoir que des données chiffrées.
  • Agrégation préalable dans l’ASO pour une disponibilité rapide des données agrégées pour la restitution.

6. Ergonomie & expérience utilisateur

Le Groovy a aussi une carte à jouer sur l’ergonomie des formulaires de saisie et de restitution.

Il permet de colorier une ou plusieurs cellules pour avertir l’utilisateur qu’une saisie est manquante sur une cellule ou tout simplement modifier le code couleur si celui par défaut ne convient pas ou ne s’inscrit pas dans la charte graphique de l’entreprise.

Il peut aussi remplir des cellules avec des paramètres par défaut, tout en laissant le choix à l’utilisateur de les modifier si besoin

Il permet d’activer des contrôles avant même d’enregistrer la donnée dans la base, en appliquant une règle ou un seuil à ne pas dépasser.

Ci-dessous, la cellule dépasse le seuil de 10 000. La donnée n’a pas été enregistrée et la cellule s’est coloriée différemment avec un message explicatif.

7. Récupération des données agrégées de l'ASO vers le BSO

Pour des questions de contrôles des données ou d’allocation, nous aurions besoin parfois des données agrégées pour calculer des clés. Or les données agrégées sont dans le cube ASO de restitution.

La solution est d’utiliser le service web de PBCS et Groovy pour récupérer (via une interface Data Management) des données agrégées de l’ASO et les stocker sur des positions techniques dans le cube BSO. Nous avons donc les mêmes données mais pas détailler.

Nous pouvons faire les contrôles et calculer les clés d’allocations aisément.

La combinaison du service web de PBCS et de Groovy, permet d’exécuter plusieurs traitements PBCS comme Data Management depuis l’interface PBCS.

Conclusion

Le Groovy est donc une solution technique aux problèmes rencontrés dans beaucoup d’application Essbase/Planning : volumétrie trop importante impactant les temps de traitement et de calcul.

En résolvant ces problématiques, Comines en un juste usage des technologies ASO/BSO, les applications EPM Cloud Planning répondent à tout ce que l’on peut attendre de l’EPM, avec en bonus des éléments d’ergonomie amélioré.

Klee Performancevous conseille donc son usage sans modération pour des applications Oracle EPM aux limites surpassées.

Note :

Groovy est disponible :

• Les souscriptions de type E-PBCS
• Les souscriptions de type Enterprise

Il n’est pas disponible dans les souscriptions de type Standard, ou dans les anciennes souscriptions de type PBCS. Nous vous invitions à vous adresser à Oracle pour plus d’information.