Landschafts-Architektur

Transkript

1 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 Release- Stand ab 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 DMIS- Add-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

2 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 SAP- Quellsysteme am SLT-Server angeschlossen werden. Allerdings schmälert jedes zusätzlich angeschlossene Quellsystem die Performance des Systems, auf dem das SLT- Plug-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. Seite 2/7 3-Tier-SLT (Quelle: PROCON IT)

3 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. Anbindung der Quellsysteme SLT mit ODQ/ODP (Quelle: PROCON IT) 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-Level- Schnittstellen 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 DB- Schnittstelle ermöglicht die Anbindung von SAP- und Nicht-SAP-Quellsystemen an einem SLT-Server. Datenbank MSFT SQL Server Enterprise Edition Oracle Enterprise Edition IBM DB2 LUW/UDB (DB6) IBM DB2 zseries IBM DB2 iseries(former AS/400) IBM Informix SAP MaxDB Kompatibilität teilweise Sybase ASE (ab ) SAP HANA Einige der unterstützten NON-SAP-Datenbanken für SLT Seite 3/7

4 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

5 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-ODP- Datasource 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. Anforderungen an die Hardware SLT ohne PSA über ODQ/ODP (Quelle: PROCON IT) Je nach Anwendungsfall können gemäß der Auslastung kleine Szenarien von mittleren und großen unterschieden werden. Anwendungsfall Klein Mittel Groß 1 Quellsystem 50 Tabellen M - Tabellengröße Datensätze/Stunde 3 Quellsysteme 200 Tabellen L Tabellengröße Datensätze/Stunde 10 Quellsysteme 500 Tabellen XL-Tabellengrößen 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

6 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

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 Performance- Optimierung von Business-Warehouse-Systemen und befasst sich intensiv mit den Themen SAP BW, SAP HANA und Big Data. Seite 7/7