Aktuell befindet sich der Leitfaden in Erstellung und wurde noch keinem Review unterzogen. Es können daher fehlerhafte, lückenhafte oder unvollständige Informationen enthalten sein.

Open Source

  1. Einleitung
  2. Was ist Open Source?
  3. Motivation und Chancen
  4. Erschwerte Rahmenbedingungen und Risiken
  5. Ausbaustufen
  6. Lizenzen

Einleitung

Open Source hat es in der ABAP-Entwicklung besonders schwer Fuß zu fassen. Immer noch halten sich Einwände, dass der Einsatz von frei verfügbarer Software in den geschäftskritischen SAP-Systemen mit den Unternehmensdaten gar nicht möglich oder zu rechtfertigen sei. Dabei gibt es für viele der berechtigten Einwände Lösungen, um die Risiken zu minimieren und die Chancen, die Open-Source-Software bietet, nutzen zu können. In anderen Programmierumfeldern überwiegen die Chancen bereits lange gegenüber den Restrisiken und es wurden Prozesse und Tools geschaffen, um Open-Source-Bestandteile effektiv in den eigenen Entwicklungsprozess zu integrieren. Dieses Kapitel soll einen Überblick über den aktuellen Stand von Open Source in der ABAP-Entwicklung geben sowie Prozesse und Tools vorstellen, um…

  1. …Open-Source-Projekte in die eigenen Lösungen zu integrieren (Einsatz von Open Source)
  2. …an Open-Source-Projekten mitzuwirken (Beteiligung an Open Source)
  3. …eigene Lösungen als Open-Source-Projekt bereitzustellen (Entwicklung von Open Source).

Eine Open-Source-Strategie muss jedes Unternehmen für sich selbst erschließen. Hier finden Sie eine Arbeitsgrundlage und Erfahrungsberichte.

Was ist Open Source?

Open Source Software (OSS) ist Software, welche unter einer Open-Source-Lizenz bereitgestellt wird. In allen drei zuvor genannten Anwendungsfällen ist die Lizenz maßgeblich für die Nutzung, die Modifikation und die Weiterverbreitung des bereitgestellten Codings. Zudem muss dieses frei verfügbar sein, also nicht nur einer bestimmten Gruppe an Personen bereitgestellt werden. Dies ermöglicht es zum Beispiel den Quellcode einer Anwendung vor dem Einsatz zu prüfen und die Binärdateien zur Ausführung selbst zu erzeugen, anstatt darauf zu vertrauen, dass die bereitgestellten Dateien auch zu dem Quellcode gehören. Bugs können im Zweifel selbst behoben werden, statt auf den Softwareanbieter warten zu müssen oder angewiesen zu sein. Zusatzfunktionalität und Integrationen können selbst entwickelt und anderen Nutzern bereitgestellt werden. Versprochene Features wie Ende-zu-Ende-Verschlüsselung und deaktivierte Telemetrie können selbst überprüft werden.

SAP S/4HANA ist nicht “Open Source” nur weil Sie als Entwickler den von der SAP geschriebenen Quellcode lesen können. Open Source ist viel mehr als die bloße Bereitstellung des Codings gegenüber dem Kunden und thematisiert die freie Nutzung, Modifikation und Weiterverbreitung ohne in einem Kundenverhältnis mit dem Softwareanbieter zu stehen.

Motivation und Chancen

