Datenextraktion – BW 350-JK Kapitel 1

SAP NetWeaver Benefits von SAP NetWeaver SAP Mobile Infrastructure (SAP MI) SAP Enterprise Portal (SAP EP) SAP Business Warehouse (SAP EP) SAP Master Data Management (SAP MDM) SAP Exchange Infrastructure (SAP XI) SAP Web Application Server (SAP Web AS) Life Cycle Management Composite Application Framework Portal Funktion: Mit SAP EP haben Sie über eine benutzerfreundlichen Portal-Oberfläche einen zentralen, personalisierten, Rollen-, sowie Web-basierten Zugriff auf Ihre Dienste, Anwendungen und Informationen aus verschiednen Quellen. Datenbereitstellung – Architektur Quellsystemtypen Sind bekannt!! Ist der Quellsystemtyp eine SAP BW-System, spricht man von einem SAP BW-Data Mart. Jede BW-System besitzt standardmäßig ein Verbindung zu sich selbst, das s.g. MySelf-System. Es muss nicht mehr eingerichtet werden. DataSource: Beschreibt gemeinsam mit einer InfoSource die Infrastruktur im BW, die die Datenübertragung bzw. –Bereitstellung von Daten quellsystemübergreifend oder innerhalb eines BW ermöglicht. Folgende DataSource-Typen: DataSource für Bewegungsdaten DataSource für Attribute DataSource für Texte DataSource für Hierarchien Metadaten einer DataSource aus Sicht des Quellsystems: eine Menge von logisch zusammengehöriger Felder, die in einer flachen Struktur, der Extraktstruktur, zur Datenübertragung ins SAP BW angeboten werden. Anwendungskomponente

Extraktionsmethode Extraktor Deltaverfahren Transfermethode InfoSource: Eine Menge von logisch zusammengehörigen InfoObjects und stellt konsolidierte und transformierte Daten zur Fortschreibung in die Datenziele des BW bereit. Sie fasst die Übertragungsregeln aller ihr zugeordneten DataSources zusammen. InfoSource mit direkter Fortschreibung Stammdaten –Attribute/Texte/Hierarchien InfoSource mit flexibler Fortschreibung Stammdaten –Attribute/Texte/Bewegungsdaten Aus technischer Sicht besteht eine InfoSource in Abhängigkeit vom InfoSource-Typ aus einer oder mehreren Kommunikationsstrukturen InfoSource mit flexibler Fortschreibung Hier werden die Daten aus einer Kommunikationsstruktur unter Verwendung von Fortschreibungsregeln in das zugeordnete Datenziel (BasisCube, ODS-Objekte; oder MerkmalInfoObjekt) fortgeschrieben. Mehrere Datenziele können über eine InfoSource versorgt werden. Über diese InfoSource können Stammdaten (Attribute, Texte) und Bewegungsdaten fortgeschrieben werden. Hierarchien können nicht über eine InfoSource mit flexibler Fortschreibung fortgeschrieben werden. Bei Verwendung eine InfoSource mit flexibler Fortschreibung ist es nicht immer gleich ersichtlich, ob es sich um Bewegungsdaten oder Stammdaten handelt. Deshalb, in der Betzeichnung kenntlich machen. Bei einer InfoSource mit flexibler Fortschreibung haben Sie in der Pflege der zugehörigen Kommunikationsstruktur die Möglichkeit, die Datenladevorgänge auf referenzielle Integrität zu prüfen. Mit den Übertragungsregeln legen Sie fest, welche InfoObjects der InfoSource (Felder der Kommunikationsstruktur) aus welchem Feld der Transferstruktur gefüllt werden kann und welche Methode dabei angewendet wird. Lokale Übertragungsroutine: Bei der Pflege der Transferstruktur zur Kommunikationsstruktur haben Sie die Möglichkeit, einem InfoObjekt eine Übertragungsroutine zuzuordnen. Sie gilt lokal quellsystemspezifisch für das InfoObjekt. Globale Übertragungsregeln:

Diese gilt global quellsystemübergreifend für das Merkmal-Info-Objekt und wird in allen Übertragungsregeln mit eingebunden. Sie können hier die Daten verändern (Hinzufügen oder löschen) oder auch prüfen. der das Datenpaket in die PSA-Tabelle schreibt. Nur PSA Verbuchung aller Datenpaketes in die PSA Tabelle. dass sowohl die PSA-Tabellen. Für iDOC ist keine Verwendung von Startroutinen möglich.Bei einem Merkmal-Info-Objekt haben Sie die Möglichkeit.und Ausgang für die Info iDOCS zu administrieren sind).und Ausgang geleert bzw. der das Datenpaket in die PSA schreibt und sobald erfolgreich in der PSA Tabelle verbucht wurde. Der Prozess zur Datenübertragung (in die PSA) steht somit schon wieder zur Verfügung. wie Sie im Quellsystem innerhalb der Transaktion SBIW (Customizing der Extraktoren) für die maximale Anzahl paralleler Prozesse eingestellt haben. wird im Unterschied zu oben. falls diese genutzt werden. nur so viele Dialog-Prozesse benötigt. beginnt die Verbuchung der Daten mit dem selben Prozess in die Datenziele. als auch die Speicher im ALE Ein. iDOC (dafür sorgen. die pro Datenpaket ausgeführt wird. dass die Datenspeicher im ALE Ein. PSA und danach Datenziel (Paketweise) Bei dieser Verbuchungsart wird ein Dialogprozess pro Datenpaket eines Request gestartet. steht der Prozess für das Verbuchen eines weiteren Datenziels zur Verfügung. obwohl der erste Prozess noch im Datenziel bucht. PSA und Datenziel parallel (paketweise) Verbuchungsart: ein Dialogprozess pro Datenpaket eines Requests. eine Übertagungsroutine anzulegen. Definition Übertragungsregeln Wählen zwischen den Transfermethoden: PSA (zu empfehlen) (dafür sorgen.) Für Hierarchie muss iDOC gewählt werden. Für die Fortschreibung in die Datenziele stehen folgende Möglichkeiten zur Verfügung: Automatische Weiterverbuchung Weiterverbuchung einplanen Nur Datenziele Verbuchung direkt in die Datenziel ohne PSA. Erst nach Abschluss der Fortschreibung. ein zweiter. Sobald es erfolgreich übertragen wurde. paralleler Prozess gestartet. Im SAP BW werden pro Datenanforderung max. Bei der Pflege von Fortschreibungsregeln wird zwischen Fortschreibungsmethode und –art unterschieden: . Falls die Daten über die PSA geladen werden kann eine Startroutine in der Pflege der Übertragungsregeln angelegt werden. Sie muss nur einmal gepflegt werden. ohne sie in Datenziel fortzuschreiben. reorganisiert werden.

Formel Darüber hinaus gibt es noch eine Reihe weitere Möglichkeiten .) .Zeitverteilung etc. Attribut/Text im Datenziel mit individueller Schlüsselkombination fortgeschrieben wird.Umrechnungsroutine . Mit Hilfe der Fortschreibungsregeln können Datenziele mit Daten aus einer oder mehreren InfoSources gefüllt werden. Sie dienen der Verbuchung der Daten in die Datenziele sowie der Anreicherung und Modifikation der Daten. Zeitmerkmal) in das Datenziel fortgeschrieben wird. sondern Datenziel-spezifisch. Speziellen Fortschreibungsmethoden. HYPERLINK "\Srvparis\user\Jürgen\BI###BOT_TEXT###quot; \l "Zeitmerkmale" Zeitmerkmale.Die Fortschreibungsregeln spezifizieren. ob und wie eine Kennzahl bzw.Initialwert . Dazu gehören u. Merkmal.a. Mit der Fortschreibungsart steuern Sie. : .Konstante . Sie haben folgende Auswahlmöglichkeiten Fortschreibungsart für BasisCubes Addition Maximum Minimum . wie ein Wert ( Kennzahl. Mit der Fortschreibungsmethode steuern Sie.Währungsumrechnung .Ermitteln des Wertes über eine Routine (ABAP) . Fortschreibungsregeln sind im Unterschied zu HYPERLINK "\Srv-paris\user\Jürgen\BI###BOT_TEXT###quot; \l "Übertragungsregeln_lokal" Übertragungsregeln nicht Quellsystem. Sie haben folgende Auswahlmöglichkeiten: . Merkmale) aus der HYPERLINK "\Srv-paris\user\Jürgen\BI###BOT_TEXT###quot; \l "Kommunikationsstruktur" Kommunikationsstruktur einer HYPERLINK "\Srv-paris\user\Jürgen\BI###BOT_TEXT###quot; \l "InfoSourc" InfoSource in ein HYPERLINK "\Srv-paris\user\Jürgen\BI###BOT_TEXT###quot; \l "Datenziel" Datenziel geschrieben werden. sie legen also fest. Fortschreibungsregeln ordnen dazu die InfoObjects der InfoSource den InfoObjects der Datenziele zu .Füllen aus einem Quellfeld (Merkmal. den sog. Datenfeld bzw. wie die Daten (Kennzahlen.Rückgabetabelle . wie Kennzahlen und Merkmale aus der Kommunikationsstruktur in das Datenziel transferiert werden. Sie verbinden eine InfoSource mit einem Datenziel.Anreicherung .spezifisch. Kennzahl etc.

