| 1 |
HELP.BCABA ABAP Programmierung (BC-ABA) Release. C ABAP Programmierung (BC-ABA) SAP AG Copyright Copyright SAP AG. Alle Rechte vorbehalten. Weitergabe und Vervielfaeltigung dieser Publikation oder von Teilen daraus sind, zu welchem Zweck und in welcher Form auch immer, ohne die ausdrueckliche schriftliche Genehmigung durch SAP AG nicht gestattet. In dieser Publikation enthaltene Informationen koennen ohne vorherige Ankuendigung geaendert werden. Die von SAP AG oder deren Vertriebsfirmen angebotenen Software-Produkte koennen SoftwareKomponenten auch anderer Software-Hersteller enthalten. Microsoft , WINDOWS , NT , EXCEL , Word , PowerPoint und SQL Server sind eingetragene Marken der Microsoft Corporation. IBM , DB , OS , DB , Parallel Sysplex , MVS ESA , RS , AIX , S , AS , OS und OS sind eingetragene Marken der IBM Corporation. ORACLE ist eine eingetragene Marke der ORACLE Corporation. INFORMIX -OnLine for SAP und Informix Dynamic Server Informix Software Incorporated. TM sind eingetragene Marken der UNIX , X Open , OSF und Motif sind eingetragene Marken der Open Group. HTML, DHTML, XML, XHTML sind Marken oder eingetragene Marken des WC , World Wide Web Consortium, Massachusetts Institute of Technology. JAVA ist eine eingetragene Marke der Sun Microsystems, Inc. JAVASCRIPT ist eine eingetragene Marke der Sun Microsystems, Inc., verwendet unter der Lizenz der von Netscape entwickelten und implementierten Technologie. SAP, SAP Logo, R , RIVA, R , ABAP, SAP ArchiveLink, SAP Business Workflow, WebFlow, SAP EarlyWatch, BAPI, SAPPHIRE, Management Cockpit, mySAP.com Logo und mySAP.com sind Marken oder eingetragene Marken der SAP AG in Deutschland und vielen anderen Laendern weltweit. Alle anderen Produkte sind Marken oder eingetragene Marken der jeweiligen Firmen. April SAP AG ABAP Programmierung (BC-ABA) Symbole Symbol Bedeutung Achtung Beispiel Hinweis Empfehlung Syntax April ABAP Programmierung (BC-ABA) SAP AG Inhalt ABAP Programmierung (BC-ABA). ABAP Einfuehrung. uebersicht ueber das R -Basis-System. Das Basis-System im Gesamtsystem. Applikationsserver. Workprozesse. uebersicht ueber die Komponenten von Anwendungsprogrammen. Aufbau von Anwendungsprogrammen. Moegliche Bildschirmbilder. Aufbau von ABAP-Programmen. Verarbeitungsbloecke in ABAP-Programmen. ABAP-Sprachelemente. Logische Datenbanken und Contexte. Speicherstrukturen eines ABAP-Programms. ABAP-Programme anlegen und aendern. Programme im Object Navigator oeffnen. Programme mit dem ABAP-Editor oeffnen. Programme durch Vorwaertsnavigation oeffnen. Programmeigenschaften pflegen. Programme editieren. ABAP Programmiersprache. ABAP-Syntax. Typen und Objekte. Grundlegende Sprachelemente. Datentypen und Datenobjekte. Datentypen. Definition von Datentypen. Eingebaute ABAP-Typen. Programmlokale Datentypen. Datentypen im ABAP Dictionary. Der TYPE-Zusatz. Der LIKE-Zusatz. Datenobjekte. Literale. Textsymbole. Variablen. Konstanten. Schnittstellen-Arbeitsbereiche. Vordefinierte Datenobjekte. Kompatibilitaet. Attribute von Datenobjekten bestimmen. Beispiele zu Datentypen und Objekten. Daten verarbeiten. Wertzuweisungen. April SAP AG ABAP Programmierung (BC-ABA) Werte mit MOVE zuweisen. Werte mit WRITE TO zuweisen. Werte auf Initialwerte setzen. Numerische Operationen. Arithmetische Berechnungen. Mathematische Funktionen. Kaufmaennisches Rechnen. Datums- und Zeitberechnungen. Verarbeitung von Zeichenketten. Feldinhalte verschieben. Feldinhalte ersetzen. Gross- Kleinschreibung oder Zeichen umsetzen. Konvertierung in ein sortierbares Format. Zeichenketten ueberlagern. Zeichenketten suchen. Laenge einer Zeichenkette ermitteln. Feldinhalte verdichten. Zeichenfolgen verketten. Zeichenketten zerlegen. Teile von Zeichenketten zuweisen. Einzelbitverarbeitung in Hexadezimalfeldern. Bits setzen und lesen. Bitoperationen. Mengenoperationen mit Bitfolgen. Typkonvertierungen. Konvertierungsregeln fuer elementare Datentypen. Konvertierungsregeln fuer Referenzen. Konvertierungsregeln fuer Strukturen. Konvertierungsregeln fuer interne Tabellen. Ausrichtung von Datenobjekten. Bearbeitung von Teilfeldern. Feldsymbole und Datenreferenzen. Feldsymbole. Feldsymbole deklarieren. Zuweisung von Datenobjekten an Feldsymbole. Grundformen der AssIGN-Anweisung. Strukturen komponentenweise zuweisen. Casting von Datenobjekten. Datenbereiche fuer Feldsymbole. Datenreferenzen. Referenzvariable. Datenobjekte dynamisch erzeugen. Referenzen auf Datenobjekte beschaffen. Datenreferenzen dereferenzieren. Beispiel zu Datenreferenzen. April ABAP Programmierung (BC-ABA) SAP AG Logische Ausdruecke. Vergleiche zwischen verschiedenen Datentypen. Vergleiche zwischen Zeichenketten. Vergleiche zwischen Bitfolgen. Intervallzugehoerigkeit pruefen. Initialwert pruefen. Selektionskriterien pruefen. Zuweisung zu einem Feldsymbol ueberpruefen. Mehrere logische Ausdruecke verknuepfen. Programmablaufsteuerung. Bedingte Verzweigungen. Schleifen. Bearbeitung grosser Datenmengen. Interne Tabellen. Interne Tabellen anlegen. Interne Tabellentypen. Interne Tabellenobjekte. Besonderheiten bei Standard-Tabellen. Interne Tabellen bearbeiten. Operationen mit der gesamten internen Tabelle. Interne Tabellen zuweisen. Interne Tabellen initialisieren. Interne Tabellen vergleichen. Interne Tabellen sortieren. Interne Tabellen als Schnittstellenparameter. Attribute interner Tabellen bestimmen. Operationen mit einzelnen Zeilen. Operationen fuer alle Tabellenarten. Tabellenzeilen einfuegen. Tabellenzeilen verdichtet einfuegen. Tabellenzeilen lesen. Tabellenzeilen aendern. Tabellenzeilen loeschen. Tabellenzeilen in Schleifen bearbeiten. Operationen fuer Index-Tabellen. Tabellenzeilen anhaengen. Tabellenzeilen ueber den Index einfuegen. Tabellenzeilen ueber den Index lesen. Binaere Suche bei Standard-Tabellen. Tabellenzeilen nach Zeichenketten durchsuchen. Tabellenzeilen ueber den Index aendern. Tabellenzeilen ueber den Index loeschen. Indexangaben bei Schleifen. Zugriff ueber Feldsymbole. Kopfzeilen als Arbeitsbereich. April SAP AG ABAP Programmierung (BC-ABA) Extrakte. Extrakt definieren. Extrakt mit Daten fuellen. Extrakte verarbeiten. Extrakt auslesen. Extrakt sortieren. Gruppenstufenverarbeitung. Anzahlen und Summen ermitteln. Daten aufbereiten. Beispiel fuer aufbereitete Daten. Daten beim Lesen aufbereiten. Daten ueber interne Tabellen aufbereiten. Daten ueber Extrakte aufbereiten. Externe Datenspeicherung. Datenobjekte als Cluster speichern. Daten-Cluster im ABAP-Memory. Datenobjekte im Memory speichern. Datenobjekte aus dem Memory lesen. Daten-Cluster im Memory loeschen. Daten-Cluster in Datenbanken. Cluster-Datenbanken. Struktur von Cluster-Datenbanken. Beispiel einer Cluster-Datenbank. Datenobjekte in Cluster-Datenbanken speichern. Inhaltsverzeichnis eines Daten-Clusters erstellen. Datenobjekte aus Cluster-Datenbanken lesen. Daten-Cluster in Cluster-Datenbanken loeschen. Open SQL-Anweisungen und Cluster-Datenbanken. Arbeiten mit Dateien. Arbeiten mit Dateien auf dem Anwendungsserver. Dateihandhabung in ABAP. oeffnen einer Datei. Grundform der Anweisung OPEN DATASET. oeffnen einer Datei zum Lesen. oeffnen einer Datei zum Schreiben. oeffnen einer Datei fuer das Schreiben an das Ende der Datei. Binaermodus angeben. Textmodus angeben. oeffnen einer Datei an einer bestimmten Position. Betriebssystemkommandos absetzen. Empfangen der Betriebssystemnachricht. Schliessen einer Datei. Loeschen einer Datei. Daten in Dateien schreiben. Daten aus Dateien lesen. April ABAP Programmierung (BC-ABA) SAP AG Automatische Pruefungen bei Dateioperationen. Berechtigungspruefung fuer bestimmte Programme und Dateien. Allgemeine Verprobung bei Dateizugriffen. Arbeiten mit Dateien auf dem Praesentationsserver. Daten mit Benutzerdialog auf den Praesentationsserver schreiben. Daten ohne Benutzerdialog auf den Praesentationsserver schreiben. Daten mit Benutzerdialog vom Praesentationsserver lesen. Daten ohne Benutzerdialog vom Praesentationsserver lesen. Dateien auf dem Praesentationsserver ueberpruefen. Verwendung plattformunabhaengiger Dateinamen. Syntaxgruppen pflegen. Betriebssysteme Syntaxgruppen zuordnen. Logische Pfade anlegen und definieren. Logische Dateinamen anlegen und definieren. Verwendung von logischen Dateien in ABAP-Programmen. Modularisierungstechniken. Quelltext-Module. Makros. Include-Programme. Prozeduren. Unterprogramme. Definition von Unterprogrammen. Globale Daten des Rahmenprogramms. Lokale Daten des Unterprogramms. Die Parameterschnittstelle. Unterprogramme beenden. Aufruf von Unterprogrammen. Benennung des Unterprogramms. Parameteruebergabe an Unterprogramme. Beispiele zu Unterprogrammen. Gemeinsamer Datenbereich. Funktionsbausteine. Funktionsgruppen. Funktionsbausteine aufrufen. Funktionsbausteine anlegen. Organisation von externen Prozeduraufrufen. Spezielle Techniken. Abfangbare Laufzeitfehler. Programmueberpruefungen. Laufzeitfehler abfangen. Berechtigungen ueberpruefen. Berechtigungskonzept. Berechtigungspruefungen. Laufzeitmessung von Programmsegmenten. GET RUN TIME FIELD. Laufzeitmessung von Datenbankzugriffen. April SAP AG ABAP Programmierung (BC-ABA) Programme dynamisch generieren und starten. Ein neues Programm dynamisch anlegen. Bestehende Programme dynamisch aendern. Dynamische angelegte Programme starten. Temporaere Unterprogramme anlegen und starten. ABAP Bildschirmbilder. Dynpros. Bestandteile von Dynpros. Dynproattribute. Bildschirmelemente. Dynprofelder. Die Dynproablauflogik. Verarbeitung von Dynpros. Benutzeraktionen auf Dynpros. Ein- und Ausgabefelder verarbeiten. Drucktasten auf dem Dynpro. Ankreuzfelder und Auswahlknoepfe mit Funktionscodes. GUI-Status verwenden. Funktionscodes auswerten. Cursorposition bestimmen. Aufruf von ABAP-Dialogmodulen. Einfacher Modulaufruf. Steuerung des Datentransports. Unbedingter Modulaufruf. Bedingte Modulaufrufe. Eingabeueberpruefungen. Automatische Eingabeueberpruefungen. Eingabeueberpruefungen in der Ablauflogik. Eingabeueberpruefungen in Dialogmodulen. Feldhilfe, Eingabehilfe und Dropdown-Boxen. Feldhilfe. Eingabehilfe. Eingabehilfen des ABAP Dictionary. Eingabehilfen des Dynpro. Eingabehilfen in Dialogmodulen. Dropdown-Boxen. Bildschirmbilder dynamisch modifizieren. Attribute dynamisch setzen. Die Funktion Feldauswahl. Cursorposition festlegen. Halten von Daten dynamisch ermoeglichen. Komplexe Bildschirmelemente. Statusikonen. Kontextmenues. Subscreens. April ABAP Programmierung (BC-ABA) SAP AG TabStrips. Custom Controls. Table Controls. Table Controls auf dem Bildschirmbild. Table Controls in der Ablauflogik. Table Controls im ABAP-Programm. Table Controls: Beispiel mit Blaettern. Table Controls: Beispiel mit Modifikationen. Anhang: Die Steploop-Technik. Selektionsbilder. Selektionsbilder und logische Datenbanken. Selektionsbilder definieren. Eingabefelder fuer Einzelwerte definieren. Grundform von Parametern. Dynamischer Dictionary-Bezug. Vorschlagswerte fuer Parameter. SPA GPA-Parameter als Vorschlagswerte. Gross- und Kleinschreibung bei Parametern. Sichtbare Laenge verkleinern. Mussfelder definieren. Suchhilfe fuer Parameter. Eingabewerte ueberpruefen. Ankreuzfelder definieren. Auswahlknoepfe definieren. Eingabefelder ausblenden. Eingabefelder modifizieren. Komplexe Selektionen definieren. Selektionstabellen. Grundform von Selektionskriterien. Selektionskriterien und logische Datenbanken. Vorschlagswerte fuer Selektionskriterien. Eingabe auf eine Zeile beschraenken. Eingabe auf Einzelfelder beschraenken. Weitere Zusaetze fuer Selektionskriterien. Selektionsbilder aufbereiten. Leerzeilen, Linien und Kommentare. Mehrere Elemente in einer Zeile. Elementbloecke. Selektionsbilder aufrufen. Standardselektionsbilder aufrufen. Eigenstaendige Selektionsbilder aufrufen. Benutzeraktionen auf Selektionsbildern. Drucktasten auf dem Selektionsbild. Ankreuzfelder und Auswahlknoepfe mit Funktionscodes. Drucktasten in der Drucktastenleiste. April SAP AG ABAP Programmierung (BC-ABA) Standard-GUI-Status aendern. Selektionsbildverarbeitung. Grundform. PBO des Selektionsbilds. Einzelfeldverarbeitung. Blockverarbeitung. Auswahlknoepfe verarbeiten. Mehrfachselektion verarbeiten. Feldhilfe definieren. Eingabehilfe definieren. Subscreens und TabStrips bei Selektionsbildern. Selektionsbilder als Subscreens. TabStrips auf Selektionsbildern. Subscreens auf Selektionsbildern. Selektionskriterien verwenden. Selektionstabellen in der WHERE-Klausel. Selektionstabellen in logischen Ausdruecken. Selektionstabellen in GET-Ereignissen. Listen. Listenerstellung. Einfache Listen mit der WRITE-Anweisung erstellen. Die Anweisung WRITE. WRITE-Ausgabedaten auf der Liste positionieren. Aufbereitungsoptionen. Symbole und Ikonen auf der Liste ausgeben. Linien und Leerzeilen. Feldinhalt als Ankreuzfeld ausgeben. WRITE ueber Anweisungsmuster verwenden. Komplexe Listen erstellen. Die Standardliste. Aufbau der Standardliste. GUI-Status der Standardliste. Listenaufbau selbst definieren. Seitenkopf gestalten. Listenbreite festlegen. Leerzeilen erzeugen. Seitenlaenge festlegen. Seitenfuss gestalten. Listen mit mehreren Seiten. Seitenvorschuebe programmieren. Standardseitenkopf einzelner Seiten. Seitenlaenge einzelner Seiten. Seitenbreite von Listenstufen. In Listen blaettern. Fensterweise blaettern. April ABAP Programmierung (BC-ABA) SAP AG Seitenweise blaettern. Zu den Raendern der Liste blaettern. Spaltenweise blaettern. Blaetterbaren Teil einer Seite festlegen. Listenseiten gestalten. Positionierung der Ausgabe. Absolute Positionsangaben. Relative Positionsangaben. Formatierung der Ausgabe. Die Anweisung FORMAT. Farben in Listen. Felder eingabebereit machen. Felder als Hotspot ausgeben. Besondere Ausgabeformate. Linien auf Listen. Benutzeraktionen auf Listen. Verzweigungslisten. Dialogstatus fuer Listen. Kontextmenues fuer Listen. Listenereignisse im ABAP-Programm. Listen in Dialogfenstern. Datenuebergabe von Listen an das Programm. Automatische Datenuebergabe. Programmgesteuerte Datenuebergabe. Verzweigungslisten beeinflussen. In Verzweigungslisten blaettern. Cursor vom Programm aus setzen. Listenzeilen modifizieren. Listen und Dynpros. Aufruf von Listen aus der Dynproverarbeitung. Aufruf von Dynpros aus der Listenverarbeitung. Listen drucken und ablegen. Drucken einer Liste nach Ihrer Erstellung. Drucken einer Liste waehrend ihrer Erstellung. Druckparameter. Ausfuehren und Drucken. Programmgesteuertes Drucken. Listen von aufgerufenen Programmen drucken. Drucksteuerung. Linken und oberen Rand festlegen. Druckformat festlegen. Ablegen von Listen mit SAP ArchiveLink. Nachrichten. Nachrichten verwalten. Nachrichten senden. Nachrichtenverarbeitung. April SAP AG ABAP Programmierung (BC-ABA) Nachrichten ohne Bildschirmbezug. Nachrichten auf Dynpros. Nachrichten auf Selektionsbildern. Nachrichten auf Listen. Nachrichten in Funktionsbausteinen und Methoden. ABAP Programmausfuehrung. Verarbeitungsbloecke definieren. Ereignisbloecke. Dialogmodule. Direkte Ausfuehrung - Reports. Verknuepfung mit logischen Datenbanken. Reporttransaktionen. Ereignisbloecke in ausfuehrbaren Programmen. Beschreibung der Reporting-Ereignisse. INITIALIZATION. AT SELECTION-SCREEN. START-OF-SELECTION. GET. GET ... LATE. END-OF-SELECTION. Ereignisbloecke verlassen. Ereignisbloecke mit STOP verlassen. Ereignisbloecke mit EXIT verlassen. Ereignisbloecke mit CHECK verlassen. GET-Ereignisbloecke mit REJECT verlassen. Dialoggesteuerte Ausfuehrung - Transaktionen. uebersicht zu Dialogprogrammen. Eine Beispieltransaktion. Transaktionspflege. Dialogtransaktion. Reporttransaktion. Variantentransaktion. Parametertransaktion. Dynprofolgen. Statisches Folgedynpro. Dynamisches Folgedynpro. Dynpros programmgesteuert beenden. Dynprofolgen aufrufen. Modale Dialogfenster einbetten. Beispieltransaktion fuer Dynprofolgen. Programme aufrufen. Ausfuehrbare Programme (Reports) aufrufen. Selektionsbild des aufgerufenen Programms fuellen. Listen des aufgerufenen Programms beeinflussen. Aufgerufenes Programm programmgesteuert verlassen. Transaktionen aufrufen. April ABAP Programmierung (BC-ABA) SAP AG Dynprofolgen als Module aufrufen. Daten zwischen Programmen uebergeben. Einstiegsbilder ueber SPA GPA-Parameter fuellen. ABAP Datenbankzugriffe. Datenbankzugriffe im R -System. Open SQL. Daten lesen. Selektion definieren. Zielbereich angeben. Datenbanktabellen angeben. Zeilen auswaehlen. Zeilen gruppieren. Zeilengruppen auswaehlen. Sortierreihenfolge angeben. Subqueries. Daten ueber Cursor lesen. Moegliche Sperrkonflikte. Daten aendern. Tabellenzeilen einfuegen. Tabellenzeilen aendern. Tabellenzeilen loeschen. Tabellenzeilen einfuegen oder aendern. Datenbankaenderungen festschreiben. Performance-Hinweise. Treffermenge klein halten. uebertragene Datenmenge klein halten. Zahl der Zugriffe klein halten. Suchaufwand klein halten. Datenbanklast klein halten. Native SQL. Native SQL fuer Oracle. Native SQL fuer Informix. Native SQL fuer DB Common Server. Logische Datenbanken. Aufbau logischer Datenbanken. Selektionsviews. Beispiel einer logischen Datenbank. Logische Datenbanken verwenden. Verknuepfung mit ausfuehrbaren Programmen. Aufruf ueber Funktionsbaustein. Logische Datenbanken bearbeiten. Logische Datenbank anlegen. Struktur bearbeiten. Suchhilfen bearbeiten. Selektionen bearbeiten. Datenbankprogramm bearbeiten. Freie Abgrenzungen im Datenbankprogramm. April SAP AG ABAP Programmierung (BC-ABA) Feldselektionen im Datenbankprogramm. Suchhilfen im Datenbankprogramm. Eigenstaendiger Aufruf und Datenbankprogramm. Weitere Komponenten bearbeiten. Performanceverbesserungen. Arbeiten mit Contexten. Was ist ein Context?. Der Context Builder in der Workbench. Contexte anlegen und pflegen. Tabellen als Module. Funktionsbausteine als Module. Contexte als Module. Contexte testen. Contexte puffern. Felder. Module. Schnittstellen. Contexte in ABAP-Programmen verwenden. Contexte suchen und anzeigen. Context-Instanzen anlegen. Context-Instanzen mit Schluesselwerten versorgen. Daten von Context-Instanzen abfragen. Nachrichtenbehandlung in Contexten. Nachrichtenbehandlung in Tabellen-Modulen. Nachrichtenbehandlung in Funktionsbaustein-Modulen. Tips zum Arbeiten mit Contexten. SAP-Transaktionskonzept. Transaktionen und Logical Units of Work. Datenbank-LUW. SAP-LUW. SAP-Transaktionen. Das R -Sperrkonzept. Beispielprogramm fuer SAP-Sperren. Techniken der Verbuchung. Asynchron verbuchen. Asynchron in Abschnitten verbuchen. Synchron verbuchen. Lokal verbuchen. Verbuchungsfunktionsbausteine anlegen. Verbuchungsfunktionsbausteine aufrufen. Verbuchungsfunktionsbausteine direkt aufrufen. Aufrufe in einem Unterprogramm aufnehmen. Spezielle ueberlegungen zu LUWs. Transaktionen, die Verbuchungsfunktionsbausteine aufrufen. Dialogbausteine, die Verbuchungsfunktionsbausteine aufrufen. Fehlerbehandlung bei gebuendelten Aktualisierungen. ABAP Objects. April ABAP Programmierung (BC-ABA) SAP AG Was ist Objektorientierung?. Was bedeutet ABAP Objects?. Von Funktionsgruppen zu Objekten. Beispiel zu Instanzen von Funktionsgruppen. Klassen. uebersichtsgrafik zu Klassen. Einfuehrendes Beispiel zu Klassen. Behandlung von Objekten. uebersichtsgrafik zu Objekten. Einfuehrendes Beispiel zu Objekten. Methoden deklarieren und aufrufen. Beispiel zu Methoden in ABAP Objects. Vererbung. uebersichtsgrafiken zur Vererbung. Einfuehrendes Beispiel zur Vererbung. Interfaces. uebersichtsgrafiken zu Interfaces. Einfuehrendes Beispiel zu Interfaces. Ereignisse ausloesen und behandeln. uebersichtsgrafik zu Ereignissen. Einfuehrendes Beispiel zu Ereignissen. Komplexes Beispiel zu Ereignissen. Class- und Interface-Pools. Anhang. Programme, Bildschirmbilder, Verarbeitungsbloecke. Programmeinleitende Anweisungen. uebersicht ueber ABAP-Aufrufe. Kontext der Aufrufe. Interne Aufrufe. Externe Prozeduraufrufe. Externe Programmaufrufe. Aufrufbare Einheiten. ABAP-Programme. Prozeduren. Dynpros und Dynprofolgen. uebersicht ueber alle ABAP-Anweisungen. ABAP-Systemfelder. ABAP-Glossar. Syntaxkonventionen. April SAP AG ABAP Programmierung (BC-ABA) ABAP Programmierung (BC-ABA) ABAP Programmierung (BC-ABA) Diese Dokumentation beschreibt die Programmierung von Anwendungsprogrammen in der dreistufigen Client-Server-Architektur des R -Systems. Praesentation SAP GUI SAP GUI SAP GUI SAP GUI Applikation ABAP ABAP Datenbank RDBMS R -Anwendungsprogramme werden in der Programmiersprache ABAP erstellt und laufen in der Anwendungsschicht des R -Systems. ABAP-Programme kommunizieren mit dem Datenbank-Management-System der zentralen relationalen Datenbank (RDBMS) und mit der graphischen Benutzerschnittstelle (SAP GUI) der Praesentationsschicht. Inhalt Die Dokumentation ist in fuenf Abschnitte unterteilt: ABAP Einfuehrung Seite Hier werden die Grundlagen der Anwendungsprogrammierung in R dargestellt, die fuer das Verstaendnis der ABAP-Programmierung unerlaesslich sind. Nach einer uebersicht ueber das R -Basis System werden die wesentlichen Merkmale von Anwendungsprogrammen und der Programmiersprache ABAP vorgestellt. Schliesslich wird in einer Kurzeinfuehrung gezeigt, wie Anwendungsprogramme in der ABAP Workbench angelegt werden. ABAP Programmiersprache Seite Hier wird auf die Anweisungen der Programmiersprache ABAP eingegangen. Von elementaren Sprachkonstrukten, wie Datendeklarationen, Datenverarbeitung und Ablaufsteuerung bis Modularisierung und spezielle Techniken wird gezeigt, welche ABAP-Anweisungen fuer welche Zwecke eingesetzt werden. April ABAP Programmierung (BC-ABA) SAP AG ABAP Programmierung (BC-ABA) ABAP Bildschirmbilder Seite Hier werden die verschiedenen Bildschirmbilder dargestellt, die zu ABAP-Programmen gehoeren koennen. Es wird gezeigt, wie die Interaktion zwischen ABAP-Programmen und Benutzer in Form von Bildschirmbildern programmiert und gesteuert wird. ABAP Programmausfuehrung Seite Hier wird auf die Ausfuehrung von ABAP-Programmen im R -System eingegangen. Der Abschnitt zeigt, wie ABAP-Programme im R -System gestartet werden koennen, welche Voraussetzungen dafuer gegeben sein muessen, und welche verschiedenen Arten von Programmausfuehrungen es gibt. ABAP Datenbankzugriffe Seite Hier wird gezeigt, wie ABAP mit der zentralen Datenbank des R -Systems arbeitet. Es wird auf die Teile der Programmiersprache eingegangen, die in der Datenbank in SQLBefehle umgesetzt werden, und es wird gezeigt, wie aenderungen auf der Datenbank programmiert werden. ABAP Objects Seite Hier wird ABAP Objects, die objektorientierte Erweiterung von ABAP eingefuehrt. Es werden Objekte, Klassen und Interfaces als die grundlegenden Elemente von ABAP Objects eingefuehrt. Es wird gezeigt, wie Klassen selbstaendig, mit Hilfe von Interfaces oder ueber Vererbung definiert werden. Es wird die Behandlung von Methoden und Ereignisse als Komponenten von Klassen gezeigt. Anhang Seite Der Anhang enthaelt zusammenfassende Beschreibungen und uebersichten, wie z.B. eine ABAP-Befehlsreferenz und ein ABAP-Glossar. Beispielprogramme Bitte beachten Sie, dass die Beispielprogramme dieser Dokumentation in jedem R -System ab Release. in der Transaktion ABAPDOCU zum Testen zur Verfuegung stehen. Die Gliederung der Programme entspricht dabei der Struktur dieser Dokumentation. Weiterfuehrende Dokumentation SAP Style Guide Extern aenderungen des SAP-Standards Extern ABAP Workbench: Werkzeuge Extern ABAP Dictionary Extern April SAP AG ABAP Programmierung (BC-ABA) ABAP Programmierung (BC-ABA) Remote Communications Extern RFC-Programmierung in ABAP Extern ABAP als OLE-Automation-Controller Extern Basis-Programmierschnittstellen Extern ABAP Query Extern April ABAP Programmierung (BC-ABA) SAP AG ABAP Einfuehrung ABAP Einfuehrung ... aber bevor es so richtig losgeht, sollten Sie zuerst die folgenden Abschnitte lesen: uebersicht ueber das R -Basis-System Seite uebersicht ueber die Komponenten von Anwendungsprogrammen Seite ABAP-Programme anlegen und aendern Seite April SAP AG ABAP Programmierung (BC-ABA) uebersicht ueber das R -Basis-System uebersicht ueber das R -Basis-System Einen wesentlichen Bestandteil des gesamten R -Systems mit seinen Anwendungen Finanzwirtschaft, Logistik, Personalwirtschaft bildet das R -Basis-System, die Plattform fuer alle R -Anwendungen. In den folgenden Abschnitten zeigen wir Ihnen, was das R -Basis-System ist und wie es in das Gesamtsystem eingegliedert ist. Zuerst stellen wir Ihnen das gesamte Basis-System vor. Anschliessend wenden wir uns ausfuehrlicher einer zentralen Komponente zu, dem Applikationsserver. Schliesslich stellen wir Ihnen Workprozesse als Komponenten der Applikationsserver vor. Das Basis-System im Gesamtsystem Seite Applikationsserver Seite Workprozesse Seite April ABAP Programmierung (BC-ABA) SAP AG Das Basis-System im Gesamtsystem Das Basis-System im Gesamtsystem In den folgenden Abschnitten zeigen wir Ihnen drei verschiedene Sichten auf das R -System. Anhand dieser Sichten zeigen wir, welche Rolle das R -Basis-System im Gesamtsystem spielt. Logische Sicht Die folgende Abbildung zeigt die logische Sicht auf das R -System in Form eines Blockdiagramms. . R Benutzer R Benutzer Praesentationskomponenten Praesentationskomponenten ABAP ABAP Workbench Workbench R Basis System R Anwendung . R Anwendung n Kernel Kernel&&Basis BasisDienste Dienste Datenbank Management System Datenbank Die logische Sicht auf das R -System hebt sich von einer hardware- oder softwaretechnischen Sicht dahingehend ab, dass die gezeigten Komponenten nicht unbedingt Hardware- oder Software-Einheiten zugeordnet werden koennen. Die Abbildung zeigt, wie sich das R -Basissystem als zentrale Plattform in das gesamte R -System einfuegt. Die folgende Aufzaehlung fasst die Aufgaben der drei im R -Basis-System enthaltenen logischen Komponenten kurz zusammen: Kernel & Basisdienste Die Komponente Kernel & Basisdienste dient als hardware-, betriebssystem- und datenbankunabhaengige Laufzeitumgebung aller R -Anwendungen. Diese Laufzeitumgebung ist hauptsaechlich in C C++ geschrieben. Einige systemnahe Teile sind aber auch in der SAPeigenen Programmiersprache programmiert. Im einzelnen erfuellt die Komponente Kernel & Basisdienste dabei folgende Aufgaben: April SAP AG ABAP Programmierung (BC-ABA) Das Basis-System im Gesamtsystem Ausfuehren von Anwendungen Alle R -Anwendungen laufen auf Softwareprozessoren (Virtual Machines) dieser Komponente. Verwaltung von Benutzern und Prozessen An einem R -System koennen viele Benutzer gleichzeitig arbeiten und jeder Benutzer kann mehrere Anwendungen unabhaengig voneinander ausfuehren. Die Komponente uebernimmt dabei die sonst ueblichen Aufgaben eines Betriebssystems. Benutzer melden sich am R -System an und fuehren dort Anwendungen aus. Sie kommen mit dem eigentlichen Betriebssystem des jeweiligen Rechners nicht in Beruehrung. Fuer das Betriebssystem des Rechners ist das R -System der einzige Benutzer. Datenbankzugriffe Jedes R -System ist mit einem Datenbanksystem, bestehend aus Datenbank Management System (DBMS) und der eigentlichen Datenbank (Datenbestand) verknuepft. Die Anwendungen greifen nicht direkt, sondern nur ueber Basisdienste auf das Datenbanksystem zu. Kommunikation R -Anwendungen koennen sowohl mit anderen R -Systemen als auch mit Nicht-R Systemen kommunizieren. Ebenso ist der Zugriff von ausserhalb auf die betriebswirtschaftliche Funktionalitaet von R -Anwendungen moeglich (BAPISchnittstelle). Die Komponente stellt alle hierfuer noetigen Dienste zur Verfuegung. Kontrolle und Administration des R -Systems Die Komponente umfasst Programme, die es erlauben den laufenden Betrieb eines R Systems zu ueberwachen, zu steuern und Laufzeitparameter zu veraendern. ABAP Workbench Die Komponente ABAP Workbench ist eine vollstaendige Entwicklungsumgebung fuer in ABAP geschriebenen Anwendungen. Sie dient der Erstellung oder Erweiterung, dem Test und der Organisation von Anwendungsprogrammen. Die Entwicklungsumgebung ist vollstaendig in das R -Basis-System integriert und ist wie andere R -Anwendungen selbst in ABAP geschrieben. Praesentationskomponenten Die Praesentationskomponenten dienen der Interaktion des R -Systems mit dem Benutzer (Einund Ausgabe) und der Integration von Desktop-Anwendungen (z.B.Textverarbeitung, Tabellenkalkulation etc.) in das R -System. Softwaretechnische Sicht Die folgende Abbildung zeigt die softwaretechnische Sicht auf das R -System. Die softwaretechnische Sicht beschreibt aus welchen Softwarekomponenten das R -System zusammengesetzt ist. In der softwaretechnischen Sicht umfassen alle SAP GUI Komponenten und Applikationsserver eines R -Systems das R -Basis-System. April ABAP Programmierung (BC-ABA) SAP AG Das Basis-System im Gesamtsystem . SAP GUI . . SAP GUI Applikationsserver SAP GUI. SAP GUI . Applikationsserver n Messageserver Datenbank Management System Praesentationsschicht Applikationsschicht Datenbankschicht Datenbank Das R -Basis-System ist ein mehrstufiges Client Server-System. Die einzelnen Softwarekomponenten sind auf einzelne Softwareschichten verteilt und arbeiten je nach Schicht als Client oder Server fuer die Komponenten der darunter bzw. darueberliegenden Schichten. In der Grundvariante umfasst das R -System Softwareschichten: Datenbankschicht Ein zentrales Datenbanksystem, das alle Daten des R -Systems verwaltet, bildet die Datenbankschicht. Das zentrale Datenbanksystem besteht aus den Komponenten Datenbank Management System (DBMS) und der eigentlichen Datenbank (Datenbestand). SAP stellt selbst kein eigenes Datenbanksystem zur Verfuegung. Das R -System unterstuetzt stattdessen folgende Datenbanksysteme anderer Hersteller: ADABAS D, DB (auf AS ), DB Common Server, DB MVS,INFORMIX, Microsoft SQL Server, ORACLE und ORACLE Parallel Server. Die Datenbank enthaelt nicht nur die betriebswirtschaftlichen Daten (Stammdaten und Bewegungsdaten) der Anwendungsprogramme, sondern ist die zentrale Datenablage fuer das gesamte R -System. Insbesondere enthaelt die Datenbank also auch Steuerungs- und Customizingdaten, die das Verhalten des R -Systems festlegen, sowie die Anwendungsprogramme selbst. Anwendungsprogramme bestehen aus Programmtexten, Bildschirmdefinitionen, Menues, Funktionsbausteinen usw. Diese Komponenten werden in einem speziellen Teil der Datenbank abgespeichert, der R -Repository genannt wird, und heissen deshalb auch Repository-Objekte. Repository-Objekte werden mit der ABAP Workbench bearbeitet. Applikationsschicht DieSoftware-Komponenten der Applikationsschicht bestehen aus einem oder mehreren Applikationsservern und ein Message Server. Jeder Applikationsserver stellt eine Reihe von April SAP AG ABAP Programmierung (BC-ABA) Das Basis-System im Gesamtsystem Diensten zum Betrieb des R -Systems zur Verfuegung. Im Prinzip genuegt ein einziger Applikationsserver, um ein R -System zu betreiben. In der Praxis werden die Dienste meistens auf mehrere Applikationsserver verteilt, so dass nicht jeder Applikationsserver jeden Dienst zur Verfuegung stellt. Der Message Server realisiert die Kommunikation zwischen den Applikationsservern. ueber den Message Server koennen Auftraege zwischen den Applikationsservern innerhalb eines R -Systems weitergeleitetet werden. Weiterhin enthaelt der Message Server Informationen ueber die Gruppierung von Applikationsservern und die aktuelle Lastverteilung innerhalb der Gruppen und kann so die Anmeldung von Benutzern entsprechend beeinflussen. Praesentationsschicht Die Praesentationsschicht enthaelt Software-Komponenten die R -spezifisch SAP GUI (Graphical User Interface) genannt werden. Die Praesentationsschicht bildet die Schnittstelle zu den Benutzern. Durch ihre SAP GUI-Komponenten bietet sie eine intuitiv bedienbare graphische Oberflaeche ueber die Benutzer Daten eingeben oder Antworten in Form von Texten oder Graphiken erhalten. Die Praesentationsschicht sendet diese Daten an die Applikationsschicht bzw. empfaengt sie von dieser. Eine SAP GUI Komponente ist waehrend ihrer Laufzeit immer fest mit einer Benutzeranmeldung an das R -System verknuepft. In weiteren Ausbaustufen koennen weitere Schichten, wie z.B. ein Internet Transaction Server (ITS), hinzukommen. Softwaretechnische Sicht und Hardwaresicht Die softwaretechnische Sicht hat zunaechst einmal nichts mit der Verteilung auf die Hardware zu tun. Sowohl in vertikaler Richtung (Schichten) als auch in horizontaler Richtung (Komponenten) sind viele verschiedene Szenarien moeglich. In vertikaler Richtung gibt es die moeglichen Extreme, dass alle Schichten auf einem einzigen Rechner installiert sind oder jede Schicht mindestens einen eigenen Rechner beansprucht. In horizontaler Richtung ist die Verteilung der Datenbankkomponenten vom jeweiligen Datenbankssystem abhaengig. Die Komponenten von Applikationsschicht und Praesentationsschicht sind ueber beliebig viele Rechner verteilbar, wobei auch mehrere Applikationsserver auf einem Rechner installiert sein koennen. Bei einer haeufig vorzufindende Konfiguration laufen das Datenbanksystem und ein Applikationsserver, der spezielle Dienste fuer die Datenbank zur Verfuegung stellt, auf einem Rechner gemeinsam, waehrend alle weiteren Applikationsserver auf eigene Rechner verteilt sind. Die Komponenten der Praesentationsschicht laufen meistens auf den Desktoprechnern jedes einzelnen Benutzers. Vorteile der mehrstufigen Architektur Die softwaretechnische Aufteilung des R -Systems auf drei Schichten sorgt durch die Verteilung der Systemlast auf die verschiedenen Schichten fuer kurze Antwortzeiten. Da das Datenbanksystem die zentrale Datenablage fuer das gesamte R -System enthaelt, wird es beim Betrieb des System stark belastet. Deshalb ist es sinnvoll, die Ausfuehrung von Anwendungsprogrammen nicht auf dem Rechner stattfinden zu lassen, auf dem auch das Datenbanksystem installiert ist. Die Architektur des R -Systems ermoeglicht es, durch die Trennung von Applikationsschicht und Datenbankschicht diese auf verschiedenenen Rechnern zu installieren, die ueber ein Netzwerk kommunizieren. Es ist sinnvoll die Verarbeitung von Benutzereingaben und die Aufbereitung der Datenausgabe von der eigentlichen Programmausfuehrung zu entkoppeln. Dies liefert die Architektur des R Systems durch die Trennung von Praesentations- und Applikationsschicht, die zur Entlastung der Applikationsserver fuehrt. SAP GUI und Applikationsserver sind so aufgebaut, dass moeglichst wenig Daten zwischen den beiden Schichten hin und her bewegt werden muessen, so dass die Komponenten der Praesentationsschicht auch auf Rechnern bedient werden koennen, die weit April ABAP Programmierung (BC-ABA) SAP AG Das Basis-System im Gesamtsystem entfernt von den Rechnern stehen, auf denen die Applikationsschicht installiert ist, und die ueber langsame Leitungen miteinander verbunden sind. Dadurch, dass die Softwarekomponenten eines R -Systems beinahe beliebig auf verschiedene Hardware-Einheiten verteilt werden koennen, wird eine hohe Skalierbarkeit erreicht. Insbesondere in der Applikationsschicht kann ein R -System leicht durch die Installation weiterer Applikationsserver an steigende Anforderungen angepasst werden. Konsequenzen fuer die Anwendungsprogrammierung Die Trennung von Anwendungs- und Praesentationsschicht hat eine wichtige Konsequenz fuer die Programmierung von Anwendungsprogrammen. Bei der Ausfuehrung eines Anwendungsprogramms, das mehrere Benutzeraktionen am Bildschirm erfordert, wechselt die Kontrolle ueber das Anwendungsprogramm staendig zwischen den Schichten. Waehrend ein Bildschirm eingabebereit ist, ist der entsprechende SAP GUI der Praesentationsschicht aktiv. Die Applikationsschicht ist in dieser Zeit nicht fuer das Anwendungsprogramm aktiv. Die Applikationsserver sind dadurch fuer andere Aufgaben frei. Nach einer Benutzereingabe am Bildschirm ist die Applikationsschicht wieder fuer das Anwendungsprogramm aktiv. In dieser Zeit ist die Praesentationsschicht inaktiv. Der SAP GUI ist zwar fuer den Benutzer aktiv und zeigt das Bildschirmbild noch an, ist in dieser Zeit aber nicht eingabebereit. Erst wenn das Anwendungsprogramm einen weiteren Bildschirm vorbereitet und an den SAP GUI geschickt hat, wird dieser wieder aktiv, wechselt die Bildschirmanzeige und wartet auf Eingaben. Als Konsequenz dieser Technik wird die Programmlogik eines Anwendungsprogramms zwischen zwei aufeinanderfolgenden Bildschirmbildern zu einem Dialogschritt zusammengefasst. Bild Bild Bild Bild Bild Bild Praesentationsschicht: SAP GUI nicht aktiv SAP GUI nicht aktiv SAP GUI Interaktion des Benutzers nicht aktiv Dialogschritt nicht aktiv Dialogschritt nicht aktiv Bearbeitung der Dialogschritte durch das System Applikationsschicht: April SAP AG ABAP Programmierung (BC-ABA) Das Basis-System im Gesamtsystem Benutzersicht Die folgende Abbildung zeigt die Benutzersicht auf das R -System: R Benutzer SAP SAPGUI GUI SAP GUI SAP SAP GUI Modus Modus Modus . Modus GUI SAP SAPGUI GUI SAP GUI SAP SAP GUI Modus Modus Modus . Modus GUI SAP SAPGUI GUI SAP GUI SAP SAP GUI Modus Modus Modus . Modus GUI . Applikationsschicht Applikationsschicht Datenbankschicht Datenbankschicht R System R System Fuer einen Benutzer sind die Komponenten des R -System unmittelbar sichtbar, die sich ihm als Fenster auf dem Bildschirm praesentieren. Diese Fenster werden von der Praesentationsschicht des R -Systems erstellt und sind auch Bestandteile des R -Basis-Systems. Vor der Anmeldung eines Benutzers an das R -System startet er zuerst ein Hilfsprogramm namens SAP Logon, das auf dem jeweiligen Frontend installiert ist. Im SAP Logon kann er eines der zur Verfuegung stehenden R -Systeme auswaehlen. Das Programm SAP Logon verbindet sich mit dem Message Server des ausgewaehlten R -Systems und erhaelt von diesem die Adresse eines geeigneten (wenig ausgelasteten) Applikationsservers. Schliesslich startet SAP Logon einen SAP GUI, der mit diesem Applikationsserver verbunden ist. Das Programm SAP Logon wird fuer diese Verbindung nicht mehr benoetigt. Der SAP GUI oeffnet erst das Anmeldebild und nach erfolgreicher Anmeldung das R Einstiegsbild in einem R -Fenster auf dem Bildschirm. Innerhalb des SAP GUI wird das R Fenster durch einen Modus repraesentiert. Der Benutzer kann nach seiner Anmeldung innerhalb eines SAP GUI bis zu fuenf weitere Modi, also R -Fenster, oeffnen, die sich untereinander fast wie unabhaengige R -Anmeldungen verhalten. In den verschiedenen Modi koennen also parallele Anwendungen unabhaengig voneinander ausgefuehrt werden. Innerhalb eines Modus, kann der Benutzer Anwendungen ausfuehren, die selbst weitere Fenster (z.B. Dialogfenster, Graphikfenster usw.) oeffnen. Diese Fenster sind dann nicht unabhaengig, sondern gehoeren zu diesem Modus. Sie koennen modal (das urspruengliche Fenster ist nicht eingabebereit) oder amodal (beide Fenster sind eingabebereit und wechselwirken miteinander) sein. Der Benutzer kann mit dem Programm SAP Logon weitere SAP GUIs fuer das gleiche oder auch andere zur Verfuegung stehende R -Systeme oeffnen. Die einzelnen SAP GUIs und die entsprechenden R -Anmeldungen eines Benutzers sind vollstaendig unabhaengig voneinander. Somit koennen zum Beispiel auf einem einzigen Desktoprechner die Praesentationsschichten mehrerer R -System durch SAP GUIs vertreten sein. April ABAP Programmierung (BC-ABA) SAP AG Applikationsserver Applikationsserver R -Programme laufen auf Applikationsservern ab. Applikationsserver sind also wichtige Softwarekomponenten des R -Systems. In den folgenden Abschnitten beschreiben wir die Applikationsserver genauer. Aufbau eines Applikationsservers Alle Applikationsserver eines R -Systems unter Einbeziehung des Message Servers bilden die Applikationsschicht der mehrstufigen Architektur des R -Systems. Die Anwendungsprogramme eines R -Systems werden auf den Applikationsservern ausgefuehrt. Die Applikationsserver kommunizieren dabei mit den Praesentationskomponenten, mit der Datenbank und ueber den Message Server auch untereinander. Das folgende Bild zeigt den Aufbau eines Applikationsservers: SAP GUI Applikationsserver . SAP GUI Dispatcher Dispatcher WorkWorkprozess prozess Gateway Gateway Kontext WorkWorkprozess prozess Kontext Shared Shared Memory Memory Benutzer n . WorkWorkprozess prozess Kontext Benutzer Datenbank Management System Datenbank Die einzelnen Komponenten sind: Workprozesse Applikationsserver enthalten Workprozesse, deren Anzahl und Typ beim Start des R -Systems festgelegt wird. Workprozesse sind Komponenten, die in der Lage sind, eine Anwendung (bzw. jeweils einen Dialogschritt) auszufuehren. Jeder Workprozess hat Verbindung zu einem Speicherbereich in dem sich der Kontext der gerade ausgefuehrten Anwendung befindet. Der Kontext beinhaltet die aktuellen Daten des laufenden Programms und muss fuer jeden Dialogschritt April SAP AG ABAP Programmierung (BC-ABA) Applikationsserver dieses Programms verfuegbar sein. Weiter unten erfahren Sie mehr ueber die unterschiedlichen Typen von Workprozessen. Dispatcher Jeder Applikationserver enthaelt einen Dispatcher. Der Dispatcher ist das Bindeglied zwischen den Workprozessen und den an dem Applikationsserver angemeldeten Benutzern (bzw. deren SAP GUIs). Seine Aufgabe besteht darin, jedesmal, wenn eine Benutzerinteraktion dazu fuehrt, dass ein Dialogschritt ausgefuehrt werden soll, diesen Auftrag vom SAP GUI entgegenzunehmen und ihn an einen freien Workprozess weiterzuleiten. Auf dem gleichen Wege gelangen die Bildschirmausgaben, die aus der Ausfuehrung des Dialogschritts resultieren, wieder zum Benutzer zurueck. Gateway Jeder Applikationserver enthaelt ein Gateway. Das Gateway ist die Vermittlungsinstanz fuer die Kommunikationsprotokolle des R -Systems (RFC, CPI C) und kann mit anderen Applikationsservern des gleichen R -Systems, mit anderen R -Systemen, mit R -Systemen oder mit externen (nicht-SAP) Anwendungen kommunizieren. Der hier beschriebene Aufbau der Applikationsserver unterstuetzt die Performance und Skalierbarkeit des gesamten R -Systems. Die feste Anzahl von Workprozessen und das Dispatching von Dialogschritten auf die Workprozesse sorgen fuer eine gute Ausnutzung des Hauptspeichers im verwendeten Rechner, da manche Komponenten und Speicherbereiche eines Workprozesses unabhaengig von den Anwendungen sind und wiederverwendet werden. Da die einzelnen Workprozesse unabhaengig voneinander arbeiten, bieten sie eine optimale Vorraussetzung fuer Mehrprozessor-Architekturen. Auf die Arbeitsweise des Dispatchers und die Verteilung von anfallenden Aufgaben auf Workprozessen gehen wir im Abschnitt Dispatching von Dialogschritten noch naeher ein. Shared Memory Alle Workprozesse eines Applikationsservers verwenden einen gemeinsamen Hauptspeicher, das Shared Memory, um Kontexte zu speichern oder um selten geaenderte Daten lokal zu puffern. Im Shared Memory stehen die von allen Workprozessen genutzten Ressourcen (wie Programme oder Tabelleninhalte) zur Verfuegung. Die Speicherverwaltung des R -Systems sorgt dafuer, dass die Workprozesse immer den aktuellen Kontext, d.h. die Datenmengen, die den aktuellen Bearbeitungszustand eines laufenden Programms enthalten, adressieren. ueber ein MappingVerfahren wird zu diesem Zweck der fuer die Ausfuehrung eines Dialogschritts erforderliche Kontext aus dem gemeinsamen Hauptspeicher in den Adressraum des bearbeitenden Workprozessses projeziert. Dadurch sind die tatsaechlichen Kopiervorgaenge auf ein Minimum reduziert. Die lokale Pufferung von Daten im Shared Memory des Applikationsservers entlastet die Datenbank, da mehrfaches Lesen vermieden wird. Dadurch verkuerzen sich die Zugriffszeiten fuer die Anwendungsprogramme erheblich. Durch die Konzentration einzelner Anwendungen (Finanzwirtschaft, Logistik, Personalwirtschaft) auf getrennte Applikationsservergruppen kann eine optimale Ausnutzung der Puffer erreicht werden. Datenbankanbindung Waehrend des Starts eines R -Systems meldet jeder Applikationsserver seine Workprozesse an die Datenbankschicht an und erhaelt dadurch fuer jeden Workprozess genau einen fest definierten Kanal. Jeder Workprozess ist fuer die gesamte Laufzeit des R -Systems ein Benutzer (Client) des Datenbanksystems (Server). Waehrend der Laufzeit des Systems erfolgen keine April ABAP Programmierung (BC-ABA) SAP AG Applikationsserver Ummeldungen und ein Datenbank-Kanal kann nicht von einem Workprozess zum anderen weitergereicht werden. Aus diesem Grund kann ein Workprozess Datenbankaenderungen immer nur im Rahmen genau einer Datenbank-LUW (Logical Unit of Work) ausfuehren. Eine DatenbankLUW ist eine nicht teilbare Folge von Datenbankoperationen. Dies hat wichtige Konsequenzen fuer das Programmiermodell, auf die wir unten noch naeher eingehen. Dispatching von Dialogschritten Die Anzahl der Benutzer, die sich an einem Applikationsserver anmelden, ist haeufig um ein Vielfaches groesser als die Anzahl der zur Verfuegung stehenden Workprozesse und nicht durch die Architektur des R -System begrenzt. Jeder Benutzer kann wiederum mehrere parallele Anwendungen ausfuehren. Der Dispatcher hat dabei die wichtige Aufgabe alle anfallenden Dialgschritte auf die Workprozesse des Applikationsservers zu verteilen. Wie der zeitliche Ablauf des Dispatching aussehen kann, zeigen wir Ihnen am folgenden Beispiel: Benutzer Benutzer WorkWorkprozess prozess Kontext Shared Shared Memory Memory Dispatcher WorkWorkprozess prozess Kontext Applikationsserver SAP SAPGUI GUI WorkWorkprozess prozess Kontext SAP SAPGUI GUI . Der Dispatcher empfaengt von Benutzer die Anforderung zur Ausfuehrung eines Dialogsschritts und leitet diese an den gerade freien Workprozess weiter. Der Workprozess adressiert den Kontext des entsprechenden Anwendungsprogramms im Shared Memory und fuehrt den Dialogschritt aus. Danach ist der Workprozess wieder frei. . Der Dispatcher empfaengt von Benutzer die Anforderung zur Ausfuehrung eines anderen Dialogschritts und leitet diese an den wieder freien Workprozess weiter. Der Workprozess bearbeitet den Dialogschritt analog zu Schritt. . Waehrend Workprozess noch mit Schritt beschaeftigt ist, empfaengt der Dispatcher von Benutzer die Anforderung zur Ausfuehrung eines weiteren Dialogschritts und leitet diese an den gerade freien Workprozess weiter. . Nachdem Workprozess und ihre Verarbeitung beendet haben, empfaengt der Dispatcher wieder von Benutzer eine Anforderung und leitet diese an den wieder freien Workprozess weiter. April SAP AG ABAP Programmierung (BC-ABA) Applikationsserver . Waehrend Workprozess noch mit Schritt beschaeftigt ist, empfaengt der Dispatcher von Benutzer eine Anforderung zur Ausfuehrung und leitet diese an den wieder freien Workprozess weiter. Dem Beispiel entnehmen wir, dass ein Dialogschritt eines Programms waehrend seiner Ausfuehrung genau einem Workprozess zugeordnet ist. die einzelnen Dialogschritte eines Programms waehrend dessen Laufzeit auf verschiedenen Workprozessen ausgefuehrt werden koennen, und der Kontext des Programms fuer jeden neuen Workprozess neu adressiert werden muss. ein Workprozess aufeinanderfolgend die Dialogschritte verschiedener Programme und verschiedener Benutzer ausfuehrt. Aus dem Beispiel geht nicht hervor, dass der Dispatcher die Auftraege so auf die Workprozesse zu verteilen versucht, dass moeglichst oft der gleiche Workprozess fuer aufeinanderfolgende Dialogschritte einer Anwendung verwendet wird. Dadurch kann die Neuadressierung des Programmkontexts im Shared Memory eingespart werden. Dispatching und Programmiermodell Nachdem die die Trennung von Anwendungs- und Praesentationsschicht die Aufteilung von Anwendungsprogrammen in Dialogschritte erforderlich machte, fuehrt das im vorhergehenden Abschnitt vorgestellte Dispatching der Dialogschritte auf einzelne Workprozesse zu weiteren wichtigen Konsequenzen fuer das Programmiermodell. Wie schon oben erwaehnt, kann ein Workprozess Datenbankaenderungen immer nur im Rahmen genau einer Datenbank-LUW (Logical Unit of Work) ausfuehren. Eine Datenbank-LUW ist eine nicht teilbare Folge von Datenbankoperationen an deren Anfang und Ende ein konsistenter Datenbestand auf der Datenbank stehen muss. Anfang und Ende einer Datenbank-LUW werden durch einen Commit-Befehl an das Datenbanksystem definiert (Datenbank-Commit). Waehrend einer Datenbank-LUW, also zwischen zwei Datenbank-Commits, sorgt das Datenbanksystem selbst fuer die Konsistenz (Widerspruchsfreiheit) des Datenbestands. Das heisst, es uebernimmt selbstaendig Aufgaben wie Datenbankeintraege waehrend ihrer Bearbeitung zu sperren oder den alten Zustand nach einem fehlerhaften Abbruch wiederherzustellen (Rollback). Typische SAP-Anwendungsprogramme erstrecken sich ueber einige Bildschirmbilder und die zugehoerigen Dialogschritte. Der Benutzer fordert auf den einzelnen Bildschirmen Datenbankaenderungen an, die nach Ablauf einer Bildschirmfolge zu einem konsistenten Datenbestand auf der Datenbank fuehren sollen. Die einzelnen Dialogschritte laufen auf unterschiedlichen Workprozessen und ein einzelner Workprozess bearbeitet nacheinander Dialogschritte unabhaengiger Anwendungen. Es ist klar, dass voneinander unabhaengige Anwendungen, deren Dialogschritte nacheinander auf einem Workprozess ausgefuehrt werden, nicht mit der gleichen Datenbank-LUW arbeiten duerfen. Daraus folgt, dass ein Workprozess fuer jeden Dialogschritt eine eigene Datenbank-LUW oeffnen muss. Der Workprozess sendet also am Ende jedes Dialogschritts, waehrend dem Datenbankaenderungen ausgefuehrt werden, einen Commit-Befehl (Datenbank-Commit) an die Datenbank. Diese Commit-Befehle sind nicht explizit in der Anwendung programmiert und wir nennen sie deshalb implizite Datenbank-Commits. Durch diesen impliziten Datenbank-Commit wird die Zeit, in der ein Benutzer eine DatenbankLUW aufrechterhalten kann auf maximal einen Dialogschritt beschraenkt. Dies bedeuted eine erhebliche Entlastung der Datenbank, verringert die Haeufigkeit von Serialisierungen und Deadlocks und ermoeglicht daher eine sehr grosse Zahl von Benutzern an einem System. April ABAP Programmierung (BC-ABA) SAP AG Applikationsserver Bild Bild Bild Bild Bild Bild SAP GUI SAP GUI SAP GUI Dialogschritt Praesentationsschicht Dialogschritt Applikationsschicht Datenbank LUW Datenbankschicht Es stellt sich jetzt die Frage, wie sich die Verknuepfung jedes einzelnen Dialogschritts mit einer Datenbank-LUW mit der Anforderung in Einklang bringen laesst, dass das Festschreiben (Commit) oder Zuruecknehmen von Datenbankaenderungen (Rollback) vom logischen Ablauf der Anwendungsprogramme abhaengen sollte und nicht von der technischen Verteilung auf Dialogschritte. Wenn Aktualisierungsanforderungen voneinander abhaengen, bilden sie logische Einheiten im Programmverlauf, die sich ueber mehrere Dialogschritte erstrecken koennen. Die Datenbankaenderungen solcher logischer Einheiten muessen zusammen ausgefuehrt und entsprechend auch zusammen zurueckgesetzt werden. Das SAP-Programmiermodell bietet fuer diese Anforderung eine Reihe von Buendelungstechniken an, die es ermoeglichen, dass Datenbankaktualisierungen in solchen logischen Einheiten ablaufen koennen. Die Teile von R -Anwendungsprogramms, die eine logisch zusammengehoerende Menge von Datenbank-Operationen buendeln, bezeichnen wir als SAP-LUW. Im Gegensatz zur Datenbank-LUW umfasst eine SAP-LUW die Gesamtheit der Dialogschritte einer logischen Einheit inklusive der Fortschreibung auf der Datenbank (Verbuchung). April SAP AG ABAP Programmierung (BC-ABA) Workprozesse Workprozesse Workprozesse fuehren die einzelnen Dialogschritte der R -Anwendungen aus. In den naechsten beiden Abschnitten zeigen wir einerseits den Aufbau eines Workprozesses und gehen andererseits auf die verschiedenen Typen von Workprozessen im R -System ein. Aufbau eines Workprozesses Workprozesse fuehren als Komponenten von Applikationsservern die Dialogschritte von Anwendungsprogrammen aus. Das folgende Bild zeigt Ihnen, welche Komponenten jeder Workprozess enthaelt, damit er R -Anwendungsprogramme ausfuehren kann: Workprozess Dynpro-Prozessor Dynpro-Prozessor ABAP-Prozessor ABAP-Prozessor Kontext Kontext Datenbankschnittstelle Datenbankschnittstelle Datenbank Management System Datenbank Ein Workprozess enthaelt zwei Softwareprozessoren und eine Datenbankschnittstelle: Dynpro-Prozessor In R -Anwendungsprogrammen unterscheiden wir zwischen Benutzerinteraktionen und Verarbeitungslogik. Programmtechnisch wird die Benutzerinteraktion durch Dynpros (dynamische Programme) realisiert. Ein Dynpro besteht aus einer Bildschirmmaske und der zugehoerigen Dynproablauflogik. Die Dynproablauflogik kontrolliert einen Grossteil der Benutzerinteraktionen. Das R -Basis-System enthaelt fuer die Erstellung von Dynpros eine eigene Sprache mit Sprachelementen fuer die Programmierung der Dynproablauflogik. Der DynproProzessor fuehrt die Dynproablauflogik des Anwendungsprogramms aus. Er uebernimmt dabei die Kommunikation zwischen Workprozess und SAP GUI (ueber den Dispatcher), ruft Module der Verarbeitungslogik auf und sorgt fuer die Weitergabe von Feldinhalten an die Verarbeitungslogik. ABAP-Prozessor Die eigentliche Verarbeitungslogik von Anwendungsprogrammen ist in der SAP-eigenen Programmiersprache ABAP geschrieben. Der ABAP-Prozessor fuehrt die Verarbeitungslogik des Anwendungsprogramms aus und kommuniziert mit der Datenbankschnittstelle. Der ABAP- April ABAP Programmierung (BC-ABA) SAP AG Workprozesse Prozessor wird vom Dynpro-Prozessor informiert, welcher Programmteil (Modul) entsprechend des Fortgangs der Dynproablauflogik abzuarbeiten ist. Das folgende Bild verdeutlicht die Zusammenarbeit zwischen Dynpro- und ABAP-Prozessor bei der Ausfuehrung von Anwendungsprogrammen. Workprozess Dynpro-Prozessor Dynpro-Prozessor ABAP-Prozessor ABAP-Prozessor Dynpro Dynpro Modul Modul Modul Modul Modul Modul Datenbankschnittstelle Datenbankschnittstelle Datenbankschnittstelle Die Datenbankschnittstelle stellt folgende Dienste zur Verfuegung: Verbindungsauf- und -abbau eines Workprozesses zur Datenbank Zugang zu Datenbanktabellen Zugang zu R -Repository-Objekten (ABAP-Programme, Dynpros etc.) Zugang zu Kataloginformationen (ABAP Dictionary) Transaktionskontrolle (Commit- und Rollback-Behandlung) Verwaltung von Tabellenpuffern auf dem Applikationsserver Die folgende Abbildung zeigt die einzelnen Komponenten der Datenbankschnittstelle: April SAP AG ABAP Programmierung (BC-ABA) Workprozesse Open SQL Dynpro-Prozessor Dynpro-Prozessor ABAP-Prozessor ABAP-Prozessor Native NativeSQL SQL Modul Modul TabellenTabellenModul Modul PufferPufferManagement Management Datenbankschnittstelle Datenbankschnittstelle Tabellenpuffer auf Applikationsserver Native SQL Workprozess Datenbankabhaengige DatenbankabhaengigeSchicht Schicht Standard SQL (dynamic, embedded) Datenbank Management System Datenbank Die Abbildung zeigt, dass es zwei unterschiedliche Moeglichkeiten gibt aus ABAP-Programmen auf Datenbanken zuzugreifen, naemlich Open SQL und Native SQL. Die Anweisungen von Open SQL sind eine vollstaendig in ABAP integrierte Untermenge von Standard SQL. Sie erlauben dem ABAP-Programmierer einen einheitlichen Zugriff auf Daten, unabhaengig vom installierten Datenbanksystem. Open SQL umfasst den DML-Anteil (Data Manipulation Language) des Standards, erlaubt es also Daten zu lesen (SELECT) und zu veraendern (INSERT, UPDATE, DELETE). Die im Standard definierten bereiche der DDL (Data Definition Language) und DCL (Data Control Language) werden im R -System vom ABAP Dictionary bzw. der Berechtigungsverwaltung uebernommen, die jeweils die Funktionalitaet der Datenbanken vereinheitlichen bzw, stark erweitern. Open SQL geht aber auch ueber den Standard hinaus, indem es einige Anweisungen anbietet, die im Zusammenhang mit den uebrigen ABAP-Konstrukten, bestimmte Zugriffe vereinfachen oder beschleunigen koennen. Zusaetzlich bietet Open SQL die Moeglichkeit, bestimmte Tabellen auf dem Applikationsserver zu puffern und dadurch Datenbankzugriffe einzusparen. Dabei uebernimmt die Datenbankschnittstelle die Kontrolle ueber die Abgleichung der Puffer mit der Datenbank. Die Puffer sind teilweise im Arbeitsspeicher des aktuellen Workprozesses und teilweise im gemeinsamen Speicher aller Workprozesse eines Anwendungsservers abgelegt. Bei R Systemen die auf mehrere Anwendungsserver verteilt sind, werden die Daten in den verschiedenen Puffern durch das Puffer-Management in festgelegten Zeitabschnitten synchronisiert. Bei der Datenbankpufferung muss man also in Kauf nehmen, dass die Daten in den Puffern nicht immer aktuell sind. Deshalb wendet man Datenbankpufferung eher bei wenig veraenderlichen Daten an. Native SQL ist nur sehr lose in ABAP eingebunden und erlaubt Zugriff auf den gesamten Umfang der Funktionalitaet, der von der Programmierschnittstelle des Datenbanksystems zur Verfuegung gestellt wird. Native SQL Anweisungen werden im Gegensatz zu Open SQL nicht geprueft und uebersetzt, sondern direkt an das Datanbanksystem gereicht. Ein Programm, das Native SQL April ABAP Programmierung (BC-ABA) SAP AG Workprozesse verwendet, ist abhaengig vom installierten Datenbanksystem. Bei der Entwicklungen der R Anwendungen wird auf den Einsatz von Native SQL weitestgehend verzichtet. Nur in einigen Basis-Komponenten wird Native SQL verwendet (z.B.: im ABAP Dictionary zum Anlegen oder aendern von Tabellen). Die im Bild gezeigte datenbankabhaengige Schicht verbirgt die Unterschiede zwischen den Datenbanksystemen vor dem Rest der Datenbankschnittstelle. Sie wird bei der Installation des Basis-Systems entsprechend der verwendeten Datenbank ausgewaehlt. Dank der Standardisierung von SQL sind die Unterschiede im Hinblick auf die Syntax der Anweisungen gering, Semantik und Verhalten unterliegen jedoch nicht ganz dem Standard und weisen daher groessere Unterschiede auf. Im Falle von Native SQL ist die Funktionalitaet der datenbankabhaengigen Schicht nur minimal. Moegliche Typen von Workprozessen Obwohl alle Workprozesse die im vorhergehenden Abschnitt beschriebenen Komponenten enthalten, koennen wir einzelnen Workprozessen verschiedene Typen zuordnen. Der Typ bestimmt, welche Arten von Aufgaben ein Workprozess im Applikationsserver erledigen soll. Der Typ bestimmt nicht die technischen Eigenschaften eines Workprozesses, sondern dient der Aufgabenverteilung auf dem Applikationsserver. Die Verteilung der Aufgaben auf die verschiedenen Workprozesse nimmt der Dispatcher vor. Fuer jeden Applikationsserver wird vor dem Start des R -Systems festgelegt, wieviele Workprozesse er enthaelt und von welchem Typ diese sind. Der Dispatcher startet die Workprozesse und verteilt an jeden Workprozess nur die Auftraege, die mit seinem Typ korrespondieren. Das erlaubt die optimierte Verteilung von Workprozesstypen hinsichtlich der Ressourcenausnutzung von Applikationsservern. Das folgende Bild zeigt nochmals den Aufbau eines Applikationsservers, wobei jetzt auch die verschiedenen moeglichen Workprozesstypen dargestellt werden: April SAP AG ABAP Programmierung (BC-ABA) Workprozesse Benutzer Benutzer n . . SAP GUI SAP GUI Dispatcher Dispatcher Dialog Dialog Dialog Dialog WorkWorkWorkWorkprozesse prozesse prozess prozess VerVerbuchungs Dialog buchungs Dialog WorkWorkWorkWork- prozesse prozess prozesse prozess Batch Batch Dialog Dialog WorkWorkWorkWorkprozesse prozesse prozess prozess Enqueue Enqueue WorkWorkprozess prozess Spool Spool WorkWorkprozess prozess Applikationsserver Datenbank Management System Datenbank Im folgenden beschreiben wir die einzelnen Workprozesstypen nur kurz, da im weiteren Verlauf dieser Dokumentation naeher auf einzelne Komponenten des Applikationsservers bzw. R Systems eingegangen wird. Dialog-Workprozesse Dialog-Workprozesse erledigen alle Auftraege zum Ausfuehren von Dialogschritten, die durch einen aktiven Benutzer ausgeloest werden. Verbuchungs-Workprozesse Verbuchungs-Workprozesse fuehren Verbuchungsauftraege aus. Verbuchungsauftraege sind die Teile einer SAP-LUW, die saemtliche aus dem Dialog resultierenden Datenbankoperationen in einer Datenbank-LUW buendeln und im Hintergrund ausfuehren. Hintergrund-Workprozesse Hintergrund-Workprozesse verarbeiten Programme, die ohne Benutzerinteraktion ausgefuehrt werden sollen (Hintergrundprogramme). Enqueue-Workprozess Der Enqueue-Workprozess verwaltet eine Sperrtabelle im Shared Memory. Die Sperrtabelle enthaelt die logischen Datenbanksperren des R -Systems und spielt eine wichtige Rolle im April ABAP Programmierung (BC-ABA) SAP AG Workprozesse Zusammenhang mit SAP-LUWs. Es darf fuer ein R -System nur eine einzige Sperrtabelle und somit nur einen einzigen Applikationsserver mit Enqueue-Workprozessen geben. Spool-Workprozess Der Spool-Workprozess gibt sequentielle Datenstroeme an einen Drucker oder an die optische Archivierung aus. Jeder Applikationsserver kann nur einen einzigen Spool-Workprozess enthalten. Die Dienste, die ein Applikationsserver zur Verfuegung stellen kann, werden durch den Typ seiner Workprozesse bestimmt. Ein Applikationsserver kann dann entsprechend mehrere Rollen annehmen, z.B. als Dialog-Server und gleichzeitig als Enqueue-Server, wenn er aus mehreren Dialog-Workprozessen und einem Enqueue-Workprozess besteht. Die Systemadministration kann waehrend des laufenden Workprozesse zwischen den Typen Dialog und Hintergrund umhaengen. Damit kann ein R -System beispielsweise von Tag- auf Nachtbetrieb umgestellt werden, wobei es tagsueber mehr Dialog- als Hintergrund-Workprozesse gibt und umgekehrt. April SAP AG ABAP Programmierung (BC-ABA) uebersicht ueber die Komponenten von Anwendungsprogrammen uebersicht ueber die Komponenten von Anwendungsprogrammen Diese uebersicht beschreibt die Anwendungsprogrammierung im R -System. Alle Anwendungsprogramme und Teile des R -Basis-Systems werden innerhalb der Entwicklungsumgebung ABAP Workbench mit der SAP-eigenen Programmiersprache ABAP geschrieben. Die einzelnen Objekte von Anwendungsprogrammen werden in einem speziellen Teil der Datenbank abgespeichert, dem R -Repository. Das R -Repository dient als zentrale Ablage fuer saemtliche Entwicklungsobjekte des R -Systems. In den folgenden Abschnitten gehen wir auf die Grundlagen und Eigenschaften der Anwendungsprogrammierung ein. Aufbau von Anwendungsprogrammen Seite Moegliche Bildschirmbilder Seite Aufbau der Verarbeitungslogik Seite Verarbeitungsbloecke in ABAP-Programmen Seite ABAP-Sprachelemente Seite Logische Datenbanken und Contexte Seite Speicherstrukturen eines ABAP-Programms Seite April ABAP Programmierung (BC-ABA) SAP AG Aufbau von Anwendungsprogrammen Aufbau von Anwendungsprogrammen R -Anwendungsprogramme laufen auf den Workprozessen der Applikationserver des R Basis-Systems ab. Aus diesem Grund sind R -Anwendungsprogramme unabhaengig von Hardware und Betriebssystem. Sie sind aber nicht ausserhalb eines R -Systems einsetzbar. Wie wir in uebersicht ueber das R -Basis-System Seite gesehen haben, stellt ein Workprozess einen Dynpro-Prozessor zur Bearbeitung von Benutzerinteraktionen, einen ABAPProzessor zur Bearbeitung von Verarbeitungslogik und eine Datenbankschnittstelle fuer die Verbindung zum Datenbanksystem zur Verfuegung. Diese Komponenten eines Workprozesses bestimmen wie folgt den Aufbau von Anwendungsprogrammen: SAP SAPGUI GUI Ablauflogik Ablauflogik (Dynpros) (Dynpros) Verarbeitungslogik Verarbeitungslogik (ABAP-Programme) (ABAP-Programme) Weitere Weitere Schnittstellen Schnittstellen DatenbankDatenbankschnittstelle schnittstelle Anwendungsprogramme bestehen aus zwei Komponenten mit unterschiedlichen Aufgaben: Ablauflogik Die Komponente von Anwendungsprogrammen, die auf Benutzeraktionen auf Bildschirmen reagieren werden durch Dynpros (dynamische Programme) realisiert. Dynpros laufen auf dem Dynpro-Prozessor eines Workprozesses ab. Sie sind definiert durch eine Ablauflogik, die mit einer speziellen Teilmenge von ABAP, der Dynprosprache, programmiert wird, und durch ihre Verknuepfung mit Bildschirmmasken. Der SAP GUI praesentiert dem Benutzer die Bildschirmmasken und uebermittelt die Benutzeraktionen an die zugehoerigen Teile der Ablauflogik. Dynpros reagieren beim Programmablauf auf Benutzeraktionen und geben Sie durch den Aufruf von Programm-Modulen an die Verarbeitungslogik weiter. Verarbeitungslogik Die Komponente von Anwendungsprogrammen, welche speziell die Datenverarbeitung im R System erledigt, wird durch ABAP-Programme (Advanced Business Application Programming) realisiert. ABAP-Programme laufen auf dem ABAP-Prozessor eines Workprozesses ab. Sie April SAP AG ABAP Programmierung (BC-ABA) Aufbau von Anwendungsprogrammen erhalten Bildschirmeingaben vom Dynproprozessor und senden Bildschirminhalte an den Dynproprozessor. Die Verarbeitungslogik greift ueber die Datenbankschnittstelle des jeweiligen Workprozesses auf das Datenbanksystem zu. Hierfuer enthaelt ABAP enthaelt einen speziellen Befehlssatz namens Open SQL, mit dem unabhaengig von der verwendeten Datenbank lesend und schreibend auf Daten zugegriffen werden kann. Die Open SQL-Befehle werden in der Datenbankschnittstelle in die Befehle der verwendeten Datenbank umgesetzt. Weiterhin gibt es die Moeglichkeit ueber sogenannte Native SQL-Befehle die Datenbank ohne Umsetzung anzusprechen. Weitere Datenschnittstellen wie z. B. Speicher, sequentielle Dateien und externe Schnittstellen bieten zusaetzliche Moeglichkeiten zum Senden und Empfangen von Daten in ABAPProgrammen. In der Zusammenarbeit mit Dynpros spielen ABAP-Programme beim Programmablauf eher eine passive Rolle, da sie Module zur Verfuegung stellen, die von der Ablauflogik aufgerufen werden. April ABAP Programmierung (BC-ABA) SAP AG Moegliche Bildschirmbilder Moegliche Bildschirmbilder Jedes Bildschirmbild, das ein Benutzer im R -System angezeigt bekommt, gehoert zu einem Dynpro eines Anwendungsprogramms. Dynpros reagieren auf Benutzereingaben auf den Bildschirmen, senden Daten zum Bildschirm und empfangen Daten vom Bildschirm. Es gibt drei Moeglichkeiten die Bildschirmein- und -ausgabe zu organisieren. Diese unterscheiden sich in der Art, wie sie programmiert werden und in der Art und Weise welche Benutzerinteraktionen typischerweise auf ihnen ausgefuehrt werden. Dynpros Im allgemeinsten Fall erstellt der Anwendungsprogrammierer die Dynpros seiner Programme vollstaendig selbst, das heisst er programmiert alle Details der Ablauflogik und verknuepft sie mit selbstdefinierten Bildschirmmasken. Die Erstellung beider Anteile findet ausschliesslich mit dem Werkzeug Screen Painter der ABAP Workbench statt. Selektionsbilder und Listen Fuer haeufige Anwendungsfaelle bietet das R System zwei spezialisierte Dynpros, naemlich Selektionsbilder und Listen an. Die Bildschirme und die Bildschirmablauflogik dieser Dynpros werden aus ABAP-Befehlen der Verarbeitungslogik generiert. Der Programmierer muss in diesem Fall nicht mit dem Werkzeug Screen Painter arbeiten, sondern er definiert den gesamten Interaktionsteil dieser Bildschirme in der Verarbeitungslogik. Bildschirme im R -System enthalten Menuleisten, Symbolleisten und Drucktastenleisten. Diese drei Objekte, dienen der direkten Eingabe von Benutzeranweisungen auf Bildschirmen und werden unter dem Begriff Status zusammengefasst. Jeder Status ist ein Entwicklungsobjekt des zugehoerigen Anwendungsprogramms und bildet einen eigenstaendigen Teil der Bildschirmbilder. Ein Status ist somit kein interner Teil eines Dynpros und kann in verschiedenen Dynpros wiederverwendet werden. Fuer die Definition von Status enthaelt die ABAP Workbench das Werkzeug Menu Painter. Fuer Dynpros und Listen kann der Status vom Programmierer frei definiert werden. Bei Selektionsbildern ist der Status fest vordefiniert. Im folgenden gehen wir etwas naeher auf die drei Bildschirmarten ein. Dynpros Jedes Dynpro enthaelt eine frei programmierbare Bildschirmmaske zur Datenein- und -ausgabe. Bei der Darstellung der Bildschirmmaske durch den SAP GUI werden zwei Ereignisse ausgeloest: Das Ereignis PBO (Process Before Output) tritt vor der Darstellung der Bildschirmmaske auf dem Bildschirm auf. Das Ereignis PAI (Process After Input) tritt durch eine Benutzeraktionen auf dem Bildschirm ein. Jede Bildschirmmaske ist mit genau zwei Verarbeitungsbloecken der Ablauflogik verknuepft, die auf diese Ereignisse reagieren, naemlich der PBO-Block und der PAI-Block. Die Zusammenfassung des PAI-Blocks eines Dynpros mit dem PBO-Block des darauf folgenden Dynpros bildet einen Dialogschritt des Anwendungsprogramms. Die Dynprosprache zur Programmierung der Ablauflogik ist eine spezielle Teilmenge von ABAP und enthaelt nur wenige Sprachelemente. Die Anweisungen sind syntaktisch zwar aehnlich zu den uebrigen ABAP-Anweisungen, es duerfen aber keine Dynproanweisungen in ABAP-Programmen verwendet werden und umgekehrt. Die wichtigsten Dynprosprachelemente sind MODULE, FIELD, CHAIN, und LOOP. Sie dienen ausschliesslich der Anbindung der Verarbeitungslogik an April SAP AG ABAP Programmierung (BC-ABA) Moegliche Bildschirmbilder die Ablauflogik, d.h. dem Aufruf von Modulen in der Verarbeitungslogik und der Steuerung der Datenuebergabe z.B. in Abhaengigkeit von Fehlerueberpruefungen. Die Bildschirmmasken von Dynpros enthalten alle ueblichen Elemente grafischer Oberflaechen (Ein- und Ausgabefelder, Drucktasten, Auswahlknoepfe etc.). Die folgende Abbildung zeigt ein Beispiel fuer eine Bildschirmmaske eines Dynpros: Alle aktiven Elemente einer Bildschirmmaske haben Namen und sind mit sogenannten Dynprofeldern im Shared Memory verknuepft. Dynprofelder koennen an das ABAP-Dictionary angebunden werden und erhalten dadurch automatische Feld- und Wertehilfefunktionen, sowie Konsistenzpruefungen. Benutzeraktionen aendern die Feldinhalte der entsprechenden Dynprofelder. Der Wertetransport zwischen Dynpros und Verarbeitungslogik erfolgt dadurch, dass beim PAI-Ereignis die Inhalte der Dynprofelder an gleichnamige Variablen im ABAP-Programm uebergeben werden. Jedes Dynpro ruft im zugehoerigen ABAP-Programm sogenannte Dialogmodule auf, welche die Inhalte der Bildschirmmasken vorbereiten (PBO) und die Benutzereingaben verarbeiten (PAI). Es gibt zwar ABAP-Anweisungen zum aendern von Bildschirmeigenschaften, wie z.B. das Ein- und Ausblenden von Bildschirmelementen, aber keine ABAP-Anweisungen fuer deren Definition. Dynpros dienen dem Dialog zwischen Benutzer und Anwendungsprogrammen. Typischerweise werden Dynpros in stark dialogorientierten Programmen eingesetzt und dienen der Ausfuehrung einer Anwendung, die aus der Bearbeitung einer Folge von Bildschirmen besteht. Sie kommen insbesondere immer dann zum Tragen, wenn die Moeglichkeiten der spezialisierten Dynpros, naemlich des Selektionsbilds oder der Liste, nicht ausreichen. Selektionsbilder Selektionsbilder sind spezialisierte Dynpros zur Werteingabe in ABAP-Programmen. Sie werden allerdings nicht mit dem Werkzeug Screen Painter sondern ausschliesslich ueber ABAP-Befehle in April ABAP Programmierung (BC-ABA) SAP AG Moegliche Bildschirmbilder der Verarbeitungslogik definiert. Das Selektionsbild wird entsprechend dieser Befehle generiert. Die Bildschirmablauflogik bleibt dabei fuer den Anwendungsprogrammierer verborgen. Die Definition von Selektionsbildern erfolgt im Deklarationsteil von ABAP-Programmen ueber spezielle Deklarationsanweisungen wie PARAMETERS, SELECT-OPTIONS und SELECTIONSCREEN. Diese Anweisungen deklarieren und formatieren die Eingabefelder eines Selektionsbilds. Die folgende Abbildung zeigt ein Beispiel fuer ein Selektionsbild: Die wichtigsten Elemente von Selektionsbildern sind Eingabefelder fuer Einzelwerte und fuer sogenannte Selektionstabellen. Selektionstabellen dienen dazu, komplexere BenutzerAbgrenzungen aufzunehmen. Bei Verwendung von Selektionstabellen in ABAP uebernimmt das System vollstaendig deren Verarbeitung. Wie bei jedem Dynpro stehen fuer Eingabefelder, die einen Bezug zum ABAP-Dictionary haben, auch auf Selektionsbildern automatische Feld- und Wertehilfefunktionen zur Verfuegung. Der Benutzer kann auf Selektionsbildern vorgefertigte Saetze von Eingabewerten in der Form sognannter Varianten verwenden. Selektionsbilder werden aus ABAP-Programmen ueber die Anweisung CALL SELECTIONSCREEN aufgerufen. Bei ausfuehrbaren Programmen (Typ ) ruft die ABAP-Laufzeitumgebung das im Deklarationsteil definierte Selektionsbild automatisch auf. Selektionsbilder loesen Ereignisse aus und koennen damit in ABAP-Programmen sogenannte Ereignisbloecke aufrufen. Da auf Selektionsbildern hauptsaechlich Eingabefelder definiert werden, ist der Dialog von Selektionsbildern eingabebezogener als der von frei definierten Dynpros. Auf Dynpros sind Einund Ausgabe gleichberechtigt. Selektionsbilder koennen deshalb immer dann sinnvoll eingesetzt werden, wenn Benutzereingaben fuer den weiteren Programmverlauf wesentlich sind. Beispielsweise werden Selektionsbilder vor Datenbankzugriffen eingesetzt, um die einzulesende Datenmenge einzuschraenken. April SAP AG ABAP Programmierung (BC-ABA) Moegliche Bildschirmbilder Listen Listen sind Bildschirme zur formatierten und strukturierten Darstellung von Daten. Listen werden ausschliesslich ueber ABAP-Befehle definiert, gestaltet und gefuellt. Das System stellt eine in ABAP definierte Liste auf einem speziellen Listen-Dynpro dar. Wie bei Selektionsbildern bleibt dabei die Bildschirmablauflogik fuer den Anwendungsprogrammierer verborgen. Die wichtigste Aufgabe von Listen ist die Datenausgabe. Sie erlauben aber auch Benutzerinteraktionen. Sie reagieren auf Mausklick und koennen Eingabefelder enthalten. Die Listendarstellung erfolgt aber mit einer voellig anderen Technik als die Dynprodarstellung. Eingabefelder auf Listen sind nicht mit Dynprofeldern gleichzusetzen denn der Datentransport zwischen Listen und ABAP-Programm geht anders vonstatten als bei Dynprofeldern. Wenn Eingabefelder auf Listen mit dem ABAP-Dictionary verknuepft sind stehen auch bei ihnen automatische Feld- und Wertehilfefunktionen zur Verfuegung. Die folgende Abbildung zeigt ein Beispiel fuer eine Liste: Die Definition von Listen erfolgt ueber einen speziellen Satz von Anweisungen (Listenanweisungen WRITE, SKIP, ULINE, NEW-PAGE etc.) in den Verarbeitungsbloecken von ABAP-Programmen. Bei der Ausfuehrung dieser Anweisungen wird systemintern eine Liste beschrieben. Die Anzeige von Listen auf Bildschirmen und die Behandlung von Benutzeraktionen auf Listen erledigt ein systeminternes Programm, welches wir als Listenprozessor bezeichnen. Im R -System koennen nur Daten, die intern als Liste abgespeichert sind an das Spoolsystem z.B. zwecks Druckausgabe gesendet werden. In ABAP-Programmen kann mit der Anweisung LEAVE TO LIST-PROCEssING das Listendynpro als Folgebild definiert und eine beschriebene Liste damit zur Anzeige gebracht werden. Bei ausfuehrbaren Programmen vom Typ ruft die ABAP-Laufzeitumgebung die im Programm definierte Liste automatisch auf. Ein Programm kann einen Stapel von bis zu Listen verwalten. Beispielsweise koennen ueber einer Grundliste bis zu Detaillisten erzeugt werden. Benutzeraktionen auf Listen loesen Ereignisse aus und koennen damit im ABAPProgramm sogenannte Ereignisbloecke aufrufen. April ABAP Programmierung (BC-ABA) SAP AG Moegliche Bildschirmbilder Listen sind hauptsaechlich ausgabeorientiert. Benutzeraktionen auf Listen dienen meistens der uebernahme von Listeninhalten in die weitere Programmverarbeitung und nicht der direkten Eingabe von Werten. Der Einsatz von Listen ist deshalb immer dann sinnvoll, wenn mit Ausgabedaten gearbeitet wird, wenn Daten gedruckt werden sollen und wenn Benutzeraktionen sich auf Ausgabedaten beziehen. April SAP AG ABAP Programmierung (BC-ABA) Aufbau von ABAP-Programmen Aufbau von ABAP-Programmen Die ABAP-Programme der Verarbeitungslogik uebernehmen die zentrale Rolle der Datenverarbeitung in der R -Anwendungsprogrammierung. Die Programmiersprache ABAP ist speziell fuer dialogorientierte Datenbankanwendungen konzipiert. In den folgenden Abschnitten gehen wir detailliert auf Aufbau und Ausfuehrung von ABAP-Programmen ein. Programmaufbau ABAP-Programme dienen der Datenverarbeitung waehrend der einzelnen Dialogschritte eines Anwendungsprogramms. Das bedeutet, dass ABAP-Programme nicht als eine einzige sequentielle Einheit aufgebaut sein koennen, sondern in Abschnitte unterteilt sein muessen, die den einzelnen Dialogschritten zugeordnet werden koennen. Um dieser Anforderung gerecht zu werden, sind ABAP-Programme modular aus Verarbeitungsbloecken aufgebaut. Ein Verarbeitungsblock besteht aus (normalerweise mehreren) ABAP-Anweisungen. Verarbeitungsbloecke sind nicht schachtelbar und die Programmausfuehrung beruht auf dem Aufruf von Verarbeitungsbloecken. Das folgende Bild zeigt den Aufbau eines ABAP-Programms: Deklarationsteil fuer globale Daten Dialogmodule Ereignisbloecke Unterprogramme etc. Jedes ABAP-Programm besteht aus den folgenden zwei Teilen: Deklarationsteil fuer globale Daten, Klassen und Selektionsbilder Der erste Teil eines ABAP-Programms ist der Deklarationsteil fuer globale Daten, Klassen und Selektionsbilder. Dieser Teil wird gebildet aus: allen Datendeklarationsanweisungen fuer globale Daten. Globale Daten sind in allen internen Verarbeitungsbloecken sichtbar. Sie werden durch die Datendeklarationsanweisungen definiert, die vor dem ersten Verarbeitungsblock, in Dialogmodulen oder in Ereignisbloecken stehen. In den letztgenannten beiden Verarbeitungsbloecken sind mit zwei Ausnahmen keine lokalen Daten deklarierbar. allen Definitionen von Selektionsbildern. allen Deklarationen von programminternen Klassen (Anweisung CLAss DEFINITION). Programminterne Klassen sind Teil von ABAP Objects, der objektorientierten Erweiterung von ABAP. Datendeklarationsanweisungen, die Prozeduren (Methoden, Unterprogramme, Funktionsbausteine) aufgefuehrt sind, bilden den Deklarationsteil fuer die lokalen Daten dieser Verarbeitungsbloecke. Diese Daten sind auch nur innerhalb der Prozeduren sichtbar. April ABAP Programmierung (BC-ABA) SAP AG Aufbau von ABAP-Programmen Container fuer Verarbeitungsbloecke Der zweite Teil eines ABAP-Programms umfasst alle Verarbeitungsbloecke des Programms. Folgende Typen von Verarbeitungsbloecken sind moeglich: Dialogmodule (kein lokaler Datenbereich) Ereignisbloecke (bis auf zwei Ausnahmen kein lokaler Datenbereich) Prozeduren (Methoden, Unterprogramme und Funktionsbausteine mit jeweils lokalem Datenbereich) Waehrend Dialogmodule und Prozeduren durch definierende ABAP-Schluesselwoerter eingeschlossen sind, werden Ereignisbloecke durch Ereignisschluesselwoerter eingeleitet und durch den naechsten Verarbeitungsblock beendet. Alle ABAP-Anweisungen (bis auf die deklarativen Anweisungen des Deklarationsteils) sind Teil eines Verarbeitungsblocks. Nichtdeklarative ABAP-Anweisungen, die zwischen dem Deklarationsteil fuer globale Daten und einem Verarbeitungsblock stehen, werden automatisch dem Ereignisblock START-OF-SELECTION zugeordnet. Aufruf von Verarbeitungsbloecken Der Aufruf von Verarbeitungsbloecken kann werden entweder von ausserhalb des ABAPProgramms oder durch ABAP-Befehle, die selbst wieder in Verarbeitungsbloecken stehen, erfolgen. Dialogmodule und Ereignisbloecke werden von ausserhalb des ABAP-Programms aufgerufen, Prozeduren werden durch ABAP-Befehle in ABAP-Programmen aufgerufen. Der Aufruf von Ereignissbloecken unterscheidet sich wie folgt von den Aufrufen von anderen Verarbeitungsbloecken: Ereignisbloecke werden aufgrund von Ereignissen aufgerufen. Benutzeraktionen auf Selektionsbildern und Listen aber auch die Laufzeitumgebung loesen Ereignisse aus, die in ABAP-Programmen behandelt werden koennen. Nur fuer Ereignisse, auf die das Programm reagieren soll, muessen Ereignisbloecke definiert sein (waehrend z.B. zu einem Unterprogrammaufruf sehr wohl ein Unterprogramm existieren muss). Das bedeutet, dass ein ABAP-Programm auf bestimmte Ereignisse reagieren kann, aber nicht muss. Programmausfuehrung und Programmtypen Ein ABAP-Programm auszufuehren bedeutet, seine Verarbeitungsbloecke aufzurufen. ABAPProgramme werden von ausserhalb des Programms gesteuert. Die Steuerung erfolgt durch die Prozessoren des aktuellen Workprozesses. Fuer den zeitlichen Ablauf fassen wir DynproProzessor und ABAP-Prozessor der beteiligten Workprozesse zur ABAP-Laufzeitumgebung zusammen. Die Laufzeitumgebung steuert Bildschirme und ABAP-Verarbeitungsbloecke. Die Laufzeitumgebung enthaelt einige spezialisierte Steuerungsablaeufe, die Bildschirme und ABAPVerarbeitungsbloecke in bestimmten, zweckgebundenen Reihenfolgen aufrufen koennen. Wir bezeichnen diese zeitlich aufeinanderfolgenden Abschnitte auch als Prozessoren. Bei der Ausfuehrung eines ABAP-Programms wechseln sich die einzelnen Prozessoren hintereinander ab und es hat immer ein bestimmter Prozessor die Kontrolle. April SAP AG ABAP Programmierung (BC-ABA) Aufbau von ABAP-Programmen Bildschirm Bildschirm SAP GUI Prozessor Prozessor Prozessor ABAP-Laufzeitumgebung PBOLogik PAILogik Verarbeitungsblock Verarbeitungsblock Dynpro-Ablauflogik Deklarationsteil fuer globale Daten Verarbeitungsblock ABAP-Programm Im R -System unterscheiden wir zwischen verschiedenen Typen von ABAP-Programmen. Die Programmtypen muessen bei der Programmerstellung festgelegt werden. Sie definieren die grundlegenden technische Eigenschaften des Programms. Das wesentliche Unterscheidungsmerkmal zwischen den einzelnen Programmtypen ist die Art und Weise wie die Verarbeitungsbloecke der Programme von der Laufzeitumgebung aufgerufen werden. Bei der Ausfuehrung eines Anwendungs-Programms muss zumindest der erste Verarbeitungsblock eines ABAP-Programms von ausserhalb des Programms, also aus der Laufzeitumgebung aufgerufen werden. Aus diesem Verarbeitungsblock heraus koennen dann weitere Verarbeitungsbloecke aufgerufen oder die Kontrolle wieder an die Laufzeitumgebung abgegeben werden. Beim Start eines ABAP-Programms wird ein vom Programmtyp abhaengiger Prozessor in der Laufzeitumgebung gestartet, der den ersten ABAP-Verarbeitungsblock aufruft. Der Start eines ABAP-Programms kann durch den Benutzer, aber auch durch das System, z.B. bei der Hintergrundverarbeitung, oder durch externe Schnittstellen, z.B. bei Remote-Function-Calls (RFC) erfolgen. Beim Programmstart durch Benutzer unterscheiden wir zwischen der direkten Ausfuehrung durch Angabe des Programmnamens und dem Start ueber Transaktionscodes. Sie koennen jedes Anwendungsprogramm mit einem Transaktionscode versehen. Der Benutzer kann das Programm dann ueber die direkte Eingabe des Transaktionscodes starten. Weiterhin werden in der Regel alle Transaktionscodes auch mit Menuepfaden auf den Bildschirmen des R -Systems verknuepft. Folgende Programmtypen sind fuer Anwendungsprogramme von Bedeutung: Typ Ein Typ -Programm hat die wichtige technische Eigenschaft, dass es nicht unmittelbar ueber selbstdefinierte Dynpros gesteuert werden muss. Bei einem Typ -Programm uebernehmen Prozessoren der Laufzeitumgebung automatisch und in einer vorgegebenen Reihenfolge die April ABAP Programmierung (BC-ABA) SAP AG Aufbau von ABAP-Programmen Aufrufe von Verarbeitungsbloecken und gegebenenfalls von Bildschirmen (Selektionsbilder und Listen). Benutzeraktionen auf den Bildschirmen koennen den Aufruf weiterer Verarbeitungsbloecke vernanlassen. Ein Typ -Programm und damit der zugehoerige Prozessor in der Laufzeitumgebung wird ausschliesslich ueber die Anweisung SUBMIT aus anderen ABAP-Programm heraus gestartet. Das R -System bietet verschiedene Moeglichkeiten, die Ausfuehrung von Typ -Programmen durch Angabe des Programmnamens auf Bildschirmbildern zu starten. Deshalb sprechen wir bei Typ Programmen auch von ausfuehrbaren Programmen. Bei Typ -Programmen laeuft in der Laufzeitumgebung eine vordefinierte Folge von ProzessSchritten ab. Der Ablauf ermoeglicht erst eine Eingabe von Selektionsparametern auf einem Selektionsbild, dann eine Datenselektion und Datenverarbeitung und schliesslich die Datenausgabe auf einer Liste, ohne dass der Programmierer eigene Dynpros definieren muss. Weiterhin steuert die Laufzeitumgebung die Zusammenarbeit mit einer logischen Datenbank. Eine logische Datenbank ist ein spezielles ABAP-Programm zum Lesen von Daten aus Datenbanktabellen. Der vorgegebene Ablauf eines Typ -Programms orientiert sich somit an den Aufgaben des Reporting. Dazu zaehlen Selektionseingabe, das Lesen von Daten, die Datenverarbeitung und die Darstellung der Daten. Aus diesem Grund werden ausfuehrbare Programme vom Typ im R -System oft als Report und das Starten von ausfuehrbaren Programmen als Reporting bezeichnet. Da die Definition von Ereignisbloecken nicht vorgeschrieben ist, kann der Programmierer entscheiden, auf welche Ereignisse das ausfuehrbare Programm reagieren soll. Weiterhin kann er jederzeit eigene Dynpros oder Verarbeitungsbloecke aufrufen, um den vorgegebenen Ablauf zu verlassen, z.B. um Daten statt auf einer Liste in einer Tabelle auf einem Dynpro darzustellen. Das einfachste ausfuehrbare Programm enthaelt z.B. nur den Standardverarbeitungsblock STARTOF-SELECTION. Fuer die Ausfuehrung von ausfuehrbaren Programmen ist kein Benutzerdialog notwendig. Das Selektionsbild kann ueber Varianten gefuellt werden und Ausgabedaten koennen statt auf die Liste direkt ins Spool-System gestellt werden. Deshalb sind ausfuehrbare Programme Voraussetzung fuer die Hintergrundverarbeitung im R -System. Wenn ein ausfuehrbares Programme vom Typ mit Transaktionscodes versehen wird, kann der Benutzer das Programm auch ueber den Transaktionscode starten. Auch in diesem Fall findet in der Laufzeitumgebung der reporting-orientierte Ablauf statt, weshalb wir solche Transaktionen auch als Report-Transaktionen bezeichnen. Der Einsatz von ausfuehrbaren Programmen ist immer dann sinnvoll, wenn der Programmablauf ganz oder teilweise dem vordefinierten Ablauf in der Laufzeitumgebung entspricht. Vor Release .A waren ausfuehrbare Programme die Voraussetzung fuer den Einsatz von logischen Datenbanken. Inzwischen koennen logische Datenbanken aber auch selbstaendig aufgerufen werden. Typ M Die wichtigste technische Eigenschaft von Typ M-Programmen ist die Tatsache, dass sie ausschliesslich ueber die Ablauflogik von Dynpros gesteuert werden. Diese Programme muessen ueber Transaktionscodes aufgerufen werden, die mit einem Dynpro (Startdynpro) des Programms verknuepft sind. Bei diesen Programmen muss der Programmierer also eigene Dynpros definieren, wobei das Startdynpro auch ein Selektionsbild sein kann. Beim Start des Programms ueber den Transaktionscode wird in der Laufzeitumgebung ein Prozessor gestartet, der zunaechst das Startdynpro aufruft, welches dann ein Dialogmodul des zugehoerigen ABAP-Programms aufruft. Der weitere Ablauf ist voellig beliebig. Das Dialogmodul kann beispielsweise April SAP AG ABAP Programmierung (BC-ABA) Aufbau von ABAP-Programmen die Kontrolle an das Dynpro zurueckgeben, dann verzweigt der Ablauf zu einem Folgedynpro. Jedes Dynpro hat ein statisches oder dynamisches Folgedynpro. Dynpros und ihre Folgedynpros sind die Bestandteile von frei definierbaren Dynprofolgen. andere Dynprofolgen, Selektionsbilder oder Listen aufrufen, von denen dann wiederum die entsprechenden Verarbeitungsbloecke im ABAP-Programm gestartet werden. andere interne oder externe Verarbeitungsbloecke aufrufen. andere Anwendungsprogramme ueber CALL TRANSACTION oder SUBMIT aufrufen. Da ABAP-Programme mit dem Programmattribut Typ M hauptsaechlich Dialogmodule der zugehoerigen Dynpros enthalten, bezeichnen wir sie als Modulpool. Die Arbeit mit Modulpools ist bei stark dialogorientierten Programmen mit vielen Dynpros sinnvoll, in denen der Programmablauf weitgehend durch die Ablauflogik von Dynprofolgen definiert wird. Typ F Typ F-Programme koennen nicht ueber Transaktionscodes oder Eingabe des Namens gestartet werden, sondern dienen ausschliesslich als Container fuer Funktionsbausteine. Funktionsbausteine sind spezielle Prozeduren im R -System, die aus anderen ABAPProgrammen aufgerufen werden koennen. Wir bezeichnen Typ F-Programme auch als Funktionsgruppen. |
Комментарии