Warum sollten Sie sich mit Open Source in der ABAP-Entwicklung beschäftigen? Langsam aber stetig steigt die Anzahl an Szenarien, in denen Ihnen Open Source, und auch Open-Source-ABAP im Alltag begegnet, statt, dass Sie danach selbst aktiv suchen müssen. Die Anzahl an in der Open Source Community verfügbaren ABAP-Projekten wächst - auf dotabap.org werden zum Zeitpunkt der Erstellung dieses Kapitels 290 Projekte gelistet. Die SAP selbst veröffentlicht Software als Open-Source-Projekte, wie zum Beispiel Code Pal for ABAP oder auch den RAP Generator und diverse Tutorials oder Lerninhalte, wie zum Beispiel RAP100 oder Fiori Elements Feature Showcase for RAP. Sich dem kategorisch zu verschließen führt zunehmend mehr zu verpassten Chancen in…

  1. …der Optimierung der eigenen Entwicklungsprozesse
    1. Mit Tools wie ABAP Cleaner, Code Pal for ABAP und abapOpenChecks können Sie Entwickler entlasten bei der Umsetzung von Entwicklungsrichtlinien und Best Practices, in dem diese teilweise automatisiert umgesetzt und in anderen Teilen statisch geprüft und Entwickler aktiv auf Findings hingewiesen werden. Und das weit über den Umfang der im SAP-Standard ausgelieferten Möglichkeiten hinaus (ABAP Formatter / Pretty Printer, ABAP Test Cockpit).
    2. Mit abapGit bietet sich Ihnen die Möglichkeit Ihre Entwicklungsprozesse Technologie-übergreifend mit einheitlichem Tooling zu harmonisieren und Ihre gesamte Unternehmenscodebase in einer Single Source of Truth zu verwalten, statt ABAP als special Snowflake mit Sonderregeln zu betrachten. Sie können Code Reviews mit dafür ausgelegtem Tooling durchführen. Sie können angefangene Änderungen automatisiert zurücknehmen, wenn sie der Fachbereich nach Entwicklungszeit doch nicht mehr haben möchte ohne große manuelle Rückbauaufwände. Und das alles sogar bei Systemen bis Basis-Release 7.02 runter.
    3. Mit Hilfe von abaplint können Sie außerhalb eines SAP-Systems ABAP Coding prüfen, entwickeln und sogar ausführen. Sie können so Continuous Integration Pipelines aufsetzen ohne dafür spezielle SAP-Systeme aufsetzen zu müssen und statische Codeanalyse und Unit Tests ausführen (mit Einschränkungen im Vergleich zu “nativer” Ausführung in ABAP-Systemen).
    4. Über Generatoren wie den RAP Generator oder ABAP OpenAPI Generator können Sie Boilerplate-Coding generieren und müssen dieses anschließend nur anpassen. So lassen sich Entwicklungsaufwände sparen und insbesondere auch schnell Prototypen aufsetzen.
  2. …der Umsetzung von betriebswirtschaftlichen Anforderungen
    1. Mit abap2xlsx können Sie die kreativen Anforderungen der Fachbereiche zur Erstellung, zum Auslesen und zur Änderung von Excel-Dateien umsetzen. Und das schon mit ABAP 7.31. Sie müssen so nicht Ihre Prozesse anpassen, weil die OLE-basierte SAP API für Excel-Mappen keine Hintergrundjobs unterstützt und ein installiertes Microsoft Office beim Anwender erwartet. Sie müssen insbesondere auch nicht den Entwicklungsaufwand investieren selbst eine Codebase zu implementieren und zu warten, die sich um die Konvertierung und den Umgang mit Excel-Dateien befasst. Und Sie müssen auch nicht in Anbetracht des Implementierungsaufwands die Anforderung als nicht verhältnismäßig umsetzbar abweisen sondern können auf der Arbeit aufsetzen, die andere sich bereits gemacht haben.
    2. Ähnlich verhält es sich bei anderen technischen Problemstellungen, zu denen es bereits etablierte Open-Source-Lösungen gibt. Beispielsweise ABAP Logger anstelle eigener Wrapper-Klassen um die Funktionsbausteine des Business Application Log. Oder ajson als JSON-Bibliothek für ABAP ab 7.02.
  3. …der Außendarstellung
    1. Sie können bewerten, ob wiederverwendbare Komponenten Ihrer ABAP-basierten Lösungen nicht auch als Open-Source-Projekt Sinn machen würden. Coding, welches nicht in Konkurrenz Ihr Geschäftsmodell umsetzt, sondern die Optimierung des Entwicklungsprozesses oder übergreifenden Themen wie der User Experience, Revisionssicherheit oder ähnlichem dient, könnte auch von anderen Unternehmen genutzt werden. Wenn Sie diese Komponenten als frei verfügbare Software publizieren, ermöglichen Sie externe Beteiligungen an der Entwicklung von denen Sie profitieren können.
      Zusätzlich kann dies als Aushängeschild im Recruiting neuer Entwickler dienen. Diese sehen direkt, dass Sie modern entwickeln und sich nicht scheuen den Quellcode nach außen zu zeigen.
      Beispiele: IBM, Microsoft, rku.it, Schwarz IT
    2. Wenn Ihr Unternehmen Dienstleistungen zur Verfügung stellt, die über Schnittstellen mit Partnern/Kunden umgesetzt werden, welche diese auch in Ihren SAP-Systemen mittels ABAP implementieren, können Sie eine Open Source SDK bereitstellen, welche Ihre API implementiert. Die Nutzer der SDK haben direkt eine Möglichkeit Issues zu öffnen oder ergänzende Features selbst per Pull Request vorzuschlagen und ihren Implementierungsaufwand erheblich zu verringern. Sie können intern die SDK selbst einsetzen oder für Integrationstests verwenden.
      Beispiele: ABAP SDK for Azure, AI SDK for SAP ABAP, ABAP SDK for IBM watsonx
  4. …im Upskilling von Entwicklern
    1. Durch die Auseinandersetzung mit externen Bibliotheken und deren Implementierung können Sie Ihre Kenntnisse erweitern mit Blick auf objektorientiertes Design und Softwarearchitektur. Sie können mit neuen Technologien oder Ansätzen vertraut werden und das direkt mit produktivem Quellcode, statt Demobeispielen. Dieser Effekt verstärkt sich insbesondere bei der Beteiligung durch eigene Features oder Bugfixes und Code Reviews.

