Rheinwerk < openbook > SAP-Wissen aus erster Hand
SAP-Wissen aus erster Hand.
 
Inhaltsverzeichnis
Vorwort zur vierten Auflage
1 ABAP und die ersten Schritte im SAP-System
2 ABAP Dictionary
3 Programmieren im ABAP Editor
4 Felder und Berechnungen
5 Modifikation von Zeichenketten
6 Debugging von Programmen
7 Modifikation von transparenten Datenbanktabellen
8 Rechnen mit Datum und Zeit, Mengen und Währungen
9 Mit Daten in einer Datenbanktabelle arbeiten
10 Programmablaufsteuerung und logische Ausdrücke
11 Selektionsbildschirme
12 Interne Tabellen
13 Modularisierung von Programmen
14 Weiterführende Themen
A Icons auf einen Blick
B Abkürzungsverzeichnis
C Die Autoren
Stichwortverzeichnis

Download:
- Beispielprogramme, ca. 23 KB

Buch bestellen
Ihre Meinung?

Spacer
<< zurück
Einstieg in ABAP von Karl-Heinz Kühnhauser, Thorsten Franz
Buch: Einstieg in ABAP

Einstieg in ABAP
Pfeil 1 ABAP und die ersten Schritte im SAP-System
Pfeil 1.1 Architektur des SAP-Systems im Überblick
Pfeil 1.1.1 Technische Architektur
Pfeil 1.1.2 Betriebswirtschaftlich-organisatorische Architektur
Pfeil 1.1.3 Plattformunabhängigkeit
Pfeil 1.2 Anwendungsprogramme und Laufzeitumgebung
Pfeil 1.2.1 Workprozesse
Pfeil 1.2.2 Struktur von ABAP-Programmen
Pfeil 1.3 Anmelden und Abmelden am System
Pfeil 1.3.1 Betriebswirtschaftlicher Modulüberblick
Pfeil 1.3.2 ABAP Workbench
Pfeil 1.3.3 Abmelden vom SAP-System

Bevor Sie damit beginnen können, Ihre eigenen ABAP-Anwendungen zu entwickeln, sollten Sie sich in diesem Kapitel kurz mit den Besonderheiten eines SAP-Systems vertraut machen.

 
Zum Seitenanfang

1    ABAP und die ersten Schritte im SAP-System Zur vorigen ÜberschriftZur nächsten Überschrift

Die client-server-basierte Entwicklung von Geschäftsanwendungen, wie sie im SAP-Umfeld eingesetzt werden, erfordert ein anderes Arbeiten und Denken als die Entwicklung lokal lauffähiger Programme. Zudem verarbeitet das SAP-System nicht einfach nur Anwendungen, sondern unternehmensübergreifende, betriebswirtschaftliche Applikationen. Bevor wir uns also in die ABAP-Programmierung stürzen können, lohnt sich ein Blick auf die SAP-Architektur, die Entwicklungsumgebung für ABAP und die grundsätzliche Struktur von ABAP-Reports. All das finden Sie in diesem Kapitel.

[»]  ABAP

ABAP ist die Programmiersprache von SAP, die eigens für dialogorientierte Datenbankanwendungen entwickelt wurde. Was als Allgemeiner Berichts-Aufbereitungs-Prozessor begann, steht heute als Advanced Business Application Programming für eine der weltweit wichtigsten Programmiersprachen für die Entwicklung betriebswirtschaftlicher Anwendungen.

