Beiträge

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 eröffnet neue Niederlassung in Freiburg im Breisgau

Der Standort fokussiert sich auf Big Data, Machine Learning und neue SAP-Technologien

 Böblingen/Freiburg, 13.04.2018 – Inspiricon wächst weiter! Am 01. Februar 2018 eröffnete Inspiricon AG die neue Niederlassung in Freiburg.

„Die Nähe zu unseren Kunden und Mitarbeitern sowie ein regionaler Bezug sind uns sehr wichtig – daher haben wir uns strategisch für Freiburg entschieden.“ So Andreas Keller, Associate Partner bei Inspiricon AG und Niederlassungsleiter Freiburg. „Unser Team hier wird sich neben den klassischen SAP BI Themen schwerpunktmäßig mit Big Data, Machine Learning und neuen SAP-Technologien beschäftigen.“

Mit der Eröffnung der neuen Niederlassung in Freiburg ebnet Inspiricon den Weg für die nächsten Jahre: es steht nun ausreichend Fläche für zukünftiges Wachstum zur Verfügung und weitere Niederlassungen sind bereits in Planung.

Bereits im Februar wurden die neuen Räumlichkeiten in der Schwarzwaldstraße 78b in Freiburg bezogen. Die Bürofläche liegt im 2. Obergeschoss des Zentrum Oberwiehre (ZO) und ist so optimal angebunden.

Die offizielle Büroeinweihung fand am 12. April 2018 statt, zu der Kunden und Unternehmen aus der Region eingeladen waren. Teil des Programms waren neben Networking mehrere Impulsvorträge:

  • Daniel Schauwecker, Lead Consultant Visualisation bei Inspiricon AG, gab Insights zu Supply Chain Visibility via Real-Time Cargo Tracking and Monitoring.
  • Andreas Keller berichtete von seinem Projekt (Abnahme erfolgte Ende Feb. 2018) im Auswärtigen Amt: Mit SAP HANA & SAP BI: Mit öffentlichen Internet-Quellen zur politischen Krisenfrüherkennung.
  • Auch die aktuelle Forschung kommt nicht zu kurz: Zusätzlich konnte Herr Dr. Marcus Vogt, Professor an der Dualen Hochschule Baden-Württemberg Stuttgart für einen Vortrag gewonnen werden: Enough Data is not Enough – Ein Blick in die Data Science.

Eingerahmt wurde der Abend von lockerer Atmosphäre und interessanten Gesprächen.

„An diesen exzellenten Standort haben wir ein Büro geschaffen, das unser zukünftiges Wachstum sichert und für die notwendige Kundennähe zu den Firmen in der Region schafft.“, so Claudio Volk, Vorstand Inspiricon AG.

Anschrift der Niederlassung Freiburg:
Inspiricon AG, Schwarzwaldstraße 78b, 79117 Freiburg

Die Pressemitteilung können Sie hier auch als PDF herunterladen.

Inspiricon_Freiburg_ SAP-Stammtisch

Inspiricon Office Freiburg SAP Stammtisch Eröffnung

Inspiricon Office Freiburg SAP Stammtisch Eröffnung

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

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. 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:

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
Wie man Informationen mit SAP Fiori in Echtzeit auswerten und visualisieren kann

Wie man Informationen mit SAP Fiori in Echtzeit auswerten und visualisieren kann

Hallo,

heute stellen wir euch ein Kundenprojekt vor, bei dem es um die Einführung der Datenauswertung und -visualisierung in Echtzeit ging.
Lasst uns direkt in das Projekt einsteigen:

Unser Kunde

Die ERCO GmbH, ist ein international führender Spezialist für Architekturbeleuchtung mit LED-Technologie. Das Familienunternehmen ist in rund 55 Ländern mit etwa 1.000 Mitarbeitern vertreten.

Die Ausgangssituation

ERCO hat uns damit beauftragt, eine App zu entwickeln, die KPIs nicht nur anzeigen kann, sondern zudem den Anwendern auch die Möglichkeit bietet, die KPIs direkt zu kommentieren. Zum Beispiel für Soll-Ist-Vergleiche oder ähnliches. All diese Informationen zusammen genommen unterstützen die Vertriebssteuerung.

Die Anforderungen

Durch die Einführung einer SAP Fiori Applikation mit Anbindung eines SAP BW Systems sollte eine Optimierung des Informationsaustauschprozesses zwischen Vertriebsmitarbeitern und der Geschäftsführung erreicht werden.

