Das SAP ABAP Backend als “IoT Ding”: SAP Monitoring über MQTT

Die DSAG Technologietage 2019 Bonn sind gerade vorbei. Inspiriert durch viele gute Vorträge und eine gute Keynote vom neuen DSAG Technologievorstand Steffen Pietsch fühlte ich mich animiert, die Heimfahrt sinnvoll zu nutzen und mein abapGit Projekt MQBA für einen speziellen Anwendungsfall zu dokumentieren: „SAP Monitoring über MQTT“.

Da das Monitoring (im SAP Solution Manager) in einem speziellen Kundenprojekt noch nicht verfügbar war, kam ich in einer schwachen Minute auf die Idee, das SAP System im „Internet Of Things“ Sinne (kurz IoT) selbst als Ding zu sehen und die zahlreichen Performanceindikatoren als seine Sensorwerte. Herausgekommen ist dabei ein kleines Dashboard, was auf einem kleinen RaspberryPI mit Touchscreen lief (siehe Screenshot).

So abgerissen scheint diese Idee gar nicht zu sein. Auf den DSAG Technologietagen 2019 berichtete Microsoft beispielsweise darüber, dass deren SAP Systeme Ihre Daten regelmäßig in der Azure Cloud ablegen. Zusammen mit anderen Daten werden diese dann für das Monitoring im Betrieb genutzt. Und eigentlich stehen ja auch in der SAP Cloud Platform (SCP) ähnliche Services bereit.

Interessanterweise ist es aber gerade Microsoft, die für SAP ABAP ein entsprechendes Azure Cloud SDK für die Zugriffe auf die Azure Services anbieten: https://github.com/Microsoft/ABAP-SDK-for-Azure.

