ABAP Cloud - Zugriff auf Komponenten

Inhaltsverzeichnis

• Einleitung
• Ebene
• Software Komponente
• Klassisches ABAP
• Lokale Entwicklung
• Zugriff
• Use-Case
• Clean Core Level Concept
• IDE Actions
• Fazit

In diesem Artikel gehen wir auf ABAP Cloud, klassisches ABAP und lokale Komponenten ein und wie du sie nutzen kannst, um bestimmte Szenarien aufzubauen.

 

Einleitung

Im Artikel über Software Komponenten und deren Beziehung hatten wir uns angeschaut, wie sich Software Komponenten untereinander verhalten. Wie sieht es aber in einem On-Prem System mit dem klassischen ABAP aus oder wie mit den lokalen Komponenten in ZLOCAL oder $TMP? In diesem Artikel werden wir uns die verschiedenen Ebenen einmal genauer anschauen und wie diese miteinander interagieren können.

 

Ebene

Dazu teilen wir die verschiedenen Objekte und Pakete auf drei Ebenen auf und wie du sie besser erkennen kannst. Dabei werden wir das Thema der Paketkapselung und -schnittstellen erst einmal außen vorlassen.

 

Software Komponente

Eine Software Komponente (SWC) ist eine Art Customizing, dass einem Paket zugeordnet werden kann. Bisher hatten Kunden vor allem die Software Komponente "HOME" in ihrer Entwicklung verwendet. Mit der Einführung des ABAP Environments und ABAP Cloud wurde die Software Komponente auch zur Strukturierung von Entwicklungen verwendet. Im Umfeld des ABAP Environments wird damit abgegrenzt:

• Sprachversion - Entwicklungen die unter dem Strukturpaket liegen, erhalten automatisch die Sprachversion für "ABAP for Cloud Development". Damit ist die Sprachversion innerhalb der Komponente sichergestellt und es müssen die Regeln für ABAP Cloud befolgt werden.
• Abgrenzung - Die angelegten Komponenten innerhalb der Software Komponente können sich gegenseitig verwenden und aufrufen, so wie es bisher in der HOME Komponente der Fall war. Allerdings funktioniert dies nicht, wenn Komponenten einer anderen SWC aufgerufen werden soll.
• Git - Hinter einer SWC befindet sich 1:1 ein Git Repository, wohin nach Freigabe eines Transports ein Commit erfolgt. Damit ist die komplette Entwicklung, sowie alle Änderungen, an einer zentralen Stelle zu finden.
• Transport - Der Transport erfolgt im ABAP Environment pro Software Komponente, es erfolgt keine Vermischung von verschiedenen Objekten aus unterschiedlichen SWCs. Bei normalen Transporten spielt dies keine Rolle, hier ist kein Commit in das Git nötig.
• APIs - Wenn es um die Nutzung von Standardobjekten geht, dann sind diese in den meisten Fällen aus der Sprachversion "Standard ABAP" und werden per Freigabe für ABAP Cloud enabled. Bedeutet für uns aber auch, wir haben einen eingeschränkten Scope auf die Objekte, die wir nutzen können.

 

Hinweis: Die Punkte Git und Transport gelten nur für das ABAP Environment, da hier der Standard gCTS für den Trasnport ist. Die verschiedenen S/4HANA Versionen verwenden in den meisten Fällen das klassische CTS und es kann optional gCTS eingesetzt werden.

 

Klassisches ABAP

Im Bereich des klassischen ABAP und der Kundenentwicklungen sind wir vor allem im Bereich der HOME Komponente unterwegs. Externe Dienstleister und Hersteller nutzen Software Komponenten zur Auslieferung von Produkten und Addons. In diesem Bereich gibt es erst einmal keine Einschränkungen beim Zugriff. Innerhalb der Komponente können wir auf alle Artefakte zugreifen, solange die Paketschnittstellen nicht aktiviert sind. Objekte auf dieser Ebene werden bei Änderungen in Transporten aufgezeichnet, meist im klassischen CTS, und damit auf der Systemlandschaft ausgerollt.

Somit können wir auf dieser Ebene alle Objekte eines SAP Systems nutzen und haben hier keine Einschränkungen. Grundsätzlich muss man aber auch dazu sagen, dass es hier auch gewissen Einschränkungen gibt oder manche SAP Objekte sich nicht für die Nutzung eignen.

 

Lokale Entwicklung

Für die lokale Entwicklung gibt es aktuell zwei Konzepte, die genutzt werden können. Hier kommt es auch auf das genutzte Paket an.