Bevor wir uns mit der ABAP-Programmiersprache selbst beschäftigen, betrachten wir kurz die betriebswirtschaftliche und technische Umgebung, in der ABAP-Programme laufen. Denn in nahezu jedem mittleren oder großen Unternehmen müssen täglich, monatlich und jährlich Millionen von Datensätzen verarbeitet und gespeichert werden. Viele Benutzer arbeiten hierbei gleichzeitig an gemeinsamen Datenbeständen auf einer gemeinsamen Datenbank. Dies stellt besondere betriebswirtschaftliche und technische Anforderungen hinsichtlich der Datensicherheit und des Datenschutzes an das System, auf dem die Daten verarbeitet und gehalten werden, und an die Systemarchitektur. SAP ERP (Enterprise Resource Planning), so der Name der SAP-Unternehmensanwendung, bietet ein Business-Paket für Unternehmen, die tagtäglich auf die computergestützte Datenverarbeitung angewiesen sind. Mit der SAP Business Suite wird dieses Paket um weitere Anwendungen ergänzt.

In der Datenverarbeitung sind 30 Jahre eine Ewigkeit. Doch in bestimmten, gesetzlich geregelten Fällen müssen betriebswirtschaftliche Daten 30 Jahre lang zurückverfolgt werden können. SAP hat aus diesem Grund von Anfang an konsequent auf Unabhängigkeit gesetzt: Unabhängigkeit von Hardware, Betriebssystemen, Datenbanksystemen und deren Herstellern (wenngleich SAP hier bei ihrem eigenen Datenbank-Flaggschiff SAP HANA teilweise großzügig Ausnahmen macht und auf die gewohnte Datenbankunabhängigkeit verzichtet) – und auch Unabhängigkeit von Programmiersprachen. Daher wurde ABAP entwickelt, eine Programmiersprache, die bis heute die Programme aus ihrer »Gründerzeit« verarbeiten kann.

Der Vorteil ist ein offenes und grenzenloses System, das auch in Zukunft durch neue Komponenten erweiterbar bleibt – und auch noch die Daten von damals verarbeiten kann. Die Daten Ihres privaten PCs aus dem Jahr 1980 – sofern Sie eine solche Rarität noch besitzen – werden Sie vermutlich nicht so einfach auf einem aktuellen Rechner verarbeiten können, ganz abgesehen von Problemstellungen wie der Historienverfolgung für Datenänderungen bis hin zu der Frage, ob Sie die Datenträger von damals noch lesen können.

Der Preis, den man allerdings für diesen Vorteil bezahlen musste, heißt Modularisierung: So ist unter technischen Gesichtspunkten die Arbeit auf mehrere Maschinen, Server und Dienste verteilt, und unter betriebswirtschaftlichen Gesichtspunkten auf verschiedene Module, ergänzt durch Lösungen für Branchen oder Kunden. Dennoch arbeiten alle Benutzer technisch gesehen auf einer gemeinsamen Datenbasis und einer gemeinsamen Datenbank, sodass es keine Insellösungen gibt und redundante Datenhaltung weitestgehend vermieden wird.

Seit der Einführung von SAP ERP ist mit dem SAP NetWeaver Application Server die ABAP-Welt weiter geöffnet worden. ABAP kann JavaScript-Programme starten und Daten zwischen ABAP und JavaScript in beide Richtungen übergeben. Mit Web Dynpro steht ein Werkzeug für die Erstellung webbasierter Geschäftsanwendungen zur Verfügung. Auch bietet der ABAP-Server mächtige Werkzeuge zur Erzeugung und Verarbeitung von XML-Datenströmen sowie zur Bereitstellung und zum Aufruf von Webservices. Mit SAP Gateway und OData ist das ABAP-System als leistungsfähiges Backend für moderne Webanwendungen auf Basis von HTML5 und JavaScript gut aufgestellt. Unter dem Namen SAP Fiori wurde damit eine neue Generation benutzerfreundlicher Anwendungen für Browser und mobile Geräte möglich. Somit sind problemlos zeitgemäße Webapplikationen möglich, die Benutzern die Funktionen des ABAP-Systems im Internet oder Intranet über einen Webbrowser oder mobile Geräte zugänglich machen. Für die Entwicklungsarbeit für Webapplikationen und Webservices gibt es eigene Werkzeuge und Workbenches, die allerdings nicht Gegenstand dieses Buches sind.

 
Zum Seitenanfang