Sie sehen es gibt viele Stellen an denen Open Source, auch in der ABAP-Entwicklung, einen erheblichen Mehrwert liefern kann. Eine Auseinandersetzung mit dem Thema lohnt sich daher in jedem Fall.

Erschwerte Rahmenbedingungen und Risiken

  • Code in der Datenbank
  • Proprietäre Programmiersprache
  • Monolithisches System
  • Geschäftskritische Anwendungen und Prozesse
  • Unternehmenskritische Daten im System

Ausbaustufen

Eine mögliche Herangehensweise an das Thema ist die verschiedenen Anwendungsfälle als aufeinander aufbauend zu sehen. Zusätzlich lässt sich der Einsatz von Open-Source-Komponenten in der eigenen Software aufteilen in die Nutzung im Entwicklungsprozess und die Integration in das Produktivcoding.

flowchart LR
 subgraph nutzung["Nutzung von Open-Source-Lösungen"]
        nutzung_dev("Nutzung von Entwicklertools im Entwicklungsprozess")
        nutzung_prd("Nutzung von Bibliotheken im Produktivcoding")
  end
    nutzung_dev -.-> nutzung_prd
    nutzung --> beteiligung("Beteiligung an Open-Source-Lösungen")
    beteiligung --> bereitstellung("Bereitstellung eigener Open-Source-Lösungen")

Notizen:

An dieser Stelle ist bereits eine Unterscheidung erkennbar, die bei einer stückweisen Einführung einer Open-Source-Strategie im SAP- und speziell im ABAP-Kontext helfen kann. Punkt 1, die Optimierung der Entwicklungsprozesse, betrifft Tooling, welches im Entwicklungsprozess genutzt wird. Dies ist oft zunächst einfacher zu betrachten als Punkt 2, die Umsetzung von betriebswirtschaftlichen Anforderungen. Bibliotheken, die dabei genutzt werden, erreichen zwangsläufig an der Stelle auch Ihr Produktivsystem und sind somit nochmal unter anderen Gesichtspunkten zu betrachten.

  • Fertige Lösungen für eigene Probleme existieren bereits
    • Kostenersparnis gegenüber Eigenentwicklung und Wartung
    • End-User-Benefit gegenüber “Aufwand zu groß” / rentiert sich nicht
  • Open-Source-Tools für den Entwicklungsprozess erhöhen die Softwarequalität, verkürzen Entwicklungszeiten, verringern Fehler
  • Aushängeschild in der Personalsuche: Nutzung moderner Tools, wir entwickeln modern
  • Möglichkeit externer Contributions
  • Enablement der Nutzung eigener Lösungen für Kunden (SDK/API für ABAP)

Lizenzen

Aspekte von Lizenzen:

MIT Apache 2.0 GPL 3.0 GPL 2.0 ...
Rechte
Kommerzielle Nutzung Erlaubt Nicht Erlaubt
Weiterverbreitung Erlaubt
Pflichten

choosealicense

https://choosealicense.com/appendix/

Bereitstellung von Lizenzen in ABAP-Code…

Inhalte

Einsatz von Open Source →