Dieser Blogpost ist ein Artikel in einer Serie von Artikeln zu dem im Dezember 2019 erschienenen Buch „Blockchain mit SAP“ (Rheinwerk Verlag, Bonn, ISBN 978-3-8362-6914-8).

Dieser Blogpost basiert auf dem sechsten Kapitel des Buches, in dem die Konfiguration und Entwicklung von Blockchain-Anwendungen mit Hyperledger Fabric und der SAP Web IDE beschrieben wird.

Im Rahmen des Buches „Blockchain mit SAP“ entwickeln wir vergleichbare Beispiel-Anwendungen parallel für Hyperledger Fabric und MultiChain. Im letzten Blogpost haben wir eine einfache Anwendung für die Speicherung von Teilnehmerdaten in einem Telefonbuch in Hyperledger entwickelt. Diesmal wird es eine etwas komplexere Anwendung …

Die Simulation eines dezentralen Energiemarktplatzes

In diesem Blogpost soll es um die Umsetzung eines dezentralen Energiemarktplatzes gehen. Die Idee dabei ist, dass mehrere Teilnehmer an einem Marktplatz Angebote anbieten und kaufen können. Jeder Teilnehmer hat ein fiktives Konto mit 50.000 virtuellen Coins, mit denen er Käufe auf dem Energiemarkt tätigen kann. Die Coins sind keine Kryptowährung und werden nicht von der Blockchain verwaltet. Sie sind nur simuliert und mit den Profilen der Nutzer verknüpft.

Das Frontend

Die Oberfläche der Anwendung für den dezentralen Energiemarktplatz sieht wie folgt aus:

(c) Rheinwerk Verlag Das finale Web-Frontend des dezentralen Energiemarktes mit drei logischen Bereichen.

 

Im linken Teil unter Punkt 1 ist der öffentliche Marktplatz zu sehen. Hier wurde ein Produkt namens „Solarstrom“ eingestellt, welches zum Verkauf steht.

Im rechten oberen Teil unter Punkt 2 sind die persönlichen Angebote und darunter unter Punkt 3 die gekauften Angebote des gerade ausgewählten Teilnehmers aufgeführt.

Der Teilnehmer, in dessen Namen gerade agiert wird, kann über das Dropdown-Menü oben rechts ausgewählt werden. Links davon wird der Kontostand dieses Teilnehmers dargestellt.

Einstellen eines Produktes

Über den Button „Angebot erstellen“ kann der aktuell ausgewählte Teilnehmer eigene Angebote für den Markt einstellen. Daraufhin erscheint das Angebot auf dem Marktplatz und kann gekauft werden:

(c) Rheinwerk Verlag Neu eingestelltes Angebot im Marktplatz

 

Über das DropDown-Menü oben rechts wird nun ein anderer Teilnehmer ausgewählt, und „Charlie Sanchez“ kauft das neue Angebot:

(c) Rheinwerk Verlag, Ein Angebot wurde gekauft

 

Die Kosten für den Kauf werden vom Kontostand des Teilnehmers abgezogen. „Charlie Sanchez“ verbleiben nur noch 49.100 Coins. Damit sind die Möglichkeiten des dezentralen Energiemarktes auch schon demonstriert.

Architektur der Anwendung

Die Energiemarkt-Anwendung nutzt eine dreigeteilte Architektur nach dem MVC-Entwurfsmuster. Es gibt …

  1. eine Hyperledger-Fabric-Blockchain, die als Datenmodell dient,
  2. eine Node.js-Serverkomponente, die als Middleware dient, und
  3. eine SAPUI5-Website, die als Frontend ausgespielt wird.

Das Frontend setzt Aufrufe an die REST-API der Middleware ab, die als Controller fungiert und bei Bedarf ebenfalls über REST-Aufrufe mit der Hyperledger-Fabric-Blockchain kommuniziert.

(c) Rheinwerk Verlag Software-Architektur des dezentralen Energiemarkts (Quelle: „Blockchain mit SAP“, Rheinwerk-Verlag 2019, S. 270)

 

