Active Directory Implementatierung für SAP Fiori

Active Directory Implementierung für SAP Fiori

Hallo und herzlich willkommen zum vierten Teil der Tutorialreihe „SAP Fiori Customization Samples“.  In diesem Video werden wir zeigen, wie man eine benutzerdefinierte Fiori-Kachel für das Fiori Launchpad erstellen kann.

Diese Kachel werden verwendet für die intuitive Anzeige dynamischer Daten, um Informationen auf einen Blick zu liefern, sobald man das Fiori Launchpad öffnet.  Dies ist das erste Video eines zweiteiligen Tutorials und konzentriert sich auf den strukturellen Teil des Prozesses.

Wir werfen zunächst einen kurzen Blick auf die Schritte, denen wir als nächstes folgen werden.

Voraussetzungen

Zuerst werden wir bestimmte Dateien aus dem SAPUI5-Framework sammeln, die uns als Grundlage für die benutzerdefinierte Kachel dienen werden.

Der zweite Schritt besteht darin, die Dateien so anzupassen, dass sie dem gewünschten Ergebnis entsprechen. Anschließend registrieren wir die Application als CHIP und nehmen sie in die Fiori Launchpad Designer-Komponente auf. Gegen Ende dieses Videos werden wir versuchen, die neue Kachel dem Launchpad hinzuzufügen.

Für dieses Tutorial gehen wir davon aus, dass Du Administratorzugriff auf das SAP-System hast, da Du eine SAP-Standardkomponente ändern musst. Außerdem gehen wir davon aus, dass die SAP WebIDE-Landschaft eingerichtet und in Betrieb ist, da wir sie für die Entwicklung und das Deployment verwenden werden. Es können auch andere Methoden eingesetzt werden, wie z.B. das manuelle Hochladen oder die Verwendung der Eclipse-IDE, aber diese Vorgehenweisen werden in diesem Tutorial nicht behandelt.

Leitfaden

Zunächst loggen wir uns in das zu modifizierende SAP-System ein und starten die Transaktion für den Fiori Designer. Dies geschieht über den Transaktionscode /ui2/flpd_CUST.

Sobald der Designer geladen ist, öffnen wir die Entwicklerkonsole mit der F12 Taste und navigieren zur Registerkarte Netzwerk.

Am Ende der URL muss man die Extension sap-ui-debug=true hinzufügen, um damit die UI5-Engine dazu zu bringen, alle Dateien zu laden. Dank der Magie der Videobearbeitung müssen wir hier jetzt nicht die Ladezeit abwarten, aber, das sei gesagt, die Wartezeit ist ziemlich lang.

Nun, da die Dateien geladen wurden, müssen wir sie nach dem Wort „Dynamic“ filtern. Es sollten dann noch drei Dateien in der Liste erscheinen. Speichere den Inhalt der Dateien in einem temporären Ordner mit Deinem bevorzugten Texteditor.

Nachdem Du diese drei Dateien gespeichert hast, klicke auf eine Kachel und warte, bis der nächste Stapel von Dateien komplett geladen ist. Nun solltest Du nach dem Wort „Konfiguration“ filtern und den Speichervorgang für die Dateien configuration.view.xml und configuiration-dbg.controller.js wiederholen.

Nachdem wir die Dateien gespeichert haben, müssen wir ein SAP WebIDE-Projekt anlegen.

Bitte öffne dazu die WebIDE ab und erstelle ein neues Projekt basierend auf der Vorlage. Wähle SAPUI5 Application und gebe die erforderlichen Felder ein. Dies wird das Projekt sein, an dem wir arbeiten werden.

Als Nächstes müssen wir die unnötigen Dateien löschen und die Dateien importieren, die wir zuvor gespeichert haben. Man kann sie als Stapel hochladen, wenn man sie als eine .zip-Datei speichert.

Erstelle einen neuen Ordner innerhalb des Webapp-Ordners und benenne ihn myKpiTile. In diesen Ordner werden wir sowohl die Ansichten als auch die Steuerungsdateien verschieben.

Benenne die App als app._launcher-Datei in kpiLaunchar_dynamic.chip.xml um und bearbeite sie, um den Ansichtspfad und den Namen der benutzerdefinierten Kachel zu ändern.

