Die Geschichte des SAP BW

Hallo zusammen,

im Rahmen unserer BW/4HANA-Aktivitäten sind wir in die Archive gestiegen und haben versucht die Geschichte das SAP BW darzustellen. Herausgekommen ist diese Infografik von den Anfängen des BW 1.2 bis heute.

Wir haben den Weg nicht nur recherchiert, sondern wir sind den ganzen Weg gegangen. Gerne unterhalten wir uns mit Euch über die Entwicklung des SAP BW und über die aktuellsten Migrations-Strategien!

Geschichte des SAP BW

Autor dieses Beitrags
Jörg Waldenmayer Lead Consultant
Tel.: +49 (0) 7031 714 660 0
E-Mail: info@inspiricon.de
inspiricon_performance-optimierung-sap-bw-ladevorgaenge

Performance-Optimierung von SAP BW Ladevorgängen durch Verwendung mehrdimensionaler interner Tabellen

Es kann bei der Beladung von Datenzielen in SAP BW zu langen Laufzeiten kommen, wenn große Datenmengen z.B. in Endroutinen prozessiert werden müssen. Unter Umständen treten Performanceprobleme erst einige Zeit nach Produktivstart bei wachsenden Datenvolumina auf, die zum Zeitpunkt der Entwicklung und in der Testphase so nicht zur Verfügung standen. In solchen Fällen ist es immer mit Risiken verbunden, wenn an einer produktiven Applikation Performanceoptimierungen vorgenommen werden müssen. Der nachfolgend beschriebene Lösungsansatz beschreibt eine Möglichkeit, die Verarbeitung größerer Datenmengen unter gewissen Voraussetzungen deutlich zu beschleunigen, ohne dass Änderungen an der ursprünglich implementierten Logik bzw. Verarbeitung vorgenommen werden müssen.

Aus der Praxis

Ein typisches Beispiel aus der Praxis ist die Ermittlung offener Lieferantenbestellungen. In einem unserer Kundenprojekte war gefordert, für offene Lieferantenbestellungen auf Positionsebene die Einteilungen sowie die Lieferantenbestätigungen und zugehörigen Wareneingänge zu verarbeiten und diese Informationen in Berichten zur Verfügung zu stellen. Ein großer Teil der Verarbeitungslogik war in der Endroutine einer Transformation implementiert, in welcher die Bestellpositionen verarbeiten wurden.

Mit Hilfe von Lookup Tabellen wurden die Einteilungen sowie die Lieferantenbestätigungen und Wareneingänge nachgelesen.  Diese Tabellen waren als Standard Tabellen definiert. Bei der Verarbeitung dieser Tabelleneinträge erfolgten die Berechnung der offenen, bestätigten und unbestätigten Bestellmengen sowie die Verrechnung von Wareneingängen bei Teilbelieferungen. Die Verarbeitung dieser Lookup Tabellen erfolgte in geschachtelten Loops im Rahmen eines Loops über das RESULT_PACKAGE. Da sowohl das RESULT_PACKAGE als auch die Lookup Tabellen mehrere zehntausend Datensätze enthielten, war die Gesamtperformance der Verarbeitung entsprechend gering.

Die Abfrage der Lookup Tabellen erfolgte über komplexe WHERE Klauseln innerhalb mehrerer verschachtelter LOOP – ENDLOOP Schleifen. Tabellen vom TYP HASHED TABLE konnten deshalb nicht ohne weiteres verwendet werden.

Für ca. 400.000 Bestellpositionen betrug die Gesamtlaufzeit der Verarbeitung ca. 90 Minuten.

Die Verwendung sortierter Tabellen führte zu nur zu geringfügigen Verbesserungen der Performance.

Dazu ein Beispiel aus der Verarbeitung:

1_inspiricon_sortierte-tabellen

Das Laufzeitproblem konnte mit Hilfe mehrdimensionaler interner Tabellen gelöst werden. Man definiert dabei eine HASH Tabelle deren Schlüssel mit „TABLE KEY“ performant gelesen werden kann. Im vorliegenden Fall bestand der Schlüssel aus der Nummer des Einkaufsbeleges und der Belegposition. Neben dem Schlüssel enthält die Tabelle an der Stelle eines weiteren Feldes eine zusätzliche interne Tabelle, welche derjenigen aus Abbildung 1 entspricht (it_eemmo06).

2_inspiricon-mehrdimensionale-interne-tabelle

Vorbereitung der Daten

Die Befüllung der ursprünglichen internen Tabelle bleibt unverändert und findet vor dem Loop über die RESULT_PACKAGE statt:

3_inspiricon-result-package

Im Anschluss werden die Daten in die HASH Tabelle übertragen und die ursprüngliche Tabelle gelöscht:

4_inspiricon-hash-tabelle

Verarbeitung der Daten

In der folgenden Verarbeitung wird die Originaltabelle für die Verarbeitung nur noch mit den aktuell benötigten Datensätzen befüllt:

5_inspiricon-datenverarbeitung

Die Verarbeitung der Originaltabelle bleibt unverändert:

6_inspiricon_verarbeitung-originaltabelle

Sie enthält jetzt nur noch diejenigen Datensätze, welche für den aktuellen Verarbeitungsschritt benötigt werden. Im vorliegenden Beispiel sind das die Einteilungen, Wareneingänge sowie die Lieferantenbestätigungen. Da die interne Tabelle nur noch sehr wenige Datensätze enthält, ist die Verarbeitung im Loop entsprechend performant.

Was bringt diese Lösung?

Ein Vorteil dieser Lösung besteht darin, dass an den bereits vorhandenen internen Tabellen und der verwendeten Logik in den WHERE Klauseln keinerlei Änderungen vorgenommen werden müssen. Der Aufwand für den Aufbau der HASH Tabelle fällt für die Gesamtlaufzeit kaum ins Gewicht. Die Lösung kann mit geringem Risiko zur Optimierung der Laufzeit bestehender Applikationen verwendet werden, da der Kern der Verarbeitungslogik unverändert bleibt und lediglich die Datenbereitstellung optimiert.

Das beschriebene Vorgehen empfiehlt sich also beispielsweise bei Applikationen, die schon sich schon seit längerer Zeit im Produktivbetrieb befinden und wegen wachsender Datenmengen an Laufzeitgrenzen stoßen.

Im oben erwähnten Beispiel, der Verarbeitung von Einkaufsbelegen, konnte die Gesamtlaufzeit der Verarbeitung von ca. 90 Minuten auf ca. 15 Minuten reduziert werden.

Quellenangabe der Bilder: Inspiricon AG

Autor dieses Beitrags
Oskar Glaser Lead Consultant BI Reporting
Tel.: +49 (0) 7031 714 660 0
E-Mail: info@inspiricon.de

 

Klassische DataStore Objekte

Klassische DataStore-Objekte vs. Advanced DataStore-Objekte

Mit SAP BW/4HANA gab es auf Architekturebene viele Änderungen, so zum Beispiel bei der Datenmodellierung.

In diesem Artikel beschäftigen wir uns mit den verschiedenen Funktionen und Möglichkeiten von ADSOs und zeigen dir zudem, wie sie dir dabei helfen können, verschiedene Aufgaben in deiner SAP BW-Umgebung zu optimieren.

Werfen wir aber zuerst einen Blick auf die klassischen DSOs und ihre Funktionen. Danach zeige ich dir noch die Unterschiede zwischen klassischen DSOs und den neu eingeführten ADSOs.

DSO (DataStore Object)

Was ist ein DSO?

Ein DSO ist eine zweidimensionale Speichereinheit, in der hauptsächlich Transaktionsdaten oder Stammdaten mit niedrigster Granularität gespeichert werden. Die Daten werden also mit einem hohen Detailgrad gespeichert.

DSO-Typen

Beim Anlegen eines DSOs musst du zunächst den Typ auswählen:

dso

Wenn wir ein DSO anlegen, legt das System standardmäßig eine System ID über die Option „Erzeugung von SIDs bei Aktivierung“ fest, die du in den Bearbeitungseinstellungen eines DSOs findest. Wird diese Option aktiviert, prüft das System die SID-Werte für alle Merkmale im DSO. Falls es keinen SID-Wert für ein Merkmal gibt, generiert das System die SID. Durch die Erzeugung der SIDs bei Aktivierung wird die Laufzeitperformance der Abfrage verbessert, da die SIDs nicht zur Laufzeit der Abfrage generiert werden müssen. SID-Werte werden grundsätzlich in der SID-Tabelle eines InfoObjects gespeichert. Über die SID wird auf die Attribute und Texte eines Stammdaten-InfoObjects zugegriffen. Die SID-Tabelle ist über den char key mit den dazugehörigen Stammdatentabellen verbunden.

In der folgenden Tabelle findest du eine Übersicht über die Eigenschaften der verschiedenen DSO-Typen und Architekturen:

table DSO types

ADSO (Advanced DataStore Object)

Das Advanced DSO ist in der Lage, all diese Objekte zu ersetzen.

 BW4HANA Modeling Objects

Bevor wir ein ADSO anlegen, müssen wir wissen, dass es 3 Haupttabellen umfasst:

  • Inbound Table
    • Tabelle der Aktivierungs-Queue bei klassischen DSOs
    • Nicht komprimierte Faktentabelle eines nicht-SAP-HANA-optimierten InfoCubes
    • Alle Sätze werden mit einem technischen Schlüssel gespeichert.
  • Tabelle der aktiven Daten
    • Enthält ebenso wie beim klassischen DSO die aktuellen Werte nach Aktivierung. Der Schlüssel der Tabelle ist der DSO-Schlüssel (auf Schlüssel werden wir noch näher eingehen).
    • Komprimierte Faktentabelle eines nicht-SAP-HANA-optimierten InfoCubes.
  • Change Log
    • Entspricht dem eines klassischen DSO.
    • Speichert die Unterschiede zwischen dem Inbound Table und der Tabelle der aktiven Daten.
    • Wird für die Delta-Erstellung benötigt.