Daraus ergaben sich folgende Projektanforderungen für uns:

  • Reports und Feedback-Möglichkeiten sollen für Vertriebsmitarbeiter einfacher zugänglich werden – inklusive mobiler Zugriffe.
  • Reports sollen in Echtzeit generiert werden.
  • Kommentare und Schätzungen von Vertriebsmitarbeitern sollen ebenfalls in Echtzeit erfasst und zentral abgespeichert werden.
  • Geschäftsführer sehen die konsolidierten Daten, sobald sie von den Vertriebsmitarbeitern erfasst wurden.

Das Projektziel

Wir hatten die Entwicklung einer mobilen App für das iPad vor Augen, die alle ca. 250 Außendienstmitarbeiter nutzen sollen, um ihre wichtigsten Vertriebskennzahlen stets im Blick zu haben. Übergeordnetes Ziel der mobilen App war es, den Außendienstmitarbeitern unabhängig von Zeit und Ort die Möglichkeit zu geben, sich über ihre aktuelle Vertriebsperformance zu informieren.

In der folgenden Grafik seht ihr – natürlich stark vereinfacht – die Projektschritte, die Veränderungen sowie Vorteile der SAP Fiori Applikation:

Inspiricon ERCO-Projekt

Am Ende stand ein mobiler, schlanker und vor allem sehr einfacher Prozess für das Monitoring und für die Anpassungen der Prognosen zur Verfügung. Mitglieder der Geschäftsführung und Vertriebsmitarbeiter haben damit immer die aktuellsten Daten zur Verfügung. Dies führt zu einer erheblichen Wertsteigerung der Daten. Das ist vor allem im Business Intelligence-Umfeld entscheidend, denn dort ist der Wert einer Information abhängig von ihrem Aktualitätsgrad.

Wir freuen uns, dass unser Kunde nach Einführung der SAP Fiori Applikation sehr zufrieden ist. So sagte Celina Berg, Projektleiterin der ERCO GmbH, nach Abschluss des Projektes:

„Inspiricon hat das Projekt professionell von Anfang bis Ende erfolgreich durchgeführt. Die Kommunikation war offen und direkt. Der Status des Projektes war jederzeit transparent. Unser Projektziel wurde in Time & Budget erreicht. Wir freuen uns, mit der Inspiricon auch in der Zukunft zusammen zu arbeiten.“

Auch wir sind gespannt auf weitere gemeinsame Projekte! Die Success Story zu diesem Projekt findet ihr auf unserer Webseite.

Wenn ihr mehr über SAP Fiori erfahren wollt, schaut doch mal in unserem Blog vorbei.

Autor dieses Beitrags
Gerald Iakobinyi-Pich Solution Architect
Tel.: +49 (0) 7031 714 660 0
E-Mail: cluj@inspiricon.de

Ein Erfahrungsbericht zum Upgrade auf SAP BW 7.5 oder „Unverhofft kommt oft“

Hallo zusammen,

heute gibt es einen Erfahrungsbericht aus einem unserer letzten Kunden-Projekte. Es ist immer wieder spannend zu den ersten zu gehören, die mit neuen Releases, Support-Packages oder Tools arbeiten dürfen. Allerdings gibt es hierbei durchaus Tücken. Von einer solchen Überraschung handelt dieser Bericht.

Wir entwickelten im Rahmen einer Migration sehr viele Daten-Modelle basierend auf den „neuen“ Objekten ADSO (Advanced Datastore Objects) und Composite Provider, um diese als HANA-Views verfügbar zu machen und anschließend mit Native HANA-Mitteln weiterzuverarbeiten.

In diesem Beitrag konzentrieren wir uns auf ein Problem, welches beim Upgrade von SAP BW 7.4 auf BW 7.5 auftrat. Dieses Upgrade fand während unseres Projektes statt.

Wie gesagt unsere Datenmodelle basieren hier vor allem auf ADSOs. Diese ADSOs können so modelliert werden, dass sie sich wie ein Cube verhalten oder wie ein klassisches DSO. Sprich entweder sie haben einen dedizierten Schlüssel (Variante DSO) oder alle Merkmale bilden gemeinsam den Schlüssel (Cube).

Ein weiterer Unterschied zwischen einem Cube und einem DSO ist, wie die Einheiten von Kennzahlen verwendet werden:

Bei Cubes gehört die Einheit zur Kennzahl: sie werden bei Transformationen in einer Regel verarbeitet.

cube-regel

