ABAP Query contains a series of improvements in Release 4.0. These are listed in this document.
In Release 4.0A, the facilities for developing reports using Query have been considerably improved by the introduction of work areas. To help to explain work areas, it is worth summarizing the key principles of how Query has worked up until now.
Until now, all query objects (queries, functional areas, user
groups) were created and administered on a client-by-client basis.
Within a client. the objects were interrelated, and formed a
closed, consistent dataset. There was no link between query objects
and the Workbench Organizer; in other words, you could not
transport them in the usual way.
The advantage of this system was that users could create ad-hoc reports in their own clients that were not intended for system-wide use. However, this was also a disadvantage when developing queries that were to be used in all clients of a system or in different systems. In particular, a link to the Workbench Organizer was required in these cases to enable developers to create, change and transport query objects in the usual way. It was actually possible to transport query objects, but this required manual preparation and post-processing (export and import, using the query transport tool). This disadvantage was also evident in query objects supplied by SAP: The transport datasets had to be imported into each client manually.
The concept of work areas will help to avoid these disadvantages.
A work area comprises a closed, consistent set of query objects. In this sense, Query used to have a single work area, in which all query objects were stored client-by-client and were not linked to the Workbench Organizer. The characteristics of this work area have not changed. This means:
For the end user, working in a work area, nothing has changed. Users will still be able to work in the way they have before, although the new individual maintenance components (see below) are, of course, available. This work area is called the 'standard area'.
In Release 4.0A, a new work area has been introduced, called the
'global area'. It has the following characteristics:
All Query objects in the global area are system-wide, that is, they can be used in all clients. These objects are also linked to the Workbench Organizer, and can therefore be transported using the normal correction and transport procedures. There is no longer any need for special manual preparation or post-processing when you transport them. This makes the global work area particularly useful for developing Queries that are intended to be used centrally. All queries supplied by SAP from Release 4.0 onwards belong to this area.
Like the standard area, the global area consists of a closed and consistent set of query objects. Relationships between objects in different work areas are not possible, so you could not, for example, create a query in the standard area using a functional area from the global area. There is a special copying process for exchanging query objects between the two work areas. The query objects in each work area belong to an enclosed namespace. This means that objects with the same name but a different function can exist in different work areas.
You can change between the work areas from any query object
maintenance component by choosing Environment ->
Work areas. A window appears in which the work areas
are displayed, along with their long text. You can then choose the
work area you want to work in. The global area is displayed on the
initial screen of the maintenance components, whereas the standard
area is not. The maintenance components contain the same functions
in both work areas.
To display the technical details for a work area, choose Information on the screen where you choose the work area. As well as the long text, the system displays whether the query objects are client-specific, and whether the work area is linked to the Workbench Organizer.
Each work area contains all of the functions required for
maintaining query objects. Since the global work area is connected
to the Workbench Organizer, you must assign a development class to
every query object you create. You can declare query objects as
local objects (temporary development classes, particularly $TMP).
This was always the case previously.
There are certain restrictions regarding assigning and changing development classes for query objects.
For simplicity, SAP recommends that you never assign user groups or functional areas in the global area to a temporary development class. You can then choose any development class for any query.
You can change the development class of an object by choosing one of the following from the maintenance functions Query -> More functions -> Change development class..., Functional area-> More functions -> Change development class... or User group -> Change development class . The following restrictions apply, in accordance with the above rules:
The Change development class functions
in the various maintenance components check whether you are allowed
to move an object to any other development class. If this is not
possible, the system displays a warning. After this, you can change
the development class. For technical reasons, you can also change
development classes even though the change is against the rules
listed above. For this reason, the system checks afterwards to see
whether the change was permitted or not. If it was an unpermitted
change, the system will prompt you to undo it. If you do not, there
is a risk that your data will be inconsistent after future
Note also that you cannot change the development class of an object that has already been transported into a non-temporary development class.
It may be necessary to change the development class of a query object that you want to rename. If you want to assign a user group or a functional area to a namespace (see the following section for more details), its development class must also belong to the same namespace. In this case, you must choose an appropriate development class for the object at the same time you rename it. If you do this with a user group, you must also reassign all of its queries to new development classes.
All query objects in the global area that are assigned to a
non-temporary development class must be assigned to a correction
request when you create them and when you change them. The
exception to this are changes that have the characteristics of
customizing settings. This enables you to change the assignment of
users to user groups or the assignment of functional areas to user
groups without having to put these changes in a correction request.
When you transport objects using the Workbench Organizer, the
assignment of functional areas to user groups is also transported.
However, the assignment of users to user groups is not. For further
details, see the "New features in transports" section.
Changing queries in the global area also includes such functions as Copy, Rename, Delete, Compare, Generate and so on. Remember that when you rename a functional area or user group, you must also change all of the dependent queries. Should you need to rename a functional area or user gorup, you will normally need to enter a series of queries in the correction request as well. The object can only be renamed when all of the necessary objects have been entered in the change request.
There is a special procedure for copying query objects between different work areas, since each work area forms a sealed, consistent unit. When you copy objects, you therefore nmeed to make sure that they are consistent with their new work area. If you regard the new global area as a special client, you will see that the previous procedure for transporting query objects from the standard area contains the required functions. Copying an object from the standard area into the global area (or vice versa) is the equivalent of transporting an object between clients. This makes it possible to copy query objects between work areas using an extension of the previous transport procedure. For further details, see the "New features in transports" section. dazu ist This kind of implementation does, however, mean that only one user can copy query objects between work areas - the user with authorization to transport objects (authorization to maintain functional areas and user groups).
In Release 4.0, there is an extended namespace for objects such
as programs, tables, data elements and so on. The two benefits of
this are longer names and a clear distinction between SAP objects
and customer objects. The extended namespace also applies to query
objects (queries, functional areas, user groups), allowing you to
assign them longer names and name prefixes. A name prefix has the
form '/prefix/'. They can be up to 10 characters long, including
the separators '/.../'.
Some more precise rules:
When you maintain query objects, the system checks the naming
syntax described above. You can only use name prefixes for query
objects in the global work area. They are only significant in this
area, since SAP objects can be imported into this area during an
upgrade. Query objects imported by SAP have the reserved name
When you use prefixes in the global area, remember that the object whose name begins with a prefix must be in a development class with the same prefix. The Workbench Organizer checks this condition.
You should be particularly careful of the fact that queries
inherit their prefix from their user group if you are creating
queries in a user group whose prefix belongs to SAP, an SAP partner
or another R/3 customer. These user groups can be transported into
your system. The query is then one of the objects in the namespace,
which is determined by the user group prefix.
For example, a query in user group '/SAPQUERY/xx' has the prefix '/SAPQUERY/'. It then belongs to the set of objects supplied by SAP. There is then a risk that this query could be overwritten in the next upgrade.
SAP therefore recommends that you do not create any new queries in these groups, but that you instead always use your own user groups.
The introduction of work areas and the namespace required a new
procedure for assigning names to generated query reports. From
Release 4.0 onwards, the name of a query report will be constructed
mm Client encoded (standard area) or
ZZ (global area)
bbbbbbbbbbbb User group name
qqqqqqqqqqqqqq Query name
Spaces in report names are replaces by =. The TEST query in user group USER1 in the global area would therefore generate the report:
All query reports belong, as before, to development class $TMP, and cannot therefore be transported. This also applies to queries in the global area that belong to a non-temporary development class.
In Release 4.0A, basic lists will contain the new option of couting the number of occurrences of a field in the dataset read. The effect of this is analogous that of the 'Sum' option.
The 'Sum' option calculates the total sum of a numeric field. That means that each time the field is found in the dataset, its value is added to the running total. The total is then displayed at the end of the basic list. In control levels, you can also display subtotals. A subtotal is the sum of the values of the fields belonging to the control level, that is, with a particular sort string.
When you use the 'Count' option for a field, a counter increases by 1 each time the field occurs in the dataset read by the system. The total number of occurrences is output at the end of the basic list in the same way as a basic list. You can also output subtotals for the count at the end of each control level. These subtotals show how many values of the field are assigned to the control level.
If you choose the 'sum' and 'Count' options for a field, the counter is the sum of the elements counted. You can also use 'count' for non- numeric fields.
To activate the counter for a field, select the corresponding radio button on the 'Line construction for basic list' screen. The total number of field values read is then displayed at the end of the report. If you want to display subtotals for each control level, select the appropriate option on the 'Control levels' screen.
Since Release 3.0C, the screens for defining graphic options
have contained the option 'Set at runtime'. If you set this option,
you could set the number of values to be displayed dynamically at
runtime. This option has been changed in Release 4.0. All display
specifications can now be made dynamically at runtime (see also the
section 'New features in query lists'). The options set in the
graphics screen are used as defaults.
The 'Set at runtime' option is set by default from Release 4.0A whenever you define a basic list, a statistic or a ranked list.
Until now, if you defined more than one sublist (basic list,
statistics, ranked lists) in a query, they were displayed in a
fixed order: First the basic list, then the statistics (in the
sequence in which they were defined), and then the ranked lists
(also in the sequence in which they were defined). However,
sometimes a different sequence can be more appropriate - for
example, a statistic followed by a basic list containing the
individual values contributing to the statistic.
In Release 4.0A you can now explicitly declare the sequence of sublists by choosing Edit -> Output sequence . When you call this function, a dialog box appears, listing all of the defined sublists and the sequence in which they ae displayed. Next to each sublist is an input field, in which yu can enter a sequential position for it between 1 and 90. If you do not enter a position (default setting), the sublists without positions are displayed after those with numbers.
If two or more sublists have the same number, they are displayed in their previous sequence (basic list, statistics, ranked list).
As before, you can maintain variants for a query or its assigned
report by choosing Goto -> Maintain
variants . If you are working with queries in the
global area that are assigned to a non-temporary development class,
you should note the following: You can create system variants for
this kind of query (a system variant name begins SAP& or
CUS&. See the variant documentation on the initial screen of
the variant maintenance transaction). The system variants of
queries are transport objects in the Workbench Organizer. You must
therefore always include them in a correction request, and you can
transport them using the Workbench Organizer. System variants have
the advantage of being available in all clients. You should always
use them if you want to create transportable variants in the global
However, system variants of queries cannot be locked. This means that a system variant can be changed by users once it has been entered in a correction request, even though the users are not registered for the correction. When the transport request is released, the system variants are transported in their current state.
Until now, you could expand summarized basic lists by choosing Edit -> Choose detail . This function was assigned to function key F2, so that double-clicking a line of a basic list expanded the list, if that was possible.
The same function is now available by choosing Edit -> Detail view . This is no longer assigned to F2. Instead, the report-report interface (Goto -> Call report ) is now assigned to F2. Double-clicking a line now calls a further report using the report-report interface, if the query is registered as a sender in the interface.
If you selected the 'set at runtime' option for graphics (see above), you can set all display options for a query dynamically at runtime - the graphic type, text, colors and number of values to be displayed. You can also display a remainder. This is the sum of all values in the selected column that were not selected for graphical display. Since up to 32 values can be displayed, you can choose up to 31 single values if you also want to display the remainder.
The component for maintaining functional areas has been completely redesigned in Release 4.0. The purpose of this was to make it more user-friendly, and to provide a better overivew of the relationships between functional groups, logical database tables, additional tables and additional fields.
The new maintenance transaction also contains new functions. Further details of this are provided below, but first, there is a description of how the previous functions were implemented.
The initial screen of the component was extended to include an overview of the available functional areas.
For each functional area, you can display an action log by choosing Extras -> Status info . A window, containing the author and the last 10 people to change the functional area (including dates), is displayed.
Up until now, when you created a functional area, the 'Title and database' and, if required, the table join definition screen, were displayed. These screens remain unchanged in Release 4.0, both in appearance and function. When you define a table join, it is now possible to include a table in the join more than once. If you do this, you must define an alias name for each repeated use. Using alias names is described below.
The three-part screen previously used as the initial screen has been replaced by a new screen, on which the functional area is displayed as a tree structure. The tree of a functional area always contains two subtrees.
The first subtree contains the functional groups. This is a flat hierarhcy, that is, all of the functional groups are assigned to the same level. Appended to each functional group are the fields assigned to it.
The second subtree describes the structure of the dataset to be read. If you are using a logical database, this subtree corresponds to that of the logical database, and contains all tables with the hierarchical relationships defined between them. For sequential datasets, direct read and data supply programs, the second subtree only contains the structure for which the functional area is defined. For table joins, the second subtree contains all of the tables in the join. Since a join always returns a flat structure, the tables are all assigned to the same hierarchical level. For functional areas using logical database in the HR application, the second subtree contains all of the infotypes that are copied into the functional area by the functional area generator. The infotypes themselves are all assigned to the same hierarchical level in the tree.
In the second subtree, the fields from the Dictionary definition of each table are appended to their respective tables, as are the fields of the additional tables, and additional fields assigned to the tables.
Using a structure tree to display functional areas has certain advantages. Firstly, the hierarchical relationships between the tables as defined in the logical datables are visible. Secondly, you can use the usual functions available with structure trees (expand, summarize, position and so on). For example, you can display the fields from more than one table. To display the fields for a table, you can either double-click the table name, or single-click the hotspot next to the table name. If you do the same thing when the field names are displayed, the system hides them again.
To create a functional group in the first subtree, choose Edit -> Functional group -> Create functional group (or click on the create icon next to the root of the first subtree). A dialog box appears, in which you can define one or more new functional groups. As was previously the case, you must define an identification code and a long text for each functional group. Once you have made the required entries, choose Continue to return to the previous screen. The new function group appears in the first subtree.
There is also a function for changing existing functional groups ( Edit -> Functional group -> Change functional group). A dialog box appears, in which you can only change the long text of the existing function group.
To delete a functional group, place the cursor on it and choose Edit -> Functional group -> Delete functional group. As in previous releases, the assignment of fields to the functional group is lost when you delete the group.
To assign fields to functional groups (see below), you first need to select a group. The marked group is highlighted in the tree. It is also displayed in the header line of the screen. There are two ways to select a functional group from the tree:
In either case, the functional area selected is then displayed at the top of the screen.
You assign a field to a particular functional group by assigning
the functional group ID to the field. However, you can no longer
enter the ID directly.
Instead, you must first display the field on the screen by expanding the fields of the appropriate table. Each field is displayed on one line, with its technical name, a special icon , the ID of the functional group (if applicable) and the long text for the field. If the field is not assigned to a functional group, no functional group ID is displayed, and the icon displays a minus sign. If it is assigned to a functional group, the ID is displayed, and the icon displays a plus sign.
If you single-click the minus sign icon, the field is assigned to the selected functional group. If you single-click a plus sign icon, the assignment of the field to the functional group is dissolved. Both functions nwork in the first subtree for functional groups. As before, you can only dissolve the assignment of a field to a functional area if the field is not used in any queries.
Using the above procedure, you can only assign fields to the
functional area that is currently selected. If you want to assigne
fields to more than one functional area, you will need to repeat
the procedure for each one.
There are two ways to change the functional group to which a field is assigned. The first method is to dissolve the relationship between the field and its current functional group, before assigning it to a new one. However, this only works if the field in question is not currently being used in any queries. If it is already in use, the system will not allow you to dissolve the existing function group assignment. In this case, you will have to go to the field text maintenance screen (see below).
To maintan the text for a field (long text and header), position the cursor on the field and choose Edit -> Change field. A dialog box appears, in whcih the functional group assignment, long text and headers are displayed.
On this screen, you can reassign a field from one functional group to another. To do this, you must use the possible values help for the field where the functional group ID appears.
The fields in which the long text and headers are displayed are input fields, so you can overwrite the displayed texts. The maximum length for headers remains 30 characters. However, they should not be longer than the output length of the field, as they will otherwise be truncated when the query is displayed. To help you, a ruler is displayed above the input field for the headers. The output length for the field is also displayed.
For each table in the logical database, you can, as before, define additional tables, additional fields, and coding for the GET event and for record processing. These enhancements are now summarized for each table. To maintain the additions for a particular table, position the cursor on the table name and choose <PFG>Goto -> Extras. A dialog box appears, containing all additional tables, additional fields and source code assigned to the table.
To change or delete an addition, position the cursor on the corresponding line and choose Change or Delete respectively. If you choose Change, the system branches to the corresponding maintenance screen.
To define a new additional table, additional field or new source code, choose Create . A new dialog box appears, on which you must select the type of addition you want to define. If you define an additional table or additional field, you also need to enter the table or field name. When you have done this, choose Continue. The system displays the maintenance screen appropriate to the type of addition.
The maintenance screen for additional tables contains, as before, the sequence number and a SELECT statement, for which you need to specify the WHERE clause. Unlike the previous maintenance transaction, the number of key fields in an additional table is no longer restricted to 10. Instead, you can use as many as you like. The new option 'Buffer internally' is described below. To check the syntax of your SELECT statement, you can choose Check additional table . Otherwise, the syntax is checked for the whole functional area when you choose Check or Generate.
The maintenance field for additional fields contains the sequential number and input fields for the long text, the header and other details for the type definition. The coding for the additional field is not displayed on this screen. To maintain the coding, choose Editor to branch to a program editor. To check the syntax of the coding, you can use the Check function in the Editor. Otherwise, the syntax is checked for the whole functional area when you choose Check or Generate.
When you maintain GET coding, a dialog box appears, in which you must give the sequential number for the coding. Next, the system branches to a program editor. To check the syntax of your coding, choose Check in the Editor. Otherwise, the syntax is checked for the whole function area when you choose Check or Generate.
You can also define coding for the GET LATE event for each table
in the logical database. To define or change this coding, position
the cursor on the table name, or on a field in the table, and
choose Goto -> Coding -> GET
You can edit other coding (DATA, START-OF-SELECTION, END-OF-SELECTION and TOP-OF-PAGE), as before, by choosing the appropriate option from the Goto menu. This branches to a program editor. To check the syntax of your coding, choose Check in the editor. Otherwise, the syntax will be checked for the whole functional area when you choose Check or Generate.
Because there is no automatic syntax check on each maintenance screen, you can, in fact, store code containing errors if the cause of the error is not in the coding itself (such as a missing definition of an auxiliary field in the DATA coding). However, each maintenance screen does have a syntax check, as mentioned above. C
Parameters and program selections (selection criteria) in the functional area are now summarized under 'Selections'. To maintain a selection, choose Goto -> Selections . A dialog box appears, in which the parameters and selection criteria are listed. For functional areas using logical databases, this overview contains all of the selections automatically presented by the logical database (standard selections). You cannot change or delete a standard selection.
To change or delete a selection definition, position the cursor on the appropriate line and choose Change or Delete. If you choose Change , the system branches to the appropriate maintenance screen (see below)
To define a new selection, choose
Create. A dialog box appears, in which
you need to specify whether you are creating a parameter or a
selection criterion. You also need to enter a name for the
selection. Then, choose Continue to move
on to the appropriate maintenance screen. The maintenance screen
contains all of the details hitherto contained in the old
Unlike additions (additional tables, additional fields, GET coding), the system automatically checks the syntax of the selection.
The Check and Generate functions have been extended to recognize and report more errors. The log now also contains warnings. As before, if the system discovers an error, it does not generate the functional area. If, on the other hand, it discovers a warning, it does generate the functional area, but warns you that there are things you should check.
Before Release 4.0A, it was not possible to attach an additional table to a functional area more than once. However, there are occasions when it makes sense to do so. For example, in logical database F1S (the example used in the documentation) there are two fields for the origin and destination airports in table SPFLI. Both fields contain an abbreviation for the airport, and have a key for table SAIRPORT, which contains the long texts for the airports. Until now, it was only possible to use SAIRPORT once as an additional table to SPFLI. This meant that you could only get the long text for one of the two airports in this way, and you had to get the other one using an additional field.
Table joins presented a similar problem. Until now, you could only include a table in a join once, even though Open SQL allows tables to be included more than once.
It was also not possible to include tables from a logical database or a join as additional tables.
From Release 4.0A, Query has solved this problem using alias tables. The basic idea is that you can assign several alias names to a table, which you can then use to address the table more than once.
To assign an alias name to a table, choose Goto -> Alias names. A dialog box appears, in which the alias names are listed, along with the tables to which they belong. Alias names must be unique within a functional area, must always refer directly to a table definition in the ABAP Dictionary, and may not have the same name as a definition in the Dictionary.
To create a new alias name, choose Create on the alias overview screen. A further dialog box appears, in wich you enter the alias name and the table from the ABAP Dictionary to which it refers.
To delete an alias name, position the cursor on its entry in the overview and choose Delete . You can only delete an alias if it is not in use in the functional area.
Example: Using a table twice as an additional table in a
You can use the table once under its original name. To use it a second time, you need to create an alias name for it. Note that the fields of the table now appear twice in the functional area with the same long texts and headers. Therefore, if you use a table more than once, you should also change the long texts and headers that are assigned to the functional group.
The procedure for using a table twice in a join is the same.
When you attach an additional table, you can use the new 'internal buffer' option to improve the performance of your query reports.
If this option is set, all of the records read in queries that use this table as an additional table are read into an internal table. If a table record is required, the system checks whether the record already exists in the internal table. Only if this is not the case does the system get the record fron the table using a SELECT SINGLE statement and read it into the internal table. This means that records from an additional table are never read more than once during a query.
You should only use the 'Internal buffer' option if you are sure that table records would otherwise be read more than once during a query. If this is not the case, using the internal buffer does not justify the memory needed by the internal table. If your table has a lot of fields, you should check whether the memory requirement is justified by the time saving.
A typical example of when to buffer an additional table internally is the case described in the previous section, where the table SAIRPORT is used as an additional table for table SPFLI to display the long text for an airport. In this case, you assume that records from SAIRPORT will normally be read more than once.
In Release 4.0A, the maintenance component for functional areas contains the function Functional area -> More functions -> Adjust. This is useful if the technical attributes of database table fields that are used in the functional area have changed (type, length, output length, use as currency or quantity field). However, this kind of change should be something of an exception.
If there have been changes like this, the system displays a
warning when you generate the functional area containing the
differences. The adjustment function then allows you to copy the
changed technical attributes into the functional area. First, the
same screen is displayed as in the warning during generation.
However, the screen now contains the
Adjust function, allowing you to copy the
attributes from the ABAP Dictionary.
Note that you should then adjust all of the queries in that function area, to ensure that the changes are made globally.
The work area section has already mentioned that the user groups in the global area are linked to the Workbench Organizer. This section describes how to assign users and functional areas to uuser groups without having to enter the changes in a change request. This is a different procedure to maintaining user groups.
Th Create and Change functions on the initial screen of the user group maintenance components display a dialog box, in which you may only maintain the long text for the user group. In the global area, these two functions lead to a correction request being created. To assign users and functional areas to a user group, choose Assign users and functional areas.
To create a new user group, enter the name of the group, and choose Create . In the following dialog box, enter the long text for the user group and then choose Save . In the global area, you will then have to enter a development class and, if necessary, a correction request. When you choose Save, you return to the initial screen of the user group maintenance component. Now choose Assign users and functional areas to branch to these two screens.
If you choose Assign users and functional areas, Assign users or Assign functional area in the global area, you do not have to create a correction request, since these settings are made independently of the Workbench Organizer. The same applies to the Assign to user groups function in the functional area maintenance component.
When you copy a user group in the global area, you should note the following: First, you must assign the new user group to a development class and, if applicable, enter a correction request. If you choose a non-temporary development class and select the option Copy queries, you must also enter a development class and correction request (if applicable) for each query.
The introduction of the work areas means that there are three different kinds of transport for query objects:
In the first two cases, the transport takes place within the same work area.
Objects in the global area are client-independent. If you transport these objects, they are always transported into other systems.
In the global area, an object's development class determines whether that object can be transported or not (see the section on work areas). Local objects (in temporary development classes) cannot be transported. All other objects are included in a correction request when you create them. They are transported in the normal way using the Workbench Organizer (when the correction and transport requests are released). F
Unlike transporting objects from the standard area, no preparation or post-processing is necessary (exporting and importing transport data sets). This means that objects transported into a system using the Workbench Organizer can be used straight away in the target system. However, when you transport using the Workbench Organizer, the system does not check the objects as it does when you import the transport datasets in the standard area. It is therefore possible for inconsistencies to occur in the datasets of the query. A typical case is where a query is transported in to a system where its associated functional area does not exist. When you transport query objects in the global area, you should always check carefully that the dependent objects exist (and in the right version) in the target system. If this is not the case, you must transport them along with the query object.
You can only transport query variants if they have been defined as system variants (see the section on new features in query maintenance).
When you change a query object in the global area that belongs to a non-temporary development class, the system records the following entries in the correction request:
The way in which query objects are stored in the global area has been changed, such that all objects are stored in their own text tables. This makes it possible to translate the objects using the SAP translation tool. The language comparison component for query objects (Transaction SQ07) still exists.
Objects in the standard area are client-specific. Transporting these objects can therefore mean that these objects are transferred to other clients within the same system without being transferred into other systems.
The procedure for transporting objects in the standard area has
not changed. You still use Environment ->
Transports in the maintenance components for
functional areas and user groups. In principle, it is possible to
transport all objects from the standard area.
Instead of transport table TAQTS, table AQTDB is used in Release 4.0. Text tables AQTXTQ and AQTXTBS are no longer used. In Release 3.x, these were used to record all texts for the transported objects. This was to enable language comparison for the delivery query objects.
When you create a transport dataset (export), the system creates a transport request in the Workbench Organize, as before. However, this transport request has been changed from transport type T to type K. This ensures that, when the transport request is released, it is transported not only into the target system, but also into all intermediate target systems in the transport route. This change was implemented in Release 3.0F.
All entries in the report-report interface for which a query is registered as a sender are included in the transport request for that query. This change was also implemented in Release 3.0F.
Copying objects between different work areas is the same as transporting objects between two clients within a system. For this reason, the query transport tools (Environment -> Transports) has been extended. You can now only copy objects between work areas if you have the authorization to maintain functional areas and user groups. In principle, you can copy any object from one one work area to the other.
The initial screen of the query transport tool contains two new functions:
Both functions combine export and import in a single step. However, no transport dataset is created in transport table AQTDB, and there is no transport request created in the Workbench Organizer. The system makes the usual checks during the import and generates a log.
The function 'Copy global area -> standard area' copies
objects from the global area into the standard area. This
corresponds to exporting the objects from the global area, and
importing them into the standard area. The 'Test run', 'Allow
overwrite', and 'Transport query variants' options are
self-explanatory. You select the objects from the global area that
you want to transport in the usual way.
The system ignores the development class to which the objects belong in the global area. This means that the objects have no development class or are local objects in the standard area.
The function 'Copy standard area -> global area' copies
objects from the standard area to the global area. This corresponds
to exporting objects from the standard area and importing them into
the global area. The 'Test run', 'Allow overwrite', and 'Transport
query variants' options are self-explanatory. You select the
objects from the standard area that you want to transport in the
The development class of the copied object in the global area is determined as follows: If an object in the global area is overwritten, the copied object inherits the development class of the overwritten object. If the copied object in the global area is a new object, a dialog box appears, in which you must assign a development class to the object. Depending on the type of development class you choose, you might then have to assign a correction request. If the copied object in the global area is a new query whose functional area or user group belongs to a temporary development class, the query is assigned to development class $TMP. In this case, the system does not display the dialog box in which you would normally set the development class.
In functional areas, a series of texts is used for which standard proposals are taken from the Dictionary (long texts and headers for fields, long texts for tables and so on9. When you compare languages for functional area, these text need to be entered in the target language, even though the corresponding texts in the target language already exist in the Dictionary.
The language comparison now allows you to copy these target language texts from the Dictionary and use them as defaults for the comparison. This greatly simplifies the process and avoids work having to be duplicated.
There is a new function for the language comparison in
functional areas:Choose Edit -> Get standard
texts . This function gets text proposals from the
ABAP Dictionary in the target language. If the source language text
corresponds to the text from the Dictionary, the two texts are
marked as a pair. On the other hand, if the source language text is
different to the Dictionary text, the texts are marked as not being
Until now, the authorization to work with Query has been controlled using the S_QUERY authorization object. Authorizations for this object always refer to both work areas. Thus if a user is authorized to change queries, he or she may do so in all user groups in the standard and global areas in which he or she is registered.
The namespace extension means that you need to convert all of your existing query objects to work in Release 4.0A. For technical reasons, this cannot be done automatically using an XPRA program in the upgrade. Instead, you need to convert the objects in each client individually following the upgrade. Special programs will be available for the conversion.
The technical basis for storing query obejcts before Release 4.0A were the database tables AQDB and TAQTS. In Release 4.0A, these tables are replaced by 15 new tables. AQDB and TAQTS will no longer be used, but their contents willl not be deleted for the time being. This makes it possible to convert your objects at any time, or to convert them one at a time. You must convert your query objects in all clients as described below.
Before you convert your query objects, each attempt to work with queries in the standard area is met with a message, stating that you need to convert them. After the conversion, the system administrator can determine the exact time at which users will be able to work with queries in the standard area.
There are two reports for the conversion: RSAQSUMM and
RSAQSUMM creates a directory of query objects and transport datasets. It analyzes the contents of the old and new database tables, so you can also use it to check the results of the conversion. On the selection screen of the report, you can select the objects and the work areas for which you want to create the directory. The following areas are available for selection:
If it is posisble for different objects to appear in the same area, you can restrict the directory to a particular object type such as the queries of particular user groups. For each object, the directory records its name, the long text assigned to it, details about its creation and last chagne, and any further details appropriate to certain object types.
RSAQSUMM is not relevant to the conversion, but can always be used when you need to create a directory of some or all of the objects in one of the work areas.
RSAQUM40 is the program used to convert the query objects. It
reads objects (user groups, functional areas, queries and transport
datasets) from the 'old' storagem and converts them into the 'new'
one. The report can convert either all objects from the old tables,
or individual objects or groups of objects. It can only be run by
the user with authorization to maintain functional areas and user
groups. The report generates a log of its actions.
RSAQUM40 also allows you to set the time after which users are allowed to work in the standard area again.
You can set the following on the intial screen of report RSAQUM40:
SAP recommends the following to convert the query objects in a single client:
You can repeat the conversion at any time for one or more
objects. In this case, you sould run report RSAQUM40 again. This
time, use the 'Allow overwrite' option, and use a selection for the
required objects. Note, however, that any changes made since the
last conversion are lost. Once you have successfully converted all
of the query objects, you should only use report RSAQUM40 again in