Landschafts-Architektur

Datenreplikation in Echtzeit mit SAP Landscape Transformation
Landschafts-Architektur
Wenn eine bestehende IT-Landschaft im Unternehmen an die Grenzen ihrer
Struktur, Kapazität oder Funktionalität stößt, wird es Zeit für einen Wandel: die IT
Transformation. Sie führt neben Neuorganisation der klassischen IT oft zur
Herausforderung, auch das Wissensmanagement zu modernisieren oder überhaupt
erst zu implementieren. Erleichtert wird die komplexe Sache, wenn die eingesetzten
Lösungen einen hohen Grad der Standardisierung ermöglichen. Bestimmte
Werkzeuge helfen hier, Geschäftsprozesse zu harmonisieren, zu beschleunigen
und die Transformation zu bewältigen. Eines davon ist die SAP Landscape
Transformation Software – kurz SLT. Sie ermöglicht Datenreplikation z.B. für SAP
HANA in Echtzeit. Details zur SLT-Implementierung bietet dieser Beitrag von
Asdren Gashi (PROCON IT).
Hier geht es vor allem um die Datenübermittlung von unterschiedlichen Quellsystemen
zum SAP BW oder direkt zu SAP HANA. Wichtiger Bestandteil von SLT ist der Replication
Server – eine Software-Erweiterung für den Netweaver Application Server (NW-AS) mit
ABAP-Stack. Seine Kernfunktion ist die Replikation von Daten über das LAN, WAN oder
die Cloud.
Der SLT Replication Server zeichnet sich dadurch aus, dass er riesige Datenmengen nicht
nur per Batch, sondern auch in Echtzeit transferieren kann. So lässt sich die Latenzzeit
bei der Beladung des SAP BW von mehreren Stunden auf wenige Minuten oder gar
Sekunden verringern.
Voraussetzungen
Ausgangsbasis für das SLT-Add-in ist der NW-AS mit ABAP-Stack und einem ReleaseStand ab 7.0.2. Soll SLT mit ODP eingesetzt werden, wird mindestens SAP NW 7.3
benötigt. Voraussetzung für einen vollen Funktionsumfang ist SAP NW 7.4 SP5. Bis ein
neues Release erscheint, folgen etwa alle drei bis vier Monate Updates in Form von
Service Packs.
Das benötigte Plug-In heißt Data Migration Server (DMIS). Es integriert die Module Read,
Controller und Write auf dem NW-AS. Zwingend erforderlich ist die DMIS-Installation auf
einer Netweaver-Instanz, um so eine SLT-Server-Instanz zu schaffen. Stammt auch das
Quellsystem von SAP, ist hier ebenfalls das DMIS-Plug-in zu installieren.
Die aktuelle Version 2.0 des SLT Replication Servers setzt auf DMIS 2011 auf.
2-Tier- oder 3-Tier-Architektur
Der SLT Replication Server bietet die Wahl. Bei der 2-Tier-Architektur wird das DMISAdd-in direkt auf dem SAP-Quell- oder Zielsystem installiert. Zur Replikation werden die
Quellsysteme mit Hilfe des Replication-Servers angebunden. Das hat den Vorteil einer
Seite 1/7
leichten Integration in eine bestehende Infrastruktur ohne weitere Lizenzkosten.
Zusätzlicher administrativer Aufwand für den SAP NW-AS entfällt, da ein bestehendes
System genutzt wird. Allerdings können nur SAP-Quellsysteme angebunden werden.
Auch kann es bei Performance durchaus einmal eng werden, da das Quell- bzw.
Zielsystem eine zusätzliche Belastung erfährt. Es ist ebenso möglich, das Zielsystem als
SLT-Server zu konfigurieren. Bei der 2-Tier-Architektur können mehrere SAPQuellsysteme am SLT-Server angeschlossen werden. Allerdings schmälert jedes
zusätzlich angeschlossene Quellsystem die Performance des Systems, auf dem das SLTPlug-in installiert ist.
2-Tier-SLT (Quelle: PROCON IT)
Bei der 3-Tier-Architektur wird das DMIS-Add-in auf einem separaten SAP NW-AS mit
ABAP Stack installiert. Diese Variante ist gegenüber der 2-Tier-Architektur flexibler.
Neben SAP-Quellen können hier auch NON-SAP-Quellen angebunden und zur
Replikation bereitgestellt werden. Die erhöhte Last wird auf ein weiteres physikalisches
System ausgegliedert und beeinträchtigt damit nicht die Leistung des Quell- oder
Zielsystems.
3-Tier-SLT (Quelle: PROCON IT)
Seite 2/7
Deltafähig durch SLT
Positiver Effekt dieses Szenarios: Quellsysteme, die ursprünglich nur im „Full“-Modus
übertragen werden konnten, werden nun Delta-fähig. Dafür sorgen die Trigger, da sie
Delta-Änderungen in die Logging-Tabellen schreiben, um eine Replikation mit kurzen
Latenzzeiten auch für sehr große Datenmengen gewährleisten zu können.
SLT mit ODQ/ODP (Quelle: PROCON IT)
Anbindung der Quellsysteme
Grundsätzlich bietet der SLT-Server zwei Schnittstellen zur Anbindung von
Quellsystemen: zum einen die High-Level-Schnittstelle Remote Function Call (RFC) und
zum anderen Database Connection (DB-Connect). RFC bietet gegenüber Low-LevelSchnittstellen einen erweiterten Funktionsumfang, wie beispielsweise Komprimierung,
verbesserte Fehlerrobustheit und besseres Monitoring. Das DB-Connect von SAP
hingegen ist eine so genannte Low-Level-Verbindung, die kurze Latenzzeiten aufweist
und im Vergleich zu High-Level-Schnittstellen mit weniger Overhead auskommt. Die DBSchnittstelle ermöglicht die Anbindung von SAP- und Nicht-SAP-Quellsystemen an einem
SLT-Server.
Datenbank
MSFT SQL Server Enterprise Edition
Kompatibilität
Ja
Oracle Enterprise Edition
Ja
IBM DB2 LUW/UDB (DB6)
Ja
IBM DB2 zSeries
Ja
IBM DB2 iSeries(former AS/400)
IBM Informix
teilweise
Ja
SAP MaxDB
Ja
Sybase ASE
Ja (ab 15.7.0.11)
SAP HANA
Ja
Einige der unterstützten NON-SAP-Datenbanken für SLT
Seite 3/7
Zielsysteme - SAP HANA DB und SAP BW
Der SLT Replication Server bietet unabhängig von der Schichtenarchitektur diverse
Möglichkeiten der Anbindung verschiedener Zielsysteme. Zwei davon sind hier
hervorzuheben: Während die HANA-Datenbank über DB-Connect angeschlossen wird
und damit eine schnelle Low-Level-Kommunikation ermöglicht, findet die Verbindung zu
BW ausschließlich auf der Applikationsebene statt und wird per RFC-Schnittstelle
eingerichtet. Man unterscheidet hierbei das Ablegen der Daten in die PSA von der direkten
Befüllung der InfoProvider ohne PSA.
Anbindung per Webservice Datasource
Der Datentransfer erfolgt per RFC-Verbindung. Um ein Quellsystem über die Webservice
Datasource anzubinden, muss auf dem SLT-Server eine Replikation mit dem Szenariotyp
BW-PSA angelegt werden. Nach dem Anstoßen der Replikation werden die gesamten
Daten in die PSA des Zielsystems übertragen – je nach Bedarf entweder in Echtzeit oder
terminiert. Bei der Echtzeit-Lösung werden die Daten über die Webservice Datasource
zum BW gepusht und mit Hilfe eines RDA in die InfoProvider über DTP fortgeschrieben.
Dagegen können sie beim Batchverfahren auch terminiert über den Scheduler geladen
und fortgeschrieben werden.
Alternative: ODP/ODQ
Die Operational Delta Queue (ODQ) Architektur ermöglicht in Verbindung mit SLT die
Zwischenhaltung von Daten in einer Warteschlange. Daten werden aus dem Quellsystem
ausgelesen und anschließend zur Queue übermittelt. Das Operational Data Providing
(ODP) Framework speichert Daten in der ODQ und sorgt über das ODP-API dafür, dass
diese Daten in SAP-Anwendungen für Extraktion und Replikation zur Verfügung stehen.
In Kombination mit dem SLT Replication Server können Daten aus der ODQ in Echtzeit
repliziert werden.
Für diese weitere Methode, Daten in die PSA zu laden, muss der SLT-Server mindestens
einen Release-Stand von 7.4 mit SP 5 aufweisen, damit er vollfunktional genutzt werden
kann. Im Gegensatz zur Webservice Datasource ist das Fortschreiben über die PSA
optional. Das ODP-Verfahren bietet eine bessere Komprimierung der Daten.
SLT mit PSA über ODQ/ODP (Quelle: PROCON IT)
Seite 4/7
Daten in SAP-BW-InfoProvider laden
Hierfür kommt nur das ODP/ODQ-Verfahren in Frage, wobei die Daten nicht in der PSA
abgelegt werden, sondern direkt im jeweiligen InfoProvider. Es wird dazu eine SLT-ODPDatasource benötigt sowie ein DTP auf dem SAP BW. Sollen die Daten in Echtzeit
übermittelt werden, bedarf es eines RDA-Jobs, in diesem Anwendungsfall besser bekannt
als Datenpaketjob (Real-Time DTP).
Die ODQ benachrichtigt über die ODP-Schnittstelle das Zielsystem, sobald es neue Daten
bereithält. Daraufhin stößt das BW-System einen Datenpaketjob an, holt die Daten aus
der Delta-Queue und schreibt sie direkt in die InfoProvider.
SLT ohne PSA über ODQ/ODP (Quelle: PROCON IT)
Anforderungen an die Hardware
Je nach Anwendungsfall können gemäß der Auslastung kleine Szenarien von mittleren
und großen unterschieden werden.
Klein
Mittel
Groß
Anwendungsfall
≤ 1 Quellsystem
≤ 50 Tabellen
≤ M - Tabellengröße
≤ 1.000.000
Datensätze/Stunde
≤ 3 Quellsysteme
≤ 200 Tabellen
≤ L – Tabellengröße
≤ 10.000.000
Datensätze/Stunde
≤ 10 Quellsysteme
≤ 500 Tabellen
≤ XL-Tabellengrößen
≤ 50.000.000
Datensätze/Stunde
SLT Server
Software:
Software:
Software:
≤ 2 Data Transfer Jobs
Hardware:
≤ 10 Data Transfer Jobs
Hardware:
≤ 25 Data Transfer Jobs
Hardware:
≥ 2 Cores
≥ 8 GB RAM
≥ 4 Cores
≥ 10 GB RAM
≥ 8 Cores
≥ 16 GB RAM
HANA
≥ + 1 CPU Core
≥ + 3 CPU Core
≥ + 8 CPU Core
Quellsystem
≥ 0.5 Core pro Daten
Transfer Job
≥ 0.5 Core pro Daten
Transfer Job
≥ 0.5 Core pro Daten
Transfer Job
ETHERNET
10 GBIT
10 GBIT
10 GBIT
Hardware-Anforderungen abhängig vom Szenario - Stand: Juli 2015
Seite 5/7
Hinweise zur Konfiguration
Die Konfigurationen von SAP-Quellen, Non-SAP Quellen, SLT, SAP BW und HANA
bedürfen allesamt höherer Berechtigungen, um eine Replikation zu ermöglichen. Bei der
Konfiguration gilt es, entsprechende Rollen zu beachten.
Auf dem SLT-Server lassen sich die zu replizierenden Datensätze loggen, um die
Replikation bei Verbindungs- oder Übertragungsfehlern zum Zielsystem erneut anstoßen
zu können, ohne ein erneutes Initial-Load zu machen. Hier kann man die Anzahl der Tage
festlegen, wie lange Daten in den Logging-Dateien des SLT zwischengehalten werden
sollen.
Daten-Replikation in der Praxis
Nach der Konfiguration des werden alle Metadaten der Quellsystem-Tabellen ausgelesen
und auf dem SLT in einer Tabelle gesichert. Nun können die Quellsystem-Tabellen auf
dem SLT-Server oder wahlweise mit der Client-Anwendung, dem HANA Studio,
ausgelesen und die zu replizierenden Tabellen ausgewählt werden. Nach Auswahl der zu
replizierenden Tabellen/Felder kann der Initial-Load ausgeführt werden. Dabei werden
alle Daten der ausgewählten Tabellen zum Zielsystem transferiert und persistent in
gleichnamige Tabellen gesichert.
Um die Replikation dauerhaft zu starten, muss zusätzlich der Replikations-Daemon
angestoßen werden. Dadurch werden auf der Datenbank des Quellsystems Trigger- und
Logging-Tabellen erstellt, die alle Änderungen auf den Originaltabellen überwachen und
protokollieren.
Bei Eingang der Delta-Daten in die Logging-Tabellen wird der SLT-Server benachrichtigt,
um die Änderungen abzuholen und persistent auf das Zielsystem zu sichern. Nachdem
die Daten erfolgreich auf dem Zielsystem repliziert wurden, sorgt der SLT-Server dafür,
dass diese Einträge aus den Logging-Tabellen wieder entfernt werden.
Transformation und Monitoring
Der SAP LT Server bietet die Möglichkeit, Transformationen von Datensätzen und
Metadaten über seine eigene Library sowie ABAP-Code durchzuführen.
Mit der Transaktion „LTRS“ gelangt man zur Ansicht für Transformationen und Mapping.
Nach Auswahl der Quellsystem-Verbindung erscheinen im linken Reiter mehrere Ordner.
Der Ordner „Rule Assigment“ ist für Transformationen auf Datensatz-Ebene. Der SLT
bietet dabei die Modi „Event“ und „Field“. Mit dem Modus Event können bei auftretenden
Ereignissen wie „Begin of Record“ (vor der Replizierung des Datensatzes) oder „End of
Record“ (nach der Replizierung des Datensatzes) Aktionen zur Filterung oder
Modifizierung von Datensätzen durchgeführt werden. Der Modus „Field“ ermöglicht, Filter
oder Modifikationen für einzelne Felder festzulegen.
Neben der Transformation von Datensätzen bietet der SLT ebenfalls unter dem
Menüpunkt „Table Settings“ die Möglichkeit, Metadaten der zu transferierenden Tabelle
Seite 6/7
und Felder zu ändern. So lassen sich Feld-Datentypen bequem ändern oder es kann
bestimmt werden, dass auf der Zieltabelle zusätzlich Unique IDs erstellt werden sollen.
Mit der DMIS-Installationen wird auch die Monitoring-Funktionalität des SAP ECC
erweitert. Das „Configuration und Monitoring Dashboard“ zeigt den Status des
Replikations-Prozesses im Ampel-System. So kann in Echtzeit nachverfolgt werden, ob
Fehler auftreten oder ob die Replikationen aktuell laufen bzw. wie lange sie gedauert
haben.
Ausblick und Fazit
Zukünftig soll es nicht nur möglich sein, einzelne Tabelle zu replizieren, sondern ganze
Business Objekte wie „Orders“, „Customers“ oder „Contracts“. Weitere Änderungen sind
im ETL-Bereich geplant, so soll die SLT-Library deutlich erweitert werden.
Wie aufgezeigt ist es kein Hexenwerk, die SAP Landscape Transformation zu
implementieren. Allerdings bedarf es dazu eines gewissen Maßes an Expertise, um die
Systemkomponenten ideal aufeinander abzustimmen. Belohnt wird der Aufwand durch
die Möglichkeit der Replikation großer Datenmengen in Echtzeit – eine ausgezeichnete
Ergänzung zu SAP HANA.
Asdren Gashi ist SAP Consultant bei der PROCON IT Aktiengesellschaft in
München. Er berät Unternehmen zu Integration, Migration und PerformanceOptimierung von Business-Warehouse-Systemen und befasst sich intensiv mit
den Themen SAP BW, SAP HANA und Big Data.
Seite 7/7