Im ersten Teil dieses Artikels wird auf den Grund eingegangen, warum es im Bereich der SAP®-Integration sinnvoll ist, sich mit Groovy zu beschäftigen. Danach zeigen wir unsere Sicht auf, wie einfach eine Umgewöhnung für jene ist, die bisher beispielweise Mappings in Java geschrieben haben.

Warum Groovy?

Als Entwickler im Bereich der SAP® Integration, wird man sich bisher hauptsächlich mit der Programmiersprache Java beschäftigt haben, da die langjährig etablierten Integrationstools in der SAP®-Welt, SAP® Process Integration (PI) bzw. SAP® Process Orchestration (PO), auf Java basieren. Eigene Adapter, Adaptermodule, individuelle Mappings oder benutzerdefinierte Bausteine in Standard Message Mappings werden in Java geschrieben. Trotzdem gibt es einen guten Grund sich mit der Skriptsprache Groovy zu beschäftigen, obwohl sie für die SAP® PI/PO nicht benötigt wird.

Das Ende des Produktlebenszyklus der SAP® PI/PO ist voraussichtlich in einigen Jahren erreicht (Mainstream Maintenance bis 12/2027, Extended Maintenance bis Ende 2030). Bis dahin müssen jene, die die Integration ihrer SAP-Systeme mit SAP® PI/PO realisiert haben, eine Alternative finden. Bei der Suche nach einem Ersatzprodukt wird man im Portfolio der SAP® mit dem Modul „Cloud Integration“ der SAP® Business Technology Platform Integration Suite fündig. Das Produkt kommt den Funktionalitäten der SAP® PI/PO sehr nah. In der SAP® Cloud Integration werden die bereits erwähnten Eigenentwicklungen, die in der SAP® PI/PO mit Java gelöst werden, mit Groovy oder JavaScript gelöst. SAP® empfiehlt allerdings Groovy einzusetzen, wenn es keinen besonderen Grund für den Einsatz von JavaScript geben sollte. Bei einer Migration von SAP® PI/PO nach

SAP® Cloud Integration, würden also beispielsweise die meisten Java-Mappings in Groovy-Skripte überführt werden müssen.

Gemeinsamkeiten und Unterschiede zu Java

Es stellt sich also die Frage, wie groß die Unterscheide zwischen Java und Groovy sind und wie aufwendig die damit einhergehenden Entwicklungen für die Überführung der Java-Entwicklungen in Groovy sind. Halten sich die Anpassungen in Grenzen oder muss man sich darauf einstellen, alles praktisch neu schreiben zu müssen? In dem Kontext ist außerdem interessant, wie lange Entwickler geschult werden müssen, um Groovy zu erlernen bzw. ob dies überhaupt notwendig ist.

Java ist ursprünglich nicht für Skriptentwicklung gedacht und optimiert gewesen. Der Einsatz von Java für Prozeduren, in denen beispielweise Datenstrukturen gemappt und umgebaut werden sollen, ist zwar möglich, aber aufgrund der strengen Syntaxregeln oft nicht effizient. Groovy dagegen ist eine Skriptsprache, die sich, trotz der eindeutigen Nähe zu Java, gut dafür eignet. Das Ziel von Groovy ist es, die Vorteile von Java mit denen von Ruby zu verbinden.

Um einschätzen zu können, wie groß aus Entwicklersicht die Umstellung auf eine neue Programmiersprache sein wird, sollte man sich als ersten Indikator anschauen, wie weit die Syntax der beiden Sprachen auseinander liegt. Um die Beziehung zwischen Groovy und Java besser zu verstehen, ist wichtig zu wissen, dass die Groovy-Syntax eine Erweiterung der Java-Syntax ist. Da die Java-Syntax eine Teilmenge der Groovy-Syntax ist, ist Java ist zu Groovy syntaktisch komplett kompatibel. Das bedeutet, dass Java-Code zu 100% in ein Groovy-Skript übernommen und dort ausgeführt werden kann. Das liegt daran, dass Groovy auf der Java-Plattform läuft. Wer es gewohnt ist, Java Code zu schreiben, der kann das innerhalb eines Groovy-Skriptes praktisch weiterhin tun. Klassen aus Java-Bibliotheken können genauso in Groovy importiert und verwendet werden. Aus syntaktischer Sicht kann eine Migration des eigenentwickelten Java-Codes aus der SAP^® PI/PO in die SAP^® Cloud Integration also relativ problemlos erfolgen.