Wichtige Schritte beim Anlegen eines ADSO

  • Ein ADSO wird in den BWMT in Eclipse wie jedes andere neue Objekt angelegt (in BW 7.5 besteht die Möglichkeit, auch weiterhin die klassischen Objekte im SAP GUI anzulegen, wohingegen in BW4/HANA nur noch die neuen Objekte in den BWMT angelegt werden können).
  • Auf der Registerkarte „General“ kannst du die Aktivierungseinstellungen und weitere Eigenschaften festlegen. Zunächst muss hier eine Beschreibung angegeben werden. Im Anschluss können wir unter „Model Template“ eine Vorlage auswählen. Dabei kann sich ein ADSO wie je eines der 4 Objekte im klassischen BW verhalten.

template

Acquisition-Schicht

In dieser Schicht lassen sich Objekte für die „schreiboptimierten“ Anwendungsfälle klassischer DSOs anlegen. Sie besteht aus 3 Schichten:

  1. Data-Acquisition-Schicht
    • Entspricht einer Persistent Staging Area (PSA) und dient als Eingangsablage im BW für Daten aus den Quellsystemen.
    • Keine Verwendung der aktiven Tabelle, daher ist eine Aktivierung nicht erforderlich.
    • Requests werden in die Inbound Table geladen und daraus extrahiert.
    • Alle Sätze in der Inbound Table enthalten eine Request-TSN, Datenpaket und Datensatznummer.
    • Auf die Inbound Table (ehemals Tabelle der neuen Daten / Aktivierungs-Queue) wird zum Ausführen einer BEx Query und zur Extraktion zugegriffen.
    • Daten werden nicht aggregiert.
  2. Corporate Memory mit Schwerpunkt auf Kompression
    • Requests werden auch weiterhin in die Inbound Table geladen.
    • Auf Detail-Level nicht mehr benötigte alte Requests können in die Tabelle der aktiven Daten komprimiert werden.
    • Um Speicherplatz zu sparen wird beim CM Compression ADSO auf eine Change-Log-Tabelle verzichtet, es gibt nur eine Inbound Table und eine Tabelle der aktiven Daten.
    • Wird ein Laderequests aktiviert, werden die Daten in die aktive Tabelle geladen und aus der Inbound Table gelöscht.
    • Gibt es 2 Sätze mit dem gleichen Schlüssel, überschreibt BW/4HANA alle Merkmale des Satzes mit denen des zuletzt geladenen Satzes.
  3. Corporate Memory mit Schwerpunkt auf Reporting
    • Der Unterschied zwischen dieser Vorlage und der Vorlage für die „Corporate Memory mit Schwerpunkt auf Kompression“ liegt darin, dass die Daten aus der Inbound Tabelle nicht gelöscht werden. Die Daten bleiben also in der Inbound Table, um zu verhindern, dass technische Informationen verloren gehen.
    • Die Vorlage für CM mit Schwerpunkt auf Reporting verfügt jedoch über keinen Change Log.
    • Ein weiterer Unterschied liegt darin, dass die Daten nicht aus der aktiven Tabelle, sondern aus der Inbound Table extrahiert werden.
    • Da die Daten nach der Aktivierung in der Inbound Table verbleiben, sind diese ADSOs sehr gut geeignet, wenn du zwar Daten speichern möchtest, durch den Wegfall des Change Log aber Speicherplatz eingespart werden soll.

Propagation-Schicht

  • Bildet die Grundlage für die weitere Verteilung und Weiterverwendung der Daten.
  • Entspricht einem Standard-DataStore-Objekt (klassisch).
  • Requests werden auch in die Inbound Table geladen.
  • Für das Reporting muss der Benutzer die geladenen Requests aktivieren.
  • Die Daten werden dann in die Tabelle der aktiven Daten übertragen und das Delta wird im Change Log gespeichert.
  • Das Change Log wird auch für den Rollback bereits aktivierter Requests genutzt.

Reporting-Schicht

  • Dient der Ausführung von Queries zur Analyse.
  • Entspricht einem Standard-InfoCube.
  • Die Inbound Table entspricht der F-Tabelle und die Tabelle der aktiven Daten der E-Tabelle.
  • Es gibt keinen Change Log. Ohne die Change-Log-Tabelle kann der Deltaprozess nicht erfolgen.
  • Nach der Aktivierung ist die Inbound Table leer.
  • Das Reporting erfolgt auf einer Union der beiden Tabellen Inbound Table und aktive Tabelle.

Planungs-Schicht

Sie ist in 2 weitere Schichten aufgeteilt:

  1. Planning on Direct Update
    • Die Daten werden automatisch in die aktive Tabelle geladen, eine Aktivierung ist also nicht erforderlich.
    • Es gibt keinen Change Log und keine Inbound Table.
    • Das Befüllen der aktiven Tabelle kann über eine API erfolgen.
    • Bei diesem ADSO-Typ können Daten können auch über den Datentransferprozess (DTP) geladen werden.
    • Es steht nur die Option Überschreiben zur Verfügung. Keine Summation von Kennzahlen wie beim Planning on Cube-like ADSO.
  2. Planning on Cube-like
    • Es gibt eine Inbound Table und eine aktive Tabelle.
    • Alle Merkmalsfelder sind in der aktiven Tabelle als Schlüsselfelder markiert, was eine Voraussetzung für die Planungseignung ist.
    • Es steht nur die Option Summation zur Verfügung.

Der Prozess der für HANA hoch-optimierten SID-Erzeugung

Zum Zwecke der Leistungsoptimierung ist es in BW/4HANA möglich, Kennzeichen sowohl auf InfoProvider-Ebene als auch einzeln für jedes Merkmal des DSOs zu setzen. Die Prüfung der Datenintegrität erfolgt dann nur für das ausgewählte Merkmal.

InfoObjects/Felder

Als neue Funktion ist es jetzt auch möglich, Felder mit einfachen Datentypen anstelle von InfoObjects zu verwenden. Wähle dazu die Registerkarte „Details“ aus und klicke auf „Add Field“. Unter „Identify with:“ kannst du über das Auswahlmenü festlegen, ob du für die Definition ein InfoObject oder ein Feld verwenden möchtest.

infoObject

In BW kann der Benutzer entscheiden, ob die Modellierung mit InfoObjects oder Feldern erfolgen soll. Das Modellieren von InfoObjects bedeutet zwar einen zusätzlichen Aufwand, andererseits bieten InfoObjects aber auch viele Vorteile. Bevor du dich also für eine dieser Modellierungsoptionen entscheidest, solltest du die jeweiligen Vor- und Nachteile genauesten abwägen.

Im Folgenden gehe ich daher ein wenig auf eben diese Vor- und Nachteile beim Modellieren mit Feldern ein:

Die Vorteile von Feldern

  • Wenn Felder in der Query enthalten sind, kann diese schlüsselbasiert in SAP HANA verarbeitet werden.
  • Wenn kleinere Datenvolumen verarbeitet werden, kann durch die Verwendung von Feldern die Flexibilität und Reichweite des Data Warehouse erhöht werden.

Die Nachteile von Feldern

  • Die Services der InfoObjects (so zum Beispiel Attribute und Hierarchien) stehen für Felder nicht zur Verfügung.
  • Die Gültigkeitsmerkmale bei DataStore-Objekten (advanced) mit Bestandskennzahlen müssen InfoObjects sein.
  • Die InfoObject-Attribute müssen InfoObjects sein.
  • Eine feldbasierte Kennzahl kann keine Ausnahmeaggregation haben.
  • Planungs-Queries auf DataStore-Objekten (advanced) werden mit Feldern nur lesend unterstützt.
  • Wenn Felder in der Query verwendet werden, können die InfoProvider nur sequentiell gelesen werden.
  • In der Query auf einem CompositeProvider werden nicht alle Datentypen für Felder unterstützt (z. B. dürfen Felder nicht länger als 20 Zeichen sein).

Definition von Schlüsseln für ein ADSO

  • In dieser Registerkarte wählen wir auch aus, welche Felder für die Schlüssel unseres ADSO verwendet werden. Klicke zur Definition eines Schlüssels auf „Manage Keys“.

fields adso

Schlüsselfelder

Es gibt 2 Schlüsseltypen: Primärschlüssel und Fremdschlüssel.

Die Vorteile von Schlüsselfeldern:

  • Eindeutige Identifikation eines Satzes in einer Tabelle.
  • Schlüsselfelder können nicht NULL sein.
  • Dient der Verbindung zweier Tabellen.
  • Hauptzweck eines Fremdschlüssels ist die Datenvalidierung.
  • Stammdatennachlesen: Durch die Verwendung des Wertes des Eingabefelds als Schlüssel kannst du das zu einem angegebenen Merkmal zugehörige Attribut des Merkmals auslesen.
  • Auslesen aus dem Advanced DataStore: Durch die Verwendung des/der Werte(s) des Eingabefelds als (geklammerter) Schlüssel, kannst du die Datenfelder eines angegebenen Advanced DataStore-Objekts (ADSO) auslesen.
  • Du möchtest auf jeden Fall vermeiden, dass BW/4HANA für 2 Sätze mit dem gleichen Schlüssel alle Merkmale des Satzes mit denen des zuletzt geladenen Satzes überschreibt.

Die Nachteile beim Verzicht auf Schlüsselfelder:

  • Sätze werden nicht eindeutig identifiziert => so besteht die Möglichkeit doppelter Sätze.
  • Die Performance wird beeinträchtigt.

Die Vorteile des Einsatzes von ADSOs anstelle von klassischen DSOs:

  • Vereinfachung von Objekttypen
    • Kann sich wie 4 Objekte im klassischen BW verhalten.
  • Flexibilität bei der Datenmodellierung
    • Modellierung deines ADSOs über die Einstellungen der Reporting-Schicht.
  • Performance beim Datenladen und der Aktivierung ist HANA-optimiert, da es sich bei ADSOs um native HANA-Objekte handelt.

Quellenangabe der Bilder: SAP SE, Inspiricon AG

Autor dieses Beitrags
Roxana Hategan Associate
Tel.: +49 (0) 7031 714 660 0
E-Mail: cluj@inspiricon.de
inspiricon unterschiede sap bw und bw4hana

Die Unterschiede in der Datenmodellierung mit SAP BW und SAP BW/4HANA

Wir studieren die Vergangenheit, um die Gegenwart zu verstehen.“  – William Lund