Bei DSOs sieht es etwas anders aus. Hier wird die Einheit als separates Feld behandelt (also in Transformationen in 2 Regeln).

DSO

DSO-Feld

Unter SAP BW 7.4 wurden alle ADSOs wie DSOs behandelt (zwei Regeln).

Wir staunten also nicht schlecht, als nach dem Upgrade die Transformationen zu allen ADSOs, die wie Cubes modelliert waren, nicht mehr funktionierten. Wir erhielten keine Fehlermeldungen, vielmehr kam es zu Verschiebung der Daten zwischen den Feldern. Es waren ja jetzt weniger Felder in der Zielstruktur. Als wir dann versuchten die Transformationen zu untersuchen, erhielten wir folgenden Fehler:

Transformation-Fehler

Wie erwähnt kam der Fehler nicht direkt und auch die Datentransferprozesse (DTPs) liefen teilweise „sauber“, also ohne Fehlermeldung. Die Transformationen selbst wurden als aktiv angezeigt. Die Fehlermeldung erschien immer nur dann, wenn die Transformation geöffnet wurde. War keine besondere Logik hinterlegt, wurde sogar, wenn man die Transformation im Änderungsmodus öffnete, als automatischer Vorschlag die fehlende Einheit zugewiesen.

Leider gab es zum damaligen Zeitpunkt keine Korrektur von der SAP! Uns blieb an dieser Stelle nichts anderes übrig, als die Fehler manuell zu korrigieren.

Kennt eine/r von euch das Problem? Gibt es mittlerweile eine Lösung der SAP?

Wir standen vor der Wahl alle ADSOs auf den Modus „Standard-DSO“ umzustellen und dann zu hoffen, dass die automatische Aktivierung die Transformationen wieder korrekt zuordnet.
Oder wir mussten alle Transformationen auf dem Testsystem anpassen.

Die Anpassung des ADSO-Modus war leider nicht möglich, da dies einen großen Einfluss auf unser Datenmodell gehabt hätte. Also hieß es Zähne zusammenbeißen und in einer Hau-Ruck-Aktion mit vereinten Kräften die Transformationen anzupassen. Leider gab es bei komplexeren Logiken größere Komplikationen, da die ungültigen Regeln gelöscht wurden (und die anderen Systeme aktuell nicht verfügbar waren). Wir konnten alle Probleme lösen und das Projekt mit vertretbarer Verzögerung in die nächste Phase bringen. Das ließ sich allerdings nur durch eine geschlossene Mannschaftsleistung erreichen, wie sie in solchen Projekten unerlässlich und für Inspiricon charakteristisch und selbstverständlich ist.

Unsere Erkenntnis in diesem Projekt war, dass neue Tools immer sehr, sehr spannend aber eben auch fehleranfällig sind. Wir versuchen deshalb neue Themen frühzeitig auf unseren internen Systemen zu testen (aktuell finden Versuche mit Predictive Analytics, Lumira 2.0 sowie SAP Leonardo statt).

Leider kann man nicht alles testen und bestimmte Dinge wie Upgrades oder Migrationen sind doch immer wieder sehr individuell. Wir berücksichtigen das in unseren Projekten, indem wir mit entsprechenden Puffern arbeiten und den Kunden über die Risiken und Chancen eines Upgrades aufklären. Gemeinsam entscheiden wir, welche Strategie für das aktuelle Projekt die Richtige ist.

Autor dieses Beitrags
Jörg Waldenmayer Lead Consultant
Tel.: +49 (0) 7031 714 660 0
E-Mail: info@inspiricon.de
Inspiricon SAP-HANA planning application kit 1030x665

Neues von den SAP Planungstools

Heute geht es mal wieder um die Planung. Was ist vom neuen HANA Planning Application Kit zu erwarten und was sind die Unterschiede und Vorteile, wenn man es mit herkömmlichen Standard-Planungsprogrammen vergleicht? Bevor wir diese Frage beantworten, lasst uns zunächst näher auf die Bedeutung von Planung eingehen.

Warum ist Planung so wichtig?

Unternehmen können ihre Entscheidungsfindungen durch eine ordentliche Planung wesentlich verbessern. Mit aktuellen und vergangenen Daten sowie voraussagenden Analysen können sie ihre Ziele für die Zukunft festlegen und steuern. Der Vergleich zwischen aktuellen Daten und Plandaten hilft den Planungsprozess zu verbessern.

Überblick über die SAP BI Planungstools