Datenmodellierung in der Blockchain

Smart Contracts heißen bei Hyperledger Fabric Chaincode. Bei Hyperledger Fabric gibt es im Gegensatz zu anderen Blockchains keine fertigen Datenstrukturen. Vielmehr liegt es an uns, eine entsprechende Beschreibung der zu verfolgenden Datenobjekte im Chaincode zu modellieren und diesen anschließend um entsprechende Funktionen zu erweitern. Das folgende Listing spiegelt die Struktur des Codes wider, ohne die Details der Implementierung zu zeigen:

//EnergyMarket Chaincode implementation

type EnergyMarket struct {

}

/

******************** Product Offering registration function *********

***********/

func (t *EnergyMarket) registerProductOffering(stub shim.ChaincodeStu

bInterface, args []string) peer.Response {

... }

/******************** Purchase Product function ********************/

func (t *EnergyMarket) purchaseProduct(stub shim.ChaincodeStubInterfa

ce, args []string) peer.Response {

...}

//

******************** get registred products function*****************

***/

func (t *EnergyMarket) getProductOfferings(stub shim.ChaincodeStubInt

erface, args []string) peer.Response {

...}

 

Der Chaincode für das Objekt EnergyMarket kommt also mit nur drei Funktionen aus:

  1. registerProductOffering zum Einstellen eines neuen Produktes
  2. purchaseProduct zur Abwicklung des Verkaufs eines Produktes und
  3. getProductOfferings zur Übersicht über die Produkte für den Marktplatz.

Das ist alles. Neben diesen drei Funktionen für den Marktplatz braucht es aber auch eine Definition der Datenstruktur für die Angebote. Ein ProductOffering ist ein solches Strom-Angebot, welches auf dem Marktplatz von den Teilnehmern eingestellt werden kann. Damit sind die wichtigsten Komponenten im Chaincode für die Blockchain definiert, und wir können uns der nächsten Architekturkomponente zuwenden – der Node.js-Middleware.

Die Node.js-Middleware-Serverkomponente

Die Middleware ist realisiert als Node.js-Server, der eine REST-API bereitstellt, die vom SAPUI5-Frontend konsumiert wird und Anfragen an die Blockchain weiterleitet. In der zentralen Datei index.js des Middleware-Projektes werden die URLs, auch Routen genannt, mit dem Aufruf entsprechender Funktionen in JavaScript verknüpft.

Beim Start der Plattform muss zum Beispiel festgestellt werden, ob es bereits Angebote gibt, die in der Tabelle des Marktplatzes dargestellt werden sollen. Dies geschieht, indem das Frontend beim Laden der Seite den Aufruf

/getAvailableProductOfferings

an die Middleware absetzt. Dieser Aufruf ist gemappt auf die Funktion:

requestHandlers.getAvailableProductOfferings

 

Diese Funktion sieht wie folgt aus:

…

function getAvailableProductOfferings(req, cb) {

const methodName = "getProductOfferings";

const filter = {"selector":{"docType":"productOfferings",

"status": 1}};

_blockchainGet(methodName, filter, cb);

}

…

 

Sie definiert die aufzurufende Chaincode-Funktion getProductOfferings sowie einen Suchfilter mit dem Selektor “docType”:”productOfferings” und dem Statuswert 1, was die verfügbaren Produkte beschreibt. Wir suchen also nach allen Produktangeboten, die noch zu haben sind.

Der letzte Aufruf reicht die Anfrage weiter an eine weitere private Funktion _blockchainGet, die sich um die Kommunikation mit der Blockchain kümmert, entsprechende Aufrufe an sie absetzt und das Ergebnis zurückliefert.

Damit ist die grundlegende Kommunikation mit der Blockchain skizziert. Alle weiteren Funktionen durchlaufen dieselben Stationen: das Frontend ruft die Middleware auf, die wiederum die Blockchain aufruft.

Weitere Aufgaben der Middleware

