Interfacer nativement ses systèmes avec OneStream

Contenu
Vignette_Article_Blog_OneStream

 

Dans un projet EPM, la partie Interfaces est souvent l’un des enjeux clefs pour récupérer entre autres, les données en provenance des systèmes transactionnels qui seront la base du reporting et/ou d’une initialisation de Budget.

 

La plateforme OneStream embarque nativement la gestion des chargements de données et permet de gérer soit des connections directes sur les systèmes sources, soit des alimentations via fichiers plats. Nous allons au travers de cet article décrire les capacités avancées de la solution en matière d’alimentation de fichiers plats.

 

 

Interface de chargement de données

 

 

La gestion des  interfaces dans OneStream se fait au travers de 2 étapes :

  • L’identification des data sources
  • Les transformations rules

 

Les data sources permettent d’associer les colonnes des fichiers de données aux dimensions dans l’application OneStream.

 

 

Les transformations rules permettent de définir les mappings pour chaque membre apparaissant dans les fichiers de données. Généralement les utilisateurs finaux ont seulement accès aux transformations rules afin de pouvoir maintenir les mappings des membres des dimensions.

 

 

 

 

Nous allons illustrer ci-après au travers d’un exemple concret les problématiques que nous pouvons rencontrer lors de la mise en place d’interfaces.

Un des cas rencontré en projet, était d’appliquer un mapping différent sur les axes analytiques selon le type de compte.
 

Il y avait deux distinctions à faire au niveau des comptes :

  • La première était de distinguer les comptes P&L des comptes de bilan. Cette distinction permettait d’appliquer un mapping spécifique sur les axes analytiques pour les comptes du P&L et de charger les lignes associées aux comptes de bilan sans détail analytique. Les utilisateurs ayant pour mission de maintenir et de mettre à jour les mappings des membres dans les Transformations Rules, nous avons fait en sorte de gérer la première distinction des mappings des comptes directement au niveau de la Data Source.

Nous voulions différencier les lignes du P&L et les lignes de bilan avant l’étape des Transformations Rules ; pour cela nous avons utilisé la dimension Flux. Toutes les lignes du P&L ayant pour membre le flux F99, par déduction toutes les autres lignes ne contenant pas de flux F99 étant forcément des lignes de bilan.


Dans le Data Source où chaque colonne du fichier de données est associée à une dimension OneStream, une règle a été mise en place au niveau de chaque axe analytique. Cela a permis de catégoriser toutes les lignes du P&L et toutes lignes du bilan afin de faciliter les mappings des membres dans les Transformations Rules et d’éviter le mapping membre par membre (One-To-One).

 

Règle de calcul associée à une dimension analytique.

 

 

  • Une seconde distinction se fait au sein même de la hiérarchie des comptes du P&L.

Le mapping des membres analytiques ne se fait pas sur la totalité des comptes du P&L mais seulement sur les comptes appartenant à l’EBIT. Les lignes qui ont pour compte un membre de l’EBIT devaient être mappées de manière détaillée et ceux n’appartenant pas à l’EBIT devaient être mappés sur un membre NO_DIMENSION (axe analytique).


Nous devions pouvoir identifier les comptes sources étant mappés vers des comptes de l’EBIT dans la dimension Account de l’application. La problématique qui s’est posée est que l’on ne connaissait pas la nature des comptes sources lors du chargement de fichier de données.

La première approche avait été de lister les comptes sources qui sont mappés vers des comptes EBIT dans OneStream, en partant de ces derniers et en faisant le mapping inverse. L’inconvénient de cette approche est qu’elle nécessite une maintenance fastidieuse par les utilisateurs et une performance peu satisfaisante au regard du volume à traiter.

Afin de faciliter cette tâche il était important de trouver un moyen d’identifier automatiquement si le compte source était dans l’EBIT ou non afin d’appliquer les mappings spécifiques sur les axes analytiques.

 

 


La solution OneStream permet de gérer principalement trois types de mappings :

  • Le mapping One-to-One qui permet de mapper un membre de dimension source vers un membre de dimension cible de manière explicite. Ce type mapping est le premier mapping qui s’applique ; le choix des types de mapping est donc important pour les priorités.
  • Le mapping Mask permet de mapper un large choix de membres avec des critères en utilisant les caractères * et ?.
  • Le mapping Composite qui permet de combiner plusieurs dimensions source

 

Exemple d’un mapping One-to-One

 

 

 


Exemple d’un mapping Mask

 

 

 

Dans chaque axe analytique nous avons fait en sorte d’appliquer un mapping One To One car c’est le plus performant. Ce mapping devant s’appliquer seulement pour les lignes contenant des comptes EBIT nous avons dû gérer cette spécificité dans le mapping Mask.

Dans le but de savoir si un compte source appartenait à l’EBIT ou non de façon automatique, une règle de calcul a été mise en place dans les mapping Mask de chaque axe analytique. Cette règle permet dans un premier temps comme on peut le voir ci-dessous, de tester si un compte source a été mappé vers un compte EBIT dans le mapping One to One du mapping Account.

 

 

 

 

 

Une fois tous les comptes de l’EBIT récupérés, on applique le mapping One To One sur les axes analytiques. Ce dernier ayant été appliqué avant le mapping Mask et ne pouvant se réitérer, nous avons utilisé une table SQL “StageRuleGroup” afin de récupérer la mapping One to One de l’axe analytique.

 

 

 

 

Grâce à cette solution nous avons pu gérer les mappings de tous les types de compte de manière automatique sans que les utilisateurs aient à maintenir un mapping fastidieux et qui soit performant en terme de temps de traitement.

 

Ces cas présentés nous ont permis de confirmer la capacité de OneStream à traiter des cas de transformation de données vers un modèle de données complexe pour assurer une complète intégration de la solution EPM dans les paysages IT de nos clients.

Tags
#Outil