Aktuell häufen sich die Fragen unserer Kunden zum Thema BW 7.5 und BW4/HANA. Grund genug für uns hier eine Serie von Blogartikeln zu starten, um diese Themen zu beleuchten. Wir beginnen damit, die Entwicklung des SAP BW zu beleuchten und schauen uns anschließend an, welche Themen-Bereiche wir in den nächsten Wochen näher untersuchen.

In diesem Artikel steht SAP BW für die Vergangenheit und SAP BW/4HANA für die Zukunft der Datenmodellierung.

Die meisten Unternehmen und auch die Anwender sind sich immer noch nicht im Klaren darüber, wo genau die Unterschiede zwischen SAP BW (der alte Modellierungsansatz) und SAP BW/4HANA liegen. Mit diesem Artikel möchten wir die Dinge ins rechte Licht rücken und klare Antworten liefern.

Eine kurze Geschichte von SAP BW

Kurze Geschichte des SAP BW

 

Wo liegen die Unterschiede zwischen SAP BW und SAP BW/4HANA?

Eines der Hauptziele der SAP liegt in der Vereinfachung des Systems. Dementsprechend werden Objekte und Prozesse zusammengefasst und die Anzahl der Schritte reduziert.

a) Modellierungsobjekte

Ein schneller Vergleich der Modellierungsobjekte in der klassischen SAP-BW-Anwendung und der Objekte in SAP BW/4HANA machen vielleicht am ehesten deutlich, in welchem Ausmaß die Modellierung vereinfacht wurde.

sap_classic-sap-bw_sap-bw4hana_objects

Wir werden euch in den folgenden Artikeln die neuen Provider vorstellen, angefangen mit den ADSOs.

b) Datenflüsse

Der zentrale Einstiegspunt für die Datenmodellierung in SAP BW/4HANA ist der Datenfluss. Hier wird definiert, welche Objekte und Prozesse zur Übertragung der Daten von der Quelle an SAP BW/4HANA sowie zur Bereinigung, Konsolidierung und Integration der Daten benötigt werden, damit diese für Analyse- und Reporting-Zwecke zur Verfügung stehen. SAP BW∕4HANA setzt auf eine neue integrierte Schichtenarchitektur (Layered Scalable Architecture – LSA++).

Das klassische SAP BW verwendet LSA, die Vorgängerverion von LSA++. Diese Schicht ist restriktiver und bietet weniger Flexibilität im Umgang mit den Daten.

vergleich sap bw und bw4hana

 

Durch den Einsatz von LSA++ wird vor allem die Anzahl der Persistenzschichten reduziert. Das hat zwei Effekte:

  1. Zum einen wird dadurch die Performance der Datenverarbeitung erhöht: man muss weniger speichern und aktivieren und spart so Zeit!
  2. Und zum anderen wird dadurch das Datenvolumen reduziert. Wurde früher durch den gewollten Einsatz von Redundanzen im BW-System die Lese-Performance optimiert und Speicherplatz nicht als kritischer Faktor gesehen, so ändert sich das durch den Einsatz von HANA grundlegend. Hauptspeicher ist teurer, sowohl in der Hardware verglichen mit Festplattenspeicher, als auch in der Lizenzierung, da HANA nach Hauptspeicher lizenziert wird. Außerdem wird das System durch weniger „physische“ Schichten auch flexibler in der Ausgestaltung.

c) Quellsysteme

Auch im Bereich der Quellsysteme treibt die SAP den Ansatz der Vereinfachung voran.

SAP BW∕4HANA bietet flexible Möglichkeiten zur Integration von Daten aus verschiedensten Quellen. Die Daten können aus dem Quellsystemen extrahiert und umgewandelt und in das SAP-BW-System geladen werden. Es ist aber auch möglich, zu Analyse- und Reporting-Zwecken direkt auf die Daten im Quellsystem zuzugreifen, ohne diese im Enterprise Data Warehouse physisch ablegen zu müssen.

sap-bw4hana-simplified-source-systems

  1. SAP-HANA-Quellsystem
    • diese Konnektivität lässt sich für alle anderen Datenbanken nutzen (z. B. Teradata, Sybase IQ, Sybase ASE).
  2. SAP Operational Data Provisioning (ODP)
    • dient als Datendrehscheibe für alle Daten, die über externe Quellen in das BW-System einfließen
    • wird ausschließlich mit SAP Landscape Transformation (SLT), SAP ERP Extractor (SAP Business Suite), HANA Views und SAP BW eingesetzt

Das neue ODP-Konzept mit seiner wesentlich schnelleren Datenextraktion macht die PSA überflüssig.

Mit diesen beiden Verbindungstypen können Daten durch Real-Time-Replikation oder direkten Zugriff im Batch-Modus verfügbar gemacht werden.

Die HANA-Views werden nach Aktivierung der Objekte (z. B. ADSO, Composite Provider) automatisch in der SAP-HANA-Datenbank generiert.

d)  Leistung

Durch den Einsatz von HANA kann die Geschwindigkeit der Datenverarbeitung, wie unter LSA++ schon beschrieben, gesteigert werden. Ging es bei den Datenflüssen noch um eine schlankere Architektur, gibt es natürlich auch handfeste technische Performance-Gewinne:

Neben dem klassischen SAP BW bietet SAP BW/4HANA zudem In-Memory-Data-Warehousing:

  • Keine Aggregate oder Rollup-Prozesse
  • Keine performance-spezifischen Objekte
  • Weniger Indizes
  • Schnelleres Laden und Verarbeiten von Daten
  • Ebenfalls in diese Richtung geht die Möglichkeit Transformationen direkt auf die Datenbank zu verlagern, die SAP spricht hierbei von Push-Down. Diese Leistungssteigerung in SAP BW/4HANA wird durch einen Algorithmus-Pushdown sichergestellt:

sap-bw4hana_algorithm-push-down

Auch auf dieses Thema werden wir in einem der folgenden Artikel im Detail eingehen.

Quellenangabe der Bilder: SAP SE, Inspiricon AG

Autor dieses Beitrags
Roxana Hategan Associate
Tel.: +49 (0) 7031 714 660 0
E-Mail: cluj@inspiricon.de
SAP BusinessObjects

SAP BusinessObjects – so wählst du das richtige Client-Tool aus

Stellst Du Dir auch die Frage, welches BusinessObjects Tool Deinen Anforderungen am meisten genügt? In diesem Beitrag möchten wir das Thema grob anreißen und Dir einige Tipps mit auf den Weg geben.

SAP BusinessObjects Front-End Palette

In den letzten Jahren hat SAP ihre BusinessObjects Front-End Palette sehr stark vereinfacht – wie man dem folgenden Schaubild entnehmen kann:

Abb. 1: SAP BusinessObjects Front-End Palette

Die Auswahl des richtigen Werkzeugs ist mittlerweile um einiges einfacher geworden. So gibt es die Wahl zwischen drei Kategorien:

  1. Data Discovery & Applications
  2. Office Integration
  3. Reporting

Diese unterscheiden sich grob anhand der Ausprägung an Interaktivität, Standardisierung und Visualisierung.

Was aber alle drei Kategorien miteinander verbindet, ist die gegebene Interoperabilität, sodass die erstellten Inhalte unter den einzelnen Tools weiterverwendet werden können. Das wären beispielsweise:

  • Lumira 2.0 Discovery Dateien (ehem. Lumira 1.x), welche in Lumira 2.0 Designer (ehem. Design Studio 1.x) mit zusätzlichen Scripts ergänzt werden können.
  • Oder in umgekehrter Reihenfolge die Verwendung von Designer Applikationen in Discovery u.a. für die Erstellung von Story Boards.
  • Das Aufrufen von parametrisierten Crystal Reports oder Web Intelligence Berichten aus den jeweiligen Tools ist weiterhin möglich und findet auch vielfach Verwendung.
  • u.a.

Nichtsdestotrotz fragen sich die Mitarbeiter in den Fachabteilungen und das Management in den Unternehmen, welches Front-End Tool für Ihre Auswertungen und Analysen am besten geeignet ist.

Dabei gibt es insbesondere zwei Situationen, in denen die Frage nach dem richtigen Tool beantwortet werden muss:

  1. Wenn die bisher produktiv eingesetzten Frontend-Tools bestimmte neue Anforderungen nicht mehr abdecken können und deshalb die verbleibenden SAP BusinessObjects-Tools dafür geprüft werden
  2. Wenn in einem Unternehmen SAP BusinessObjects komplett neu eingeführt wird

Werden an dieser Stelle nicht die passenden Tools ausgewählt, kann dies nicht nur zu geringerer Akzeptanz bei den Endnutzern, sondern meist auch zu längeren Implementierungszeiten führen. Der richtigen Toolauswahl fällt somit ein hoher Stellenwert zu.

Phasen der Auswahl

Der Auswahlprozess durchläuft im Idealfall verschiedene Phasen. In folgender Grafiksind diese veranschaulicht:

inspiricon-auswahlphasen-client-tool

Abb. 2: Phasen der Toolauswahl

Grob zusammengefasst:
es muss zum einen geklärt werden, wer der eigentliche Konsument der Berichte/Applikationen ist. Ein Manager hat meist deutlich andere Anforderungen an Inhalte und Darstellung wie z.B. ein Business Analyst und ist meist mehr an aggregierten, statischen und visuell anspruchsvolleren Daten interessiert. Darüber hinaus hat ein Manager weniger Zeit die Daten im Detail zu analysieren und will Berichte oft vorberechnet und automatisiert mit einer Zusammenfassung erhalten.

Im nächsten Schritt werden verschiedene Use Cases definiert, die für die grundsätzlich unterschiedlichen Anforderungen an den Einsatz der Tools verstanden werden können. Die letzte Phase dient der Bewertung und Beobachtung der Werkzeuge im produktiven Betrieb.

Auswahlmethoden

Die oben genannten Anforderungen werden gesammelt und können anschließend in einen Entscheidungsbaum überführt werden. So ein Entscheidungsbaum könnte beispielsweise wie folgt aussehen:

inspiricon-auswahlmethoden-toolauswahl

Abb. 3: Entscheidungsbaum bei der Toolauswahl