XML/SOAP: Unterstützt: SOAP-Services des SAP WAS. Bewegungsdaten. Kapitel 2 Datenextraktion aus SAP-Quellsystemen Die Verbindung zwischen Quellsystemen und BW besteht aus einzelnen Verbindungen und Einstellungen. Open Hup Service: Daten aus SAP-BW in SAP-CRM. Data Marts und nicht SAP-Applicationen zu übertragen. die auf beiden Systemen eingestellt werden müssen: RFC-Verbindung ALE-Einstellungen Partnerverbindungen Port iDOC-Typen iDOC-Segment Beim automatischen Anlegen des Quellsystems werden die notwendigen RFC-verbindungen mitgeneriert. DB Connect: Daten aus externen Anwendungen aus den jeweiligen DB-Tabellen oder –Views direkt ins BW übertragen . ERP. Manuell müsse diese vorab angelegt werden. Es können auch Third Party Tools integriert werden. UD-Connect: Unterstützt JSEE Konnektivität. Schnittestellen Service-API: Diese Technologie ermöglicht die Übertragung von Daten aus SAP-Sytemen.und Nicht-SAP-Systemen. Spezieller Bestandteil ist das Data Mart-Interface BAPI: für die Extraktion von Daten aus Fremdsystemen unter Anbindung verschiedener Third-PartyTools.Keine Fortschreibung Fortschreibungsart für ODS-Objekte Überschreiben Addition Keine Fortschreibung Analog zu den Übertagungsregeln haben Sie die Möglichkeit in der Pflege der Fortschreibungsregeln eine Startroutine anzulegen. SAP XI und Web Services. Die Transferstruktur muss im BW gepflegt sein. Texte. . Z. RFC-Verbindungen können in der Transaktion SM59 gepflegt werden. Hierarchien. praktisch alle relationalen und multidimensionalen Datenquellen. Daten aus Oracle. Sie beruhen auf der ALE Technologie (Applikation Link Enabling). Transaktion BAPIBrowser – anzeigen lassen. Flat Files: Flache Dateien wie Attribute. aus SAP.b.

Daten im Quellsystem zu verbuchen. DataSourceübergreifender Standardwert. Testtool zur Datenextraktion: Extractorchecker. Early-Delta-Initialisierung: Diese Eigenschaft einer DataSource. sind zwei Schritte notwendig: Übernahme der Anwendungskomponentenhierarchie Selektive Übernahme der DataSources Generische DataSource: Unabhängig von einer bestimmten Anwendung können folgende. Globale Steuerparameter der Datenübertragung: Die in der Transaktion SBIW im Bereich Allg. gelten als global.h. BCT-DataSources: Bevor Übernahme möglich. d. eigendefinierte Extraktionsmethoden gewählt werden: DB-Tabellen DB-Views Funktionsbausteine InfoSet (SAP Query) Es sind keine ABAP-Kenntnisse notwendig. Logistik Datenextraktion Die Pflege der Extraktstruktur und DataSources werden im „Logistik Extraktstrukturen Customizing Cockpit (LBWE)“ mit der Transaktion SBIW durchgeführt. . Einstellungen gepflegten Steuerparameter zur Datenübertragung.Service API-Funktionalität: Konfiguration von Quellsystemverbindungen Delta Queue (Zwischenablage für Delta-Sätze) Kontrolle der Datenextraktion durch Austausch von Meldungen zwischen den Systemen Weniger Ausfallzeit bei Initialisierungen Delta Queue: Zentrale Zwischenablage für Delta-Sätze. Das Customizing der Datasources wird in der Transaktion SBIW durchgeführt. ermöglicht es. Es gibt an auf welche Weise Daten übertragen werden. während einer Delta-Initialisierung. Technische Eigenschaften der DataSource: Extraktionsmethode/Extractor PSA oder iDOC Deltaverfahren: Ist eine DataSource deltafähig beschreibt sie in ihren Metadaten ein bestimmtes Deltaverfahren.