Setzte den View-Namen auf mykpitile.myTile.view.js und den Titel der Kachel auf „mydynamictile“ und die Beschreibung wird vom Tutorial erstellt.

Nun müssen wir die Ansicht und den Controller umbenennen, damit sie dem neuen Namen, den wir ausgewählt haben, zu entsprechen. Daher werden wir die Ansicht in myTile.view.js umbenennen und der Controller wird myTile.controller.js sein.

Benenne auch den Konfigurations-Controller um und lösche die Debug-Registerkarte im Namen weg.

Wir müssen den Namensraum und den Namen der Ansicht auch in den aktuellen Dateien aktualisieren. Dies kann mit der Such- und Ersetzungsfunktion durch Drücken von Strg+f geschehen. Damit ändern wir den vorherigen Namensraum zu unserem aktuellen Pfad, also myKpiTile und den Namen der View zu myTile. Dies muss auch in der Steuerungsdatei geändert werden und kann auf die gleiche Weise erfolgen.

Um die Anwendung als CHIP zu registrieren, muss man sie als BSP-Applikation im SAP-System bereitstellen. Wie man hier sehen kann, hatte ich einige Probleme bei der Bereitstellung der Anwendung, weil ich vergessen habe, einige unnötige Dateien zu löschen. Achte darauf, dass Du nur die Dateien speicherst, die Du im Projekt benötigst, sonst stürzt es während des Deployments ab.

Wir wechseln nun zur Transaktion se80, um zu überprüfen, ob die Anwendung erfolgreich bereitgestellt wurde. Nachdem wir sichergestellt haben, dass die Bereitstellung erfolgreich war, können wir mit der Registrierung als CHIP fortfahren. Dies geschieht mit dem Transaktionscode /ui2/chip.

Gebe einen Namen ein und erstelle den CHIP. Gebe die URL der BSP-Applikation, den Anzeigenamen und die Beschreibung ein. Da es sich um einen CHIP und nicht um eine normale UI5-Anwendung handelt, vergiss nicht, den Pfad zu kpilauncer_dynamic.chip.xml anzugeben.

Nachdem der CHIP erfolgreich registriert wurde, kannst Du nun fortfahren und den neuen CHIP in die Fiori Launchpad-Designerkomponente aufnehmen. Dies kann durch den Aufruf des CUSTOMIZE_COMPONENT aus dem Transaktionscode se80 oder durch Folgen der in der Beschreibung angegebenen URL geschehen.

Man muss über Administratorrechte verfügen, um die Standardkomponente zu ändern. Wir passen die Komponente chip_catalog_config an und die Konfigurations-ID lautet Fiori Launchpad Katalog.

Wie man sieht, gibt es hier bereits benutzerdefinierte Kacheln, die ich in der Vergangenheit erstellt habe. Hier müssen wir also einen neuen Wert hinzufügen. Sei vorsichtig, da der Wert des Parameters genau einem der vorherigen Einträge entsprechen muss. Wir fügen x-SAP-ui2 hinzu.

Lasst uns noch einmal den Namen des CHIPs überprüfen, den wir erstellt haben, Z_mytuttile. Achtung, es gibt dort keine Leerzeichen. Jetzt können wir es speichern, einem Transport zuordnen und es wird dem System hinzugefügt.

Kehren wir zurück zum Fiori Launchpad-Designer, und versuchen, eine neue Kachel hinzuzufügen. Wie man sieht, ist meine benutzerdefinierte Kachel: mYtutorial TILE nun als Option zum Hinzufügen vorhanden. Leider gibt es in diesem Moment noch nichts anderes als die standardmäßige dynamische Kachel, aber das werden wir im zweiten Teil dieses Tutorials ändern.

Kurze Zusammenfassung

Wir hoffen, dass dieser erste Teil des Tutorials hilfreich für Dich war. Wenn Du Fragen dazu hast, zögere nicht, uns zu kontaktieren. Wir werden sie Dir gerne beantworten. Verpasse auch nicht den nächsten Teil, damit Du Dir einen Überblick über den kompletten Prozess verschaffen kannst!