Diese Methode hilft bei wenigen klaren sich gut unterscheidbaren Anforderungen – und bei wenigen Endanwendern. Ist die Anzahl der Nutzer und damit meist die der Nutzeranforderungen deutlich größer und vielfältiger, bietet sich das Verfahren an, mittels geführten standardisierten Nutzerbefragungen (Interviews) den Anforderungskatalog zu erarbeiten. Das könnte folgendermaßen aussehen:

  • Berichte und Analysen sollen im Browser oder Microsoft Office verfügbar sein
  • Nutzer sollen Ad-hoc neue Berechnungen erstellen / hinzufügen können
  • Nutzer sollen mit Hierarchien arbeiten können
  • Nutzer sollen mit Standard SAP BEx-Query Strukturen arbeiten können
  • Berichte und Analysen sollen sowohl online als auch offline genutzt werden können
  • Berichte und Analysen sollen per E-Mail versendet werden können
  • Nutzer sollen die Daten filtern können
  • Nutzer sollen selbst eigene Berichte erstellen oder bestehende anpassen können
  • Navigation innerhalb der Berichte soll möglich sein
  • Drill-Down Funktionalität soll ermöglicht werden
  • Berichte und Analysen sollen hoch formatiert sein
  • Informationen in den Berichten müssen hoch aggregiert sein
  • Berichte und Analysen müssen hohe visuelle Standards erfüllen
  • usw.

Nach der möglichst vollständigen Erfassung aller relevanten Anforderungen, werden diese gegen die Funktionen der unterschiedlichen SAP BusinessObjects-Tools abgeglichen. Dabei werden durch das Tool erfüllbare Anforderungen grün und nicht umsetzbare rot markiert.

Nachfolgend wird dies beispielhaft anhand Crystal Reports verdeutlicht:

  • Berichte und Analysen sollen im Browser oder Microsoft Office verfügbar sein
  • Nutzer sollen Ad-hoc neue Berechnungen erstellen / hinzufügen können
  • Nutzer sollen mit Hierarchien arbeiten können
  • Nutzer sollen mit Standard BEx-Query Strukturen arbeiten können
  • Berichte und Analysen sollen sowohl online als auch offline genutzt werden können
  • Berichte und Analysen sollen per E-Mail versendet werden können
  • Nutzer sollen die Daten filtern können
  • Nutzer sollen selbst eigene Berichte erstellen oder bestehende anpassen können
  • Navigation innerhalb der Berichte soll möglich sein
  • Drill-Down Funktionalität soll ermöglicht werden
  • Berichte und Analysen sollen hoch formatiert sein
  • Informationen in den Berichten müssen hoch aggregiert sein
  • Berichte und Analysen müssen hohe visuelle Standards erfüllen

Nachdem die Anforderungsprüfung für jedes der Tools durchgeführt wurde, kann anschließend das Tool mit den meisten grün markierten Anforderungen bestimmt werden.

Ein derartiger Anforderungskatalog kann noch weiter beliebig komplex z.B. pro Abteilung oder Nutzerkreis  verfeinert werden, sodass am Ende für jede spezifische Zielgruppe innerhalb des Unternehmens die passendsten Tools zur Verfügung stehen.

Oft wird dieses Verfahren – bei umfangreicherem Einsatz – in Form einer Funktionsmatrix (z.B. in MS Excel) abgebildet. Das schafft zu Beginn höhere Aufwände bei der Erstellung, stellt aber bei häufiger Verwendung ein standardisiertes und probates Mittel dar, mit hoher Wahrscheinlichkeit das richtige Tool auszuwählen, das die meisten Anforderungen abdeckt.

Fazit

Ungeachtet dessen, für welche Auswahlmethode man sich entscheidet, wird es am Ende selten eine 100%ige Übereinstimmung mit allen Anforderungen geben – die „eierlegende Wollmilchsau“ wird sich am Ende auch hier nicht finden. Ein guter Mix aus den verschiedenen SAP BusinessObjects-Tools ist auch durchaus wünschenswert, um auch die Stärken der einzelnen Tools bestmöglich auszuschöpfen.

Die vorgestellten Methoden dienen als beispielhafte Denkanstöße und sind nur grobe Verfahrensweisen. Im Detail kann eine kundenindividuelle detaillierte Analyse und Gegenüberstellung der Anforderungen in hohem Maße zur richtigen Auswahl des Tools führen.

Bist Du interessiert an einer Vertiefung des Themas oder benötigst Du eine individuelle Analyse, dann kontaktiere uns. Wir werden Dich gerne dabei unterstützen.

Autor dieses Beitrags
Artur Witzke Senior Consultant
Tel.: +49 (0) 7031 714 660 0
E-Mail: info@inspiricon.de
Wer braucht schon SAP Vora?!

Wer braucht schon SAP Vora?!

Für was benötige ich überhaupt SAP Vora?

SAP Vora bietet die Möglichkeit, strukturierte und semi-strukturierte Daten innerhalb eines existierenden Hadoop-Clusters über eine moderne Oberfläche auszuwerten und diese untereinander sowie mit Daten aus SAP HANA zu kombinieren.

Es handelt sich hierbei technisch gesehen um eine Erweiterung des Apache Spark Execution Framework, das sich schon seit Längerem in der Hadoop-Welt etabliert hat.

SAP Vora realisiert somit eine verteilte In-Memory Abfrage-Engine für strukturierte und semi-strukturierte Daten in einem Hadoop-Cluster.

Wie kann ich SAP Vora nutzen?

Es gibt mehrere Optionen, wie ihr SAP Vora einsetzen könnt; natürlich empfiehlt SAP bevorzugt die Nutzung in der Cloud – entsprechend der eigenen Cloud-Strategie:

On-Premise:

Cloud-basiert:

  • Nutzung der für SAP Partner kostenfreien Developer Edition über Amazon Web Services (AWS) oder SAP Cloud Appliance Library (SAP CAL)
  • Nutzung der kostenpflichtigen Production Edition über AWS
  • Als Service über SAP Big Data Services
  • Über das Bring Your Own License (BYOL) -Modell (SAP Cloud Platform, AWS)

Die SAP Vora Developer Edition über AWS verfügt über die volle Funktionalität und mit ein paar wenigen Klicks wird die Umgebung entsprechend den vorher für die eigenen Bedürfnisse ermittelten Parametern konfiguriert.

Der zugrundeliegende vorhandene Hadoop-Cluster ist eine Hortonworks-Distribution (HDP) mit den entsprechenden Tools/Software wie Spark, Ambari, Zeppelin, usw. und verfügt über maximal 4 Knoten.

Die von SAP über die SAP Cloud Appliance Library (CAL) angebotene Variante kommt in Form einer vorkonfigurierten Appliance daher mit sehr ähnlicher Funktionalität wie die bei der AWS. Sie macht vor allem dann Sinn, wenn man bereits SAP CAL nutzt.

Die produktive Edition unterscheidet sich nur in der nach oben möglichen Skalierbarkeit des Clusters und natürlich durch die Kosten.

Wie funktioniert SAP Vora?

Nach der Entscheidung für ein Deployment-Modell (On-Premise oder Cloud) geht es – je nach Wahl – an die Installation und Konfiguration.

Die Installation erfolgt in drei Schritten:

  1. Festlegung der benötigten Anzahl Knoten für Vora im Hadoop-Cluster in Abhängigkeit von
    • Anforderungen an die Verfügbarkeit
    • Anforderungen an das Sizing (CPU, Disk vs. RAM, Control Nodes vs. Compute Nodes, unterschiedliches Sizing für jede spezifische Spark-Engine, usw.)
    • Erwartetes Datenwachstum
  2. Deployment des SAP Vora Manager Services auf den benötigten Cluster-Knoten
  3. Konfigurieren und Starten der SAP Vora Services auf den Cluster-Knoten mit Hilfe des SAP Vora Manager User Interfaces

Nach erfolgreicher Installation und Konfiguration in einem Hadoop-Cluster (Distributionen HDP, Cloudera und MapR werden unterstützt) könnt ihr SAP Vora nutzen. Neben dem bereits oben erwähnten SAP Vora Manager für eher administrative Aufgaben, stehen die sogenannten SAP Vora Tools als die zentrale GUI für den Endanwender zur Verfügung.

Folgende Tools werden in der GUI angeboten:

  • Data Browser: Inhalte von Tabellen und Views anschauen
  • SQL Editor: SQL-Statements erstellen und ausführen
  • Modeler: Tabellen und Views erstellen und ändern
  • User Management: Anwender-Konten und Zugriffe auf die SAP Vora Tools managen

Mit Hilfe der SAP Vora Tools kann der Endanwender die im Hadoop-Cluster befindlichen Daten, die sich in Struktur und Datentyp unterscheiden, auswerten. Nachfolgend sind die Auswertungsmöglichkeiten detaillierter beschrieben.

Was kann ich mit SAP Vora auswerten?

Mit Vora habt ihr die Möglichkeit JSON-Dokumente auszuwerten, Zeitreihen- und Graphen-Analysen durchzuführen sowie via SQL auch klassisch relational strukturierte Daten zu analysieren.

Dabei nutzt Vora für jede Art der unterschiedlichen Analysen eine spezifische Spark-Engine mit entsprechender Optimierung in der Verarbeitung.

Der „Doc Store“ – NoSQL-Analysen von semi-strukturierten JSON-Dokumenten

Mit der Version 1.3 hat SAP den sogenannten „Doc Store“ eingeführt, mit dem veränderte Dokumente als schemalose Tabellen gespeichert werden können und somit eine horizontale Skalierung (scale-out) und eine flexible Handhabung bei den Dokument-Feldern (Löschen, Hinzufügen) ermöglicht wird.

Nachdem ihr in Vora einen Document Store (=Collection) auf Basis von im Cluster existierenden JSON-Dokumenten erstellt habt, wird darauf basierend ein View erstellt, den man auch mit den bekannten JSON-Expressions erweitern kann. Dieser wird dann im Vora-eigenen Doc Store gespeichert und kann im Tabellen- als auch JSON-Format bearbeitet werden.

Zeitreihenanalyse – Ausnutzung effizienter Kompression und Daten-Verteilung

Die Spark-Engine, die für die Zeitreihenanalyse zur Verfügung steht, kann ihre Stärken vor allem dann ausspielen, wenn die zugrundeliegenden Daten über möglichst viele Cluster-Knoten verteilt sind und effizient komprimiert werden können.