Queued Delta: (V2 – Verbuchung: Asynchrone Verbuchung. Customer Append: Erster Schritt: Customer Append für die Extraktstruktur der DataSource generieren. Aus LO-Cockpit nicht möglich. Jede Belegbuchung erfolgt direkt in die BW-Delta-Queue. Sie gelangen in die BW-Delta Queues. . BW-Protokoll: Kontrolle der Übertragung. Ein Full-Update ins BW wird ebenfalls über die Neuaufbautabellen durchgeführt. und fortan werden Daten in die Extraktstruktur geschrieben. Aktivieren der Fortschreibung: Setze Aktivierung. Jedem Hintergrundlauf wird ein Name zugeordnet. wird das Protokoll benutzerbezogen pro Applikation abgelegt. Zwischenstand wird danach gelöscht. Erfolgt ein Abbruch. Fehlende Felder werden ergänzt.Realtime Verbuchung. aber ohne Reihefolge. Jobsteuerung Initialisierung/Setup: erfolgt auf OLTP-Seite. Protokoll nur zu Testzwecken benutzen. Unserialisierte V3-Verbuchung: Werden in die Verbuchungstabellen geschrieben und dort solange gehalten bis die Daten durch Verbuchungssammellauf ausgelesen und verarbeitet werden. Daten werden in einer sog. online und beim Füllen der Neuaufbautabellen. Nach der Erstellung der Extraktstruktur wird diese automatisch generiert. SAP liefert bereits Extraktstrukturen. Es werden dabei pro DataSource bis zu 10000 Delta-Extraktionen zu einer LUW verdichtet. synchrone Verbuchung). Erweiterung von BCT DataSources (Datenextraction anpassen) Es kann weniger Auswand bedeuten eine neue Generische DataSource anzulegen als eine vorhandene zu erweitern. Neuaufbau soll im Hintergrund laufen. Die Übertragungsreihenfolge stimmt dabei mit der zeitlichen Erstellungsreihenfolge der Daten überein. Löschen der Inhalte aus der Neuaufbautabelle: Das Löschen der Tabellen geschieht aus Performance-Gründen mandantenübergreifend. Wenn der Benutzerparameter MCL gesetzt ist. wird der Stand des Neuaufbaus unter diesem Namen gespeichert und kann später an dieser Stelle fortgesetzt werden. Verbuchungsmethoden: Stehen im Logistik Extraktstrukturen Customizing Cockpit (LBWE)“ pro Applikation zur Verfügung. die erweitert werden können.Funktionalitäten: Pflege von Extraktstrukturen ( wird von Berater oder von SAP gepflegt). die während der Initialisierung gelesen werden. Ein Neuaufbau füllt Neuaufbautabellen. Verbuchung erfolgt erst nachdem alle V1 – Verbuchungen erfolgt sind). Direct Delta: (V1 Verbuchung . Extractions Queue gesammelt und können durch einen Verbuchungssammellauf in die BW-Delta-Queue übertragen werden. Pflege von DataSources: allgemeine Pflege zur Auswahl von selektierbaren Feldern und Negierbarkeit.

ist aber möglich. Im Bereich Generische DataSource im Quellsystem steht die Transaktion RSO2 Generische Data Source pflegen von Bewegungsdaten. DQ = DeltaQueue Bezeichnung der Tabelle RSA7 = die zentrale Transaktion zur Anzeige der Delta Queue im SAP-Quellsystem. wenn keine DataSource zur Verfügung gestellt wird.. EXIT_SAPLRSAP_001 Bewegungsdaten-Versorgung EXIT_SAPLRSAP_002 Stammdaten.Zweiter Schritt: Erweiterung zum Füllen der neuen Felder in der Extraktstruktur. über BAPI. Kapitel 3 Delta Management Bedeutet: Nur neue oder geänderte Datensätze in das SAP BW zu extrahieren. SAP-System: Nicht alle BCT-DataSources Fremdsystem: Third Party Tools.DeltaQueue SAP BW Quellsystem: Delta-Queue wird nicht verwendet. UD-Connect: lässt sich mit dem Tool „Generische DataSource“ realisieren. Delta vorahnden: Deltafähig. ist deltafähig XML/SOAP: Deltafähigkeit leitet sich immer von Flat File DataSource ab. bei DataMart Szenarien. Generische Datenextraktion Einsetzen. . SAP stellt die Erweiterung RSAP0001 mit vier Erweiterungskomponenten zur Verfügung.und Text-Versorgung EXIT_SAPLRSAP_003 Text-Versorgung EXIT_SAPLRSAP_004 Hierarchie-Versorgung Hier ist in INCLUDES das Füllen der Extrastruktur hinterlegt. ohne das weitere Einstellungen erfolgen müssen Delta möglich: nach Beschaffenheit der Daten kann eine Delta-Verfahren ermöglicht werden Kein Delta: DataSources dieser Quelle sind grundsätzlich nicht deltafähig Quellsystem . Neues Projekt anlegen. Stammdaten und Texten zur Verfügung.

Es ist daraus abzuleiten für welche Datenziele eine DataSource geeignet ist. Der Extraktor liefert additive Deltas. Technischer Name: ABR. Fortschreibung in ODS-Objekt und InfoCube möglich. wie fortzuschreiben ist und wie Serialisiert wird.DeltaQueue stellt eine Funktionalität des SAPI dar. da der gleiche Schlüssel mehrmals übertragen werden kann. Die Schlüsselfelder werden nur einmal geliefert. Direkte Fortschreibung in InfoCube ist nicht zugelassen. die direkt in die Delta-Queue fortgeschrieben werden die Daten werden paketweise serialisiert. da es sonst zu falsche Ergebnissen kommen würde. wie die Daten der DataSource ins Ziel übermittelt werden. Delta Queues zu generischen Datasources: Beim löschen geht das Delta-verfahren der DataSource unwiderruflich verloren. Fortschreibung in ODS-Objekt und InfoCube möglich. Technischer Name: ADD. Fortschreibungsmodus/Updatemodus im InfoPackage bestimmt welche Daten angefordert werden. gibt an auf welche Weise Daten übertragen werden. Nur das Addieren von Feldern ist erlaubt. Alle im InfoPackage angeforderten . Als Attribut der DataSource gibt es an. Es ist Addieren und Überschreiben erlaubt. Verschiedene Deltaverfahren für SAP-Quellsysteme: Bildung von Deltas mit: After-Image (liefert den Zustand nach der Änderung) Before-Image (den Zustand vor der Änderung mit negativem Vorzeichen) Reverse-Image (ebenfalls mit negativen Vorzeichen und kennzeichnet ihn als zu löschen Die Datenpakete werden dabei serialisiert. Full-Update (F): Steht in allen Datasources zur Verfügung. weil auch die Initialisierungsselektion zur DataSource gelöscht wird. (zentrales Interface im BW) Aufgaben der DeltaQueue Ablagebereich für neue und veränderte Datensätze im Quellsystem. Unabhängige Delta-Versorgung mehrerer SAP BW-Zielsysteme: Pro Zielsystem eine separate Deltaqueue. Die DeltaQueue besteht aus drei Tabellen Fortschreibungsmodus und Deltaverfahren Delta Verfahren: Eigenschaft des Extractors. Technischer Name: AIM/AIMD. Hier ist bei numerischen Kennzahlen nur Überschreiben nicht Addieren erlaubt. Zur Fortschreibung eines InfoCubes muss immer ein ODS-Objekt zwischengeschaltet sein. die requestweise serialisiert werden. Die DeltaQueue bei Bewegungsdaten und Stammdaten: Beide Datentypen verhalten sich im Bezug auf ihr Delta-verfahren gleich. Bildung von Deltas mit After-Image. Wiederholung der vorangegangenen Delta-Anforderung: Deltaqueue basiert auf QueueFunktionalität innerhalb der RFC-Technologie des SAP Web Application-Servers (qRFC). damit Delta-Datensätze zu dieser DataSource unabhängig voneinander angefordert werden können. die bei nächster DeltaAnforderung an das BW übertragen werden.

FI. Die Selektionen mehrerer Initialisierungen dürfen sich dabei nicht überschneiden. Die DeltaQueue ((3Tabellen) speichert Datensätze im R/3 und kann auf drei Arten geladen werden: Zeitpunkt der Transaktion Nach der Transaktion (V3) Beim Aufruf Extraktorjob durch BW Deltaverfahren ermitteln: In der Tabelle RODELTAM wird festgelegt welche Ausprägungen ein Deltaverfahren verwendet. ohne die Verbuchung der Daten im Quellsystem zu stoppen.historischen Daten werden weitergegeben Delta Initialisieren (C ): Die Initialisierung des Delta-verfahrens ist Voraussetzung für das Anfordern von Deltas. Extraktoren. Z.. die diese Methode unterstützen. Wiederholen (R ): Schlägt der Ladevorgang fehl. Es kann keine Init-Simmulation mit einem Early-Delta zusammen ausgeführt werden. Selektionsbedingungen werden gesichert und ein Full-Load wird gestartet. Der Extractor liefert das Delta der DataSource. der der Datenquelle zugeordnet ist. Serialisierung). Zum Beispiel erst für Kostenstelle 1000 und dann für Kostestelle 2000. werden frühestens mit Plug-In 2002. dass eine leerer Ablagebereich für neue oder geänderte Daten zu einer DataSource angelegt wird. SAPI liest die Selektionsfilter und ruft den Extractor auf.b. Delta Update (D): Die seit der letzten Initialisierung geänderten oder neuen Daten werden angefordert. . LIS. CO-PA. Aufgrund großer Datenvolumen kann die Initialisierng des Deltaverfahrens schrittweise erfolgen. Z.b. Ein Delta-Update ist nur für das Laden aus SAP-Quellsystemen möglich!!! Unterteilt sich zusätzlich in: Pushed Delta (D): Daten werden ohne Beteiligung von BW von der Anwendung in die DeltaOueue bereitgestellt. wird das Delta erneut angefordert.1 ausgeliefert. (Das Delta leifert die Anwendung) Early-Delta-Initialisierung: Dabei ist es möglich. LO. Wenn es heißt: Deltaqueue zur DataSource wird im Quellsystem erzeugt bedeutet das. bereits während der Initialisierungsanforderung im Quellsystem die Daten in die Delta-Queue der Anwendung zu schreiben. Es ist mehr als eine Initialisierung möglich und somit ist es möglich die Daten Schrittweise in das BW zu laden. Die Initialisierung des Delta-verfahrens (Init-Request. (Daten liefert der Extractor) Pulled Delta (E): Pulled Delta führt den Pull der Daten in die Queue durch das Extractorprogramm im Deltamodus aus. Die Tabelle RODELTAM definiert die Eigenschaften des Deltaverfahrens einer DataSource: (Delta-Typ. kann durchgeführt werden. Satztypen (Record-Mode).

Before. der Satz liefert ein After-Image. Für ODS erfordert er aber ein additives Fortschreiben. der Satz liefert ein additives Image. Die DataSource ermittelt das Delta mit ALE Fortschreibungszeigern. Vorzeichenumkehrung durchführen durch Extraktor (Default) oder durch SAPI. Der Satz muss gelöscht werden. Der Satz liefert eine New-Image. „D“. „X“. „D“. Dieser Satz und die DataSource kann nur in ODS fortgeschrieben werden. schreibt Delta-Datensätze direkt in die Deltaqueue (Push) zur DataSource. diesem Feld wird im InfoObjekt das Feld 0RECORDMODE zugeordnet): Satztyp = Record Mode befasst sich mit der Frage. „E“. Übertragen wird der Zustand nach einer Änderung oder nach dem Einfügen. gespeichert im Feld ROCANCEL. FI-AR/AP. Der Extraktor bestimmt Delta. „A“. Übertragen wird nur der Schlüssel. wenn es im Request das entesprechende Befor-Image gegeben gibt. In einer nicht additiven Fortschreibung eines ODS-Objektes werden diese Sätze ignoriert. auf welche Weise im Delta-Verfahren Änderungen an Daten aufgezeichnet werden. Der Satz liefert ein Reverse: Äquivalent zum Before-Image. Sieben Ausprägungen (Record Mode. „A“. Übertragen wird der Zustand vor einer Änderung oder vor dem Löschen. „F“. wie die Daten über die DataSource extrahiert oder in der Tabelle RSOLTPSOURCE (im BW).ist ergänzend zu After-Image. Die DataSource ermittelt das Delta auf Anforderung durch den Extraktor. LO.B. ` ´. „N“. Übertragen wird für summierbare Attribute nur die Veränderung und für nicht summierbare Attribute der Zustand nach der Änderung bzw. Delta-Typ ist nicht definiert. Der Satz liefert eine Before-Image. Alle summierbaren Attribute des Satzes (Kennzahlen) müssen mit umgekehrten Vorzeichen übertragen werden. Diese Methode wird vor allen Dingen im Zusammenhang mit DataSources für Attribute und Texte aus SAP-Quellsystemen verwendet. Deltatyp: ` ´ . Nur die Differenz für alle numerischen Werte anzeigen. Ohne DeltaQueue. Deltatyp nur für Flat File. Art und Weise der Delta-Bereitstellung. Im InfoCube kann er uneingeschränkt fortgeschrieben werden. Er darf nur dann direkt in einen InfoCube fortgeschrieben werden. . Der Extraktor muss auf Anforderung die Delta-Sätze der DataSource liefern PULL. Unterscheidet sich aber in der Fortschreibung eines ODS: Ein vorhandener Satz mit gleichem Schlüssel wird gelöscht.In der Tabelle ROOSOURCE (im SAP Quellsystem) kann überprüft werden. Anwendung bestimmt Delta z. nach dem Anlegen. „R“.

Stammdatenattribute. New. wenn eine Satz angelegt wird. Zwei Möglichkeiten für Hierarchien : . Für jede Änderung wird eine neuer. Diese Frage wird auf technisch unterschiedliche Weise im Extraktor einer DataSource oder in der Anwendung selbst gelöst und hängt vom Umfeld und dem Datenmodell der Anwendung ab.Äquivalent zum After-Image ohne Before-Image. Ein New-Image sollte anstelle eines After-Iamge übertragen werden. das Daten hinzugefügt werden können. sind Beforeund After-Image nötig.und Fortschreibungsregeln. eine Stammdaten-ODS-Objekt als Zwischenstufe vor dem InfoObjekt. Hier ist es möglich. Handelt es sich um eine Additives Image. muss diese zunächst in eine ODS fortgeschrieben werden. Wenn bei ODS die Einstellung zum überschreiben gewählt wurde. kann diese Kombination in einen beliebigen InfoCube oder ein beliebiges ODS-Objekt geladen werden. eindeutiger Satz erzeugt. zu verwenden. Bei ODS muss die Fortschreibungsart für Kennzahlen allerdings auf Addieren eingestellt werden und nicht auf Überschreiben. Delete-Images können nur von ODS verarbeitet werden. InfoCube können keine Löschungen verarbeiten. Folgende Abhängigkeiten sind bei deltafähigen Datasources zu beachten: Wenn die DataSource eine Before. aber nicht erforderlich. Reverse-Image können von allen Zielen verarbeitet werden. Direktes Staging mit Übertragungsregeln: Verwendet nur Übertragungsregeln. Zwei Möglichkeiten für das Laden von Stammdatenattributen und Texten: Flexibles Staging: Unter Verwendung einer flexiblen DataSource mit Übertragungs. gelangt nur das After-Image (das Letzte) in die AktivierungsQueue Tabelle des ODS. Hierarchien und Bewegungsdaten) ins BW. Wichtig: Ein Delta-Verfahren sagt grundsätzlich nichts darüber aus. Grundsätzlich ist in InfoCubes nur eine additive Fortschreibung möglich. können die Daten in eine ODS oder InfoCube geschrieben werden. Zusätzliche Hinweise Unterstützt eine DataSource kein Delta-Verfahren (Selektion im Full Update) ist eine SnapshotSzenario möglich. Ist ODS so eingestellt.und ein After-Image sendet. wie das Delta in der Anwendung ermittelt wurde. Kapitel 4 Übertragen von Daten aus Flat Files Flache Dateien ermöglichen das Laden aller Arten von Daten (Text. Sendet die DataSource nur das After-Image. das sich im Modus überschreiben befindet. keine Fortschreibungsregeln.ist ergänzend zum Reverse-Image.

Datenübertragung ohne Transformation. Zum Test der Übertragung.und Fortschreibungsregeln kann auch ein Simulation durchgeführt werden.Direktes Staging nur mit Übertragungsregeln. Für Hierarchien und Texte gelten feste Formatanforderung für die Datei. Damit kann dann in der Transaktion FILE der physische Datenpfad und Name hinterlegt werden. Dort könne auch Variablen zur Bestimmung des physischen Dateinamens oder Pfades verwendet werden. Gewährleistung dafür. Hinweis: Falls die Datei über eine Batchverarbeitung geladen werden soll ist die Dateiablage auf dem Anwendungsserver zwingend notwendig. Es können Kopfzeilen ignoriert werden. Es kann ein logischer Dateiname eingegeben werden. (Ladevorgänge extrem flexibel) Funktionen zur Unterstützung von Datei-Ladevorgängen: Ausschließen bestimmter Kopfzeilen Auswahloptionen zum Filtern der Datei beim Laden Mehrere Datasources aus dem gleichen Quellsystem Routine für die Benennung der physischen Datei Umfangreiche Vorschaufunktion Simulation der Ladevorgänge Ein Datei-Quellsystem wird in der AWB unter Quellsystem angelegt. (angelegt im Register Quellsystem der AWB) Der tatsächliche Ort der physischen Datei Dateien wird im InfoPackage festgelegt und kann auf dem Anwendungsserver oder im LAN/WAN liegen. Da es beim Upload von Flat Files kein direktes Mapping über die Transferstruktur gibt. dass die Datei zum Ladezeitpunkt auch tatsächlich vorhanden ist. ohne das die Dateien mit einem InfoPackage geladen werden müssen und es können Filter eingesetzt werde. Voraussetzung für das Laden von Flat Files dient eine File-System in der Quellsystem Umgebung des BW-Systems. d. Drei Möglichkeiten des Delta-Managements bei flachen Dateien: Delta mit Status Neu: Sendet das After-Image o. Schutz vor doppeltem Laden. während bei Stammdatenattributen die Reihenfolge beliebig ist. lediglich die Transferstruktur im BW muss dem Layout der Datei entsprechen. New-Image eines Satzes. Bewegungsdaten: verwenden den Ladevorgang der flexiblen InfoSource (Flexibles Staging) ebenfalls mit Option für ein zwischengeschaltetes ODS besitzen kein festes Format.h. Die Schlüssel müssen sich am Anfang des Dateilayouts befinden. Eine Vorschau ist möglich. Das Datenformat muss dem gewünschten Ergebnis entsprechen. Wenn das Altsystem nur . Dateien mit gleichen Namen).b. Beim Laden von flachen Dateien können ABAP-Routinen angelegt werden. Direktes Staging ohne Übertragungsregeln. Die ist keine BW spezifische Transaktion. ist die Feldreihenfolge in der Transferstruktur zwingend einzuhalten. die das Laden steuern und überwachen (z.

muss die Überschreibfunktion des ODS Verwendet werden. Nachdem die Daten in das Change Log des ODS fortgeschrieben wurden (durch Aktivieren der ODSDaten). sondern nur die Daten die sich geändert haben könnten. können die Daten anderen BasisCubes oder ODS mit den additiven Daten. der das Vorzeichen umkehren würde. kann der Prozess automatisiert werden. führt zu leerem Delatverfahren: wenn Deltaverfahren leer ist. Um die Daten mittels DB Connect aus einem von SAP unterstützten Datenbank-Management- . müssen die Metadaten vorher in Form einer DataSource vorliegen. Bei Standardverbindungen sind DB-Client und Data Base Shared Library (DBSL) bereits installiert. Die Prozesse. Man generiert eine DataSource für Datenbankquellsysteme mit dem Kontextmenü des Datenbankquellsystems. Deltaverfahren = FILO). Deltaverfahren = FIL1. steht der normale Delta-Ladevorgang nicht zur Verfügung. nur ODS. Kapitel 5 Datenübertragung mit DB Connect DB-Connect bietet flexible Optionen für die Datenextraktion ins BW aus Tabellen und Views in Datenbankmanagement-Systemen. DB-Connect bietet die Möglichkeit neben der normalen SAP-Standard-Verbindung weitere Datenbankverbindungen herzustellen. Welches Delta-Verfahren verwendet werden soll. Pseudo Delta (Löschen und Hinzufügen): Das Ziel besteht darin. Pseudo Delta einsetzen. zur Verfügung gestellt werden. sind zeitintensiv und fehleranfällig. Additives Delta (BsisCUbes und ODS ok). d. Der technische Name mit beginnt mit 6DB. die für ein Pseudo Delta notwendig sind.den aktuellen Status einer Änderung kennt. Das Filesystem verarbeitet nicht den Record Mode. Hier wird das technische Delta-Verfahren bestimmt: Full Load durchführen. Das Before-Image muss bereits umgekehrte Kennzeichen aufweisen. die das jeweilige Ziele verarbeiten kann. den gesamten BasisCube oder das gesamte ODS nicht ständig löschen und erneut laden zu müssen. nicht verwendbar. die an Standardverbindungen angeschlossen sind. Bei anderen müssen sie erst installiert werden Grundregel für die Nutzung DB Connect: Die Fremddatenbank benötigt DBSL. wird in Form des Fortschreibungsmosdus auf dem Register Transferstruktur bestimmt. Um Genauigkeit und Konsistenz zu gewährleisten. die normalen Deltavorgänge stehen nicht zur Verfügung. Delta mit Staus Neu: für geänderte Sätz (After-Tmage. führt das zu einem leeren Deltaverfahren. Es kann hier auch mit einem PseudoDelta gearbeitet werden. daher ist der Record Mode „X“. Wenn eine Full Load durchgeführt wird. Eine DataSource wird aus der Tabelle oder dem View generiert. wenn es sich um eine MySAPQuelle handelt. Additives Delta: Das BW erwartet entweder einen Satz mit dem Unterscheid oder zwei Sätze: einen mit After-Image und einen mit Before-Image.h. Um Daten von einem Datenbanksystem übertragen zu können.

Diese DataSources erfüllen die Aufgabe die Metadaten dem BW bekannt zu machen.System laden zu können müssen: die fremde Datenbank als Quellsystem an das SAP BW-System angebunden und somit eine direkter Zugang zur externen relationalen DBMS (RDBM) geschaffen werden. Z. DB2 usw. . DB Connect Daten und Metadatenbereitstellung Bevor Daten aus dem externen DBMS geladen werden können. Die Metadaten der Tabelle oder Views des externen RDBMS durch Definition einer DataSource dem BW bekannt gemacht werden. Wenn nicht. Wenn diese Transaktion auf eine Verbindung zugreift. die aufgerufene Transaktion wird gestartet. wenn alle DB-Verbindungen des Typs Permanent wiederhergestellt sind. Mit Hilfe von DB-Tabellen bzw.und Feldinformationen im BW in Form einer DataSource vorhanden sein. DB-Wiederverwendungstyp ist permanent (DBCON_RECO=X): Nach dem ersten Verbindungsfehler wird geprüft.h. DB Connect beinhaltet somit auch das Mapping von Datenbank-Datentypen auf ABAP-Datentypen.-Info: Datenbank-Namen. Danach kann der Bereitstellungsprozess der Daten erfolgen.bzw.b.und Native-SQL-Statements). ob eine Neuverbindung vor jeder Transaktion möglich ist. Datenbank-Host usw. bei Ausfall der Netzwerkverbindung. Identifizierung und Verbindung zum DBMS: DB-Verbindung DBMS auswählen: ( ADA. ob die aktuelle Transaktion auf diese spezielle Verbindung zugreifen würde oder nicht. Permanent: wird benötigt. ? Open-SQL = Datenbankabfragesprache. (Nutzen Open. Das SAP-System funktioniert nur in vollem Umfang. wenn die Verbindung ausfällt. Um aus anderen DBMS über DB-Connect Daten in das BW laden zu können. wird die Transaktion nicht gestartet. müssen zuvor die Metadaten. Dies gilt unabhängig davon. Unabhängig davon versucht der SAP Workflow. die nicht besteht. –Views aus dem Datenbankkatalog des DBMS können DataSources generiert werden. die unterbrochene Verbindung wiederherzustellen. d. die sich am SQL-Standard orientiert aber Erweiterungen enthält.) Benutzername (DB-User unter dessen Namen wird die Verbindung geöffnet) DB-Passwort Verb. View. die Tabellen. Nutzen der Funktionalität von DB Connect – Vorbereitungen: Bei Standardverbindungen sind DB-Client und Data Base Shared Library (DBSL) bereits installiert. kommt es zu einem Transaktionsabbruch. müssen sowohl der datenbankspezifische DB Client (beim Hersteller Lizenz erwerben) als auch die SAP-spezifische DBSL (Data Base Share Library) für jeden BW-Server installiert sein. Schlägt dieser Versuch fehl verhält sich das System wie folgt DB-Wiederverwendungstyp ist nicht permanent (DBCON_RECO=BlANK): Fehler wird ignoriert.

. Anzahl der simultanen Verbindungen fest. Verbindungslimit: Legt die max. Die DB Connect-DataSource unterstützt kein Deltaverfahren (weil keine Unterstützung von SAPI. Name der Tabelle bzw. Views zusammensetzt. Namenskonventionen für Tabelle und Views: entsprechen im allgemeinen den ABAP-Dictonary Namenskonventionen es können nur Tabellen und Views zur Extraktion verwendet werden. Namen der Tabelle bzw. Zeitstempel) oder über ODS erfolgen. so sorgt der Workprozess nach Beendigung der Transaktion selbstständig dafür das die darüber hinausgehenden Verbindungen wieder aufgebaut werden. Kapitel 6 Universal Data Integration UDI-Technologie ist auf Kundenwunsch entstanden. Der techn. Beispiel: 6DB_ (4Zeichen). Namenskonventionen für Felder: es können nur Felder zur Extraktion verwendet werden deren technische Namen nur aus Großbuchstaben. deren technische Namen nur Großbuchstaben. Durch die Besonderheiten der UDI –Technologie wird der Zugriff (ohne den Einsatz von ETL-Tools) auf multidimensionale und relationale DBMS ermöglicht. also nur 26 für Zeichen. Name sich aus dem Präfix 6DB_ und dem techn. Wird diese Anzahl überschritten. Tabellen/Views mit längeren nahmen stehen somit zur Extraktion nicht zur Verfügung. Die techn.b. Darüber hinausgehende Verbindungen werden abgelehnt. Belegnummer o. Der techn.Hinweis: Das Kennzeichen „ist permanent“ sollte dann gesetzt werden. Name der DataSource im BW ist auf 30 Zeichen begrenzt. Ziffern und dem Zeichen _ (Unterstrich bestehen). des Views darf demnach nicht länger als 26 Zeichen sein. deren techn. Verbindungsoptimum: Legt die Anzahl der optimalen Verbindungen fest. Verbessert enorm die Integrationsmöglichkeiten von BW in bestehende heterogene Systemlandschaften. Feldnamen dürfen nicht länger als 26 Zeichen sein. Ziffern und dem Zeichen _ (Unterstrich) bestehen. der technische Name der DataSource ist max 30 Zeichen. Felder mit reservierten Feldnamen dürfe nicht verwendet werde. DB Connect unterstützt nur die Transfermethode PSA. wenn die geöffnete DBVerbindung unverzichtbar ist oder sehr häufig benötigt wird. Aus einer Tabelle oder View wird eine DataSource generiert. Verwendung weiterer Zeichen kann zu Problemen führen. DeltaQueue existiert) Eine Pseudo Delta-Fortschreibung kann über eine Selektion (z.

die mit Java SDK ((Software Development Kit) erstellt worden sind. BI. Der JDBC-Connector ermöglicht den JDBC-Treibern: Eine einheitliche Verbindungsverwaltung. der ein Framework für die Darstellung von Metadaten in Data Warehouse. Teradata. SQL usw. Knowledge Management und Portalen zur Verfügung stellt. mit mehr als 200 JDBCTreibern verbinden. UD-Connect besteht aus zwei wesentlichen Komponenten: Java-Komponente auf dem J2EE-Server ABAP-Komponente im SAP BW Mit dem JDBC-Connector (Java Database Connectivity. JMI: die Java MetaData Interface-Spezifikation der (Object Management Group) OMG definiert eine plattformunabhängige Infrastruktur. ist ein Standard OMG (Objekt Management Group). Dieser Connector ermöglicht es Anwendungen die mit Java SDK erstellt wurden mit ODBO –fähigen Datenquellen zu verbinden. BI ODBO Connector ODBO OLE DB for OLAP von Microsoft hat sich als Industriestandard OLAP-API für die Windows-Plattform entwickelt. Einen einheitlichen Metadaten-Service durch Implementierung von JMI-Funktionen. die Erkennung sowie den Austausch von Metadaten und den Zugriff auf Metadaten ermöglicht. Es werden persistente (Staging) und transiente (OLAP) (direkter Zugriff über RemoteCube) Datenbereitstellung unterstützt.Grundlage: bilden die sog. JMI ist ein erweiterter Metadaten-Service für die Java-Plattform. von Sun) können sie Anwendungen. die auf den CWM basieren: CWM: Das Common Warehouse Model. die die Erstellung. BI Java Connectors auf dem J2EE-Server des (SAP WAS) SAP Web Application Server: BI Java Database Connectivity (JDBC) Connector – (Sun) BI OLE DB for Olap (ODBO) Connector – (Microsoft OLE-DB for OLAP) BI XML for Analysis (XMLA) Connector – Microsoft XML for Analysis) BI SAP Query Connector – (SAP Query) Realisiert die Java-basierte Implementierung des BW. Oracle. BI XMLA Connector . die in die Benutzerverwaltung im SAP Enterprise Portal. die Speicherung.

Funktionsbausteine im BW aufrufen oder von den Funktionsbausteinen aufgerufen werden. UD Connect Mit SAP BW 3. Jeder BI Java Connector kann „n“ Instanzen ansprechen. Konfiguration: im J2EE-Engine Administrator: Im ersten Schritt stellen Sie die Verbindung zwischen den BI Java Connector und den Datenquellen her. dass die SAP WAS J2EE-Engine mit den Java Komponenten installiert ist. sowie die Verbindung zwischen der SAP J2EE-Engine und dem SAP BW. Siehe. Hinweis: Voraussetzung dafür ist.XMLA von Microsoft erleichtert einen Web-service-basierten. Der BI XMLA Connector ermöglicht den Austausch von analytischen Daten zwischen einer Client-Anwendung und einem Daten-Provider über das Internet unter Verwendung eines SOAPbasierten XML-Kommunikations-API. besteht mit UD Connect (Universal Data Connect) eine weitere Möglichkeit.g. plattformunabhängigen Zugriff auf OLAP-Provider. können auf Daten aus operativen SAP-Anwendungen zu greifen. BI SAP Query Connector SAP-Query ist eine Komponente des SAP WAS. die Verbindung zwischen der J2EE-Engine und der Datenquelle (nahezu alle Systeme) herzustellen. Session Beans. Dabei ist im SAP BW eine persistente (Stagingbereich) und eine transiente (OLAP über RemoteCube) Datenbereitstellung im BW möglich. Daten aus SAP-Systemen und Fremdsystemen für die Analyse im BW zu nutzen. Anwendungen.5. Der Connector bekommt einen . 125 Auf Basis einer RFC-Verbindung zwischen dem SAP BW und der J2EE Engine können s. 1. die mit BI Java SDK erstellt worden sind. UD-Connect-Architectur: Hat zwei wesentliche Komponenten: Java Komponente auf dem J2EE-Server des SAP WAS (Interface) ABAP-Komponente im SAP BW (Interface) Die Java-Komponente ist für die Kommunikation zwischen Datenquellen und SAP BW zuständig. UD Connect – Konfiguration Die für die Nutzung von UD-Connect notwendigen Konfigurationen auf der SAP WAS J2EE Engine und im SAP BW dienen dazu. Abb. mit der wir ohnen ABAP-kenntnisse benutzerspezifische Berichte erstellen können. Und die Verbindung zwischen der J2EE-Engine und dem SAP BW herzustellen.

UD Connect Quelle: Darüber werden Instanzen bezeichnet. System number. müssen Sie die Metadaten der zu extrahierenden Daten dem SAP BW über DataSources mitteilen. Für den Namen des Connectors ist „SDK _“ als Präfix zu vergeben. Einstellungen Registriertes Serverprogramm ProgramID: Programm ID Hinweis: Die hier eingegebene Programm ID muss der Programm ID entsprechen. Number of Prozesse. Unter Repository: Application server host. Gateway-Host. GatewayHost. Password 2. Gateway-services Sichern und testen. Definition einer UD-Connect DataSource: Bevor Sie Daten aus UD Connect-Quellen ins BW übertragen können. Gateway-services. die über BI Java Connectors als Datenquelle angesprochen werden können. Konfiguration im SAP-BW: Einrichten der RFC-Destination zur SAP J2EE Engine Transaktion SM59 Name und Beschreibung für die Destination eingeben Verbindungstyp: „T“ für TCP/IP Register techn. . Client. Einrichten der RFC-Destination zum SAP BW: Unter RFC Destination: Programm ID. Username. die Sie bei der Pflege der J“EE Engine eingeben. Sie können nun im SAP BW zu einer InfoSource eine UD-Connect DataSource für die transiente/persistente Datenbereitstellung definieren. Language.sogenannten JNDI-Namen (Java Naming Directory Interface). damit der Java Connector von UD Connect erkannt wird. unter dem alle wesentlichen Eigenschaften zusammengefasst werden.

Der Service ist zu finden unter /sap/bc/soap/rfc. Merkmale und Kennzahlen von Cubes bezeichnet. Ablauf: Aufrufen des SOAP RFC-Service zum Übertragen der Daten in die Delta Queue im SAP BW mittels Push. .) Quellobjekt Element: Sind die Komponenten der UD-Connect Quellobjekte. HTTP + XML = SOAP!! Der SOAP-Service überprüft die XML-Daten auf ordnungsgemäße Syntax und konvertiert sie in ABAP-Felder. Die Pflegeeinstellung für diesen Service in der Transaktion SICF (System Internet Communication Framework) anzeigen. Laden der Daten aus Delta Queue in BW InfoProvider. Die Datenübertragung im BW findet im BW über ein Push in die DeltaQueue der generierten DataSource statt. Damit können für das SOAP-Protokoll ausreichende XML-Daten an RFC-fähige Funktionsbausteine in die ABAP-Umgebung übertragen werden. UD Connect Quellobjekt Das sind die relationalen und multidimensionalen Datenablagen ( Tabellen. Kapitel 7 XML/SOAP-basierte Datenübertragung Verwendung des Web AS SOAP-Service Im BW wird der mit dem SAP Web Application Server bereitgestellte SOAP-Service verwendet. Cubes usw. XML-fähige (multi-dimensionale) Datenquellen und SAP Anwendungen in Frage.Als Datenquelle kommen relationale Datenquellen. Hier ist der entsprechende http-Port zum Aufrufen des Web AS SOAP-Service aufgeführt. Die Anwendungslogik (Schreibvorgänge in die Delta Queue) wird als ABAP-RFCFunktionsbaustein statt. Senden die im XML-Format zu ladenden Daten über den unter /sap/bc/soap/rfc angegebenen HTTPPort an den SOAP-Service des SAP Web Application Servers. Felder von Tabellen. OLAP-fähige (multi-dimensionale) Datenquellen.

Auf Basis von Funktionsbausteinen für XML-fähige DataSources. Discovery (UDDI) eXtensibel Markup Language (XML) SOAP Im SAP Web Application Server ist der Web Service Creation Wizard enthalten. XI ist dabei offen und flexibel . sicher. Im SAP Web Application Server sind die grundlegenden Webservice-Standards implementiert.B. XML Data Load – Verwendung von SAP XI XI steht für eXchange Infrastructure und stellt ein zentrales System für die zentrale Datenverteilung dar. Beispiele: Intelligente Produktkatalogsuche.XML Data Load – Verwendung eines Web Service Selbstständige Anwendungsfunktionen. . Rechnungen usw. die verarbeitet werden durch offene Internet Standards. es genügt eine einfache Konfiguration ohne zusätzlichen Codierungsaufwand. können hier Web Services für das Laden von Daten generiert werden. Es können heterogene Systeme mit weniger Verbindungen und zur gleichen Zeit kombiniert werden. Funktionsbausteine etc auf einfache Weise (Wizard gestützt) in einen Web Service verwandeln. z. Das SAP XI stellt die Standardisierung. Architektur unter der Verwendung von SAP XI SAP XI wird für den Datenaustausch (Bestellungen. BAPIs.) zwischen Lieferanten und den SAP SRM-Systemen über Unternehmensgrenzen hinweg verwendet. das SAP BW. Kundenbonitätsabfragen aber auch Automatische Websuche (Google) Web Services nutzen offnen Standards. iDOC . Die Daten stammen dabei aus einer Reihe von SAP und Nicht-SAP Systemen. Man kann so Java Klassen. Web Service Discription Language (WSDL) Universal Discription. Produktverfügbarkeitssuche Preisanfragen. Web Services sind innerhalb SAP BWs einfach zu erstellen. Bereinigung und Verteilung der Daten an die Zielsysteme.

EOIO (Exactly Once in Order): Über die Exactly Once-Methode hinaus werden Nachrichten mit demselben Queue-Namen (von der Anwendung bereitgestellt) in der Reihenfolge bearbeitet. in der sie vom Sendersystem gesendet wurden. Die Nachrichtenverarbeitung erfolgt in diesem Fall asynchron (Proxy Kommunikation). dass die Nachricht genau einmal gesendet und verarbeitet wird (RFC-Adapter). Begründung für die Verwendung der SAP XI/BW-Verbindung in einem Beispiel: Da die Daten zu Analysezwecken auch über SAP XI an das BW weitergeleitet werden. Methode für SAP-BW!! System Landscape Directory (SLD) Ermöglicht die Beschreibung von Produkten. Bewegungs. Übereinstimmung mit der SAP NetWeaver-Architekturvorgabe.Die ausgetauschten Daten werden in XI kopiert und mittels Push an das BW übermittelt. zukünftiges Wachstum von SAPAngeboten und der NetWeaver Plattform wird vollständig ermöglicht. Nachdem die Nachricht auf dem Zielsystem verarbeitet wurde. dies bedeutet. SAP Exchange Infrastructure greift beim Entwurf. Softwarekomponenten. Die Konsistenz und die Details werden während der Verteilung der Daten von system zu system vollständig aufrechte erhalten. ist die Extraktion der Daten von den mySAP SRM-Quellsystemen in das BW nicht erforderlich. Verbinden von SAP XI und SAP BW Für die Art der Verbindung ist insbesondere die über die verschiedenen Techniken erreichte Qualität of Services von Bedeutung: Verbindungen für den Nachrichtenfluss: BE (Best Effort): Die Nachricht wird synchron gesendet. Hinweis: wenn die Filialen die Daten als flache Dateien übertragen.und Stammdaten von SAP ERP können direkt in das BW geladen werden (optional) Lieferantendaten und Produkttypen werden in SAP MDM konsolidiert und können im BW um Informationen von Dun & Bradstreet erweitert werden. Die Vorteile von SAP XI werden in jedem Fall für die Verbindung des mySAP SRM mit den Lieferanten genutzt. welche Interfaces benötigt . logischen Systemen und technischen Systemen. Die Nachricht wird von der Integration Engine nicht aufbewahrt. EO (Exactly Once): Die Nachricht wird asynchron gesendet. wartet vor der Weiterverarbeitung nicht auf Antwort. das Sendersystem wartet vor der Weiterverarbeitung auf Antwort. Die Integration Engine gewährleistet. können diese einfach über XI in ein XML-Format umgewandelt werden. Dies bedeutet. erfolgt ein impliziter Datenbank-Commit (SOAP-Komminikation). bei der Konfiguration und zur Laufzeit auf diese Informationen zu Integration Builder Entwurf Erlaubt während der Entwurfsphase einer SLD die Dokumentation des gesamten unternehmensübergreifenden Vorgangs und legt darüber hinaus fest. keine Punktzu-Punkt-verbindung mit dem EBP.

Integration Server (Monitorring): Laufzeit Zentrale Verteilungsengine für Nachrichten in der SAP Exchange Infrastructure zur Laufzeit. Integration repository: Das Ziel des XI Integration repository besteht in der Konfiguration der Sender-EmpfängerBeziehung. Enthält die Interfaces der verwendeten Systeme. Die Interfaces können importiert oder manuell angelegt werden. Man unterscheidet dabei folgende Ansätze: Implementierung von außen nach innen. um die Mappingregeln für das Struktur.Directory entscheidet der IntegrationsServer. Beispielsweise definieren Sie Bedingungen für den Nachrichtenfluss und wählen gemäß Ihren Anforderungen Designobjekte aus. Funktionen sind bereits vorhanden und werden (Proxy) Eingebunden. die zur Laufzeit verwendet werden.und Werte-mapping zu sichern. (Adapter) Implemenetierung von innen nach außen. Mapping-Konzepte In XI stehen verscheiden Mapping-Methoden zur Verfügung: nachrichten-mapping XSLT (eXtensible Stylesheet Language) Java ABAP . Alle systeme. Mit den Konfigurationsdaten aus dem Integrations. systemunabhängige Interfaces werden definiert aber zu einen späteren Zeitpunkt implementiert. verwenden zum Austauschen von Nachrichten diesen Server. die über SAP Exchange Infrastructure kommunizieren. Integration Builder Konfiguration In der Konfigurierungsphase konfigurieren Sie den unternehmensübergreifenden Vorgang für eine bestimmte Systemlandschaft. an welche Empfänger die Nachricht gesendet werden soll und ob zuvor ein Mapping ausgeführt werden muss.werden. Es steht ein grafisches Mapping Werkzeug zur Verfügung.

Damit könnte z. stellt das BW offene Schnittstellen.b. Es wird ein Proxy in ABAP oder Java generiert: Verbinden neue SAP-Anwendungen mit XI Systemeigene Anbindung ans das ABAP-System ohne Adapter Interface mit Integration repository zentral entwickelt Entwicklungsmethode von außen nach innen Datenübertragung mit Third Party – ETL-Tools Werkzeuge von Drittanbietern. Kapitel 9 Datenübertragung über das Data Mart Interface Data Marts sind bereichspezifische Lösungen innerhalb eines Unternehmens. In der Regel bieten ETL-Tools folgende Funktionalitäten (Push): Anbindung unterschiedlicher Plattformen Bereitstellung von Transformationen Design von ETL-Prozessen Ausführung von ETL-Prozessen Administration von ETL-Prozessen Anbindung an das SAP BW ETL-Tools werden von BW als Quellsystem erkannt. Dies sind Adapter: Verbindung vorhandener (alter) Systeme Bestimmtes Kabelgebundenes Protokoll Interface-Semantik externen definiert Entwicklungsmethode von innen nach außen Im Fall von neuen SAP Anwendungen (ABAP oder Java) hat sich der Vorgang der Interfaceentwicklung geändert. das über RFC und iDOC kommuniziert nicht geändert werden.B. Um die Extraktion von daten und Metadaten aus Fremdsystemen zu ermöglichen. Vorteile schnelle Implementierung mit überschaubarem Datenvolumen.Unterschied zwischen Proxy und Adapter (RFC) bei der Verwendung der XI Technologie: Normalerweise kann die Interface-Semantik für eine System. um sie als Entwicklungsstufe für einen langfristig unternehmensweiten Ansatz zu verwenden. . z. die Staging BAPIs (Business Applicatiom Programming Interface) zur Verfügung. die von SAP zertifiziert sind. einen firmenbasierte DWH Lösung Schritt für Schritt realisiert werden.

Daten werden von einem Datenziel an eine oder mehrere Datenziele innerhalb eines BW-Systems fortgeschrieben. . Das zentral SAP BW versorgt sich selbst mit daten (BasisCube zu BasisCube) und übergibt auch replizierte daten an das regionale SAP BW. Hinweis: Der Quellsystemtyp MySelf-System wird automatisch im Hintergrund nach der Installation oder dem Upgrade während des ersten Starts der AWB erzeugt. Aggregierende Architektur: Daten werden von einem oder mehreren BW-Systemen in eine zentrales BW-System fortgeschrieben. Daten von einem BW-System in eine anders BW-System oder das gleiche BW-System laden.g. Replizierende Architektur: Ein BW-Server liefert die Daten für andere BW-Server. Der Delta Modus steht nur zur Verfügung. Als Datenquellen können alle SAP-BW-Datenziel dienen: BasisCubes ODS-Objekte Merkmal-InfoObjekt (Attribute/Texte) Mittels Open Hub Service werden die Daten aus den o. Die Daten können im Full. wenn Sie als Datenquelle einen BasisCube oder ein ODS verwenden. Datenzielen extrahiert und entweder in einer DB-Tabelle oder einer Flat File geschrieben.Das Data Mart Interface ist Bestandteil der Service-API und ermöglicht somit die Fortschreibung aus einem Datenziel in eine weiteres. MySelf System Data Mart Architecture: Wird zum Umverteilen von Daten im BW verwendet. wobei das Delta über die Request-ID ermittelt wird. Für BasisCubes und ODS ist die Export DataSource deltafähig. Gemischte Architektur: Zwei BW-Systeme in den Niederlassungen 1 und 2 dienen als Data Mart. bei Flat File wird nur das CSV-Format unterstützt. Kapitel 10 Datenbereitstellung über Open Hub Service Open Hub Service bietet als Bestandteil des SAP BW den Rahmen für die geplante und überwachte Extraktion von konsolidierten und integrierten Daten aus dem BW und das Weiterleiten an externe Systeme.und Delta Modus extrahiert werden. Sie übertragen ausgewählte Daten an eine zentrales SAP BW.

Flatfile) Extraktionsparameter (Extraktionsmodus.. Paketierung) Selektionsoptionen für die zu extrahierenden Daten Optional BAdI für Transformationslogik Anlegen eines InfoSpoke Allgemeines Typ der Datenquelle (Cube. mit denen direkt auf Datenbanktabellen von anderen Anbietern zugegriffen werden kann.b DB2. Oracle. Die Delta-Funktion liefert der Zieldatei oder Zieltabelle nur die neuen oder geänderten Bewegungen. SQL usw. um die Systemressourcen nicht zu überlasten. (Werden auch von SAP bei DB-Connect verwendet) Vom Open Hub Service angelegte CSV-Dateien können auf den BW-Server oder in eine Datei gelegt werden. alle nicht unmittelbar. Für das Extrahieren von Daten aus dem BW stehen folgende Möglichkeiten zur Verfügung: daten aus Open Hub-generierten Tabellen oder Dateien extrahieren und an BW-basierten Delta Mart weiterleiten. DB-Tabelle.Der Extraktionsprozess kann über Prozessketten automatisiert und eingeplant werden. Z.. Standard DBMS bietet Werkzeuge. SDTM) Technischer Name der Destination Extraktionsparameter Extraktionsmodus Zeilen pro Datenpaket Destination Beschreibung Logisches Zielsystem Destinationstyp DB-Tabelle Löschen der Tabellen vor Extraktion . Mit der Verwendung von SAPI steht ein direkter Weg zur Verfügung. Die Extraktion erfolgt asynchron. ODS. Überblick Leistungsmerkmale Open Hub Service Unterstützung aller SAP BW Datenziele (keine Hierarchien) Extraktionsmodus Full und Delta Verteilungsziele DB-Tabelle und Flatfile (nur CSV) Transformation während der Extraktion (BAdI) Einbindung in Prozessketten Überwachung (Monitor und Protokoll) Technischer Aufbau eines Open Hub Services InfoSpoke – Das zentrale Objekt des Open Hub Service Die Definition eines InfoSpoke beinhaltet: Open Hub Datenquelle Open Hub Destination (Zielsystem.

Transformation InfoSpoke mit Transformation via Badi (Kennzeichen Ja/Nein) Eigenschaften Quellstruktur Zielstruktur BadI-Implementierung Open Hub Monitor Wird eine Datenextraktion über einen InfoSpoke durchgeführt. Verzeichnis und Trennzeichen InfoObjects Auswahl der InfoObjects die übertragen werden sollen.Technischer Schlüssel (Kennzeichen gesetztHinzufügen und ausschließliches verwenden der Schlüsselfelder OHREQID. Aktivieren und Deaktivieren von Delta) angezeigt werden. Darüber hinaus kann bei deltafähigen InfoSpokes die Delta-Verwaltung (Zeigt gelesene und nicht gelesene Requests. Schlüsselfelder (Nur bei Typ DB-Tabelle) BasisCube Dimensionsmerkmale ODS Schlüsselfelder SDTM Schlüssel der Stammdatentabellen Selektion Selektion über ausgewählte InfoObjects. PAGE PAGE 27 .mit Status – angezeigt. nachfolgendes ETL-Tool) DateiServer. Dieser wird im Monitor . Open Hub Destination und InfoSpoke. zu einem der Requests angezeigt werden. Der Open Hub Monitor gliedert sich in 2 Bereiche: Im ersten Bereich gruppiert der Open Hub Monitor die Requests nach logischen Zielsystem. so wird ein Open Hub Request erzeugt. Im zweiten Bereich können Detailinformationen. DATAPAKID und RECORD) Benachrichtigung an 3Anbieterwerkzeug (z.B. Name. Details hinsichtlich Laufzeitfehler und Job-Protokoll sind ebenfalls verfügbar. Einschränkung auf Einzelwerte oder Intervalle.