Wie am Anfang des Beitrags erwähnt, ist dieses Video der vierte Teil der Tutorialreihe SAP Fiori Customization Samples.

Der erste Teil zeigt Dir, wie Du ein SAP Fiori Launchpad auf der SAP Cloud-Plattform erstellst und Apps auf dem Fiori Launchpad hinzufügst.

Der zweite Teil erklärt Dir, wie Du Dein Fiori Launchpad für Dich anpassen kannst.

Der dritte Teil veranschaulicht, wie sich ein Single Sign-On zwischen einem Fiori Launchpad, das auf einem BW-System bereitgestellt wird, und SAP Business Objects konfigurieren lässt.

 

Autor dieses Beitrags
Andrei Ghiura Associate
Tel.: +49 (0) 7031 714 660 0
E-Mail: cluj@inspiricon.de

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

 

Maschinelles-Lernen-mit-SAP-HANA-und-SAP-Fiori

Machine Learning mit SAP HANA und SAP Fiori

Was ist maschinelles Lernen und warum ist es so wichtig?

Auf jeden Fall ist es heute in aller Munde. Wir sollten also zunächst einmal klären, warum genau alle Welt so interessiert daran ist.

Der Grund, warum maschinelles Lernen in aller Munde ist, ist die Tatsache, dass es uns in vielen Bereichen gewaltige Fortschritte bringt. Es erlaubt Computern, bestimmte Aufgaben nicht nur auszuführen, sondern die zugrunde liegenden Regeln für die Ausführung dieser Aufgaben im Vorfeld überhaupt erst zu erlernen (also basierend auf historischen Daten aus Erfahrungen zu lernen).

Ein gutes Beispiel ist das Gesundheitswesen. Hier werden Algorithmen für das maschinelle Lernen bereits erfolgreich eingesetzt, um die Anzeichen für ein Reihe schwerer Krankheiten wie zum Beispiel Brustkrebs frühestmöglich zu erkennen und so das Risiko für Patienten zu senken.

Im Finanzwesen kommen Lernalgorithmen zum Einsatz, um Betrugsversuchen auf die Spur zu kommen und Geldwäsche zu bekämpfen. Derartige Algorithmen können Abermillionen von Transaktionen analysieren und dabei verdächtige Muster erkennen und offenlegen.

Im Bereich der Online-Sicherheit werden Algorithmen für das maschinelle Lernen eingesetzt, um verdächtiges Verhalten zu beobachten und Datenschutzverletzungen zu erkennen.

Und nicht zuletzt ist maschinelles Lernen schon längst Teil unseres Alltags. Egal, ob wir mit Siri auf unseren Apple-Geräten oder mit Alexa über unseren Echo kommunizieren, in den sozialen Netzwerken unterwegs sind oder uns von Google Maps leiten lassen, den Kern all dieser Systeme bilden maschinelle Lernalgorithmen.

Auch im Tagesgeschäft vieler Unternehmen sorgen diese Algorithmen für die Automatisierung grundlegender Aufgaben, die früher von Hand verrichtet wurden, so zum Beispiel bei der Prüfung von Rechnungen auf Duplikate, Bestellungen und vielem mehr. …

Im Bereich Business Intelligence nimmt maschinelles Lernen als Bestandteil von Predictive-Analytics-Verfahren ebenfalls ein wichtige Rolle ein und ermöglicht es Mitarbeiten, bestimmte Ergebnisse zu prognostizieren. So können im Vertrieb zum Beispiel Vorhersagen zu Verkaufszahlen getroffen werden und Führungskräfte können verschiedene Prognosen zu den möglichen Auswirkungen von Entscheidungen auswerten und so ihre Entscheidungsfindung unterstützen.

Aber wie funktioniert es?

Machen wir einen kleinen Test:

  • 2 → 4
  • 3 → 9
  • 5 → 25
  • 6 → ?

Die richtige Antwort ist natürlich 36. Und der Grund, warum du das wusstet, ist die Tatsache, dass du ein Muster erkannt hast. Und genau so arbeiten auch maschinelle Lernalgorithmen. Sie werden anhand von Beispieldaten trainiert und lernen auf diesem Wege, Muster zu erkennen und diese Muster den richtigen Reaktionen zuzuordnen (aus Erfahrung lernen). Nach Abschluss des Trainings können wir den Algorithmus mit neuen Daten füttern und erhalten (hoffentlich) die richtige Antwort auf unsere Abfrage.