Auf Basis von im Cluster vorliegenden Zeitreihen-Daten wird innerhalb Vora eine „Zeitreihen-Tabelle“ erstellt, für die es eine eindeutige Spalte mit Zeitperioden (=Range Type) geben muss. Neben weiteren Optionen können Eigenschaften zur Äquidistanz und zusätzliche Komprimierungs-Parameter eingeben werden.

Um Zeitreihendaten auswerten zu können, müsst ihr noch eine View erstellen, den man mit spezifischen Table Functions (z.B. Cross/Auto Correlation) erweitern kann.

Es lassen sich dann für Zeitreihen entsprechende Analysen wie Regression, Binning, Sampling, Similarity, usw. durchführen.

Real-time Graphen-Analyse – Auswertung sehr großer Graphen

Vora verfügt über eine eigene In-Memory Graphen-Datenbank, die insbesondere die Analyse großer Graphen in real-time unterstützt. Die Modellierung der Graphen im grafischen Metadaten-Viewer wird entsprechend durch einen Pfad-Expression-Editor unterstützt.

Die Abfragen auf die Graphen dürfen durchaus – aufgrund der In-Memory-Engine – sehr komplex werden und die Visualisierung der Graphen zeigt sich State-of-the-Art.

Die Engine für die Graphen-Analyse bietet sich insbesondere im Bereich des Supply Chain Managements an oder zur Darstellung von umfangreichen Organisations- oder Projekt-Hierarchien oder Geschäfts-Netzwerken.

Relational Engine – Verwendung von SQL zur Auswertung von Relationen

Nicht zuletzt bietet Vora auch die Möglichkeit mit Hilfe von SQL strukturierte Daten im Cluster in Form von relationalen spaltenbasierten Tabellen abzubilden und abzufragen. Dabei werden auch hier die Daten im Memory komprimiert.

Für relationale Daten, die nicht im Arbeitsspeicher liegen müssen, bietet Vora die Disk Engine an. Diese legt die Daten in einer Datei auf dem lokalen Knoten ab, auf dem die Engine läuft. Analog dem Dynamic Tiering bei HANA, können auch hier die spaltenbasierten relationalen Disk- mit den In-Memory-Tabellen problemlos gejoint werden.

Auch noch erwähnenswert

  • SAP HANA-Tabellen können in Vora – nach erfolgter Registrierung im Repository – zusammen mit den dort erstellen Views und Tabellen zusammen verwendet werden. Von Vora aus können Daten auch in SAP HANA geschrieben werden.
  • Erstellung von Level- und Parent-Child-Hierarchien und gemeinsame Verwendung mit Fakten-Tabellen wird unterstützt.
  • Währungsumrechnung (Standard oder ERP) kann in Tabellen und Views verwendet werden.
  • Für jede Engine respektive für die in Vora erstellten spezifischen Datenstrukturen gibt es spezielle Funktionen und Typen für die Partitionierung, mit denen diese im Cluster optimal verteilt bzw. partitioniert werden (Hash, Block, Range).

Welche Datenquellen und -formate werden aktuell unterstützt?

Mit SAP Vora Tools können folgende Dateien in Vora verarbeitet werden:

  • .CSV
  • .ORC
  • .PARQUET
  • .JSON
  • .JSG

Neben dem Standard-Datentyp HDFS sowie den Typen ORC und PARQUET (Option (format „orc“ / format „parquet“)) können folgende weitere im „Create Table“-Statement in Vora geladen werden:

  • Amazon S3 (Option (storagebackend „s3“))
  • Swift Object (Option (storagebackend „swift“))

Fazit und Ausblick

SAP Vora spielt seine Stärken natürlich insbesondere im Zusammenhang mit SAP HANA aus: so kann man relationale Daten aus HANA mit semi-strukturierten Daten aus dem Hadoop-Cluster zusammen auswerten. Des Weiteren findet ihr in Vora verschiedene Auswertungs-Möglichkeiten (Graphen, Dokumente, usw.) in einem Tool vereint, die man sonst in jeweils verschiedenen Tools (oder nur mit verschiedenen Datenbanken) der Hadoop-Distributoren oder Drittanbietern findet.

Zukünftig plant SAP für Vora für alle Engines das Transaktionskonzept (ACID) zu unterstützen, um eine konsistente Datenhaltung zu verbessern. Für dieses Jahr 2018 ist ein erster Support für Insert-/Update-/Delete-Statements geplant. Vorgesehen ist darüber hinaus auch die Unterstützung für SQL-Pass-thru von SAP HANA zu SAP Vora.

Für Freunde des SAP BW noch interessant: über 2018 hinaus ist die Unterstützung von DSOs geplant.

Wenn ihr SAP Partner seid, könnt ihr einfach mit der kostenfreien Developer Edition starten, um in die Materie einzusteigen – dort könnt ihr euch in Ruhe mit der Konfiguration und der Nutzung vertraut machen.

Oder fragt uns – wir helfen gerne!

Autor dieses Beitrags
Andreas Keller Associate Partner
Tel.: +49 (0) 7031 714 660 0
E-Mail: info@inspiricon.de

So gelingt der Einstieg in den Query Designer in Eclipse

Es freut uns sehr, dass wir euch heute unseren ersten Gastautor vorstellen dürfen: Jürgen Noe. Er ist Geschäftsführer der Jürgen Noe Consulting UG (haftungsbeschränkt) in Mannheim (www.juergen-noe-consulting.de). Jürgen ist Autor verschiedender Bücher aus der SAP-Welt. Sein Artikel – so wie sein neues Buch – dreht sich um den Query Designer in Eclipse. Vielen Dank nochmals an ihn und euch viel Spaß bei der Lektüre!

 

Mit der Einführung von SAP BW 7.4 kam neben der HANA Unterstützung auch eine stille Revolution in der Oberfläche hinzu. War bis zu diesem SAP BW Release die SAP GUI die einzige unterstützte Softwareentwicklungsumgebung (SEU), setzte das Hasso-Plattner-Institut bei der Entwicklung der HANA Datenbank von vornherein auf Eclipse als SEU. Damit sind jetzt zwei Entwicklungsumgebungen für Entwickler von SAP Applikationen relevant. So ist zum Beispiel für die Entwicklung der HANA Datenbankobjekte das HANA Studio relevant. Für klassische ABAP-Applikationen war weiterhin die SAP GUI notwendig.

Doch SAP hielt eine weitere Überraschung parat: Neben der reinen Unterstützung der HANA Plattform kamen mit der Zeit weitere Tools für die Entwicklung und das Customizing von Applikation auf HANA in Eclipse hinzu.

Ein Tool hieraus sind die sogenannten BW Modelling Tools, kurz auch BW-MT. Diese erlauben es, das typische BW Customizing komplett in Eclipse zu vollziehen. Das Anlegen von InfoProvidern, des kompletten Extraktions-Transformation-Lade-Prozesses (ETL) ist komplett in den BW-MT möglich.

Damit war es nur logisch, das zentrale Tool zum Anlegen von BW Queries ebenfalls in den Modelling Tools nachzubauen. Mit den neueren Releases von SAP BW ab Version 7.4 aufwärts, wird der gute alte Query Designer als Stand-Alone-Applikation im Rahmen der Business Explorer- Suite (BEx) damit obsolet.

Schnelleinstieg in den Query Designer in Eclipse

Vor diesem Hintergrund habe ich die neuen Funktionalitäten des Query Designers in Eclipse daher in dem Buch „Schnelleinstieg in den Query Designer in Eclipse“, erschienen im September 2017 im Verlag Espresso Tutorials, beschrieben.

Query Designer Cover

 

Den Link zum Buch findet ihr hier: https://de.espresso-tutorials.com/business_intelligence_0159.php

Das Buch möchte ich euch in den nächsten Abschnitten kurz vorstellen:

Das Buch beginnt mit allgemeinen Grundlagen über SAP BW und Eclipse im Allgemeinen. Im Abschnitt zu Eclipse erkläre ich kurz den Aufbau von Eclipse sowie zentrale Begriffe wie Plug-In, View und Perspektiven. Erfahrene Eclipse-Anwender können dies Kapitel auch überspringen.

Im dritten Kapitel erfolgt eine Kurzübersicht zu den BW Modelling Tools. Hier erkläre ich, wie ihr klassische Transaktionen, wie die Data Warehouse Workbench in Eclipse aufrufen, wie ihr einen Datenfluss anlegt und gehe auf zentrale Views ein, wie die Project Explorer- und die InfoProvider-View.

Da der Project Explorer in Eclipse von zentraler Bedeutung ist, zeige ich detailliert, wie ihr ein neues Projekt anlegt und damit arbeitet. Anschließend erkläre ich, wie ihr im Project Explorer in die InfoProvider-View, die in der folgenden Abbildung 1 dargestellt ist, navigieren könnt:

Infoprovider view

Abbildung.0.1 Infoprovider View

In dieser View könnt ihr globale, wiederverwendbare Objekte, wie eingeschränkte und berechnete Kennzahlen, Strukturen, Filter, aber auch Variablen anlegen. Diese sind unterhalb des Ordners Reusable Components in Abbildung 1 zu finden.

Wie genau die einzelnen wiederverwendbaren Elemente anzulegen sind, welche Einstellungen es gibt und wie sich diese auswirken, beschreibe ich im Detail im Kapitel 4 des Buches mit zahlreichen Screenshots. Die Möglichkeit der zentralen Anlage von wiederverwendbaren Komponenten ist für mich ein Grund, warum sich der Umstieg von der  alten BEX Version auf den neuen Query Designer in Eclipse lohnt. Vorbei sind die Zeiten, in denen Sie sich mühsam durch mehrere Fenster im BEx-Query-Designer klicken mussten, um zum Beispiel eine Formelvariable anzulegen. Die Navigation und Benutzerfreundlichkeit wurde aus meiner Sicht hier entscheidend verbessert.