Groovy ist in seiner Syntax allerdings wesentlich freier als das in seiner Syntax als sehr restriktiv geltende Java. Das Semikolon am Ende jeder Anweisung ist optional. Man kann es verwenden, muss es aber nicht. Variablen können wie in Java spezifisch mit simplen und komplexen Datentypen deklariert werden oder sie werden einfach mit dem Keyword „def“ generisch deklariert und können dann jeden verfügbaren Datentyp annehmen.

Migration von SAP® PI/PO zu SAP® Cloud Integration

Die Verwendung generischer Variablen hat bei der Entwicklung von Mappings, bei denen die Datentypen aus bestimmten Feldern vor der Laufzeit noch nicht bekannt sind, Vorteile. Diese Freiheit im Umgang mit Daten kann sich schließlich positiv auf die Entwicklungsdauer von Mappings oder User-Defined-Functions auswirken. Besonders praktisch für das Handling von Inhalten aus Datenstrukturen kann die Anwendung der sogenannten „Closures“ sein, die es ähnlich in Java unter dem Begriff „Lambda-Ausdrücke“ gibt. In Kombination mit den in Groovy verfügbaren „Collections“, die entweder eine „List“ oder eine „Map“ sein können, ergibt sich eine wunderbar einfache Möglichkeit auch große Datenstrukturen einfach und effizient zu durchlaufen.

Der Knackpunkt bei der Migration von Java-Mappings und User-Defined-Functions ist also nicht die Syntax, sondern die Umgebung, in der der Code ausgeführt wird. Es kann je nach Funktionalität des auszuführenden Codes dazu kommen, dass Klassen oder Methoden, die in der Laufzeit einer SAP^® PI/PO-Message verwendet werden können, nicht in der gleichen Form im Kontext einer SAP^® Cloud Integration-Exchange verwendet werden können. Ein Beispiel hierfür wäre der Zugriff auf adapterspezifische Message-Attribute, die es in dieser Form nicht in der SAP^® Cloud Integration gibt. An die veränderten Schreibweisen, die bei User-Defined-Functions angewendet werden, muss man sich zunächst gewöhnen. Konnte man in der SAP^® PI/PO noch per Drop-Down-Menü auswählen, ob eine Funktion einzelne Werte, die Werte eines Kontextes oder die Werte der gesamten Queue behandeln soll, so wird das in Groovy-Funktionen über die Datentypen der Übergabeparameter gesteuert.

Fazit

Zusammengefasst lässt sich sagen, dass die Umgewöhnung von den in der SAP® PI/PO verwendeten Java-Funktionen auf die in der SAP® Cloud Integration verwendeten Groovy-Funktionen gar nicht so schwer ist. Bei einer Migration kann ein Großteil des Codes einfach übernommen und an den Kontext der SAP® Cloud Integration- Exchange angepasst werden. Je mehr es in der Funktion um die Inhalte der Nachricht und weniger um deren Kontext wie etwa adapterspezifische Message-Attribute oder Anhänge geht, desto einfacher wird es, die Funktion zu übernehmen. Wer den Code nicht einfach nur übernehmen, sondern gegebenenfalls noch optimieren möchte, der wird feststellen, dass Groovy an einigen Stellen Kniffe bietet, die in Java nicht verfügbar sind, mit denen man sich das Leben aber sehr viel einfacher machen kann.