Kontakt

Ansicht
Dokumentation

ABAP-Query ( RELNBC_ABAP-QUERY-40A )

ABAP-Query ( RELNBC_ABAP-QUERY-40A )

rdisp/max_wprun_time - Maximum work process run time   TXBHW - Original Tax Base Amount in Local Currency  
Diese Dokumentation steht unter dem Copyright der SAP AG.
SAP E-Book

Kurztext

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

  1. Neuerungen in Query-Listen
  • Änderung in der Belegung der Funktionstasten

  • Dynamischer Aufruf der Grafik und Restwerte

  1. Neuerungen bei der Pflege von Sachgebieten
  • Neue Pflegetransaktion

  • Alias-Tabellen

  • Option 'intern puffern' für Zusatztabellen

  • Funktion Abgleichen

  1. Neuerungen bei der Pflege von Benutzergruppen
  2. Neuerungen bei Transporten
  • Transporte von Objekten des globalen Bereiches

  • Transporte von Objekten des Standardbereiches

  • Transport von Objekten (Kopieren) zwischen Arbeitsbereichen

  1. 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 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 (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 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 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.

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 -> 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 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äß 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:

  • 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.
  • 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 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 ü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 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 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.

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 Query-Objekten drei verschiedene Transportfälle berücksichtigt werden müssen:

  • Transport von Objekten des globalen Bereiches
  • Transport von Objekten des Standardbereiches
  • 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.
  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 kopiert werden.

Auf dem Einstiegsbild des Transportwerkzeuges der Query stehen zwei neue Transportaktionen zur Verfügung:

  • Kopieren Globaler Bereich -> Standardbereich
  • 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 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.

Einfluß auf den Datenbestand im Fehlerfall

Soft-/Hardwarevoraussetzungen

Besonderheiten bei der Installation

Auswirkungen auf die Systemverwaltung

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.

Auswirkungen auf das Customizing

Auswirkungen auf Batch-Input

Änderungen an der Oberfläche

Ä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:

  • Globaler Bereich (ab Release 4.0A)
  • neuer Standardbereich (ab Release 4.0A)
  • neue Transportdatenbestände (ab Release 4.0A)
  • alter Standardbereich (bis Release 4.0A)
  • 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 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:

  • 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.
  • Weiterhin existieren eine Reihe von Auswahlknöpfen, über die der Umfang der umzusetzenden Objekte bestimmt wird.
  • Wird der Auswahlknopf 'Alles umsetzen' gewählt, so erfolgt eine Umsetzung aller in der alten Ablage vorhandenen Objekte.
  • 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.
  • 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:

  • 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.
  • Anschließend sollte der Report RSAQUM40 mit der Option 'Alles umsetzen' abgearbeitet werden.
  • 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.
  • 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 vorangegangenen Umsetzung vorgenommen wurden, verloren gehen. Nach einer erfolgreichen Gesamtumsetzung sollte deshalb eine erneute Verwendung des Reports RSAQUM40 die Ausnahme sein.

Aktionen zum Beheben von Fehlern am Datenbestand

Abhängige Funktionen

Planungen

Weitere Hinweise






BAL_S_LOG - Application Log: Log header data   TXBHW - Original Tax Base Amount in Local Currency  
Diese Dokumentation steht unter dem Copyright der SAP AG.

Length: 83188 Date: 20240523 Time: 160059     sap01-206 ( 1802 ms )