Auch in einem zweiten Punkt stellen die BW-MT ihre volle Stärke dar: Nie war es so einfach, von einem Objekt zu einem anderen abspringen, es zu ändern und die Änderung sofort im Ausgangsobjekt zu sehen. Ein konkretes Beispiel: Ihr stellt fest, dass ihr eine weitere Kennzahl in der Query benötigt. In der alten Welt musstet ihr diese erst in der DataWarehouse Workbench (DWB) anlegen, im MultiProvider ergänzen und zuordnen, den Query Designer neu starten, damit er die Änderung mitbekam und dann konnte man die Kennzahl in die Query einfügen. Dieses lästige Hin-und Herspringen zwischen verschieden Tools und Transkationen entfällt komplett. Mit den BW-MT wechseln in Eclipse lediglich die Views! Ihr wechselt von der  Query Designer View zur Stammdaten-View, legt dort die Kennzahl an, fügt sie eurem Datenmodell im Multiprovider in der InfoProvider-View hinzu, speichert diese ab und wechselt zurück in die Query Designer View.

Alles parallel in einem Tool, in mehreren Fenstern nebeneinander!

Sofort ist die Änderung am MutliProvider in Eclipse sichtbar. Falls nicht, kurz auffrischen und schon ist die neue Kennzahl auch in der Query verfügbar. So einfach war es noch nie!

Die Queryeigenschaften im Detail

Jetzt fragt ihr euch bestimmt schon, wie sieht die View des Query Designers aus, mit der man Queries erstellen, ändern und löschen kann? Schauen wir dazu auf die folgende Abbildung 2:

Query Definition

Abbildung.0.2 Querydefinition (Filter)

Wie ihr seht, ist die Querydefinition über mehrere Reitere verteilt. Im Reiter Allgemeines (General) stellt man allgemeine Queryeigenschaften ein, wie Anzeigen wiederholender Schlüsselwerte und vieles mehr.

In Abbildung 2 seht ihr die Definition eines Queryfilters. Wie im BEx-Query Designer bleibt die prinzipielle Querystruktur mit Spalten Zeilen und freien Merkmalen erhalten. Diese Struktur definiert ihr im Reiter Sheet Definition. Gearbeitet wird prinzipiell mit dem Kontextmenü, über das ihr alle wichtigen Funktionen in der jeweiligen View erreicht.

Über den Reiter Conditions legt man Bedingungen an, wie etwa zeige mir alle Datensätze mit einem Umsatz größer 1 Mio. Euro.

In den Exceptions definiert man Ausnahmen. Ausnahmen erlauben es, Zeilen, Spalten oder auch nur einzelne Zellen farbig zu markieren und damit auf Ausreißer oder besondere Zustände hinzuweisen.

Gelungen finde ich den Reiter Dependency Structure, der aufzeigt, in welchen anderen Queries die verwendeten Variablen dieser Query noch verwendet werden.

Im Reiter Runtime Properties stellt ihr die Performance-Eigenschaften der Query ein, wie etwa Nutzen des Delta-Caches und viele weitere Eigenschaften, die wir aus der RSRT bereits kennen.

Was man genau in jedem einzelnen Reitern einstellen kann und wie sich diese Einstellungen auswirken, zeige ich anhand vieler Screenshots und Beispielen im Kapitel 5 des Buches.

Und wie sieht das Queryergebnis aus?

Nachdem ihr eure Query erstellt haben, möchtet ihr sie auch testen und ausführen. Mit den BW-MT erfolgt die Ausgabe des Queryergebnisses in einer eigenen View, hierzu Abbildung 3:

Queryergebnis

Abbildung.0.3: View für Queryergebnis

Ihr könnt im Queryergebnis frei navigieren, Filter setzen, Aufrisse hinzufügen, entfernen, so wie ihr es kennt. Auch hier findet ihr alles komplett in dieser View wieder, es ist kein installierter JAVA-Server für eine Webausgabe oder ein Wechsel zum BEX-Analyzer für eine Ausgabe in Excel mehr nötig!

Bei komplizierteren Queries benötigt ihr eventuell zwei Strukturen:
Im alten BEx Query Designer musstet ihr mit dem Zelleditor arbeiten. Im neuen Query Designer in Eclipse ist der Zelleditor rundum erneuert worden und verfügt nun über nützliche Funktionen wie Copy & Paste. Des Weiteren finden auch keine lästigen Roundtrips zum Server mehr statt, um die Eingabe zu prüfen, was das Arbeiten mit dem Zelleditor deutlich beschleunigt. Schaut euch den neuen Zelleditor auf Abbildung 4 an:

Zelleditor

Abbildung 0.4 Zelleditor

Zu guter Letzt: die Variablen

Was jetzt noch fehlt sind Variablen, die euch Dynamik in den Queries erlauben. Im sechsten Kapitel widme ich mich den Variablen und zeige, wie alle typischen Variablen anhand von Screenshots und mit einfachen Beispielen angelegt werden können.

Die Vorteile des neuen Query Designers in Eclipse:

  • Moderne, benutzerfreundliche und zukunftsfähige Oberfläche
  • Alle bestehende Funktionen des BEX Query Designer sind im neuen Query Designer in Eclipse enthalten
  • Nahtlose Integration der BW-Datenmodellierung in einem Tool

Als Fazit kann ich euch den Query Designer in Eclipse samt den BW-MT nur ans Herz legen. Das Erstellen und  Testen von ganzen BW Datenmodellen und Queries war noch nie so einfach. Damit stellt der Query Designer im Eclipse für mich einen wichtigen Schritt in die Zukunft dar!

Autor dieses Beitrags
Jürgen Noe Geschäftsführer der Jürgen Noe Consulting UG (haftungsbeschränkt)
Tel.: +49 (0) 621 72963337
E-Mail: juergen.noe@juergen-noe-consulting.de
5 Stufen einer erfolgreichen Test-Strategie bei BI-Implementierungen

Die fünf wesentlichen Stufen einer erfolgreichen Teststrategie für SAP-BI-Implementierungen

Wie wichtig sind Tests in SAP BI überhaupt?

Es wird den ein oder anderen geben, der die drei goldenen Regeln für erfolgreiche SAP-BI-Projekte noch nicht kennt. Sie lauten:

„Testen, testen und dann noch einmal testen!

Und jetzt mal ganz im Ernst: Eine erfolgreiche Teststrategie für jede SAP-BI-Implementierung umfasst genau genommen sogar fünf ganz wesentliche Schritte. Diese lassen sich wie folgt zusammenfassen:

  1. Modultests
  2. Funktionstests
  3. Datenmigrations- und Integrationstests
  4. Performancetests
  5. User-Acceptance-Tests (UAT) & abschließende Freigabe

„Wenn Sie meinen, dass Tests zu teuer sind, sollten Sie sich darüber bewusst sein, was ein Auslassen dieser Tests kostet!“

Man hört diese Frage förmlich schon: „Was kosten mich denn diese ganzen Tests?!“

Es gibt immer wieder Kunden, die die Kosten für die erforderlichen Tests einer SAP-BI-Implementierung scheuen. Vielleicht verweisen sie darauf, dass die „Qualität“ eigentlich inbegriffen sein sollte – vorausgesetzt, das BI-Team hat bei der Entwicklung aller Berichtsobjekte gründlich gearbeitet.
Vielleicht wehren sie sich gegen eine Bereitstellung ihrer knappen Mittel für Testmaßnahmen und geben das Geld lieber für weitere Entwicklungen vor dem Go-live aus.
Und vielleicht stehen sie auch selbst unter Druck das „Maximum“ aus dem BI-Projektteam herauszuholen, solange es noch vor Ort ist – und all das sollte möglichst im festgelegten Projektumfang aus Zeit, Budget und Qualität liegen.

Und trotz all dieser Widerstände, die auf den ersten Blick für geringere Investitionen in Testläufe sprechen, zeichnet die Erfahrung aus SAP-BI-Projekten ein gegenteiliges Bild. Natürlich bedeutet die Entscheidung für gründlichere Tests auch erheblichen Mehraufwand, den es im Projektzeitplan frühzeitig zu berücksichtigen gilt – letztendlich können so aber in aller Regel auch die Gesamtkosten der Implementierung gesenkt werden.

Untersuchungen haben gezeigt, dass die tatsächlichen Kosten von Softwarefehlern abhängig vom Zeitpunkt ihrer Entdeckung exponentiell steigen können.

So gibt es zum Beispiel die 1-10-100-Regel:
Ein Fehler, der in der Entwicklungs- und anfänglichen Programmierungsphase noch 1 Euro kostet, kann während der Akzeptanztests schon 10 Euro und nach dem Go-live sage und schreibe 100 Euro kosten!

Unsere langjährige Erfahrung in BI-Projekten hat uns immer wieder gezeigt, dass Kosten gespart werden können, wenn Bugs bereits in den anfänglichen Testphasen entdeckt und behoben werden – je früher man also mit den Testläufen beginnt und je mehr Geld vorab in diese Tests investiert wird, desto mehr kann bei den Projektkosten sowohl kurz- als auch langfristig eingespart werden.

So mancher BI-Projektmanager schätzt das mögliche Einsparpotential auf das Zwei- bis Dreifache der Kosten! Und wenn sich die Projektverantwortlichen so noch nicht vom Wert zusätzlicher Tests überzeugen lassen, gilt es auch nicht zu vergessen, dass ebenso die Aufwände und der Druck direkt vor dem Go-live ganz erheblich reduziert werden können – ganz zu schweigen davon, dass so auch die Fachabteilungen beruhigt werden können –, wenn die anfängliche Konzentration auf die Tests allmählich Wirkung zeigt. Spätestens dann zeigt sich, dass sich diese Investition in die Qualität mehr als lohnen.

Testen oder Nichttesten, das ist hier (nicht) die Frage …

Da wir uns jetzt einig sind, dass Tests ein wesentlicher Bestandteil eines jeden SAP-BI-Projekts sind, stellen sich natürlich weitere Fragen:
Was genau muss wann, wie und wie oft getestet werden?

Grundsätzlich gilt: Je mehr man testet, desto geringer fallen die Gesamtentwicklungskosten aus.

Geht man beim Testen dann noch strukturiert vor, eröffnen sich weitere Vorteile. Hält man die Testergebnisse zum Beispiel fest und setzt sie in unmittelbaren Nutzen um, wird mit jeder Wiederholung von Testdurchläufen und Testphasen die Qualität des Endprodukts (eure BI-Berichte) gesteigert. Auf diese Weise stoßt ihr einen Prozess kontinuierlicher Verbesserung in eurem BI-Projekt an, der eurem SAP-BI-System auch lange nach Abschluss des ursprünglichen Implementierungsprojektes noch zugutekommt.

