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.

 

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