Wer ordentlich planen möchte, muss in der Lage sein, Daten manuell in ein System einzutragen (eingabebereite Queries). Diese Möglichkeit kann auf verschiedenen Wegen mit zahlreichen Tools erreicht werden, sowohl im BI- als auch im transaktionalen System.

Was Planungstools von einfachen Datenerfassungsfunktionalitäten unterscheidet, ist offensichtlich: Planungstools ermöglichen die Analyse von Daten und die Generierung komplexer Szenarien. Dies kann mit verschiedenen Planungsfunktionen erreicht werden. Diese reichen von simplen Vorgängen wie einfügen, löschen, kopieren und Währungsumrechnung bis hin zu umfassenderen benutzerdefinierten Funktionen. Im Folgenden findet ihr eine Übersicht der SAP BI Planungstools:

Inspiricon Evolution von BI Planung

Inspiricon Evolution von BI Planung

BPS (Business Planning and Simulation)

Anders als bei der Integrierten Planung ist dieses Tool nicht vollständig in das SAP BI-System eingebunden. Einige Funktionen laufen teilweise immer noch auf BPS (z. B. die Kostenstellenkürzung).

Weitere Eigenschaften von BPS:

  • Ebenen der Planung, Planungsfunktionen und Sequenzen werden mit der Transaktion BPS0 erzeugt.
  • Mit BPS0 werden auch manuelle Eintrittslayouts, Filter und Variablen angelegt und nicht mit BEx-Abfragen, Filtern oder Variablen verbunden.
  • Das Frontend ist nicht in den BI-Tools integriert. Stattdessen muss man ein Web-Interface in BPS_WB schaffen.

SAP BI Integrated Planning

Diese Lösung ist vollständig in das SAP BI-System integriert. In der Data Warehouse Workbench werden Datenprovider festgelegt. Mit dem BEx Query Designer werden eingabebereite Queries erzeugt. Alle anderen planungsspezifischen Funktionalitäten wie Planungsfunktionen, Planungsabläufe, Datensegmente und charakteristische Merkmale werden im Planning Modeller definiert. Dieser kann vollständig in eine SAP HANA Datenbank migriert werden, mit dem Vorteil eines verbesserten Lesezugriffs (In-Memory).

Weitere Eigenschaften von SAP BI Integrated Planning:

  • Manuelle Einträge werden direkt im BEx Query Designer erzeugt. Variablen und Filter korrespondieren mit BEx-Variablen und -Filtern.
  • Planungsfunktionen, Sequenzen, Datensegmente, kennzeichnende Zusammenhänge usw. werden in der Transaktion RSPLAN erzeugt.
  • Eine Migration auf die SAP HANA Datenbank ist ohne Anpassungen möglich. Dies führt zu einer schnelleren Reaktionsgeschwindigkeit – davon profitiert auch die Benutzerfreundlichkeit. Die Daten werden nun in einer In-Memory Datenbank gespeichert. Nichtsdestotrotz werden Aggregationen und Kalkulationen weiterhin auf der Anwendungsebene ausgeführt.

SAP Planning Application Kit on HANA

Dieses Tool ist derzeit das Neueste aus dem Bereich Planung. Das Planung-Tool ist im Gegensatz zur obigen Lösung auf In-Memory optimiert. Die Applikation der Business Logik wird von der Applikations-Ebene auf die In-Memory Datenbank verschoben. Dadurch reduziert sich die Datenzirkulation und führt zu einer deutlichen Leistungsverbesserung.

Weitere Eigenschaften des Planning Application Kit on HANA:

  • BW-IP benötigt keine Veränderungen, um mit HANA zu arbeiten. Damit von einer verbesserten Reaktionsgeschwindigkeit profitiert werden kann, müssen die Planungsfunktionen jedoch zuvor migriert werden.
  • Die Ausführung von Kalkulationen In-Memory wird mit dem Planning Application Kit ermöglicht. SAP notes1637199 erklärt die Schritte zur Aktivierung des Kits.
  • Die meisten Planungsfunktionen sind bereits im Planning Application Kit vorhanden (Kopieren, Löschen usw.).
  • Es ist immer noch so, dass nicht alle Planungsfunktionen In-Memory ausgeführt werden können, insbesondere Planungsfunktionen, die auf ABAP exit basieren. Um diese Funktionen In-Memory auszuführen, muss ein SQL-Skript geschrieben werden.
  • Um eine Planungsfunktion zu generieren, die auf einem SQL-Skript basiert, muss ein Funktionstyp geschaffen werden, der auf der ABAP Klasse beruht. Das SQL-Skript wird dann von der Methode Execute abgerufen.
