Die AWB ist das zentrale Werkzeug zur Steuerung, Überwachung und Pflege aller mit der Datenbeschaffung,Datenverarbeitung sowie der Datenbereitstellung verbundenen Prozesse im BW. Die Aufgaben werden in denfolgenden Funktionsbereichen durchgeführt:
Modellierung ( Transaktion: RSA1)Dieser Funktionsbereich dient dem Anlegen und Pflegen der zum Datenbereitstellungs- bzw. Datenladeprozessrelevanten (Meta-)Objekte des BW.Monitoring ( Transaktion: RSMON)Das Monitoring ermöglicht es, den Datenladeprozess sowie weitere Prozesse der Datenverarbeitung im BW zuüberwachen und zu steuern.Reporting Agent ( Transaktion: ’RSA1’ Drucktaste: ’Reporting Agent’)Der Reporting Agent ist ein Werkzeug, mit dem Reporting-Funktionen im Hintergrund ( Batch) eingeplant undausgeführt werden, wie z.B. das Auswerten von Exceptions und Drucken von QueriesTransportanschluss ( Transaktion: ’RSA1’ Drucktaste: ’Transportanschluss’)Mit dem Transportanschluss können neu angelegte bzw. geänderte BW-Objekte gesammelt und mit Hilfe desChange and Transport Organizer (CTO) in andere BW-Systeme transportiert werden.Dokumente ( Transaktion: ’RSA1’ Drucktaste: ’Dokumente’)Dieser Funktionsbereich ermöglicht es, ein oder mehrere Dokumente in verschiedenen Formaten,Versionen und Sprachen hinzuzufügen, zu verlinken und zu durchsuchen.Business Content ( Transaktion: RSORBCT)Der Business Content bietet auf konsistente Metadaten basierend u.a. vorkonfigurierte rollen- und aufgaben-bezogene Informationsmodelle ( siehe Business Content).Übersetzung Transaktion: ’RSA1’ Drucktaste: ’Übersetzung’)In diesem Funktionsbereich können Kurz- und Langtexte von BW-Objekten übersetzt werden.Metadata Repository ( Transaktion: RSOR)Mit dem HTML-basierten BW Metadata Repository werden zentral alle BW Meta-Objekte und derenVerknüpfungen zueinander verwaltet, wodurch ein konsistentes und homogenes Datenmodell über alleQuellsysteme ermöglicht wird ( siehe Metadata Repository).
AggregatEin Aggregat speichert den Datenbestand eines BasisCube in verdichteter Form redundant und persistent auf derDatenbank. Da Aggregate die gleiche Speicherform (Fakten-/Dimensionstabellen) wie BasisCubes haben, werdendiese auch häufig als ’Aggregat Cubes’ bezeichnet. Aggregate werden zur Verbesserung der Query-Performanceverwendet, d.h. es wird ein schnellerer Zugriff auf die Daten eines BasisCubes im Reporting ermöglicht. Da einBasisCube mehrere Aggregate besitzen kann, greift der ’Optimizer’ des OLAP-Prozessors beim Ausführen einerQuery automatisch auf das jeweils am besten geeignete Aggregat zu. D.h. die Entscheidung, ob für das Reportingein BasisCube oder ein Aggregat verwendet wird, ist für den Endanwender nicht transparent. Informationen zuAggregaten, wie technische Eigenschaften sowie inhaltliche und Status-Eigenschaften sind in der TabelleRSDDAGGRDIR abgelegt.
Pflege von Aggregaten im BW-System:1. Transaktion: RSDDV2. Einstieg: AWB Modellierung InfoProvider InfoArea wählen
Im Kontextmenü des gewählten BasisCube ’Aggregate pflegen’ wählen
Beim Aufbau eines Aggregates aus Merkmalen und Navigationsattributen eines BasisCube können die Datennach verschiedenen Aggregationsstufen gruppiert werden:
Alle Merkmalswerte ( ’ * ’)Die Daten werden nach allen Werten, der für die Aggregatsdefinition kombinierten Merkmale bzw.Navigationsattribute gruppiert.Hierarchielevel ( ’H’ )
Die Daten werden nach den Knoten eines Hierarchielevels gruppiert.
5
Festwert ( ’F’ )Die Daten werden nach einem Einzelwert eines Merkmals bzw. Navigationsattribut gefiltert und gruppiert.
In Hinblick auf das Laden von Daten in Aggregate eines BasisCube unterscheidet man zwischen ’Aktivieren/Füllen’und ’Hochrollen’:
Aktivieren und Füllen Mit dieser Funktion wird das erstmalige Laden von Daten in Aggregate ermöglicht. Die aktiven und gefüllte Aggregate sind dann für das Reporting verfügbar.
Roll-Up (Hochrollen)Unter dem Roll-Up versteht man das Laden von Requests eines BasisCubes, die in den zugehörigenAggregaten noch nicht vorhanden sind, in alle Aggregate dieses BasisCubes. Ein Rolll-Up ist erforderlich,sobald sich die BasisCube-Daten geändert haben, um Datenkonsistenz zwischen Aggregate und BasisCubezu gewährleisten. Nach dem Roll-Up werden die neuen Daten beim Ausführen einer Query verwendet.Roll-Up Hierarchie (Aggregatshierarchie)In der Roll-Up-Hierarchie wird die Abhängigkeit von Aggregaten zum BasisCube und zueinander im bezugauf das Roll-Up angezeigt, d.h. ob beim Roll-Up ein Aggregat über ein übergeordnetes Aggregat oder direktüber den BasisCube gefüllt wird. Mit Hilfe der Roll-Up-Hierarchie können ähnliche Aggregate identifiziert,und auf dieser Grundlage die Aggregate manuell gezielt optimiert werden.
Weitere Funktionalitäten:Ein-/AusschaltenWird ein Aggregat temporär ausgeschaltet, so wird beim Ausführen einer Query dieses Aggregat nichtverwendet. Beim erneuten Einschalten des Aggregats muss dieses nicht nochmals aktiviert und gefüllt werden.Damit hat man die Möglichkeit, die Laufzeiten der Queries mit bzw. ohne dieses Aggregat zu vergleichen,um zu prüfen, ob die Verwendung dieses Aggregats sinnvoll ist.DeaktivierenDeaktivieren eines Aggregates bedeutet, dass alle Daten des Aggregats gelöscht werden, jedoch die Strukturdes Aggregats erhalten bleibt.LöschenBeim Löschen wird das Aggregat deaktiviert und zusätzlich auch die Struktur des Aggregats gelöscht.KomprimierenDie Komprimierung von Aggregaten entspricht der Komprimierung von BasisCubes.D.h. komprimierte Requests können nicht mehr aus dem Aggregat gelöscht werden. Es ist aber möglich,die Komprimierung nach dem Roll-Up auszuschalten, so dass die Aggregate Request-erhaltend sind.Hierarchie-/Attributsänderungslauf ( Change Run)Wenn sich Hierarchien und Navigationsattribute von Merkmalen, die in Aggregaten verwendet werden,geändert haben, werden Strukturänderungen in den Aggregaten nötig, um die Daten entsprechendanzupassen. Bei einer Strukturänderung werden sämtliche von den Änderungen an Hierarchien undNavigationsattribute betroffenen Aggregate aller BasisCubes angepasst:Einstieg: AWB Werkzeuge Hierarchie/Attributs-Änderungen für das Reporting ausführenMit Hilfe des ABAP-Programmes ’RSDDS_CHANGE’ ’RUN_MONITOR’ ist es möglich zur Laufzeit des ChangeRun die anzupassenden Attribute, Hierarchien und Aggregate zu ermitteln. Stammdatenänderungen sind erstwirksam, wenn ein Change Run für diese Stammdaten durchgeführt wurde. Ab einer bestimmten Größen-ordnung der Änderung wird das Modifizieren des Aggregates aufwendiger als einNeuaufbau. Diesen Schwellwert kann man selbst festlegen:
1. Transaktion: RSCUSTV82. BW Customizing Einführungsleitfaden Business Information Warehouse Allgemeine BW Einstellungen Parameter für Aggregate
ALE (Application Link Enabling)
6
ALE unterstützt die Konfiguration und den Betrieb von verteilten Anwendungssystemen (zwischen SAP-Systemeneinerseits und SAP-Systemen und Fremdsystemen andererseits). Für die Kommunikation (Datenaustausch)zwischen verteilten Anwendungssystemen stellt ALE bestimmte Services und Tools zur Verfügung, wie z.B.Konsistenzprüfungen, Monitoring der Datenübertragung, Fehlerbehandlung und synchrone/asynchroneVerbindungen. Dadurch ist eine ein kontrollierter Datenaustausch zwischen den verteilten Anwendungssystemenbei konsistenter Datenhaltung gewährleistet
Anwendungskomponentenhierarchie- SAP-Quellsystem:
Die Anwendungskomponentenhierarchie ist Bestandteil des SAP-Quellsystems – Business Content, welchermit dem Plug-In eingespielt wird. Sie kann kann aber auch manuell gepflegt werden. Sie dient der Organisationder DataSources.Anwendungskomponentenhierarchie ändern:
1. Transaktion: RSA8 2.. Transaktion: SBIW Nachbereitung von DataSources Anwendungskomponentenhierarchie ändern- Im BW-System:
Die Anwendungskomponentenhierarchie ist ebenfalls Bestandteil des BW – Business Content; sie kann auchhier manuell gepflegt werden. Hier dient sie der Organisation von InfoSources im InfoSource-Baum und PSA-Tabellen im PSA-Baum.
ArchivierungDie Datenarchivierung ermöglicht es, Daten aus BasisCubes und DSO-Objekten (Tabelle mit den aktiven Daten) zuarchivieren, d.h. als flache Struktur in einem Datei-System abzulegen und aus dem BasisCube bzw. DSO-Objekt zulöschen. Die Archivierung von Daten dient unter anderem dazu,- das Datenvolumen zu verkleinern und somit Speicherplatz einzusparen.- aufgrund des geringeren Datenvolumens die Performance, wie z.B. bei Analysen,- bei der Fortschreibung, beim Roll-Up und Change Run zu verbessern.- die gesetzlichen Vorgaben zur Aufbewahrung von Daten einhalten zu können
ADK (Archiving Development Kit)Zur Archivierung wird das Werkzeug ADK der mySAP Technology Basis eingesetzt. Das ADK stellt dieLaufzeitumgebung für die Archivierung bereit. Es dient hauptsächlich zum Schreiben und Lesen von Datenin und aus Archivdateien. Das ADK gewährleistet die Plattform- und Release-Unabhängigkeit für diearchivierten Daten.Archivierungsprozess
Der Archivierungsprozess im BW besteht aus den folgenden Teilprozessen:- Schreiben der Daten in die Archive (Transaktion: SARA )- Löschen der archivierten Daten aus dem BasisCube/DSO-Objekt (Transaktion: SARA )
Werden archivierte Daten aus einem BasisCube gelöscht, so werden diese Daten auch aus den zumBasisCube gehörigen Aggregaten gelöscht. Werden Daten aus einem DSO-Objekt gelöscht, so bleibenDatenziele, die mit den Daten aus diesem DSO-Objekt versorgt wurden, von der Archivierung unberührt.
- Wiederherstellen archivierter Daten im BW-SystemDas Wiederherstellen archivierter Daten erfolgt über die Export-DataSource des BasisCube bzw. desDSO-Objektes, aus dem die Daten archiviert wurden. Das ADK stellt dabei die Funktionen für das Lesender Archivdateien zur Verfügung. Die weitere Fortschreibung erfolgt dann über die bekannten Datenlade-prozesse im BW-System.
Archivierungsobjekte
7
Voraussetzung für jede Archivierung sind sogenannte Archivierungsobjekte, die betriebswirtschaftlichzusammengehörige Daten durch eine Datenstruktur beschreiben und mit denen das Lesen, Schreiben undLöschen im Rahmen des Archivierungsprozess definiert und durchgeführt. Sie sind das Bindeglied zwischendem ADK und den BW-Objekten.Das Anlegen eines Archivierungsobjektes erfolgt über:Einstieg: AWB Modellierung InfoProvider InfoArea wählen
Im Kontextmenü des gewählten BasisCube/DSO-Objekts ’Ändern’ wählen Zusätze Archivierung
AttributAttribute sind InfoObjects (Merkmal/Kennzahl), die zur näheren Beschreibung von Merkmalen verwendet werden.Beispiel:Merkmal: ’Kostenstelle’Attribute: 'Kostenstellenverantwortlicher' (Merkmal als Attribut),
'Größe der Kostenstelle in Quadratmeter' (Kennzahl als ’ausschließliches Attribut’)In der InfoObject-Pflege zu einem Merkmal hat man die Möglichkeit, dem Merkmal Attribute mit Attributseigen-schaften mitzugeben:
AnzeigeAttribute mit dieser Eigenschaft können nur als zusätzliche Information in Kombination zum Merkmal imReporting verwendet werden, d.h. es ist keine Navigation in Queries möglich. Ein Sonderfall bei der Definitionvon InfoObjects ist die Option, InfoObjects (Merkmale bzw. Kennzahlen) als ausschließliches Attribute zudefinieren, d.h. diese Attribute können nicht als Navigationsattribut definiert werden, sondern nur als Anzeige-attribut genutzt werden.NavigationAttribute vom InfoObject-Typ ’Merkmal’ können als Navigationsattribute definiert werden. Derartige Attributekönnen zur Navigation analog zu (Dimensions-) Merkmalen in Queries verwendet werden, d.h. alleNavigationsfunktionen von (Dimensions-) Merkmalen in Queries gelten auch für Navigationsattribute. Im Gegen-satz zu (Dimensions-) Merkmalen sind mit Navigationsattributen aktuelle und stichtagsbezogene Datensichtenauf Query-Ebene möglich ( .Tracking History). Damit diese Attribute als Navigationsattribute im Reportingverfügbar sind, müssen diese auf Datenziel-Ebene zusätzlich eingeschaltet werden. Ein Merkmal, welches alsNavigationsattribut genutzt wird, kann selbst über Navigationsattribute verfügen, sogenannte transitiveAttribute ( zweistufige Navigationsattribute). Diese können ebenfalls eingeschaltet werden und somit zurNavigation in Queries zur Verfügung stehen.ZeitabhängigkeitSowohl Anzeige- als auch Navigationsattribute können als zeitabhängige Attribute gekennzeichnet werden,falls für jede Attributsausprägung ein Gültigkeitsbereich benötigt wird.
BAPI (Business Application Programming Interface)BAPIs sind offene, standardisierte Schnittstellen, die auf Anwendungsebene definiert werden.Transaktion: BAPIDiese von der SAP bereitgestellten Schnittstellen ermöglichen die Kommunikation zwischen SAP-Systemenund Anwendungen, die von Drittherstellern entwickelt wurden. Aus technischer Sicht ist der Aufruf eines BAPIder Aufruf eines Funktionsbausteins über RFC oder tRFC.
Staging BAPIÜber Staging BAPIs können Daten (Meta-, Stamm- und Bewegungsdaten) aus Fremdsystemen in dasBW-System übertragen werden.
8
BasisCubeEin BasisCube ist ein InfoCube, der einen in sich geschlossenen, themenbezogenen abgespeicherten Daten-bestand darstellt, auf den Queries definiert werden können. Er wird über eine oder mehrere InfoSources viaFortschreibungsregeln mit analyserelevanten Bewegungsdaten versorgt. Er ist der für die multidimensionaleModellierung relevante InfoCube, da für das BW-Datenmodell nur Objekte berücksichtigt werden, die Datenbeinhalten. Aus technischer Sicht ist ein BasisCube eine Menge von relationalen Tabellen, die multidimensional(mittels Sternschema) zusammengestellt sind:
FaktentabellenEin BasisCube besteht aus zwei Faktentabellen, in der die Kennzahlen abgelegt werden.F- Tabelle: ’normale Faktentabelle’ ( bzgl. der Request-ID partitioniert)E-Tabelle: ’komprimierte Faktentabelle’ ( F-Tabelle ohne Request-ID)Dabei können maximal 233 Kennzahlen abgespeichert werden.Die Nutzung der E-Tabelle ist optional (siehe unten Komprimierung).DimensionstabellenEin BasisCube besteht maximal aus 16 Dimensionstabellen. Davon werden die Zeitdimensions- undDatenpaketdimensionstabelle vom System automatisch generiert. Die Einheitendimensionstabelle wird nurdann vom System generiert, wenn mindestens eine Kennzahl vom Typ ’Betrag’ oder ’Menge’ ist. In diesemFall muss nämlich der Kennzahl eine fixe oder variable Währung/Einheit mit gegeben werden ( siehe
Kennzahlen).SID-Tabellen/StammdatentabellenDie Relation zwischen den Stammdatentabellen zu einem Merkmal-InfoObject und den Dimensionstabellenwird mit Hilfe systemgenerierter INT4-Schlüssel, der sogenannten SIDs (Surrogat Identifications), der jeweiligenMerkmal-InfoObjects hergestellt. In den Dimensionstabellen werden ausschließlich SIDs der jeweiligenMerkmal-InfoObjects, niemals Merkmalsausprägungen abgelegt. Dabei können maximal 248 SIDs derjeweiligen Merkmal-InfoObjects in einer Dimensionstabelle stehen. Die Relation zwischen einer Faktentabelleund den zugehörigen Dimensionstabellen wird mit Hilfe künstlicher systemgenerieter INT4-Schlüssel, dersogenannten DIM-IDs (Dimension-Identifikationen) realisiert.
1. Anlegen von BasisCubes:Einstieg: AWB Modellierung InfoProvider InfoArea wählen
Im Kontextmenü der gewählten InfoArea ’ InfoCube anlegen’ und den Typ ’BasisCube’ wählen2. Pflege von BasisCubes
Transaktion: RSDCUBEBasisCubes administrieren:
Selektives Löschen ( Registerkarte ’Inhalt’)Mit dieser Funktion können durch eine vorherige Selektion gezielt Datensätze, die diesen Selektionskriterienentsprechen, aus dem BasisCube gelöscht werden. Wird das selektive Löschen verwendet, um fehlerhafteDatensätze aus dem BasisCube zu löschen, so kann man die richtigen bzw. korrigierten Datensätze mit Hilfeeines Reparatur-Request im Scheduler Scheduler InfoPackage pflegen) wieder einbuchen.Indizes prüfen/löschen/reparieren ( Registerkarte ’Performance’)Für jede DIM-ID ist ein Index auf der Faktentabelle von BasisCubes angelegt. Diese Indizes sind notwendig,um ein optimales Auffinden/Selektieren der Daten zu gewährleisten. Allerdings müssen diese Indizes beiSchreibzugriffen durch das Datenbanksystem angepasst werden, was zu wesentlichen Einbußen derPerformance führen kann. Mit der Funktion ’Indizes löschen’ besteht bei der Fortschreibung in BasisCubesdaher die Möglichkeit, die Schreibzugriffe zu beschleunigen. Nach Beendigung der Fortschreibung müssendie Indizes mit der Funktion ’Indizes reparieren’ wieder aufgebaut werden. Mit der Funktion ’Indizes prüfen’kann festgestellt werden, ob Indizes gelöscht ( rote Ampel), aufgebaut ( gelbe Ampel) oder aktiv sind
grüne Ampel).Requests löschen ( Registerkarte ’Requests’)Mit dieser Funktion hat man die Möglichkeit gezielt Requests zu löschen, die in den BasisCubes geladenwurden (falls diese noch nicht in Aggregate hochgerollt wurden).
9
Requests neu aufbauen ( Registerkarte ’Neuaufbau’)Mit dieser Funktion können bereits gelöschte Requests zu einem BasisCube wiederhergestelltwerden. Des Weiteren können diese Requests auch für andere BasisCubes verwendet werden.Diese Funktion ist nur möglich, falls die Requests in den PSA-Tabellen gehalten werden.Requests hochrollen ( Registerkarte ’Roll-Up’)
siehe Aggregate Roll-Up)Komprimieren ( Registerkarte ’Komprimieren’)Jeder BasisCube besitzt, vom System vorgegeben, eine Datenpaketdimensionstabelle in der die SIDzum technischen Merkmal ’0REQUID’ (Request-ID) abgelegt ist. Diese Dimensionstabelle wird beim jedemLadevorgang automatisch gefüllt. Folglich werden in der Faktentabelle Daten mit einem höheren Detaillierungs-grad abgelegt, was aus betriebswirtschaftlicher Sicht nicht erforderlich ist. Je nach Modellierung desBasisCube, Häufigkeit der Ladevorgänge und Zusammensetzung der geladenen Daten kann sich dieseDetaillierung erheblich auf das Datenvolumen des BasisCube auswirken. Mit dem Verschwinden der Request-ID ( wird auf Null gesetzt) kann das Datenvolumen um ein Vielfaches verringert werden, ohne Nachteile ausbetriebswirtschaftlicher Sicht in Kauf zu nehmen. Um diese Verringerung zu erreichen, besteht jeder BasisCubeaus zwei Faktentabellen:- F-Tabelle: ’normale Faktentabelle’- E-Tabelle: ’komprimierte Faktentabelle’ (= F-Tabelle ohne Request-ID)Mit der Funktion ’Komprimieren’ wird die E-Tabelle mit Daten aus der F-Tabelle gefüllt. Dabei kann die gesamteF-Tabelle komprimiert oder nur ein älterer Teil der Requests komprimiert werden. Neue Requests werden in dieF-Tabelle geschrieben und können anschließend komprimiert werden. Analog verhält es sich mit der Kompri-mierung bei Aggregaten. Nachteil der Komprimierung ist, dass sie nicht rückgängig gemacht werden kann!
Business Content (BCT)
Ein wesentlicher Vorteil des BW gegenüber anderen Data Warehouse – Lösungen ist der von der SAP mit dem BWausgelieferte BCT, der permanent weiterentwickelt wird. Dabei handelt es sich um umfassend vordefinierteInformationsmodelle für die Analyse von Geschäftsprozessen.Darin enthalten ist die gesamte Definition aller erforderlichen BW-Objekte, wie z.B.: InfoAreas, InfoObjectCatalogs,Rollen, Arbeitsmappen, Query-Elemente, InfoCubes, InfoObjects, DSO-Objekte, Fortschreibungsregeln,InfoSources, Übertragungsregeln, Währungsumrechnungsarten, Extrakoren, DataSources. Demnach werden zweiBereiche des BCT unterschieden:- BCT für die Quellsysteme (z.B. Anwendungskomponentenhierarchie, DataSources)- BCT für das BW-SystemDer BCT für SAP-Quellsysteme (für R/3-Systeme: Release 3.1 I) wird über Plug-Ins eingespielt.Falls BW-Systeme als Quellsysteme an andere BW-Systeme angeschlossen, ist das Einspielen von Plug-Ins nichterforderlich.Bevor Bestandteile des BCT genutzt werden können, müssen diese explizit übernommen bzw.aktiviert werden. Dies geschieht im Quellsystem über die Transaktion: SBIW und im BW-System über dieTransaktion: RSORBCT.
Objekt-VersionenAlle BW-Objekte werden zunächst in der D(elivered)-Version mit dem BCT ausgeliefert. Durch die Übernahmedieser Objekte aus dem BCT wird eine A(ctive)-Version angelegt, dabei bleibt die D-Version erhalten. Werdendiese aktivierten Objekte verändert, so wird eine neue M(odified)-Version generiert. Diese kann aktiviertwerden und überschreibt dann die ältere aktive Version. Die Änderung von BW-Objekten, die aus dem BCTübernommen sind, werden bei einer erneuten Übernahme einer neueren Content-Version nicht überschrieben.
10
Business Explorer (BEx)Der BEx ist ein Werkzeug, um zentral gespeicherte Daten, die aus verschiedenen Quellen stammen können,auszuwerten. Der BEx beinhaltet folgende Komponenten:
BEx Analyzer (Transaktion: RRMX)Analyse- und Reportingwerkzeug des BEx, das als Add-In für Microsoft Excel implementiert ist und damit aufdie komplette Excel-Funktionalität zurückgreift. Der BEx Analyzer wird verwendet:- zur Erstellung und Änderung von Berichten- für Auswertungen von und Navigation innerhalb von Berichten- zum Aufrufen und Speichern von Berichten in Rollen bzw. persönlichen Favoriten- zur Publikation von Berichten für das Web-ReportingBEx BrowserWerkzeug zum Organisieren und Verwalten von Arbeitsmappen und Dokumenten.Mit dem BEx Browser kann man auf alle Dokumente des BW zugegriffen werden, die seiner Rolle zugeordnetsind und die man in seinen Favoriten abgelegt hat. Im BEx Browser kann mit folgenden Dokumenttypengearbeitet werden:- BW Arbeitsmappen- Dokumente, die im Business Document Service (BDS) abgelegt sind- Verknüpfungen (Referenzen auf das Dateisystem, Shortcuts)- Links auf Internetseiten (URLs)- SAP Transaktionsaufrufe- Web Applications und Web TemplatesFormatiertes ReportingMit Hilfe des formatierten Reporting ist es möglich, die Daten nicht nur für die interaktive Analyse bereitzu-stellen, sondern auch in formatierte Drucklayouts aufzubereiten. Das formatierte Reporting basiert auf denim BEx Analyzer definierten Queries. Hinter dem formatierten Reporting stehen die Crystal Reports von Crystal-Decission, die im BW integriert sind.BEx Web Application DesignerMit dem BEx Web Application Designer hat man die Möglichkeit, Queries und HTML-Dokumente ins Intranetoder Internet zu stellen.
Cleansing/HomogenisierungMit Hilfe von sogenannten Übertragungsregeln können im BW die Daten aus den Quellsystemen vor derVerbuchung im bezug auf die Datenstruktur und Semantik homogenisiert bzw. harmonisiert werden. Dabei könnenFehlinformationen herausgefiltert bzw. bereinigt oder korrigiert werden.
DatengranularitätMit der Datengranularität wird der Detaillierungsgrad von Daten beschrieben. Sehr detaillierte Daten haben eineniedrige Granularität; mit wachsender Verdichtung (= Aggregation) der Daten wird eine hohe Granularität erreicht.Die Granularität wirkt sich u.a. auf den Speicherplatz, Informationsgehalt sowie der Leseperformance aus. Im BWwerden für das Reporting detaillierte Daten in DSO-Objekten und aggregierte Daten in BasisCubes bzw. Aggregateabgespeichert.
Data Dictionary (DDIC)Das (ABAP) – Data Dictionary ermöglicht eine zentrale Beschreibung und Verwaltung aller im System verwendetenDatendefinitionen. Das DDIC ist vollständig in die ABAP Workbench integriert. Das DDIC unterstützt die Definitionbenutzerdefinierter Typen (Datenelemente, Strukturen und Tabellentypen). Im DDIC kann auch die Struktur vonObjekten der Datenbank (Tabellen, Indizes und Views) definiert werden. Diese Objekte können dann mit dieserDefinition automatisch auf der Datenbank erzeugt werden.Transaktion: SE11
11
Data Mart InterfaceDie Data Mart Schnittstelle ermöglicht die Fortschreibung von Daten aus einem Datenziel in ein weiteres Datenziel.Diese Art der Fortschreibung kann zum einen innerhalb eines BW-Systems, d.h. das BW ist als Quellsystem ansich selbst angeschlossen (Myself – Data Mart) und zum anderen zwischen mehreren BW-Systemen realisiertwerden. Beim Einsatz von mehreren BW-Systemen wird das datenliefernde System als Quell-BW, das Datenempfangende System als Ziel-BW bezeichnet. Die einzelnen BWs einer derartigen Anordnung werden als DataMarts bezeichnet. Für die Datenübertragung aus einem Datenziel in ein weiteres Datenziel ist eine sogenannteExport-DataSource erforderlich, die aus der Struktur des Quell-Datenziels abgeleitet wird. Ist das Quell-Datenzielein DSO-Objekt, so wird im Gegensatz zum BasisCube beim Aktivieren eines neu angelegten DSO-Objektes dieExport-DataSource automatisch generiert.
DataSourceEine DataSource beschreibt jeweils eine betriebliche Einheit von Stammdaten (z.B. Materialstammdaten) sowieBewegungsdaten (z.B. Vertriebsdaten). Aus Sicht der Quellsysteme gehören zu jeder DataSource Meta-Informationen wie z.B. die Felder/Feldbeschreibungen zu den Stamm- und Bewegungsdaten und Programme, diebeschreiben, wie die Extraktion durchgeführt wird. Diese Informationen sind Quellsystem-spezifisch, d.h. eineDataSource ist Quellsystem-abhängig. Diese DataSource-Informationen bzw. -Eigenschaften werden im SAP-Quellsystem in den Tabellen ROOSOURCE und RODELTAM. und im BW-System in der Tabelle RSOLTPSOURCE.abgelegt. Aus technischer Sicht unterscheidet man bei einer DataSource zwei Arten von Feldstrukturen:- Extraktstruktur- TransferstrukturMan unterscheidet die folgenden Typen von DataSources:
DataSources für BewegungsdatenDataSources für Stammdaten-AttributeDataSources für Stammdaten-TexteDataSources für Stammdaten-Hierarchien
Mit der Definition sogenannter generischer DataSources hat man die Möglichkeit, Daten aus beliebigen DDIC-Tabellen/Views, SAP Queries/InfoSets oder Funktionsbausteinen aus SAP-Quellsystemen zu extrahieren. Damitkönnen auch Daten aus SAP-Quellsystemen extrahiert werden, die nicht durch BCT-DataSources extrahiert werden
Transaktion: RSO2 ). Die Extraktion von Daten für externe Hierarchien ist mit generischen DataSources nichtmöglich!
Data StagingAufbereitungsprozesse für die Datenbereitstellung im BW
Data Warehouse (DWH)Unter einem DWH versteht man ein System, in dem die entscheidungsrelevanten Daten themen- orientiert,integriert, nicht flüchtig und zeitbezogen gespeichert werden. Die Aufgabe eines DWH besteht darin, Daten ausunterschiedlichen firmeninternen und externen Quellen zu bereinigen, zu konsolidieren und den Zugriff mittelsOLAP-Tools bereitzustellen. Dabei ist die Integration von OLAP-Tools in einem DWH-System nicht zwingend.Allerdings bieten Hersteller in der heutigen Zeit immer mehr DWH-Systeme mit integrierten OLAP-Tools an.Solche DWH-Systeme werden auch häufig OLAP-System oder DWH-Lösungen bezeichnet. Demnach ist das SAPBW eine DWH-Lösung.
12
DatenzielEin Datenziel ist ein BW-Objekt, in das Daten geladen werden können (= physisches Objekt). Datenziele sind dieObjekte, die bei der Modellierung des BW-Datenmodells relevant bzw. berücksichtigt werden. Datenziele könnensein:- BasisCubes- DSO-Objekte- Merkmal-InfoObjects
DB ConnectMit DB Connect wird ein direkter Zugriff auf (externen) relationalen Datenbanken ermöglicht. Dazu wird über dasSAP DB MultiConnect eine Verbindung zum Datenbankmanagesystem (DBMS) der externen Datenbank herge-stellt. Über das Einlesen von Metadaten sowie den orginären Daten können auf sehr einfache Weise die notwen-digen Strukturen im BW generiert und die Daten geladen werden. Voraussetzung dafür ist, dass es sich dabei umein von der SAP unterstütztes DBMS handelt. Diese Daten können dann über DataSources dem BW-Systembekannt gemacht und extrahiert werden. Unterstützte DBMS sind:- SAP DB- Informix- Microsoft SQL Server- Oracle- IBM DB2 390//400/UDBDes Weiteren muss der SAP spezifische Teil der Datenbankschnittstelle Database Shared Library (DBSL) für dasjeweilige Quell-DBMS auf dem BW-Applikationsserver installiert werden.
DimensionUnter einer Dimension (= Perspektive) versteht man die Gruppierung logisch zusammengehöriger Merkmale untereinem gemeinsamen Oberbegriff. Dabei können innerhalb einer Dimension maximal 248 Merkmale zusammen-gefasst werden. Aus technischer Sicht besteht eine Dimension eines BasisCube aus einer Dimensionstabelle(falls keine Line Item Dimension) sowie SID- und Stammdatentabellen.
Line Item DimernsionMerkmale können als Line Items definiert werden, d.h. neben diesem Merkmal können keine weiterenMerkmale einer Dimension zugeordnet werden. Eine solche Dimension bezeichnet man als Line ItemDimension (= degenerierte Dimension). Im Gegensatz zu einer gewöhnlichen Dimension enthält die Line ItemDimension keine Dimensionstabelle. Hier ist die SID-Tabelle des Line Items über eine Fremd-/Primärschlüsselbeziehung direkt mit der Faktentabelle verbunden. Diese Möglichkeit wird genutzt, falls ein Merkmal, wie z.B.die Auftragsnummer, sehr viele Werte besitzt. Dadurch kann die Query-Performance verbessert werden.
Dimension-Identifikation (DIM-ID)Die Relation zwischen einer Faktentabelle und ihren Dimensionstabellen eines BasisCubes wird mit Hilfe system-generierter INT4-Schlüssel, der sogenannten DIM-IDs, umgesetzt. Beim Laden von Bewegungsdaten in denBasisCube werden die DIM-ID-Werte eindeutig vergeben, dabei wird jedem DIM-ID-Wert eindeutig eineKombination von SID-Werten der unterschiedlichen Merkmale zugeordnet.
Delta-UpdateEin Delta-Update fordert jeweils nur die Daten an, die seit dem letzten Update angefallen sind und füllt mitdiesen Daten die entsprechenden Datenziele. Bevor man ein Delta-Update anfordern kann, muss man erstdie Initialisierung des Delta-Verfahrens durchführen. Ein Delta-Update ist DataSource-abhängig!Diese Eigenschaft einer DataSource sind in den Tabellen ROOSOURCE und RODELTAM im SAP-Quellsystembzw. in der Tabelle RSOLTPSOURCE im BW-System abgelegt.
13
Error-HandlingMit Hilfe der Funktion Fehlerbehandlung auf der Registerkarte ’Fortschreibungsparameter’ im InfoPackage desSchedulers hat man beim Laden von Daten über die PSA die Möglichkeit, das Verhalten des BW-Systems beimAuftreten fehlerhafter Datensätze zu steuern. Dabei stehen die folgenden Optionen zur Verfügung:- Keine Verbuchung, kein Reporting (Default)- Verbuchung gültiger Sätze, kein Reporting (Request rot)- Verbuchung gültiger Sätze, Reporting möglich (Request grün)Ferner kann festgelegt werden:- nach wie viel fehlerhaften Sätzen der Ladeprozess abgebrochen wird. Falls hierzu keine Eintragung gemacht
wird, wird der Ladeprozess beim ersten Fehler abgebrochen.- der Request wird als fehlerhaft gewertet, falls die Anzahl der empfangenen Sätze nicht mit
der Anzahl der verbuchten Sätze übereinstimmt (Kennzeichen: ’Keine Aggregation erlaubt’)
ETL-ProzessEin ETL-Prozess setzt sich aus den folgenden Teilprozessen zusammen:- Extraktion von Daten aus einem Quellsystem- Transformation der Daten- Laden der Daten in das BW-System
ExtraktstrukturDie Extraktstruktur enthält sämtliche Felder des SAP-Quellsystems, die von sogenannten Extraktoren imQuellsystem für den Datenladeprozess bereitgestellt werden. Extraktstrukturen von DataSources können imQuellsystem definiert, bearbeiten und erweitert werden.Transaktion im Quellsystem: SBIW
ExtraktorEin Extraktor ist ein Programm für die:- Bereitstellung von Metadaten aus einem SAP-Quellsystem über die Extraktstruktur einer DataSource- Verarbeitung von Datenanforderungen- Durchführung der ExtraktionDiese Extraktoren werden mit den DataSources in Form eines Plug-Ins in die SAP-Quellsysteme eingespielt.
FlatfileDie Daten können über eine Dateischnittstelle in das BW eingespielt werden. Als Quelldateien für das BW werdendie folgenden zwei Dateiformate unterstützt:- ASCII (American Standard Code for Information Interchange) – Dateien mit fixer Feldlänge- CSV (Colon Separated Variables) – Dateien mit variabler Länge, wobei die Trennzeichen
(= Separator) benutzerdefiniert festgelegt werden können (Transaktion: RSCUSTV1 ).Durch die Verwendung von Flatfiles (flache Dateien) können Schnittstellenproblematiken reduziert werden,hingegen müssen die Metadaten manuell im BW gepflegt werden.
14
TransformationssregelÜber die Transformationsregeln gelangen die Stamm- und Bewegungsdaten nach einer definierten Logik in dieDatenziele (BasisCubes, DSO-Objekte, Merkmal-InfoObjects mit Attributen oder Texten).Demnach sind Transformationsregeln im Gegensatz zu Übertragungsregeln nicht Quellsystem-spezifisch, sondernDatenziel-spezifisch. Jedoch können Transformationsregeln eines Datenziels für ein weiteres Datenziel kopiertwerden. Mit Hilfe dieser Regeln können die Datenziele über eine oder mehrere DataSources und/oder Info Sourcesversorgt werden. Sie dienen der Verbuchung der Daten in die Datenziele sowie der Modifikation und Anreicherungder Daten.Definition von Transformationssregeln:Einstieg: AWB Modellierung InfoProvider InfoArea wählen
Im Kontextmenü des gewählten Datenziels ’Transformationsregeln anlegen’ wählenBeispiele für Transformationsregeln sind:- Nachlesen von Stammdaten-Attribute- Felder im Datenziel mit einer Konstante füllen- Felder im Datenziel über eine Routine (ABAP-Coding) bzw.über eine Formel (Transformationsbibliothek)- versorgen- Währungsumrechnung- Rückgabetabelle ( Splitting von Kennzahlen)Bei der Fortschreibung jeder Kennzahl muss zwischen den folgenden Fortschreibungsarten ausgewählt werden:- ’Addition’ / ’Maximum’ / ’Minimum’
Das Standard-Aggregationsverhalten einer Kennzahl wird in der Kennzahl-Pflege festgelegt und in der Pflegeder Fortschreibungsregeln zu dieser Kennzahl entweder als Addition, Maximum oder Minimum angeboten.Speziell die ’Addition’ ist auch für Datenfelder von DSO-Objekten möglich, falls diese vom numerischen Daten-typ sind. Diese Forschreibungsart gilt nicht für Merkmal-InfoObjects als Datenziel.
- ’Überschreiben’ Diese Fortschreibungsart ist nicht für BasisCubes, sondern nur für DSO-Objekte und Merkmal- InfoObjects möglich.- ’Keine Fortschreibung’
Wird diese Fortschreibungsart gewählt, so wird für die betreffende Kennzahl kein Wert berechnet. Ebenso wirddie Berechnung der zugehörigen Merkmale/Schlüsselfelder nicht durchgeführt.
FremdsystemFremdsysteme sind Nicht-SAP-Systeme (inklusive R/2-System, R/3-Systeme – Release < 3.1i), die Metadaten undDaten für das BW bereitstellen und damit dem BW als Quellsystem dienen. Die Extraktion, Transformation und dasLaden dieser Daten kann über Staging BAPIs mit Hilfe von Third Party Extraction-Tools umgesetzt werden.
Full-UpdateEin Full-Update fordert alle Daten an, die den im Scheduler InfoPackage festgelegten Selektionskriterienentsprechen. Im Gegensatz zum Delta-Update unterstützt jede DataSource ein Full-Update.
HierarchieUnter dem Begriff ’Hierarchie’ wird gewöhnlich eine Anordnung von Objekten verstanden,die in einer 1:N – Beziehung stehen. In diesem Sinn gibt es im BW Hierarchien in denDimensions-, Attributs- und Hierarchietabellen. In der DWH-Terminologie ist dieser Hierarch-Begriff eng verbunden mit dem Begriff ’Drill-down’ ( vordefinierter Drill-down – Pfad).
15
Externe HierarchienIm BW versteht man unter dem Begriff ’externe Hierarchien’ Präsentationshierarchien, die zur Strukturierungder Ausprägungen eines Merkmals in sogenannten Hierarchietabellen abgelegt werden. D.h. sie sind losgelöstvon den Attributen/Texten eines Merkmal-InfoObject und können somit unabhängig von den Attributen/Textendes Merkmal-InfoObject gepflegt werden. Wird das Kennzeichen ‘Mit Hierarchie’ in der Merkmal-Pflege gesetzt,so können zu einem Merkmal (kein referenzierendes Merkmal) Hierarchien innerhalb des BW angelegt, ausSAP-Quellsystemen oder über Flatfiles in das BW geladen werden.Pflege von Hierarchien zu einem Merkmal:1. Transaktion: RSH12. Einstieg: AWB Modellierung InfoObjects InfoArea wählen
Im Kontextmenü des gewählten Merkmal-InfoObjects ’Hierarchie anlegen’ wählen(Bereits existierende Hierarchien zu einem Merkmal werden im InfoObject-Baum unterhalb diesesMerkmals angezeigt, und können über das zugehörige Kontextmenü bearbeitet werden)
Eigenschaften von externen Hierarchien:VersionsabhängigkeitExterne Hierarchien können in verschiedenen Versionen verwendet werden. Versionsabhängige
Hierarchien können bspw. für planungs- und simulationsähnliche Reportingaufgaben verwendet werden. D.h. Hierarchieversionen können in einer Query miteinander verglichen werden.
ZeitabhängigkeitBei der Zeitabhängigkeit unterscheidet man:- zeitabhängige Gesamthierarchie
D.h. die Zeitabhängigkeit bezieht sich auf die Hierarchiewurzel, und wird damit auf alle Hierarchie-knoten übertragen. Je nach Auswahl des Stichtages der Query können dabei verschiedene Hierarchienverwendet werden.
- zeitabhängige Hierarchiestruktur D.h. die Zeitabhängigkeit bezieht sich auf Hierarchieknoten. Damit wird festgelegt, für welchen Zeitraum der Knoten an der angebenen Stelle der Hierarchie stehen soll.
Hierarchie-Intervalle Es ist möglich, unter einem Hierarchieknoten Merkmalsausprägungen in Form von Intervallen zu hängen. Anstatt z.B. in einer Kostenarten-Hierarchie die Kostenartenausprägungen zu Materialkosten alle einzeln unter den Knoten Materialkosten zu hängen, können die Kostenartenausprägungen in der Form Kostenart 100 bis 1000 angegeben werden.
Vorzeichenumkehr für KnotenMit dieser Funktion können die Vorzeichen der Werte, die einem Hierarchieknoten zugeordnet sind,umgekehrt werden.
IDocEin IDoc (Intermediate Document) ist ein Datenbehälter für den Austausch von Daten zwischenSAP-Systemen einerseits und SAP-Systemen und Fremdsystemen andererseits unter Nutzungder ALE-Technlogie. Ein IDoc besteht aus:- einen ’Kopfsatz’
Der Kopfsatz enthält Informationen über Sender, Empfänger, Nachrichten- und IDoc-Typ und- ’zusammenhängende Datensegmente’
Jedes Datensegment enthält einen Standardheader, der aus einer fortlaufenden Segment-nummer sowieeiner Beschreibung des Segmenttyps besteht, und eine 1000-Byte lange Feldleiste, die die Daten des Segmentsbeschreiben.
- ’Statussätze’Die Statussätze beschreiben die bisherigen Verarbeitungsschritte des IDoc.
16
InfoAreaInfoAreas dienen als oberstes Ordnungskriterium von InfoProvider und InfoObjects im BW. Diese Objekte werdenin der AWB in entsprechenden Bäumen angeordnet:- InfoProvider-Baum- InfoObjects-BaumDabei muss jeder InfoProvider genau einer InfoArea im InfoProvider-Baum zugeordnet sein. InfoObjects könnenüber sogenannte InfoObjectCatalogs verschiedenen InfoAreas im InfoObjects-Baum zugeordnet werden.Analog zu anderen BW-Objekten werden InfoAreas durch einen technischen Namen und eine Beschreibungdefiniert und innerhalb des InfoProvider- oder InfoObjects-Baum angelegt.
InfoCubeInfoCubes sind die zentralen Objekte im BW, auf denen multidimensionale Analysen und Berichte basieren.Ein InfoCube beschreibt aus Reporting-Sicht, d.h. für den Reporting-Endanwender, einen in sich geschlossenenDatenbestand eines betriebswirtschaftlichen Bereichs, auf den Queries definiert bzw. ausgeführt werden. Siestellen somit InfoProvider dar.Im BW werden folgende InfoCube-Typen unterschieden:- BasisCube- Allgemeiner RemoteCube- SAP RemoteCube- Virtueller InfoCube mit Services1. Anlegen eines InfoCubes im InfoProvider-Baum: Einstieg: AWB Modellierung InfoProvider InfoArea wählen
Im Kontextmenü der InfoArea ’InfoCube anlegen’ wählen2. Berabeiten von InfoCubes Transaktion: RSDCUBE
InfoObjectIm BW werden die ‘kleinsten Informationsbausteine’ (= Felder) als InfoObjects bezeichnet, die über ihrentechnischen Namen eindeutig identifizierbar sind. Als Bestandteil des Metadata Repository tragen InfoObjects dietechnischen und fachlichen Informationen der Stamm- und Bewegungsdaten im BW. Sie werden systemweit zumAufbau von Tabellen und Strukturen eingesetzt, wodurch die Informationen im BW in strukturierter Form abgebildetwerden können. InfoObjects werden nach ihrer Funktion und Aufgabe in die nachstehenden Klassen unterteilt:
Kennzahl (z.B. Umsatz, Menge)Kennzahl-InfoObjects liefern die Werte, die ausgewertet werden sollen.Merkmal (z.B. Material, Kunde, Quellsystem-ID)Merkmal-InfoObjects sind betriebswirtschaftliche Bezugsobjekte, anhand derer die Kennzahlenausgewertet werden.Zeitmerkmal (z.B. Kalendertag, -monat)Zeitmerkmale bilden den Bezugsrahmen für viele Datenanalysen und Auswertungen. Diese Merkmale werdenmit dem BCT ausgeliefert; es können keine eigenen Zeitmerkmale definiert werden.Einheit (z.B. Währungsschlüssel, Mengeneinheit)Den Kennzahlen können Einheit-InfoObjects mitgegeben werden, um in den Auswertungen eine Verknüpfungzwischen den Kennzahlwerten und zugehörigen Einheiten zu ermöglichen.technisches MerkmalDiese Merkmale haben eine organisatorische Bedeutung innerhalb des BW. So liefert z.B. das technischeMerkmal ’0REQUID’ die Nummern, die beim Laden von Requests vom System vergeben werden und dastechnische Merkmal ’0CHNGID’ die Nummern, die bei Aggregats- änderungsläufen vergeben werden.
17
1. Anlegen eines InfoObjects im InfoObjects-Baum: Einstieg: AWB Modellierung InfoObjects InfoArea wählen InfoObjectCatalog wählen
Im Kontextmenü des InfoObjectcatalog ’InfoObject anlegen’ wählen2. Pflege von InfoObjects Transaktion: RSD1 bis RSD5
InfoObjectCatalogEin InfoObjectCatalog ist eine Gruppierung von InfoObjects nach anwendungsspezifischen Gesichtspunkten.Er ist dabei ein rein organisatorisches Hilfsmittel und dient nicht zu Auswertungszwecken. Ein InfoObjectCatalogist im InfoObjects-Baum einer InfoArea zugeordnet. Ein InfoObjectCatalog ist vom Typ ’Merkmal’ oder vom Typ’Kennzahl’ und enthält dementsprechend entweder Merkmale oder Kennzahlen.1. Anlegen eines InfoObjectCatalog im InfoObjects-Baum: Einstieg: AWB Modellierung InfoObjects InfoArea wählen
Im Kontextmenü der InfoArea ’InfoObjectCatalog anlegen’ wählen2. Bearbeiten von InfoObjectCatalogs Transaktion: RSDIOBC
InfoPackageEin InfoPackage beschreibt, welche Daten aus einem Quellsystem über eine DataSource angefordert werdensollen. Dabei können die Daten anhand von Selektionsparametern gezielt ausgewählt werden. Die Einplanungs-optionen werden mit Hilfe des Schedulers bestimmt. Dabei können zu einer DataSource mehrere InfoPackagesdefiniert werden.Anlegen eines InfoPackage im InfoSources-Baum:Einstieg: AWB Modellierung InfoSources InfoSource wählen Quellsystem wählen
Im Kontextmenü des Quellsystems ’InfoPackage anlegen’ wählen (und im Scheduler einplanen)(Bereits existierende InfoPackages werden im InfoSources-Baum unterhalb eines Quellsystems angezeigt,und können über das zugehörige Kontextmenü bearbeitet werden)
InfoProviderEin InfoProvider ist ein BW-Objekt, über das Queries definiert bzw. ausgeführt werden können. Infoproviderkönnen sein:- InfoCubes (BasisCubes, virtuelle Cubes)- DSO-Objekte- Merkmal-InfoObjects (mit Attributen oder Texten)- InfoSets- MultiProvider
InfoSetEin InfoSet ist ein InfoProvider, welche selbst keine Daten enthält. Ein InfoSet ist eine Abfragedefinition, mit derenHilfe Daten in der Regel über Joins von DSO-Objekten und/oder Merkmal-InfoObjects (mit Attributen oder Texten)im BW-System zur Laufzeit der Datenanalyse gelesen werden. Eine mögliche Anwendung von InfoSets ist dasReporting über Stammdaten.1) Anlegen eines InfoSets im InfoProvider-Baum: Einstieg: AWB Modellierung InfoProvider InfoArea wählen
Im Kontextmenü der InfoArea ’InfoSet anlegen’ wählen2) Pflege von InfoSets: Transaktion: RSISET
18
InfoSourceEine InfoSource ist eine Menge von logisch zusammengehörigen InfoObjects, die alle verfügbaren Informationenzu einem Geschäftsprozess enthält (z.B. Kostenstellenrechnung). Die Info Sourcen in BI 7.0 sind eine flacheTabellenstruktur, die eine temporäre Zwischenspeicherung von Daten nach einem Verarbeitungsschritt im Rahmenvon Transformationsregeln ermöglichen sollen. Ziel von Info Sourcen ist es, die Daten für den nächstenVerarbeitunsschritt vorzubreiten. Einer InfoSource können mehrere Transformationsregeln zugewiesen werden.
KennzahlKennzahl-InfoObjects, wie z.B. Umsatz, Menge, liefern die Werte, die bzgl. Merkmale ausgewertet werden sollen.Das BW unterscheidet folgende Kennzahltypen:- Betrag- Menge- Zahl- Integer- Datum- ZeitWählt man den Kennzahltyp Betrag oder Menge, so müssen entsprechende Einheiten mitgegeben werden, d.h.die Kennzahl wird an einem Einheiten-InfoObject oder an einem fixen Wert für eine Einheit geklammert.
Kennzahl als Flussgröße (= zeitraumbezogene Größe)In jeder Zeiteinheit, für die Werte zu dieser Kennzahl berichtet werden sollen, müssen Werte für diese Kennzahlgebucht sein ( z.B. Umsatz).
Kennzahl als Bestandsgröße (= zeitpunktbezogene Größe) Für die Bestandskennzahl werden nur für ausgewählte Zeitpunkte (Stützstellen) Werte gespeichert. Die Werte für die übrigen Zeitpunkte werden aus dem Wert in einer Stützstelle und den dazwischen- liegenden Bestandsveränderungen errechnet (z.B. Lagerbestand). Dabei gibt es zwei Möglichkeiten, Bestandsgrößen zu definieren:- ’Bestand mit Bestandsveränderung’
Bei der Definition der Bestandsgröße wird zusätzlich eine Flussgröße als Kennzahl-InfoObject,einesogenannte Bestandsveränderung benötigt, die in der Typdefinition mitder zu definierenden Bestandsgröße übereinstimmt.
- ‘Bestand mit Zu- und Abgängen’Bei der Definition der Bestandsgröße werden zwei Flussgrößen ‘Zugang’ und ‘Abgang’benötigt, die in der Typdefinition mit der zu definierenden Bestandsgröße übereinstimmen.
Aggregationen von Kennzahlen- ‘Standard-Aggregation (SUM/Max/Min)’
Mit der Standard-Aggregation legt man in der Kennzahl-Pflege fest, wie die Kennzahl im Datenziel (BasisCube, DSO-Objekt) aggregiert wird. Beim DSO-Objekt spielt diese Einstellung nur dann eine Rolle, wenn in der Pflege der Fortschreibungsregeln die Überschreiben-Funktion nicht ausgewählt wird..
- ‘Ausnahmeaggregation (letzter Wert, erster Wert, Max, Min,…)’Mit der Ausnahmeaggregation, die in der Kennzahl-Pflege festgelegt wird, kann eine komplexereAggregation von Kennzahlen ausgeführt werden.Beispiel:Die Kennahl ‘Anzahl der Mitarbeiter wird summiert über das Merkmal ‘Kostenstelle’
Standard-Aggregation). In diesem Fall könnte man für die Ausnahmeaggregation‘letzter Wert’ ein Zeitmerkmal als Bezugsmerkmal wählen.
ReferenzkennzahlEs besteht die Möglichkeit, eine Kennzahl mit Referenz auf eine andere Kennzahl (= Referenzkennzahl)anzulegen. Ein Referenzkennzahl benötigt man in der Regel für die Binnenumsatzeleminierung.
1. Anlegen eines Kennzahl-InfoObject im InfoObjects-Baum
19
Einstieg: AWB Modellierung InfoObjects InfoArea wählen InfoObjectCatalog vom Typ Kennzahl wählen Im Kontextmenü des InfoObjectCatalog ’InfoObject anlegen’ wählen
2. Pflege von Kennzahlen:Transaktion: RSD1 bis RSD5
KlammerungEs ist häufig erforderlich, Merkmalswerte (Ausprägungen eines Merkmals) zu klammern, um eine eindeutigeZuordnung von Merkmalswerten zu ermöglichen. Die Klammerung wird in der Merkmal-InfoObject – Pflegeumgesetzt. Dabei können mehrere Merkmale als geklammerte Merkmale verwendet werden. Generell sollte mitgeklammerten Merkmalen sparsam umgegangen werden, da ansonsten die Reporting-Performance beeinträchtigtwird ( geklammerte Merkmal sind Bestandteil des Primärschlüssels der entsprechenden Stammdatentabellen)Beispiel:Die Kostenstelle 100 im Kostenrechnungskreis 1000 ist der Einkauf und im Kostenrechnungskreis 2000 derVertrieb, d.h. es ist keine eindeutige Auswertung möglich. Durch die Klammerung der Kostenstelle an denKostenrechnungskreis wird die Eindeutigkeit gewährleistet.
MerkmalMerkmal-InfoObjects (z.B. Kunde, Artikel) sind Bezugsobjekte. Sie werden genutzt, um Kennzahlen zubeschreiben, zu selektieren und auszuwerten. Merkmale können ferner Träger von Stammdaten (in Form vonStammdatentabellen) sein:- Attribute- Texte- HierarchienStammdatentragende Merkmale können ebenso als InfoSource mit direkter Fortschreibung für das Ladenvon Stammdaten verwendet werden. (Ausnahme: Referenzmerkmale, Einheit-InfoObjects und das merkmal0SOURSYSTEM)Besondere Merkmale:- Einheiten (z.B. 0CURRENCY (Währungsschlüssel), 0UNIT (Mengeneinheit))- Zeitmerkmale (z.B 0CALYEAR (Kalenderjahr))- technische Merkmale (z.B. 0REQUID (Request-ID))1. Anlegen eines Merkmal-InfoObject im InfoObjects-Baum
Einstieg: AWB Modellierung InfoObjects InfoArea wählen InfoObjectCatalog vom Typ Merkmal wählen Im Kontextmenü des InfoObjectCatalog ’InfoObject anlegen’ wählen
2. Pflege von Merkmalen: Transaktion: RSD1 bis RSD5
ReferenzmerkmalZur Wiederverwendbarkeit definierter Merkmal-InfoObjects, können Referenzmerkmale verwendet werden.Referenzmerkmale liefern die technischen Eigenschaften zu einem anderen Merkmal. Diese Eigenschaftensind nur beim Referenzmerkmal pflegbar. (Unter technische Eigenschaften fallen Stammdatentabellen(Attribute, Texte, Hierarchien) Datentyp, Länge, Anzahl und Art der geklammerten Merkmale, Kleinbuchstabenund Konvertierungsroutine)
Metadata RepositoryDas Metadata Repository umfasst alle Meta-Objekte (InfoCubes, InfoObjects, Queries, etc.) im BW und derenBeziehungen zueinander.1. Einstieg: AWB Metadata Repository
20
2. Transaktion: RSORMetadatenMetadaten sind Daten/Informationen über Daten. D.h. Metadaten beschreiben Herkunft, Historie und weitereAspekte der Daten. Durch die Metadaten können die Informationen, die im BW gespeichert sind, effektiv für dasReporting und der Analyse genutzt werden. Dabei unterscheidet man zwischen:- technische Metadaten
(z.B. Ablagestrukur der Daten, wie etwa das Zahlenformat einer Kennzahl)- betriebswirtschaftliche/fachliche Metadaten
(z.B. Verantwortliche für die Daten, Datenherkunft)
MonitorMit Hilfe des Monitors können Datenanforderungen (Requests) und die Datenverarbeitung innerhalb der AWBüberwacht werden.1. Einstieg: AWB Monitoring2. Transaktionen: RSMON (Monitoring) bzw. RSMO (Monitor)
MultiProviderEin MultiProvider ist ein spezieller InfoProvider, der Daten aus mehreren InfoProvidern zusammenführt und siegemeinsam für das Reporting zur Verfügung stellt. Ein MultiProvider enthält selbst keine Daten. Seine Datenergeben sich ausschließlich aus den zugrunde liegenden InfoProvidern. Ein MultiProvider kann sich ausverschiedenen Kombinationen der nachstehenden InfoProvider zusammensetzen:- InfoCube- DSO-Object- Merkmal-InfoObject (mit Attributen oder Texten)- InfoSetDefinition von MultiProvider:Einstieg: AWB Modellierung InfoProvider InfoArea wählen
Im Kontextmenü der gewählten InfoArea ’ MultiProvider anlegen’ und die InfoProvider wählenDSO-Objekt
Ein Operational Data Store – Objekt (DSO-Objekt) dient der Ablage von konsolidierten und bereinigten Daten(Bewegungs- oder Stammdaten) auf Belegebene. Ein DSO-Objekt enthält Schlüsselfelder (Merkmale) sowieDatenfelder, die im Gegensatz zum BasisCube neben Kennzahlen auch Merkmale sein können.Im Unterschied zu BasisCubes bestehen DSO-Objekte aus drei (flachen) Tabellen:
Activation Queue ( = Eingangstabelle des DSO-Objektes)In dieser Tabelle werden die neuen Daten abgelegt, bevor sie aktiviert werden. Sie ist von der Struktur ähnlichwie eine PSA-Tabelle aufgebaut, d.h. der Schlüssel wird aus Request-, Datenpaket- und Datensatznummergebildet. Nachdem alle in der Activation Queue stehenden Requests erfolgreich aktiviert sind, werden dieRequests aus der Activation Queue gelöscht.Tabelle mit den aktiven DatenHier ist der aktuelle Zustand der Daten abgelegt. Diese Tabelle besitzt einen semantischen Schlüssel, der vomModellierer definiert werden kann (z.B. Auftragsnummer, -position). Das Reporting setzt auf diese Tabelle auf.Werden angeschlossene Datenziele im Fortschreibungsmodus Full-Update versorgt, so werden diese aus derTabelle mit den aktiven Daten fortgeschrieben.Change Log ( = Ausgangstabelle für angeschlosssene Datenziele)Beim Aktivierungslauf werden die Änderungen im Change Log abgelegt. Dort findet man alsodie gesamte (Aktivierungs-)Historie der Änderungen, da der Inhalt des Change Log nicht automatisch gelöschtwird. Werden angeschlossene Datenziele aus dem DSO-Objekt im Deltaverfahren mit Daten versorgt, sowerden diese aus dem Change Log fortgeschreiben. Das Change Log ist eine PSA-Tabelle und auch im PSA-Baum der AWB pflegbar. Demnach besitzt das Change Log einen technischen Schlüssel aus Request-Datenpaket-, Datensatznummer).
21
Der neue Zustand der Daten wird parallel in das Change Log und in die Tabelle mit den aktiven Daten geschrieben!Man unterscheidet die folgenden DSO-Objekt – Typen:
Standard – DSO-ObjektBei diesem Objekt handelt es sich um das oben beschriebene DSO-Objekt ( drei Tabellen).Analog zu BasisCubes werden DSO-Objekte über eine oder mehrere InfoSources viaFortschreibungsregeln versorgt. Bei den Fortschreibungsregeln hat man neben denen,
die auch für BasisCubes gelten, die zusätzliche Option, Datenfelder zu überschreiben. 1. Standard – DSO-Objekt anlegen:
Einstieg: AWB Modellierung InfoProvider InfoArea wählen Im Kontextmenü der gewählten InfoArea ’DSO-Objekt anlegen’ wählen
2. Bearbeiten von Standard – DSO-Objekten: Transaktion: RSDDSO
3. Standard – DSO-Objekt administrieren:Einstieg: AWB Modellierung InfoProvider InfoArea wählen
Im Kontextmenü des gewählten DSO-Objektes ’Administrieren’ wählenSelektives löschen ( Registerkarte ’Inhalt’)Analog zum BasisCube können mit dieser Funktion durch eine vorherige Selektion gezielt Datensätze,die diesen Selektionskriterien entsprechen, aus dem DSO-Objekt gelöscht werden. Das selektiveLöschen hat nur Auswirkungen auf die Tabelle mit den aktiven Daten! D.h. nur in dieser Tabellewerden die Einträge gelöscht.Wird das selektive Löschen verwendet, um fehlerhafte Datensätze aus dem DSO-Objekt zu löschen,so kann man die richtigen bzw. korrigierten Datensätze mit Hilfe eines Reparatur-Request
Scheduler InfoPackage pflegen) wieder einbuchen.Requests löschen ( Registerkarte ’Requests’)Mit dieser Funktion hat man die Möglichkeit gezielt Requests zu löschen, die in das DSO-Objektgeladen wurden (falls diese noch nicht in angeschlossene Datenziele fortgeschrieben sind). Dabeiunterscheidet man zwei Ausganssituationen:
- nicht aktivierte Requests In diesem Fall werden die Requests nur aus der Activation Queue gelöscht- aktivierte Requests
In diesem Fall werden die Requests aus der Tabelle mit den aktiven Daten und aus dem ChangeLog gelöscht
Requests neu aufbauen ( Registerkarte ’Neuaufbau’)Mit dieser Funktion können bereits gelöschte Requests zu einem DSO-Objektwiederhergestellt werden. Diese werden dann wieder in die Activation Queue abgelegt.Diese Funktion ist nur möglich, falls die Requests in der PSA-Tabelle gehalten werden.Change Log löschenMit dieser Funktion können Requests aus dem Change Log gelöscht werden, die nicht mehr zurFortschreibung oder zum Neuaufbau von angeschlossenen Datenzielen benötigt werden. Des Weiterenmacht es Sinn Change Log Requests zu löschen, sofern das Change Log überhaupt nicht benötigtwird.Administrieren: Umfeld Change Log Daten löschen
Direkt update DSO-ObjektEin DSO-Objekt diesen Typs besitzt nur die Tabelle mit den aktiven Daten. Folglich kann dieser DSO-Typ nicht in denStaging-Prozess eingebunden werden, da sowohl die Activation Queue als auch das Change Log nicht verwendetwerden. Diese DSO-Objekt –Typen werden durch APIs gefüllt und können über ein BAPI gelesen werden. Sie dienen alsDatenablage für externe Applikationen, wie z.B. das SAP SEM (Strategic Enterprise Management). Transaktionale DSO-Objekte sind automatisch für das Reporting verfügbar.
Im Kontextmenü der gewählten InfoArea ’DSO-Objekt anlegen’ wählen Unter Einstellungen Typ DSO-Objekt wählen Im Kontextmenü ’Typ ändern’ wählen
2. Bearbeiten von Standard – DSO-Objekten: Transaktion: RSDDSO
Write optimized DSO-Objekt Ein DSO-Objekt diesen Typs besitzt nur die Tabelle mit den aktiven Daten. Dieses Objekt ist optimiert für die Übernahme
von Massendaten aus einem Vorsystem. Die Daten werden dabei 1:1 übernommen. Jeder Datensatz wird mit einemeindeutigen technischen Schlüssel versehen, der eine weitere Verarbeitung im Rahmen der Datentransferprozesseermöglicht. Ein Reporting ist generell auf diesem Objekttyp möglich, die Aussagekraft ist jedoch nicht in allen Fälleneindeutig.
Online Analytical Processing (OLAP)Kernpunkt dieser Softwaretechnologie ist die multidimensionale Bereitstellung der Daten.Durch die Multidimensionalität lassen sich sehr flexible Abfrage- und Analysewerkzeuge erstellen, die einenschnellen, interaktiven, flexiblen Zugriff auf relevante Informationen ermöglichen
ROLAP (Relationales OLAP) Aufgabe der ROLAP-Engine ist es, relationale Daten (mittels Sternschema) in multi- dimensionalen Strukturen aufzubereiten, um so für einen effizienten Zugriff zu sorgen. Beispiel für ein ROLAP-System ist das SAP BW.MOLAP (multidimensionales) OLAPHier werden die Daten bereits physikalisch in multidimensionalen Strukturen (Zell-/Array-Strukturen)gespeichert, weshalb eine weitere Aufbereitung der Analysewerkzeuge nicht mehr nötig ist sehr schnelleAntwortzeiten bei Abfragen und Kalkulationen. Bisher sind aber MOLAP-Systeme für große Datenmengenweniger geeignet als ROLAP-Systeme.
Online Transaction Processing (OLTP)Kernpunkt dieser Softwaretechnologie ist die relationale Bereitstellung der Daten für die Abwicklung undDokumentation von Geschäftsprozessen (z.B. Fakturierung, Lagerbestands- verwaltung). Durch die notwendigeNormalisierung ( i.d.R. die 3.Normalform garantiert Datenkonsistenz und referentielle Integrität) werdenaber die Abfragen komplexer, da viele Tabellen gelesen werden müssen. (z.B. das klassische R/3-System ist einOLTP-System).PSA-TabelleDie Persistent Staging Area (PSA) stellt die Eingangsschicht in der SAP BW Architektur dar. Die PSA besteht austransparenten DB-Tabellen, den sogenannten PSA-Tabellen, in denen aus dem Quellsystem stammende Datenohne Modifikation (= Rohdaten) abgelegt bzw. zwischengespeichert werden können. Der Aufbau der PSA-Tabellenentspricht im wesentlichen der Transferstruktur. Genau: Schlüsselfelder der PSA + Felder der Transferstruktur,wobei sich der Schlüssel aus der Request-, Datenpaket-, Datensatznummer zusammensetzt. PSA-Tabellen(technischer Name: /BIC/B000*) werden pro DataSource beim Aktivieren der Übertragungsregeln vom System nurdann generiert, falls die Transfermethode ’PSA’ in der Pflege der Übertragungsregeln gewählt wurde.Beim Laden von Daten in die Datenziele Merkmal-InfoObject/BasisCube/DSO-Objekt kann zwischen den folgendenVerbuchungsarten im Scheduler gewählt werden:
PSA und danach InfoObject/Datenziele (paketweise)Bei dieser Verbuchungsart wird ein Datenpaket eines Requests zunächst aus dem Quellsystem extrahiert undin die PSA-Tabelle geschrieben. Sobald das Datenpaket vollständig in die PSA-Tabelle übertragen wurde,beginnt die Verbuchung der Daten in die Stammdatendaten- tabellen/Datenziele. Zeitgleich mit der Verbuchungbeginnt auch die Extraktion des nächsten Datenpaketes, so dass Extraktion und Verbuchung parallel ausgeführtwerden.PSA und danach InfoObject/Datenziele parallel (paketweise)
23
Bei der parallelen Verbuchung beginnt die Verbuchung in die Stammdatendatentabellen /Datenziele zeitgleichmit dem Schreiben der Datenpakete in die PSA-Tabelle.Nur PSA und anschließend in die InfoObjects/Datenziele fortschreibenBei dieser Verbuchungsart werden alle Datenpakete eines Requests zunächst in die PSA-Tabelle geschriebenund anschließend in die Stammdatentabellen/Datenziele verbucht. D.h. hier findet keine Parallelisierung vonVerbuchung und Extraktion statt.Nur PSADiese Verbuchungsart ermöglicht es, alle zu extrahierenden Datenpakete eines Requests in die PSA-Tabelleabzulegen, ohne sie in die Stammdatentabellen/Datenziele fortzuschreiben. Die Weiterverbuchung wird zueinem anderen Zeitpunkt angestoßen.Nur InfoObject/DatenzielBei dieser Verbuchungsart werden die Datenpakete eines Requests direkt in die Stammdaten-tabellen/Datenziele verbucht, d.h. die Datenpakete werden nicht in einer PSA-Tabelle zwischengespeichert.
ProzessketteUnter einer Prozesskette versteht man eine Reihe von Prozessen, die im Hintergrund (= Batch) eingeplant auf einEreignis (Event) warten. Einige dieser Prozesse lösen ein eigenes Ereignis aus, das wiederum andere Prozessestarten kann. Mit Prozessketten lassen sich:- die komplexen Abläufe, wie z.B. die Ladeprozesse, im BW mit Hilfe der ereignisgesteuerten Verarbeitung
automatisieren- die Abläufe durch die Verwendung von Netzplangraphiken visualisieren- das Verarbeiten der Prozesse zentral steuern und überwachenPflege von Prozessketten: Transaktion: RSPC
QuellsystemQuellsysteme sind datenliefernde Instanzen für das BW:- Fremdsysteme (Non–SAP-System, R/2-System, R/3-System ( Rel. 3.1i)- SAP-Systeme- BW-Systeme (Data Marts)- Datenbanken (DB Connect)- Flatfiles (CSV- und ASCII-Dateien)- Flatfiles für externe Marktdaten (z.B. Marktdaten von Dun & Bradstreet (D&B))- XML-DateiQueryMit Hilfe einer Query (= Abfrage) lassen sich Merkmal- und Kennzahl-InfoObjects zur Analyse der Daten einesInfoProvider im Query-Designer zusammenstellen. Eine Query bezieht sich immer auf einen InfoProvider, währendzu einem InfoProvider beliebig viele Queries definiert werden können.
Referentielle IntegritätDie Prüfung auf referentielle Integrität kann nur für Bewegungsdaten und für Stammdaten erfolgen, falls dieseflexibel fortgeschrieben werden ( InfoSource mit flexibler Fortschreibung). Sie ermittelt die gültigen Werte desInfoObjects. Die Verprobung erfolgt nach dem Füllen der Kommunikationsstruktur, aber noch vor dem Anwendender Fortschreibungsregeln. Geprüft wird gegen die SID-Tabelle eines Merkmals oder gegen ein DSO-Objekt, das inder Pflege eines Merkmal-InfoObject ausgezeichnet wurde. Um die Prüfung auf referentielle Integrität nutzen zukönnen, muss im Scheduler (InfoPackage pflegen) innerhalb der Registerkarte ’Fortschreibung’ die Option ’Datenimmer verbuchen, auch wenn keine Stammdaten für Daten existieren’ gewählt werden, da sonst die Prüfung aufreferentielle Integrität übersteuert wird. Ferner müssen die Merkmal-InfoObjects, die auf referentielle Integritätgegen SID-Tabellen/DSO-Objekte geprüft werden sollen, in der InfoSource-Pflege in der Spalte ’ReferentielleIntegrität’ gekennzeichnet werden.
24
RFC (Remote Function Call)Über den RFC können Daten zwischen SAP-Systemen und eigenentwickelten Programmen sicher und zuverlässigübertragen werden. Mit dem RFC wird ein Funktionsbaustein in einem fremden SAP-System, BW-System,eigenentwickelten Programmen oder innerhalb eines SAP-Systems aufgerufen. Dabei werden die Daten überTCP/IP oder X.400 als Bytestrom übergeben. Im Fall eines asynchronen Aufrufs spricht man von einemtransktionalen RFC (tRFC).
SAPI (Service-API)Das (BW-)SAPI ist die Schnittsstelle, die mit dem Plug-In eingespielt wird. Über das SAPI findet dieKommunikation bzw. der Datenaustausch zwischen den SAP-Systemen (z.B. SEM, CRM, APO, R/3) unddem BW-System, zwischen XML-Dateien und BW-System und zwischen BW-Systemen statt. Das SAPI beruhtausschließlich auf SAP Technologie und ist für SAP-Systeme ab Basis Release 3.1I verfügbar.Die BW Service-API Technologie wird an verschiedenen Stellen innerhalb der SAP BW Architektur verwendet:- Zur Übertragung von Daten und Metadaten aus SAP-Systemen- Bei Datenübertragungen zwischen BW-Datenzielen innerhalb eines BW-Systems
(Data Mart – Myself Interface) oder in ein anderes BW-System (Data Mart – Interface)- Bei der Übertragung von Daten aus XML-Dateien
Surrogat-Identifikation (SID)Die SIDs sind systemgenerierter INT4-Schlüssel. Dabei wird zu jedem Merkmal (Ausnahme: Merkmal ist ein‘ausschließliches Attribut’) ein SID-Schlüssel generiert. Diese Zuordnung wird in einer SID-Tabelle zum jeweiligenMerkmal umgesetzt, wobei das Merkmal Primärschlüssel der SID-Tabelle ist. Die SID-Tabelle ist über denMerkmalschlüssel mit den zugehörigen Stammdatentabellen (falls vorhanden) verbunden. Wird ein Merkmalbeim Anlegen eines BasisCube einer Dimension zugeordnet, so wird nach der Aktivierung des BasisCube dieSID-Tabelle dieses Merkmals mit der entsprechenden Dimensionstabelle verbunden. Die SID-Werte werden beimLaden von Stamm- bzw. Bewegungsdaten generiert und in die entsprechenden SID-Tabellen geschrieben.Bei Bewegungsdaten werden diese zum Aufbau der DIM-ID auch in die Dimensionstabellen geschrieben. DieVerwendung von INT4-Schlüsseln (SID-/DIM-ID – Schlüssel) ermöglicht einen schnelleren Datenzugriff als beilangen alphanumerischen Schlüsseln. Durch die SID-Technik im BW Sternschema wird ferner ermöglicht, dieStammdaten BasisCube-übergreifend zu verwenden.
Technischer Content (TCT)Mit dem TCT werden die nötigen BW-Objekte/Werkzeuge zur Nutzung der BW Statistik bereitgestellt.Die BW Statistik ist ein Werkzeug zur Analyse und Optimierung der Prozesse, wie z.B. Zugriffszeiten auf Datenmit Queries, Ladeprozesszeiten. Die Daten der BW Statistik werden im BW gespeichert und werden über einenMultiProvider, der auf mehrere BW BasisCubes basiert. Die Übernahme des TCT erfolgt analog zum BCT.Um die BW Statistik schließlich nutzen zu können, muss diese vorher für ausgewählte InfoProvider aktiviert werden(Einstieg: AWB Werkzeuge BW Statistiken für InfoProvider).
TextTexte (z.B. Bezeichnung einer Kostenstelle) gehören wie Attribute und Hierarchien zu den Stammdaten im BW. Inder Pflege eines Merkmal-InfoObject ( Registerkarte ’Stammdaten/Texte’) legt man fest, ob das Merkmal überTexte verfügen soll. Falls ja, muss man mindestens eine Textauswahl treffen: Kurz-, Mittellanger-, und Langtext(20, 40, 60 Zeichen). Ferner kann ausgewählt werden, ob die Texte zeit- und/oder sprachabhängig sind. Textewerden in einer Stammdatentabelle für Texte zum Merkmal abgelegt.
25
Transaktionaler BasisCubeTransaktionale BasisCubes finden meist nur in Verbindung mit SEM Verwendung. Auf die Daten eines solchenBasisCube wird transaktional zugegriffen, d.h. Daten werden (evtl. von mehreren Benutzern gleichzeitig) in denBasisCube geschrieben und möglicherweise sofort wieder gelesen; (Standard-)BasisCubes sind dafür nichtgeeignet. Für einen reinen Lesezugriff sollten Standard-BasisCubes verwendet werden.
TransferstrukturDie Transferstruktur dient dem BW zur Bereitstellung aller zu einem Geschäftsprozess bzw. zu einer Geschäfts-einheit verfügbaren Metadaten eines SAP-Quellsystems. Sie stellt eine Auswahl der Felder einer Extraktstrukturdes SAP-Quellsystems dar. In der Transferstrukturpflege im BW wird durch Zuordnung von DataSource undInfoSource festgelegt, welche Felder Ladeprozess genutzt werden sollen. Mit dem Aktivieren der Übertragungs-regeln wird die Transferstruktur sowohl im BW-System als auch im SAP-Quellsystem generiert. Die Transferstrukturwird im BW-System in der Tabelle RSTS und im SAP-Quellsystem in der Tabelle ROOSGEN abgelegt. Die Datenwerden 1:1 von der Transferstruktur des SAP-Quellsystems in die Transferstruktur des BW übernommen und dannmit Hilfe der Übertragungsregeln der Kommunikationsstruktur des BW übergeben. Ist das Quellsystem ein Dateien-System, so werden die Metadaten im BW-System gepflegt, somit muss auch die die Transferstruktur manuell imBW-System definiert werden. Dabei muss die Struktur der Transferstruktur die Struktur der Datei beschreiben.
ÜbertragungsregelMit den Übertragungsregeln wird festgelegt, wie Quelldaten über die BW-Transferstruktur an die Kommunikations-struktur weitergegeben werden, d.h. Übertragungsregeln gelten nur für die Daten aus einem Quellsystem. Manspricht daher auch von lokalen Übertragungsregeln. Man unterscheidet folgende Übertragungsregeln:- Daten werden 1:1 fortgeschrieben- Versorgung mit einer Konstanten Die Felder der Kommunikationsstruktur können während des Ladeprozesses mit fixen Werten versorgt werden, d.h. die Felder werden nicht über die Transferstruktur versorgt.- Mit Hilfe von ABAP-Routinen bzw. des Formel-Editors können Übertragungsregeln flexibel gestaltet werden.Bearbeiten von Übertragungsregeln:Einstieg: AWB Modellierung InfoSources Anwendungskomponente wählen
ÜbertragungsroutineIn der Pflege eines Merkmal-InfoObject hat man die Möglichkeit, eine sogenannte (globale) Übertragungsroutine(ABAP-Routine/kein Formel-Editor)) anzulegen. Im Gegensatz zur lokalen Übertragungsroutine ist die globaleÜbertragungsroutine quellsystemübergreifend verwendbar. Diese Übertragungsroutine wird nur genutzt, falls dasMerkmal als InfoSource mit direkter Fortschreibung verwendet wird. Falls eine lokale und eine globale Übertra-gungsroutine genutzt wird, so wird erst die lokale und dann die globale Übertragungsroutine durchlaufen.
Virtueller CubeVirtuelle Cubes sind spezielle InfoCubes. Ein virtueller stellt eine logische Sicht dar. Im GegensatzZum BasisCube werden aber keine Daten physisch im BW abgelegt. Die Daten werden erst bei der Ausführung vonQueries aus den Quellsystemen beschafft. Man unterscheidet im Hinblick auf die Datenbeschaffung folgendeTypen:
SAP RemoteCube Ein SAP RemoteCube erlaubt die Definition von Queries mit direktem Zugriff auf Bewegungsdaten in anderen SAP-Systemen. Voraussetzungen für das Nutzen von SAP RemoteCubes:
- die Funktionalität des BW SAPI ist installiert ( enthalten im Plug-In des SAP-Quellsystems- der Releasestand des Quellsystems ist mindestens 4.0B
26
- der InfoSource des RemoteCube sind DataSources aus dem Quellsystem zugeordnet, die für den Direkzugriff freigegeben sind, und es bestehen aktive Übertragungsregeln für diese Kombination. Ob eine DataSource den direkten Zugriff unterstützt, kann man sich in der Tabelle ROOSOURCE
anschauen. Falls das Feld VITCUBE die Ausprägungen 1 oder 2 hat.Allgemeiner RemoteCubeEin Allgemeiner RemoteCube ermöglicht das Reporting von Daten aus Nicht-SAP – Systemen.Das Fremdsystem übergibt die angeforderten Daten über BAPIs an den OLAP-Prozessor. Dabei müssen dieDaten bereits aus dem Quellsystem in der Form geliefert werden, wie sie bei der Analyse benötigt werden, d.h.es können im BW System keine Übertragungsregeln definiert werden.Virtueller InfoCube mit ServicesDieser Typ ermöglicht es, Analysen auf den Daten eines selbstentwickelten Funktionsbaustein aufzubauen.Dieser Typ wird bei komplexen Berechnungen eingesetzt, die durch Queries mit Formeln und Ausnahme-aggregationen nicht vorgenommen werden können., wie z.B. beim SEM)
XML (eXtensible Markup Language) – IntegrationDer Datenaustausch mittes XML basiert auf den Standards, die von der Object Management Group (OMG) definiertwerden. Die OMG versucht Industriestandards für den Datenaustausch zwischen verschiedenen Systemen zuentwickeln. Im BW sind solche Transfermethoden für die Integration von Daten mittels XML implementiert. DieÜbertragung der XML-Daten in das BW erfolgt über das SOAP (Simple Object Access Protocol) unter Verwendungdes HTTP (Hypertext Transfer Protocol). Dabei werden die Daten selbst im XML-Format beschrieben. Diese Datenwerden zunächst in die Delta-Queue geschrieben und anschließend über eine DataSource zum Quellsystem Myselfin die gewünschten Datenziele fortgeschrieben. Diese Transfermethode sollte nicht für Massendaten verwendetwerden; große Datenmengen sollten dann über das Flatfile-Interface geladen werden.
27
Anhang 1: Abkürzungen
ABAP Advanced Business Application ProgrammingADK Archiving Development KitALE Application Link EnablingAPI Application Programming InterfaceASCII American Standard Code for Information InterchangeAWB Administrator WorkbenchBAPI Business Application Programming InterfaceBCT Business ContentBEx Business ExplorerBW Business Information WarehouseCSV Colon Separated Variables/ValuesDDIC Data DictionaryDIM-ID Dimension-IdentifikationDWH Data WarehouseETL Extraktion, Transformation und LadenIDoc Intermediate DocumentODBO OLE DB (Object Linking and Embedding Database) for OLAPOLAP Online Analytical ProcessingOLTP Online Transaction ProcessingRFC Remote Function CallSAPI Service-APISID Surrogat-IdentifikationSOAP Simple Object Access ProtocolSQL Structured Query LanguageTCT Technischer ContenttRFC transaktionaler RFCWAS Web Application ServerXML eXtensible Markup Language
28
Anhang 2: Transaktionscodes
1. Transaktionen im BW-System
Transaktion BedeutungBAPI BAPI ExplorerCMOD Projektverwaltung von SAP-ErweiterungenFILE Pflege von logischen dateipfadenLISTCUBE Listviewer für Datenziele ( BasisCubes, DSO-Objekte, Merkmal-InfoObjects)LISTSCHEMA Schemaviewer für BasisCubes (inklusive Aggregate)RRMX Starten des BEx AnalyzerRS12 Sperreinträge (von Tabellen) anzeigen und löschenRSA1 Administrator Workbench ( Modellierung)RSA3 Extraktorchecker SAPI 3.0RSA5 DataSources aus dem Business Content übernehmenRSA6 DataSources und Anwendungskomponentenhierarchie nachbearbeitenRSA7 Pflege der Delta-QueueRSA9 Anwendungskomponente aus dem Business Content übernehmen
RSCUSTV1 Einstellungen für flache Dateien ändern Tausender-, Dezimal-, Feldtrenner sowie Feldbegrenzer)
RSCUSTV6 Schwellwerte für Datenladen ändern Paketgröße, Größe einer PSA-Partition, Frequenz Status-IDOC)
RSCUSTV8 Einstellungen zum Aggregatsänderungslauf (Change Run) ändern Schwellwert für Neuaufbau, Blockgröße)
RSD1, RSD2, RSD3 Pflege von InfoObjects vom Typ Merkmale / Kennzahlen / Einheiten)RSD4, RSD5 Bearbeiten von technischen Merkmalen und ZeitmerkmalenRSDBC DB Connect: Tabellen und Views selektierenRSDDV Pflege von AggregatenRSDIOBC Bearbeiten von InfoObjectCatalogsRSDMD Pflege von Stammdaten (zu einem Merkmal)RSDMPROM Bearbeiten von MultiProviderRSDDSO Bearbeiten von DSO-Objekten
RSDV Pflege der Gültigkeitsscheibe BasisCubes mit Kennzahlen vom Typ Bestandsgröße)
RSFH Test-Tool für BewegungsdatenextraktorenRSIMG BW Customizing EinführungsleitfadenRSISET Pflege von InfoSetsRSKC Pflege der erlaubten Zusatzzeichen im BWRSMD Test-Tool für StammdatenextraktorenRSMO MonitorRSMON Administrator Workbench ( Monitoring)RSMONCOLOR Wertung von RequestsRSO2 Pflege von generischen DataSourcesRSO3 Einrichten der Delta-Extraktion für Attribute und TexteRSOR Administrator Workbench ( Metadata Repository)RSORBCT Administrator Workbench ( Business Content)RSPC Pflege von ProzesskettenRSRT QuerymonitorRSRTRACE Query-TraceRSRV Analyse und Reparatur von BW-ObjektenRSSM Pflege von Reporting-BerechtigungsobjekteRSU1 / RSU2 / RSU3 Fortschreibungsregeln anlegen/ändern/anzeigen ( BasisCubes und DSO-Objekte)
29
Transaktion BedeutungSARA ArchivadministrationSBIW Anzeigen des Einführungsleitfadens ( Customizing der Extraktoren)SE03 Transport Organizer ToolsSE09 Transport OrganizerSE11 ABAP DictionarySE37 Function Builder ( Pflege von Funktionsbausteinen)SE38 ABAP Editor ( Pflege von ABAP-Programmen)SM04 BenutzerlisteSM12 Sperreinträge selektierenSM37 Job-ÜbersichtSM38 Queue (Job) – DefinitionSM50 ProzessübersichtSM59 Pflege von RFC-VerbindungenSM62 Pflege von EventsSM66 Globale Workprozess-ÜbersichtSPRO Customizing-LeitfadenST05 Performance-Analyse ( SQL-Trace)TRSA Test-Tool für Service-API
2. BW-relevante Transaktionen im SAP-R/3-System
Transaktion BedeutungRSA3 Extraktorchecker SAPI 3.0RSA5 DataSources aus dem Business Content übernehmenRSA6 DataSources und Anwendungskomponentenhierarchie nachbearbeitenRSA7 Pflege der Delta-QueueRSA9 Anwendungskomponente aus dem Business Content übernehmenRSO2 Pflege von generischen DataSourcesRSO3 Einrichten der Delta-Extraktion für Attribute und TexteSBIW Anzeigen Einführungsleitfadens ( Customizing der Extraktoren)TRSA Test-Tool für Service-API
30
Anhang 3: Metadaten-Tabellen
InfoObject
Tabelle BedeutungRSDIOBJ Verzeichnis aller InfoObjectsRSDIOBJT Texte von InfoObjectsRSDATRNAV NavigationsattributeRSDATRNAVT NavigationsattributeRSDBCHATR Stammdaten-AttributeRSDCHABAS Basismerkmale (für Merkmale, Zeitmerkmale und Einheiten)RSDCHA MerkmalskatalogRSDDPA DatenpaketmerkmaleRSDIOBJCMP Klammerung (Abhängigkeiten) von InfoObjectsRSKYF KennzahlenRSDTIM ZeitmerkmaleRSDUNI Einheiten
InfoCube
Tabelle BedeutungRSDCUBE Verzeichnis der InfoCubesRSDCUBET Texte zu den InfoCubesRSDCUBEIOBJ NavigationsattributeRSDDIME Verzeichnis der DimensionenRSDDIMET Texte zu DimensionenRSDDIMEIOBJ InfoObjects je Dimension (Verwendungsnachweis)RSDCUBEMULTI An MultiCube beteiligte InfoCubesRSDICMULTIIOBJ MultiProvider: Auswahl/Identifikation von InfoObjectsRSDICHAPRO InfoCubespezifische MerkmaleigenschaftenRSDIKYFPRO InfoCubespezifische KennzahleigenschaftenRSDICVALIOBJ InfoObjects der Bestandsgültigkeitstabelle zum InfoCube
Aggregat
Tabelle BedeutungRSDDAGGRDIR Verzeichnis der AggregateRSDDAGGRCOMP Beschreibung der AggregateRSDDAGGRT Texte zu den Aggregaten
DSO-Objekt
Tabelle BedeutungRSDO Verzeichnis aller DSO ObjekteRSDOT Texte von DSO-ObjektenRSDOIOBJ InfoObjects des DSO-ObjektesRSDOATRNAV Navigationsattribute im DSO-ObjektRSDOTABL Verzeichnis aller DSO Tabellen
31
PSA
Tabelle BedeutungRSTSDSO Verzeichnis aller PSA-Tabellen
DataSource (= OLTP-Source)
Tabelle BedeutungROOSOURCE Kopf Tabelle für SAP BW DataSources (SAP-Quellsystem/BW-System)RODELTAM BW Deltaverfahren (SAP-Quellsystem)RSOLTPSOURCE Replikatstabelle für DataSources im BW
InfoSource
Tabelle BedeutungRSIS Verzeichnis der InfoSources mit flexibler FortschreibungRSIST Texte zu den InfoSources mit flexibler FortschreibungRSISFIELD InfoObjects einer InfoSource
Kommunikationsstruktur
Tabelle BedeutungRSKS Kommunikationsstruktur zur InfoSources mit flexibler Fortschreibung
Kommunikationsstruktur (View) für Attribute zur InfoSource mit direkter FortschreibungRSKSFIELD Texte zu den InfoSources mit flexibler FortschreibungRSISFIELD InfoObjects einer InfoSource mit flexibler Fortschreibung
Transferstruktur
Tabelle BedeutungRSTS Transferstruktur im BWROOSGEN Generierte Objekte zur DataSource (z.B.Transferstruktur) im SAP-Quellsystem
Mapping
Tabelle BedeutungRSISOSMAP Mapping zwischen InfoSources und DataSources (= OLTP-Sources)RSOSFIELDMAP Mapping zwischen DataSource-Feldern und InfoObjects