1.1    Architektur des SAP-Systems im Überblick Zur vorigen ÜberschriftZur nächsten Überschrift

SAP-Systemlandschaften lassen sich auf verschiedene Weise charakterisieren. In diesem Abschnitt werden Ihnen die Herangehensweisen erläutert, und Sie erfahren, was diese für Ihren Einstieg in ABAP bedeuten. Im Lauf Ihres Entwicklerlebens werden Ihnen die hier vorgestellten Begriffe, wie z. B. Präsentationsserver, immer wieder begegnen. 

 
Zum Seitenanfang

1.1.1    Technische Architektur Zur vorigen ÜberschriftZur nächsten Überschrift

Aus technischer Sicht ist das SAP-System in drei Schichten unterteilt:

  • Präsentationsschicht

  • Applikationsschicht

  • Datenbankschicht

Diese sogenannte Client-Server-Architektur beruht auf dem Prinzip der Arbeitsteilung (siehe Abbildung 1.1).

Client-Server-Architektur des SAP-Systems

Abbildung 1.1    Client-Server-Architektur des SAP-Systems

Die Ein- und Ausgabe von Daten sowie die Arbeit des Benutzers mit Dialogbildschirmen erfolgen vor Ort im Intranet am Arbeitsplatz-PC, dem Client oder Präsentationsserver. Präsentationsserver bilden die Präsentationsschicht des SAP-Systems. Die Kommunikation zwischen dem Präsentationsserver und dem Applikationsserver übernimmt dabei ein spezielles Programmpaket für die grafische Benutzerschnittstelle, das SAP GUI (siehe Abschnitt 1.3, »Anmelden und Abmelden am System«). Das SAP GUI muss lokal auf dem Client installiert sein. Ohne dieses Programmpaket ist die direkte Kommunikation mit dem SAP-System nicht möglich.

[»]  SAP NetWeaver Business Client

Möglicherweise ist Ihnen der Begriff SAP NetWeaver Business Client für Desktop oder die Abkürzung NWBC begegnet. Hierbei handelt es sich um eine mit dem SAP GUI eng verwandte Anwendung, die ebenfalls zwischen Applikationsserver und Präsentationsserver steht.

Die Verarbeitung der Daten erfolgt zentral auf einem oder mehreren Servern, den Applikationsservern. Der oder die Applikationsserver kommunizieren mit dem Client über einen Message-Server und das SAP GUI (Graphical User Interface). Je nach betriebswirtschaftlicher Anforderung könnte auch ein einziger Applikationsserver genügen. Bei großen Systemen stellt ein einziger Applikationsserver jedoch üblicherweise nicht alle Dienste zur Verfügung, sondern nur einen Teil. Die Lastverteilung und die Kommunikation zwischen den Applikationsservern übernimmt dann der Message-Server, ebenso wie die Verbindung zur Präsentationsschicht und zu den Benutzern.

Mit dem Datenbankserver läuft die Kommunikation über ein Datenbank-Management-System (relationales Datenbank-Management-System oder RDBMS). Je nach physischer Datenbank funktioniert dieses System im Hintergrund unterschiedlich. Für einen Entwickler – d. h. Sie – ist hingegen die Oberfläche bei der Arbeit mit den verschiedenen Datenbanksystemen immer gleich. Auf den Applikationsservern, die auch als Applikationsschicht des SAP-Systems bezeichnet werden, laufen die Programme, d. h. beispielsweise Ihre ersten, mithilfe dieses Buches selbst geschriebenen Programme.

[»]  Einer oder viele?

Im weiteren Verlauf des Buches wird zwischen einem und mehreren Applikationsservern nicht mehr unterschieden, denn für den Einstieg in ABAP ist diese Unterscheidung irrelevant.