Planung alt/neu

Planung alt/neu

Zusammenfassend kann man sagen, dass mit dem neuen HANA Planungs Kit die gleichen Planungsfunktionen erreicht werden können, die im Standard IP verfügbar sind. Allerdings mit einer grundlegend verbesserten Geschwindigkeit, da eine In Memory-Datenbank genutzt wird.

Lest mehr zum Thema Planung und SAP HANA in unserem Blog.

Euch ist vielleicht aufgefallen, dass wir BPC noch nicht erwähnt haben – dies wird Thema eines nächsten Beitrags sein. Bis dahin!

 

Autorin dieses Beitrags
Gabriela López de Haro Senior BI Consultant
Tel.: +49 (0) 7031 714 660 0
E-Mail: info@inspiricon.de
SAL Fiori query runner

Wie ihr mit dem BW Query Runner Reports auf Knopfdruck generiert

Im heutigen Blogartikel geht es um die dritte – und derzeit letzte – SAP Fiori Applikation in unserer Inspiricon Toolbox: der Inspiricon BW Query Runner. Dies ist eine App, mit der die User vorab definierte Queries im BEx Query Analyser abrufen können. Die App ahmt sozusagen die Funktionalitäten des Standardanalyse-Add-Ins von Microsoft Excel nach – jedoch mit einem mobilen Konzept.

Mehr über unsere beiden anderen Apps, Manage Users und Time Tracker, könnt ihr jederzeit in unserem Blog nachlesen.

Die Motivation

Um ganz am Anfang zu starten: wir haben festgestellt, dass es ein Problem mit der Darstellung von BI Daten gibt, wenn man sie von unterwegs abrufen möchte. Dies gilt jedoch nicht für große Datenmengen oder irgendeinen anderen umfassenden BI Prozess. Den BW Query Runner haben wir daher so designed, dass Nutzer, die eine intuitive Art und Weise für den Zugang zu ihren Daten benötigen, dies schnell, einfach und mobil tun können.

Die Zielgruppe

Mit dieser Fiori Applikation wollen wir hauptsächlich die Leute erreichen, die ihre Geschäftsdaten jederzeit und überall abrufen möchten und so unabhängiger arbeiten können.

Die Lösung

Unsere Inspiricon Toolbox-Komponente BW Query Runner ist eine Lösung, die wir als eine Art „Schweizer Messer“ für unsere Zielgruppe entwickelt haben. Anstatt eine Fiori App für jede einzelne Anforderung zu bauen, wollen wir einen Vorgeschmack darauf liefern, was diese neue Technologie alles kann – so entstand diese SAP Fiori Applikation. Nachdem wir bereits einige benutzerdefinierte Apps erstellt hatten, über die wir zuvor berichtet haben, haben wir uns für eine Anwendung entschieden, die – zumindest teilweise – in der Lage ist, sie alle zu ersetzen.

Die technische Seite

Wir nutzen die SAP Gateway Komponente, um die BI Queries in zu verarbeitende OData Services umzuwandeln, die später auch im BW Query Runner genutzt werden. So konnten wir eine nahtlose Integration für den technischen Support unserer Inspiricon Toolbox erschaffen. Einen neuen Query zur Liste der bereits verfügbaren in der Anwendung hinzuzufügen ist jetzt eine Sache von wenigen Klicks (s. FIG.1).

FIG.1: Query hinzufügen

FIG.1: Query hinzufügen

Die praktische Seite

Unsere Fiori App verfügt über eine Palette von abrufbaren Funktionen für die Nutzer, die sowohl die Fähigkeiten der neuen Technologie als auch die BI-Erfahrung von Inspiricon demonstriert.

Darunter folgende:

  • Einfacher Zugang zu einer Liste von vordefinierten Queries, die „maßgeschneidert“ auf die Vorlieben und Bedürfnisse jedes einzelnen Users sind (FIG.2 und FIG.3).
    FIG.2: Vordefinierte Queries

    FIG.2: Vordefinierte Queries

    FIG.3: Vordefinierte Queries

    FIG.3: Vordefinierte Queries

  • Individuelle Auswahl in jeder Query, um immer die beste Nutzererfahrung für die optimalste Leistung abrufen zu können (FIG.4 und FIG.5).
    FIG.4: Individuelle Auswahl

    FIG.4: Individuelle Auswahl

    FIG.5: Individuelle Auswahl

    FIG.5: Individuelle Auswahl

  • Angepasste Filtermöglichkeiten für den Schnellabruf der Daten, die unsere Nutzer benötigen (FIG.6).

    FIG.6: Angepasste Filtermöglichkeiten

    FIG.6: Angepasste Filtermöglichkeiten

