La notion de « space » est une nouveauté dans l’univers BI SAP. Avec cette fonctionnalité, SAP entend offrir plus de « liberté » à ses utilisateurs. Et qui dit « liberté », dit « multiplicité de scénarios possibles ». Or, s’agissant d’une solution innovante (en comparaison à BW), il aurait été plus judicieux de guider les utilisateurs vers quelques cas d’utilisations.
Dans cet article, nous vous présentons une organisation des spaces au sein de SAP Datasphere. Le but n’étant pas de diffuser notre vision, mais d’aider à y voir clair dans son utilité afin que vous puissiez réfléchir à celle qui pourrait vous convenir.
Tout d’abord, Qu’est-ce qu’un space ?
Dans son dernier outil de datawarehousing (Datasphere), SAP a mis en œuvre un « objet » appelé « space ». Cet objet a pour utilité de créer des environnements de travail virtuels à l’intérieur desquels, seuls les membres pourront y accéder. Et comme dans la plupart des solutions informatiques, différents rôles donneront accès à différents usages.
Sans space, il n’est pas possible de commencer à travailler avec Datasphere.
Chaque space créé a une capacité de stockage qui lui est allouée (réajustable à souhait), et c’est aussi au niveau des spaces que se gèrent les connexions vers des systèmes source.
S’il fallait donner un équivalent au terme de « space », ça serait tout simplement un « dossier » au sein d’un réseau partagé. Bien évidemment, d’autres éléments de configuration de space sont disponibles mais vous l’aurez compris, l’idée de cet article n’est pas de passer en revue ces aspects-là.
Comment organise-t-on des « spaces » au sein de SAP Datasphere?
2 points essentiels avant d’entrer dans le vif du sujet :
Avant tout, il faut savoir qu’avec Datasphere, SAP remet complètement à plat sa philosophie en matière de gestion d’écosystème BI. Amis BWistes, prière de mettre de côté vos connaissances BW et allons acquérir de nouvelles connaissances.
Rassurez-vous, cela demande beaucoup moins de skills que ce qu’exige BW 😊
Il n’y a pas UNE façon d’organiser ses spaces. Je serais tenté de dire qu’il en existe autant qu’il y a de roadmap au sein des organisations BI.
Devoir administrer plusieurs spaces peut avoir quelques inconvénients comme par exemple répéter la création d’une connexion à un système source sur plusieurs spaces, ou encore ajouter un utilisateur dans plusieurs spaces.
Cette contrainte cache en réalité une vertu. A savoir, la sécurisation des données.
D’abord, rappelons qu’il existe 2 « applications » bien distincts à destination des utilisateurs :
le « Data-Builder » avant tout réservé aux équipes techniques.
Il sert à la création d’un modèle relationnel au sens technique du terme. En commençant par l’interrogation des éléments source, la création de différents objets techniques telles que des dimensions, hiérarchies, la gestion des textes, les flux de données, et autres…
le « Business-Builder » destiné aux équipes fonctionnelles.
Ce dernier servira à une population Métier désireuse de s’approprier ses données. En créant ses propres datasets, en concordance avec les besoins du terrain, et à partir des éléments fournis par le Data-Builder. En y apportant une sémantique plus adéquate. Le Métier devient maitre de sa donnée.
Pourquoi cette distinction ?
Nous verrons par la suite que certains spaces auront vocation à être utilisés par une population « technique » et d’autres par une population plus « fonctionnelle-métier »
1.SAP préconise de disposer à minima d’un space « Administration »
Comme son nom l’indique, celui-ci sera dédié à tout ce qui touche à de l’administration, à savoir la gestion des utilisateurs, leurs autorisations, aux logs d’activité & monitoring, etc. Inutile de préciser que comme toute action relevant de l’admin, ce space sera strictement réservé à des administrateurs.
Arrêtons-nous quelques instants afin de voir comment peuvent être gérées les autorisations au sein de ce space.
1ere étape : Disposer d’une table d’autorisation contenant une colonne « User » ainsi qu’une colonne portant l’objet d’autorisation (ex : région, société, catégorie de produit, etc)
2ème étape : Créer une vue à partir de cette table
3eme étape : mettre la vue en partage avec les autres spaces
Vient ensuite l’intégration des autorisations grâce au DAC (Data Access Control) au sein des objets analytiques. Cette partie ne faisant plus partie de ce space, je ne m’étalerai pas davantage sur cet aspect.
Ainsi, les autorisations sont centralisées et sécurisées.
2. Un space « Acquisition »
Ce space serait dédié comme son nom l’indique à faire l’acquisition de données en 1 : 1. Aucune transformation, aucune normalisation, aucun MDM à ce stade. Le strict équivalent de la couche d’extraction que l’on retrouve dans les grands principes BI.
A noter que ce space peut tout à fait être optionnel et être géré au sein du space « Administration ». L’idée d’un space dédié est de scinder la partie Admin de la partie Acquisition.
Population : IT/Admin
3. Un space « Propagation »
Fidèle aux grands principes BI, un environnement dédié à ce qui a trait à la Transformation. On y gère le MDM (BI), les filtres, jointures, unions, etc. Le tout afin de constituer des modèles de données exploitables de 2 manières différentes :
Soit connecter directement un outil de reporting aux objets de ce space qui auront été préalablement déclarés comme étant consommables
Soit partager (en lecture) les objets développés au sein de ce space avec d’autres spaces.
Population : IT/BI
4. Un space par « Métier »
Dédier des spaces à des domaines bien précis va permettre de cloisonner les données (toujours en ayant la possibilité de partager du contenu avec d’autres domaines). En d’autres termes, vous gardez le contrôle de qui voit quoi. Mais en plus, vous allez pouvoir personnaliser son contenu puisque seul le domaine concerné ne sera autorisé à y pénétrer.
Cela apporte une très grande autonomie aux utilisateurs. C’est d’ailleurs un des atouts majeurs de cette solution.
Et c’est ici que vient la distinction évoquée précédemment : Data-Builder & Business-Builder. Les métiers seront principalement utilisateurs de l’application Business-Builder. Ils pourront y intégrer leur propre sémantique, créer leurs propres jeux de données, gérer à leur manière le contrôle d’accès de leur données, etc …
Néanmoins, l’utilisation du Data-Builder, leur offrira la possibilité d’intégrer des fichiers plats dont ils seraient les seuls détenteurs. C’est un gain de temps énorme par rapport à BW. Cela confère aux métiers une autonomie qu’ils n’ont jamais connu dans l’univers BI SAP.
Il ne vous reste plus qu’à connecter vos outils de reporting à vos modèles de consommations créés par les métiers dans les spaces métiers !
Consommation des données
Prenons le cas d’un SAP Analytics Cloud (SAC).
DWC a été conçu pour intégrer l’offre analytique proposée par SAP (mais pas que !), et à ce titre, SAC joue le rôle d’outil de prédilection lorsqu’il est nécessaire de restituer de la donnée. Et c’est d’ailleurs pour cette raison que l’accès au SAC s’opère directement depuis DWC.
Un utilisateur SAC ne pourra créer un dashboard sourcé depuis Datasphere que si les conditions suivantes sont remplies:
-D’être membre du space à partir duquel les données proviennent
-S’il s’agit d’une vue du Data-Builder, que celle-ci soit exposée pour être consommée
-S’il s’agit d’un modèle du Business-Builder, que celui-ci soit ouvert au public
Et une fois que le rapport aura été créé, les scénarios d’autorisations qui auront été définis dans SAP Datasphere viendront contrôler qui accède à quelle information dans SAC.
Conclusion
Une bonne gestion des spaces est primordiale ! C’est un aspect à ne pas négliger. Elle est un des facteurs-clé du succès de votre solution. Cela sous-entend qu’il faut mener une réflexion avant de se lancer dans une organisation des spaces de votre SAP Datasphere. L’approche à adopter devra répondre aux besoins de votre entreprise.
Si vous recherchez un cas d’usage, c’est par ici que ça se passe.