Présentation SAP BI&BW Farid Brahimi Indus SAP Mars 2008 PSA Bessoncourt Projet Compas Présentation du dataware BI/BW

SAP BW  SAP BI SAP BI fait partie de la suite Netweaver. D'autres composantes viennent avec SAP Enterprise Portal (EP), Web Application Server (WAS), SAP Process Integration (PI) et Master Data Management (MDM). La version BI 7.0 est sorti en Juin 2006. Son ancien nom est BW 3.5, révolutionnant le produit pour être le meilleur du marché. D'après SAP, il y a déjà plus de 12 000 installations dans le monde.

BW : pour quoi faire ?

OLAP versus OLTP OLTP : Online Transactional Processing (R/3, ECC6)  Transactionnel OLAP : Online Analytical Processing (BW, BI)  Décisionnel Préconisation SAP WP: 2 UPD (max) et 1 UP2 (ne sont pas utilisés pour les chargements).

Data flow InfoCube ODS PSA InfoSource InfoSource BI7 Source ECC6 Update Rules ODS Level 2 Order-Deliv. Level 1 Order Delivery Update Rules Transfer Rules PSA Order Delivery InfoSource InfoSource BI7 Source System ECC6 Datasource Datasource

Réplication du datasource R/3 OLTP Extract Structure BW Server Transfer Structure DataSource Replication Réplication à effectuer sur BI après chaque transport du datasource sur ECC6 La réplication est à faire par les Etudes . Si oubli, erreur dans la nuit applicative BI RSA1/Datasources

Gestion de la PSA (1) Zone de stockage temporaire des données brutes « données récentes » Poubelle des anciennes donées http://dtii.pcinfo.inetpsa.com/document/11 1405768.pc1fm http://dtii.pcinfo.inetpsa.com/document/11 1395948.pc1fm

Gestion de la PSA (2) I Purge automatique de la PSA sur PMB Demander aux études d’intégrer nouvelles tables de PSA dans PC de purge I Evolution de la base à surveiller : PSAPSR3 1,3 Go de données absorbées chaque jour, purge des PSA à la longue insuffisant pour empêcher la saturation du tablespace

Master Data (Donnée de base) Référentiel commun et unique des données de base Une seule master data par objet fonctionnel Une master data est partagée par plusieurs domaines Une gestion centralisée de la master data Modélisation BW Une table d’ID, Une table d’attribut, une table d’attributs dépendants du temps, Une table de texte

Schéma d’une Master Data Master Data Classique SID Dépendance au temps Textes Attribut de nav Attribut de Nav Données (attributs) Hierarchies SID Données Hierarchies Textes SID Données Hierarchies Textes Attribut standard

Un exemple : Article (0MATERIAL) Attributs 0CREATEDON Date de création 0PLANT Division 0MRP_CONTRL Gestionnaire 0CUSTOMER Numéro de Client 0Equipment Numéro d’equipement 0notification Numéro de notification Master data = données de bases = données pérennes Faibles volumétries, temps de chargements raisonnables Master data chargées de préférence avant le flux transactionnel

Transactional Data (Données Transactionnelles) Modèle BW : ODS Versus Infocube ODS (Stockage) A priori, premier niveau de stockage Permet la gestion des changements (remplacement) Source d’Infocube et ODS reporting (nouvelles cibles et rechargement) Infocube (Reporting) Stockage de données permanentes Indexation par le modèle en étoile -> Sélection et Aggrégation Partitionné (avec compression) Constitution d’agrégats Transaction data = données de masse = données périssables

Transactional Data (Données Transactionnelles) Modèle BW : Principe d’alimentation Premier niveau : stockage doit être semblable à la source Une structure de stockage par objet source Données changeantes Structure normalisée Même granularité élémentaire Second niveau : consolidation pour le reporting Sélection (filtre) Assemblage d’objets (unification) Consolidation des colonnes complémentaires Calcul de ratios Agrégation Analyse multidimensionnelle Structure dénormalisée Troisième niveau : précalcul pour le reporting (optionnel) Détermination de ratios calculés et restreints Multicubes

Schéma d’un ODS Pas de notion de dimension physique, pas de stockage de SID des master data => performances dégradées Master data SID Données Hierarchies Textes "An Operational Data Store object (ODS object) is used to store consolidated and cleansed data (transaction data or master data for example) on a document level (atomic level)"

ODS Architecture - Extracted from SAP Docs "An Operational Data Store object (ODS object) is used to store consolidated and cleansed data (transaction data or master data for example) on a document level (atomic level)" Il existe trois tables pour chaque ODS Une table « Activation queue » Une table de données actives Une table de change log qui enregistre les changements

Activation d’un ODS : tables impactées Données chargées dans une 1ère table /BIC/AODSXXX40 Données inactives Après Activation : Données transférées dans 2nde table /BIC/AODSXXX00 Données actives /BIC/AODSXXX50 Rollback data table Données tracées dans change log table

Schéma en étoile d’un Cube Article Master data 1 SID Données Hierarchies Textes Schéma en étoile d’un Cube Dimension Article Dimension 1 Dimid SID Master Data1 SID Master Data2 … SID Master DataN Cube Division Article Division Centre de coûts Master data 2 SID Données Hierarchies Textes Dimension Document Achat Dimension 13 dimid SID Master Data X … Dimension 2 line item dimid SID Master Data (line item) Num Doc Achat Numéro Doc Achat Centre de coûts Master data SID Données Hierarchies Textes Master data N SID Données Hierarchies Textes

Schéma de différents niveaux BW Multi-Cube Heures Gratuités Cube Cube ODS ODS R/3

Le flux BW BW R/3 Replicate Infoprovider Règle de Mise à jour Infosource Règles de transfert Lien “Zone R/3” “InfoObjet BW” PSA Table contenant les enregistrements transferés au format BRUT Chaque DataSource définit une structure de transfert Structure de transfert Replicate Datasource R/3 Structure de transfert Structure d’Extraction- Système Source Données de base Attributs Texte Hierarchie Données transactionnelles

Les process chains (Transaction RSPC) Préconisations SAP Chargement PSA Suppression indexes Chargement ODS Start MAJ Aggrégats Activation ODS Raffraichissement Statistiques Chargement Cube Création des indexes

Description d’une process chain Process de lancement Conditions de lancement process suivant

Dépendance entre process chains Meta-Chain concept Lorsqu’une process chain contient d’autres process chains dans ses différentes étapes, elle est appelée « méta-chaine », elle est alors constituée de « local chains » On utilise se concept lorsque l’on veut faire rendre dépendants entre eux le déclenchement de process chains. Des liens faibles ou forts définissent les relations entre local chains. Inconvénient : pas de visibilité depuis $UNIVERSE Uprocs et sessions On doit éviter d’utiliser des métachains sur COMPAS, on conditionne les process chains entre eux par des liens $Universe. Chaque process chain corresponds à une uproc regroupées dans des sessions $Universe. La relation entre les process chain, donc entre les uprocs doit être définie au PLUS TOT par les Etudes.

Data Transfer Process

DTP : Open Hub destination On double clique sur l’Open Hub pour détailler le type de destination

DTP : création de fichier Surveiller régulièrement l’espace occupé dans /usr/sap/PMB/DVEBMGS00