Partnerschaft mit SAP

Die SAP Data Warehouse Cloud bietet Nutzer:innen neue Wege, um Daten im Unternehmen zu verarbeiten und zu nutzen. Mit der „SAP BW Bridge for SAP Data Warehouse Cloud“ wird es Kund:innen mit einem On-Premise-SAP-BW nun erleichtert, den Schritt in die Cloud zu gehen. Wir zeigen Dir hier, was die BW Bridge ausmacht und wodurch sie Dich auf der Reise in die Cloud unterstützt!

Wenn Du Dich für die SAP Analytics Cloud entscheidest, wirst du schnell mit der Frage konfrontiert sein, welche Fähigkeiten Benutzer:innen zur Verfügung gestellt werden sollen. Die Antwort darauf wird im Betriebskonzept festgehalten. Wir zeigen Dir hier, was dabei zu beachten ist!

Bei der Auswahl des Verbindungstyps sind verschiedene Aspekte zu beachten. Erfahre hier, welche dies sind und welche Szenarien mit den jeweiligen Verbindungen abgedeckt werden können!

Mit der Entscheidung für die SAP Analytics Cloud (SAC) setzt Du auf eine innovative, flexible und performante Cloud-Lösung für Dein Unternehmen. Der nächste Schritt ist nun die Auswahl der zu Deinem Anwendungsfall passenden Analyse- und Visualisierungsmethode. Wir geben Dir einen Einblick in beide Entwicklungsumgebungen der SAC!

SAP BW stellt als Business-Intelligence-Paket viele Möglichkeiten für ein performantes Reporting bereit – birgt jedoch auch zahlreiche Hemmnisse, die die Performance merklich verlangsamen. Am Beispiel von in der Anwendung verfügbaren Berichtsfiltern zeigt dieser Beitrag, wie kleinste Adaptionen die Leistung von SAP BW mindern und wie eine performante Einstellung der Filtermöglichkeiten zu besseren Ergebnissen führen kann.

In den vergangenen Jahren gab es immer wieder Nachrichten und Gerüchte über die Zukunft von SAP BusinessObjects.

Mittlerweile gibt es interessante Neuigkeiten!

Aktuelles zu SAP BusinessObjects BI 4.2 SP07

Am 04.03.2019 hat SAP das Support Package 07 für die „SAP BusinessObjects Business Intelligence Platform 4.2“ (SBOP BI 4.2) veröffentlicht. Dabei handelt es sich laut Aussage von SAP um das letzte Feature Pack für das Release 4.2. Ein Support Package 08 ist zwar geplant, wird aber ein reines Maintenance Release darstellen, das „nur“ Bugfixes und keine neuen Funktionserweiterungen beinhaltet.

Ausnahmeaggregationen waren vor HANA in SAP BW häufiger eine Herausforderung bei der Laufzeit; dazu gehörte auch die Distinct-Count-Operation. Diese wird zum Beispiel beim Zählen von Kunden aus den Aufträgen genutzt.

Früher wurden Distinct-Count-Operationen häufig folgendermaßen umgesetzt:  Es wurde eine berechnete Kennzahl mit dem Wert 1 angelegt und diese dann über eine Ausnahmeaggregation aufsummiert. Was in Umgebungen ohne HANA gut geklappt hat, führt aktuell jedoch dazu, dass der Pushdown nicht mehr funktioniert. Je nach Einstellung kann es also dazu kommen, dass die Berechnung nicht optimal durchgeführt wird.

Eine Lösung für HANA-Umgebungen muss also her: Konzentrieren wir uns daher im Weiteren auf die optimale Implementierung von Distinct Count mit BW on HANA oder BW/4HANA.

Noch einmal möchte ich mich mit dem Thema Speichernutzung auseinandersetzen. In anderen Blogartikeln wie „SAP HANA – kein Speicher mehr? Bewusster Early Unload!“ ist bereits die Relevanz der korrekten Einstellung der SAP-BW-Objekte für die vorgesehene Nutzung aufgezeigt worden. Zusammengefasst: Immer alles frühzeitig aus dem Speicher schieben, was nicht immer und sofort für Abfragen benötigt wird. Gesteuert wird dies über die „Early Unload Priority“, die in der HANA-Datenbank auf Tabellenebene gesetzt wird. Da diese Einstellungen nicht im ABAP-Transportwesen (CTS) enthalten sind, muss der Entwickler oder der Betrieb sicherstellen, dass diese Einstellung immer korrekt gesetzt ist. Ansonsten liegen nur für das Staging benötigte Daten aus dem „Data Acquisition Layer“ sehr performant im RAM, was unnötig teuer ist und das System belastet.

Optimierte Hauptspeichernutzung bei SAP BW on HANA

Die Ausnutzung des Hauptspeichers ist bei SAP-HANA- und Data-Warehouse-Szenarien immer ein spannendes Thema im Vergleich zu ERP-Anwendungen bzw. Anwendungen mit einem sich gering verändernden Datenvolumen. Somit muss man eines im Hinterkopf behalten: Lasse niemals den freien Hauptspeicher ausgehen.

Mit der Einführung von SAP BW on HANA im Jahre 2010 wurden viele bisherigen Maßnahmen zur Performancesteigerung in BW-Systemen obsolet; gleichzeitig drängen sich aber viele neuen Fragen bezüglich der neuartigen Plattform auf. Von großer Relevanz ist dabei auch die Frage, ob es immer noch sinnvoll ist, die sogenannten "Advanced Business Application Programming-Routinen" zu cachen. Denn mit HANA werden die Daten einerseits in der unter einem Applikationsserver liegenden Datenbank im Hauptspeicher abgelegt und andererseits für Abfragen optimiert. Hinzu kommt, dass die Abfragen in Routinen systembedingt auf dem Applikationsserver ausgeführt werden. Die Frage nach der Sinnhaftigkeit der Nutzung eines Caches für ABAP-Routine-Abfragen soll deshalb im nachfolgenden Blogbeitrag eingehend erläutert werden:

Bei häufig wiederkehrenden Daten lässt sich dies grundsätzlich bejahen. Denn wenn beispielsweise das Attribut "Kontinent" von dem Info-Objekt "Land" hinzugelesen werden soll, ist der zeitliche Overhead eines Zugriffs durch den SQL Parser, das Netzwerk, etc. auf HANA wiederkehrend für jede Zeile zu hoch. Zwischen dem ABAP-Programm und den eigentlichen Daten liegen etliche technische Layer, welche damit wiederholend ausgeführt werden. Ist es jedoch notwendig, mehrere Joins zwischen Tabellen durchzuführen oder ist die Anzahl der zu lesenden Zeilen sehr groß, kippt der Vorteil wieder in Richtung der HANA-Datenbank.

Nach meinen Erfahrungen bei Kunden mit großen Datenmengen beschleunigt ein Cache im ABAP die DTP-Ausführung in einem SAP BW on HANA System teils um den Faktor 3. Dies ist natürlich immer abhängig von der Situation (z.B. Datenverteilung, Homogenität der Daten etc.), sowie von der aufgebauten Infrastruktur. Alles noch ohne Einsatz des Shared Memory. Dieser führt für alle Datenpakete zusammen, also pro Beladung, nur eine Abfrage auf die Datenbank aus. Im Handling ist dieser aber unnötig kompliziert.