• $TMP - Entwicklungen in diesem Paket sind alles lokale Objekte des Systems. Für die Objekte wird kein Transport benötigt, sie werden aber auch nicht in der Systemlandschaft transportiert. Objekte in diesem Bereich werden im Standard mit "Standard ABAP" definiert, damit kann auf alle Objekte zugegriffen werden.
• ZLOCAL - Entwicklungen unter diesem Paket sind ebenfalls lokale Objekte, die nicht transportiert werden. Je nach Release, kann es sein das nach einem Transport gefragt wird. Hier gab es im ABAP Environment mit 2508 Änderungen, sodass neu angelegte Pakete keinen Transport mehr erfordern. Objekte, die hier angelegt werden, werden mit "ABAP for Cloud Development" definiert und können somit nicht auf den kompletten Standard zugreifen, sondern nur auf freigegebene APIs. Allerdings dürfen Objekte aus diesem Paket auf alle Objekte einer Software Komponente zugreifen, ohne dass eine Freigabe erfolgt ist.

 

Grundsätzlich eignet sich die lokale Entwicklung für mehrere Szenarien:

• Prototyping - Da die Objekte und Pakete lokal sind, werden diese oft für Prototypen, Tests und Schulungen verwendet. Damit wird erst einmal kein Änderungsauftrag erzeugt und im Nachgang können die Objekte einfach aus dem System entfernt werden.
• Generierung - Bestimmte Frameworks, wie LSMW oder SAP Query, nutzen die lokalen Objekte in Test und Produktion, um Objekte zu generieren und abzulegen. Da kein Transport erfolgt und die Objekte nur lokal verwendet werden, lohnt sich dieser Layer besonders.

 

Zugriff

Wie sieht es nun eigentlich mit dem Zugriff aus den verschiedenen Layern aus? Dazu wollen wir uns gleich eine Grafik anschauen und die verschiedenen Szenarien ableiten. Dazu die folgende Legende, um die Grafik einmal zu beschreiben.

 

Die folgende Übersicht demonstriert die Zugriffe aus Software Komponenten in Richtung Standard, aber auch zwischen ABAP Cloud, Standard ABAP und lokalen Komponenten. Dabei können die Komponenten unterschiedliche Objekte repräsentieren, zum Beispiel Klassen, Core Data Services, Tabellen, RAP Objekte und Vieles mehr. In der Mitte steht dabei der SAP Standard, da dieser für die meisten Eigenentwicklungen benötigt wird für den Zugriff auf die APIs.

 

Fassen wir daher einmal die Besonderheiten zusammen:

• Standard ABAP - Im Standard dürfen wir eigentlich alles tun, wir können den kompletten SAP Standard nutzen, aber auch alle Komponenten einer Software Komponente. Damit sind wir ebenfalls flexibel, wenn wir bestimmte APIs erst einmal nur in ABAP Cloud zur Verfügung stellen, da wir sie auch in bestehenden Anwendungen verwenden können.
• ZLOCAL - Die lokale ABAP Cloud Komponente kommt dem Standard ABAP schon sehr nah, darf allerdings vom Standard nur die freigegebenen Objekte verwenden. Damit soll sichergestellt werden, dann du auch im lokalen Kontext nur das verwenden kannst, was der Standard zur Verfügung stellt.
• Software Komponente - Ist die restriktivste Form, da wir nur freigegebene Objekte (C1) nutzen können. Dafür können wir alle möglichen Objekte verwenden, auch aus dem lokalen Bereich. Hier solltest du allerdings vorsichtig sein, da dies zu Transportproblemen und Fehlern führen kann.

 

Use-Case

Was können wir nun aus den verschiedenen Eigenschaften ableiten? Schauen wir uns dazu zwei aktuelle Use-Cases an, die wir On-Prem und in der Cloud umsetzen können.

 

Clean Core Level Concept

Wenn wir das Level Concept umsetzen und ABAP Cloud Komponenten zur Verfügung stellen, können wir diese immer noch in der klassischen ABAP Entwicklung verwenden. Ein klassisches Beispiel wäre hier ein Nachrichtenlogging oder zentrale Einstellungen, die wir für Anwendungen hinterlegen können. Die saubere Trennung erfolgt zwischen den verschiedenen SWCs, was aber wieder ein kleines Risiko für Standard ABAP bedeutet, da wir Objekte nutzen können, die vielleicht nicht für die Freigabe gedacht sind.

 

IDE Actions

Die Entwicklung von IDE Actions können wir ganz entspannt in ZLOCAL machen, da wir von dort Zugriff auf die Komponenten in den Software Komponenten haben, was für zentrale Aktionen wichtig ist. In 99% der Fälle werden wir die Aktionen nutzen, um unseren Entwicklungsflow auf dem Entwicklungssystem zu beschleunigen, daher müssen diese auch nicht transportiert werden.

 

Fazit

Welche Ebene darf auf welche Elemente zugreifen? Diese Frage sollten wir nun geklärt haben, auch die verschiedenen Möglichkeiten, die es in diesem Zusammenhang gibt. Damit steht auch einer API in ABAP Cloud nicht im Weg, aber Vorsicht, wenn die Kollegen am Konzept vorbei aus Classic ABAP deine Objekte nutzen.