Was genau umfassen SAP-BI-Tests eigentlich – was gehört dazu?

Testläufe sind genau genommen regelmäßige „Qualitätsprüfungen“, also eine Gelegenheit, die Qualität einer Implementierung an festgelegten Punkten im Projektzeitplan und unter Berücksichtigung verschiedener Aspekte zu messen. Dabei sollte jeder Test durch Nachverfolgung und Dokumentation sowohl der SAP-BI-Testfälle als auch der Mängel in einem geeigneten Testtool unterstützt werden.
„HPQC” – HP ALM Quality Center ist ein häufig genutztes Testtool, aber natürlich gibt auch viele weitere Tools am Markt.

Wir bei Inspiricon wissen, dass jede Kundensituation einzigartig ist. Es gibt keine „Standardvorgehensweise“, die sich auf jedes beliebige Szenario anwenden lässt. Es gibt jedoch ein bewährtes Framework, das zur Strukturierung der Testaktivitäten eingesetzt werden kann. In unseren SAP-BI-Projekten konzentrieren wir unsere umfassenden Erfahrungen und unser Fachwissen aus vorausgegangenen Projekten, um auf die spezifischen Herausforderungen eingehen zu können. Darüber hinaus erarbeiten wir eine individualisierte Teststrategie und einen Testplan, um maximale Qualität für eure SAP-BI-Implementierung sicherzustellen und die Gesamtkosten möglichst gering zu halten.

Die folgenden Testaktivitäten haben nicht den Anspruch vollständig zu sein oder eine Standardvorgehensweise abzubilden. Sie dienen lediglich als Beispiel für einige der wichtigsten Qualitätsprüfungen, die im Rahmen unserer fünf wesentlichen Stufen von SAP-BI-Testläufen erfolgen können:

1. Modultests:

Gute Modultests liefern die Grundlage für alle weiteren Schritte. Diese ersten Tests umfassen eine gründliche Prüfung der Gestaltungsarbeit, gefolgt von einer schrittweisen Dokumentation der Daten auf ihrem Weg durch die verschiedenen Schichten eurer BI-Architektur, sowohl im persistenten als auch im nicht-persistenten Status.
Je größer die Zahl der erkannten und (einfacher) behobenen Bugs zu diesem Testzeitpunkt ausfällt, je größer sind die Einsparungen insgesamt!

  • Dokumentation und Freigabe der technischen Daten (dies kann zum Beispiel eine Beschreibung der Berichtsgestaltung und der Datenflüsse in Word, eine visuelle Übersicht in PowerPoint und eine Excel-Tabelle mit umfassenden Mappings des Datenmodells umfassen)
  • Treffen der Fachabteilung zur Freigabe der Berichtslayouts und -köpfe (schon bevor die Testdaten verfügbar sind)
  • Interne Tests durch den BI-Entwickler, einschließlich gründlicher Prüfung der Daten in jeder Stufe des Datenflusses und eines direkten Vergleiches der Quellsystemdaten, der SAP-BW-Daten und der Daten im endgültigen BI-Bericht

2. Funktionstests:

Um die Funktion effektiv testen zu können, muss im Team das notwendige Fachwissen nicht nur bezüglich der fachlichen Anforderungen und der Prozesse im ERP-Quellsystem vorliegen, sondern auch in Hinblick auf das Datenmodell, die Datenflüsse, die Berichtsgestaltung in SAP BI und die Möglichkeiten, diese beiden Welten zu „überbrücken“ bzw. zu vereinen.

  • Tests zur Sicherung der Qualität (QA), vor allem durch interne BI-Projektverantwortliche mit eingehenden Kenntnissen des vorherigen Berichtssystems und der zugrunde liegenden Geschäftsprozesse
  • Dokumentation der Testfälle in Testsoftware wie zum Beispiel HPQC
  • Pre-UAT-Tests (Pre-User Acceptance Testing) auf Fachseite, einschließlich Mängelbehebung und erneuter Tests, umfassender Dokumentation und Nachverfolgung im Testtool, z. B. HPQC
  • Interne Tests durch das BI-Team, koordiniert durch die Entwicklungsleiter und Dokumentation in einer zentralen Statusliste bzw. einem „Katalog“ aller BI-Berichte

3. Datenmigrations- und Integrationstests:

An diesem Punkt erfolgt die Überprüfung der Datenmigration und der reibungslosen Integration mit dem/den Quellsystem(en). Datenflüsse, einschließlich InfoPackages, DTPs, Transformationen und letztendlich der Prozessketten, die das vollständige tägliche Laden der Daten automatisieren, müssen koordiniert und auf Vollständigkeit, Richtigkeit, korrekte Fehlerbehandlung und Stabilität geprüft werden. Und selbstverständlich müssen alle BI-Objekte, die ins Produktivsystem transportiert werden, vor dem Go-live geprüft werden!

  • Prüfung der Datenmigrationen
  • Prüfung vollständige Datenübernahme gegenüber Delta-Datenübernahme
  • Optimierung und Test der täglichen und periodischen Prozessketten
  • Konfiguration und Test der Meta-Ketten
  • Aktivierung und Prüfung der automatisierten BW-“Housekeeping“-/Bereinigungsaufgaben
  • Prüfung der transportierten BI-Objekte im Produktivsystem vor dem Go-live

4. Performancetests:

An dieser Stelle erfolgt eine gründliche Prüfung der Performance der Systemarchitektur sowie des System-Sizings. Die Aktualisierungszeiten und akzeptablen Performancewerte werden anhand der Anforderungen auf fachlicher Seite festgelegt, üblicherweise werden dabei als Vergleichswert die Performance-Benchmarks der vorausgegangenen Berichtssysteme zu Grunde gelegt.

Automatisierte Performance-Tests durch Drittanbieter-Software wie LoadRunner. Dabei werden unter anderem die folgenden Aspekte berücksichtigt:

  • Lastspitzen durch gleichzeitige Benutzer
  • Anfängliche Ladezeiten für Berichtsstruktur und Eingabeaufforderungen
  • Aktualisierungszeiten für Berichte mit Daten
  • Maximale durch Berichtsabfragen zurückgegebene Datenmengen
  • Speichervolumen für gespeicherte Berichte und Zeitpläne

5. User-Acceptance-Tests (UAT) und abschließende Freigabe:

Hier wird es erst richtig interessant, denn hier haben die Endanwender als eigentliche „Empfänger“ unseres finalen Produkts endlich auch Gelegenheit, ihre Berichte zu testen! Sie können die Qualität der Berichtergebnisse durch Durchführung von Testfällen für Daten- und Plausibilitätsprüfungen prüfen. Darüber hinaus können sie mögliche Mängel und Erweiterungen im Testtool protokollieren und erfolgte Fehlerbehebungen erneut prüfen. Bei der endgültigen Freigabe eines Berichts auf der Fachseite haben immer die Endanwender das letzte Wort.

  • Datenprüfung im UAT auf Fachseite, einschließlich einer weiteren Runde an Fehlerbehebungen und erneuter Tests
  • Plausibilitätsprüfung im UAT auf Fachseite zum Abgleich der ursprünglichen Berichte mit den migrierten/replizierten SAP-BI-Berichten in Hinblick auf Zweck, verfügbare Spalten und ungefähre Ergebnisse. Dies kann trotz der zunehmenden Unterschiede zwischen den beiden Datenbestände nützlich sein: „laufende“ Live-Daten aus dem Quellsystem gegenüber dem „Snapshot“ der ursprünglich migrierten Daten und den gesammelten Daten aus den Akzeptanztests.
  • Weitere Tests nach Abschluss des UAT und Validierung durch größer angelegte Testgruppen mit umfangreicherem Datenmaterial, so zum Beispiel mit zusätzlichen migrierten Daten und weiteren gesammelten Testdaten.
  • Finale Freigabe auf Fachseite durch „bestandene“ Testfälle im Testtool, z. B. HPQC.

Es soll noch einmal betont werden, dass es sich hierbei lediglich um einige Beispiele empfohlener Schritte in einer umfassenden Teststrategie für BI-Implementierungen handelt und dass diese in keiner Weise eine Standardherangehensweise darstellen sollen. Jedes Implementierungsprojekt ist einzigartig und es sollte daher auch für jeden Kunden eine eigene Teststrategie und ein eigener Plan entwickelt werden, der den spezifischen Anforderungen und SAP-BI-Szenarien gerecht wird.

Qualität ist Trumpf!

Zusammengefasst ist eine umfassende Teststrategie unterstützt durch wirksame Strukturierung, Nachverfolgung und Dokumentation in einem geeigneten Testtool die beste Investition zur Sicherstellung eines reibungslosen Go-lives für Endanwender und eines zukunftssicheren BI-Systems mit nachhaltig hoher Qualität!

Je mehr Zeit und Geld ihr von Anfang an für Testzwecke investieren, desto weniger Probleme werden auch beim Go-live auftreten – und desto geringer werden auch die Gesamtkosten für das SAP-BI-Projekt ausfallen!

Ihr benötigt Unterstützung bei der Entwicklung einer eigenen Teststrategie für SAP BI? Dann ruft mich heute noch an oder schreibt mir eine E-Mail!

Autor dieses Beitrags
Andrea Taylor Senior Consultant SAP BI
Tel.: +49 (0) 7031 714 660 0
E-Mail: info@inspiricon.de
Ihre BusinessObject Mobile App

Run better – und zwar überall mit SAP BusinessObjects Mobile

Fachabteilungen erwarten heute eine ständige Verfügbarkeit ihrer Daten, Berichte und Dashboards. Ihre Mitarbeiter möchten nicht an den Schreibtisch gefesselt sein, sondern überall und jederzeit auch auf ihren Mobiltelefonen und Tablets darauf zugreifen können.

Mit SAP BusinessObjects Mobile und der SAP BusinessObjects BI Plattform lässt sich diese Anforderung optimal umsetzen.

Dabei gilt es aber zu beachten, dass es große Unterschiede zwischen der Benutzerinteraktion mit einem mobilen Dashboard und der Arbeit am Laptop oder Desktop gibt – durch die kleineren Bildschirme auf Mobilgeräten bleibt auch weniger Platz für Visualisierungen, Filter, Schaltflächen und alle anderen Komponenten.