Die Datenhaltung für ein SAP-System übernimmt eine gemeinsame Datenbank auf wiederum einem eigenen Server, dem Datenbankserver. Je nach Datenvolumen und sonstigen Rahmenbedingungen können der Applikations- und der Datenbankserver auf einer Maschine liegen oder auf mehrere Maschinen verteilt sein. Beispielsweise könnte der Applikationsserver aus mehreren physischen Servern bestehen. Auch bei dieser Thematik wird im weiteren Verlauf nicht mehr zwischen gemeinsamen und getrennten Servern für Applikation und Datenbank unterschieden.

Bei Webanwendungen ist die Architektur sehr ähnlich: Der Webbrowser übernimmt anstelle des SAP GUI die Aufgabe des Clients oder Präsentationsservers. Die Kommunikation mit dem ABAP-System erfolgt anstatt über den Message-Server über das im ABAP-Server enthaltene Internet Communication Framework (ICF). Auch hier ist die Präsentationsschicht sorgfältig von der Applikationsschicht und Datenhaltung abgegrenzt.

 
Zum Seitenanfang

1.1.2    Betriebswirtschaftlich-organisatorische Architektur Zur vorigen ÜberschriftZur nächsten Überschrift

Abgesehen von der technischen Sicht auf die Client-Server-Architektur, werden SAP-Systemlandschaften häufig auch in betriebswirtschaftlich-organisatorischer Form beschrieben:

  • Test- und Entwicklungssystem

  • Konsolidierungssystem

  • Produktivsystem

Auch bei dieser mehrstufigen Gliederung gilt das Prinzip der Arbeitsteilung. Je nach Datenmenge und Anforderungen an die Datensicherheit und den Datenschutz ist in der Praxis von zwei bis zu vier Systemstufen alles zu finden. Die minimale Ausprägung besteht aus Test- und Produktivsystem. Beide Systeme können – je nach Betriebssystem und Hardware des Servers – auch auf einer gemeinsamen physischen Maschine laufen, sind aber technisch getrennt als eigene Instanz installiert und verfügen jeweils über eine eigene Datenbank. Bei vierstufigen Landschaften liegen zwischen Entwicklungs- und Produktivsystem zwei Qualitätssicherungssysteme.

Hinsichtlich der Hardwareressourcen ist die Skala nach oben hin offen und endet im Mainframe-Bereich bei den Großrechnern. Entscheidende Einflussfaktoren für das Sizing sind das Betriebssystem des Applikationsservers sowie das Datenvolumen. Es gibt Betriebssysteme, die es erlauben, mehrere Instanzen auf einer physischen Maschine zu betreiben; andere Betriebssysteme können dies nicht. Das anfallende Datenvolumen, d. h. die Anzahl der zu verarbeitenden Datensätze, bedeutet für den Applikationsserver Rechenzeit und für den Datenbankserver Zugriffszeit für Lese- und Schreibprozesse. Nun hängt von den betriebswirtschaftlichen Anforderungen ab, wie schnell das Ergebnis zur Verfügung stehen soll. Server mit geringen Ressourcen stoßen hier schnell an ihre Grenzen.

[»]  Sizing

Das Bestimmen der optimalen Hardwarearchitektur, das sogenannte Sizing, ist ein eigenes Wissensgebiet, auf das hier nicht näher eingegangen werden kann.

Im Test- und Entwicklungssystem liegen Übungs- und Schulungsdaten; hier wird programmiert, hier werden Systemeinstellungen getestet. Auch die kundenspezifischen SAP-Einstellungen, das Customizing, werden im Test- und Entwicklungssystem erstmals gepflegt und an kundenspezifische Anforderungen angepasst.

