OpenSQL 1×1

OpenSQL ist eine Datenbanksprache mit der man bestimmte Operationen auf der Datenbank durchführen kann. Es stammt von der Firma SAP und wurde von der älteren Datenbanksprache SQL abgeleitet.

SQL, Abkürzung für „Structured Query Language“, wurde von Edgar Codd (IBM), Donald Chamberlin und Raymond Boyce, in den 1970er entworfen.

Es ist eine Sprache zum Abfragen und Bearbeiten von Datenbeständen in relationalen Datenbanken und zur Definition neuer Datenstrukturen.

Es gibt drei Kategorien von SQL Befehlen:

  • DML – Data Manipulation Language
    • Einfügen, Ändern, Löschen und lesender Zugriff
  • DDL – Data Definition Language
    • Definition neuer Datenbankstrukturen (Schemas, Tabellen usw.)
  • DCL – Data Control Language
    • Zur Rechteverwaltung und Transaktionskontrolle

In SAP bildet das ABAP Dictionary die DDL- und DCL-Befehle ab. Open SQL beinhaltet die DML Befehle. Wobei hier noch zu erwähnen ist, dass es nur aus einer Untermenge der Schlüsselwörter des Standard-SQL besteht. Nachfolgend eine Auflistung der Open SQL Schlüsselwörter, die verwendbar sind:

Schlüsselwort Funktion
SELECT Daten aus Datenbanktabellen lesen
INSERT Neue Zeilen in Datenbanktabellen einfügen
UPDATE Zeileninhalte in Datenbanktabellen ändern
MODIFY Neue Zeilen in Datenbanktabellen einfügen oder bestehende Zeileninhalte ändern
DELETE Zeilen aus Datenbanktabellen löschen
OPEN CURSOR,
FETCH,
CLOSE CURSOR
Zeilen von Datenbanktabellen über den Cursor lesen

Bevor wir uns den einzelnen Schlüsselwörtern widmen und diese näher erläutern, trägt der folgende Absatz noch zum besseren Verständnis vom Open SQL und seiner Verwendung in SAP, bei.