Für mich ist der MQTT Standard (https://de.wikipedia.org/wiki/MQTT) eine der wichtigsten Komponenten im IoT Umfeld. Sowohl im privaten (z.B. Smarthome) aber auch im geschäftlichen Bereich trifft man inzwischen sehr oft auf die MQTT Begriffe und Beispiele. Wie wichtig APIs (oder auch Standards), die Interoperabilität und der Zugang zu Informationen für die Digitalisierung sind, hat die DSAG Keynote dieses Jahr eindringlich betont.

Für MQTT bedeutet das beispielsweise, dass es viele kommerzielle aber auch frei nutzbare Tools gibt und diese noch dazu gut dokumentiert sind. Die c’t aus dem Heise Verlag hat inzwischen regelmäßig nachvollziehbare Beispiele im Programm, die auch für den geschäftlichen Bereich interessant sind. Glücklicherweise stammt eine notwendige Komponente, um ein SAP ABAP System mit einem externen MQTT Broker zu verbinden, sogar aus meiner Feder. An der Dokumentation arbeite ich hier gerade…

Das Szenario und ein bisschen Theorie

Als „IoT Ding“ würde ein SAP System beispielsweise seine Sensorwerte als Nachrichten regelmäßig über das MQTT Protokoll an einen sogenannten MQTT Broker („das Postamt“) senden („publish“). Der MQTT Broker verteilt diese Nachrichten dann – falls vorhanden – an verschiedene Empfänger, die sogenannten „Subscriber“. Der MQTT Broker kann die Daten aber auch speichern und für bestimmte Empfänger sogar aufheben, falls diese mal „verhindert“ sein sollten.

Über sogenannte MQTT Topics (die „Adresse“, ähnlich einer URL) finden sich Sender und Empfänger. Da es bei MQTT mehrere Empfänger für eine Nachricht geben kann, könnte man sich das Ganze vielleicht eher als Schwarzes Brett (in einem Postamt) vorstellen und das Topic enthält Informationen zum Sender und zum Inhalt.

Ein solcher Empfänger könnte dann beispielsweise ein Dashboard sein, wo man live das aktuelle Befinden seines SAP Systems mitverfolgen kann. Genau dieses Szenario beschreibe ich hier. Man könnte aber auch Daten mehrerer SAP Systeme am MQTT Broker abgreifen, sie irgendwo sammeln (in der Cloud?) und dann auswerten (ähnlich dem Microsoft Szenario). Die Ideen kommen dann schon, wenn man die Materie erst einmal begriffen und für gut befunden hat.

Systemvoraussetzungen

Achtung: Es wird ein SAP Netweaver ABAP 7.53 benötigt. Dieser ABAP Stack kommt beispielsweise beim S/4 HANA 1809 zum Einsatz. Somit werden nur sehr wenige das hier dargestellte Szenario selbst testen können. Vielleicht ein Grund mehr für die SAP, zeitnah eine aktualisierte SAP Netweaver ABAP Trial Version heraus zu geben (https://blogs.sap.com/2017/09/14/sap-netweaver-as-for-abap-7.52-available-now/)?!

Das Projekt „Message Queue Broker ABAP“ (kurz MQBA, Projektseite https://github.com/MDJoerg/MQBA) implementiert das MQTT Grundkonzept im SAP ABAP und ermöglicht auch die externe Kommunikation. Das Addon-Projekt MQTT_PINS liefert diese externe Kommunikation über die native MQTT Unterstützung des ABAP Stacks, die aber erst mit ABAP Stack 7.53 verfügbar ist.

Vor 7.53 gibt es eine Alternative über einen Node-RED Flow (https://nodered.org/). Dies ist auf der Github MQBA Projektseite beschrieben. Eine weitere Alternative für ältere SAP Releases – zumindest zum Senden der Daten aus dem SAP heraus – wäre das abapGit Projekt abapMQ (https://github.com/INVIXO/abapMQ). Beide Alternativen allerdings mit konzeptionellen Schwächen oder technischen Einschränkungen, so dass ich hier nicht näher eingehen möchte.

Die Testumgebung

Das MQTT Protokoll benötigt einen MQTT Broker – das „Postamt“. Natürlich könnte man sich recht einfach mit einem RaspberryPI und „mosquitto“ (https://mosquitto.org/) eine eigene Testumgebung aufsetzen. Mit Docker auf dem Desktop würde das auch recht schnell gehen (https://hub.docker.com/_/eclipse-mosquitto).

Man kann aber auch einen der für Testzwecke frei verfügbaren MQTT Broker verwenden (z.B. https://iot.eclipse.org/). Für diesen Blog fiel die Entscheidung auf http://www.mqtt-dashboard.com/ und HiveMQ als MQTT Broker Lösung, weil diese Seite ein attraktives Dashboard und eine webbasierte Client-Anwendung beinhaltet.

Broker Konfiguration und Test

Auf der Startseite von http://www.mqtt-dashboard.com/ sind die Anmeldeinformationen für die Clientprogramme sichtbar.

Der Link zum webbasierten Client ist etwas versteckt. Es öffnet sich eine Maske, mit der man sich als Erstes am Broker mit einer eindeutigen Identifikation anmeldet.

Die Verbindung zum Broker wird über „Connect“ hergestellt. Der nächste Schritt besteht darin, beim Broker die Ereignisse zu registrieren, über die man informiert werden will. Dazu muss man sich auf einem bestimmten „Topic“ „subscriben“. D.h. Topics sind oft in einer ähnlichen Form aufgebaut wie die URLs im Browser. Es wird meistens eine Hierarchie abgebildet, die Informationen zum Organisationsbereich (z.B. Region Nord, zum physischen Objekt (auch „Thing“, z.B. Maschine X) und zum Sensor (z.B. Temperatur) abbildet. Eine Registrierung mit „Wildcards“ ist möglich.

Für das hier beschriebene Szenario erfinden wir einen organisatorischen Bereich „mqba1111“ (bitte entsprechend anpassen). Das Topic für die Registrierung (Button „Add new topic Subscription“) wäre demnach „/mqba1111/#“. Damit würden alle Ereignisse weitergeleitet, die mit „/mqba1111“ beginnen.

Das kann man bereits im Webclient testen, in dem man mit „Publish“ ein Ereignis selbst erzeugt, z.B. publish an „/mqba1111/sensor1“ mit dem Wert „34“. Diese weiter geleiteten Ereignisse werden im unteren Teil des Webclients angezeigt.

MQBA Installation

Die beiden oben erwähnten abapGit Projekte MQBA und MQBA_PINS sind als OpenSource auf Github (https://github.com/MDJoerg) verfügbar und werden über abapGit (https://docs.abapgit.org/) installiert. Dafür sollte man in English angemeldet sein.

Bevorzugt in die Pakete $MQBA und $MQBA_PINS (in Testsysteme ohne Transport) oder ZMQBA und ZMQBA_PINS, wenn ein Transport in weitere Systeme erfolgen soll. Für wen abapGit neu ist, der erfährt beispielsweise hier (https://www.tricktresor.de/blog/abapgit/) die wichtigsten Informationen für eins der derzeit interessantesten Tools der SAP Community.

Nach der Installation über abapGit stehen die ABAP Objekte in den Paketen $MQBA und $MQBA_PINS zur Verfügung.

Konfiguration

Über die installierten Projekte stehen Transaktionen, Konfigurationstabellen und natürlich auch die entsprechenden ABAP Programme zur Verfügung. Um es ein bisschen einfacher zu machen, habe ich mich für ein Bereichsmenü entschieden, dass über Eingabe von „ZMQBA“ im SAPGUI Fenster aktiviert werden kann.

Dadurch erscheint das Bereichsmenü des MQBA Projektes. Die für diesen Block interessantesten Transaktionen sind markiert.

Der erste Schritt wäre die Konfiguration des externen Brokers (hier HIVEMQ) mit der Transaktion ZMQBA_BRKC. Die wichtigsten Einstellungen finden sich im rot markierten Bereich.

Der externe Broker wird im SAP als „HIVEMQ“ geführt und soll (nur) auf den Präfix „/mqba1111“ reagieren (ggf. anpassen). Die Client ID muss weltweit eindeutig sein das sich sonst der Broker die Zustellung nicht garantieren kann.

Die Broker URL enthält die Verbindungseinstellungen wie auf der Startseite von http://www.mqtt-dashboard.com/  aufgeführt. Für abweichende Broker müssen diese Einstellungen entsprechend angepasst werden. Falls eine Benutzeranmeldung oder ein Proxy notwendig ist, können entsprechende Informationen hier ebenfalls hinterlegt werden.

Die beiden Klassen in den Felder „Brk Impl*“ werden 1:1 übernommen. Hierbei handelt es sich um die aktuellen MQBA Implementierungen der Bridge-Komponente (auch Daemon; implementiert als ABAP Daemon) und der MQTT Client Komponente zum Senden von Nachrichten. Der Daemon routet die Nachrichten zwischen dem internen und externen Broker über den konfigurierten Präfix. An dieser Stelle könnten auch eigene abweichende Implementierungen verwendet werden.

Weiterhin ist der „Push Mode“ aktiviert und QOS 0 (Quality of Service, siehe MQTT Informationen) eingestellt. Mit dem „Push Mode“ werden eintreffende MQTT Nachrichten in Echtzeit verteilt. Das kann ggf. zu Timing Problemen bei hohem Traffic führen. Alternativ (inaktiver „Push Mode“) werden die Nachrichten als QRFC Pakete verarbeitet (Monitoring mit SMQ2). Das ist dann zwar nicht mehr Echtzeit, allerdings können so Lastspitzen abgefangen werden und die Datenpakete kommen häufig trotzdem innerhalb weniger Sekunden an.

Die Einstellungen außerhalb des markierten Bereiches sind optional und bedeuten, dass statistische Informationen zur Bridge-Komponente selbst als MQTT Nachrichten (Sensorwerte) erzeugt werden. Falls gewünscht sogar an einen externen Broker (hier HIVEMQ).

Im zweiten Schritt wird dem internen MQTT Broker noch mitgeteilt, an welchen externen Broker Nachrichten normalerweise geroutet werden sollen. Das wäre ebenfalls wieder der konfigurierte Broker „HIVEMQ“ und wird über Transaktion ZMQBA_CFGD konfiguriert.

Achtung: Danach sollte man einmal die Transaktion ZMQBA_REBUILD aufrufen. Aus Performancegründen werden die Brokernachrichten und auch die Konfiguration im ABAP Shared Memory abgelegt. Das heißt aber auch, dass bei Konfigurationsänderungen, dieser Speicher neu aufgebaut werden muss. Genau das wird über diese Transaktion erreicht.

MQTT Daemon starten

Im nächsten Schritt wird die Verbindung zum externen Broker hergestellt. Technisch handelt es sich hier um ein neues SAP Konzept: das „ABAP Daemon Framework“ (kurz ADF). Solche Daemons sind ABAP Prozesse, die ständig aktiv sind aber nur in vordefinierten Intervallen eine bestimmte Aufgabe erfüllen. Eine interessante Alternative zu den bekannten Batchjobs, die alle 5 min laufen und selten wirklich was zu tun haben?!

In unserem Fall ist dieser MQBA Bridge Daemon ständig aktiv, um eingehende Nachrichten sofort entgegen zu nehmen und zu verarbeiten. Zusätzlich wird in regelmäßigen Abständen überprüft, ob die Verbindung noch steht und ggf. diese Verbindung wieder aufgebaut. Auch ein ausgehender Sendeprozess profitiert vom Daemon: Da bereits ein Clientprozess mit dem externen Broker verbunden ist, kann diese Verbindung auch zum Senden der Nachrichten verwendet werden. Für die Kommunikation zwischen SAP Prozess und SAP Daemon werden ABAP Messaging Channel (kurz AMC) verwendet.

Für das Starten, Stoppen u.ä. Aktionen eines solchen Daemons stellt MQBA die Transaktion ZMQBA_DAEMON bereit.

Hier ist der Name des zuvor registrierten externen Brokers einzutragen („HIVEMQ“). Prinzipiell ist es sogar möglich, mehrere solcher Daemons parallel zu verwenden. Über die in der Konfiguration hinterlegten ABAP Klassen könnten auch abweichende Implementierungen verwendet und ggf. sogar das MQTT Protokoll durch andere Transfermechanismen ersetzt werden.

Das erfolgreiche Starten wird durch eine entsprechende Ausgabe bestätigt.

Im Fehlerfall erscheint hier eine Fehlermeldung. Beispielsweise wird verhindert, dass der gleiche Daemon Prozess mehr als einmal gestartet werden kann.

In der „offiziellen“ SAP Transaktion SMDAEMON sollte der eben gestartete Daemon Prozess bereits sichtbar sein.

Eigentlich könnten jetzt schon die ersten MQTT Nachrichten aus dem SAP auf dem WebClient eintreffen, da der MQTT Daemon Statistikinformationen sendet, falls dies in der Konfiguration so eingestellt wurde. Aber wir werden später noch einen zweiten Daemon Prozess starten, der die eigentlichen aktuellen Systeminformationen regelmäßig abfragt und versendet.

Test: Eingehende Nachrichten

Die Kommunikation zwischen externem Broker und SAP funktioniert bereits und wir können das in einem einfachen Test überprüfen.

Dazu starten wir im SAP die Transaktion ZMQBA_MSG_LIST. Mit dieser Transaktion rufen wir die aktuellen Nachrichten des lokalen SAP Brokers auf. Hier könnten bereits Nachrichten des Daemons stehen oder die Liste ist noch leer. Diese Anzeige des internen Brokers zeigt aktuell bekannte Nachrichten an und ist so programmiert, dass sie sich selbst (alle x Sekunden) auffrischt. Neue Nachrichten sind also automatisch sichtbar.

Jetzt wäre ein guter Zeitpunkt die Echtzeitfähigkeit des MQTT Protokolls zu überprüfen und SAPGUI und das Browserfenster nebeneinander anzuzeigen.

Wenn man dann im Webclient im Topic „/mqba1111/sensor1“ und als Message „35“ eingibt und mit „Publish“ diese Nachricht auf die Reise schickt… sollte diese sehr schnell im SAPGUI Fenster erscheinen. Damit würde man beispielsweise einen Sensorwert simulieren (hier bereits mehrfach ausgeführt).

Auf der SAP Seite sieht das dann ungefähr so aus.

Der für den externen Broker zuvor konfigurierte Präfix wurde abgeschnitten und somit ist das hier empfangende Topic nur „/sensor1“. In komplexeren Szenarien sollte man daher geeignetere längere Topics verwenden, die dann auch Gerät, Sensor u.a. enthalten.

Diese eingehenden Nachrichten kann man natürlich auch „abfangen“ und entsprechend darauf reagieren. Das hebe ich mir aber für einen späteren Blog auf.

Test: Ausgehende Nachrichten

Natürlich geht das mit den Nachrichten auch umgekehrt: SAP sendet Nachrichten an die externe Welt. Genau das brauchen wir ja hier für die Verteilung von Monitoring Daten. Ein einfacher manueller Test ist mit der Transaktion ZMQBA_PUB möglich. Damit werden erst einmal MQTT ähnliche Nachrichten im SAP selbst erzeugt.

Der folgende Screenshot zeigt die minimal notwendigen Eingaben. Durch den aktivierten Haken „as external message“ wird die Nachricht zusätzlich an einen externen Broker verteilt. Welcher das genau sein soll, kann im Feld „external broker id“ angegeben werden. Da hier bei der Konfiguration der Broker „HIVEMQ“ bereits vordefiniert wurde, kann das Feld hier leer bleiben.

Zusatzinformation:
Die Maske enthält noch ein paar zusätzliche Eingabemöglichkeiten wie zusätzliche Parameterfelder und eine „private with session id“. Im Hintergrund erfolgt die Verarbeitung über ABAP Push Channels (APC) und ABAP Messaging Channels (AMC). Man kann damit sehr gezielt an einen (privaten) oder mehrere Empfänger im ABAP Nachrichten versenden, was vom MQBA Framework ebenfalls unterstützt wird und einen eigenen Blog wert ist.

Mit „Enter“ wird die Nachricht erzeugt und erhält eine eigene ID.

Die angezeigte Meldung enthält zusätzlich eine Information über den Scope der Nachricht. Hier „D“ für „Distributed“/“Verteilt“. Weitere Scopes wären „I“ (intern), „P“ (privat) oder „E“ (extern). Die Scope Information ist auch in der Liste der SAPGUI Überblicksliste sichtbar.

Jetzt sollte die soeben geschickte Nachricht auch sehr schnell im Browserfenster zu sehen sein.

Damit steht auch die Verbindung in die umgekehrte Richtung und lässt viel Freiräume für eigene Experimente. Es gibt natürlich auch ein Testprogramm für einen empfangenen SAP Prozess (Transaktion ZMQBA_SUB). Im Coding der beiden Transaktionen erhält man einen Einblick in die verwendete objektorientierte API des MQBA Broker Frameworks. Wer es etwas klassischer mag, sollte mal einen Blick in die Funktionsgruppe „ZMQBA_API_BROKER“ werfen.

Monitor Daemon starten

Jetzt ist endlich der Zeitpunkt gekommen, wo das SAP seine Monitoringdaten regelmäßig erzeugen soll und über MQTT versendet.

Der dafür zuständige zweite Daemon ist im Paket ZMQBA_PINS implementiert und auch erst ab ABAP 7.53 verfügbar. Dieser Daemon nutzt die Eigenschaft des periodischen „Aufwachens“ und macht tatsächlich in der restlichen Zeit nichts. Er ist allerdings eher als eine Machbarkeitsstudie zu verstehen, die in Projekten schon recht hilfreich war. Für Tipps von den Monitoring Profis für geeignete Sensoren und deren Zugriffsmethoden bin ich sehr empfänglich.

Gestartet wird dieser Daemon über das Programm ZMQBA_PINS_AD_CONTROL (Transaktion SE38/SA38).

Als „Class/Interface“ ist „ZCL_MQBA_PINS_AD_SYSINFO“ einzutragen. Hier könnten auch andere Klassen eingetragen werden, die ein entsprechendes Interface implementieren und ggf. einen komplett anderen Zweck erfüllen.

Über den Parameter „DEFAULT“ wird wieder das mehrfache Starten verhindert und man könnte an diesen Parameter als Identifikation für eine zusätzliche Konfiguration verwenden.

Nach dem Ausführen erhält man wieder eine Meldung, ob der Start erfolgreich war.

In der SAP Transaktion SMDAEMON sollten jetzt beide gestarteten Daemons sichtbar sein.

Erfolgskontrolle

Spätestens ab jetzt sollte es im Browserfenster „richtig abgehen“. Da der Daemon jetzt in regelmäßigen Abständen Daten sendet (ca. 60 Sekunden) wird das Browserfenster inzwischen mit Nachrichten aus dem SAP „geflutet“.

Daten visualisieren

Was macht man jetzt mit solchen Nachrichten? Bunte Bildchen sind meistens überzeugend. Daher wäre ein Dashboard für diese SAP Monitoring Daten eine gute Idee.

Jetzt kommt Node-RED ins Spiel. Mit Node-RED können attraktive Dashboards sehr schnell und wirklich ohne Programmierung umgesetzt werden. Wie das genau geht, erkläre ich hier nicht. Es gibt unzählige Videos auf Youtube u.ä. und ich empfehle hier stellvertretend dieses Tutorial Video: https://www.youtube.com/watch?v=X8ustpkAJ-U.

Damit habe ich im oben erwähnten Projekt beispielsweise dieses Dashboard ungesetzt.

Node-RED kann man beispielsweise über Docker sehr schnell auf dem Laptop aufsetzen. Alternativ ist in der Standard Distribution Raspian („raspian with desktop“) für den Raspberry PI bereits vorinstalliert (https://www.raspberrypi.org/downloads/raspbian/). Wer dazu Informationen sucht, wird im Internet sehr schnell fündig.

Node-RED ist auch für anderweitige Verarbeitung der Daten nicht ganz ungeeignet, da es sehr viele Plugins enthält, mit denen man beispielsweise die Daten auch „irgendwo hinspeichern“ kann. Das Tool ist so mächtig, dass es bei Siemens auf den IoT Gateways ebenfalls vorinstalliert ist.

Weitere Anregungen

Wer jetzt noch weiter machen möchte und Geräte auf Android Basis sein Eigen nennt, der sollte mal nach Apps mit dem Suchbegriff „MQTT“ suchen. Apple Jünger werden derzeit noch nicht so gut versorgt oder müssen Geld ausgeben.

Mein persönlicher Favorit ist die Android App „MQTT Dash (IoT, Smarthome)“.

Mit dieser App können ebenfalls kleine Dashboards auf dem Smartphone oder Tablets erstellt werden. Man kann allerdings auch Kommandos an SAP oder an das erzeugte Node-RED Dashboard schicken.

Eine weiteres weit verbreitetes Werkzeug ist „MQTT.fx“ (https://mqttfx.jensd.de/). Damit kann man ohne das hier verwendete Webfrontend andere MQTT Broker testen.

Viel Spaß beim Experimentieren!

Ein paar Worte zum Schluss

Je nach Resonanz werde ich mir die Zeit für weitere Dokumentation und auch die Weiterentwicklung des Projektes MQBA nehmen. Ich selbst teste das MQBA Framework bereits in produktiven Szenarien und es funktioniert schon recht gut. Da ich teilweise sehr aktuelle SAP Komponenten und Konzepte verwende, kann es hier und da noch etwas rumpeln.

Wir verwenden das MQBA Framework auch für Design Thinking IoT Workshops oder für Ausbildungsmaßnahmen. Egal ob das Framework dann wirklich produktiv zum Einsatz kommt, man bekommt recht schnell anfassbare Ergebnisse und einen Eindruck, ob bestimmte Ideen dann wirklich funktionieren können. Und darum geht es ja schließlich.

Derzeit suche ich noch nach dem besten Konzept, sehr große Datenmengen sinnvoll zu verarbeiten. In meinen Tests war es beispielsweise kein Problem, Datenmengen von >5000 Nachrichten/Sekunde zu empfangen. Die Verarbeitung (über BAPI u.ä.) schafft ein normales SAP System dann aber kaum noch. Dafür muss man dann wahrscheinlich doch auf die Cloud oder spezialisierte Tools ausweichen. Trotzdem halte ich MQTT für das SAP Backend für einen interessanten Ansatz und werde Ihn weiterverfolgen.

Denkt bitte daran, Eure Daemons wieder zu stoppen. Die laufen wirklich sehr robust bis zum nächsten Reboot des SAP Systems…

 

Advertisement