Das war unsere kurze Einführung in unsere dritte Applikation der Inspiricon Toolbox: BW Query Runner. Ihr möchtet mehr dazu erfahren? Kontaktiert uns gerne direkt oder schaut auf unsere Webseite und unseren Flyer.

Bleibt dran und erfahrt alles weitere über unsere nächsten Fiori Apps :)!

 

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

So geht effiziente Zeiterfassung im Betrieb: der Inspiricon Time Tracker

Heute präsentieren wir euch die 2. Applikation der Inspiricon Toolbox, den Time Tracker. Diese Applikation dient dazu, die Arbeitszeit der Mitarbeiter direkt zu erfassen.

Warum haben wir uns entschlossen, diese Fiori App zu entwickeln?

Besonders im SAP-Umfeld gibt es viele Firmen, die Lösungen für die Zeiterfassung im Einsatz haben, die auf Excel basieren. Wir haben festgestellt, dass Excel von vielen als das meist genutzte BI Tool für die Zeiterfassung angesehen wird. Unserer Meinung nach ist dies aber nicht effizient genug!

Daher haben wir einen anderen Weg gefunden, um auf SAP BW Daten zugreifen zu können und sie zu analysieren – und zwar mit SAP Fiori und OData Services. Die „Hauptstütze“ der Time Tracker Applikation ist ein Planungscube. Der Datentransfer aus dem Backend wird durch einen Input-bereiten Query ermöglicht, der als OData in die Fiori Applikation eingebunden ist.

Wie funktioniert unsere Fiori App?

Wir erklären euch den Workflow anhand eines Beispiels:

Lasst uns mal davon ausgehen, dass du ein Mitarbeiter in der Firma X bist – eine Firma, die SAP ERP im Einsatz hat. D.h. es werden immer BI Tools für die Visualisierung, Reporting usw. benötigt. Jeden Tag arbeitest du an einem Projekt und an bestimmten Aufgaben dafür. Deine Arbeitszeit für jede noch so kleinste Aufgabe muss genau und nachvollziehbar erfasst werden.

Wie geht das am schnellsten und einfachsten?

Mit dem Inspiricon Time Tracker! Einer browserunabhängigen Applikation, mit der über alle Informationen Buch geführt werden kann. Dies ist von überall und von jedem Gerät aus möglich: PC, Laptop, Tablet oder Smartphone. Natürlich läuft die App in Echtzeit. Wenn dein Vorgesetzter also genau jetzt deinen Stundennachweis benötigt, muss er sich nur einloggen und sieht ihn auf einen Blick.

Oder wenn du z.B. einen Fehler in deiner eingetragenen Arbeitszeit entdeckst. Dann dauert es nur Sekunden, um das zu korrigieren.

Funktionsweise, Umfang und Workflow des Time Trackers

Die Funktionsweise ist einfach und klar. Üblicherweise wird in SAP Fiori Applikationen die Funktionsweise so weit wie möglich aufgesplittet. Wenn es wie in unserem Beispiel um die Zeiterfassung geht, wären mindestens drei Applikationen nötig:

  1. eine um die Zeit zu erfassen,
  2. eine für die Planung
  3. und eine für die Genehmigung.

Der Time Tracker ist die App für die Zeiterfassung.

Im Wesentlichen haben wir einen View für alle Funktionalitäten (FIG.1):

FIG.1: View für alle Funktionalitäten