Naturgemäß sind Test- und Entwicklungssysteme relativ offen und ungeschützt. Zumeist gibt es zahlreiche Entwicklungsbenutzer mit umfangreichen Berechtigungen, die Daten und Strukturen aufbauen und verändern, aber vielleicht nicht mehr weiterpflegen und verwerfen. Zuweilen findet man in diesem System auch einen sogenannten Sandkasten, einen Bereich für Anwender, die dort Geschäftsprozesse simulieren und testen. In der Regel ist es jedoch ratsam, die »ernsthaften« Entwicklungs- und Konfigurationsaufgaben im Test- und Entwicklungssystem von den spielerischen, explorativen Tätigkeiten im Sandkasten zu trennen und hierfür ein gesondertes Sandbox-System bereitzustellen. Durch die relativ große Anzahl »mächtiger« Benutzer sind Datenschutz und Datensicherheit in diesen Systemen nicht in dem Ausmaß gewährleistet, wie es ein produktives System erfordert.

Für die nächste Stufe der Systemlandschaft werden Objekte vom Test- und Entwicklungssystem zunächst in das Konsolidierungs- bzw. Qualitätssicherungssystem übernommen. Wie der Name schon sagt, dient dieses System der Qualitätssicherung. Zugang und Berechtigungen, Datensicherheit und Datenschutz werden restriktiver gehandhabt als im Test- und Entwicklungssystem.

Im Konsolidierungssystem findet häufig keine Entwicklung, sondern nur noch die Abnahme von Entwicklungen durch einen gesonderten Test statt. Oft werden zu diesem Zweck vom Produktivsystem echte Daten durch einen Transport kopiert und eventuell anonymisiert oder strukturgleiche Daten im Konsolidierungssystem aufgebaut. Erst, wenn die Entwicklung auch mit diesen »echten« Daten ohne Fehler läuft, wird in einem weiteren separaten Transport die Entwicklung in das Produktivsystem übernommen.

Das Produktivsystem birgt für das Unternehmen die höchsten Sicherheitsrisiken und wird deshalb am besten geschützt. Systemparameter dürfen hier nicht direkt verändert werden. Entwicklungen oder Customizing-Einstellungen werden auf dem Produktivsystem nicht vorgenommen. Nur über protokollierte Transporte werden getestete und freigegebene Objekte in das Produktivsystem importiert.

Aus dieser mehrstufigen Systemaufteilung ergeben sich u. a. zwei Folgerungen: Erstens haben echte Produktivdaten in einem Testsystem nichts verloren, und zweitens muss man unterscheiden können, welche Entwicklungen und Einstellungen vom Test- und Entwicklungssystem ins Produktivsystem übernommen werden sollen und welche nicht. Für die Übernahme dieser Objekte in ein anderes SAP-System gibt es spezielle Werkzeuge, die im Korrektur- und Transportwesen zusammengefasst sind. Auf dieses Spezialthema für Systemadministratoren wird hier allerdings nicht weiter eingegangen.

[+]  Transporte nicht selbst durchführen

Für Sie als Einsteiger ist es an dieser Stelle wichtig zu wissen, dass Sie Transporte von Objekten in ein anderes SAP-System als Entwickler in der Regel nicht selbst durchführen dürfen und können.

Das Transportwesen benötigt für den Transport eine Auftragsnummer. Diese Auftragsnummer kann vom Entwickler bereits beim ersten Anlegen und Sichern eines Objektes festgelegt werden. Bei strengeren Auflagen der Systemadministration darf ein Entwickler die Auftragsnummer nicht selbst vergeben, sondern muss diese von der Systemadministration anfordern. In diesem Fall darf er das Objekt, beispielsweise einen Report, erst nach der Zuteilung der Auftragsnummer anlegen. Der weitere Weg folgt einem immer gleichen Schema: Existiert ein Auftrag, muss dieser vom Entwickler zum Export freigegeben, d. h. zur Abholung bereitgestellt werden. Der Administrator des Zielsystems nimmt nun den Auftrag an und importiert ihn in sein System. Auf den Zeitpunkt hat der Entwickler keinen direkten Einfluss.

