SAP Query - Prof Dr Dieter Steinmann FH Trier

SAP Projekt 

sap_work_query_04 

1 

Arbeitspapiere SAP 

SAP Query: 

Flexible Auswertungen in SAP R/3 

Vorbemerkungen: Die vorliegenden Unterlage sind auf Basis unterschiedlicher 

Systemversionen entstanden. Die Ursprünge gehen zurück auf 

ein System SAP R/3 Version 2.2e. Mittlerweile wird ein System 

SAP R/3 Version 4.4e eingesetzt. 

Die Aktualisierung aller Angaben entsprechend der 

unterschiedlichen Releases wie z.B. der Bildschirmkopien wurde 

nur an wichtigen Stellen vorgenommen. 

Es ist daher bei auftretenden Problemen immer zu prüfen, ob 

durch die Veränderungen über Releases die gemachten 

Angaben angepasst werden müssen. 

Alle Rechte an wiedergegebenen Screen Shots oder Inhalten der Online Dokumente bzw. sonstiger schriftlicher 

oder elektronischer Unterlagen bei SAP 

Prof. Dr. Dieter Steinmann Fachhochschule Trier Erstelldatum 28.08.2001 11:04



2 

Gliederung 

1. Einführung zu SAP Query .............................................................................. 5 

1.1. Bedeutung von SAP Query...................................................................... 5 

1.2. Menues und Informationen zu SAP Query ................................................ 5 

1.1.1 Aufruf SAP Query ............................................................................ 5 

1.1.2 Hilfe zu SAP Query .......................................................................... 6 

1.3. Verwandte Themenstellungen ................................................................. 7 

2. Kurzüberblick SAP Query .............................................................................. 8 

3. Eigene Queries ............................................................................................. 8 

3.1. Voraussetzung Benutzergruppen anlegen und Benutzer zuordnen............. 9 

3.2. Sachgebiete zur logischen Datenbank und Art des Zugriffs 

Benutzergruppen zuordnen ............................................................................. 11 

3.3. Auswahl logischer Datenbanken............................................................ 13 

3.4. Darstellung von Tabellen über Data Dictionary und Datenmodell ............. 16 

3.5. Query anlegen...................................................................................... 28 

3.6. Logische Datenbanken und Tabellen den Sachgruppen zuordnen ........... 29 

3.7. Sachgruppenauswahl, Feldauswahl und Aktivieren von Feldern 

für eine Query ...................................................................................... 30 

3.8. Grundliste definieren............................................................................. 32 

3.9. Ausführen der Query............................................................................. 33 

4. Anhang ....................................................................................................... 35 

4.1. Tabellenumsetzung für SAP Query ........................................................ 35 

1.1.3 Suche der Release Info über Freitextsuche in den Release-Hinweisen 

35 

1.1.4 Ausführen der Reports zur Umsetzung ............................................ 37 

1.1.5 Release Info Text zur SAP Query: Tabellenumsetzung als 

Voraussetzung zur Nutzung der ABAP Workbench........................................ 40 






3 

Abbildungsverzeichnis 

Abbildung 1: Aufruf SAP Query über Infosysteme .................................................. 5 

Abbildung 2: Aufruf SAP Query über System Dienste ............................................. 6 

Abbildung 3: Aufruf SAP Query über ABAP Workbench.......................................... 6 

Abbildung 4: Berichtspool Infosystem .................................................................... 7 

Abbildung 5: Berechtigungsgruppe als zusätzliche Zugriffsbeschränkung ................ 8 

Abbildung 6: Anlegen von Benutzergruppen für SAP Query über die ABAP 

Workbench (Hilfsmittel) .................................................................................. 9 

Abbildung 7: Anlegen von Gruppen und Benutzern für SAP Query ....................... 10 

Abbildung 8: Sachgebiet und Sachgruppen generieren (Sachgruppen 

Feldzuordnungen müssen noch durchgeführt werden) ................................... 11 

Abbildung 9: Gruppe, Benutzer Sachgebiet zuordnen........................................... 12 

Abbildung 10: Beispiel Auswahl der Logischen Datenbank Disposition (MDKP)...... 15 

Abbildung 11: Darstellung der Tabelle MDTB über das Data Dictionary 

(Werkzeuge ? Workbench ? Pull Down Menue oder Button Data Dictionary, 

Eingabe des Tabellennamens) ..................................................................... 16 

Abbildung 12: Einstieg in das Datenmodell über die Workbench-Funktion 

Entwicklung - Data Modeler (Werkzeuge ? Workbench ? ...)...................... 16 

Abbildung 13: Auswahl des Datenmodells im Bereich Disposition über MM 

Produktionsplanung..................................................................................... 17 

Abbildung 14: Eintität Disponentengrupe ............................................................. 18 

Abbildung 15: Grafische Darstellung des Datenmodells mit ausgehenden 

Beziehungen zu Disponentengruppe eingeblendet ........................................ 19 

Abbildung 16: Grafische Darstellung des Datenmodells mit eingehenden 

Beziehungen zu Disponentengruppe eingeblendet ........................................ 20 

Abbildung 17: Darstellung des Entitätstyps Disponentengruppe ........................... 21 

Abbildung 18: Darstellung der Tabelle T024D ...................................................... 22 

Abbildung 19: Grafische Darstellung der Tabelle MDTB über das Data Dictionary .. 23 

Abbildung 20: Verbindung der MDTB zum Entitätstypen ....................................... 24 

Abbildung 21: Anzeige der Verwendung der Tabelle MDTB in Programmen und 

Entitätstypen............................................................................................... 25 

Abbildung 22: Entitätstyp Dispositionslistenposition.............................................. 26 

Abbildung 23: Die Darstellung der eingehenden und ausgehenden Beziehungen 

der Dispositionslistenposition zeigt wie schnell die Zusammenhänge 

unübersichtlich und nicht mehr darstellbar werden. ........................................ 27 

Abbildung 24: Query anlegen Einstieg ................................................................. 28 

Abbildung 25: Query Parameter anlegen ............................................................. 28 

Abbildung 26: Anlegen von Sachgruppen und Zuordnen von Datenbank-Feldern... 29 

Abbildung 27: Auswahl der Sachgruppe in einer Query......................................... 30 

Abbildung 28: Feldauswahl im Rahmen der Erstellung einer Query ....................... 31 

Abbildung 29: Aktivieren von Feldern für die Query .............................................. 31 

Abbildung 30: Aufbau der Grundliste einer Query................................................. 32 

Abbildung 31: Ausführen einer Query .................................................................. 33 

Abbildung 32: Ausgabe der Query....................................................................... 34 

Abbildung 33: Suche in den Release Informationen.............................................. 35 

Abbildung 34: Release Hinweise zu Query .......................................................... 36 

Abbildung 35: Kopieren des Inhaltsverzeichnisses ............................................... 37 

Abbildung 36: Ausführen Report RSAQUM40 ...................................................... 38 






4 

Abbildung 37: Umsetzen der Objekte zu Release 4.0 ........................................... 38 

Abbildung 38: Fehlermeldung zur Umsetzung ...................................................... 39 






5 

1. Einführung zu SAP Query 

1.1. Bedeutung von SAP Query 

SAP Query ist ein Werkzeug, mit dem besonders geschulte Anwender (key user) 

eigene Auswertungen definieren können. 

SAP Query sollte in den Fachbereichen von den key usern eingesetzt werden, um für 

den jeweiligen Fachbereich auf kurzem Weg Auswertungen auf die Datenbank 

erstellen zu können. SAP Query unterscheidet ad hoc-Auswertungen und solche die 

gespeichert werden können und von einem begrenzten Benutzerkreis immer wieder 

