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 Merkmal-
InfoObjekt) 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:
Bei einem Merkmal-Info-Objekt haben Sie die Möglichkeit, eine Übertagungsroutine anzulegen.
Diese gilt global quellsystemübergreifend für das Merkmal-Info-Objekt und wird in allen
Übertragungsregeln mit eingebunden. Sie muss nur einmal gepflegt werden.

Definition Übertragungsregeln

Wählen zwischen den Transfermethoden:

PSA (zu empfehlen) (dafür sorgen, dass sowohl die PSA-Tabellen, falls diese genutzt werden, als auch
die Speicher im ALE Ein- und Ausgang für die Info iDOCS zu administrieren sind).

iDOC (dafür sorgen, dass die Datenspeicher im ALE Ein- und Ausgang geleert bzw. reorganisiert
werden.)

Für Hierarchie muss iDOC gewählt werden.

PSA und danach Datenziel (Paketweise)

Bei dieser Verbuchungsart wird ein Dialogprozess pro Datenpaket eines Request gestartet, der das
Datenpaket in die PSA-Tabelle schreibt. Sobald es erfolgreich übertragen wurde, beginnt die
Verbuchung der Daten mit dem selben Prozess in die Datenziele. Erst nach Abschluss der
Fortschreibung, steht der Prozess für das Verbuchen eines weiteren Datenziels zur Verfügung.

Im SAP BW werden pro Datenanforderung max. nur so viele Dialog-Prozesse benötigt, wie Sie im
Quellsystem innerhalb der Transaktion SBIW (Customizing der Extraktoren) für die maximale
Anzahl paralleler Prozesse eingestellt haben.

PSA und Datenziel parallel (paketweise)

Verbuchungsart: ein Dialogprozess pro Datenpaket eines Requests, der das Datenpaket in die PSA
schreibt und sobald erfolgreich in der PSA Tabelle verbucht wurde, wird im Unterschied zu oben, ein
zweiter, paralleler Prozess gestartet. Der Prozess zur Datenübertragung (in die PSA) steht somit schon
wieder zur Verfügung, obwohl der erste Prozess noch im Datenziel bucht.

Nur PSA
Verbuchung aller Datenpaketes in die PSA Tabelle, ohne sie in Datenziel fortzuschreiben.
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.
Falls die Daten über die PSA geladen werden kann eine Startroutine in der Pflege der
Übertragungsregeln angelegt werden, die pro Datenpaket ausgeführt wird. Sie können hier die Daten
verändern (Hinzufügen oder löschen) oder auch prüfen. Für iDOC ist keine Verwendung von
Startroutinen möglich.

