Mit SAP BW on HANA kommt das ADSO mit neuen Tabellenstrukturen und Funktionen. Im Vergleich zu den InfoProvidern, die auf nicht auf HANA basierenden SAP BW-Systemen genutzt werden, besitzen ADSOs die Fähigkeit, ihre Funktion ohne Verlust der abgelegten Daten zu ändern. Dies schließt auch eine Änderung der Inhalte von Tabellen mit ein, wenn der Typ verändert wird.
Ein ADSO besteht dabei immer aus drei Tabellen, die je nach ADSO-Typ gefüllt und verarbeitet werden. Nicht genutzte Tabellen werden vom System trotzdem angelegt. Somit ist die Nutzung in Routinen, HANA-Experten-Skripten etc. möglich, aber generell nicht immer richtig.
Table of Contents
Das folgende Diagramm zeigt die Tabellen eines ADSO mit dem technischen Namen "SAPBLOG".
Um eine stabile Implementierung bei einer Änderung des Objekttyps zu garantieren, werden bei der Aktivierung des ADSO zwei Views mit den Namen /BIC/ASAPBLOG6 (Extraktion) und /BIC/ASAPBLOG7 (Reporting) angelegt. Diese zeigen auf die Tabelle mit den jeweils aktiven Daten und/oder auf die Extrakt-Tabelle. Die Views werden dabei automatisch mit einer Änderung des Typs eines ADSO aktualisiert und ermöglichen so auch bei Anpassungen des Modells einen stabilen Ladeprozess ohne Seiteneffekte.
Die folgende Tabelle zeigt die unterschiedlichen Einstellungen eines ADSO, die den Aufbau der Views beeinflussen. Kommt ein View in beiden Spalten der folgenden Tabelle vor, enthält dieser auch beide SAP BW-Tabellen über eine UNION-Funktion.
Damit ergibt sich die generelle Regel, dass, egal welcher ADSO-Typ genutzt wird, ein Lookup im ABAP oder SQL immer auf den 7er View erfolgen sollte, damit die Implementierung nach einer Änderung des ADSO-Typs reibungslos funktioniert. Da stets alle Tabellen angelegt werden, fällt ein Fehlverhalten oftmals nicht sofort auf, falls die Tabelle vom SAP BW nicht mehr genutzt wird.
Wer sich die Views anschauen möchte, sollte dies am besten via SAP HANA Studio erledigen, da das ABAP DDIC nicht sofort aktualisiert wird. Deshalb sind etwaige Anpassungen dort nicht direkt sichtbar.
Das Beispiel zeigt den Reporting View eines ADSO mit allen Info-Objekten als Schlüssel (vormals InfoCube genannt).
Wer ist b.telligent?
Du willst den IoT Core durch eine Multi-Cloud-Lösung ersetzen und die Vorteile weiterer IoT-Services von Azure oder Amazon Web Services nutzen? Dann melde Dich bei uns und wir unterstützen Dich bei der Umsetzung mit unserer Expertise und dem b.telligent Partnernetzwerk.
Exasol ist ein führender Hersteller von analytischen Datenbanksystemen. Das Kernprodukt ist eine auf In-Memory-Technologie basierende Software für die professionelle, parallele und schnelle Datenanalyse. Normalerweise werden SQL-Statements in einem SQL-Skript sequenziell abgearbeitet. Wie können aber mehrere Statements gleichzeitig ausgeführt werden? Dies zeigen wir anhand eines einfachen Skripts in diesem Blogbeitrag.
Viele Unternehmen mit SAP-Quellsystemen kennen diese Herausforderung: Sie wollen ihre Daten in einen Azure Data Lake integrieren, um sie dort mit Daten aus anderen Quellsystemen und Applikationen für Reporting und Advanced Analytics weiterzuverarbeiten. Auch die neuen SAP-Informationen zur Nutzung des SAP-ODP-Frameworks führten bei b.telligent Kunden zu Fragen. In diesem Blogbeitrag stellen wir drei gute Ansätze zur Datenintegration (in die Microsoft Azure Cloud) vor, die wir bei b.telligent empfehlen und die von der SAP unterstützt werden.
In Teil 1 fassen wir die Anforderungen der Kunden zusammen.
Viele Unternehmen entscheiden sich im Rahmen ihrer aktuellen Modernisierung- und Digitalisierungsinitiativen, ihr Datawarehouse (DWH) oder auch ihre Datenplattform in die Cloud zu heben. Dieser Beitrag diskutiert aus fachlicher/organisatorischer Sicht, welche Aspekte dafür besonders wichtig sind und welche Strategien dabei helfen, etwaige Risiken zu minimieren. Eine Migration sollte nicht als rein technische Übung verstanden werden. "Weiche" Faktoren und Fachlichkeit haben einen deutlich höheren Einfluss.