Bereitstellung eines WebI Reports in der SAP BusinessObjects Mobile App

In diesem Artikel möchten wir uns mit der Möglichkeit der Bereitstellung eines WebI Reports in der SAP BusinessObjects Mobile App befassen. Hierbei handelt es sich um die bevorzugte Option, da mit der App ganz bequem und sicher eine Verbindung mit der BI-Plattform hergestellt werden kann, um anschließend WebI Reports, Design-Studio-Anwendungen sowie weitere BI-Dokumente wie Crystal Reports oder SAP-Lumira-Dokumente abrufen zu können. Ein weiterer wichtiger Faktor ist die Unterstützung von Lumira 2.0, was mit der neuesten Version 6.6 von SAP Business Objects Mobile für iOS hinzugekommen ist.

iOs Android

Zwar profitieren iOS-Anwender gegenüber der Android-Version aktuell von einem geringfügig größeren Funktionsumfang sowie von einigen technischen Neuerungen, grundsätzlich bilden aber beide Versionen die Mehrzahl der Anforderungen von Unternehmensanwendern zuverlässig ab.

Unten sehen Sie einen WebI Report in der Desktop-Ansicht. Am Ende dieses Artikels zeigen wir Ihnen dann als Ergebnis den gleichen Bericht in der mobilen Darstellung (Abb. 1.1).

WebI ReportAbb. 1.1

Natürlich erfordert die Entwicklung einer verlässlichen und optimierten Mobilanwendung eine andere Herangehensweise als zum Beispiel die Entwicklung eines Dashboards zur Anzeige auf Desktop-Computern. Dennoch lassen sich diese Schritte auch auf die Bereitstellung in SAP BusinessObjects Mobile anwenden.

Ihre App in vier Schritten

>> Bitte beachten Sie: Um diese App nutzen zu können, muss sie von Anwendern der SAP BusinessObjects Business Intelligence Plattform heruntergeladen werden, deren IT-Abteilung die Nutzung von mobilen Diensten bereits aktiviert hat.

  1. Laden Sie die SAP BusinessObjects Mobile App aus dem Apple Store bzw. von Google Play herunter.
  2. Konfigurieren Sie in der App die Verbindung zu Ihrem BO-Server.

Für die nächsten Schritte gehen wir davon aus, dass Sie die App bereits auf Ihrem Telefon installiert haben. Als nächstes gilt es nun, die Verbindung zum BO-Server zu konfigurieren (Abb. 1.2).

Neue Verbindung zum BO Server

Abb. 1.2

Da unser Ziel die BI Plattform ist, wählen wir als Verbindungstyp BOE aus. Um den CMS-Namen zu ermitteln, melden wir uns bei der Central Management Console ein. Unter Server – Serverliste finden wir den Central Management Server mit dem Hostnamen (Abb. 1.3).

Central Management Console

Abb. 1.3

  1. Stellen Sie die gewünschte App bzw. den gewünschten Bericht über das BO-Launchpad bereit.

Im nächsten Schritt erfolgt zunächst die Anmeldung beim BO-Launchpad. Für den Zugriff auf den Ordner „Kategorien“ benötigen wir Administratorrechte. In diesem Ordner finden wir alle Anwendungen und Berichte, die aktuell für die mobile Nutzung verfügbar sind (Abb. 2.1).

BI Launchpad

Abb. 2.1

Wir rufen unsere Ordner auf und wählen per Rechtsklick den Bericht aus, den wir bereitstellen möchten. In dem Kontextmenü, das jetzt erscheint, klicken Sie auf „Kategorien“ (Abb. 2.2).

Kategorien

Abb. 2.2

Ein neues Fenster wird angezeigt. Klicken Sie auf „Öffentliche Kategorien“ – „Mobil“ und speichern Sie Ihre Auswahl (Abb. 2.3).

Öffentliche Kategorien - Mobil

Abb. 2.3

  1. Wenn wir jetzt unsere mobile Anwendung aufrufen, wird der bereitgestellte Bericht angezeigt (Abb. 2.4).

Bericht

Abb. 2.4

Zu welchem Ergebnis führen diese Schritte?

Das Ergebnis ist ein Bericht, der jederzeit und überall über Ihr Mobilgerät aufgerufen werden kann. Dabei kann die Anzeige auch im Querformat erfolgen (Abb. 3).

Ergebnis

Mit SAP BusinessObjects Mobile können auch Push-Benachrichtigungen eingerichtet werden, über die Mobilanwender auch dann benachrichtigt werden können, wenn keine aktive Benutzersitzung läuft oder die mobile Anwendung gerade nicht ausgeführt wird. Um diese Funktion zu aktivieren, müssen die Einstellungen sowohl server- als auch clientseitig entsprechend angepasst werden (Abb. 4).

Push Benachrichtigungen

Abb. 4, Quelle: YouTube

Fazit und Ausblick

Der große Vorteil hier liegt darin, jederzeit fundierte und damit intelligentere Entscheidungen treffen zu können. Und zwar auf Grundlage von maßgeschneiderten und personalisierten Informationen, die überall bereitstehen – egal ob im Vorstandszimmer, beim Kunden vor Ort oder in der Produktionshalle – und auch ohne zusätzlichen Schulungsbedarf analysiert werden können.

Mit SAP BusinessObjects Mobile können Sie ohne Wartezeit sofort auf Business Intelligence-Berichte, Kennzahlen und Echtzeitinformationen zugreifen. Es gibt natürlich noch viele weitere Aspekte, die es im Zusammenhang mit SAP BusinessObjects Mobile und der richtigen Herangehensweise bei der Entwicklung von mobilen Anwendungen zu besprechen gilt, und wir werden uns diesen Themen in einem unserer nächsten Artikel widmen.

Autor dieses Beitrags
Cristian Moldovan Associate SAP BI
Tel.: +49 (0) 7031 714 660 0
E-Mail: cluj@inspiricon.de
So erhöhen Sie mit SAP Fiori Ihre Benutzerproduktivität und Automatisierung

So erhöhen Sie mit SAP Fiori Ihre Benutzerproduktivität und Automatisierung

Sie kennen die „alten“ SAP-Oberflächen? Diese sehen nicht gerade ansprechend aus, wenn wir ehrlich sind. Das ändert sich jedoch grundlegend mit SAP Fiori!

Schluss mit komplizierten Workflows, Schluss mit langweiligen Designs,
Schluss mit der unnötigen Verschwendung von Ressourcen!

SAP Fiori stellt ein User Interface für alle Aufgaben zur Verfügung: Mit den browser-basierten SAP Fiori Apps lassen sich Aufgaben rollenbasiert und prozessbezogen in einer einzigen Benutzeroberfläche erledigen – und zwar über alle Devices hinweg.

SAP Fiori bildet damit die Schnittstelle von Effizienz und Design.

Der wesentliche Vorteil für Sie von SAP Fiori – abgesehen vom verbesserten Aussehen und der damit einhergehenden erhöhten Benutzerakzeptanz – ist die effektivere Nutzung von Ressourcen. Mit genauen Kenntnissen über das Nutzerverhalten Ihrer Mitarbeiter, können Sie die Apps so gestalten, dass sie die Arbeitsprozesse mit einer idealen User Experience optimal unterstützen.

Das bedeutet für Sie:

  • beschleunigte Prozesse
  • effektive Kostensenkung
  • Zugriff auf alle wichtigen Unternehmensprozesse von jedem Ort und jedem Gerät.

Zum Beispiel können Self Service Workflows, Abwesenheitsanträge, Zeiterfassung oder Bestellungen durchgeführt werden, die direkt in SAP Fiori angelegt und auch dort genehmigt werden.

Sie möchten sich detaillierter mit SAP Fiori auseinandersetzen und mehr über seine Funktionsweise lernen? Da haben wir etwas für Sie!

Webinar SAP Fiori Crashkurs in 30 Minuten

Schauen Sie sich die Aufzeichnung unseres Webinars vom 28. Juni 2017 an: SAP Fiori Crashkurs in 30 Minuten.

Darin zeigen wir Ihnen, wie Sie eine Fiori App für Live-Reporting auf SAP BW erstellen können. Erfahren Sie außerdem, wie SAP Fiori Sie noch unterstützen kann:

  • Vereinfachung von Prozessen und Workflows
  • Fehlerminimierung
  • optimale Nutzung Ihrer Ressourcen – denn SAP Fiori steht Ihnen bereits mit Ihrer SAP-Lizenz zur Verfügung
  • Individualisierung von Prozessen: Sie können alle SAP Fiori Apps Ihrem CI anpassen
  • Vereinfachung und Automatisierung Ihrer täglichen Aufgaben
  • last but not least: es ist einfach zu bedienen, macht Spaß und sieht auch noch gut aus!

>> Hier können Sie die Aufzeichnung anfordern.

In 7 Schritten zu Ihrer ersten SAP Fiori App

In diesem Leitfaden beschreiben wir Ihnen ausführlich und Schritt für Schritt, wie Sie selbst eine SAP Fiori App zur Datenvisualisierung erstellen können – und zwar in nur einer Stunde!

SAP Fiori repräsentiert ein neues personalisiertes, reaktionsschnelles und einfaches Benutzererlebnis über verschiedene Endgeräte hinweg. Für unsere Kunden stellt SAP Fiori die moderne, hochperformante und benutzerfreundliche Schnittstelle zu einem komplexen BI dar – BI meets Fiori.

>> Klicken Sie hier, um den Leitfaden anzufordern.

Das Beste kommt zum Schluss

In diesem Info-Video finden Sie komprimiert die wichtigsten Infos zu SAP Fiori. >> Hier geht’s zum Video!

Oder Sie lesen alles bequem in unserem E-Book nach – >> hier geht es zum Download.

Inspiricon-E-Book-SAP-Fiori

Sie haben weitere Fragen zu SAP Fiori? Kontaktieren Sie mich gerne direkt – ich freue mich auf Ihren Anruf, E-Mail oder SMS!

Autor dieses Beitrags
Andrei Vlad CEO Inspiricon SRL
Tel.: +49 (0) 7031 714 660 0
E-Mail: cluj@inspiricon.de