Bei der Pflege von Fortschreibungsregeln wird zwischen Fortschreibungsmethode und –art
unterschieden:
 Die Fortschreibungsregeln spezifizieren, wie die Daten (Kennzahlen, HYPERLINK "\\Srv-
paris\user\Jürgen\BI\" \l "Zeitmerkmale" Zeitmerkmale, Merkmale) aus der HYPERLINK
"\\Srv-paris\user\Jürgen\BI\" \l "Kommunikationsstruktur" Kommunikationsstruktur einer
HYPERLINK "\\Srv-paris\user\Jürgen\BI\" \l "InfoSourc" InfoSource in ein HYPERLINK
"\\Srv-paris\user\Jürgen\BI\" \l "Datenziel" Datenziel geschrieben werden.

Sie verbinden eine InfoSource mit einem Datenziel.

Fortschreibungsregeln sind im Unterschied zu HYPERLINK "\\Srv-paris\user\Jürgen\BI\" \l
"Übertragungsregeln_lokal" Übertragungsregeln nicht Quellsystem- spezifisch, sondern
Datenziel-spezifisch.

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.

Fortschreibungsregeln ordnen dazu die InfoObjects der InfoSource den InfoObjects der
Datenziele zu , sie legen also fest, wie Kennzahlen und Merkmale aus der
Kommunikationsstruktur in das Datenziel transferiert werden.

Mit der Fortschreibungsmethode steuern Sie, wie ein Wert ( Kennzahl, Merkmal,
Zeitmerkmal) in das Datenziel fortgeschrieben wird. Sie haben folgende
Auswahlmöglichkeiten:

- Füllen aus einem Quellfeld (Merkmal, Kennzahl etc.)

- Ermitteln des Wertes über eine Routine (ABAP)
- Anreicherung
- Konstante
- Initialwert
- Formel

Darüber hinaus gibt es noch eine Reihe weitere Möglichkeiten , den sog. Speziellen
Fortschreibungsmethoden. Dazu gehören u.a. :

- Rückgabetabelle
- Währungsumrechnung
- Umrechnungsroutine
- Zeitverteilung etc.

Mit der Fortschreibungsart steuern Sie, ob und wie eine Kennzahl bzw. Datenfeld bzw.
Attribut/Text im Datenziel mit individueller Schlüsselkombination fortgeschrieben wird.

Sie haben folgende Auswahlmöglichkeiten

Fortschreibungsart für BasisCubes

Addition
Maximum
Minimum
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.

Schnittestellen

Service-API: Diese Technologie ermöglicht die Übertragung von Daten aus SAP-Sytemen. Spezieller
Bestandteil ist das Data Mart-Interface
BAPI: für die Extraktion von Daten aus Fremdsystemen unter Anbindung verschiedener Third-Party-
Tools. Z.b. Daten aus Oracle. Transaktion BAPIBrowser – anzeigen lassen.
Flat Files: Flache Dateien wie Attribute, Texte, Hierarchien, Bewegungsdaten. Die Transferstruktur
muss im BW gepflegt sein.
DB Connect: Daten aus externen Anwendungen aus den jeweiligen DB-Tabellen oder –Views direkt
ins BW übertragen .
XML/SOAP: Unterstützt: SOAP-Services des SAP WAS, SAP XI und Web Services.
UD-Connect: Unterstützt JSEE Konnektivität, aus SAP- und Nicht-SAP-Systemen, praktisch alle
relationalen und multidimensionalen Datenquellen.
Open Hup Service: Daten aus SAP-BW in SAP-CRM, ERP, Data Marts und nicht SAP-Applicationen
zu übertragen. Es können auch Third Party Tools integriert werden.

Kapitel 2

Datenextraktion aus SAP-Quellsystemen

Die Verbindung zwischen Quellsystemen und BW besteht aus einzelnen Verbindungen und
Einstellungen, 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. Manuell müsse diese vorab angelegt werden.

RFC-Verbindungen können in der Transaktion SM59 gepflegt werden. Sie beruhen auf der ALE
Technologie (Applikation Link Enabling).
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.

Testtool zur Datenextraktion: Extractorchecker.

Das Customizing der Datasources wird in der Transaktion SBIW durchgeführt.

BCT-DataSources: Bevor Übernahme möglich, sind zwei Schritte notwendig:

Übernahme der Anwendungskomponentenhierarchie

Selektive Übernahme der DataSources

Generische DataSource: Unabhängig von einer bestimmten Anwendung können folgende,

eigendefinierte Extraktionsmethoden gewählt werden:

DB-Tabellen
DB-Views
Funktionsbausteine
InfoSet (SAP Query)

Es sind keine ABAP-Kenntnisse notwendig.

Technische Eigenschaften der DataSource:

Extraktionsmethode/Extractor
PSA oder iDOC

Deltaverfahren:
Ist eine DataSource deltafähig beschreibt sie in ihren Metadaten ein bestimmtes Deltaverfahren. Es
gibt an auf welche Weise Daten übertragen werden.

Early-Delta-Initialisierung: Diese Eigenschaft einer DataSource, ermöglicht es, Daten im

Quellsystem zu verbuchen, während einer Delta-Initialisierung.

Globale Steuerparameter der Datenübertragung: Die in der Transaktion SBIW im Bereich Allg.
Einstellungen gepflegten Steuerparameter zur Datenübertragung, gelten als global, d.h. DataSource-
übergreifender Standardwert.

Logistik Datenextraktion

Die Pflege der Extraktstruktur und DataSources werden im „Logistik Extraktstrukturen

Customizing Cockpit (LBWE)“ mit der Transaktion SBIW durchgeführt.
Funktionalitäten:

Pflege von Extraktstrukturen ( wird von Berater oder von SAP gepflegt). SAP liefert bereits
Extraktstrukturen, die erweitert werden können. Nach der Erstellung der Extraktstruktur wird diese
automatisch generiert. Fehlende Felder werden ergänzt.
Pflege von DataSources: allgemeine Pflege zur Auswahl von selektierbaren Feldern und
Negierbarkeit.
Aktivieren der Fortschreibung: Setze Aktivierung, und fortan werden Daten in die Extraktstruktur
geschrieben, online und beim Füllen der Neuaufbautabellen.
Jobsteuerung
Initialisierung/Setup: erfolgt auf OLTP-Seite. Ein Neuaufbau füllt Neuaufbautabellen, die während
der Initialisierung gelesen werden. Jedem Hintergrundlauf wird ein Name zugeordnet. Erfolgt ein
Abbruch, wird der Stand des Neuaufbaus unter diesem Namen gespeichert und kann später an dieser
Stelle fortgesetzt werden. Zwischenstand wird danach gelöscht. Neuaufbau soll im Hintergrund laufen.
Löschen der Inhalte aus der Neuaufbautabelle: Das Löschen der Tabellen geschieht aus
Performance-Gründen mandantenübergreifend.
BW-Protokoll: Kontrolle der Übertragung. Wenn der Benutzerparameter MCL gesetzt ist, wird das
Protokoll benutzerbezogen pro Applikation abgelegt.
Protokoll nur zu Testzwecken benutzen.

Ein Full-Update ins BW wird ebenfalls über die Neuaufbautabellen durchgeführt.

Verbuchungsmethoden:

Stehen im Logistik Extraktstrukturen Customizing Cockpit (LBWE)“ pro Applikation zur

Verfügung.

Unserialisierte V3-Verbuchung: Werden in die Verbuchungstabellen geschrieben und dort solange

gehalten bis die Daten durch Verbuchungssammellauf ausgelesen und verarbeitet werden. Sie gelangen
in die BW-Delta Queues, aber ohne Reihefolge.

Direct Delta: (V1 Verbuchung - Realtime Verbuchung, synchrone Verbuchung). Jede Belegbuchung
erfolgt direkt in die BW-Delta-Queue. Die Übertragungsreihenfolge stimmt dabei mit der zeitlichen
Erstellungsreihenfolge der Daten überein.

Queued Delta: (V2 – Verbuchung: Asynchrone Verbuchung, Verbuchung erfolgt erst nachdem alle V1
– Verbuchungen erfolgt sind). Daten werden in einer sog. Extractions Queue gesammelt und können
durch einen Verbuchungssammellauf in die BW-Delta-Queue übertragen werden. Es werden dabei pro
DataSource bis zu 10000 Delta-Extraktionen zu einer LUW verdichtet.

Erweiterung von BCT DataSources (Datenextraction anpassen)

Es kann weniger Auswand bedeuten eine neue Generische DataSource anzulegen als eine vorhandene
zu erweitern.

Customer Append: Erster Schritt: Customer Append für die Extraktstruktur der DataSource
generieren. Aus LO-Cockpit nicht möglich.
Zweiter Schritt: Erweiterung zum Füllen der neuen Felder in der Extraktstruktur. Neues Projekt
anlegen,. SAP stellt die Erweiterung RSAP0001 mit vier Erweiterungskomponenten zur Verfügung.

EXIT_SAPLRSAP_001 Bewegungsdaten-Versorgung

EXIT_SAPLRSAP_002 Stammdaten- und Text-Versorgung

EXIT_SAPLRSAP_003 Text-Versorgung

EXIT_SAPLRSAP_004 Hierarchie-Versorgung

Hier ist in INCLUDES das Füllen der Extrastruktur hinterlegt.

Generische Datenextraktion

Einsetzen, wenn keine DataSource zur Verfügung gestellt wird.

Im Bereich Generische DataSource im Quellsystem steht die Transaktion RSO2 Generische Data
Source pflegen von Bewegungsdaten, Stammdaten und Texten zur Verfügung.

Kapitel 3

Delta Management

Bedeutet: Nur neue oder geänderte Datensätze in das SAP BW zu extrahieren.

DQ = DeltaQueue Bezeichnung der Tabelle

RSA7 = die zentrale Transaktion zur Anzeige der Delta Queue im SAP-Quellsystem.

Delta vorahnden: Deltafähig, 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 - DeltaQueue

SAP BW Quellsystem: Delta-Queue wird nicht verwendet, bei DataMart Szenarien, ist aber
möglich.

SAP-System: Nicht alle BCT-DataSources

Fremdsystem: Third Party Tools, über BAPI, ist deltafähig

XML/SOAP: Deltafähigkeit leitet sich immer von Flat File DataSource ab.

UD-Connect: lässt sich mit dem Tool „Generische DataSource“ realisieren.

DeltaQueue stellt eine Funktionalität des SAPI dar. (zentrales Interface im BW)

Aufgaben der DeltaQueue

Ablagebereich für neue und veränderte Datensätze im Quellsystem, die bei nächster Delta-
Anforderung an das BW übertragen werden.
Wiederholung der vorangegangenen Delta-Anforderung: Deltaqueue basiert auf Queue-
Funktionalität innerhalb der RFC-Technologie des SAP Web Application-Servers (qRFC).
Unabhängige Delta-Versorgung mehrerer SAP BW-Zielsysteme: Pro Zielsystem eine separate
Deltaqueue, damit Delta-Datensätze zu dieser DataSource unabhängig voneinander angefordert werden
können.
Die DeltaQueue bei Bewegungsdaten und Stammdaten: Beide Datentypen verhalten sich im Bezug
auf ihr Delta-verfahren gleich.
Delta Queues zu generischen Datasources: Beim löschen geht das Delta-verfahren der DataSource
unwiderruflich verloren, weil auch die Initialisierungsselektion zur DataSource gelöscht wird.

Die DeltaQueue besteht aus drei Tabellen

Fortschreibungsmodus und Deltaverfahren

Delta Verfahren: Eigenschaft des Extractors; gibt an auf welche Weise Daten übertragen werden. Als
Attribut der DataSource gibt es an, wie die Daten der DataSource ins Ziel übermittelt werden. Es ist
daraus abzuleiten für welche Datenziele eine DataSource geeignet ist, wie fortzuschreiben ist und wie
Serialisiert wird.

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. Es ist Addieren und Überschreiben erlaubt. Fortschreibung
in ODS-Objekt und InfoCube möglich. Technischer Name: ABR.

Der Extraktor liefert additive Deltas, die requestweise serialisiert werden. Nur das
Addieren von Feldern ist erlaubt. Die Schlüsselfelder werden nur einmal geliefert.
Fortschreibung in ODS-Objekt und InfoCube möglich. Technischer Name: ADD.

Bildung von Deltas mit After-Image, die direkt in die Delta-Queue fortgeschrieben werden
die Daten werden paketweise serialisiert, da der gleiche Schlüssel mehrmals übertragen werden kann.
Direkte Fortschreibung in InfoCube ist nicht zugelassen.
Zur Fortschreibung eines InfoCubes muss immer ein ODS-Objekt zwischengeschaltet sein.
Hier ist bei numerischen Kennzahlen nur Überschreiben nicht Addieren erlaubt, da es sonst zu falsche
Ergebnissen kommen würde. Technischer Name: AIM/AIMD.

Fortschreibungsmodus/Updatemodus im InfoPackage bestimmt welche Daten angefordert werden.

Full-Update (F): Steht in allen Datasources zur Verfügung. Alle im InfoPackage angeforderten
historischen Daten werden weitergegeben

Delta Initialisieren (C ): Die Initialisierung des Delta-verfahrens ist Voraussetzung für das Anfordern
von Deltas. Es ist mehr als eine Initialisierung möglich und somit ist es möglich die Daten Schrittweise
in das BW zu laden. Zum Beispiel erst für Kostenstelle 1000 und dann für Kostestelle 2000.
Selektionsbedingungen werden gesichert und ein Full-Load wird gestartet. SAPI liest die
Selektionsfilter und ruft den Extractor auf., der der Datenquelle zugeordnet ist.

Wiederholen (R ): Schlägt der Ladevorgang fehl, wird das Delta erneut angefordert.

Delta Update (D): Die seit der letzten Initialisierung geänderten oder neuen Daten werden angefordert.

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. Z.b. FI, LO. (Daten liefert der Extractor)
Pulled Delta (E): Pulled Delta führt den Pull der Daten in die Queue durch das Extractorprogramm
im Deltamodus aus. Z.b. LIS, CO-PA. Der Extractor liefert das Delta der DataSource. (Das Delta
leifert die Anwendung)

Early-Delta-Initialisierung:
Dabei ist es möglich, bereits während der Initialisierungsanforderung im Quellsystem die Daten in die
Delta-Queue der Anwendung zu schreiben.
Die Initialisierung des Delta-verfahrens (Init-Request, kann durchgeführt werden, ohne die Verbuchung
der Daten im Quellsystem zu stoppen.
Es kann keine Init-Simmulation mit einem Early-Delta zusammen ausgeführt werden.
Extraktoren, die diese Methode unterstützen, werden frühestens mit Plug-In 2002.1 ausgeliefert.

Wenn es heißt: Deltaqueue zur DataSource wird im Quellsystem erzeugt bedeutet das, dass eine leerer
Ablagebereich für neue oder geänderte Daten zu einer DataSource angelegt wird.

Aufgrund großer Datenvolumen kann die Initialisierng des Deltaverfahrens schrittweise erfolgen. 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. Die
Tabelle RODELTAM definiert die Eigenschaften des Deltaverfahrens einer DataSource: (Delta-Typ,
Satztypen (Record-Mode), Serialisierung).
In der Tabelle ROOSOURCE (im SAP Quellsystem) kann überprüft werden, wie die Daten über die
DataSource extrahiert oder in der Tabelle RSOLTPSOURCE (im BW).

Art und Weise der Delta-Bereitstellung, Deltatyp:

` ´ , Delta-Typ ist nicht definiert.

„A“, Die DataSource ermittelt das Delta mit ALE Fortschreibungszeigern. Diese Methode wird vor
allen Dingen im Zusammenhang mit DataSources für Attribute und Texte aus SAP-Quellsystemen
verwendet.

„D“, schreibt Delta-Datensätze direkt in die Deltaqueue (Push) zur DataSource. Anwendung
bestimmt Delta z.B. LO, FI-AR/AP.

„E“, Die DataSource ermittelt das Delta auf Anforderung durch den Extraktor. Der Extraktor muss
auf Anforderung die Delta-Sätze der DataSource liefern PULL. Der Extraktor bestimmt Delta.

„F“, Deltatyp nur für Flat File. Ohne DeltaQueue.

Sieben Ausprägungen (Record Mode, gespeichert im Feld ROCANCEL, diesem Feld wird
im InfoObjekt das Feld 0RECORDMODE zugeordnet):

Satztyp = Record Mode befasst sich mit der Frage, auf welche Weise im Delta-Verfahren
Änderungen an Daten aufgezeichnet werden.

` ´, der Satz liefert ein After-Image. Übertragen wird der Zustand nach einer Änderung oder nach
dem Einfügen. Er darf nur dann direkt in einen InfoCube fortgeschrieben werden, wenn es im Request
das entesprechende Befor-Image gegeben gibt.
„X“, Der Satz liefert eine Before-Image. Übertragen wird der Zustand vor einer Änderung oder vor
dem Löschen. Alle summierbaren Attribute des Satzes (Kennzahlen) müssen mit umgekehrten
Vorzeichen übertragen werden. Vorzeichenumkehrung durchführen durch Extraktor (Default) oder
durch SAPI. In einer nicht additiven Fortschreibung eines ODS-Objektes werden diese Sätze ignoriert.
Before- ist ergänzend zu After-Image.
„A“, der Satz liefert ein additives Image.
Nur die Differenz für alle numerischen Werte anzeigen. Übertragen wird für summierbare
Attribute nur die Veränderung und für nicht summierbare Attribute der Zustand nach der
Änderung bzw. nach dem Anlegen.
Im InfoCube kann er uneingeschränkt fortgeschrieben werden. Für ODS erfordert er aber
ein additives Fortschreiben.
„D“, Der Satz muss gelöscht werden.
Übertragen wird nur der Schlüssel. Dieser Satz und die DataSource kann nur in ODS
fortgeschrieben werden.
„R“, Der Satz liefert ein Reverse:
Äquivalent zum Before-Image. Unterscheidet sich aber in der Fortschreibung eines ODS:
Ein vorhandener Satz mit gleichem Schlüssel wird gelöscht.
„N“, Der Satz liefert eine New-Image.
 Äquivalent zum After-Image ohne Before-Image. Ein New-Image sollte anstelle eines
After-Iamge übertragen werden, wenn eine Satz angelegt wird. New- ist ergänzend zum
Reverse-Image. Für jede Änderung wird eine neuer, eindeutiger Satz erzeugt.

Grundsätzlich ist in InfoCubes nur eine additive Fortschreibung möglich.

Folgende Abhängigkeiten sind bei deltafähigen Datasources zu beachten:

Wenn die DataSource eine Before- und ein After-Image sendet, kann diese Kombination in einen
beliebigen InfoCube oder ein beliebiges ODS-Objekt geladen werden. Wenn bei ODS die Einstellung
zum überschreiben gewählt wurde, gelangt nur das After-Image (das Letzte) in die Aktivierungs-
Queue Tabelle des ODS. Ist ODS so eingestellt, das Daten hinzugefügt werden können, sind Before-
und After-Image nötig.
Handelt es sich um eine Additives Image, können die Daten in eine ODS oder InfoCube geschrieben
werden. Bei ODS muss die Fortschreibungsart für Kennzahlen allerdings auf Addieren eingestellt
werden und nicht auf Überschreiben.
Sendet die DataSource nur das After-Image, muss diese zunächst in eine ODS fortgeschrieben werden,
das sich im Modus überschreiben befindet.
Reverse-Image können von allen Zielen verarbeitet werden.
Delete-Images können nur von ODS verarbeitet werden, InfoCube können keine Löschungen
verarbeiten.

Wichtig: Ein Delta-Verfahren sagt grundsätzlich nichts darüber aus, wie das Delta in der Anwendung
ermittelt wurde. 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.

Zusätzliche Hinweise

Unterstützt eine DataSource kein Delta-Verfahren (Selektion im Full Update) ist eine Snapshot-
Szenario möglich.

Kapitel 4

Übertragen von Daten aus Flat Files

Flache Dateien ermöglichen das Laden aller Arten von Daten (Text, Stammdatenattribute, Hierarchien
und Bewegungsdaten) ins BW.

Zwei Möglichkeiten für das Laden von Stammdatenattributen und Texten:

Flexibles Staging: Unter Verwendung einer flexiblen DataSource mit Übertragungs- und
Fortschreibungsregeln. Hier ist es möglich, aber nicht erforderlich, eine Stammdaten-ODS-Objekt als
Zwischenstufe vor dem InfoObjekt, zu verwenden.
Direktes Staging mit Übertragungsregeln: Verwendet nur Übertragungsregeln, keine
Fortschreibungsregeln.

Zwei Möglichkeiten für Hierarchien :

Direktes Staging nur mit Übertragungsregeln.
Direktes Staging ohne Übertragungsregeln, d.h. Datenübertragung ohne Transformation. Das
Datenformat muss dem gewünschten Ergebnis entsprechen.

Bewegungsdaten:
verwenden den Ladevorgang der flexiblen InfoSource (Flexibles Staging)
ebenfalls mit Option für ein zwischengeschaltetes ODS
besitzen kein festes Format, lediglich die Transferstruktur im BW muss dem Layout der Datei
entsprechen.

Für Hierarchien und Texte gelten feste Formatanforderung für die Datei, während bei
Stammdatenattributen die Reihenfolge beliebig ist. Die Schlüssel müssen sich am Anfang des
Dateilayouts befinden.

Voraussetzung für das Laden von Flat Files dient eine File-System in der Quellsystem Umgebung
des BW-Systems. (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. (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. Beim Laden von flachen Dateien
können ABAP-Routinen angelegt werden, die das Laden steuern und überwachen (z.b. Schutz vor
doppeltem Laden, Dateien mit gleichen Namen). Es können Kopfzeilen ignoriert werden. Eine
Vorschau ist möglich, ohne das die Dateien mit einem InfoPackage geladen werden müssen und es
können Filter eingesetzt werde. Zum Test der Übertragung- und Fortschreibungsregeln kann auch ein
Simulation durchgeführt werden.

Hinweis: Falls die Datei über eine Batchverarbeitung geladen werden soll ist die Dateiablage auf dem
Anwendungsserver zwingend notwendig. Gewährleistung dafür, dass die Datei zum Ladezeitpunkt
auch tatsächlich vorhanden ist.

Es kann ein logischer Dateiname eingegeben werden. 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. Die ist keine BW spezifische Transaktion. Da
es beim Upload von Flat Files kein direktes Mapping über die Transferstruktur gibt, ist die
Feldreihenfolge in der Transferstruktur zwingend einzuhalten.

Drei Möglichkeiten des Delta-Managements bei flachen Dateien:

Delta mit Status Neu: Sendet das After-Image o. New-Image eines Satzes. Wenn das Altsystem nur
den aktuellen Status einer Änderung kennt, muss die Überschreibfunktion des ODS Verwendet werden.
Nachdem die Daten in das Change Log des ODS fortgeschrieben wurden (durch Aktivieren der ODS-
Daten), können die Daten anderen BasisCubes oder ODS mit den additiven Daten, die das jeweilige
Ziele verarbeiten kann, zur Verfügung gestellt werden.
Additives Delta: Das BW erwartet entweder einen Satz mit dem Unterscheid oder zwei Sätze: einen
mit After-Image und einen mit Before-Image. Das Filesystem verarbeitet nicht den Record Mode,
daher ist der Record Mode „X“, der das Vorzeichen umkehren würde, wenn es sich um eine MySAP-
Quelle handelt, nicht verwendbar. Das Before-Image muss bereits umgekehrte Kennzeichen aufweisen.
Pseudo Delta (Löschen und Hinzufügen): Das Ziel besteht darin, den gesamten BasisCube oder das
gesamte ODS nicht ständig löschen und erneut laden zu müssen, sondern nur die Daten die sich
geändert haben könnten. Die Prozesse, die für ein Pseudo Delta notwendig sind, sind zeitintensiv und
fehleranfällig. Um Genauigkeit und Konsistenz zu gewährleisten, kann der Prozess automatisiert
werden.

Wenn eine Full Load durchgeführt wird, führt das zu einem leeren Deltaverfahren, d.h. die normalen
Deltavorgänge stehen nicht zur Verfügung. Es kann hier auch mit einem PseudoDelta gearbeitet
werden.

Welches Delta-Verfahren verwendet werden soll, wird in Form des Fortschreibungsmosdus auf dem
Register Transferstruktur bestimmt. Hier wird das technische Delta-Verfahren bestimmt:

Full Load durchführen, führt zu leerem Delatverfahren: wenn Deltaverfahren leer ist, steht der normale
Delta-Ladevorgang nicht zur Verfügung. Pseudo Delta einsetzen.

Delta mit Staus Neu: für geänderte Sätz (After-Tmage, nur ODS, Deltaverfahren = FILO).

Additives Delta (BsisCUbes und ODS ok), Deltaverfahren = FIL1.

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, die an Standardverbindungen angeschlossen sind.

Bei Standardverbindungen sind DB-Client und Data Base Shared Library (DBSL) bereits
installiert.
Bei anderen müssen sie erst installiert werden
Grundregel für die Nutzung DB Connect: Die Fremddatenbank benötigt DBSL.
Eine DataSource wird aus der Tabelle oder dem View generiert.
Der technische Name mit beginnt mit 6DB.
DB-Connect bietet die Möglichkeit neben der normalen SAP-Standard-Verbindung weitere
Datenbankverbindungen herzustellen.
Um Daten von einem Datenbanksystem übertragen zu können, müssen die Metadaten vorher in Form
einer DataSource vorliegen.
Man generiert eine DataSource für Datenbankquellsysteme mit dem Kontextmenü des
Datenbankquellsystems.

Um die Daten mittels DB Connect aus einem von SAP unterstützten Datenbank-Management-
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.
Die Metadaten der Tabelle oder Views des externen RDBMS durch Definition einer DataSource dem
BW bekannt gemacht werden.

Nutzen der Funktionalität von DB Connect – Vorbereitungen:

Bei Standardverbindungen sind DB-Client und Data Base Shared Library (DBSL) bereits
installiert. (Nutzen Open- und Native-SQL-Statements). ? Open-SQL = Datenbankabfragesprache,
die sich am SQL-Standard orientiert aber Erweiterungen enthält.

Um aus anderen DBMS über DB-Connect Daten in das BW laden zu können, 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.

DB Connect Daten und Metadatenbereitstellung

Bevor Daten aus dem externen DBMS geladen werden können, müssen zuvor die Metadaten, d.h. die
Tabellen- bzw. View- und Feldinformationen im BW in Form einer DataSource vorhanden sein.
Mit Hilfe von DB-Tabellen bzw. –Views aus dem Datenbankkatalog des DBMS können DataSources
generiert werden.
DB Connect beinhaltet somit auch das Mapping von Datenbank-Datentypen auf ABAP-Datentypen.
Diese DataSources erfüllen die Aufgabe die Metadaten dem BW bekannt zu machen. Danach kann
der Bereitstellungsprozess der Daten erfolgen.

Identifizierung und Verbindung zum DBMS:

DB-Verbindung
DBMS auswählen: ( ADA, DB2 usw.)
Benutzername (DB-User unter dessen Namen wird die Verbindung geöffnet)
DB-Passwort
Verb.-Info: Datenbank-Namen, Datenbank-Host usw.
Permanent: wird benötigt, wenn die Verbindung ausfällt. Z.b. bei Ausfall der Netzwerkverbindung.
Unabhängig davon versucht der SAP Workflow, die unterbrochene Verbindung wiederherzustellen.
Schlägt dieser Versuch fehl verhält sich das System wie folgt

DB-Wiederverwendungstyp ist nicht permanent (DBCON_RECO=BlANK):

Fehler wird ignoriert, die aufgerufene Transaktion wird gestartet. Wenn diese
Transaktion auf eine Verbindung zugreift, die nicht besteht, kommt es zu einem
Transaktionsabbruch.
DB-Wiederverwendungstyp ist permanent (DBCON_RECO=X): Nach dem ersten
Verbindungsfehler wird geprüft, ob eine Neuverbindung vor jeder Transaktion möglich ist. Wenn
nicht, wird die Transaktion nicht gestartet. Dies gilt unabhängig davon, ob die aktuelle Transaktion auf
diese spezielle Verbindung zugreifen würde oder nicht. Das SAP-System funktioniert nur in vollem
Umfang, wenn alle DB-Verbindungen des Typs Permanent wiederhergestellt sind.
Hinweis: Das Kennzeichen „ist permanent“ sollte dann gesetzt werden, wenn die geöffnete DB-
Verbindung unverzichtbar ist oder sehr häufig benötigt wird.

Verbindungslimit: Legt die max. Anzahl der simultanen Verbindungen fest. Darüber hinausgehende
Verbindungen werden abgelehnt.

Verbindungsoptimum: Legt die Anzahl der optimalen Verbindungen fest. Wird diese Anzahl
überschritten, so sorgt der Workprozess nach Beendigung der Transaktion selbstständig dafür das die
darüber hinausgehenden Verbindungen wieder aufgebaut werden.

Namenskonventionen für Tabelle und Views:

entsprechen im allgemeinen den ABAP-Dictonary Namenskonventionen

es können nur Tabellen und Views zur Extraktion verwendet werden, deren
technische Namen nur Großbuchstaben, Ziffern und dem Zeichen _ (Unterstrich) bestehen,
Verwendung weiterer Zeichen kann zu Problemen führen.
Aus einer Tabelle oder View wird eine DataSource generiert, deren techn. Name sich aus dem Präfix
6DB_ und dem techn. Namen der Tabelle bzw. Views zusammensetzt.
Der techn. Name der DataSource im BW ist auf 30 Zeichen begrenzt.
Der techn. Name der Tabelle bzw. des Views darf demnach nicht länger als 26 Zeichen sein.
Tabellen/Views mit längeren nahmen stehen somit zur Extraktion nicht zur Verfügung.

Namenskonventionen für Felder:

es können nur Felder zur Extraktion verwendet werden deren technische Namen nur aus
Großbuchstaben, Ziffern und dem Zeichen _ (Unterstrich bestehen).
Die techn. Feldnamen dürfen nicht länger als 26 Zeichen sein.
Felder mit reservierten Feldnamen dürfe nicht verwendet werde.
Beispiel: 6DB_ (4Zeichen), der technische Name der DataSource ist max 30 Zeichen, also nur 26 für
Zeichen.

Die DB Connect-DataSource unterstützt kein Deltaverfahren

(weil keine Unterstützung von SAPI, DeltaQueue existiert)

Eine Pseudo Delta-Fortschreibung kann über eine Selektion (z.b. Belegnummer o. Zeitstempel)
oder über ODS erfolgen.

DB Connect unterstützt nur die Transfermethode PSA.

Kapitel 6

Universal Data Integration

UDI-Technologie ist auf Kundenwunsch entstanden.

Durch die Besonderheiten der UDI –Technologie wird der Zugriff (ohne den Einsatz von ETL-Tools)
auf multidimensionale und relationale DBMS ermöglicht. Verbessert enorm die
Integrationsmöglichkeiten von BW in bestehende heterogene Systemlandschaften.
Grundlage: bilden die sog. 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. Es werden persistente (Staging) und
transiente (OLAP) (direkter Zugriff über RemoteCube) Datenbereitstellung unterstützt.

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, von Sun) können sie Anwendungen, die
mit Java SDK ((Software Development Kit) erstellt worden sind, mit mehr als 200 JDBC-
Treibern verbinden. Teradata, Oracle, SQL usw.

Der JDBC-Connector ermöglicht den JDBC-Treibern:

Eine einheitliche Verbindungsverwaltung, die in die Benutzerverwaltung im SAP Enterprise Portal.

Einen einheitlichen Metadaten-Service durch Implementierung von JMI-Funktionen, die auf den
CWM basieren:

CWM: Das Common Warehouse Model, ist ein Standard OMG (Objekt Management
Group), der ein Framework für die Darstellung von Metadaten in Data Warehouse, BI,
Knowledge Management und Portalen zur Verfügung stellt.

JMI: die Java MetaData Interface-Spezifikation der (Object Management Group) OMG
definiert eine plattformunabhängige Infrastruktur, die die Erstellung, die Speicherung, die
Erkennung sowie den Austausch von Metadaten und den Zugriff auf Metadaten ermöglicht.
JMI ist ein erweiterter Metadaten-Service für die Java-Plattform.

BI ODBO Connector

ODBO OLE DB for OLAP von Microsoft hat sich als Industriestandard OLAP-API für die
Windows-Plattform entwickelt.

Dieser Connector ermöglicht es Anwendungen die mit Java SDK erstellt wurden mit ODBO –fähigen
Datenquellen zu verbinden.

BI XMLA Connector
XMLA von Microsoft erleichtert einen Web-service-basierten, plattformunabhängigen Zugriff auf
OLAP-Provider. 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 SOAP-
basierten XML-Kommunikations-API.

BI SAP Query Connector

SAP-Query ist eine Komponente des SAP WAS, mit der wir ohnen ABAP-kenntnisse
benutzerspezifische Berichte erstellen können. Anwendungen, die mit BI Java SDK erstellt worden
sind, können auf Daten aus operativen SAP-Anwendungen zu greifen.

UD Connect

Mit SAP BW 3.5. besteht mit UD Connect (Universal Data Connect) eine weitere Möglichkeit, Daten
aus SAP-Systemen und Fremdsystemen für die Analyse im BW zu nutzen.

Hinweis: Voraussetzung dafür ist, dass die SAP WAS J2EE-Engine mit den Java Komponenten
installiert ist.

Dabei ist im SAP BW eine persistente (Stagingbereich) und eine transiente (OLAP über RemoteCube)
Datenbereitstellung im BW möglich.

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. Siehe, Abb. 125

Auf Basis einer RFC-Verbindung zwischen dem SAP BW und der J2EE Engine können s.g. Session
Beans, Funktionsbausteine im BW aufrufen oder von den Funktionsbausteinen aufgerufen werden.

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, die Verbindung zwischen der J2EE-Engine und der Datenquelle
(nahezu alle Systeme) herzustellen.

Und die Verbindung zwischen der J2EE-Engine und dem SAP BW herzustellen.

1. Konfiguration: im J2EE-Engine Administrator:

Im ersten Schritt stellen Sie die Verbindung zwischen den BI Java Connector und den
Datenquellen her, sowie die Verbindung zwischen der SAP J2EE-Engine und dem SAP BW.

Jeder BI Java Connector kann „n“ Instanzen ansprechen. Der Connector bekommt einen
 sogenannten JNDI-Namen (Java Naming Directory Interface), unter dem alle wesentlichen
Eigenschaften zusammengefasst werden.

Für den Namen des Connectors ist „SDK _“ als Präfix zu vergeben, damit der Java Connector
von UD Connect erkannt wird.

Einrichten der RFC-Destination zum SAP BW:

Unter RFC Destination:

Programm ID, Gateway-Host, Gateway-services, Number of Prozesse,

Unter Repository:
Application server host, System number, Client, Language, Username, Password

2. 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. Einstellungen

Registriertes Serverprogramm

ProgramID: Programm ID

Hinweis: Die hier eingegebene Programm ID muss der Programm ID entsprechen, die Sie bei
der Pflege der J“EE Engine eingeben.

GatewayHost, Gateway-services

Sichern und testen.

Sie können nun im SAP BW zu einer InfoSource eine UD-Connect DataSource für die
transiente/persistente Datenbereitstellung definieren.

Definition einer UD-Connect DataSource:

Bevor Sie Daten aus UD Connect-Quellen ins BW übertragen können, müssen Sie die Metadaten der
zu extrahierenden Daten dem SAP BW über DataSources mitteilen.

UD Connect Quelle:

Darüber werden Instanzen bezeichnet, die über BI Java Connectors als Datenquelle angesprochen
werden können.
Als Datenquelle kommen relationale Datenquellen, OLAP-fähige (multi-dimensionale) Datenquellen,
XML-fähige (multi-dimensionale) Datenquellen und SAP Anwendungen in Frage.

UD Connect Quellobjekt

Das sind die relationalen und multidimensionalen Datenablagen ( Tabellen, Cubes usw.)

Quellobjekt Element:

Sind die Komponenten der UD-Connect Quellobjekte, Felder von Tabellen, Merkmale und Kennzahlen
von Cubes bezeichnet.

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.
Damit können für das SOAP-Protokoll ausreichende XML-Daten an RFC-fähige Funktionsbausteine
in die ABAP-Umgebung übertragen werden.

HTTP + XML = SOAP!!

Der SOAP-Service überprüft die XML-Daten auf ordnungsgemäße Syntax und konvertiert sie in
ABAP-Felder.

Die Datenübertragung im BW findet im BW über ein Push in die DeltaQueue der generierten
DataSource statt.

Die Anwendungslogik (Schreibvorgänge in die Delta Queue) wird als ABAP-RFC-

Funktionsbaustein statt.

Die Pflegeeinstellung für diesen Service in der Transaktion SICF (System Internet Communication
Framework) anzeigen.
Der Service ist zu finden unter /sap/bc/soap/rfc. Hier ist der entsprechende http-Port zum Aufrufen
des Web AS SOAP-Service aufgeführt.

Ablauf:
Aufrufen des SOAP RFC-Service zum Übertragen der Daten in die Delta Queue im SAP BW mittels
Push.

Senden die im XML-Format zu ladenden Daten über den unter /sap/bc/soap/rfc angegebenen HTTP-
Port an den SOAP-Service des SAP Web Application Servers.

Laden der Daten aus Delta Queue in BW InfoProvider.

XML Data Load – Verwendung eines Web Service

Selbstständige Anwendungsfunktionen, die verarbeitet werden durch offene Internet Standards.

Web Services sind innerhalb SAP BWs einfach zu erstellen, es genügt eine einfache Konfiguration
ohne zusätzlichen Codierungsaufwand.

Man kann so Java Klassen, BAPIs, iDOC , Funktionsbausteine etc auf einfache Weise (Wizard
gestützt) in einen Web Service verwandeln.

Beispiele:
Intelligente Produktkatalogsuche, Produktverfügbarkeitssuche
Preisanfragen, Kundenbonitätsabfragen aber auch
Automatische Websuche (Google)

Web Services nutzen offnen Standards.

Im SAP Web Application Server sind die grundlegenden Webservice-Standards implementiert.

Web Service Discription Language (WSDL)

Universal Discription, Discovery (UDDI)

eXtensibel Markup Language (XML)

SOAP

Im SAP Web Application Server ist der Web Service Creation Wizard enthalten. Auf Basis von
Funktionsbausteinen für XML-fähige DataSources, können hier Web Services für das Laden von Daten
generiert werden.

XML Data Load – Verwendung von SAP XI

XI steht für eXchange Infrastructure und stellt ein zentrales System für die zentrale Datenverteilung
dar. Die Daten stammen dabei aus einer Reihe von SAP und Nicht-SAP Systemen. Es können
heterogene Systeme mit weniger Verbindungen und zur gleichen Zeit kombiniert werden.

Das SAP XI stellt die Standardisierung, Bereinigung und Verteilung der Daten an die Zielsysteme, z.B.
das SAP BW, sicher.

XI ist dabei offen und flexibel .

Architektur unter der Verwendung von SAP XI

SAP XI wird für den Datenaustausch (Bestellungen, Rechnungen usw.) zwischen Lieferanten und den
SAP SRM-Systemen über Unternehmensgrenzen hinweg verwendet.
Die ausgetauschten Daten werden in XI kopiert und mittels Push an das BW übermittelt; keine Punkt-
zu-Punkt-verbindung mit dem EBP.
Bewegungs- 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.

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, ist die
Extraktion der Daten von den mySAP SRM-Quellsystemen in das BW nicht erforderlich.
Die Konsistenz und die Details werden während der Verteilung der Daten von system zu system
vollständig aufrechte erhalten.
Die Vorteile von SAP XI werden in jedem Fall für die Verbindung des mySAP SRM mit den
Lieferanten genutzt.
Übereinstimmung mit der SAP NetWeaver-Architekturvorgabe, zukünftiges Wachstum von SAP-
Angeboten und der NetWeaver Plattform wird vollständig ermöglicht.

Hinweis: wenn die Filialen die Daten als flache Dateien übertragen, können diese einfach über XI in
ein XML-Format umgewandelt werden.

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, dies bedeutet; das Sendersystem wartet vor
der Weiterverarbeitung auf Antwort.
Die Nachricht wird von der Integration Engine nicht aufbewahrt. Nachdem die Nachricht auf dem
Zielsystem verarbeitet wurde, erfolgt ein impliziter Datenbank-Commit (SOAP-Komminikation).
EO (Exactly Once): Die Nachricht wird asynchron gesendet. Dies bedeutet, wartet vor der
Weiterverarbeitung nicht auf Antwort. Die Integration Engine gewährleistet, dass die Nachricht genau
einmal gesendet und verarbeitet wird (RFC-Adapter).
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).
Methode für SAP-BW!!

System Landscape Directory (SLD)

Ermöglicht die Beschreibung von Produkten, Softwarekomponenten, logischen Systemen und

technischen Systemen. SAP Exchange Infrastructure greift beim Entwurf, 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, welche Interfaces benötigt
 werden.

Man unterscheidet dabei folgende Ansätze:

Implementierung von außen nach innen, systemunabhängige Interfaces werden definiert aber
zu einen späteren Zeitpunkt implementiert. (Adapter)
Implemenetierung von innen nach außen, Funktionen sind bereits vorhanden und werden
(Proxy)
Eingebunden.

Integration Builder Konfiguration

In der Konfigurierungsphase konfigurieren Sie den unternehmensübergreifenden Vorgang für

eine bestimmte Systemlandschaft. Beispielsweise definieren Sie Bedingungen für den
Nachrichtenfluss und wählen gemäß Ihren Anforderungen Designobjekte aus.

Integration Server (Monitorring): Laufzeit

Zentrale Verteilungsengine für Nachrichten in der SAP Exchange Infrastructure zur Laufzeit.
Alle systeme, die über SAP Exchange Infrastructure kommunizieren, verwenden zum
Austauschen von Nachrichten diesen Server.
Mit den Konfigurationsdaten aus dem Integrations- Directory entscheidet der Integrations-
Server, an welche Empfänger die Nachricht gesendet werden soll und ob zuvor ein Mapping
ausgeführt werden muss.

Integration repository:

Das Ziel des XI Integration repository besteht in der Konfiguration der Sender-Empfänger-
Beziehung, die zur Laufzeit verwendet werden.

Enthält die Interfaces der verwendeten Systeme. Die Interfaces können importiert oder manuell
angelegt werden. Es steht ein grafisches Mapping Werkzeug zur Verfügung, um die Mapping-
regeln für das Struktur- und Werte-mapping zu sichern.

Mapping-Konzepte

In XI stehen verscheiden Mapping-Methoden zur Verfügung:

nachrichten-mapping

XSLT (eXtensible Stylesheet Language)

Java

ABAP
Unterschied zwischen Proxy und Adapter (RFC) bei der Verwendung der XI Technologie:

Normalerweise kann die Interface-Semantik für eine System, das über RFC und iDOC kommuniziert
nicht geändert werden.

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.

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, die von SAP zertifiziert sind. Um die Extraktion von daten und
Metadaten aus Fremdsystemen zu ermöglichen, stellt das BW offene Schnittstellen, die Staging BAPIs
(Business Applicatiom Programming Interface) zur Verfügung.

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.

Kapitel 9

Datenübertragung über das Data Mart Interface

Data Marts sind bereichspezifische Lösungen innerhalb eines Unternehmens, z.B. um sie als
Entwicklungsstufe für einen langfristig unternehmensweiten Ansatz zu verwenden. Vorteile schnelle
Implementierung mit überschaubarem Datenvolumen. Damit könnte z.b. einen firmenbasierte DWH
Lösung Schritt für Schritt realisiert werden.
Das Data Mart Interface ist Bestandteil der Service-API und ermöglicht somit die Fortschreibung aus
einem Datenziel in eine weiteres.

Daten von einem BW-System in eine anders BW-System oder das gleiche BW-System laden.

Aggregierende Architektur:
Daten werden von einem oder mehreren BW-Systemen in eine zentrales BW-System fortgeschrieben.

Replizierende Architektur:
Ein BW-Server liefert die Daten für andere BW-Server.

Gemischte Architektur:
Zwei BW-Systeme in den Niederlassungen 1 und 2 dienen als Data Mart. Sie übertragen ausgewählte
Daten an eine zentrales SAP BW. Das zentral SAP BW versorgt sich selbst mit daten (BasisCube zu
BasisCube) und übergibt auch replizierte daten an das regionale SAP BW.

MySelf System Data Mart Architecture:

Wird zum Umverteilen von Daten im BW verwendet. Daten werden von einem Datenziel an eine oder
mehrere Datenziele innerhalb eines BW-Systems fortgeschrieben.

Für BasisCubes und ODS ist die Export DataSource deltafähig.

Hinweis: Der Quellsystemtyp MySelf-System wird automatisch im Hintergrund nach der Installation
oder dem Upgrade während des ersten Starts der AWB erzeugt.

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.

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.g. Datenzielen extrahiert und entweder in einer
DB-Tabelle oder einer Flat File geschrieben, bei Flat File wird nur das CSV-Format unterstützt.

Die Daten können im Full- und Delta Modus extrahiert werden. Der Delta Modus steht nur zur
Verfügung, wenn Sie als Datenquelle einen BasisCube oder ein ODS verwenden, wobei das Delta über
die Request-ID ermittelt wird.
Der Extraktionsprozess kann über Prozessketten automatisiert und eingeplant werden.

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.. Mit der Verwendung von SAPI steht ein direkter Weg zur Verfügung.
Standard DBMS bietet Werkzeuge, mit denen direkt auf Datenbanktabellen von anderen Anbietern
zugegriffen werden kann. Z.b DB2, Oracle, SQL usw.. (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.

Die Extraktion erfolgt asynchron, alle nicht unmittelbar, um die Systemressourcen nicht zu überlasten.
Die Delta-Funktion liefert der Zieldatei oder Zieltabelle nur die neuen oder geänderten Bewegungen.

Ü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, DB-Tabelle, Flatfile)
Extraktionsparameter (Extraktionsmodus, Paketierung)
Selektionsoptionen für die zu extrahierenden Daten
Optional BAdI für Transformationslogik

Anlegen eines InfoSpoke

Allgemeines
Typ der Datenquelle (Cube, ODS, SDTM)
Technischer Name der Destination
Extraktionsparameter
Extraktionsmodus
Zeilen pro Datenpaket

Destination
Beschreibung
Logisches Zielsystem
Destinationstyp
DB-Tabelle
Löschen der Tabellen vor Extraktion
Technischer Schlüssel (Kennzeichen gesetztHinzufügen und ausschließliches verwenden der
Schlüsselfelder OHREQID, DATAPAKID und RECORD)
Benachrichtigung an 3Anbieterwerkzeug (z.B. nachfolgendes ETL-Tool)
DateiServer, Name, Verzeichnis und Trennzeichen

InfoObjects
Auswahl der InfoObjects die übertragen werden sollen.
Schlüsselfelder (Nur bei Typ DB-Tabelle)
BasisCube Dimensionsmerkmale
ODS Schlüsselfelder
SDTM Schlüssel der Stammdatentabellen
Selektion
Selektion über ausgewählte InfoObjects. Einschränkung auf Einzelwerte oder Intervalle.
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, so wird ein Open Hub Request erzeugt.
Dieser wird im Monitor - mit Status – angezeigt.

Der Open Hub Monitor gliedert sich in 2 Bereiche:

Im ersten Bereich gruppiert der Open Hub Monitor die Requests nach logischen Zielsystem, Open Hub
Destination und InfoSpoke.

Im zweiten Bereich können Detailinformationen, zu einem der Requests angezeigt werden.

Details hinsichtlich Laufzeitfehler und Job-Protokoll sind ebenfalls verfügbar.

Darüber hinaus kann bei deltafähigen InfoSpokes die Delta-Verwaltung (Zeigt gelesene und nicht
gelesene Requests, Aktivieren und Deaktivieren von Delta) angezeigt werden.

PAGE

PAGE 27