Arbeitsbereiche der Query 
Um die SAP Query für verschiedene Anforderungen einsetzen zu können, existieren sogenannte Arbeitsbereiche.
Ein Arbeitsbereich umfaßt eine Menge von Query-Objekten (Queries, InfoSets und Benutzergruppen), die in sich abgeschlossen und konsistent sind.
Es werden zwei Arbeitsbereiche unterschieden, der Globale Bereich und der Standardbereich. Die Funktionalität des Werkzeuges SAP Query steht in beiden Arbeitsbereichen in vollem Umfang zur Verfügung.
Globaler Bereich
Die Query-Objekte des Globalen Bereiches sind mandantenunabhängig. Sie sind systemweit, d.h. in allen Mandanten verfügbar. Die Query-Objekte des Globalen Bereichs sind an den Workbench Organizer angeschlossen. Sie können mit den üblichen Korrektur- und Transportverfahren erfaßt und transportiert werden.
Beim Transport sind keine manuellen Aktionen zur Vor- bzw. Nachbereitung 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.
Standardbereich
Im Standardbereich werden alle Query-Objekte (Queries, InfoSets, Benutzergruppen) pro Mandant angelegt und verwaltet. Query-Objekte sind nicht an den Workbench Organizer angeschlossen, d.h. sie können nicht über das übliche Korrektur- und Transportverfahren erfasst und transportiert werden. Die Nutzung des Standardbereichs hat genau dann Vorteile, wenn Endbenutzer in ihren Mandanten eigene Queries (ad-hoc-Berichte) entwickeln wollen, die nicht für eine systemweite Verwendung gedacht sind. Zwar ist der Transport von Query-Objekten auch möglich, er erfordert jedoch eine manuelle Vor- und Nachbereitung (Export und Import mit Hilfe des Transportwerkzeuges der Query). Nähere Informationen hierzu finden Sie im Abschnitt Transport von Objekten des Standardbereichs.
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 InfoSet aus dem Globalen Bereich anzulegen.
Hinweis
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.
Die Benennung von Queries, Benutzergruppen und InfoSets wurde in den vorangehenden Abschnitten bereits erläutert. Bei der Benennung von Query-Objekten im Globalen Bereich können Namenspräfixe verwendet werden.
Hinweis
Einen Namenspräfix dürfen Sie nur verwenden, wenn Sie eine entsprechende Lizenz erworben haben.
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:
Namen von InfoSets können die Form '/präfix/infoset' haben
Der gesamte Name eines InfoSets einschließlich Präfix kann 24 Zeichen lang sein.
Namen von Benutzergruppen können die Form '/präfix/benutzergruppe' haben.
Der gesamte Name einschließlich Präfix kann 12 Zeichen lang sein.
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.
Präfixe dürfen nur bei InfoSets und Benutzergruppen im Globalen Bereich verwendet werden. Die korrekte Verwendung von Präfixen wird durch den Workbench Organizer kontrolliert.
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/'.
Hinweis
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 Namensraum 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.
er Wechsel zwischen den Arbeitsbereichen ist in jeder Komponente zur Pflege von Query-Objekten über die Funktion 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 Funktionen stehen in beiden Arbeitsbereichen zur Verfügung.
Im 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.
Da der globale Arbeitsbereich an den Workbench Organizer angeschlossen ist, muß beim Anlegen von Query-Objekten eine Entwicklungsklasse vergeben werden. Das Query-Objekt wird beim Anlegen und Ändern in einem Korrekturauftrag erfaßt.
Sie haben die Möglichkeit, im Globalen Bereich Query-Objekte als lokale Objekte (temporäre Entwicklungsklasse, insbesondere $TMP) zu vereinbaren. (Dies entspricht dem Anlegen eines Query-Objektes im Standardbereich). Bei der Vergabe und Änderung von Entwicklungsklassen existieren allerdings einige Einschränkungen:
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.
Benutzergruppen und InfoSets können beliebigen Entwicklungsklassen zugeordnet werden.
Queries können nur dann einer nicht temporären Entwicklungsklasse zugeordnet werden, wenn die betreffende Benutzergruppe und das zugeordnete InfoSet ebenfalls in einer nicht temporären Entwicklungsklasse liegen. Falls beim Anlegen einer Query festgestellt wird, daß entweder das zugeordnete InfoSet 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.
Hinweis
Zur Vereinfachung wird empfohlen, Benutzergruppen und InfoSets im Globalen Bereich immer einer nicht temporären Entwicklungsklasse zuzuordnen. Dann kann für jede Query eine beliebige Entwicklungsklasse gewählt 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 InfoSets 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 InfoSets zu Benutzergruppen mit transportiert, die Zuordnung von Benutzern zu Benutzergruppen dagegen nicht.
Ein Wechsel der Entwicklungsklasse kann in den Komponenten zur Pflege der verschiedenen Query-Objekte über die Funktionen , bzw. vorgenommen werden. Entsprechend der oben formulierten Regel zur Vergabe von Entwicklungsklassen gelten jedoch folgende Einschränkungen:
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.
Bei InfoSets ist ein Wechsel von einer nicht temporären Entwicklungsklasse in eine temporäre Entwicklungsklasse nur sinnvoll, wenn alle Queries über diesem InfoSet in einer temporären Entwicklungsklasse liegen.
Bei Queries ist ein Wechsel von einer temporären Entwicklungsklasse in eine nicht temporäre Entwicklungsklasse nur sinnvoll, wenn das zugeordnete InfoSet 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.
Hinweis
Aus technischen Gründen ist es 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.
Ein Wechsel der Entwicklungsklasse ist nicht mehr möglich, 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 InfoSet durch Umbenennen in einen Namensraum 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.
Bei der Funktion Umbenennen für InfoSets und Benutzergruppen ist zu beachten, daß neben dem umzubenennenden InfoSet bzw. der umzubenennenden Benutzergruppe auch alle abhängigen Queries geändert werden müssen. Sollen ein InfoSet oder eine Benutzergruppe umbenannt werden, so müssen in der Regel neben dem InfoSet 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 Globalen Bereich als einen einzelnen Mandanten, so entspricht das Kopieren eines Objektes vom Standardbereich in den Globalen Bereich bzw. umgekehrt dem Transport eines Objektes von einem Mandanten in einen anderen. Aus diesem Grund wird das Kopieren von Query-Objekten zwischen den Arbeitsbereichen genauso wie im Standardbereich realisiert. Siehe auch Kapitel Query-Objekte transportieren.
Hinweis
Der Austausch von Query-Objekten zwischen den Arbeitsbereichen kann nur von einem Nutzer vorgenommen werden, der die Berechtigung hat, Transporte durchzuführen (Berechtigung zur Pflege von InfoSets und Benutzergruppen).
Achtung
Wenn ein oder mehrere Query-Objekte vom Standardbereich in den Globalen Bereich (oder umgekehrt) kopiert werden, gehen sämtliche Beziehungen zwischen Original und Kopie verloren, es entstehen zwei von einander völlig unabhängige Objekte. Die Kopie eines Objekts vom Standard- in den Globalen Bereichs allein zum Zweck eines einfacheren Transports sollte daher unbedingt vermieden werden. Wenn ein Objekt zunächst im Standardbereich entwickelt wurde und nun vom Globalen Bereich aus transportiert werden soll, ist es auf jeden Fall sinnvoll, dieses Objekt anschließend nur noch im Globalen Bereich zu bearbeiten. Um Missverständnisse zu vermeiden sollte das ursprüngliche Objekt im Standardbereich eventuell gelöscht werden.
Wenn Sie im Globalen Bereich Varianten von Queries transportieren möchten, so müssen Sie diese Varianten als Systemvarianten anlegen Der Name einer Systemvariante beginnt mit SAP& bzw. CUS&. Andere Varianten können nicht transportiert werden. (Vergleichen Sie dazu auch die Dokumentation zu Varianten auf dem Einstiegsbild zur Variantenpflege).