ausgeführt werden können. Queries können auch als Varianten (also z.B. mit 

vorbelegten Selektionskriterien abgelegt werden. 

SAP Query setzt spezielle Zugriffsberechtigungen voraus die sich unterscheiden 

nach anlegen und modifizieren von Queries, Ausführen und Verwalten von Queries 

sowie die Organisation der Query-Nutzung. 

Die Ergebnisse können entweder am Bildschirm ausgegeben, ausgedruckt oder in 

unterschiedlichen Formaten auf das Front End heruntergeladen werden. 

1.2. Menues und Informationen zu SAP Query 

1.1.1 Aufruf SAP Query 

Der Aufruf von SAP Query erfolgt über unterschiedliche Menüfolgen: 

1. entweder über ? System ? Dienste ? ABAP Query, 

2. über Infosysteme ? Ad-hoc-Berichte ? ABAP/4 Query 

3. oder über ? Werkzeuge ? ABAP Workbench ? Hilfsmittel ? ABAP Query 

a. ? Queries 

b. ? Sachgebiete 

c. ? Benutzergruppen. 

Abbildung 1: Aufruf SAP Query über Infosysteme 






6 

Abbildung 2: Aufruf SAP Query über System Dienste 

Abbildung 3: Aufruf SAP Query über ABAP Workbench 

1.1.2 Hilfe zu SAP Query 

In der Online-Dokumentation findet sich die Hilfe zu SAP-Query unter 

R/3-Bibliothek ? BC – Basis ? ABAP Workbench (BC-DWB) ? Customizing Tools 

(BC-DWB-CUS) ? BC - ABAP Query 

Weitere Themenstellungen in der Online-Dokumentation finden sich unter 

R/3-Bibliothek ? BC – Basis ? ABAP Workbench (BC-DWB) Customizing Tools 

(BC-DWB-CUS) ? BC – ABAP Reporting Tutorial ? ABAP-Query 






7 

1.3. Verwandte Themenstellungen 

Es existieren in SAP eine Vielzahl von vordefinierten Berichte oder Reports. Vor 

Erstellung eines eigenen Berichts sollte zunächst einmal geprüft werden, ob ein 

solcher Bericht, vielleicht in einer Variante für eine entsprechende Aufgabenstellung 

verwendet werden kann. 

Es existiert in den Infosystemen eine Vielzahl von Auswertungen, die durch die Allg. 

Berichtsausw. Ergänzt werden. Hier ist ebenso der Zugriff auf Ad-hoc Berichte mit 

der SAP Query oder dem Report Writer. 

Abbildung 4: Berichtspool Infosystem 






8 

2. Kurzüberblick SAP Query 

? Man unterscheidet 

1. Grundlisten 

2. Statistiken 

3. .Ranglisten 

? Man bildet Benutzergruppen und ordnet Benutzer zu. Innerhalb der Gruppe 

kann jedes Gruppenmitglied alle Queries ausführen und wenn er über die 

Rechte verfügt, bearbeiten. 

? Den Benutzergruppen werden Sachgebiete zugeordnet. Dies sind logische 

Sichten auf die SAP-Datenbanken. Jedes Sachgebiet wird noch einmal in 

Sachgruppen unterteilt, die beim Anlegen von Feldern in einer Query 

verwendet werden. Sachgebiete können mehreren Benutzergruppen 

zugeordnet werden. 

? Eine weitere Einschränkung ergibt sich dadurch, dass beim anlegen von Sachgebieten 

eine Berechtigungsgruppe vergeben werden kann, die den Benutzern dieses 

Sachgebietes als Voraussetzung für den Zugriff auf diesen Datenbereich zugeordnet 

werden muss. 

Abbildung 5: Berechtigungsgruppe als zusätzliche Zugriffsbeschränkung 

3. Eigene Queries 

Voraussetzung für das anlegen von Queries ist, dass die entsprechenden 

Benutzerrechte in der Benutzerverwaltung vergegeben sind. Weiterhin ist wichtig, 

dass es einen Verwalter für Queries gibt, der speziell für diesen Bereich 

Benutzergruppen anlegt, den Gruppen Benutzer zuweist und gleichzeitig die 

entsprechenden Datenbank-Bereiche für die Bearbeitung in diesem Kontext 

zuordnet. 






9 

Ferner muss beim Übergang von SAP R/3 3.xx auf 4.0a die Umsetzung einiger 

Tabellen erfolgen (siehe Anhang). Die Vorgehensweise findet sich in den Release 

Hinweisen zum Release 4.0a. 

Es ist darauf zu achten, dass nach der Umsetzung, oder falls die Umsetzung mit dem 

System bereits erfolgt ist, in einem erneuten ausführen der entsprechenden Query 

ein Freigabelauf für die Tabellen durchgeführt wird. Erst dann ist es möglich 

Benutzergruppen und Benutzer mit allen weiteren Parametern einzustellen, um SAP 

Query zu nutzen. 

3.1. Voraussetzung Benutzergruppen anlegen und Benutzer 

zuordnen 

Abbildung 6: 

Anlegen von Benutzergruppen für SAP Query über die ABAP Workbench 

(Hilfsmittel) 

Beim Versuch Benutzer anzulegen kann es zu einer Fehlermeldung kommen, 

Tabellenumsetzung muss durchgeführt werden. Näher Angaben in den Release 

Infos Query zu Release 4.0A. Die Vorgehensweise ist im Anhang beschrieben. Es 

kann jedoch sein, dass nur der Freigabelauf nach einer Umsetzung oder auch nach 

der Installation eines 4.NN-Releases noch nicht erfolgt ist. 






10 

Einstieg: Felder leer 

Ergebnismaske: Zuordnung Benutzergruppe, Benutzer, Sachgebiet 

Abbildung 7: Anlegen von Gruppen und Benutzern für SAP Query 






11 

3.2. Sachgebiete zur logischen Datenbank und Art des Zugriffs 

Benutzergruppen zuordnen 

Abbildung 8: Sachgebiet und Sachgruppen generieren (Sachgruppen Feldzuordnungen 

müssen noch durchgeführt werden) 






12 

Abbildung 9: Gruppe, Benutzer Sachgebiet zuordnen 






13 

3.3. Auswahl logischer Datenbanken 

Logische Datenbanken (Darstellung der Eingabeliste in SAP R/3) 

------------------------------------------------------------- 

DatenbankKurztext- 

------------------------------------------------------------- 

$$M-VERARBEITUNG OHNE DATENBANK 

$$S-Verarbeitung ohne Datenbank 

50V-Lieferungen in Arbeit- 

AAV-Logische Datenbank RV: Verkaufsbelege 

ABS-ABAP/4 Book: Customers and bookings 

ACS-Beispieldatenbank zum Lesen von Archiven 

ADA-Anlagendatenbank 

AFI-Logische Datenbank Aufträge 

AKV-Logische Datenbank RV: Verkaufsbelege 

ALV-Archivierung Lieferungen 

ARV-Logische Datenbank RV: Verkaufsbelege 

ASV-Anforderungsbild fuer verdichtete 

Informationen 

AUK-Abrechnungsbelege 

AUW-Aufteiler- 

B1L-Transportbedarfe nach Nummer 

BAF-BAV-Datensammler 

BAM-Bestellanforderungen Allgemein 

BBM-Archivierung Bestellanforderungen- 

BCD- 

BJF-Bewegungssaetze Darlehen mit 

Datumseingrenzung (JR 

BKK-Bauteile- 

BKM-Bestellanforderung zur Kontierung- 

BMM-Belege zur Nummer 

BPF-Treasury-Geschäftspartner 

BRF-BELEGDATENBANK 

BRM-Buchhaltungsbelege 

BTF-Bestände und Bewegungen Darlehen- 

BTM-Batchrezept; Drucken- 

BUCHUNGSJOURNAL-LDB für Buchungsjournal 

BUD-LDB für Darlehensstammdaten, Konditionen, 

Belege 

C1F-Finanzmittelrechnung- 

CDC-Dokumentstückliste 

CEC-Equipmentstückliste- 

CEK-Kostenstellen - Einzelposten 

CFK-Datenpool für SAP-EIS- 

CIK-Kostenstellen - Istdaten 

CKC-Kundenauftragsstückliste 

CKM-Materialstamm 

CMC-Materialstückliste 

CPK-Kostenstellen - Plandaten 

CRC-Arbeitsplätze 

CRK-Kostenstellen - gesamt 

CRZ-Logische Datenbank zu Kursen BC220/BC230 

CSC-Standardstückliste 

CSR-Logische Datenbank zur Archivierung für 

BOM- 

CTC-TechnischerPlatzStückliste 

D$I-VERARBEITUNG OHNE DATENBANK 

D$M-VERARBEITUNG OHNE DATENBANK 

D$S-Verarbeitung ohne Datenbank 

D$V-VERARBEITUNG OHNE DATENBANK 

DBM-Dispositionsbelege 

DDF-DEBITOREN DATENBANK- 

DPM-Planauftträge 

DSF-Sollstellung Darlehen- 

DVS-Logische Datenbank zur Archivierung für DVS- 

DWF-Darlehen WDV 

EBM-Einkaufsaktivitäten zur Bedarfsnummer 

ECM-Einkaufsbelege zur Materialklasse- 

EKM-Einkaufsbelege zur Kontierung 

ELM-Einkaufsbelege zum Lieferanten 

EMM-Einkaufsbelege zum Material 

ENM-Einkaufsbelege zur Belegnummer 

EQI-Logische Datenbank Equipment 

ERM-Archivierung Einkaufsbelege 

ESM-Einkaufsbelege zur Submissionsnummer 

EWM-Einkaufsbelege zum Lieferwerk 

F1F-Logische Datenbank für das 

Haushaltsmanagement 

F1S-BC: geplante Flüge, Flüge und Buchungen 

FDF-Finanzdisposition 

FEF-Finanzdispo-Einzelsätze 

FMF-Haushaltsmanagement- 

FRF-Selektionsbild für Recherche 

FSF-Finanzdispo-Summensätze 

GLG-FI-SL Summen- und Einzelposten 

GLU3 Felxibles Hauptbuch- 

I1L-Inventurdaten zum Lagerplatz 

I2L-Lagerquants zum Lagerplatz 

I3L-Inventurbelege 

IBF-Logische Datenbank Immobilien (Mietvertrag)- 

IDF-Logische Datenbank Immobilien 

IFM-Einkaufsinfosätze Allgemein 

ILM-Archivierung Einkaufsinfosätze 

IMA-Logische Datenbank Investitionsprogramme 

IMC-Verdichtung IM (nicht operativ nutzbar) 

IMM-Inventurbelege zum Material 

IMR-MaßnahmenAnforderungen (nicht operativ 

nutzbar) 

IMT-MaßnahmenAnforderungen (nicht operativ 

nutzbar) 

INM-Inventurbelege 

IOC-Shop floor control - Auftragsinfosystem 

IRM-Reorganisation Inventurbelege 

J5F-Logische DB für neue Nota-Fiscal-Datenbank 

K1V-Konditionen: Generieren 

KDF-DATENBANK KREDITOR 

KIV-Kunden-Material-Info- 

KKF-Kontokorrent Kontenschreibung 

KLF-Klassische Kontenschreibung 

KMV-SD Belege für Kreditlimit 

KOV-Selektion von Konditionssätzen 

L1L-Auswertung Lagerbelege 

L1M-Lagerbewegungen zum Material 

LMM-Lagerbewegungen zum Material 

LNM-Lagerbewegungen 

LO_CHANGE_MNMT- Logische Datenbank für 

Änderungsdienst 

MAF-Datenbestand für Mahnungen 

MIV-BC: geplante Flüge, Flüge und Buchungen 

MRM-Reorganisation Materialbelege 

MSM-Materialstamm 

NTI-Logische Datenbank Objektvernetzung 

ODC-Shop floor control - Aufträge zum 

Disponenten- 

ODK-Aufträge- 

OFC-Shop floor control - Aufträge zum FertSteuerer 

OHC-Shop floor control - Aufträge nach Nummern 






14 

OPC-Shop floor control - Aufträge zum Material 

PAK-CO-PA Objektebene und Einzelposten 

PAP-Bewerberstammdaten 

PCH-PD 

PGQ-QM: Vorgaben und Ergebnisse der 

Qualitätsprüfung 

PMI-Strukturdatenbank Instandhaltung- 

PNI-PM Plan-Datenbank 

PNM-Plan-Datenbank 

PNP-RP-STAMM- 

POH-Datenbank Fertigungsaufträge - Kopf 

PSJ-Projektsystem 

PTRVP Reisemanagement 

PYF-Datenbank für Zahlungsträgerdruckprogramme 

QAM-Prüfkataloge: Auswahlmengen 

QAQ-Prüfkataloge: Auswahlmengen 

QCM-Prüfkataloge: Codes- 

QCQ-Prüfkataloge: Codes- 

QEM-Ergebnisserfassung 

QMI-Logische Datenbank PM-Meldungen- 

QMQ-Prüfmerkmale 

QNQ-Qualitätsmeldungen 

QTQ-Logische Datenbank für Prüfmethoden 

R0F-Archivierung: Bankstammdaten 

R0L-Auslesen Archiv: Transportaufträge (MM-WM) 

R1F-Archivierung: FI Verkehrszahlen- 

R1L-Auslesen Archiv: Transportbedarfe (MM-WM) 

R2L-Auslesen Archiv: Umbuchungsanweisungen 

(MM-WM) 

R3L-Auslesen Archiv: Inventuraufnahmebelege 

(MM-WM) 

R4L-Auslesen Archiv: Inventurhistorien (MM-WM) 

RBL-Archivierung Transportbedarfe 

RHL-Archivierung Inventurhistorie 

RIL-Archivierung Inventur-Aufnahmebelege 

RKM-Reservierungen zur Kontierung 

RMM-Reservierungen zum Material 

RNM-Reservierungen 

RTL-Archivierung Transportaufträge 

RUL-Archivierung Umbuchungsanweisungen 

S1L-Bestände nach Lagerplätzen 

S2L-Lagerquant zum Material 

S3L-Bestände- 

SAK-Vollständig stornierte Allocations-Belege 

SDF-SACHKONTENDATENBANK- 

SD_KUSTA Logische Datenbank zum 

Kundenstammblatt 

SD_ORDER Logische Datenbank für Angebote, 

Kontrakte 

SD_SALES_DOCUMENT Logische Datenbank für 

Angebote, Kontrakte 

SMI-Serialnummernverwaltung 

T1L-Transportaufträge nach Nummer 

T2L-Transportaufträge zum Material 

T3L-Transportaufträge zum Lagertyp 

T4L-Transportauftrag zum TA-Druck 

T5L-Transportaufträge zur Referenznummer 

TAF-Treasury- 

TIF-Treasury Informationssystem 

TPI-Logische Datenbank Technischer Platz 

U1S-Reorg Benutzerstamm: Kennwortänderungen 




V12L Konditionsliste 

VAV-Logische Datenbank RV: Verkaufsbelege 

VC1-Liste Kontakte 

VC2-Erzeugen Adressbestand 

VDF-Debitorendatenbank mit View über 

Belegindex- 

VFV-Logische Datenbank RV: Fakturen- 

VLV-Logische Datenbank Lieferungen 

VXV-SD: Faktura Export 

WAF-Wertpapier-Bestand plus zusätzlicher 

Stammdaten 

WOI-Wartungsposition 

WPI-Wartungspläne 

WTF-Bestände und Bewegungen Wertpapiere 

WUF-WP-Stammdaten zu Beständen ermitteln 

Z01-Erste logische DB 

Z01B zweite log DB 

Z03-Logische Datenbank von NL 

Z03NEUNeue log. Datenbank von NL (16.6.2k) 

Z07-neue logische Datenbank 

Z07B jpn 

Z08-bdv uebung3 erste logische DB 

Z09JA Logischedatenbank 

ZAHA Erste logische Datenbank 

ZRULODB1 Logische Datenbankt zu Übungsblatt 3 

Aufgabe1- 

__S-Verarbeitung ohne Datenbank 

-------------------------------------------------------------------- 






15 

Abbildung 10: Beispiel Auswahl der Logischen Datenbank Disposition (MDKP) 

Nach Auswahl der Logischen Datenbank „Disposition (MDKP)“ können über den 

button Tabellenfelder die Felder direkt angezeigt werden, wie dies die Abbildung 

oben zeigt. Die Tabellenfelder sind in dem zweiten Fenster zu sehen. 

Sinnvoll ist es, die Auswahl der für eine Gruppe relevanten Tabellen vorzubereiten. 

Dies kann auch über das Data Dictionary geschehen (Werkzeuge ? Workbench ? 

Pull Down Menue oder Button Data Dictionary, Eingabe des Tabellennamens). Die 

nachfolgende Abbildung zeigt die Auswahl und Anzeige der Tabelle über das Data 

Dictionary. Es können hier weitere Such- und Strukturierungshilfsmittel des Data 

Dictionaries genutzt werden. 






16 

3.4. Darstellung von Tabellen über Data Dictionary und 

Datenmodell 

Abbildung 11: Darstellung der Tabelle MDTB über das Data Dictionary (Werkzeuge ? 

Workbench ? Pull Down Menue oder Button Data Dictionary, Eingabe des 

Tabellennamens) 

Ein noch effizienteres Hilfsmittel, wenn es darum geht, die Abhängigkeiten der 

Datenstrukturen zu erkennen ist das Datenmodell. 

Abbildung 12: Einstieg in das Datenmodell über die Workbench-Funktion Entwicklung - Data 

Modeler (Werkzeuge ? Workbench ? ...) 






17 

Über die Auswahl Anwendungsarchitektur erhält man eine Übersicht über die 

unterschiedlichen enthaltenen Architekturkomponenten. Über die Auswahl 

Funktionen kann man systematische über die Funktionen der unterschiedlichen 

Module systematisch selektieren. Der Bereich der Disposition findet sich unter der 

Produktionsplanung und –steuerung (siehe Abbildung). 

Abbildung 13: Auswahl des Datenmodells im Bereich Disposition über MM 

Produktionsplanung 






18 

Abbildung 14: Eintität Disponentengrupe 

Über die Entität Disponentengruppe wiederum kann man über die Vielzahl von 

Auswahl oder Verzweigungsfunktionen entweder in das Data Dictionary verzweigen 

oder sich die Zusammenhänge grafisch anzeigen lassen. 






19 

Abbildung 15: Grafische Darstellung des Datenmodells mit ausgehenden Beziehungen zu 

Disponentengruppe eingeblendet 

In gleicher Weise lassen sich die eingehenden Beziehungen darstellen 






20 

Abbildung 16: Grafische Darstellung des Datenmodells mit eingehenden Beziehungen zu 

Disponentengruppe eingeblendet 

Man kann nun wiederum einzelne Entitätstypen durch Doppelklick auswählen und 

wiederum grafisch über eingehende und ausgehende Beziehungen 

weiterverzweigen. Die detaillierter Darstellung der Nutzung des Data Dictionaries und 

des Datenmodells erfolgt an anderer Stelle. 






21 

Abbildung 17: Darstellung des Entitätstyps Disponentengruppe 

Der Klick auf Data Browser liefert die Informationen über die dazugehörige Tabelle 

(T024D). 

Doppelklick auf die Tabelle wiederum führt zur Anzeige der Tabelle T024D. 






22 

Abbildung 18: Darstellung der Tabelle T024D 






23 

Abbildung 19: Grafische Darstellung der Tabelle MDTB über das Data Dictionary 

Über den Verwendungsnachweise lässt sich der Bezug zu dem jeweiligen 

Entitätstypen herstellen. 






24 

Abbildung 20: Verbindung der MDTB zum Entitätstypen 






25 

Abbildung 21: Anzeige der Verwendung der Tabelle MDTB in Programmen und Entitätstypen 






26 

Abbildung 22: Entitätstyp Dispositionslistenposition 






27 

Abbildung 23: Die Darstellung der eingehenden und ausgehenden Beziehungen der 

Dispositionslistenposition zeigt wie schnell die Zusammenhänge 

unübersichtlich und nicht mehr darstellbar werden. 






28 

3.5. Query anlegen 

Abbildung 24: Query anlegen Einstieg 

Fehlermeldung Sachgruppe eingeben/fehlende Sachgruppe 

Anlegen von Sachgruppen 

Abbildung 25: Query Parameter anlegen 






29 

3.6. Logische Datenbanken und Tabellen den Sachgruppen 

zuordnen 

Abbildung 26: Anlegen von Sachgruppen und Zuordnen von Datenbank-Feldern 

Folgebild Query, Felder anlegen, automatisch erscheint das zugeordnete 

Sachgebiet, Sachgruppe und die ausgewählten Felder 






30 

3.7. Sachgruppenauswahl, Feldauswahl und Aktivieren von 

Feldern für eine Query 

Abbildung 27: Auswahl der Sachgruppe in einer Query 

Auswahl von weiter ? führt zu dem nächsten Bildschirm. 






31 

Abbildung 28: Feldauswahl im Rahmen der Erstellung einer Query 

Abbildung 29: Aktivieren von Feldern für die Query 






32 

3.8. Grundliste definieren 

Abbildung 30: Aufbau der Grundliste einer Query 






33 

3.9. Ausführen der Query 

Abbildung 31: Ausführen einer Query 






34 

Abbildung 32: Ausgabe der Query 






35 

4. Anhang 

4.1. Tabellenumsetzung für SAP Query 

Voraussetzung für die Nutzung der Query ist nach dem Release 4.0 eine 

durchzuführende Tabellenumsetzung 

1.1.3 Suche der Release Info über Freitextsuche in den Release-Hinweisen 

Abbildung 33: Suche in den Release Informationen 






36 

Abbildung 34: Release Hinweise zu Query 






37 

1.1.4 Ausführen der Reports zur Umsetzung 

System ? Dienste ? Reporting ? Report ausführen ... 

Ausführen folgender Reports 

RSAQSUMM (altes Inhaltsverzeichnis kopieren) 

RSAQUM40 (alles Umsetzen) 

RSAQSUMM (neues Inhaltsverzeichnis erstellen) 

Abbildung 35: Kopieren des Inhaltsverzeichnisses 






38 

Abbildung 36: Ausführen Report RSAQUM40 

Abbildung 37: Umsetzen der Objekte zu Release 4.0 






39 

Abbildung 38: Fehlermeldung zur Umsetzung 






40 

1.1.5 Release Info Text zur SAP Query: Tabellenumsetzung als Voraussetzung 

zur Nutzung der ABAP Workbench 

-Kurztext 

Umsetzung von Tabellenänderungsprotokollen 

-Beschreibung 

- Die Änderungen von Tabelleninhalten können protokolliert werden. Dies ist 

- in erster Linie für Customizing-Tabellen gedacht. Wenn Sie eine Tabelle 

- für die Erstellung von Tabellenänderungsprotokollen vorsehen wollen, 

- müssen Sie das entsprechende Flag in den technischen Einstellungen der 

- Tabelle setzen. Außerdem muß der Profilparameter rec/client gesetzt sein. 

- Die Protokolle werden ab Release 4.0 in der Tabelle DBTABLOG abgelegt. 

- Die vor Release 4.0 verwendete Tabelle DBTABPRT wird nicht mehr 

- unterstützt. Die Archivierung und Auswertung der Protokolle ist nur noch 

- für Einträge in der neuen Tabelle möglich. Daher müssen Sie, sofern Sie 

- mit alten Daten arbeiten wollen, diese aus der Tabelle DBTABPRT in die 

- Tabelle DBTABLOG umsetzen. 

- Die Umsetzung wird mit dem Report RSDBLOGCONV40 durchgeführt. Bei der 

- Umsetzung können Sie zwischen einer kompletten Umsetzung oder einer 

- Umsetzung eines bestimmten Zeitraums wählen. 

- Nach der erfolgreichen Umsetzung werden die umgesetzten Protokolle aus 

- der Tabelle DBTABPRT gelöscht. 

-Einfluß auf den Datenbestand im Fehlerfall 

- Da die Datensätze aus der Tabelle DBTABPRT zuerst nach erfolgreichem 

- Umsetzen gelöscht werden, kommt es beim Abbruch des Reports zu keinem 

- Datenverlust. Im Fehlerfall muß der Report nur neu gestartet werden. 

-Weitere Hinweise 

- Da bei umfangreichen Datenbeständen der Tabelle DBTABPRT lange Laufzeiten 

- des Reports zu erwarten sind, sollte dieser nur im Batch-Betrieb 

- gestartet werden. 

- Der Report wird mit zwei Reportvarianten ausgeliefert: 

- o Die erste Variante dient zur kompletten Umsetzung der Tabelle 

DBTABPRT. 

- o Die zweite Variante dient als Kopiervorlage für eigene Varianten, wenn 

ein bestimmter Zeitraum umgesetzt werden soll. 

- Technische Details zum Report (z.B. Ressourcenbelastung) entnehmen Sie 

- der Reportdokumentation. 

- Die Archivierung der Tabellenänderungsprotokolle wurde ab Release 4.0 auf 

- die zentrale Archivierung im R/3 über die Transaktion SARA umgestellt. 

- Das dafür vorgesehene Archivierungsobjekt heißt BC_DBLOGS. 

Ganz zurück-> 






41 

- Anwendung 






42 

Umsetzung ABAP-Query 

-Beschreibung 

Mit Release 4.0A werden in der ABAP Query eine Reihe von Erweiterungen 

und Verbesserungen wirksam, die in der folgenden Übersicht aufgeführt 

sind. 

1. Arbeitsbereiche 

2. Namensraum 

3. Neuerungen bei der Pflege von Queries 

-- Zählung des Auftretens eines Feldes im Datenbestand 

-- Neue Bedeutung der Dynamikoption im Grafikbild 

-- Festlegung der Ausgabereihenfolge der Teillisten 

-- Variantenpflege 

4. Neuerungen in Query-Listen 

-- Änderung in der Belegung der Funktionstasten 

-- Dynamischer Aufruf der Grafik und Restwerte 

5. Neuerungen bei der Pflege von Sachgebieten 

-- Neue Pflegetransaktion 

-- Alias-Tabellen 

-- Option 'intern puffern' für Zusatztabellen 

-- Funktion Abgleichen 

6. Neuerungen bei der Pflege von Benutzergruppen 

7. Neuerungen bei Transporten 

-- Transporte von Objekten des globalen Bereiches 

-- Transporte von Objekten des Standardbereiches 

-- Transport von Objekten (Kopieren) zwischen Arbeitsbereichen 

8. Neuerungen beim Sprachabgleich 

-- Standardtexte für Sachgebiete 

Arbeitsbereiche 

Zu Release 4.0A werden die Möglichkeiten der Query zur Entwicklung von 

Reports durch die Einführung sogenannter Arbeitsbereiche wesentlich 

verbessert. Zur Erläuterung des Begriffs 'Arbeitsbereich' sollen zunächst 

einige wichtige Merkmale der bisherigen Lösung zusammengefaßt werden. 

Bisher wurden alle Query-Objekte (Queries, Sachgebiete, Benutzergruppen) 

pro Mandant angelegt und verwaltet. Innerhalb eines Mandanten standen 

diese Objekte untereinander in Beziehung und bildeten einen in sich 

abgeschlossenen und konsistenten Datenbestand. Query-Objekte waren nicht 

an den Workbench Organizer angeschlossen, d.h. sie konnten nicht über das 

übliche Korrektur- und Transportverfahren erfasst und transportiert 

werden. 

Diese Arbeitsweise hat dann Vorteile, wenn Endbenutzer in ihren Mandanten 

eigene Queries (ad-hoc-Berichte) entwickeln wollen, die nicht für eine 

systemweite Verwendung gedacht sind. Bei der Entwicklung von Queries, die 

zentral in allen Mandanten und in verschiedenen Systemen verwendet werden 

sollen, hat diese Arbeitsweise jedoch einige Nachteile. Insbesondere wäre 

in solchen Fällen ein Anschluß an den Workbench Organizer zweckmäßig, um 

das Anlegen und Ändern von Query-Objekten in der üblichen Art 

registrieren zu lassen und die Transportmöglichkeiten des Workbench 

Organizers zu nutzen. Zwar ist der Transport von Query-Objekten auch 

bisher möglich, er erfordert jedoch eine manuelle Vor- und Nachbereitung 

(Export und Import mit Hilfe des Transportwerkzeuges der Query). Dieser 

Nachteil machte sich auch bei Query-Objekten, die von SAP ausgeliefert 






43 

wurden, bemerkbar: die bisher von SAP ausgelieferten 

Transportdatenbestände mußten manuell in jeden Mandanten importiert 

werden, in dem sie genutzt werden sollen. 

Durch das Konzept der Arbeitsbereiche werden diese Nachteile vermieden. 

Ein Arbeitsbereich umfaßt eine Menge von Query-Objekten, die in sich 

abgeschlossen und konsistent sind. In diesem Sinne verfügt die Query 

bisher über genau einen Arbeitsbereich, in dem die Query-Objekte 

mandantenabhängig abgelegt sind und die nicht an den Workbench Organizer 

angeschlossen sind. An den Eigenschaften dieses Arbeitsbereiches hat sich 

nichts geändert. Das heißt: 

Für einen Endbenutzer, der in diesem Arbeitsbereich arbeitet, ändert sich 

nichts. Er kann in der bisher gewohnten Weise weiter arbeiten. Die neuen 

Möglichkeiten der einzelnen Pflegekomponenten (siehe unten) stehen ihm 

selbstverständlich zur Verfügung. Dieser bisherige Arbeitsbereich wird 

'Standardbereich' genannt. 

Ab Release 4.0A existiert ein weiterer Arbeitsbereich. Dieser 

Arbeitsbereich wird als 'Globaler Bereich' bezeichnet und hat folgende 

Eigenschaften: 

Alle Query-Objekte im globalen Bereich sind mandantenunabhängig. Sie sind 

deshalb systemweit, d.h. in allen Mandanten verfügbar. Außerdem sind 

diese Objekte an den Workbench Organizer angeschlossen. Sie können 

deshalb mit dem üblichen Korrektur- und Transportverfahren erfaßt und 

transportiert werden. Beim Transport sind keine manuellen Aktionen zur 

Vor- bzw. Nachbereitung mehr notwendig. Der globale Arbeitsbereich eignet 

sich deshalb zur Entwicklung von Queries, die als zentral verwendbare 

Objekte entwickelt und verteilt werden sollen. Auch die von SAP ab 

Release 4.0 ausgelieferten Query-Objekte liegen in diesem Bereich. 

Der globale Bereich umfaßt genauso wie der Standardbereich eine in sich 

abgeschlossene und konsistente Menge von Query-Objekten. Zwischen den 

Objekten verschiedener Arbeitsbereiche sind keine Beziehungen möglich. Es 

ist also z.B. nicht möglich, im Standardbereich eine Query über einem 

Sachgebiet aus dem globalen Bereich anzulegen. Der Austausch von 

Query-Objekten zwischen den Arbeitsbereichen erfolgt über ein spezielles 

Kopierverfahren. Jeder Arbeitsbereich bildet bezüglich seiner 

Query-Objekte einen in sich abgeschlossenen Namensraum, d.h. innerhalb 

der verschiedenen Arbeitsbereiche können Objekte mit gleichem Namen, aber 

unterschiedlicher Bedeutung existieren. 

Der Wechsel zwischen den Arbeitsbereichen ist in jeder Komponente zur 

Pflege von Query-Objekten über die Funktion Umfeld -> Arbeitsbereiche 

möglich. Es erscheint ein Fenster, in dem die beiden Arbeitsbereiche mit 

ihrem Langtext aufgelistet sind. Mit der Funktion Auswählen kann der 

gewünschte Arbeitsbereich ausgewählt werden. Der globale Bereich wird auf 

dem Einstiegsbild der Pflegekomponente ausgewiesen, der Standardbereich 

dagegen nicht. In jedem Arbeitsbereich ist die Funktionalität der 

Pflegekomponenten gleich, d.h. alle bisher vorhandenen und alle neuen 

Funktionen stehen in beiden Arbeitsbereichen zur Verfügung. 

Auf dem Fenster zur Auswahl des Arbeitsbereiches können mit der Funktion 

Information die technischen Angaben zu einem Arbeitsbereich angezeigt 

werden. Diese Anzeige enthält neben dem Langtext die Angaben, ob die 

Query-Objekte mandantenabhängig abgelegt werden und ob ein Anschluß an 

den Workbench Organizer existiert. 

Wie bereits erwähnt, stehen in jedem Arbeitsbereich alle Funktionen zur 

Pflege von Query-Objekten zur Verfügung. Da der globale Arbeitsbereich an 

den Workbench Organizer angeschlossen ist, muß beim Anlegen von 

Query-Objekten eine Entwicklungsklasse vergeben werden. Hier besteht die 

Möglichkeit, ein Objekt als lokales Objekt (temporäre Entwicklungsklasse, 

insbesondere $TMP) zu vereinbaren, was dem bisher üblichen Fall bei 

Query-Objekten entspricht. Bei der Vergabe und Änderung von 

Entwicklungsklassen existieren allerdings einige Einschränkungen. 

1. Alle Query-Objekte im globalen Bereich müssen einer Entwicklungsklasse 






44 

-(einschließlich temporärer Entwicklungsklassen) zugeordnet werden. Ist 

-diese Entwicklungsklasse nicht temporär, so muß das Objekt beim 

-Anlegen bzw. Ändern in einem Korrekturauftrag erfaßt werden. 

2. Benutzergruppen und Sachgebiete können beliebigen Entwicklungsklassen 

-zugeordnet werden. 

3. Queries können nur dann einer nicht temporären Entwicklungsklasse 

-zugeordnet werden, wenn die betreffende Benutzergruppe und das 

-zugeordnete Sachgebiet ebenfalls in einer nicht temporären 

-Entwicklungsklasse liegen. Falls beim Anlegen einer Query festgestellt 

-wird, daß entweder das zugeordnete Sachgebiet oder die zugeordnete 

-Benutzergruppe in einer temporären Entwicklungsklasse liegen, so wird 

-der Query automatisch die Entwicklungsklasse $TMP zugeordnet. In 

-diesem Fall erfolgt kein Dialog, um die Entwicklungsklasse 

-festzulegen. 

Zur Vereinfachung wird empfohlen, Benutzergruppen und Sachgebiete im 

globalen Bereich immer einer nicht temporären Entwicklungsklasse 

zuzuordnen. Dann kann für jede Query eine beliebige Entwicklungsklasse 

ausgewählt werden. 

Ein Wechsel der Entwicklungsklasse kann in den Komponenten zur Pflege der 

verschiedenen Query-Objekte über die Funktionen Query -> Weitere 

Funktionen -> Entwicklungsklasse wechseln, Sachgebiet -> Weitere 

Funktionen -> Entwicklungsklasse wechseln bzw. Benutzergruppe -> 

Entwicklungsklasse wechseln vorgenommen werden. Entsprechend den oben 

formulierten Regeln zur Vergabe von Entwicklungsklassen gelten jedoch 

folgende Einschränkungen: 

1. Bei Benutzergruppen ist ein Wechsel von einer nicht temporären 

-Entwicklungsklasse in eine temporäre Entwicklungsklasse nur sinnvoll, 

-wenn alle Queries der Benutzergruppen in einer temporären 

-Entwicklungsklasse liegen. 

2. Bei Sachgebieten ist ein Wechsel von einer nicht temporären 

-Entwicklungsklasse in eine temporäre Entwicklungsklasse nur sinnvoll, 

-wenn alle Queries über diesem Sachgebiet in einer temporären 

-Entwicklungsklasse liegen. 

3. Bei Queries ist ein Wechsel von einer temporären Entwicklungsklasse in 

-eine nicht temporäre Entwicklungsklasse nur sinnvoll, wenn das 

-zugeordnete Sachgebiet und die Benutzergruppe in einer nicht 

-temporären Entwicklungsklasse liegen. 

Die Funktionen Entwicklungsklasse wechseln der verschiedenen Komponenten 

zur Pflege von Query-Objekten prüfen zunächst, ob ein beliebiger Wechsel 

möglich ist und geben eine Warnung aus, falls dies nicht der Fall ist. 

Anschließend kann der Wechsel der Entwicklungsklasse vorgenommen werden. 

Aus technischen Gründen ist es hierbei auch möglich, einen Wechsel 

vorzunehmen, der den oben genannten Einschränkungen widerspricht. Deshalb 

wird anschließend überprüft, ob ein unzulässiger Wechsel vorgenommen 

wurde. In diesem Fall wird eine Meldung ausgegeben, daß dieser Wechsel 

wieder rückgängig gemacht werden sollte. Falls dies nicht erfolgt, 

besteht die Gefahr, daß nach Transporten in Folgesystemen inkonsistente 

Datenbestände auftreten. 

Zu beachten ist weiterhin, daß ein Wechsel der Entwicklungsklasse nicht 

mehr möglich ist, wenn ein Objekt in einer nicht temporären 

Entwicklungsklasse liegt und bereits transportiert wurde. Der Wechsel von 

Entwicklungsklassen in der oben beschriebenen Art ist deshalb nur bei 

Objekten möglich, die noch nicht transportiert wurden 

Ein Wechsel der Entwicklungsklasse kann auch erforderlich sein, wenn ein 

Query-Objekt umbenannt werden soll. Wenn eine Benutzergruppe oder ein 

Sachgebiet durch Umbenennen in einen Namensraum (vgl. den folgenden 

Abschnitt) eingeordnet werden soll, ist es erforderlich, daß die 






45 

Entwicklungsklasse ebenfalls in diesem Namensraum liegt. In diesem Fall 

muß während des Umbenennens auch eine passende Entwicklungsklasse gewählt 

werden. Im Fall von Benutzergruppen müssen dann auch die Queries der 

Benutzergruppen in neue Entwicklungsklassen eingeordnet werden. 

Alle Query-Objekte im globalen Bereich, die in einer nicht temporären 

Entwicklungsklasse liegen, müssen beim Anlegen bzw. Ändern in einem 

Korrekturauftrag erfaßt werden. Eine Ausnahme bilden Änderungen, die den 

Charakter von Customizing-Einstellungen haben. Deshalb können Änderungen 

bei der Zuordnung von Benutzern zu Benutzergruppen bzw. bei der Zuordnung 

von Sachgebieten zu Benutzergruppen vorgenommen werden, ohne daß diese 

Änderungen in einem Korrekturauftrag erfaßt werden. Bei Transporten mit 

Hilfe des Workbench Organizers wird die Zuordnung von Sachgebieten zu 

Benutzergruppen mit transportiert, die Zuordnung von Benutzern zu 

Benutzergruppen dagegen nicht. Näheres ist im Abschnitt über die 

Neuerungen bei Transporten beschrieben. 

Zu den Änderungen von Query-Objekten im globalen Bereich gehören auch 

solche Funktionen wie Kopieren, Umbenennen, Löschen, Abgleichen, 

Generieren usw. Bei der Funktionen Umbenennen für Sachgebiete und 

Benutzergruppen ist zu beachten, daß neben dem umzubenennenden Sachgebiet 

bzw. der umzubenennenden Benutzergruppe auch alle abhängigen Queries 

geändert werden müssen. Sollen ein Sachgebiet oder eine Benutzergruppe 

umbenannt werden, so müssen in der Regel neben dem Sachgebiet bzw. der 

Benutzergruppe auch eine Reihe von Queries in einem Korrekturauftrag 

erfaßt werden. Das Umbenennen wird erst dann durchgeführt, wenn alle 

erforderlichen Objekte in einem Korrekturauftrag erfaßt sind. 

Der Austausch (Kopieren) von Query-Objekten zwischen den verschiedenen 

Arbeitsbereichen erfordert ein besonderes Verfahren, da jeder 

Arbeitsbereich bezüglich seiner Query-Objekte einen in sich 

abgeschlossenen und konsistenten Datenbestand bildet. Beim Austausch muß 

deshalb sichergestellt werden, daß das in einen Arbeitsbereich 

übertragene Objekt konsistent in diesen Datenbestand eingefügt werden 

kann. Betrachtet man den neu eingeführten globalen Bereich als einen 

speziellen Mandanten, so zeigt sich, daß das bisher unterstützte 

Transportverfahren für Query-Objekte aus dem Standardbereich genau die 

Funktionalität besitzt, die für einen solchen Austausch notwendig ist. 

Das Kopieren eines Objektes vom Standardbereich in den globalen Bereich 

bzw. umgekehrt entspricht dem Transport eines Objektes von einem 

Mandanten in einen anderen. Aus diesem Grund wird das Kopieren von 

Query-Objekten zwischen den Arbeitsbereichen über eine Erweiterungen des 

bisherigen Transportverfahrens realisiert. Näheres dazu ist im Abschnitt 

über Neuerungen bei Transporten beschrieben. Es folgt jedoch aus dieser 

Art der Realisierung unmittelbar, daß der Austausch von Query-Objekten 

zwischen den Arbeitsbereichen nur von einem Nutzer vorgenommen werden 

kann, der die Berechtigung hat, Transporte durchzuführen (Berechtigung 

zur Pflege von Sachgebieten und Benutzergruppen). 

Namensraum 

Zu Release 4.0 wird für Objekte wie Programme, Tabellen, Datenelementen 

usw. ein erweiterter Namensraum eingeführt, durch den ersten längere 

Namen gebildet werden können und zweitens eine saubere Trennung zwischen 

SAP-Objekten und Kundenobjekten möglich ist. Auch für Query-Objekte 

(Queries, Sachgebiete, Benutzergruppen) wird ein solcher erweiterter 

Namensraum eingeführt. Für Query-Objekte können damit längere Namen und 

Namenspräfixe verwendet werden. Ein Namenspräfix wird durch '/präfix/' 

gebildet und dem eigentlichen Objektnamen vorangestellt. Die 

einschließenden Zeichen / gehören zum Präfix. Ein Präfix kann 

einschließlich der Zeichen / höchstens 10 Zeichen lang sein. 

Im einzelnen gilt: 

1. Sachgebietsnamen haben die Form '/präfix/sachgebiet'. 

-Der Präfix kann entfallen. Der gesamte Name eines Sachgebietes 






46 

-einschließlich Präfix kann 24 Zeichen lang sein. 

2. Namen von Benutzergruppen haben die Form '/präfix/benutzergruppe'. 

-Der Präfix kann entfallen. Der gesamte Name einschließlich Präfix kann 

-12 Zeichen lang sein. 

3. 3. Query-Namen haben die Form 'query'. 

-Query-Namen besitzen keinen eigenen Präfix, sondern erben den Präfix 

-ihrer Benutzergruppe. Der Name einer Query darf 14 Zeichen lang sein. 

4. Präfixe dürfen nur bei Sachgebieten und Benutzergruppen im globalen 

-Bereich verwendet werden, da die korrekte Verwendung von Präfixen 

-durch den Workbench Organizer kontrolliert wird. 

In den entsprechenden Transaktionen zur Pflege von Query-Objekten wird 

die oben beschriebene Syntax der Namen überprüft. Die Arbeit mit 

Namenspräfixen ist für Query-Objekte nur im globalen Arbeitsbereich 

erlaubt und von Bedeutung, da in diesen Bereich beim Put ggf. 

Query-Objekte von SAP eingespielt werden. Die von SAP ausgelieferten 

Query-Objekte besitzen den reservierten Namenspräfix '/SAPQUERY/'. 

Bei der Verwendung von Präfixen im globalen Bereich ist zu beachten, daß 

das Objekt, dessen Namen mit einem Präfix beginnt, in einer 

Entwicklungsklasse liegen muß, die den gleichen Präfix besitzt. Diese 

Bedingung wird durch den Workbench Organizer überprüft. 

Die Tatsache, daß Queries den Präfix ihrer Benutzergruppe erben, muß 

insbesondere beachtet werden, wenn Queries in einer Benutzergruppe 

angelegt werden sollen, deren Präfix der SAP, einem Partner oder einem 

anderen R/3-Kunden gehört. Solche Benutzergruppen können über einen Put 

oder einen anderen Transport in das System gelangen. Die Query ist dann 

ein Bestandteil der Objekte, die sich in dem Namenraum befinden, der 

durch den Präfix der Benutzergruppe festgelegt ist. 

Wird zum Beispiel eine Query in einer Benutzergruppe '/SAPQUERY/xx' 

angelegt, so erbt diese Query den Präfix '/SAPQUERY/'. Sie gehört damit 

praktisch zu den von SAP ausgelieferten Objekten. Deshalb besteht die 

Gefahr, daß beim nächsten Put diese Query überschrieben wird. 

Es wird deshalb empfohlen, in solchen Benutzergruppen keine neuen Queries 

anzulegen, sondern dafür eigene Benutzergruppen zu verwenden. 

Die Einführung der Arbeitsbereiche und des Namensraums erfordern ein 

neues Verfahren bei der Vergabe der Namen der generierten Query-Reports. 

Ab Release 4.0 wird der Name eines Query-Reports wie folgt gebildet: 

-AQmmbbbbbbbbbbbbqqqqqqqqqqqqqq 

Dabei bedeuten: 

AQ 

mm Mandant verschlüsselt (Standardbereich) oder 

ZZ (Globaler Bereich) 

bbbbbbbbbbbb Name der Benutzergruppe 

qqqqqqqqqqqqqq-Name der Query 

Leerzeichen im Reportnamen werden durch = ersetzt. Die Query TEST der 

Benutzergruppe USER1 in globalen Bereich erzeugt deshalb den Report: 

-AQZZUSER1=======TEST========== 

Alle Query-Reports liegen wie bisher in der Entwicklungsklasse $TMP und 

können deshalb nicht transportiert werden. Dies gilt auch für Queries aus 

dem globalen Bereich, die in einer nicht temporären Entwicklungsklasse 

liegen. 






47 

Neuerungen bei der Pflege von Queries 

-Zählung des Auftretens eines Feldes im Datenbestand 

Mit Release 4.0A wird innerhalb von Grundlisten die neue Option 

angeboten, das Auftreten eines Feldes im gelesenen Datenbestand zu 

zählen. Die Wirkung dieser Option läßt am einfachsten durch einen 

Vergleich mit der Option 'Summe' erklären. 

Die Option 'Summe' bewirkt für ein numerisches Feld, daß die Gesamtsumme 

des Feldes gebildet wird. Das bedeutet, daß jedesmal, wenn das Feld im 

gelesenen Datenbestand gefunden wird, der Wert des Feldes auf die 

Gesamtsumme addiert wird. Die Gesamtsumme wird am Ende der Grundliste 

ausgegeben. Bei Gruppenstufen besteht die Möglichkeit, Zwischensummen 

auszugeben. In eine Zwischensumme gehen alle die Werte des Feldes ein, 

die der Gruppenstufe, d.h. einem bestimmten Sortierbegriff, zugeordnet 

sind. 

Die Option 'Zählen' für ein Feld bewirkt, daß jedesmal, wenn das Feld im 

gelesenen Datenbestand gefunden wird, ein Zähler für dieses Feld um 1 

erhöht wird. Die so gewonnene Gesamtanzahl wird in der gleichen Art und 

Weise wie eine Gesamtsumme am Ende der Grundliste ausgegeben. Analog zur 

Summation besteht auch bei der Zählung die Möglichkeit, bei Gruppenstufen 

die Zwischenwerte der Zählung auszugeben. Ein solcher Zwischenwert 

(Zwischenzählung) gibt an, wieviele Werte des Feldes der Gruppenstufe 

zugeordnet sind. 

Wenn für ein numerisches Feld die Optionen 'Summe' und 'Zählung' gewählt 

werden, entspricht der Zähler der Anzahl der Summanden. Die Option 

'Zählung' kann aber auch für nichtnumerische Felder gewählt werden. 

Um für ein Feld die Zählung einzuschalten, muß auf dem Bild 'Zeilenaufbau 

Grundliste' der entsprechende Auswahlknopf gesetzt werden. Dies bewirkt, 

daß am Ende der Grundliste die Gesamtanzahl der gelesenen Feldwerte 

ausgegeben wird. Wenn für eine Sortierkriterium die Ausgabe der 

Zwischenwerte der Zählung pro Gruppenstufe gewünscht wird, muß auf dem 

Bild 'Gruppenstufen' der entsprechende Auswahlknopf gesetzt werden. Damit 

wird die Option 'Zählung' völlig analog zur Option 'Summe' behandelt. 

-Neue Bedeutung der Dynamikoption im Grafikbild 

In den Bildern zur Definition der Grafikoptionen existiert seit Release 

3.0C die Option 'zur Laufzeit festlegen'. Wurde diese Option gesetzt, so 

bestand zur Laufzeit der Query die Möglichkeit, die Anzahl der 

anzuzeigenden Werte dynamisch festzulegen. Die Bedeutung dieser Option 

wurde zu Release 4.0A erweitert. Sie bedeutet jetzt, daß zur Laufzeit 

alle Angaben für die Grafik dynamisch dargestellt werden können (siehe 

auch Abschnitt über Neuerungen in Query-Listen). Die im Grafikbild 

festgelegten Optionen werden als Vorschlagswerte verwendet. 

Die Option 'zur Laufzeit festlegen' wird ab Release 4.0A standardmäßig 

gesetzt, wenn eine Grundliste, eine Statistik oder eine Rangliste neu 

definiert wird. 

-Festlegung der Ausgabereihenfolge der Teillisten 

Wurden in einer Query mehrere Teillisten (Grundliste, Statistiken, 

Ranglisten) definiert, so wurden diese Teillisten bisher in einer festen 

Reihenfolge in der Liste ausgegeben: zuerst die Grundliste, dann die 

Statistiken (in der Reihenfolge ihrer Definition) und dann die Ranglisten 

(in der Reihenfolge ihrer Definition). In manchen Fällen ist aber eine 

andere Reihenfolge sinnvoll, z.B. zuerst eine Statistik und dann eine 

Grundliste, in der die Einzelwerte auftreten, die in die Statistik 

eingeflossen sind. Eine solche Reihenfolge konnte aber bisher nicht 

vereinbart werden. 

Ab Release 4.0A besteht die Möglichkeit, die Reihenfolge der Teillisten 

explizit zu vereinbaren. Dazu kann die Funktion Bearbeiten -> 






48 

Ausgabereihenfolge verwendet werden. Wird diese Funktion aufgerufen, so 

erscheint ein Fenster, in dem alle bisher definierten Teillisten in der 

Reihenfolge, wie sie ausgegeben werden, aufgeführt sind. Vor jeder 

Teilliste existiert ein Eingabefeld, in das eine Reihenfolgenummer 

zwischen 1 und 90 eingetragen werden kann. Diese Reihenfolgenummer 

bestimmt die Ausgabereihenfolge der Teillisten. Falls keine 

Reihenfolgenummer angegeben wird (das ist die Standardannahme), wird die 

entsprechende Teilliste nach den Teillisten mit einer Reihenfolgenummer 

ausgegeben. 

Falls zwei oder mehrere Teillisten die gleiche oder keine 

Reihenfolgenummer besitzen, so werden diese Teillisten in der Reihenfolge 

ausgegeben, die auch bisher gültig war (Grundliste, Statistiken, 

Ranglisten). 

-Variantenpflege 

Wie bisher können über die Funktion Springen -> Variantenpflege für eine 

Query bzw. den zugeordneten Report Varianten gepflegt werden. Bei Queries 

aus dem globalen Bereich, die einer nicht temporären Entwicklungsklasse 

zugeordnet sind, ist jedoch eine Besonderheit zu beachten. Für solche 

Queries besteht die Möglichkeit, Systemvarianten anzulegen (der Name 

einer Systemvariante beginnt mit SAP& bzw. CUS&, vgl. dazu die 

Dokumentation zu Varianten auf dem Einstiegsbild zur Variantenpflege). 

Die Systemvarianten von Queries sind Transportobjekte des Workbench 

Organizers. Sie müssen deshalb beim Anlegen oder Ändern immer in einem 

Korrekturauftrag erfaßt werden und können mit Hilfe des Workbench 

Organizers transportiert werden. Sie haben weiterhin den Vorteil, in 

allen Mandanten zur Verfügung zu stehen. Sollen also für eine Query im 

globalen Bereich transportierbare Varianten erfaßt werden, so müssen 

immer Systemvarianten verwendet werden. 

Systemvarianten von Queries sind allerdings keine sperrbaren Objekte. Das 

bedeutet, daß nach dem Eintragen einer Systemvariante in einen 

Korrekturauftrag diese Systemvariante auch von Nutzern geändert werden 

darf, die nicht für diese Korrektur eingetragen sind. Bei Freigabe des 

Transportauftrages wird der zu diesem Zeitpunkt vorhandene Stand der 

Systemvariante transportiert. 

Neuerungen in Query-Listen 

-Änderung in der Belegung der Funktionstasten 

Das Aufreißen von verdichteten Grundlisten wurde bisher über die Funktion 

Bearbeiten -> Auswählen Detail realisiert. Diese Funktion lag auf der 

Funktionstaste F2, so daß ein Doppelklick auf eine Zeile einer 

mehrzeiligen Grundliste zum Aufreißen der Grundliste führte, wenn ein 

solches Aufreißen möglich ist. 

Das Aufreißen wird jetzt über die Funktion Bearbeiten -> Detailsicht 

realisiert, die nicht mehr auf der Funktionstaste F2 liegt. Dafür liegt 

die Funktion Springen -> Bericht aufrufen zum Aufruf der 

Berichts-Berichts-Schnittstelle auf der Funktionstaste F2. Ein 

Doppelklick auf eine Zeile führt deshalb zum Aufruf eines weiteren 

Berichtes über die Berichts-Berichts-Schnittstelle, falls die Query als 

Sender in dieser Schnittstelle eingetragen ist. 

-Dynamischer Aufruf der Grafik und Restwerte 

Wird in der Query-Definition für eine Teilliste die Grafikoption 'zur 

Laufzeit festlegen' gewählt (vgl. oben), so können zur Laufzeit der Query 

alle Angaben zur Grafik dynamisch festgelegt werden, also der Grafiktyp, 

die Text- und die Farbdarstellung und die Anzahl der darzustellenden 

Werte. Außerdem besteht die neue Möglichkeit, einen Restwert zur 

grafischen Anzeige zu bringen. Dieser Restwert ist die Summe aller Werte 

der ausgewählten Spalte, die nicht zur grafischen Anzeige ausgewählt 






49 

wurden. Da maximal 32 Werte zur Anzeige gebracht werden können, dürfen 

maximal 31 Einzelwerte ausgewählt werden, wenn der Restwert mit angezeigt 

werden soll. 

Neuerungen bei der Pflege von Sachgebieten 

-Neue Pflegetransaktion 

Mit Release 4.0A wurde die Komponente zur Pflege von Sachgebieten völlig 

neu gestaltet. Das Ziel dieser Umgestaltung war die Verbesserung der 

Benutzerführung und eine bessere Visualisierung der Zusammenhänge 

zwischen Sachgruppen, Tabellen der logischen Datenbank, Zusatztabellen 

und Zusatzfeldern. 

In der neuen Pflegetransaktion wurde auch die Funktionalität erweitert. 

Auf diese neue Funktionalität wird weiter unten gesondert eingegangen. Im 

folgenden wird zunächst beschrieben, wie die bisherige Funktionalität 

realisiert wurde. 

Das Einstiegsbild der Komponente wurde um eine Übersicht über die 

vorhandenen Sachgebiete erweitert. Die Auswahl eines Sachgebietes kann 

über die Markierung der entsprechenden Zeile erfolgen und entspricht 

damit dem Auswahlverfahren, das auch in der Komponente zur Pflege von 

Queries verwendet wird. 

Außerdem kann für jedes Sachgebiet über die Funktion Zusätze -> 

Statusinfos ein Action-Log ausgegeben werden. Es erscheint ein Fenster, 

in dem der Autor und die letzten 10 Änderer des Sachgebietes 

einschließlich des entsprechenden Datums angezeigt werden. 

Beim Anlegen eines Sachgebietes werden wie bisher das Bild 'Titel und 

Datenbank' sowie ggf. die Bilder zur Definition eines Tabellen-Joins 

durchlaufen. Diese Bilder wurden unverändert und mit der gleichen 

Funktionaltät übernommen. Bei der Definition eines Tabellen-Joins besteht 

jetzt die Möglichkeit, eine Tabelle mehrfach in den Join aufzunehmen. 

Dazu muß allerdings bei jeder erneuten Verwendung der Tabelle ein 

Alias-Name definiert werden. Die Technik der Alias-Namen wird weiter 

unten beschrieben. 

Das bisher als zentrales Pflegebild verwendete dreigeteilte 

Bildschirmbild wurde durch ein neues Bild ersetzt, auf dem das Sachgebiet 

als Baumstruktur dargestellt wird. Der Baum eines Sachgebietes enthält 

stets zwei Teilbäume. 

Der erste Teilbaum enthält die Sachgruppen. Dieser Teilbaum ist flach, 

d.h. alle Sachgruppen sind nebeneinander auf dem gleichen Niveau 

angeordnet. An jede Sachgruppe sind die Felder angehängt, die dieser 

Sachgruppe zugeordnet wurden. 

Der zweite Teilbaum beschreibt die Struktur des zu lesenden 

Datenbestandes. Bei logischen Datenbanken entspricht dieser Teilbaum dem 

Baum der logischen Datenbank und enthält alle Tabellen mit den zwischen 

ihnen definierten hierarchischen Beziehungen. Bei sequentiellen 

Beständen, direktem Lesen und Datenversorgungsprogrammen enthält der 

zweite Teilbaum lediglich die Struktur, über der das Sachgebiet definiert 

ist. Bei einem Tabellen-Join enthält der zweite Teilbaum alle Tabellen 

des Joins. Da ein Join immer wieder eine flache Struktur liefert, sind 

die Tabellen des Joins nebeneinander auf dem gleichen Niveau angeordnet. 

Bei Sachgebieten über logischen Datenbanken aus der Anwendung HR enthält 

der zweite Teilbaum alle Infotypen, die durch den Sachgebietsgenerator in 

das Sachgebiet aufgenommen wurden. Die Infotypen sind ebenfalls 

nebeneinander auf dem gleichen Niveau angeordnet. 

An jede Tabelle im zweiten Teilbaum sind die Felder angehängt, die gemäß 






50 

der Dictionary-Definition zur Tabelle gehören, sowie die Felder der 

Zusatztabellen und die Zusatzfelder, die der Tabelle zugeordnet wurden. 

Die Verwendung eines Strukturbaumes zur Darstellung des Sachgebietes 

bietet etliche Vorteile. Zunächst werden in dieser Darstellung die 

hierarchischen Beziehungen der Tabellen untereinander sichtbar, wie sie 

durch die logische Datenbank definiert werden. Weiterhin können die 

üblichen Funktionen bei Strukturbäumen verwendet werden (Aufreißen, 

Verdichten, Positionieren, usw.). So ist es zum Beispiel möglich, die 

Felder von mehr als einer Tabelle anzuzeigen. Um die Felder einer Tabelle 

anzuzeigen, kann entweder ein Doppelklick auf den Tabellennamen 

ausgeführt werden oder ein Einfachklick auf die rechts neben dem 

Tabellennamen stehende Ikone (hot key). Um die Felder wieder aus der 

Anzeige zu entfernen, ist analog zu verfahren. 

Um eine Sachgruppe (im ersten Teilbaum) anzulegen, muß die Funktion 

Bearbeiten -> Sachgruppe -> Anlegen Sachgruppe aufgerufen werden. Die 

gleiche Funktion wird gerufen, wenn ein Einfachklick auf die Ikone zum 

Anlegen rechts neben der Wurzel des ersten Teilbaums ausgeführt wird. Es 

erscheint dann ein Fenster, in dem eine oder mehrere neue Sachgruppen 

definiert werden können. Wie bisher üblich, muß eine Sachgruppe durch 

Angabe eines Kürzels und eines Langtextes definiert werden. Wurden in dem 

Fenster die erforderlichen Angaben vorgenommen, so kann mit der Funktion 

Weiter auf das rufende Bild zurückgekehrt werden. Die neuen Sachgruppen 

sind jetzt im ersten Teilbaum eingetragen. 

Neben der Funktion zum Anlegen existiert eine Funktion zum Ändern von 

Sachgruppen (Bearbeiten -> Sachgruppe -> Ändern Sachgruppe oder 

Einfachklick auf die entsprechende Ikone rechts neben der Wurzel des 

ersten Teilbaums). Mit dieser Funktion können nur die Langtexte der 

bereits existierenden Sachgruppen geändert werden. Es erscheint ein 

Fenster, in dem diese Änderungen vorgenommen werden können. Ein Anlegen 

oder Löschen von Sachgruppen ist hier nicht möglich. 

Um eine Sachgruppe zu löschen, muß der Cursor im Baum auf die Sachgruppe 

gestellt und die Funktion Bearbeiten -> Sachgruppe -> Löschen Sachgruppe 

aufgerufen werden. Das Löschen einer Sachgruppe bedeutet wie bisher, daß 

die Zuordnung von Feldern zu dieser Sachgruppe verloren geht. 

Für das Verfahren der Zuordnung von Feldern zu Sachgruppen (vgl. unten) 

ist es notwendig, eine Sachgruppe auszuwählen bzw. zu markieren. Im Baum 

wird diese markierte Sachgruppe durch eine gesonderte farbliche 

Darstellung hervorgehoben. Außerdem wird sie im Kopf des Bildes 

ausgewiesen. Zur Markierung einer bestimmten Sachgruppe sind zwei Wege 

möglich: 

o Ist der erste Teilbaum auf dem Bildschirm sichtbar, so kann der Cursor 

-auf den Namen der Sachgruppe gestellt und die Funktion Bearbeiten -> 

-Sachgruppe -> Markieren Sachgruppe oder ein Doppelklick verwendet 

-werden. 

o Ist der erste Teilbaum auf dem Bildschirm nicht sichtbar, weil durch 

-Blättern Teile des zweiten Teilbaums sichtbar gemacht wurden, so muß 

-die Funktion Bearbeiten -> Sachgruppe -> Markieren Sachgruppe 

-verwendet werden. Es erscheint dann ein Fenster mit allen vorhandenen 

-Sachgruppen. In diesem Fenster kann eine Sachgruppe ausgewählt werden. 

In jedem Fall führt die Markierung dazu, daß im Kopf des Bildes die 

markierte Sachgruppe ausgewiesen wird. 

Die Zuordnung eines Feldes an eine bestimmte Sachgruppe erfolgt wie 

bisher über die Zuordnung des Sachgruppenkürzels an das Feld. Allerdings 

kann das Kürzel nicht mehr direkt eingegeben werden. 

Um ein Feld einer Sachgruppe zuzuordnen, muß das Feld zunächst durch 

Aufreißen der entsprechden Tabelle im zweiten Teilbaum sichtbar gemacht 

werden. Jedes Feld wird auf einer Zeile dargestellt, die seinen 

technischen Namen, eine spezielle Ikone, ggf. das Kürzel der zugeordneten 






51 

Sachgruppe und den Langtext des Feldes enthält. Ist ein Feld keiner 

Sachgruppe zugeordnet, so ist kein Sachgruppenkürzel angegeben und die 

Ikone enthält ein Minus-Zeichen (Negativ). Ist das Feld einer Sachgruppe 

zugeordnet, so ist das entsprechende Sachgruppenkürzel angegeben und die 

Ikone enthält ein Plus-Zeichen (Positiv). 

Ein Einfachklick auf die Minus-Ikone führt dazu, daß das Feld der 

markierten Sachgruppe zugeordnet wird, d.h. nach dem Einfachklick ist das 

Kürzel der markierten Sachgruppe eingetragen und aus der Minus-Ikone ist 

eine Plus-Ikone geworden. Ein Einfachklick auf eine Plus-Ikone führt 

dazu, daß die vorhandene Zuordnung zwischen Feld und Sachgruppe aufgelöst 

wird, d.h. anschließend ist kein Sachgruppenkürzel mehr vorhanden und aus 

der Plus-Ikone ist eine Minus-Ikone geworden. Beide Funktionen wirken 

sich auch unmittelbar im ersten Teilbaum für die Sachgruppen aus. Wie 

bisher ist die Auflösung einer Zuordnung zwischen Feld und Sachgruppe nur 

möglich, wenn das Feld noch nicht in Queries verwendet wird. 

Das soeben beschriebene Verfahren zur Zuordnung eines Feldes an eine 

Sachgruppe ermöglicht immer nur die Zuordnung an die markierte 

Sachgruppe. Sollen also Felder an verschiedene Sachgruppen zugeordnet 

werden, so muß zwischendurch jeweils die richtige Sachgruppe markiert 

werden (siehe oben). 

Ist ein Feld einmal einer Sachgruppe zugeordnet und soll die Sachgruppe 

gewechselt werden, so sind zwei Wege möglich. Im ersten Fall wird durch 

einen Einfachklick auf die Plus-Ikone zunächst die Zuordnung zwischen 

Feld und Sachgruppe aufgelöst. Anschließend wird die richtige Sachgruppe 

markiert und durch Einfachklick auf die Minus-Ikone die Zuordnung zur 

markierten Sachgruppe hergestellt. Dieses Verfahren funktioniert aber 

nur, wenn das betreffende Feld noch nicht in Queries verwendet wird. Im 

Falle einer bereits erfolgten Verwendung wird die Auflösung der Zuordnung 

zur Sachgruppe abgelehnt. In diesem Fall muß auf das Bild zur Pflege der 

Texte des Feldes (siehe unten) verzweigt werden. 

Zur Pflege der Texte eines Feldes (Langtext und Überschriften) muß der 

Cursor auf das Feld gestellt und die Funktion Bearbeiten -> Feld ändern 

aufgerufen werden. Die gleiche Wirkung hat ein Doppelklick auf den 

Feldnamen. Es erscheint ein Fenster, auf dem für das ausgewählte Feld die 

Zuordnung zur Sachgruppe, der Langtext und die Überschriften angezeigt 

werden. 

Auf diesem Bild kann für ein Feld, das bereits einer Sachgruppe 

zugeordnet wurde, die Zuordnung an eine andere Sachgruppe vorgenommen 

werden. Dazu muß die Wertehilfe für das Feld, in dem das 

Sachgruppenkürzel angezeigt wird, benutzt werden. 

Die Felder, in denen der Langtext und die Überschriften angezeigt werden, 

sind eingabebereit. Die entsprechenden Texte können durch Überschreiben 

geändert werden. Überschriften können wie bisher mit einer Länge von 30 

Zeichen gepflegt werden. Sie sollten aber nicht länger als die 

Ausgabelänge des Feldes sein, da sie ansonsten bei der Ausgabe in Queries 

abgeschnitten werden. Als Eingabehilfe ist über den Eingabezeilen für die 

Überschriften ein Lineal angegeben. Außerdem wird die Ausgabelänge des 

Feldes angezeigt. 

Pro Tabelle der logischen Datenbank können wie bisher Zusatztabellen, 

Zusatzfelder und ein Coding zum Zeitpunkt GET bzw. zur Satzverarbeitung 

definiert werden. Diese Erweiterungen sind jetzt pro Tabelle 

zusammengefaßt und über die Funktion Springen -> Zusätze erreichbar. Um 

für eine bestimmte Tabelle diese Zusätze zu pflegen, muß der Cursor auf 

den Tabellennamen oder ein Feld dieser Tabelle gestellt und anschließend 

diese Funktion aufgerufen werden. Es erscheint ein Fenster, in dem alle 

Zusatztabellen, Zusatzfelder und Codings, die dieser Tabelle zugeordnet 

sind, aufgeführt werden. 

Um die Definition eines Zusatzes zu ändern oder zu löschen, muß der 

Cursor auf die entsprechende Zeile gestellt und anschließend die Funktion 

Ändern oder Löschen aufgerufen werden. Bei der Funktion Ändern, die auch 






52 

über die Funktionstaste F2 (Doppelklick) ausgelöst wird, wird direkt in 

das entsprechende Pflegebild verzweigt (siehe unten). 

Um eine neue Zusatztabelle, ein Zusatzfeld oder ein Coding zu definieren, 

muß auf dem Bild die Funktion Anlegen aufgerufen werden. Es erscheint ein 

weiteres Fenster, auf dem zunächst über Auswahlknöpfe festgelegt werden 

muß, ob eine Zusatztabelle angeschlossen oder ein Zusatzfeld oder ein 

Coding definiert werden soll. Außerdem muß bei Zusatztabellen und 

Zusatzfeldern der Name der Tabelle bzw. des Feldes eingegeben werden. 

Anschließend wird mit der Funktion Weiter auf ein Pflegebild gemäß der 

Auswahl verzweigt. 

Bei Zusatztabellen enthält dieses Pflegebild wie bisher die 

Reihenfolgenummer und eine SELECT-Anweisung, bei der die WHERE-Klausel 

spezifiziert werden muß. Im Gegensatz zur bisherigen Pflegetransaktion 

ist die Zahl der Schlüsselfelder bei Zusatztabellen nicht mehr auf 10 

beschränkt und kann beliebig groß werden. Auf die neue Option 'intern 

puffern' wird weiter unten eingegangen. Zur Prüfung der SELECT-Anweisung 

auf syntaktische Richtigkeit kann die Funktion Prüfen Zusatztabelle 

verwendet werden. Ansonsten wird diese Prüfung erst durch die Funktionen 

Prüfen bzw. Generieren für das gesamte Sachgebiet vorgenommen. 

Bei Zusatzfeldern enthält das Pflegebild die Reihenfolgenummer sowie 

Eingabefelder für den Langtext, die Überschrift und alle bisher bekannten 

Angaben zur Typdefinition. Das Coding für das Zusatzfeld ist in diesem 

Bild nicht enthalten. Um das Coding zu pflegen, muß mit der Funktion 

Editor in einen Programm-Editor verzweigt werden. Zur Prüfung des Codings 

auf syntaktische Richtigkeit kann die Funktion Prüfen im Editor verwendet 

werden. Ansonsten wird diese Prüfung erst durch die Funktionen Prüfen 

bzw. Generieren für das gesamte Sachgebiet vorgenommen. 

Bei der Pflege eines GET-Codings wird zunächst ein Fenster angezeigt, in 

dem die Reihenfolgenummer für dieses Coding spezifiziert werden muß. 

Anschließend wird direkt in einen Programm-Editor verzweigt. Zur Prüfung 

des Codings auf syntaktische Richtigkeit kann die Funktion Prüfen im 

Editor verwendet werden. Ansonsten wird diese Prüfung erst durch die 

Funktionen Prüfen bzw. Generieren für das gesamte Sachgebiet vorgenommen. 

Außerdem kann wie bisher pro Tabelle der logischen Datenbank ein Coding 

zum Zeitpunkt GET LATE definiert werden. Um ein solches Coding zu 

definieren bzw. zu ändern, muß der Cursor auf den Tabellennamen oder ein 

Feld dieser Tabelle gestellt und anschließend die Funktion Springen -> 

Codings -> GET LATE aufgerufen werden. 

Weitere Codings (Zeitpunkte DATA, START-OF-SELECTION, END-OF-SELECTION 

und TOP-OF-PAGE) können wie bisher über entsprechende Funktionen aus dem 

Menü Springen zur Pflege aufgerufen werden. Auch hier erfolgt direkt eine 

Verzweigung in einen Programm-Editor. Zur Prüfung des Codings auf 

syntaktische Richtigkeit kann die Funktion Prüfen im Editor verwendet 

werden. Ansonsten wird diese Prüfung erst durch die Funktionen Prüfen 

bzw. Generieren für das gesamte Sachgebiet vorgenommen. 

Wie oben beschrieben erfolgen automatische Prüfungen auf syntaktische 

Richtigkeit erst durch die Funktionen Prüfen bzw. Generieren für das 

gesamte Sachgebiet und nicht mehr wie bisher bei jeder Eingabe auf einem 

Pflegebild. Damit ist es möglich, zunächst auch fehlerhaftes Coding zu 

speichern, falls die Fehlerursache nicht im Coding selbst zu suchen ist 

(z.B. wenn die Definition eines Hilfsfeldes im DATA-Coding fehlt). Als 

Ersatz für die automatische Prüfung pro Eingabe stehen die oben erwähnten 

Funktionen Prüfen auf jedem Pflegebild zur Verfügung. 

Parameter und Programmabgrenzungen (Selektionskriterien) des Sachgebietes 

sind jetzt unter dem Begriff 'Abgrenzungen' zusammengefaßt. Zur Pflege 

einer Abgrenzung muß die Funktion Springen -> Abgrenzungen aufgerufen 

werden. Es erscheint ein Fenster, in dem die vorhandenen Parameter und 

Selektionskriterien aufgeführt sind. Bei Sachgebieten über logischen 

Datenbanken sind in dieser Übersicht jetzt auch alle Abgrenzugen 






53 

enthalten, die durch die logische Datenbank automatisch zur Verfügung 

gestellt werden (Standard-Abgrenzungen). Das Ändern oder Löschen dieser 

Standard-Abgrenzungen ist aber nicht möglich. 

Um die Definition einer Abgrenzung zu ändern oder zu löschen, muß der 

Cursor auf die entsprechende Zeile gestellt und anschließend die Funktion 

Ändern oder Löschen aufgerufen werden. Bei der Funktion Ändern, die auch 

über die Funktionstaste F2 (Doppelklick) ausgelöst wird, wird direkt in 

das entsprechende Pflegebild verzweigt (siehe unten). 

Um eine neue Abgrenzung zu definieren, muß auf dem Bild die Funktion 

Anlegen aufgerufen werden. Es erscheint ein weiteres Fenster, auf dem 

zunächst über Auswahlknöpfe festgelegt werden muß, ob ein Parameter oder 

ein Selektionskriterium definiert werden soll. Außerdem muß der Name der 

Abgrenzung eingegeben werden. Anschließend wird mit der Funktion Weiter 

auf ein Pflegebild gemäß der Auswahl verzweigt. Dieses Pflegebild enthält 

alle Angaben, die auch in der bisherigen Pflegetransaktion zur Definition 

zur Verfügung standen. 

Im Gegensatz zu den Zusätzen (Zusatztabellen, Zusatzfelder, GET-Coding) 

erfolgt bei den Abgrenzungen die Prüfung auf syntaktische Richtigkeit wie 

bisher auf dem Pflegebild selbst. 

Die Funktionen Prüfen und Generieren wurden erweitert. Es werden mehr 

Fehler erkannt und gemeldet. Außerdem werden im Protokoll auch Warnungen 

ausgegeben. Fehler führen wie bisher dazu, daß die Generierung nicht 

vorgenommen wird. Warnungen dagegen führen nicht zum Abbruch der 

Generierung, sondern verweisen nur auf Zustände, die überprüft werden 

sollten. 

-Alias-Tabellen 

Bis Release 4.0A bestand keine Möglichkeit, eine Zusatztabelle mehrfach 

an ein Sachgebiet anzuschließen. Es existieren aber Fälle, wo ein solcher 

mehrfacher Anschluß durchaus sinnvoll ist. So tritt z.B. in der logischen 

Datenbank F1S, die im Handbuch für die Beispiele verwendet wird, der Fall 

auf, daß in der Tabelle SPFLI zwei Felder für den Start- und den 

Zielflughafen existieren. Beide Felder enthalten eine Abkürzung für den 

Flughafen und bilden einen Schlüssel für die Tabelle SAIRPORT, die die 

Langtexte für Flughäfen enthält. Bisher konnte die Tabelle SAIRPORT nur 

einmal als Zusatztabelle an SPFLI angeschlossen werden. Das bedeutet, daß 

über diesen Mechanismus nur der Langtext für einen der beiden Flughäfen 

gewonnen werden konnte. Der Langtext für den anderene Flughafen mußte 

über ein Zusatzfeld ermittelt werden. 

Ein ähnlich gelagertes Problem bestand bei Tabellen-Joins. Bisher konnte 

eine bestimmte Tabelle nur einmal in den Join aufgenommen werden, obwohl 

es das Open SQL durchaus zuläßt, in einen Join eine Tabelle mehrfach 

aufzunehmen. 

Außerdem sei noch darauf hingewiesen, daß es auch nicht möglich war, eine 

Tabelle, die in der logischen Datenbank oder in einem Join vorhanden ist, 

auch als Zusatztabelle anzuschließen. 

Ab Release 4.0A bietet die Query über das Konzept der Alias-Tabellen eine 

Lösung für diese Problematik. Die Grundidee besteht darin, für eine 

Tabelle mehrere verschiedene Alias-Namen vergeben zu können. Die Tabelle 

kann dann über die verschiedenen Alias-Namen mehrfach angesprochen 

werden. 

Um für eine Tabelle einen Alias-Namen zu vergeben, muß die Funktion 

Springe -> Alias-Namen aufgerufen werden. Es erscheint ein Fenster, in 

dem die vorhandenen Alias-Namen aufgeführt sind, einschließlich der 

Information, auf welche Tabellendefinitionen aus dem Dictionary sich die 

Alias-Namen beziehen. Alias-Namen müssen innerhalb eines Sachgebietes 

eindeutig sein. Sie müssen sich immer direkt auf eine Tabellendefinition 

aus dem Dictionary beziehen und dürfen nicht mit dem Namen einer 






54 

Definition aus dem Dictionary identisch sein. 

Um einen neuen Alias-Namen zu vergeben, muß in der Übersicht für die 

Alias-Namen die Funktion Anlegen gewählt werden. Es erscheint ein 

weiteres Fenster, in dem der Alias-Name und die zugeordnete Tabelle aus 

dem Dictionary eingegeben werden können. 

Um einen Alias-Namen wieder zu löschen, muß in der Übersicht für die 

Alias-Namen der Cursor auf den betreffenden Alias-Namen gestellt und die 

Funktion Löschen aufgerufen werden. Das Löschen ist nur möglich, wenn die 

Alias-Tabelle nicht im Sachgebiet verwendet wird. 

Um eine Tabelle z.B. zweimal als Zusatztabelle in einem Sachgebiet 

anzuschließen, muß wie folgt verfahren werden. Zunächst kann die Tabelle 

unter ihrem Orginal-Namen einmal angeschlossen werden. Dann muß für die 

Tabelle ein Alias-Name vergeben werden. Anschließend kann die Tabelle 

unter diesem Alias-Namen ein zweites Mal als Zusatztabelle angeschlossen 

werden. Zu beachten ist, daß die Felder dieser Tabelle jetzt zweimal mit 

den gleichen Langtexten und Überschriften im Sachgebiet auftreten. Bei 

einem mehrfachen Anschluß einer Tabelle müssen deshalb in der Regel auch 

die Langtexte und Überschriften der Felder geändert werden, die einer 

Sachgruppe zugeordnet werden. 

Analog ist zu verfahren, wenn eine Tabelle zweimal in einem Join 

verwendet werden soll. 

-Option 'intern puffern' für Zusatztabellen 

Beim Anschluß einer Zusatztabelle kann die neue Option 'intern puffern' 

verwendet werden. Diese Option kann zur Verbesserung der Performance von 

Query-Reports benutzt werden. 

Ist diese Option gesetzt, so werden in Queries, die diese Zusatztabelle 

verwenden, alle gelesenen Sätze dieser Tabelle in einer internen Tabelle 

gesammelt. Wird ein Satz der Tabelle benötigt, so wird zunächst 

überprüft, ob dieser Satz bereits in der internen Tabelle vorhanden ist. 

Nur wenn das nicht der Fall ist, wird mit Hilfe einer SELECT SINGLE 

Anweisung der Satz aus der Datenbanktabelle gelesen und in die interne 

Tabelle aufgenommen. Die interne Pufferung bewirkt also, daß ein Satz der 

Zusatztabelle pro Ausführung einer Query höchstens einmal gelesen wird. 

Die Option 'intern puffern' sollte nur verwendet werden, wenn zu erwarten 

ist, daß bei der Abarbeitung einer Query ein Satz der Zusatztabelle 

mehrfach gelesen werden muß. Anderenfalls sollte diese Option nicht 

verwendet werden, da die interne Tabelle Speicherplatz kostet. Außerdem 

sollte bei sehr breiten Tabellen, d.h. Tabellen mit sehr vielen Felder 

geprüft werden, ob der Speicherplatzbedarf zur Führung der internen 

Tabelle die Zeitersparnis beim Lesen rechfertigt. 

Ein typisches Beispiel, bei dem eine Zusatztabelle intern gepuffert 

werden sollte, ist der im obigen Abschnitt über Alias-Namen genannte 

Fall, die Tabelle SAIRPORT als Zusatztabelle an die Tabelle SPFLI 

anzuschließen, um den Langtext für einen Flughafen bereitzustellen. In 

diesem Fall muß davon ausgegangen werden, daß im Normalfall Sätze aus 

SAIRPORT mehrfach gelesen werden müssen. 

-Funktion 'Abgleichen' 

Auf dem Einstiegsbild der Komponente zur Pflege von Sachgebieten 

existiert ab Release 4.0A die Funktion Sachgebiet -> Weitere Funktionen 

-> Abgleichen. Diese Funktion ist von Bedeutung, wenn sich die 

technischen Eigenschaften von Feldern aus Datenbanktabellen, die im 

Sachgebiet verwendet werden, geändert haben (Typ, Länge, Ausgabelänge, 

Verwendung als Währungsbetrags- oder Mengenfeld). Solche Änderungen 

sollten allerdings die Ausnahme sein. 






55 

Liegen derartige Änderungen vor, so wird bei der Generierung des 

Sachgebietes eine Warnung ausgegeben, in der die Abweichungen zwischen 

den Felder im Sachgebiet und im Dictionary beschrieben werden. Die 

Funktion Sachgebiet -> Weitere Funktionen -> Abgleichen bietet dann die 

Möglichkeit, die geänderten technischen Eigenschaften in das Sachgebiet 

zu übernehmen. Zunächst wird das gleiche Bild mit Warnungen wie bei der 

Generierung ausgegeben. Auf diesem Bild existiert jetzt aber die Funktion 

Abgleichen, mit der die Angaben aus dem Dictionary in das Sachgebiet 

übernommen werden können. 

Zu beachten ist, daß im Anschluß daran alle Queries über diesem 

Sachgebiet ebenfalls einem Abgleich unterworfen werden sollten, damit die 

geänderten Eigenschaften auch in die Definition der Queries übernommen 

wird. 

Neuerungen bei der Pflege von Benutzergruppen 

Im Abschnitt über Arbeitsbereiche wurde bereits erwähnt, daß die 

Benutzergruppen im globalen Bereich an den Workbench Organizer 

angeschlossen sind. Weiterhin wurde in diesem Abschnitt erwähnt, daß die 

Zuordnung von Benutzern und Sachgebieten zu den Benutzergruppen 

vorgenommen werden kann, ohne daß diese Änderungen in einem 

Korrekturauftrag erfaßt werden müssen. Dies erfordert eine anderes 

Vorgehen bei der Pflege von Benutzergruppen. 

Die Funktionen Anlegen und Ändern auf dem Einstiegsbild der Komponente 

zur Pflege von Benutzergruppen führen jetzt auf ein Dialogfenster, in dem 

lediglich der Langtext für die Benutzergruppe gepflegt werden kann. Nur 

diese beiden Funktionen führen im globalen Bereich dazu, daß ggf. ein 

Korrekturauftrag angelegt wird. Die Bilder zur Zuordnung von Benutzern 

und Sachgebieten zu einer Benutzergruppe können über die Funktion 

Benutzer und Sachgebiete zuordnen erreicht werden. 

Um eine neue Benutzergruppe anzulegen, muß deshalb wie folgt verfahren 

werden. Zunächst muß der Name der Benutzergruppe eingegeben und die 

Funktion Anlegen gerufen werden. Im Dialogfenster muß der Langtext für 

die Benutzergruppe eingegeben und anschließend die Funktion Sichern 

(ENTER) aufgerufen werden. Diese Funktion erfordert im globalen Bereich 

die Zuordnung einer Entwicklungsklasse und ggf. eines Korrekturauftrages. 

Die Funktion Sichern führt auf das Einstiegsbild der Komponente zur 

Pflege von Benutzergruppen zurück. Jetzt kann über die Funktion Benutzer 

und Sachgebiete zuordnen auf die bekannten Bilder zur Zuordnung von 

Benutzern und Sachgebieten verzweigt werden. 

Werden die Funktionen Benutzer und Sachgebiete zuordnen, Benutzer 

zuordnen und Sachgebiet zuordnen im globalen Bereich aufgerufen, so wird 

in keinem Fall das Anlegen eines Korrekturauftrages gefordert, da diese 

Einstellungen, wie bereits erwähnt, nicht durch den Workbench Organizer 

erfaßt werden. Das gleiche gilt für die Funktion Zuordnung zu 

Benutzergruppen der Komponente zur Pflege von Sachgebieten. 

Beim Kopieren von Benutzergruppen im globalen Bereich ist eine weitere 

Besonderheit zu beachten. Zunächst muß für die neue Benutzergruppe eine 

Entwicklungsklasse festgelegt und ggf. ein Korrekturauftrag erfaßt 

werden. Wird eine nicht temporäre Entwicklungsklasse gewählt und wurde 

die Option Queries mitkopieren gewählt, so muß auch für jede kopierte 

Query eine Entwicklungsklasse und ggf. ein Korrekturauftrag festgelegt 

werden. 

Neuerungen bei Transporten 

Die Einführung der Arbeitsbereiche führt dazu, daß bei Transporten von 






56 

Query-Objekten drei verschiedene Transportfälle berücksichtigt werden 

müssen: 

o Transport von Objekten des globalen Bereiches 

o Transport von Objekten des Standardbereiches 

o Transport von Objekten (Kopieren) zwischen Arbeitsbereichen 

In den ersten beiden Fällen wird durch den Transport der Arbeitsbereich, 

in dem sich das Query-Objekt befindet, nicht gewechselt. 

-Transporte von Objekten des globalen Bereiches 

Objekte des globalen Bereiches sind mandantenunabhängig. Ein Transport 

solcher Objekte heißt deshalb immer, daß diese Objekte in andere Systeme 

übertragen werden. 

Im globalen Bereich entscheidet die Entwicklungsklasse eines Objektes 

darüber, ob dieses Objekt transportiert werden kann oder nicht (vgl. dazu 

den Abschnitt über Arbeitsbereiche). Lokale Objekte (in temporären 

Entwicklungsklassen) können generell nicht transportiert werden. Alle 

anderen Objekte werden beim Anlegen bzw. Ändern in einem Korrekturauftrag 

erfaßt. Der Transport erfolgt dann in der üblichen Form über den 

Workbench Organizer (Freigabe von Korrektur- und Transportauftrag). 

Im Gegensatz zu Transporten von Objekten aus dem Standardbereich sind 

keine Vor- und Nacharbeiten (Export und Import von 

Transportdatenbeständen) mehr notwendig, d.h. die über den Workbench 

Organizer in ein anderes System transportierten Query-Objekte können dort 

direkt verwendet werden. Allerdings werden beim Transport über den 

Workbench Organizer keine Prüfungen durchgeführt, wie sie beim Import von 

Transportdatenbeständen im Standardbereich ablaufen. Es ist deshalb 

möglich, daß im Zielsystem Inkonsistenzen in den Datenbeständen der Query 

auftreten. Ein typischer Fall ist der Transport einer Query, ohne daß das 

zugehörige Sachgebiet im Zielsystem vorhanden ist. Bei Transporten von 

Query-Objekten im globalen Bereich sollte deshalb immer sorgfältig 

kontrolliert werden, ob abhängige Objekte in der aktuellen Fassung im 

Zielsystem bereits vorhanden sind. Wenn dies nicht der Fall ist müssen 

diese Objekte mit transportiert werden. 

Der Transport von Varianten für Queries ist nur möglich, wenn die zu 

transportierenden Varianten als Systemvarianten erfaßt werden (vgl. dazu 

den Abschnitt über Neuerungen bei der Pflege von Queries). Alle anderen 

Varianten können nicht transportiert werden. 

Durch Änderungen an Query-Objekten im globalen Bereich, die in einer 

nicht temporären Entwicklungsklasse liegen, werden folgende Einträge in 

Korrekturaufträgen erfaßt: 

1. Benutzergruppen 

-R3TR AQBG bbbbbbbbbbbb 

-Dieses Transportobjekt umfaßt lediglich den Katalogeintrag für die 

-Benutzergruppe. Die Zuordnung von Benutzern und Sachgebieten zu dieser 

-Benutzergruppe wird nicht erfaßt und demzufolge auch nicht 

-transportiert. 

2. Sachgebiete 

-R3TR AQSG ssssssssssssssssssssssss 

-Dieses Transportobjekt umfaßt den Katalogeintrag für das Sachgebiet, 

-die Definition des Sachgebietes selbst und die Zuordnung des 

-Sachgebietes zu Benutzergruppen. Bei der Freigabe des 

-Transportauftrages wird der gerade aktuelle Stand der Zuordnung des 

-Sachgebietes zu den Benutzergruppen transportiert. 






57 

3. Queries 

-R3TR AQQU bbbbbbbbbbbbqqqqqqqqqqqqqq 

-Dieses Transportobjekt umfaßt den Katalogeintrag für die Query und die 

-Definition der Query selbst. 

4. Systemvarianten von Queries: 

-R3TR AQQV rrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrvvvvvvvvvvvvvv 

-Dieses Transportobjekt umfaßt jeweils genau eine Systemvariante einer 

-Query. Systemvarianten können nur angelegt werden, wenn die Query in 

-einer nicht temporären Entwicklungsklasse liegt. Weiterhin ist zu 

-beachten, daß dieses Transportobjekt ein nicht sperrbares Objekt ist 

-und demzufolge gleichzeitig in verschiedenen Korrekturaufträgen 

-auftreten kann. Soll deshalb eine Query zusammen mit den 

-Systemvarianten transportiert werden, so ist bei der Vergabe der 

-Korrekturaufträge darauf zu achten, daß die Systemvarianten in den 

-gleichen Korrekturauftrag wie die Query gelegt werden. 

Die Ablage der Query-Objekte im globalen Bereich wurde so geändert, daß 

alle Texte in eigenen Texttabellen erfaßt werden. Damit ist es möglich, 

diese Texte mit den von SAP bereitgestellten Programmen zum 

Sprachabgleich zu übersetzen. Daneben existiert natürlich weiterhin die 

Komponente zum Sprachabgleich von Query-Objekten (Transaktion SQ07). 

-Transporte von Objekten des Standardbereiches 

Objekte des Standardbereiches sind mandantenabhängig. Ein Transport 

solcher Objekte kann deshalb bedeuten, daß diese Objekte innerhalb des 

gleichen Systems in andere Mandanten übertragen werden oder daß diese 

Objekte in andere Systeme übertragen werden. 

Das Verfahren zum Transport von Objekten aus dem Standardbereich hat sich 

nicht geändert. Es erfolgt wie bisher mit Hilfe der Funktion Umfeld -> 

Transporte in den Komponenten zur Pflege von Sachgebieten und 

Benutzergruppen. Prinzipiell können alle Objekte des Standardbereiches 

transportiert werden. 

Anstelle der Transporttabelle TAQTS wird ab Release 4.0 die 

Transporttabelle AQTDB verwendet. Außerdem werden die Texttabellen AQTXTQ 

und AQTXTBS nicht mehr versorgt. Diese Texttabellen dienten im Release 

3.x zur Aufnahme aller Texte der transportierten Objekte und ermöglichten 

so den Sprachabgleich für auszuliefernde Query-Objekte. 

Beim Erzeugen eines Transportdatenbestandes (Export) wird wie bisher ein 

Transportauftrag im Workbench Organizer angelegt. Der Transportauftrag 

wurde von der Transportart T auf die Transportart K umgestellt. Damit 

wird dieser Transportauftrag bei Freigabe nicht nur in ein Zielsystem 

übertragen, sondern in alle Zielsysteme, die auf dem entsprechenden 

Transportweg liegen. Diese Änderung ist bereits ab Release 3.0F gültig. 

Außerdem werden bei Queries alle Einträge in die 

Berichts-Berichts-Schnittstelle, bei denen die Query als Sender 

eingetragen ist, mit in den Transportauftrag übernommen. Auch diese 

Änderung ist bereits ab Release 3.0F gültig. 

-Transport von Objekten (Kopieren) zwischen Arbeitsbereichen 

Das Kopieren von Objekten zwischen den verschiedenen Arbeitsbereichen 

entspricht einem Transport von Objekten zwischen zwei Mandanten eines 

Systems. Aus diesem Grund wurde das Transportwerkzeug der Query (Funktion 

Umfeld -> Transporte) erweitert. Das Kopieren von Objekten zwischen den 

Arbeitsbereichen kann deshalb nur von einem Nutzer vorgenommen werden, 

der die Berechtigung zur Pflege von Sachgebieten und Benutzergruppen hat. 

Es kann prinzipiell jedes Objekt in den jeweils anderen Arbeitsbereich 






58 

kopiert werden. 

Auf dem Einstiegsbild des Transportwerkzeuges der Query stehen zwei neue 

Transportaktionen zur Verfügung: 

o Kopieren Globaler Bereich -> Standardbereich 

o Kopieren Standardbereich -> Globaler Bereich 

Beide Transportaktionen stellen jeweils eine Kombination von Export und 

Import in einem Schritt dar. Es wird allerdings kein 

Transportdatenbestand in der Transporttabelle AQTDB angelegt und auch 

kein Transportauftrag im Workbench Organizer erzeugt. Beim Import werden 

die üblichen Prüfungen durchgeführt und ein Protokoll erstellt. 

Die Transportaktion 'Kopieren Globaler Bereich -> Standardbereich' 

kopiert Objekte aus dem globalen Bereich in den Standardbereich. Dies 

entspricht einem Export von Objekten aus dem globalen Bereich und einem 

Import dieser Objekte in den Standardbereich. Die Optionen 'Testlauf', 

'Überschreiben erlaubt' und 'Transport von Varianten von Queries' haben 

die übliche Bedeutung. Die Auswahl der zu transportierenden Objekte aus 

dem globalen Bereich erfolgt in der üblichen Weise. 

Die Entwicklungsklassen der aus dem globalen Bereich kopierten Objekte 

werden ignoriert, d.h. die Kopien dieser Objekte im Standardbereich 

besitzen keine Entwicklungsklasse bzw. sind lokale Objekte. 

Die Transportaktion 'Kopieren Standardbereich -> Globaler Bereich' 

kopiert Objekte aus dem Standardbereich in den globalen Bereich. Dies 

entspricht einem Export von Objekten aus dem Standardbereich und einem 

Import dieser Objekte in den globalen Bereich. Die Optionen 'Testlauf', 

'Überschreiben erlaubt' und 'Transport von Varianten von Queries' haben 

die übliche Bedeutung. Die Auswahl der zu transportierenden Objekte aus 

dem Standardbereich erfolgt in der üblichen Weise. 

Bezüglich der Entwicklungsklassen der kopierten Objekte im globalen 

Bereich wird wie folgt verfahren. Wird ein Objekt im globalen Bereich 

überschrieben, so erbt das kopierte Objekt die Entwicklungsklasse des 

überschriebenen Objektes. Ist das kopierte Objekt im globalen Bereich ein 

neues Objekt, so erscheint in der Regel ein Fenster, in dem dem Objekt 

eine Entwicklungsklasse zugeordnet werden muß. Je nach Art der 

Entwicklungsklasse kann es anschließend notwendig sein, einen 

Korrekturauftrag zu vergeben. Ist das kopierte Objekt im globalen Bereich 

eine neue Query, bei der entweder das zugeordnete Sachgebiet oder die 

zugeordnete Benutzergruppe eine temporäre Entwicklungsklasse besitzen, so 

wird der Query die Entwicklungsklasse $TMP zugeordnet. In diesem Fall 

erfolgt kein Dialog zur Festlegung der Entwicklungsklasse. 

Neuerungen beim Sprachabgleich 

In Sachgebieten werden eine Reihe von Texten verwendet, bei denen 

Standardvorschläge dem Dictionary entnommen werden (Langtexte und 

Überschriften der Felder, Langtexte von Tabellen usw.). Beim 

Sprachabgleich für Sachgebiete mußten diese Texte in der Zielsprache alle 

neu erfaßt werden, obwohl entsprechende Texte im Dictionary auch in der 

Zielsprache vorhanden sind. 

Beim Sprachabgleich für Sachgebiete wurde nun die Möglichkeit geschaffen, 

diese Texte in der Zielsprache aus dem Dictionary zu besorgen und als 

Vorschlag für den Sprachabgleich zur Verfügung zu stellen. Damit wird der 

Sprachabgleich wesentlich vereinfacht und Mehrarbeit vermieden. 

Für den Sprachabgleich von Sachgebieten existiert die neue Funktion 

Bearbeiten -> Standardtexte ergänzen. Wird diese Funktion aufgerufen, so 

wird bei jedem Text, der in der Zielsprache noch nicht vorhanden ist und 

für den ein Textvorschlag im Dictionary existiert, dieser Text aus dem 

Dictionary gelesen und als Vorschlag für den Zielsprachtext 






59 

bereitgestellt. Stimmt der Quellsprachtext noch mit dem Text aus dem 

Dictionary überein, so werden beide Texte als abgeglichen gekennzeichnet. 

Anderenfalls, d.h. wenn der Quellsprachtext gegenüber dem Text aus dem 

Dictionary geändert wurde, werden beide Texte als nicht abgeglichen 

gekennzeichnet. 

Die beschriebene Funktion gehört bereits ab Release 3.0F zur 

Standardauslieferung der Query. 

-Änderungen in der Systemadministration 

Die Berechtigung zur Arbeit mit der Query wird wie bisher über das 

Berechtigungsobjekt S_QUERY gesteuert. Eine Berechtigung für dieses 

Berechtigungsobjekt bezieht sich immer auf beide Arbeitsbereiche. Besitzt 

also ein Nutzer die Berechtigung zum Ändern von Queries, so darf er in 

allen Benutzergruppen des Standardbereiches und des globalen Bereiches, 

in denen er eingetragen ist, Queries anlegen und ändern. 

-Änderungen in der Vorgehensweise 

Umsetzung von Query-Daten 

Beim Übergang auf Release 4.0 ist aufgrund des erweiterten Namensraums 

eine Umsetzung aller vorhandenen Query-Objekte notwendig. Aus technischen 

Gründen wird diese Umsetzung nicht automatisch beim Put durch 

XPRA-Programme vorgenommen, sondern muß nach dem Put für jeden Mandanten 

einzeln durchgeführt werden. Für die Umsetzung wurden spezielle Programme 

bereitgestellt. 

Die technische Grundlage zur Ablage von Query-Objekten bilden bis Release 

4.0A im wesentlichen die Datenbanktabellen AQDB und TAQTS. Ab Release 

4.0A werden diese Tabellen durch insgesamt 15 neue Datenbanktabellen 

abgelöst. Die Tabellen AQDB und TAQTS werden nicht mehr verwendet, ihr 

Inhalt bleibt jedoch vorläufig erhalten. Damit ist es möglich, die 

Umsetzung jederzeit vollständig oder teilweise, d.h. für jedes einzelne 

Objekt zu wiederholen. Die Umsetzung muß für jeden Mandanten in der unten 

beschriebenen Art vorgenommen werden. 

Vor der Umsetzung der Query-Objekte wird jeder Versuch, im 

Standardbereich mit Query-Objekten zu arbeiten, mit einer Meldung 

angelehnt, daß zunächst eine Umsetzung vorzunehmen ist. Nach der 

Umsetzung kann durch den Systemadministrator genau der Zeitpunkt 

festgelegt werden, ab dem die Arbeit im Standardbereich erlaubt wird. 

Für die Umsetzung stehen zwei Reports zur Verfügung: RSAQSUMM und 

RSAQUM40. 

Der Report RSAQSUMM erstellt ein Inhaltsverzeichnis über Query-Objekte 

und Transportdatenbestände. Dieser Report ist insbesondere in der Lage, 

den Inhalt der alten und der neuen Datenbanktabellen auszuwerten. Er kann 

deshalb dazu verwendet werden, das Ergebnis der Umsetzung zu 

kontrollieren. Auf dem Selektionsbild des Reports kann über Ankreuzfelder 

festgelegt werden, für welche Objekte aus welchen Arbeitsbereichen das 

Inhaltsverzeichnis erstellt werden soll. Es sind folgende Bereiche 

möglich: 

o Globaler Bereich (ab Release 4.0A) 

o neuer Standardbereich (ab Release 4.0A) 

o neue Transportdatenbestände (ab Release 4.0A) 

o alter Standardbereich (bis Release 4.0A) 

o alte Transportdatenbestände (bis Release 4.0A) 

Falls in einem Bereich verschiedene Objekte auftreten können, kann das 

Inhaltsverzeichnis auf bestimmte Objekte eingeschränkt werden, so z.B. 

auf die Queries bestimmter Benutzergruppen. Das Inhaltsverzeichnis 

enthält für jedes Objekt seinen Namen, den zugeordneten Langtext, Angaben 






60 

zur Erstellung und letzten Änderung sowie ggf. weitere Angaben je nach 

Art des Objektes. 

Der Report RSAQSUMM ist nicht nur für die Umsetzung von Interesse, 

sondern kann immer dann verwendet werden, wenn ein Inhaltsverzeichnis 

über alle oder bestimmte Objekte in einem der Arbeitsbereiche erstellt 

werden soll. 

Der Report RSAQUM40 ist das Programm zur Umsetzung aller Query-Objekte. 

Er liest Objekte (Benutzergruppen, Sachgebiete, Queries und 

Transportdatenbestände) aus der 'alten' Ablage und überführt sie in die 

'neue' Ablage. Der Report ist in der Lage, sowohl eine Gesamtumsetzung 

aller vorhandenen Objekte aus der alten Ablage vorzunehmen als auch 

einzelne Objekte oder Gruppen von Objekten umzusetzen. Dieser Report kann 

nur von einem Nutzer ausgeführt werden, der die Berechtigung zum Pflegen 

von Sachgebieten und Benutzergruppen hat. Die Arbeit des Reports wird in 

einem Protokoll festgehalten. 

Mit dem Report RSAQUM40 kann auch der Zeitpunkt festgelegt werden, ab dem 

die Arbeit im Standardbereich erlaubt wird. 

Auf dem Selektionsbild des Reports RSAQUM40 können verschiedene 

Festlegungen getroffen werden: 

o Durch das Ankreuzfeld 'Überschreiben erlaubt' kann festgelegt werden, 

-ob bereits vorhandene Objekte im (neuen) Standardbereich überschrieben 

-werden dürfen oder nicht. Diese Option ist nur von Bedeutung, wenn die 

-Umsetzung komplett oder für einzelne Objekte wiederholt werden soll. 

o Weiterhin existieren eine Reihe von Auswahlknöpfen, über die der 

-Umfang der umzusetzenden Objekte bestimmt wird. 

o Wird der Auswahlknopf 'Alles umsetzen' gewählt, so erfolgt eine 

-Umsetzung aller in der alten Ablage vorhandenen Objekte. 

o Wird einer der Auswahlknöpfe 'Benutzergruppen umsetzen', 'Sachgebiete 

-umsetzen', 'Queries umsetzen' oder 'Transportdatenbestände umsetzen' 

-gewählt, so werden nur Objekte dieser Art umgesetzt. Dabei ist es 

-jeweils möglich, über Abgrenzungen festzulegen, welche Objekte 

-umgesetzt werden sollen. 

o Wird der Auswahlknopf 'Freigabekennzeichen setzen' gewählt, so wird 

-lediglich ein Kennzeichen gesetzt, daß ab sofort die Arbeit im 

-Standardbereich wieder möglich ist. 

Zur Umsetzung der Query-Objekte eines Mandanten wird damit folgendes 

Vorgehen empfohlen: 

RSAQSUMM (altes Inhaltsverzeichnis kopieren) 

RSAQUM40 (alles Umsetzen) 

RSAQSUMM (neues Inhaltsverzeichnis erstellen) 

o Zunächst sollte mit dem Report RSAQSUMM ein komplettes 

-Inhaltsverzeichnis aller alten und neuen Bereiche angefertigt werden. 

-Im neuen Standardbereich dürfen keine Objekte vorhanden sein. Im alten 

-Standardbereich müssen alle bisher angelegten Query-Objekte 

-verzeichnet sein. Gleiches gilt sinngemäß für die 

-Transportdatenbestände. 

o Anschließend sollte der Report RSAQUM40 mit der Option 'Alles 

-umsetzen' abgearbeitet werden. 

o Mit Hilfe des Reports RSAQSUMM sollte erneut ein komplettes 

-Inhaltsverzeichnis aller Bereich angefertigt werden. Die Query-Objekte 

-und Transportdatenbestände müssen jetzt in alter und neuer 

-(umgesetzter) Form vorliegen. 

o Falls alle Objekte ordnungsgemäß umgesetzt wurden, kann dann der 

-Report RSAQUM40 mit der Option 'Freigabekennzeichen setzen' 

-abgearbeitet werden. Damit können die Endbenutzer wieder mit der ABAP 

-Query im Standardbereich arbeiten. 

Wie bereits erwähnt kann die Umsetzung für einzelne oder mehrere Objekte 

jederzeit wiederholt werden. In diesem Fall muß der Report RSAQUM40 

erneut abgearbeitet werden, diesmal in der Regel jedoch mit den Optionen 

'Überschreiben erlaubt' und einer Abgrenzung auf die gewünschten Objekte. 

Zu beachten ist in diesem Fall jedoch, daß Änderungen, die ggf. seit der 






61 

vorangegangenen Umsetzung vorgenommen wurden, verloren gehen. Nach einer 

erfolgreichen Gesamtumsetzung sollte deshalb eine erneute Verwendung des 

Reports RSAQUM40 die Ausnahme sein. 






62 

Dokumentinformationen 

Dateiname: 

H:\sap_work_doku\sap_work_query_03.doc 

Erstelldatum: 25.08.01 01:11 

Letzte Speicherung: 28.08.2001 10:11 

Druckdatum: 26.09.2001 11:14 

Größe: 6033408 

Anzahl Seiten: 1 

Erstellt von: 

Prof. Dr. Dieter Steinmann, Fachhochschule Trier 

Infos und Kontakte 

www.fh-trier.de/~stmann 

www.ebit-online.de 

d.steinmann@fh-trier.de 

d.setinmann@ebit-online.de

SAP Query - Prof Dr Dieter Steinmann FH Trier

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?