FIG.1: View für alle Funktionalitäten

  1. Nach Datum filtern: Die Datenbindung zwischen der Zeitintervall-Komponente und der erhaltenden OData war eine Herausforderung und zwar wegen dem ACALLDAY. Aber wir geben nicht so einfach auf! Wir haben den Mock-Up mit dieser Komponente erstellt und das Ergebnis war ein voller Erfolg. Durch diese Komponente ist es möglich ein spezifisches Datum oder ein Intervall auszuwählen, um deine Arbeit zu visualisieren.
  2. Überblick über alle Eingaben: das ist eine Tabellenkomponente mit zusätzlicher Such- und Filterfunktionalität (FIG.2).

    FIG.2: Überblick über alle Daten

    FIG.2: Überblick über alle Eingaben

  3. Arbeitszeit erfassen: man muss nur auf den Log Work Button klicken und ein Fenster mit Formular öffnet sich. Wähle dann das Projekt, die Aufgabe, füge eine Beschreibung deiner Arbeit hinzu, die Anzahl der geleisteten Stunden, klicke dann Log und du hast es geschafft (FIG.3 and FIG.4)!
    FIG.3: Log Work

    FIG.3: Log Work (Desktop)

    FIG.4: Log Work (mobil)

    FIG.4: Log Work (mobil)

  4. Update der Arbeitszeit: dies ist auch ein Fenster, das sich öffnet wenn ein Eintrag aus der Tabelle angeklickt wird – so können die geleisteten Stunden angepasst oder geändert werden (FIG.5).

    FIG.5: Update der Arbeitszeit

    FIG.5: Update der Arbeitszeit

Und dies war der Umfang und Workflow unserer Applikation Time Tracker. Als nächste Schritte planen wir die Planungs- und Genehmigungs-Workflows zu implementieren.

Aller guten Dinge sind 3 

Nächste Woche präsentieren wir euch unsere dritte Fiori Applikation aus der Inspiricon Toolbox: den BEx Query Analyzer. Dabei handelt es sich um eine etwas technischere App als die beiden bisherigen. Nichtsdestotrotz finden wir, dass sie sehr interessant ist und möchten sie deshalb mit euch teilen :)!

Du hast den Artikel zu unserer 1. Applikation, Manage User, verpasst? Macht nichts, er ist jederzeit hier nachzulesen.

Weitere Informationen über die Inspiricon Toolbox findest du auf unserer Webseite und in unserem Flyer SAP BI meets SAP Fiori.

 

Autorin dieses Beitrags
Ana-Maria Pop Lead Consultant
Tel.: +49 (0) 7031 714 660 0
E-Mail: cluj@inspiricon.de
SAP Fiori Stammdatenpflege

Wie man Applikationen baut, die SAP Fiori und SAP BI verbinden

Lasst uns über SAP Fiori sprechen: Wie nutzen wir es für unsere Kunden und was haben wir bisher damit getan?

SAP Fiori bietet uns bei Inspiricon großartige Möglichkeiten. Warum? Weil an unserem Standort in Cluj, Rumänien, die Kernkompetenzen SAP BI und Plattformentwicklung sind – zwei sehr unterschiedliche Bereiche und Technologien. Dank Fiori und SAP HANA haben wir es geschafft, eine Brücke zwischen diesen Geschäftsbereichen zu bauen. Unser Cross Technology Team ist für die Entwicklung der SAP Fiori Applikationen zuständig.

Wir haben bereits einige Projekte erfolgreich abgeschlossen. Und vor allem haben wir die Inspiricon Toolbox geschaffen. Das ist eine Sammlung von Applikationen, die auf der neuen, von SAP empfohlenen Architektur basieren (lest hier mehr über die Inspiricon Toolbox).

Mit der Toolbox möchten wir bestimmte Geschäftstätigkeiten von SAP abdecken, DSO Funktionalitäten ausbauen, Funktionen eines Input-bereiten Query aufrufen (basierend auf einem Planungs-Infocube) sowie den BEx Analyzer nachbilden. Basierend auf diesen Aussagen haben wir die Geschäftsziele definiert und bis dato drei Applikationen erstellt:

  1. Manage Users
  2. Time Tracker
  3. BEx Query Analyzer

Heute präsentieren wir die erste Applikation: Manage Users – Stammdatenpflege leicht gemacht

Diese Applikation ermöglicht CRUD Operationen auf einem Data Store Object (DSO) aus BW auszuführen. Das „Motto” der Applikation lautet: „Als User dieser Applikation möchte ich folgendes tun können

  • einen Überblick über alle User haben,
  • einen User anlegen, updaten, löschen
  • sowie die Userliste zu filtern und zu durchsuchen.“

Schritt für Schritt nähern wir uns einer neuen Applikation

Grundsätzlich mussten wir zuerst einen OData Service kreieren und diesen Service dann mit der SAP Fiori Applikation verbinden. Eine Fiori Applikation basiert auf den SAPUI5 Rahmenbedingungen und den SAP Fiori Design Richtlinien (lest mehr über SAP Fiori Applikationen in unserem Blog). Die Architektur baut auf dem MVC Modell auf. Wir nutzen die sap.m Bibliothek, da unsere Applikationen responsive sein sollen – über alle Devices hinweg: Desktop, Tablet und Smartphones.
Im nächsten Schritt haben wir die Funktionalitäten aufgesplittet und die Architektur erstellt.