Natürlich sind diese Algorithmen auf die Bearbeitung von Problemen ausgelegt, die um ein Vielfaches komplexer sind als unser kleiner Test und zudem unzählige Eingabewerte erfordern. So stellen auch komplexe Aufgaben wie Bild- und Spracherkennung oder die Vorhersage möglicher Vertriebsergebnisse anhand von historischen Marktdaten kein Problem dar.

 Maschinelles Lernen mit SAP HANA und Fiori

Als viel diskutiertes Thema weckt maschinelles Lernen natürlich auch Neugier und Experimentierfreude und auch wir bilden da keine Ausnahme. Bei Inspiricon stellte sich vor allem die Frage, welchen Mehrwert dieser neue Trend in unseren angestammten Fachgebieten wie BI, SAP Fiori und SAP HANA entfalten könnte.

Dabei hat sich gezeigt, dass SAP HANA das maschinelle Lernen bereits heute schon sehr beachtlich unterstützt. Mit der SAP HANA Predictive Analytics Library ermöglicht SAP die Verwendung von maschinellen Lernalgorithmen und sogar den Aufbau von neuronalen Netzen. Nutzt man diese Stärken und verbindet sie mit SAP Fiori, lassen sich einige hochinteressante Anwendungen im Bereich der Predictive Analytics realisieren. So konnten wir beispielweise ein kleine Fiori-Anwendung für die Prognose von Verkaufszahlen in den einzelnen Filialen einer Supermarktkette erstellen. Die folgende Abbildung zeigt einen groben Überblick über die Architektur dieser Anwendung:

Architecture-Application-Machine-Learning

Die von uns entwickelte Fiori-Anwendung wäre vor allem für Führungskräfte interessant und würde es ihnen erlauben, innerhalb der Anwendung die Prognose bis zum Jahresende auszuwerten. Wir beschäftigen uns auch weiterhin mit diesem Szenario und arbeiten daran, es um zusätzliche Funktionen wie zum Beispiel “Was-wäre-wenn-Szenarien” zu erweitern, über die sich die Auswirkungen von Management- und Marketingentscheidungen (z. B. Werbeaktionen) auf die prognostizierten Verkaufszahlen untersuchen lassen:

Fiori-Predictive-Demo-Machine-Learning

Fazit

Maschinelles Lernen ist schon mit einem einfachen HANA-Backend möglich!

Zwar gibt es am Markt bereits umfassende und leistungsstarke Tools wie z. B. Tensorflow für neuronale Netzwerke oder SAP Predictive Analytics, aber ihr solltet unbedingt wissen, dass diese für einen Einstieg in das Thema nicht unbedingt zwingend erforderlich sind. Wie schon oben gesagt, erhaltet ihr mit SAP HANA schon alles, was ihr braucht. Und mit SAP Fiori lassen sich UI-Anwendungen realisieren, die das implementierte Szenario optimal unterstützen. Für die vorausgehende Analyse der Daten stehen euch leistungsstarke und zudem kostenlose Analysetools wie Python (Pandas) oder R zur Verfügung. Daraus kann sich ein durchaus sehr attraktiver Ansatz ergeben, der sich auch ohne zusätzliche Lizenz- oder Infrastrukturkosten umsetzen lässt und insbesondere für kleinere Probleme geeignet ist, die auch ohne intensive Datenverarbeitung auskommen.

Für welchen Ansatz ihr euch letzten Endes entscheidet, hängt ganz allein von dem jeweiligen Anwendungsfall ab und sollte vom Entwicklungsteam genau durchdacht sein. Ein wichtiger Faktor, der bei der Entscheidungsfindung nicht außer Acht gelassen werden darf, sind die Kosten, die durch Pflege und Lizenzen entstehen.

Quellenangabe der Bilder:  Inspiricon AG

Autor dieses Beitrags
Gerald Iakobinyi-Pich Solution Architect
Tel.: +49 (0) 7031 714 660 0
E-Mail: cluj@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