SAP Commerce erweitern mit Kyma

Können Sie sich noch an Zeiten erinnern, in denen Releases im SAP ERP Umfeld halbjährlich erfolgten? Die gesamte Softwareentwicklung musste sich darauf ausrichten und konnte daher nur zweimal im Jahr neue Funktionalitäten live stellen.

Die Entwicklung von SAP Commerce hat sich aus diesem Grund insbesondere im B2C Umfeld im Laufe der Zeit von der engen Kopplung an das Backendsystem abgewandt. Im B2B Sektor ist die Abhängigkeit an das Backendsystem jedoch weiterhin größtenteils vorzufinden. Hier wird oftmals auf eine Architektur mit Synchronous Order Management gesetzt. Diese bietet eine Echtzeit-,Preis- und Verfügbarkeitsberechnung mit Hilfe des SAP ERP Backendsystems. Diese Logiken komplett in der Commerce Plattform abzubilden, würde für viele Kunden doppelten Aufwand erzeugen.

Ist eine solche enge Kopplung auf verschiedene Prozesse ausgelegt, so lähmt es ein Unternehmen. Auf die sich damit ändernden Marktbedingungen kann nur sehr langsam reagiert werden.

Selbst wenn eine Commerce Plattform im Schnitt bereits alle 4 bis 6 Wochen Releases bereitstellen kann, so müssen sich neue Funktionalitäten an den Release-Zyklus halten. Und dieser Zyklus ist gegenüber Marktführern einfach zu lang.

Um auf eine Lösung zu kommen, möchten wir uns folgende Fragen stellen:

• Wie wäre es, wenn Funktionalitäten „on Demand“ und völlig entkoppelt von der Commerce Plattform, geschweige denn dem ERP-Backendsystem umgesetzt werden könnten?
• Wie wäre es, wenn man die Funktionalitäten in einer modernen, für die Cloud ausgelegten Art und Weise umsetzen könnte?
• Wie wäre es, wenn die Funktionalitäten unabhängig von der Commerce Plattform skalierbar wären?

Man denke hier an eine Black Friday-Kampagne. Bei Bedarf könnten zusätzliche Funktionalitäten live gestellt werden, die je nach Last skalieren und somit nicht die Commerce Plattform und auch das Backendsystem lahm legen. Zieht diese Kampagne nicht, kann eine weitere on-Demand live geschalten werden.

Eine mögliche technologische Lösung hierzu ist Kyma.

„Kyma /Keema/ ist eine Plattform zur Erweiterung von Anwendungen mit serverlosen Funktionen und Microservices. Es bietet eine Auswahl von verbundenen Cloud-native Projekten, um die Erstellung und Verwaltung von Erweiterungen zu vereinfachen.“

Quelle: https://kyma-project.io

Kyma basiert hierbei auf den aktuell fortschrittlichsten Open-Source-Projekten im Cloud-native Umfeld, so verspricht es die Open-Source Community. Es kombiniert dabei Projekte für Authentifizierung, Protokollierung, Eventing, Alerting, Tracing und vieles mehr. Beispiele hierfür sind Kubernetes und Istio. Kyma sorgt dafür, dass die Bestandteile gut zusammenspielen, sodass weniger die Infrastruktur, sondern der Code und die Business Logik im Vordergrund stehen.

Laut SAP ist Kyma für die SAP Commerce und viele weitere Anwendungen der C/4 HANA Welt der präferierte und zukünftige Weg zur Erweiterung von Funktionalität und Anbindung von externen Services. Unter der Haube betrachtet, kann Kyma somit auf Events aus der SAP Commerce lauschen und hierzu verknüpfte Microservices oder sogenannte „Serverless Functions“ ansprechen. Zudem hat eine Anwendung über Kyma Zugriff auf SAP Commerce und kann dessen API nutzen.

Da dies alles sehr abstrakt erscheinen mag, nähern wir uns über ein Anwendungsbeispiel.

Use Case „Conversion-Rate Steigerung durch Bewerbung von ähnlichen Produkten mit kurzen Lieferzeiten“

Ein Händler möchte mehr über die kaufentscheidenden Produkte einer Bestellung und deren Lieferzeit erfahren. Der Händler entscheidet sich für das jeweils teuerste Produkt der Bestellung.

Er lässt hierzu unabhängig von seiner Commerce Plattform eine Funktionalität umsetzen, die genau das teuerste Produkt der Bestellung mit Herstellerinformation und Lieferzeit speichert.

Dabei macht er sich Folgendes zunutze:

In SAP Commerce wird nach einer Bestellung ein Ereignis ausgelöst, auf das Kyma reagieren und die Funktionalität anstoßen kann.

Diese kann z.B. als Microservice umgesetzt werden, in unserem Fall entscheidet sich das Entwicklungsteam jedoch für eine „Serverless Function“. Diese lädt die Herstellerinformation aus SAP Commerce nach und speichert alle Informationen in einer Datenbank ab. Hierzu wird ein Key-Value Store benutzt, der bereits in der Cloud-Umgebung bereitsteht.

Um weitere Daten aus SAP Commerce zu laden, steht die OCC-API (Omnichannel-Commerce-Connect) zur Verfügung. Somit muss keine Entwicklung in SAP Commerce erfolgen. Der Datenbank-Service kann damit nach Fertigstellung unabhängig vom Release-Zyklus von SAP Commerce live gestellt werden.

Das folgende Schaubild zeigt das eben beschriebene Zusammenspiel zwischen SAP Commerce und Kyma

Nach geraumer Zeit wertet der Händler diese Daten aus. Die Auswertung ergibt, dass eine signifikant hohe Anzahl der kaufentscheidenden Produkte eine Lieferzeit von weniger als 5 Tagen besitzen. Mit dieser Information bindet er in seiner Commerce Plattform eine Recommendation-Engine ein, die Kunden von Produkten mit längeren Lieferzeiten hin zu vergleichbaren Produkten mit kürzerer Lieferzeit berät. Diese Anwendung lässt der Händler von seinem Entwicklungsteam als Microservice umsetzen. Das hauseigene Entwicklungsteam entscheidet sich für node.js als Programmiersprache und braucht keinerlei Kenntnisse von SAP Commerce, welches bekanntlich auf Java/Spring basiert.

Der Händler beauftragt schließlich seinen Entwicklungspartner um die Einbindung der Recommendations in den Warenkorb von SAP Commerce zu ermöglichen. Da die Anpassung in SAP Commerce geringfügig war, kann er das nächste SAP Commerce Release-Update ohne erheblichen Einfluss auf sein Customizing ebenso kostengünstig vom Entwicklungspartner erledigen lassen.

Spinnt man das Beispiel weiter, so stehen dem Händler noch weitere Möglichkeiten offen. Man denke hier an die Möglichkeit mit Echtzeitinformationen zu arbeiten. Eine Prognose, welche Lieferzeit aktuell zum Kaufabbruch führt, könnte ebenso als Service umgesetzt werden. Dieser könnte als Basis für die Empfehlungen dienen. Er kann sich bspw. einen Machine-Learning Service, der in vielen Cloud Umgebungen bereit steht, zu Nutze machen.

Im Großen und Ganzen wirkt dieser Use Case zwar nicht bahnbrechend, nur zeigt er gut folgende Vorteile für den Händler:

• Es können ergänzende Funktionalitäten losgelöst von SAP Commerce bereitgestellt werden
• Das hauseigene Entwicklungsteam kann Funktionalitäten in ihrer präferierten Programmiersprache erstellen und verwalten
• Anpassungen in SAP Commerce selbst, die meist teuer sind, werden reduziert
• Services, die man bereits über seine Cloudumgebung beziehen kann, können eingesetzt werden (hier als Beispiel: Key-Value-Store, Machine-Learning-Service)
• Man muss sich zur Einführung von neuen Funktionalitäten nicht zwingend an den starren Release-Zyklus von SAP Commerce oder des SAP ERP-Backends halten

Es gibt eine Reihe von praxisnäheren Use Cases. Wir möchten diese zumindest kurz erläutern:

Use Case „Bestellinformationen in einer Recommendation Engine nutzen“

Besitzt der Kunde bereits eine Recommendation Engine, kann er diese mit Bestelldaten speisen.

Dafür könnte ein Stück Code als Serverless Function in Kyma implementiert werden, die basierend auf den Produkten weitere Informationen aus SAP Commerce nachlädt. Diese Daten können anschließend in das von der Recommendation Engine erwartete Format umgewandelt und an jene gesendet werden.

Use Case „Kunden benachrichtigen, wenn Produkte wieder lieferbar sind“

Spannend klingt auch der Fall, wenn ein Produkt schlecht oder gar nicht lieferbar ist. Dann könnte man über Kyma eine Benachrichtigungsfunktionalität bereitstellen, für die sich ein Kunde aktiv registrieren kann.

Sobald das Produkt zurück im Lager ist oder eine geringe Lieferzeit aufweist, wird der Kunde durch ein Ereignis aus SAP Commerce per E-Mail benachrichtigt und damit dann zum Kauf animiert.