Als erstes haben wir über die Anzahl der benötigten Views entschieden, welche Funktionalität zu welchem View gehören soll und welche Komponente zur Funktionalität passt. Was benötigen wir?:

  1. Einen Überblick über alle User; in Bezug auf SAPUI5 ist das eine Liste oder eine Tabelle,
  2. Einen neuen User anlegen, d.h. wir fügen einen neuen View hinzu oder fügen ein Popup dort ein, wo Userdaten eingegeben werden,
  3. Update eines Users, dies entspricht dem Szenario einen neuen User anzulegen.

Struktur und Komponenten erwachen zum Leben

Nachdem wir ein Set von Mock-Ups erstellt haben und unsere Alternativen verglichen haben, wurden die folgende Struktur und Komponenten implementiert:

  1. Überblick: eine Tabellenkomponente, sap.m.Table, ist verbunden mit dem Tabellendatenmodell das automatisch upgedatet wird, sobald eine Änderung im Modell gemacht wird, z. B. das Löschen oder Updaten eines Users (FIG.1 und FIG.2):
    FIG.1: Löschen und Updaten von Usern (Desktop)

    FIG.1: Löschen und Updaten von Usern (Desktop)

    FIG.2: Löschen und Updaten von Usern (Mobile)

    FIG.2: Löschen und Updaten von Usern (Mobile)

  2. Neuen User hinzufügen: für diese Funktionalität haben wir einen neuen View zu unserer App hinzugefügt. Dazu brauchten wir die Route-Komponente, sap.m.routing.Router, und mussten ein Route-Steuerungsprogramm implementieren. Die Hauptkomponente in diesem View ist das „Submit-Formular“, sap.ui.layout.form.SimpleForm (FIG.3 und FIG.4):
    FIG.3: Neuen User hinzufügen (Desktop)

    FIG.3: Neuen User hinzufügen (Desktop)

    FIG.4: Neuen User hinzufügen (Mobile)

    FIG.4: Neuen User hinzufügen (Mobile)

  3. Update User: dies ist ebenfalls ein neuer View, mit einem einfachen Formular (FIG.5, FIG.6 und FIG.7):
    FIG.5: Update User (Desktop)

    FIG.5: Update User (Desktop)

    FIG.6: Update User (Mobile)

    FIG.6: Update User (Mobile)

    FIG.7: Update User

    FIG.7: Update User

  4. Einen User löschen: um einen User zu löschen, benötigten wir nur ein Auswahlprogramm in der Tabelle, einen „Lösch“-Button sowie eine Komponente, die über den Erfolg / Misserfolg des Löschens informiert (sap.m MessageToast).
  5. Filter: wir nutzen sap.m.IconTabBar, das uns gleichzeitig das Filtern erlaubt wenn ein Icon angeklickt wird.
  6. Suche: dies ist eine Komponente, die bereits in der Tabelle vorhanden ist und die wir nur noch mit dem Tabellenmodell verbinden mussten.

Ein sehr wichtiger Aspekt des UI-Entwicklungsprozesses ist der Umgang mit Datenanbindung. Glücklicherweise bietet SAPUI5 eine fertige out-of-the-box Komponente wie „sap.ui.model.odata.ODataModel”, das nur die URL des OData Service benötigt und alle CRUD Abläufe sowie Such- und Filterfunktionen übernimmt.

So entstand die Inspiricon Toolbox und ihre erste Applikation: Manage Users.

Und nun, wie geht es weiter?

Wir ihr seht haben wir heute erst eine Applikation vorgestellt – dabei gibt es ja insgesamt drei in unserem Launchpad! Nächstes Mal geht es dann um den Time Tracker – Zeiterfassung im Betrieb. Also bleibt dran :).

Wir verbinden SAP BI-Anwendungen mit SAP Fiori: Die Inspiricon-Toolbox. Weitere Details findet ihr auch in unserem Flyer.

Ihr möchtet weitere Informationen zur Infrastruktur und der Landschaft von SAP Fiori Applikationen erfahren? Kontaktiere uns jetzt!

 

Autorin dieses Beitrags
Ana-Maria Pop Lead Consultant
Tel.: +49 (0) 7031 714 660 0
E-Mail: cluj@inspiricon.de