Die Middleware hat neben der Kommunikation mit der Blockchain noch weitere Aufgaben, wie etwa die Verwaltung der simulierten Teilnehmer und deren Kontoständen. Dies geschieht über eine Datei user.json, in der eine JSON-Liste mit den Teilnehmerdaten angelegt ist. Diese wird beim Start der Middleware eingelesen, und die Daten werden im Betrieb kontinuierlich aktualisiert. Beim Kauf eines Produktes durch einen Benutzer werden die entsprechenden Kontostände angepasst, d.h. der Verkäufer bekommt den Kaufpreis gutgeschrieben und der Käufer entsprechend abgezogen. Spätestens hier wird klar, dass die Kontostände in Coins keine echte Kryptowährung sind.

Das SAPUI5-Frontend

Die Darstellung der Benutzeroberfläche wird mit SAPUI5 in der SAP Web IDE entwickelt und im Betrieb von der Middleware mit den Daten zur Darstellung bespielt. Beim Laden des Marktplatzes werden zum Beispiel vom Frontend folgende Daten über die Middleware angefragt:

  • verfügbare Produkte für den Markt (Bereich 1)
  • Abfrage der durch den aktuell gewählten Teilnehmer erstellten Produkte (Bereich 2)
  • Abfrage der durch den aktuell gewählten Teilnehmer erworbenen Produkte (Bereich 3)

Diese entsprechen den drei skizzierten Bereichen des dezentralisierten Energiemarktes:

(c) Rheinwerk Verlag Das Web-Frontend des dezentralen Energiemarktes mit drei logischen Bereichen.

 

Die SAP Cloud Platform bietet Unterstützung für ein vereinfachtes Aufsetzen und Starten mehrerer Dienste im Rahmen einer Gesamtanwendung und reduziert damit erheblich den administrativen Aufwand – für Entwickler ein wirklicher Segen.

Weitere Artikel dieser Serie finden sie hier:

Wollen Sie mehr zur SAP Cloud Platform und der Funktionsweise der Blockchains erfahren? In unserem Buch „Blockchain mit SAP“ erläutern wir Ihnen ausführlich die Funktionsweise und demonstrieren Ihnen anhand zahlreicher Beispiele die Vorzüge dieser innovativen Technologie. Eine ausführliche Leseprobe zum Buch stellt der Verlag online bereit.

Wollen Sie mehr über die Möglichkeiten von Hyperledger Fabric für Ihr Unternehmen erfahren? In unserem Buch „Blockchain mit SAP“ erläutern wir Ihnen ausführlich die Vorteile der Hyperledger-Fabric-Blockchain und wie Sie diese mit Knoten in der SAP Cloud Platform aufsetzen können. Kennen Sie auch schon unsere Hypertrust Platform, die die Ausführung von dezentralen Apps unter verschiedenen Blockchain-Frameworks ermöglicht? Eine ausführliche Leseprobe zum Buch stellt der Verlag online bereit.

 

S/HANA Studie Banner

SAP S/4: Studie zur Transformation

Die Studie „Erwartungen an S/4HANA in 2022" von techconsult und CamelotITLab zeigt Stolpersteine der Migration und wie sie vermieden werden können. Mit Daten von 200 Unternehmen aus Deutschland.

Hier geht es zum Download

Empfohlene Artikel

New Now in Organizations

Warum jetzt der richtige Zeitpunkt für lokales CSR-Engagement ist

Wir erleben derzeit nie dagewesene Zeiten. Der Ausbruch von COVID-19 verändert den Alltag von Unternehmen und deren Mitarbeitern grundlegend. Inmitten …

weiterlesen
CRM

Migration zur SAP Business Technology Platform Multi-Cloud – Beispiel

In diesem Blogpost geben wir Ihnen eine Übersicht über die Features und Vorteile der neuen SAP BTP. Wir zeigen Ihnen, wie …

weiterlesen
Data & Analytics

Chief Data Officer vs. Chief Digital Officer

Complexity of digital transformation demands new skills in the C-suite. Two CDOs? Where is the difference?

weiterlesen

Denken Sie Ihre Value Chain neu mit uns

Kontaktieren Sie uns