Ein SAP System ist ein drei Schichten System, bestehend aus UI, Applikationsserver und einer Datenbank. Die Datenbank kann von unterschiedlichen Datenbankenherstellern, wie MaxDB, DB2, Oracle, MSSQL, usw., verwendet werden. (Hier eine vollständige Auflistung der von der SAP unterstützten Datenbanken: http://help.sap.com/saphelp_nw73/helpdata/de/84/0cb892edfbc34290c1685132006662/content.htm)

Da jede von diesen Datenbanken einen unterschiedlichen SQL-Dialekt besitzt, wurde Open SQL eingeführt.

Denn Open SQL ist eine portable und datenbank-unabhängige Sprache. D.h., von allen Programmen bzw. Entwicklungen, die am Anwendungsserver laufen und Open SQL verwenden, können deren Open SQL Befehle auf jeder beliebigen darunter liegenden Datenbank ausgeführt werden.

Genauer gesagt, setzt die ABAP Laufzeitumgebung die Open SQL Befehle in die entsprechende Native SQL Befehle um. Mit Native SQL bezeichnet man das erwähnte spezifische SQL Dialekt der darunter liegenden Datenbank.

Es ist natürlich auch erlaubt Native SQL im ABAP Programm zu verwenden. Dabei arbeitet man mit datenbankspezifischen SQL Anweisungen. Das erlaubt die Einbindung verschiedener Datenbanktabellen, die nicht vom ABAP Dictionary verwaltet werden. Die Einschränkung jedoch ist, dass solche Programme im Allgemeinen nicht auf verschiedenen Datenbanksystemen laufen können.

 

Widmen wir uns nun den oben erwähnten Open SQL Schlüsselwörtern zu:

Schlüsselwort Funktion
SELECT, ENDSELECT Daten aus Datenbanktabellen lesen
INSERT Neue Zeilen in Datenbanktabellen einfügen
UPDATE Zeileninhalte in Datenbanktabellen ändern
MODIFY Neue Zeilen in Datenbanktabellen einfügen oder bestehende Zeileninhalte ändern
DELETE Zeilen aus Datenbanktabellen löschen
OPEN CURSOR,

FETCH,

CLOSE CURSOR

Zeilen von Datenbanktabellen über den Cursor lesen

Wie schon erwähnt sind diese nur eine Untermenge der Standard-SQL Schlüsselwörter, jedoch auch mit einigen SAP-spezifischen Elementen, wie z.B. der Zusatz FOR ALL ENTRIES, angereichert.

Um Datenbestände abzufragen wird das Schlüsselwort SELECT, am häufigsten verwendet. Das Lesen über den Cursor (OPEN CURSOR, FETCH, CLOSE CURSOR) ist auch möglich, jedoch ziemlich selten benutzt. Der Unterschied ist, dass beim Lesen der Daten über einen Cursor, die INTO-Klausel von der SELECT-Anweisung entkoppelt werden kann. Mit OPEN CURSOR wird ein Cursor für die Select-Anweisung geöffnet und danach können die Zeilen der Selektion einzeln in einen flachen Zielbereich gestellt werden.

 

SELECT

Die SELECT-Anweisung wird zum Lesen von Daten aus Datenbanktabellen verwendet und ist in mehrere elementare Klauseln aufgeteilt:

SELECT result: result definiert die Struktur der zu lesenden Daten. Dabei können einzelne Spalten oder komplette Zeilen mit * angegeben werden.

INTO target: die INTO Klausel bestimmt den Arbeitsbereich innerhalb eines ABAP Programms indem die gelesenen Daten gestellt werden sollen.

FROM source: source gibt die Datenbanktabelle oder View an von der gelesen werden soll. Die FROM-Klausel kann auch vor die INTO-Klausel gestellt werden.

WHERE cond: In der WHERE-Klausel werden Bedingungen bestellt, welche Zeilen gelesen werden sollen.

GROUP BY fields: Hiermit werden Gruppen mehrerer Zeilen zu einzelnen Zeilen zusammengefasst. Eine Gruppe ist ein Satz von Zeilen, die in jeder Spalte auf der Liste fields die gleichen Werte enthalten.

HAVING cond: Mit dieser Klausel werden logischen Bedingungen auf die durch GROUP BY  kombinierten Zeilen gesetzt.

ORDER BY fields: Hiermit gibt man eine Sortierreihenfolge der zu lesenden Zeilen vor.

 

Bei fast jeder dieser Klauseln gibt es Zusätze, wie z.B. SINGLE oder DISTINCT beim SELECT-Statement, CORRESPONDING FIELDS OF TABLE bei der INTO-Klausel, auf die ich hier nicht näher eingehen werde. (bei Bedarf liefert die SAP Onlinedokumentation Hilfe mit weiteren Details und konkreten Beispielen)

 

Aggregatfunktionen

Auf einzelnen Spalten von Datenbanktabellen können Aggregatsfunktionen angewendet werden. Aggregate sind zusammengefasste Daten einzelner Spalten.

S1 steht für einzelne Spaltennamen. Der Ausdruck agg steht für eine der folgenden Aggregatsfunktionen:

MAX: liefert den Maximalwert der Spalte

MIN: liefert den Minimalwert der Spalte

SUM: liefert die Summer der Spalte

AVG: liefert den Durchschnittswert der Spalte

COUNT: zählt Werte oder Zeilen;

COUNT( DISTINCT s ) liefert die Anzahl unterschiedlicher Werte in der Spalte s. Mit DISTINCT werden doppelt vorkommende Werte aus der Berechnung ausgeschlossen.

COUNT( * ) liefert die gesamte Anzahl der Zeilen in der Ergenismenge

Der Zusatz AS kann ein Alias, ein alternativer Spaltenname a1, definiert werden.

Nachfolgend ein Beispiel einer Select-Anweisung mit einer Aggregatsfunktion:

Mit dieser Anweisung erhält man den Geschäftspartner mit der höchsten vergebenen Geschäftspartnernummer.

 

Inner Join und Outer Join

Joins geben die Möglichkeit die Datenmenge über mehrere Datenbanktabellen zu selektieren. Bei einem INNER JOIN erhält man nur die Sätze des Kreuzproduktes, zu denen in allen beteiligten Tabellen ein Eintrag existiert.

Bei einem LEFT [OUTER] JOIN werden dagegen aus der linken Tabelle der Join-Verknüpfung auch Sätze selektiert, selbst wenn kein Eintrag in der anderen Tabelle existiert.

Nachfolgend ein Beispiel eines INNER JOINS:

Als Ergebnis würde man einen Datensatz erhalten, wenn dieser in beiden Tabellen vorhanden ist.

Nachfolgend ein Beispiel eines LEFT [OUTER] JOINS:

Mit LEFT OUTER JOIN wird nicht wie beim INNER JOIN nur dann ein Wert zurückgegeben wenn sich die JOIN Bedingung in beiden Tabellen findet, sondern hier kann als Ergebnis auch nur der Inhalt von Tabelle 1 (in diesem Fall BUT000) geliefert werden.

UP TO x ROWS

Mit diesem Zusatz werden die Anzahl der zu liefernden Zeilen an die Datenbank übergeben.

GROUP BY
Nachfolgend ein Beispiel eines GROUP BY:

SUBQUERIES

Mit Subqueries lassen sich eigene SELECT-Anweisung als Bedingung in der WHERE- oder HAVING- Klausel verschachteln.

Hier ein Beispiel eines Sub-Selects:

 

FOR ALL ENTRIES

Mit diesem Befehl werden alle Partner die sich in der internen ABAP Tabelle lt_partnertab befinden selektiert.

Der OPEN-SQL Zusatz FOR ALL ENTRIES ist bekanntlich eine SAP-spezifische Erweiterung und als solche nicht auf den Datenbanksystemen bekannt. Der DB-Optimizer wandelt solche SELECTS in entsprechende SQL Kommandos der Datenbank um.

 

Der Optimizer

Jedes Datenbanksystem verfügt über einen Optimizer. Die Aufgabe des Optimizers ist es, den Ausführungsplan für ein SQL-Statement zu erstellen (z.B. festlegen, ob ein Index- oder Table Scan durchgeführt wird). Es gibt zwei Ausprägungen von Optimizern:

Rule-based

Ein Rule-Based Optimizer analysiert die Struktur einer SQL-Anweisung (hauptsächlich SELECT und die WHERE-Klausel ohne Werte) und den Index der Tabelle(n). Über einen Bewertungsmechanismus entscheidet der Optimizer welches Vorgehen er anwendet, um den Befehl auszuführen.

Cost-based

Ein Cost-Based Optimizer betrachtet zusätzlich einige Werte in der WHERE-Klausel und die Statistiken der Tabellen. Die Statistiken enthalten Low- und High Values der Felder oder sogar ein Histogramm, das die Verteilung der Daten in der Tabelle enthält. Der Cost-Based Optimizer nutzt mehr Informationen über die Tabellen und führt daher meistens zu einem schnelleren Zugriff. Ein Nachteil beim Cost-Based Optimizer ist, daß die Statistiken periodisch auf den neuesten Stand gebracht werden müssen.

 

Rückgabewerte

Ein OpenSQL Befehl liefert folgende Rückgabewerte:

sy-subrc
Konnte der Befehl erfolgreich abgesetzt werden so enthält sy-subrc immer den Wert 0, ansonsten ungleich 0.

sy-dbcnt
Der Inhalt dieses Systemfelds enhält den Wert der durch den Befehl bearbeiteten Zeilen.

 

Neue Open SQL Features ab ABAP® 7.40, SP8

Mit dem Release 7.40, SP5 und SP8, hat sich im Open SQL einiges getan. SAP hat nach einem längeren Stillstand bei Open SQL endlich an den SQL92-Standard, der aus dem Jahre 1992 stammt, angeknüpft und unterstützt nun Features, wie UNION und CASE.

Neue Syntax

Mit 7.40, SP5 gibt es einen neuen SQL Parser im ABAP Kernel und somit auch eine neue SQL Syntax. Das Verwenden dieser neuen Syntax ist auf jeden Fall ein Muss, wenn man die neuen SQL Features nutzen möchte.

Hier die zwei wichtigsten Punkte davon:

  • Aufgelistete Spaltennamen können und sollen durch Komma getrennt werden
  • Bei Hostvariablen soll ein @ vorangestellt werden

Nachfolgend ein Beispiel mit der neuen SQL Syntax:

Open SQL Expressionen

Die Open SQL Expressionen werden in der Spaltenliste nach dem SELECT Befehl verwendet. Das Ergebnis dieser Expression wird direkt auf der Datenbank berechnet und in die entsprechende Spalte geschrieben. Dabei kann man sowohl andere Spalten, als auch Hostvariablen für die Berechnung verwenden.

Dabei ist hier das Stichwort „Code push down“. Diese Strategie ist in letzter Zeit in aller Munde. Ursprünglich wurde es immer nur mit der SAP HANA in Verbindung gebracht. Doch spätestens jetzt, mit diesen neuen Open SQL Features, eröffnen sich ganz neue Möglichkeiten für Entwickler, auch mit einer traditionellen Datenbank darunter.

Mit „Code push down“ soll so viel Anwendungslogik wie möglich, vom Applikationsserver auf die Datenbank verlagert werden. D.h., dass alle rechen- bzw. daten-intensive Logik, die die Datenbank berechnen kann – es auch tut.

Es liegt natürlich im Ermessen des Entwicklers, die Logik sinnvoll auszulagern. In Anbetracht der Performance lässt sich definitiv eine Verbesserung erzielen.

Hier eine Auflistung der Open SQL Expressions

  • Verwenden von Festwerten
  • Arithmetische Kalkulationen (+,-,*,/)
  • Arithmetische Funktionen (ABS, CEIL, FLOOR, DIV, MOD)
  • Verketten von Zeichenketten mit &&
  • Typanpassung mit CAST (momentan nur von DEC zu FLTP)
  • COALESCE Funktion
  • Fallunterscheidung mit CASE

Es können auch mehrere SQL Expressionen miteinander kombiniert und durch Verwendung von runden Klammern, auch priorisiert werden.

Nachfolgend einige Beispiele der SQL Expressionen:

Zu Demozwecken wurde eine eigene DB-Tabelle ‚ZDATENTYPEN‘ verwendet, deren Spaltennamen, nach den Datentypen der jeweiligen Spalte, vergeben wurden.

Beispiel einer arithmetischen Kalkulation:

Ergebnis:

bsp1

Erklärung: Beispiel einer einfachen Addition. Sie ersten drei Spalten werden direkt ausgegeben. Die vierte Ausgabespalte zweigt den Wert der dritten Spalte + 100. Der Spaltennamen der vierten Spalte lautet „I4CALC“.

Beispiel einer arithmetischen Funktion:

Hier ein Beispiel einer Auf- und Abrundung:

Ergebnis:

bsp2

Erklärung: Mit der arithmetischen Funktion CEIL findet eine Aufrundung, mit FLOOR eine Abrundung statt.

Beispiel eines Castings:

Ergebnis:

bsp3

Erklärung: In der zweiten Spalte wurde das Feld, das einen dezimalen Datentypen hat, als Float ausgegeben.

!! Achtung: mit SP8 ist der CAST nur von DEC auf FLTP möglich !!

Beispiel Verketten von Zeichenketten:

Ergebnis:

bsp4

Erklärung: In der dritten Spalte werden die ersten zwei Zeichenketten zusammen, durch ein Semikolon getrennt, ausgegeben.

Beispiel COALESCE:

Ergebnis:

bsp5

Erklärung: Liefert die Join-Verknüpfung ein Ergebnis aus der BUT020, wird die Adressnummer in die zweite Spalte geschrieben, ansonsten wird der Wert „NO ADDRESS“ hineingeschrieben.

Beispiel einer Fallunterscheidung mit CASE:

Ergebnis:

bsp6

Erklärung: In der zweite Spalte, vom Namen TYPE_DESC, wird je nach TYPE = 1, der Wert „Person“ und bei TYPE = 2, „Unternehmen“ hineingeschrieben. Bei allen anderen Werten, wird „Unbekannt“ ausgegeben.

Beispiel einer Kombination:

Ergebnis:

bsp7

Erklärung: Hier wurde einer Fallunterscheidung mit CASE und eine Verkettung vom Zeichenketten miteinander kombiniert.

CDS – Core Data Services

Bei den CDS handelt es sich um eine neue Art der View-Definition in SAP. Nachdem es bei den traditionellen Datenbank-Views sehr viele Einschränkungen gibt, wie keine Outer Joins, keine komplexen Joins, keine Kommentare, kein Union, keine View auf eine View usw. , hat sich dahingehend mit den CDS Views ein revolutionärer Fortschritt entwickelt. Es gibt keine Einschränkungen mehr. Mittels Datenbank-unabhängigen DDL statements (Data Definition Language) sind der Kreativität und Komplexität fast keine Grenzen mehr gesetzt.

DDL umfasst die komplette Data Definition Language vom SQL und erweitert es um die Möglichkeit sogenannte Annotationen und Assoziationen zu definieren. Hier eine Auflistung der Möglichkeiten:

  • SQL Funktionen (ABS, CEIL, DIV, DIVISION, CONCAT, COALESCE,…)
  • Parameter
  • Fallunterscheidung mit CASE
  • CASTING
  • Built-In Funktionen (Konvertierungsfunktionen für Währungen und Einheiten)
  • UNION, UNION ALL
  • Associations

Die CDS Views sich vollständig im ABAP integriert. Sowohl im ABAP Dictionary sichtbar, als auch mit den SAP Transportmanagement-Tool transportierbar.

Die Pflege erfolgt mit den ADT (ABAP Development Tools) im Eclipse.

Hier ein kleines, einfaches Beispiel einer CDS View:

cds1

Auch die CDS Views tragen zur „Code push down“ Strategie bei. Sogar mehr als die SQL Expressionen, da es hier durchaus mehr Möglichkeiten gibt.

Der Zugriff auf CDS Views erfolgt mittels Open SQL. Nachfolgend ein paar Beispiele von CDS Views.

Beispiel einer CDS View mit UNION ALL:

cds2

Zugriff auf die View:

Ergebnis:

cds2_result

Beispiel einer CDS View mit einer Währungskonvertierung:

cds3

Zugriff auf die View:

Ergebnis:

cds3_result

ABAP Managed Database Procedures

Als dritter Newcomer und „Code push down“-Vertreter, darf ich AMDP vorstellen. ABAP Managed Database Procedures (AMDP) sind sogenannte Prozeduren, auch bekannt als „Stored procedures“.  Diese sind in nativer Datenbank-Sprache implementiert. Momentan ist SAP HANA, die einzige Datenbank, die AMDPs unterstützt.

Dazu gibt es ein klassenbasiertes Framework, mit dem sich AMDP Prozeduren verwalten und aufrufen lassen. Eine AMDP Klasse implementiert das spezielle Interface (IF_AMDP_MARKER_HDB). Bei der Methodenimplementierung muss die Datenbank und die entsprechende Datenbank-Sprache angegeben werden. Momentan sind nur SQL-Script und die SAP HANA möglich.

Die Pflege von AMDPs erfolgt nur mit ADT (ABAP Development Tools) in Eclipse.

Webinar – ABAP® 7.40 SP5/SP8 Releaseabhängige Änderungen – Unterlagen, Links, …

Unterlagen/Links zum Webinar ABAP 7.40 SP5 SP8 Releaseinformationen

Unsere nächsten Webinar Termine

SAP Online Dokumenation

Videos (Teched, … )

Blogs

Behind the scenes

Hier ein Bild von unserem Webinar. Man beachte, worauf wir die Webcam in der Mitte platziert haben!

20160129_111931

 

 

ABAP® – Das gibt’s ja nicht!

Ich wollte schon länger einmal über ein paar seltsame Dinge in ABAP schreiben. Es gibt nämlich ein paar Sachen in ABAP bei denen man sich einfach nur wundert. Na dann, fangen wir mal an:

BSEG, MARA oder DMBTR

Wer kennt sie nicht, die berühmten SAP ECC Tabellen BSEG oder MARA. Auch die Felder DMBTR oder GSBER sind sicher jedem bekannt.

Aber warum gibt es eigentlich solche komischen Kürzel, haben die Entwickler hier einfach ein paar Buchstabenwürfel verwendet? Natürlich nicht, das sind ganz einfach Relikte
aus R/2. Übrigens, DMBTR steht für „Deutsche Mark Betrag“!dmbtr

In R/2 waren nur 4stellige Tabellennamen und 5stellige Feldnamen erlaubt. SAP hat zwar damals mit R/3 eine völlig neue Technologie geliefert, aber viele ABAP Codes, Tabellen und Prozesse wurden einfach 1:1 übernommen. Und bis dato hat sich bei SAP offensichtlich niemand getraut hier einzugreifen.

Das älteste Programm das ich in einem aktuellen ECC gefunden habe, weißt Kommentare aus dem Jahr 1989 auf!

Bin schon jetzt gespannt, ob wir die Tabellen in S/4 HANA wiederfinden.

 

FOR ALL ENTRIES

Manche ABAP Entwickler schwören auf den FOR ALL ENTRIES Zusatz, manche verteufeln ihn. Ich bin da gespalten denn eigentlich mag ich das Zeug überhaupt nicht, aber andererseits komme auch ich manchmal nicht darum herum.

Aber was ich wirklich – sagen wir mal bescheiden – finde ist, wie ein SELECT mit FOR ALL ENTRIES reagiert, wenn die FOR ALL ENTRIES-Tabelle leer ist. Es werden einfach alle sonstigen Selektionsbedingungen komplett ignoriert und ein kompletter Tablescan durchgeführt. Ohne ersichtlichen Grund.

Hier ein Auszug aus der SAP Online Original Dokumentation:

Before using an internal table itab after FOR ALL ENTRIES, always check that the internal table is not initial. In an initial internal tables, all rows are read from the database regardless of any further conditions specified after WHERE. This is not usually the required behavior.

Nicht zu vergessen ist, dass FOR ALL ENTRIES auf unterschiedlichen Datenbanken teilweise ganz unterschiedlich performant ist. Es gäbe noch viele weitere Argumente (Bufferung, .. ) FOR ALL ENTRIES nicht zu verwenden, aber belassen wir es erst einmal dabei.

Man merke sich jedenfalls: Immer die Größe der FOR ALL ENTRIES Tabelle vor dem SELECT überprüfen – oder noch besser, über Alternativen wie JOINs oder Subselects nachdenken.

 

POOL/Cluster Tabellen

Oh, wie ich diese POOL und CLUSTER Tabellen liebe. Von der Technologie her betrachtet meiner Meinung nach einfach ein ziemlicher Schwachsinn. – Aber auch für diese Technologie gibt es einen triftigen Grund: Wie oben erwähnt waren in R/2 Tabellen nur max. 4stellig. Irgendwann ist SAP dann mit der 4stellen Limitierung einfach an Grenzen gestoßen und hat daher versucht hinter einer Tabelle mehrere Tabellen abzubilden. Das war die Geburt der POOL/CLUSTER Tabellen!

Aber es gibt Hilfe! Wenn wir dann einmal alle auf SAP Hana umstellen bekommen die POOL/CLUSTER Tabellen nach so vielen Jahren endlich ihren verdienten Ruhestand.

Es wäre aber nicht SAP wenn sie für den Vorgang nicht auch einen Namen gefunden hätte: „Depooling/Declustering“.

 

ABAP Open SQL und SQL92

SAP hat mit den aktuellen NetWeaver Releases 7.40 SP5, SP8 und SP12 bzw. NetWeaver 7.50 ein paar wichtige Erweiterungen in das ABAP Open SQL aufgenommen und nähert sich so nach und nach dem Standard SQL92. Manche ABAP Entwickler sind deswegen (SQL Expressions, CDS Views, … ) in heller „Juhu!“ Aufregung!

Liebe Entwickler, bitte vergesst nicht – das 92 hinter SQL Steht für das Jahr! Im Jahr 1992 wurde der Standard definiert. Diese jetzt aufgenommenen Erweiterungen werden von allen namhaften Datenbanken bereits seit Jahrzehnten unterstützt.

Ich meine, eine Erweiterung von ABAP Open SQL war seit Jahren längst überfällig!

 

TCURX

In der TCURX ist gecustomized, wie die Dezimalstelle von Währungen in einem SAP zu interpretieren sind. Wieso das?

Geboren wurde die Tabelle noch im R/2, als auch noch Währungen wie die italienische Lira existiert haben. Die Lira waren teilweise so „groß“ dass die Betragsfelder im R/2 nicht mehr ausgereicht hätten. Also hat man kurzerhand die Kommastellen laut Datenbank außer Kraft gesetzt und dafür die Tabelle TCURX erschaffen. Erst wenn eine Währung nicht in der TCURX enthalten ist, gelten für die Währung die 2 Nachkommastellen.

Im Bereich von Schnittstellen ist das immer wieder ein extra Aufwand – nur um die Betragfelder hin und her zu konvertieren. Beispielswiese für YEN.

Ob man hier nicht irgendwann einmal eine besser Lösung hätte finden können?

 

Jetzt also doch, CODE PUSH DOWN

Jahrelang hat SAP ihren Kunden und uns Entwickler gesagt, DB Nahe Operationen (EXEC SQL, DB Hints, … ) nur in begründeten Fällen und mit Vorsicht zu verwenden. Man verliere so die Unabhängigkeit zur Datenbank oder hat natürlich einen Adaptierungsaufwand wenn gleiches Coding mit verschiedenen Backend-Datenbanken laufen soll.

Nun, da SAP jetzt mit SAP Hana ja eine eigene tolle Datenbank hat, sieht die Sache natürlich etwas anders aus. Jetzt empfiehlt SAP sogar direkter auf der Datenbank „operieren“ um deren Vorteile auch wirklich nutzen zu können. Das Modewort dafür ist „Code Push Down“. Aus ABAP Sicht werden darunter die CDS Views, die AMDB Prozeduren und die SQL Expressions verstanden. Auf der SAP Hana ist darunter z.B. SQL Script zu verstehen.

Nicht falsch verstehen, ich bin ein großer Fan von SAP Hana. Die ist einfach – sorry für den Ausdruck – Sauschnell!

Ich find es halt einfach nur interessant.

 

SAP® CodeJam SAPUI5® hosted von Cadaxo

Am 5. November 2015 veranstalte die Firma Cadaxo gemeinsam mit der SAP die erste SAPUI5 CodeJam in Wien. Zweck dieser CodeJam war es Entwickler zusammenzubringen, um gemeinsam die neue SAP Technologie SAPUI5 kennenzulernen, gemeinsam auszuprobieren, praxisnah zu entwickeln und dabei Spaß haben.

Die SAP Expertin Denise Nepraunig führte diese Veranstaltung und stand den Teilnehmern mit Rat und Tat zur Seite. Nach einer kleinen Einführung in die Materie, dem Kennenlernen des WebIDE, der Entwicklungsumgebung für SAPUI5 Apps, ging es gleich ran an die Tasten.
Sowohl Erfahrene SAPUI5 Entwickler, als auch Beginner befassten sich intensiv mit dem Thema und konnten am Ende des Tages beachtliche, eigens-programmierte SAPUI5 Apps vorweisen.

IMG_0172 IMG_0173

 

Trotz der anstrengenden Arbeit, kam der Spaß nicht zu kurz:

IMG_0189 IMG_0117IMG_0151

Dieses hervorragende Mittagessen haben wir uns redlich verdient:

IMG_0250 IMG_0236 IMG_0248

Nach getaner Arbeit haben wir den Abend bei dem einen oder anderen Glas Bier und Wein, gemütlich ausklingen lassen…

IMG_0264

Wem die Fotos nicht genügen, hier noch ein kurzes Video über die SAPUI5 CodeJam: SAP CodeJam SAPUI5 Wien

Nach so viel positives Feedback, können wir beruhigt sagen, dass es ein gelungenes Event war, bei dem für jeden was dabei war. Ich freue mich schon auf die nächste SAP CodeJam in Wien.

Ich möchte mich auch bei allen Teilnehmern bedanken und natürlich aus bei Denise! CodeJam rocks!

 

HCP IoT Raspberry Demo

iotdemo0

Im Jahr 2015 ist mit dem  Begriff IoT ein neuer IT Trend vermehrt aufgetaucht. Gartner zählt IoT als einen der 10 wichtigsten IT Trends des Jahres 2016:

http://www.gartner.com/newsroom/id/3143521

Ich habe dies zum Anlass genommen und wollte die in der HCP zur Verfügung gestellten Services im IoT Bereich einem Praxistest unterziehen. Um den neuen IoT Service der HCP zu testen habe ich meinen RaspberryPi als Sensor Datenlieferant umfunktioniert.

Hierzu gibt es unzählige Guides und unterschiedliche Sensoren auf die ich hier nicht genauer eingehen möchte. Für mein Beispiel habe ich jedenfalls einen DHT22 (Temperatur/ Luftfeuchtigkeit) von AdaFruit verwendet. Er soll seine Daten später zum IoT-Service der HCP schicken.

 

Einrichten der HCP

Zuerst benötigen wir einen Account auf der HCP Trial. Dieser kann via https://account.hanatrial.ondemand.com erstellt werden. Haben wir unsere Zugangsdaten erhalten so aktivieren wir zuerst im Menüpunkt Services den „Internet of Things Service“:

iotdemo1

Die HCP generiert nun ein Schema und auch eine Java Applikation welche wir im über den Menüpunkt Subscriptions(iotcockpit) sehen können und auch starten wollen. Im IoT Cockpit ist es nun ganz wichtig im Menüpunkt Roles den eigenen User zuzuweisen. Da es hier bei mir immer zur Verwirrung gekommen ist habe ich kurzerhand beide User assigned die in der HCP immer wieder auftauchen(also s-User und s-User+trial).

iotdemo2

Ist dies erledigt finden wir im Punkt Overview die Start-URL zu unserem IoT Cockpit.

iotdemo3

Mit einem Klick auf die URL starten wir nun das Cockpit.

Devicekonfiguration

Im Cockpit müssen wir nun unsere Devices konfigurieren, damit unser IoT Service auch mitbekommt welche Geräte Sensordaten schicken dürfen.
Dazu bekommen wir pro registriertem Device einen Token, doch dazu später mehr. Im Device Management sehen wir nun die 3 Kacheln:

  • Device Types
  • Message Types
  • Devices

In dieser Reihenfolge werden wir nun auch vorgehen um unser IoT zu konfigurieren.

Device Types

Zuerst legen wir mit einem Klick auf die Kachel „Device Types“ den Device Type an. Am unteren Ende findet man einen Button mit einem Plus. Hier muss man sonst eigentlich nur einen Namen vergeben.

Message Types

Nun weiter zum Message Type. Hier definieren wir eine Struktur wie die Daten geliefert werden sollen. Mit dem Plus am unteren Ende können wir nun einen neuen Namen auswählen und im Folgeschritt die Struktur definieren. In meinem Fall habe ich hier den Namen temperatur gewählt mit 2 Feldern, temperatur(Temperatur) und humidity(Luftfeuchtigkeit).

iotdemo4

Device

Auch hier beim Device haben wir wieder ein ähnliches vorgehen. Mit dem Plus unten legen wir das neue Device an und wählen unseren Namen gemeinsam mit der Device Type die wir im Schritt 1 angelegt haben.

Ist das Device angelegt bekommen wir in einem Popup einen OAuth token angezeigt.

In der Registerkarte Information sehen wir nun eine generierte Device ID, diese gemeinsam mit dem OAuth token aus dem Poup im Anlegeprozess zuvor brauchen wir in einem späteren Schritt. Deshalb bitte Beides notieren.

Geschafft unser Device ist nun eingerichtet!

Zurück im Overview starten wir nun die Kachel „Deploy Message Management Service“.

iotdemo5

Auf Deploy klicken, Popup bestätigen und die angezeigte URL klicken, damit wird das HCP Cockpit gestartet.

iotdemo6

Hier sehen wir nun im Overview beim Punkt State, dass der Service am Starten ist. Es kann sein, dass es bis zu 5 Minuten dauert bis der Status auf Grün und gestartet ist.

Ist der Status einmal auf Grün so können wir von unserem Cockpit Daten zum IoT Service schicken.

Hierzu gibt es auf GitHub ein Starterkit(basierend auf PYTHON) welches man verwenden kann: https://github.com/SAP/iot-starterkit

Ich habe mich jedoch für PHP mit der cURL Extension entschieden, da ich bereits ein PHP Script hatte welches die Daten für einen anderen Service zur Verfügung stellte.

Die in eckige Klammern gesetzten Zeichen:

[USER]: HCP Trial User
[MessageTypeID]: Message Type ID aus dem Cockpit
[oAuth Token]: oAuth Token aus dem Cockpit des registrierten Device
[DeviceID]: DeviceID aus dem Cockpit des registrierten Device

Bitte mit den zuvor notierten Daten richtig versorgen:

Dieses Script habe ich in der Crontab des auf Linux basierenden Raspbian Betriebssystem eingetragen und wird in meinem Fall alle 5 Minuten aufgerufen.

Das Ergebnis können wir nun in unserem MMS Cockpit betrachten, welches wir aus dem iot Cockpit heraus mit der Entsprechenden Kachel starten können.

iotdemo7

Weiterführende Links

https://de.wikipedia.org/wiki/Internet_der_Dinge

https://help.hana.ondemand.com/iot/frameset.htm

CL_ABAP_GZIP – Komprimieren von Strings oder binären Inhalten in ABAP®

Allgemeines

Die Komprimierung von großen Dateien, die so genannte Datenkompression bzw. Datenkomprimierung, durch entsprechende Programme, ist im täglichen Gebrauch nicht mehr wegzudenken. Die Datenkomprimierung reduziert nicht nur wertvolle Speicherplätze, eine geringere Datenmenge beim Austausch zweier Systeme wirkt sich positiv auf die Übertragungszeit aus.

Komprimieren/Dekomprimieren in SAP

SAP hat mit dem Web AS 6.20 die Komprimierung innerhalb von ABAP™ verfügbar gemacht. In diesem CADAXO Development Tipp werde ich einen kurzen Überblick liefern.

Überblick CL_ABAP_GZIP / CL_ABAP_ZIP

Zwei Klassen stehen zur Verfügung. Die Klasse CL_ABAP_GZIP wird zum Komprimieren/Dekomprimieren von Texten, Strings oder binären Inhalten verwendet. Darüber hinaus gib es die Klasse CL_ABAP_ZIP mit welcher mehrere Objekte zu einem ZIP Ordner zusammengefasst werden können. Auf diese Klasse wird in diesem Development Tipp nicht weiter eingegangen.

Klasse CL_ABAP_GZIP

Zum Komprimieren von einzelnen Texten, Strings oder binären Inhalten kann die Klasse CL_ABAP_GZIP verwendet werden. Die Klasse bietet vier Methoden an:

  • COMPRESS_TEXT Komprimierung von Text in GZIP-Format
  • DECOMPRESS_TEXT Dekomprimierung von gezippten Textdaten
  • COMPRESS_BINARY Komprimierung von Binärdaten in GZIP-Format
  • DECOMPRESS_BINARY Dekomprimierung von gezippten Binärdaten

Methode COMPRESS_TEXT – Komprimierung von Texten bzw. Strings

Diese Methode wird verwendet, um einen Text/Textstring zu komprimieren. Der zu zippende Text muss in einem CSEQUENCE Typ vorliegen. Zur Erinnerung, bei CSEQUENCE handelt es sich um einen generischen, textartigen ABAP Typ wie STRING oder C.

Der Text wird durch den einzigen Pflichtparameter Parameter TEXT_IN übergeben. Als Ergebnis erhält man zwei Parameter nämlich GZIP_OUT und GZIP_OUT_LEN. Wie vermutet, wird mit GZIP_OUT der komprimierte Inhalt und in GZIP_OUT_LEN die Länge zurückgeliefert. Für GZIP_OUT ist ein XSEQUENCE Typ (X oder XSTRING) zu verwenden.

Nachfolgend ein Beispiel für eine Komprimierung eines Textes:

Die Methode bietet noch weitere optionale Eingabeparameter an:

  • TEXT_IN_LEN Wenn keine Textlänge angegeben ist, wird der gesamte übergebene Text komprimiert, ansonsten erfolgt die Komprimierung auf den Teilbereich des Textes.
  • COMPRESS_LEVEL Durch die Angabe des Komprimierungslevels kann die Größe und Geschwindigkeit der Komprimierung gesteuert werden. 1 bedeutet höchste Geschwindigkeit und 9 beste Komprimierung. Wenn keine Angabe erfolgt, wird 6 als Default-Wert gesetzt. 0 bedeutet keine Komprimierung.
  • CONVERSION Die Eingabedaten können vor der Komprimierung noch in eine andere Codepage konvertiert werden. Hier kann entweder die gewünschte Codepage, UTF-8, NONE oder DEFAULT angegeben werden. Bei DEFAULT wird in Unicode Systemen auf UTF-8 umgewandelt, in nicht Unicode Systemen erfolgt keine Konvertierung. DEFAULT ist als Default-Wert gesetzt.

Methode DECOMPRESS_TEXT – Dekomprimierung von Texten bzw. Strings

Um einen gezippten Text wieder in eine CSEQUENCE zu dekomprimieren, ist die Methode DECOMPRESS_TEXT zu verwenden. Die Methode verfügt über die gleichen Parameter wie COMPRESS_TEXT deshalb hier nur kurz die Parameter zusammengefasst:

  • GZIP_IN Hier wird der XSEQUENCE Typ mit dem gezippten Wert übergeben.
  • GZIP_IN_LEN Optionale Angabe der Länge.
  • CONVERSION Mit DEFAULT wird in einem Unicode-System auf UTF-8 umgewandelt, in nicht UNICODE-Systemen auf die Systemcodepage. Weitere mögliche Angabe NONE und eine gewünschte Codepage.
  • TEXT_OUT Liefert den dekomprimierten Text.
  • TEXT_OUT_LEN enthält die Länge des dekomprimierten Textes.

Beispiel:

Methoden COMPRESS_BINARY und DECOMPRESS_BINARY – Binärdaten

Die Komprimierung bzw. Dekomprimierung von Binärdaten unterscheidet sich nicht wesentlich von der Vorgehensweise mit Texten. Zum Komprimieren wird die Methode COMPRESS_BINARYverwendet. Die einzigen beide Unterschiede betreffen den Typ des zu komprimierenden/dekomprimierenden Feldes und das Fehlen der optionalen Parameter zur Codepage Konvertierung. Zur Dekomprimierung ist die Methode DECOMPRESS_BINARY zu verwenden.

Als Typ des zu komprimierenden/dekomprimierenden Feldes wird ein XSEQUENCE, also entweder ein Feld vom Typ X oder XSTRING, benötigt.

Anwendungsfälle

Wo ist nun eine Anwendung der Klasse denkbar und sinnvoll?

Beispielsweise werden in einer Anwendung Langtexte/Notizen erfasst oder Dokumente/Bilder hochgeladen. Komprimiert können diese wesentlich platzsparender in SAP Tabellen abgelegt werden. In Programmen verwendete XML Strings können auf diese Weise platzsparend im System abgelegt werden. Bei einer RFC Kommunikation zwischen zwei SAP Systemen bietet sich diese Technik an, um bei großen Datenmengen die Netzwerkbelastung wesentlich zu reduzieren und den Datenaustausch somit zu beschleunigen.

Einbinden von sap.m.page als Content in sap.m.IconTabBar funktioniert nicht

In das Control sap.m.IconTabBar können über die Aggregation content bzw. über die entsprechenden Content-Methoden SAPUI5 Controls eingebunden werden. Zumindest bis zum SAPUI5 Release 1.24 funktioniert das Einbinden von Objekten vom Typ sap.m.Page nicht korrekt, sondern liefert teilweise fehlerhafte Ergebnisse.

Stattdessen sollte ein SAPUI5 Layout-Control (Flex Box, … ) oder eine „echtes“ UI Control verwendet werden.

Hier ein Javascript Beispiel in dem eine Tabelle im eingebundenen View zurückgeliefert wird:

addviewtoicontab1

SubView: „zui5_demo_acc.ListOpportunitites“

addviewtoicontab2

Onlinekurs ABAP development for HANA

Onlinekurs „ABAP® development for HANA“

Wir, die Entwickler der Firma Cadaxo, beschäftigen uns seit einiger Zeit mit SAP HANA. Nach vielen gemeinsamen internen Know-how-Transfers und Diskussionen, haben wir uns entschieden, beim Onlinekurs „ABAP Development for HANA“ auf open.sap.com mitzumachen, um unser Know-how zu vertiefen.

Der Kurs erstreckte sich über vier Wochen und wurde von den Instruktoren Dr. Jasmin Gruschke und Jens Weiler auf Englisch gehalten. Wie es die Namen schon verraten, sind die beiden gebürtige Deutsche und wie man schon ahnen kann, drang der deutsche Akzent ziemlich stark durch – vor allem bei Jens Weiler, was mich immer bei guter Laune während des Vortrags hielt.

Im Kurs geht es hauptsächlich darum, was im SAP zu tun ist, wenn man HANA einführt. Bestehendes Coding zu analysieren, worauf man achten muss und mit welchen Tools man das am besten macht.

Der zweite große Teil behandelt Optimierungen – datenbankorientierte Programmierung und Verwendung von HANA-spezifischen Features.

Erst im Laufe des Kurses ist mir wirklich bewusst geworden, wie effizient HANA sein kann. Ein tieferer Blick in die Funktionsweise von HANA, ein paar Demos, in denen enorme Massendaten sekundenschnell aufbereitet und angezeigt werden – und man erkennt den signifikanten Unterschied zur traditionellen Datenbank.

Hier ein paar Themen, die mir am besten gefallen haben und auf die ich in weiteren Beiträgen näher eingehen werde:

  • Bestehendes Coding – was funktioniert nicht mit HANA und muss adaptiert werden
  • Performance von bestehendem Coding – Richtlinien und Ergänzungen
  • Core Data Services-Views – Was ist es und wofür kann ich es verwenden

Ich hoffe, dass auch für euch ein paar interessante Themen dabei sind!

Kundenindividueller Object Collector für den SAP®/ABAP® Code Inspector

Die Objekt-Selektion des Code-Inspectors kann durch einen eigenen Object Collector erweitert werden. Der Standard bietet zwar viele Selektionsmöglichkeiten, manchmal reichen dies aber einfach nicht aus.

ci_own_collector_1

Die notwendige Erweiterung gestaltet sich relativ einfach. Es muss lediglich eine Klasse mit dem Interface IF_CI_COLLECTOR implementiert werden. Üblicherweise wird die Super-Klasse CL_CI_COLLECTOR_ROOT vererbt. Das Interface verfügt über folgende Methoden:

Interface IF_CI_COLLECTOR Methoden

  • COLLECT In dieser Methode ist die Objekt-Selektion auszuprogrammieren und dem Export-Parameter P_OBJSLIST zu übergeben. Anwender können den Objekt-Collector mit Filterwerten starten, diese Werte stehen in den Parametern P_CONFINE_* zur Verfügung.
  • QUERY_ATTRIBUTES In dieser Methode werden Attribute wie der Titel der Selektion bzw. die Select-Options/Parameter definiert. Als Vorlage bei der Implementierung kann man sich die Implementierung der Klasse CL_CI_COLLECTOR_ST22 ansehen.
  • GET_ATTRIBUTES/SET_ATTRIBUTES Die Methoden dienen der Kommunkation zwischen Code Inspector Framework und dier implementierten Klasse. Mittels EXPORT/IMPORT from MEMORY werden die Attribute übergeben. Auch hier kann die Klasse CL_CI_COLLECTOR_ST22 als Vorlage verwendet werden.
  • DISPLAY_DOCUMENTATION Wenn der Collector über eine Dokumentation verfügt, kann hier die Anzeige der Dokumentation gestartet werden.

Interface IF_CI_COLLECTOR Attribute

Das Interface verfügt über einige Steuerparameter welche als globale Attribute umgesetzt wurden. Hier die wichtigsten Attribute:

  • DESCRIPTION Kurzbeschreibung des Object Collector.
  • NAME Name des Object Collectors
  • HAS_DOCUMENTATION ABAP_TRUE bzw. ABAP_FALSE je nachdem, ob der Collector über eine Dokumentation verfügt. Wenn ABAP_TRUE ist im Popup der Button für die Dokumentation aktiv. (siehe Methode DISPLAY_DOCUMENTATION)
  • HAS_ATTRIBUTES ABAP_TRUE/ABAP_FALSE je nachdem, ob der Collector über Attribute verfügt. Wenn ABAP_TRUE ist im Popup der Button für die Parameter aktiv.

Meine Empfehlung

Am Einfachsten und Schnellsten gestaltet sich die Implementierung, wenn man die vorhandenen Code Inspector Collectoren (CL_CI_COLLECTOR*) der SAP als Vorlage verwendet.