In order to allow you to fulfill numerous demands with ABAP Query, so called application areas exist. An application area contains a set of discrete Query objects (queries, functional areas, and user groups).

You can differentiate between two different application areas, the standard area and the global area. Both application areas provide you with a full range ABAP Query functions.

• Standard Area

• Global Area

Both the global and the standard areas contain discrete and consistent numbers of query objects. No relationships of any sort can exist between objects from different application areas. For example, you cannot create a query in the standard area using a functional area from the global area.

Naming queries, user groups, and functional areas has already been discussed in previous sections. With global area objects, certain prefixes can be used.

A prefix is composed of '/prefix/' and precedes the actual object name. The '/' symbols before and after the prefix name are actually part of the prefix. A prefix can contain up to 10 characters including the two '/' symbols.

Pay attention to the following guidelines:

• Functional area names can take the form '/prefix/functional_area'.

• User group names can take the form '/prefix/user_group'.

• Query names take the form 'query'.

• Prefixes may only be used with functional areas and user groups from the global area. The Workbench Organizer checks to see if prefixes are used correctly.

The corresponding query object maintenance transactions check the name syntax described above. You can only work use name prefixes with query objects in the global application area. This is significant because it in this area that query objects from SAP are inserted at PUT if necessary. All query objects delivered by SAP have the prefix '/SAPQUERY/', which has been reserved for them.

You can change application areas from each query object maintenance component by choosing Environment ® Application areas. A window appears containing both application areas and their long texts.

Use Choose to choose the application area that you want. If you choose to work in the global area, this is displayed on the initial screen of the maintenance component. In the standard area no such text is displayed. The same maintenance component functions are available in both application areas.

You can display technical information about a application area by choosing Information on the screen where you chose which application area you wanted to work in. A dialog box appears where a long text is displayed along with information about whether or not the objects are client specific or linked to the Workbench Organizer.

Due to the fact that application areas are linked to the Workbench Organizer, a development class must be designated when query objects are created. Query objects are entered into a correction request whenever they are created or changed.

In the global area, you can classify query objects as local objects (using a temporary development class, usually $TMP). (This is the same as creating a query object in the standard area). There are several conditions that you should pay attention to when designating or changing development classes:

• All query objects in the global area have to be assigned to a development class (temporary development classes included). If the development class is not temporary, that is to say transportable, then the object must be entered in a correction request when it is being created or changed.

• User groups and functional areas can be assigned to any development class you want.

• Queries can only be assigned to transportable development classes if their corresponding user groups and functional areas are also assigned to transportable development classes. If, when you are creating a query, it is determined that either the functional area or user group assigned to that query is part of a temporary development class, then your query will automatically be assigned to development class $TMP. Whenever this happens, no dialog box asking you to determine a development class will appear.

You can change development classes in the various query object maintenance components by choosing either Query ® More functions ® Change development class, Functional area ® More functions ® Change development class or User group ® Change development class. However, in accordance with the rules for assigning development classes formulated above, the following restrictions apply:

• Changing a user group from a transportable development class to a temporary development class only makes sense if all of the user group’s queries are assigned to a temporary development class.

• Changing a functional area from a transportable development class to a temporary development class only make sense if all of the functional area’s queries are assigned to a temporary development class.

• Changing queries from a temporary development class to a transportable development class only makes sense if the functional areas and user groups they are assigned to are in a transportable development class themselves.

The function Change development class... checks to see if you are allowed to change an object’s development class and displays a warning if this is not possible. Otherwise you can immediately make any changes you want.

You can no longer change a development class when an object belongs to a transportable development class and has already been transported. This means that all development class changes described above must be made prior to transporting the object.

A development class change may also be necessary after a query object has been renamed. You must also ensure that the development classes of user groups and functional areas that have been renamed still lie within the accepted name spaces for the new names. In this case it is advisable to choose an appropriate development class when you are renaming the object. With user groups the individual queries within the user group must also be assigned new development classes.

When using the function Rename with functional areas and user groups be aware of the fact that in addition to the functional area or user group, all dependent queries must also be renamed. If several functional areas or user groups have been renamed, a series of queries must be included in a correction request in addition to the functional areas and user groups. The renaming process is only actually finished when all objects necessary have been entered into a correction request.

In order to copy query objects from one application area to another a special procedure must be followed to ensure that the datasets of each application area remain intact and consistent. During transfer you must check to see that the object being transferred can be inserted in the new dataset without upsetting the consistency of the latter. If you conceptualize the global area as a single client, then the whole copying process, from the standard area to the global area and vice versa, corresponds to object transport from one client to the next. Thus, you copy query objects from one application area to the next in much the same manner as you copy objects within the standard area.

If you want to transport query variants within the global area, these variants must be created as system variants. System variant names start with either SAP& or CUS&. Other kinds of variants cannot be transported. (Please see also the variant documentation available on the initial variant maintenance screen).