ABAP Unit - Software-Architektur

Inhaltsverzeichnis

• Voraussetzungen
• Architektur
• Daten
• Fazit

In diesem Artikel wollen wir etwas die Architektur der Zukunft beschreiben, wie sie aktuell aus unserer Sicht aussieht. Dabei muss man einige Punkte beachten, wenn man darüber nachdenkt, wie Anwendungen und Software im SAP Umfeld die nächsten Jahre aussehen soll.

 

Voraussetzungen

Welche Punkte sind also für die Zukunft zu beachten? Dabei sollte man einen Blick auf die aktuellen und vergangenen Techniken werfen, die zum Einsatz kommen.

• Report Design (klassisch und objektorientiert)
• Design von Anwendungen (MVC Pattern)
• Testbarkeit von Anwendungen
• API Design mit OData Services
• Wiederverwendbarkeit von Zugriffen (DAOs)
• Clean Code

 

Im Gegensatz zu den klassischen Anwendungen, wurden die letzten Jahre immer mehr Techniken aus der gängigen Software Entwicklung übernommen und sollten ebenfalls in der ABAP Entwicklung zum Einsatz kommen.

 

Architektur

Da du in diesem Buch nun viel über das Design von testbaren Anwendungen erfahren hast und welche Vorteile globale Klassen beim Testen haben, wird die Architektur dir etwas klarer und verständlicher sein.

 

Im Grunde steht hier die globalen Klasse im Fokus der Architektur. Alle Komponenten, die entwickelt werden, sind auf Wiederverwendung ausgelegt, um so zentrale Aspekte von Clean Code und auf deren Prinzipien aufzusetzen. Alle anderen Komponenten in der Hierarchie, wie zum Beispiel Reports, RFC-Funktionsbausteine oder OData-Services, dienen nur als Hüllen zum Aufrufen der Klasse. Damit ist die Logik auf globaler Ebene gekapselt und kann an beliebigen Stellen wiederverwendet werden. Mit dieser Architektur ist auch sichergestellt, dass jede Klasse seinen eigenen Unit-Test hat, der dann auch noch die volle Funktionalität von ABAP Unit zur Verfügung stellt.

Eine solche Architektur solltest du dir erst einmal durch den Kopf gehen lassen und dir dabei mit jeder Entwicklung vor Augen führen, welchen Vorteil diese Architektur aufweist. Dazu ein paar Beispiele wieso du dir so einen Umstand machen solltest:

• Du implementierst in einem Report ein paar Validierungen, um Eingaben gegen bestimmte Tabellen und Daten zu prüfen. Diese Validierung kannst du nicht nur in einem Report benötigen, sondern auch in einer Eingangsschnittstelle (RFC-Funktionsbaustein), einem OData-Service oder einem anderen Report.
• Du greifst auf Daten einer Tabelle zurück und aktualisierst deren Inhalte. Wenn du dies nur lokal in deinem Report machst, dann wird die nächste Implementierung in einer Funktionsbaustein doppelt sein, da diese Funktion nicht sauber gekapselt wurde. Hier lohnt sich eine zentrale Stelle für den Zugriff auf die Tabelle.

 

Für alle diese Beispiele kannst du noch zusätzlich ABAP Unit Tests implementieren und für stabile APIs zu deinen Anwendungen sorgen. Bei Erweiterungen musst du dir in Zukunft weniger Gedanken machen.

 

Daten

Zugriffe auf die Datenbank können mit DAOs (Data Access Objects) abgebildet werden. Damit hat man einen Single-Point-of-Access für die Tabelle und bildet die Logik für den Zugriff nicht doppelt ab. Berechtigungsprüfungen und Sperrkonzepte müssen nur einmal implementiert werden. Weiterhin kann das Objekt für den Zugriff durch andere Anwendungen freigegeben werden.

Handelt es sich dabei um einen Zusammenhang von Tabellen die Abhängigkeiten untereinander haben, dann sollte ein DAO nicht mehr verwendet werden. Hier handelt es sich eher um ein Business Objekt, dafür gibt es andere Technologien, wie:

• BOPF - Business Object Processing Framework
• RAP - ABAP Restful Application Programming Modell

 

An dieser Stelle solltest du dich für RAP entscheiden, wenn die neue Architektur bereits in deinem System unterstützt wird. Ansonsten kannst du auch auf BOPF ausweichen, um so ein sauberes und konsistentes Business Objekt abzubilden.

 

Fazit

Mit einer sauberen Architektur und Regeln zur Verwaltung von Quellcode, verbessert sich die Wiederverwendung von Code im System. Durch die Möglichkeit der automatisierten Testbarkeit und von Tests, können auch Fehler während der Entwicklung einfach aufgedeckt werden. Wichtig ist vor allem die Abstimmung und Unterstützung innerhalb des Entwicklungsteams und dem Finden eines gemeinsamen Wegs.