Immer wieder gibt es allerdings Objekte, die überhaupt nicht transportiert werden sollen. Dies können beispielsweise die Objekte sein, die im Rahmen dieses Buches angelegt werden. Solche Objekte werden lokal im Testsystem gespeichert und nie transportiert. Sie werden deshalb auch als lokale Objekte bezeichnet.

 
Zum Seitenanfang

1.1.3    Plattformunabhängigkeit Zur vorigen ÜberschriftZur nächsten Überschrift

Trotz der möglichen technischen und inhaltlichen Trennung von SAP-Systemen betrachten wir für den Einstieg in ABAP jedes SAP-System als technische Einheit (Instanz) und vernachlässigen dabei bewusst die Verteilung von Applikationen und Datenbanken auf mehrere Server. Ebenso interessiert es uns hier wenig, welche Hardware, welches Betriebssystem und welches Datenbanksystem tatsächlich unter unserem SAP-System liegen. Auch die Frage, ob auf einer Hardware eine oder mehrere Instanzen aufgebaut sind, spielt für den Einstieg keine Rolle. Für Fortgeschrittene kann dies jedoch ein sehr spannendes Thema sein, man denke nur an Performanceunterschiede und die Stabilität bei der Verarbeitung von großen Datenmengen und komplexen Abläufen.

Für Sie als Anfänger ist es hingegen beruhigend zu wissen, dass es eine der Stärken des SAP-Systems ist, unabhängig von einzelnen Systemkomponenten stabil zu laufen. Selbstverständlich gibt es zertifizierte Plattformen, d. h. von SAP geprüfte und abgenommene Kombinationen aus Hardware, Betriebssystem und Datenbank. Mit welcher dieser Verbindungen Sie allerdings arbeiten, ist für den Einstieg und die praktische Arbeit vorerst gleichgültig. Alles, was Sie an Werkzeugen benötigen, finden Sie auf der SAP-Oberfläche – und die sieht immer gleich aus, egal, welche Plattform im konkreten Fall darunterliegt. Wir arbeiten im Folgenden demnach nicht mit Datenbankwerkzeugen des Datenbankherstellers oder mit Tools des Betriebssystemherstellers, sondern ausschließlich mit SAP-Werkzeugen, bei denen gewährleistet ist, dass die Anweisungen in unseren Anwendungsprogrammen sauber in die entsprechenden Kommandos umgesetzt werden.

 


Ihre Meinung?

Wie hat Ihnen das Openbook gefallen? Wir freuen uns immer über Ihre Rückmeldung. Schreiben Sie uns gerne Ihr Feedback als E-Mail an kommunikation@rheinwerk-verlag.de

<< zurück
 Zum Rheinwerk-Shop
Zum Rheinwerk-Shop: Einstieg in ABAP Einstieg in ABAP
Jetzt Buch bestellen

 Buchempfehlungen
Zum Rheinwerk-Shop: SAP – Der technische Einstieg
SAP – Der technische Einstieg


Zum Rheinwerk-Shop: ABAP Objects – Das umfassende Handbuch
ABAP Objects – Das umfassende Handbuch


Zum Rheinwerk-Shop: ABAP-Entwicklung für SAP S/4HANA
ABAP-Entwicklung für SAP S/4HANA


Zum Rheinwerk-Shop: Kundeneigene Erweiterungen mit ABAP
Kundeneigene Erweiterungen mit ABAP


Zum Rheinwerk-Shop: Schrödinger programmiert ABAP
Schrödinger programmiert ABAP


Zum Rheinwerk-Shop: Migration nach SAP S/4HANA
Migration nach SAP S/4HANA


Zum Rheinwerk-Shop: Design Thinking mit SAP
Design Thinking mit SAP


 Lieferung
Versandkostenfrei bestellen in Deutschland, Österreich und in die Schweiz
InfoInfo

 
 


Copyright © Rheinwerk Verlag GmbH 2020
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das <openbook> denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt.
Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.

 
[Rheinwerk]

Rheinwerk Verlag GmbH, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, service@rheinwerk-verlag.de

Cookie-Einstellungen ändern