InfoSet Query / SAP Query / Quick Viewer

Use
With Release 4.6C the SAP Query is positioned as a Reporting tool for tabular (flat ) Reporting for all R/3
systems including the Business Information Warehouse (BW). In connection with this lies the creation of
new, or the revision of existing, tools as well as the use of some new terms.
With Release 4.6C an additional tool for maintaining queries is made available for use, the InfoSet
Query (the term InfoSet replaces the term functional area). The InfoSet query uses the HR ad-hoc query
as a template, and thus represents a generalization of the ad-hoc query for all applications. Please also
take note here of the Release information for the HR application .
The large majority of existing queries can be processed with the InfoSet query (more precise statements
on this are given further below). Inversely each query, that was created with the InfoSet query, can be
processed with the previous tools.
The tool for maintaining InfoSets (functional areas) has been completely revised.
Besides the InfoSet query as a new tool, a set of enhancements for queries and InfoSets (functional
areas) has also been realized.
1. New terms
2. InfoSet query

Overview

Query maintenance

Logging

Calling the InfoSet query

3. InfoSet maintenance
4. Enhancements to InfoSet maintenance

Generation and preassignment of field groups

Text fields

Additional structures

Coding at the time AT SELECTION-SCREEN

Fields that cannot be summed

Application-specific enhancements

5. Enhancements to the query maintenance

Roundung in basic lists

New options for selection conditions

Dynamic determination of the number of ranked list places

6. Enhancements for query runtime

Using the SAP List Viewers

New terms
The positioning of the SAP Query as a Reporting tool, that is also set in the Business Information
Warehouse (BW), has resulted in some terms being redefined.
The term InfoSet is a new name for the functional areas . No limitation to the functionality of the
functional areas is connected to this name change. All the previous options still remain available for use,
and new functions are now offered on top.
In connection with the renaming of functional areas, the term functional group has been replaced by Field
group .
The function Interactive list, that can be used for queries and that uses the ABAP List Viewer for display,
has been renamed to SAP List Viewer since the ABAP List Viewer (ALV) has been renamed in its long
form to the SAP List Viewer.

InfoSet Query
Overview
When designing the InfoSet query, the experiences gained from the HR ad-hoc query were taken into
consideration. The principle idea was that a user first reads a more or less detailed template for a query,
then makes changes according to his/her requirements, and then executes the query. The changes affect
not only the selection conditions that are available but also the values that are read and are to be
outputted by the query. The changes are always temporary, meaning that if the InfoSet query is left
without having saved explicitly, then the query definition is lost. It is, however, possible to save the
changes provided that the user has the corresponding authorization for this. An existing query can be
overwritten here, or a new query can be created.
All important entries for the query, meaning the fields that can be used, the defined selection conditions
and the query output are all made available for use on a screen. Graphical interface elements and
Drag&Drop make query handling simple and clear.
With the InfoSet query we have tried to simplify the various extensions of the query as a development tool
and as a tool for ad-hoc Reporting. This means that this tool is designed for both purposes and the
definition of a query is identical in both cases. In the section on the calling of the InfoSet query (see
below) there is an explanation as to which differences exist between the two enhancements.
The InfoSet query was designed in such a way that it can be called out of roles to enable Reporting within
the framework of a role. When calling from a role the end user is no longer confronted by the user groups
of the query, but rather only with the InfoSets that have been assigned to this particular role. The section
on calling the InfoSet query (see below) is also referred to here.

With the introduction of the InfoSet query, the SAP List Viewer (ALV, previously ABAP List Viewer)
becomes the standard output medium for the query. This mean that:

if a query is processed then the result is always displayed using the SAP List Viewer.
This means that the SAP List Viewer also takes on the previous, interactive query functions, such
as
the
connection
to
EXCEL,
Crystal,
WORD,
graphic,
and
so
on.
For the present it is also possible to generate a list (and thereby the previous standard output) to
cover any existing gaps in the functionality (in comaprison to the previous standard). For this,
however, the query must be started in a separate session.

Each query, that is created by the InfoSet query, can only contain a partial list (basic list, statistics
or
ranked
list).
The construction of queries with several partial lists is not supported by InfoSet query.

Each query, that is generated by the InfoSet query, can only contain a single list.
In the case of basic lists this also means that the selected fields for output can no longer be
distributed on several lines. This was, however, also the previously case when outputting by the
List Viewer, to be more precise: the values for lists with several lines were transferred for display
in
the
List
Viewer
in
a
table,
meaning
a
one-line
list.
The construction of lists with several lines is not supported by the InfoSet query.

Furthermore, it is not possible to define and use local fields with the InfoSet query.
It follows on from these statements that an existing query should not be processed using the InfoSet
query if it

contains several partial lists or

contains a basic list of several lines that (even in the previous state) cannot be displayed by the
SAP List Viewer (in any case such queries process data from parallel nodes of a logical
database) or

contains local fields.

If such a query is used as a template for the InfoSet query (function Open query , see below), then only
the part of the query is transferred that can be processed by the InfoSet query (first partial list, first line of
a basic list with several lines, no local fields). Warnings are displayed with this. If this query is overwritten
(function Save , see below), then the untransferred parts are lost.
As mentioned above, temporary queries are always used for working in the InfoSet query. The template
for such a temporary query is either an InfoSet (only the fields currently available are then recognized) or
a query that already exists (in this case selection conditions and an output have also already been
defined). In every case, however, it is a template, meaning several users can use the same query at the
same time as a template, and each one can make his/her required changes without affecting anyone
else. Only when a user decides to save the changes he/she wishes to makes, does the user need to
determine via a dialog how the current state of his/her temporary object should be saved. It is possible to
overwrite an existing query or to create a new query.
It was not possible to transfer all the options of the SAP query with all the details in the InfoSet query
version released for 4.6C. It is, therefore, still occasionally necessary to refer to the previous transaction
SQ01. There is generally no problem switching between InfoSet query and transaction SQ01 (see below,
section on calling the InfoSet query). Some restrictions have already been detailed above. The target of
further development is to also make available in the InfoSet query all the important and required options
in a similar or new form.

Query Maintenance

Having called the InfoSet query, a tripartite screen is displayed on which all the required information for
maintaining a query is contained. Apart from some dialog boxes, this is the only screen in the InfoSet
query.
The InfoSet currently being worked with is displayed on the upper left part of the screen. You can have
different displays (as a tree or just a catalog). A further box can be found under the InfoSet display, in
which technical information about the selected field can be displayed if required.
The selections used when reading the dataset for selection are displayed on the top right part of the
screen. You enter the selections in a selection control (ALV grid that is ready-for-input) or using a
selection screen.
The output list is displayed using an ALV grid on the lower part of the screen. This grid functions are a
preview of the output to be expected and can be used for determining options such as sorting, summing,
and the output sequence. The results list can also be displayed directly in this grid.
What is displayed on the partial screen after calling up the InfoSet query depends on the template . The
parameters when calling (see below, section on calling the InfoSet query) and, if these are not set, the
previous steps (SET/GET parameters) determine with which InfoSet or query the processing to begin. If
an InfoSet is defined as a template then only the upper lift part of the screen is taken to display the
InfoSet. If a query is defined as a template then all the partial screens are used, in accordance with the
previous definition of the query. It should also be pointed out that reading a query as a template does not
lead to this query being locked, and that the same query can consequently be used by any number of
users as a template at any one time.
The upper left part of the screeb contains the InfoSet fields. You can switch the display between the
variants

field group display (standard),

logical database structure display (if the InfoSet was created using a logical database) or

field catalog display (display of fields for a field group or all fields of the InfoSet)

With the first two displays the field groups or structure nodes of the logical database can be expanded or
collapsed with the usual tree functions in order to get the section that is optimal for the current step onto
the screen. InfoSet selection fields, meaning fields for which a selection was defined in the InfoSet or
logical database, are grouped together to a special field group (Selection fields from InfoSet). You can
switch between different displays by using the corresponding pushbuttons.
Each InfoSet field is indicated with an icon. The icons Simple field (ICON_SIMPLE_FIELD) and Field
with text (ICON_FIELD_WITH_TEXT) can occur. In the first case the field is used for selection and output
as usual. In the second case a text can be automatically generated for each value of the field. You must,
therefore, decide when choosing such a field for selection, or output, whether you want to use the value of
the field, the text belonging to the value, or both. With such a field, the value is used as standard when
choosing for selection, and the text when outputting. You can change this definition, however, with the
function Settings (see below). You can get deviating definitions to this standard when you carry out
selection by selecting the field by clicking on it, and then using the context menu (right mouse button).
In the tree, each field has two columns each with a checkbox. Marking the field in the first column
(selection) causes the selection of the field for selection (field value). Selecting the second column
(output) causes the selection of the field for output (text of the field value if one exists, otherwise field
value).
Furthermore, the marking a field for selection or output can also take place by selecting and dragging the
field into the required area. (Drag &Drop). You have here a total of three options that are open to you for
selection: Setiing checkbox, Drag&Drop, and using the context menu. Drag&drop for the selection is,

however, not possible if the selection part is represented by a selectgion screen. A selection may be
removed by the checkbox selection being removed.
If the InfoSet query runs in the HTML Gui then the selection must take place elsewhere. In this case the
chosen fields must first be selected using the checkboxes. The selected fields can then be put in one step
either in the selection part or the output part. Two different pushbuttons exists for this purpose in the
application toolbar.
With the function Adjust column width, you can set an optimum column width in accordance with the
existing contents of the column. With the function Technical name on/off , you can show the technical
name of the fields in an additional column.
The top rightpart of the screen contains the selections. These can be displayed using selection control
(ALV grid ready-for-input) or on the selection screen.
If the selection control is used and a field for selection is chosen, then a new row appears in the control.
The first column is a selection column, with which one or more rows can be selected. The selected rows
can then be moved within the control (by Drag&Drop) or can be deleted (function in the application
toolbar).
The second column specifies the selections further. Using the icon Simple field (ICON_SIMPLE_FIELD)
or Text field (ICON_TEXT_FIELD) you indicate whether the field value or the text of the value field is
used for selection.
The third column contains the field name. In the fourth column you can maintain the selection options
(single value, larger or the same size, and so on). The column contains a pushbutton using which the
selection can be made. If no selection is made then Select single value is entered. If the chosen selection
option only requires one value (for example, with Select single value or Template), then this can be
entered in the fifth column. Thus the majority of all required selections can be described.
The sixth column contains a pushbutton that allows complicated selections (multiple selection). Several
single values and intervals are permitted.
Instead of the selection control you can also use the selection screen. The selection screen has the
advantage that for selections, that are realized by a logical database, corresponding checks are already
run when you enter values. Furthermore, the selection field groupings designed by a logical database, as
well as radio buttons and pusbuttons can only be displayed on one selection screen. It is possible to
switch between both displays using the functions from the menu Extras.
In thelower part of the screen, the output list is displayed using the ALV grid. If fields are selected from
the InfoSet for output, as described above, then they are first attached to the existing fields, and are then
moved using Drag&Drop (in this case the correct place in the output list can be determined straightaway).
You can determine whether to use ascending or descending sorting, totals, and subtotals within the ALV
grid by using the pushbutton designed for this purpose. The procedure is just like in every ALV grid. The
result of such an operation is displayed immediately.
First used for display is sample data that either just happens to be defined or is chosen from a pool of
possible values by chance. By using function Refresh data you can display real data. The function causes
the query to be executed in accordance with the selections made and the data generated is transferred
intot the ALV grid. In this case the ALV grid already contains in practice a complete result for the query
correctly according to the selections. You can, therefore, also use the usual functions of the ALV grid such
as EXCEL, word processing, and so on. Additional changes can, however, also be made in the output list.
If these changes result in new selections having to be made in order to retain a correct list (for example,
due to a new field being added), then the runtime functions mentioned are switched to inactive and
sample data is used again for the display. You then have to recall the function Refresh data to get a
current results list. There are several options for executing a query (as defined in the output list) in
accordance with the selections (as entered in the selection part). The first option is the function just

mentioned Refresh data, with which the results list is displayed directly in the InfoSet query. The second
option is the function Output. This function starts the query and displays the result in a full screen. This
corresponds to the previously usual way of processing queries. The function Output works in such a way
that the selections entered in the selection part are taken into consideration, that the selection screen of
the query is not processed and that the result is displayed with the SAP List Viewer (ALV). What you
determine here, however, can be changed with the function Settings . You can determine that the
selection screen should be displayed after the start, and that another output format instead of the SAP
List Viewer (EXCEL, Crystal, and so on) is chosen. This corresponds to the settings using the direct list
transfer, how it could previously be made on the selection screen.
With the aid of the function Settings you can further determine whether a basic lists, a set of statistics, or
a ranked list is the list that is displayed in the lower part of the screen. When using Crystal as an output
medium you can also determine if the Crystal Report is regenerated or should refer to an existing
template. This is only relevant in the case where the Crystal is started directly by the query. If Crystal is
called using the SAP List Viewer (this should be the standard method) then the conventions determined in
the SAP List Viewer must be taken into account.
Furthermore, every user can determine, using the Settings function, whether the the value or, if one
exists, the text should be used as default when choosing a field for selection or output.
With the functions New query and Open query you can choose a new template via a dialog. In the case
of the function New query , an InfoSetoSet can be chosen, and forOpen query it is a query that can be
chosen. Which InfoSets and queries can be used depends on the context in which the InfoSet Query was
called (see below, section on calling the InfoSet Query). If the call was made from a role then you can use
just those InfoSets that are assigned to the role, and also the queries that were created by users of the
role. If the call was not made from a role then the previous, usual rules about user groups are then valid.
The user group can, thus, be chosen first in such cases with the function New query and Open query .
This selection then determines which InfoSets and queries are made available for use.
In the menu Query the queries processed last can be used as menu entries (history). You can choose
one of the executed queries in this menu as a template by clicking on the corresponding menu option.
After a new template has been selected, you can carry out the required changes to the template. The
query can be executed to determine results lists. The process of changing and executing can be
repeated. If a change is saved then the functions Save and Save as can be used. The user can,
however, only use these functions if he/she has the authorization to change queries (authorization field for
the authorization object S_QUERY with the value 02 for the field ACTVT).
The way the Save and Save as functions work depends on what has happened before.
The function Save always overwrites the last saved query - if has already been saved once before,
otherwise it works just like the function Save as. With the function Save as a dialog is always kept, in
which the name of the query to be saved, as well as the long text, can be entered. If the name of an
existing query is chosen when doing this, then this query is overwritten. If the InfoSet Query is called from
a context that works with the previously usual user groups, then the user group can also be selected here,
if necessary.
When saving the query, a lock is put on the query that has just been saved. This means that another user
of the InfoSet Query can use the saved query as a template, but cannot overwrite this query. This does
not mean, however, that saving a query under a certain name is only possible if this query has not just
been locked by another user.
The functions Save and Save as are grouped together as follows:

If the function Save is executed for the first time after having loaded the template (New
query and Open query), then it works like the function Save as, meaning it is processed like a

dialog box in which the name of the query, to be saved, can be entered. A new name is given as a
proposal if the template was an InfoSet, otherwise the name of the query is proposed that was
used as a template. The saved query is locked.

If the function Save is not executed for the first time after loading a template then, when you
save, the name of the query is used that was also used with the previous save. The lock that
already exists on the query remains so. No dialog takes place in this instance.

If the function Save as is executed then a dialog box is processed first, in which the name of the
query to be saved can be entered. As a proposal, the name of the query is taken that was used
as a template or that was saved last. The query is saved under the name determined in the
dialog, and a lock is placed on this query. If another query was saved previously then this lock is
removed, meaning that the previously locked query can be processed by another user.

If a new template is read by using the New query or Open query functions and if there is currently
a lock on a certain query due to a previous save, then this lock is removed.

The standard way of working with the InfoSet Query consists of changing the template read, and then
saving it in several steps if necessary. The function Save can always be used for this. When saving for
the first time you are asked for the query name, and this name is used again for all further saves.
Furthermore, since a lock is set when saving for the first time, there will be no problem carrying out future
saves because this query cannot be locked by another user.
The function Save as is required if a query should be copied and then processed.
When saving a query the current selections from the selection control or selection screen are also taken
into account. For this query a standard variant is defined and stored with the
name STANDARD or SAP&STANDARD (for queries from the global work area that are not temporary ). If
such a variant exists then it is overwritten.
If a user does not have the authorization to change queries (see above) then he/she can read and change
with the InfoSet query template, and can execute the changed version of the template too. He/she cannot
save the changes as a query, thus as a new template.
With the functions Goto -> Variant Maintenance and Goto -> Report Assignment you can maintain
variants or entries for a query in the Report/Report Interface. This maintenance is done for the query that
was last saved, or, if no save was carried out after reading the template, for the query that was used as a
template. This means that it is possible to maintain variants and entries in the Report/Report Interface for
this query immediately after function Open query .
With the function Query -> Delete the query that was first saved or, if no save was carried out after
reading the template, the query that was used as a template is deleted. The query, however, is retained
as the template for the user, meaning that it still cannot work with this query further. Only if a new
template is chosen or the maintenance is left, this query is irretrievably lost for the user.

Logging
The work with the InfoSet Query can be logged. If this is required then the following entries can be written
to the database table AQPROT when processing a query.

Work area and InfoSet

User, date and time

All selection fields including the values for selection

All output fields

This logging is only carried out when calling a query out from the InfoSet Query. In all other cases (start
via a menu entry, via transaction SQ01, or via one of the function modules put there for that purpose) no
logging is done.
The setting for the logging is made via the function Goto -> Additional Functions -> Set up Logging on the
initial screen of the transaction for the InfoSet maintenance (SQ02). A corresponding function can also be
found in Customizing. The function takes you to a table control, in which entries for database
AQPROTCUST can be maintained. The database table contains the fields work area (possible values
are SPACE for the standard area and G for the global area) and InfoSet . If all work, that is made by the
InfoSet Query, is logged then a record is entered in the table, that contains the value * as an InfoSet. If
only work with certain InfoSets is logged, then a record is entered in the table for each of these InfoSets.
Using the function Goto -> Additional Functions -> Manage Logging on the initial screen of transaction
SQ02 you can start a report with which logs can be deleted from the log table.
The evaluation of logs can take place, for example, by using queries.
The Business Add-In (BAdI) AQ_QUERY_PROT exists with whose help the user can connect user-defined
logging. The same information is transferred to the log that the standard logging can also use, and the
same rules applies about when the logging takes place. Using customer- defined logging, customerspecific filters or another log folder can be realized.

Calling the InfoSet Query

When InfoSet Query was developed, the aim was that this tool could be called from different contexts.
This is why a new transaction especially for InfoSet Query was not developed. Instead, there are function
modules and reports that allow the user to call InfoSet Query with different parameters.
There are two decisions the user calling InfoSet Query has to make. Firstly, what the access
authorizations are going to be and secondly, which type of reporting he/she wants to use. 'User groups' in
the following section refers to SAP Query user groups.
Controlling the Access Authorizations
You can control access authorizations over roles or user groups. If you choose to control them over roles,
this should be the only means of control on a long-term basis. User groups are really only a technical
method for administration.
If you use a role to control the access authorizations, the technical process dictates that a user group is
first assigned to one role. The Administrator must then assign the InfoSets to the user groups in the usual
way. That is, those InfoSets that may be used within the user group (and therefore within the role) for
Reporting. However, you no longer need to enter the users in the user group as they were already
assigned when the roles were assigned. This means that a user, who is assigned to a role, is then
automatically transferred to the user group in turn, assigned to the role. But the assignment to the
user group is only valid when the user calls InfoSet Query over the role. If you access SAP Query in any
other way, the previous settings apply.
If you want to a user to be able to save queries, he/she must have the changing authorization for queries
(authorization object S_QUERY, value 02 for field ACTVT). Otherwise, he/she can work with with the
available templates in the role without being able to create new templates.

When you control the access authorizations using a role, the end user is no longer confronted with the
term user group. He/she calls InfoSet Query with a menu entry and can then choose from a range of
InfoSets that he can use to create queries. There is a more detailed description of how to create a menu
entry below. The Administrator only uses the user group to determine which InfoSets can be used.
Controlling the access authorizations using user groups fully corresponds to the previous settings, that is,
which InfoSets can be used is determined for each user, as well as which users belong to the user group.
In addition, the changing authorization (see above) should be given to those users that are to be
authorized to save queries .
Reporting Type
InfoSet Query allows you to decide between development and Ad-hoc Reporting. With development,
queries that will exist for a longer time should be created, as single reports are called from menus and so
on, and, if necessary, are also distributed. With Ad-hoc Reporting, queries are usually no longer needed
after one use, which of course does not exclude the fact that queries that exist through Ad-hoc Reporting
can also be saved.
With the Reporting type 'Development', the global query area is always used and there is an active
connection to the Workbench Organizer (WBO). This corresponds to the usual type of work of SAP Query
in the global query area. All known settings are still valid.
With Ad-hoc Reporting, you can choose the query area (global or standard). With the standard area, the
usual type of work of SAP Query is relevant in this area. With the global area, basic queries with a
temporary development class (($TMP) are created and the connection to Workbench Organizer is not
active. This means that there is never dialog with the Workbench Organizer.
Modules for calling InfoSet Query
According to the possible settings for controlling access authorizations, there is a total of four function
modules or four reports each with the same name:

SAP_QUERY_DEVELOPMENT_ROLE: Access
to
roles,
development
parameters are the role (necessary), an InfoSet (optional) and a query (optional). A user group
from the global work area must be assigned to the role. If an InfoSet is specified, it must be
assigned to the user group. If a query is specified, it only has to belong to the user group.

SAP_QUERY_AD_HOC_ROLE: Access

via

role,

Ad-hoc

Reporting

The same parameters exist with the same restrictions as for SAP_QUERY_DEVELOPMENT_ROLE ,
The assigned user group can also be derived from the standard area.

SAP_QUERY_DEVELOPMENT: Access
via
user
group,
Development
Parameters are a user group, an InfoSet and a query (all optional) The user group must be
derived from the global query area. If more than one parameter is set, the values must match. So,
if, for example, user group and InfoSet are specified, the InfoSet must be assigned to the user
group.

SAP_QUERY_AD_HOC: Access

via

user

group,

Ad-hoc

Reporting

The same parameters with the restrictions exist as for SAP_QUERY_DEVELOPMENT. The query
area can be selected.
Optional parameters are used to create a template when calling InfoSet Query. If these parameters are
not set, an attempt is made to retrieve a sensible proposal for the template from the last object (role, user
group, InfoSet) used by the user.

The reports call the function modules directly and make value helps available for the parameters.
Otherwise it does not matter whether the function modules or the reports are used for calling InfoSet
Query. The reports are necessary if you are creating menu entries.
Call-up from the transaction SQ01
You can call InfoSet Query via the transaction used for maintaining queries (SQ01). This is a specific
example for the technique described above for call-up and demonstrates the close connection between
the exisiting tools. (It should also be mentioned that the usual way to call InfoSet Query is via a role).
In the initial screen of the transaction SQ01, a query is selected as normal and the function InfoSet
Query chosen. This means the selected query is used for InfoSet Query. Make sure that this call-up via
transaction SQ01 does not lock the selected query, as would be the case if you chose the
function change.
If you called InfoSet Query from the standard area, then Ad-hoc Reporting is put into action,(see
above SAP_QUERY_AD_HOC ). If you call it from the global area, the development of queries is put into
action (see above SAP_QUERY_DEVELOPMENT ). Both correspond to the usual previous settings.
Processing Queries
Queries with longer life-spans are processed according to the procedure described so far, that is, they are
primarily positioned in menus. You should only use the InfoSet Query for processing if you have to make
temporary changes to the query (as a template) beforehand.
Including the InfoSet Query in a role
The following passage summarizes the steps that are necessary to include the InfoSet Query into a role.
1. Select a user group or create a new user group that you want to connect with a role. Assigned to this
user group are all those InfoSets that you later want to be made available to a user of this role for
reporting
purposes.
If you want the role to support query development (no ad-hoc reporting), then you have to select a user
group from the global area. Both the user group and all assigned Infosets should also contain nontemporary development classes to enable transportable queries to
be developed.
Note: You can change the assignment of Infosets to user group at any time. It is not necessary to assign
users.
2. You have to create a variant where the parameter Role is filled exactly with the name of the relevant
role for the report SAP_QUERY_DEVELOPMENT_ROLE orSAP_QUERY_AD_HOC_ROLE (depending on the
reporting type you want). You can determine the other parameters as each case requires.
3. The selected user group is assigned to the role. In the transaction for role maintenance (PCFG) on the
tab Personilization , select the keySAP_QUERY_USERGROUP by double-clicking. A dialog box appears
in which you can enter the user group.
4. The report SAP_QUERY_DEVELOPMENT_ROLE or SAP_QUERY_AD_HOC_ROLE is included in the role
menu. Additionally, the relevant report is added (as an ABAP report) along with the variant you created
previously (see point 2) in the role maintenance transaction (PFCG) in the tab Menu using the
function Add report . The selection radio button Skip selection screen should always be set.
As a result of this action, the InfoSet Query is available as a menu entry for the role. Available InfoSets
are determined using the user group assigned to the role. Which template is used to start the InfoSet's
work is determined using the other report parameters.

Maintaining InfoSets
As already mentioned, functional areas are known as InfoSets from Release 4.6C. The maintenance
transaction for InfoSets (SQ02) has also been completely revised, and some functional enhancements

have been made. The next section first explains in brief how InfoSets are maintained using the revised
transaction, and then goes on to talk about the functional enhancements.
The initial screen for transaction SQ02 remains unchanged. The dialog for creating an InfoSet is now
more comprehensive and contains some new options (see below). The definition of table joins also
remains unchanged.
The screen for maintaining Field groups (previously function groups) has been completely revised. It is
now divided into three parts.
The data source (logical database, table join, table) structure is displayed along with the relevant
enhancements (additional tables, additional fields) as a tree in the leftsection of the screen. Each field is
marked with an icon. The icons Simple
field (ICON_SIMPLE_FIELD) and Field with
text (ICON_FIELD_WITH_TEXT) are possible. In the first case, only a field's own values can be staged.
In the second case, a text can be automatically generated for each field value. Two columns containing
the field technical name and assignment to a field group are assigned to each field.
The field groups are displayed as a tree in the right upper part of the screen. The same icons as for the
data source (left) and the technical name are assigned to each field in a separate column. Here, as well
as with the data source, the tree display enables you to select the section you want on the screen using
the 'expand' and 'collapse' actions.
Creating and changing field groups is possible using special functions that you can find above the field
groups on pushbuttons. You select fields in the field groups by marking the fields with a single click in the
data source. These fields can then be moved using drag&drop into the field group you want. It is also
possible to select the relevant field group with a single mouse click and then call the function Add fields to
field group.
You can use drag&drop to determine the sequence of field groups as well as the sequence of fields within
a field group.
A double-click on a field in the data source or in a field group displays all the technical information for this
field in the lower right part of the screen. You can change long texts and headers if you need to here.
Calling the functions Extras, Selections and Coding , causes corresponding maintenance screens to be
shown in the right half of the screen. The procedure here is basically the same as before and is therefore
not explained in detail. When maintaining selections, you can use checkboxes to determine which
selections for use as templates are copied into selection control when using an InfoSet. Suggestions can
thus be made to an InfoSet user on which selections it is most advisable to use within the InfoSet Query.
The following section deals with the Application-specific enhancements function.

InfoSet maintenance enhancements

A range of functional enhancements were also made when revising the maintenance transaction. All
these enhancements are used by the InfoSet Query, but they are also available for use with the usual
query maintenance tools.

Generation and preassignment of field groups

Field groups are preassigned when an InfoSet is created. This means that field groups already exist if the
screen for field group maintenance is processed for the first time following the dialog for determining the
data source. There are the following specifications.

If the InfoSet has been created using a single table, then there is exactly one field group whose
longtext agrees with the langtext for the table. In a dialog box you can determine whether all table
fields, only the table key fields or no table fields are entered into the field group.

If the InfoSet has been created using a table join, then exactly one field group is created for every
table in the join whose longtext agrees with the longtext in the corresponding table. In a dialog
box you can determine whether all tables fields, only the table key fields or or no table fields are
entered in the field groups.

If the InfoSet has been created using a logical database, then exactly one field group is created
for each node, providing that the logical database has, at most, four nodes. If the logical database
contains more than four nodes, then you can use the dialog box to determine for which nodes
fields group should be provided. The structure tree for the logical database is also displayed in a
dialog box. Here you can use checkboxes to select each node for which a field group is to be
provided.
The field groups contain the same longtexts as the corresponding nodes. They are however
emplty, meaning that no fields have been assigned to them.

The predefined and, where necessary preassigned field groups can be changed in any number of ways.
You can change longtexts, delete or add new field groups. It is recommended, however, that you copy
and keep the 1:1 assignment between field groups and tables or nodes.
The technical process involved in the provision of predefined contents is carried out earlier in InfoSet
maintenance using the InfoSet Generator for HR InfoSets (logical databases, PNP, PCH and PAP). The
existing form of generation represents a generalization of this technological process. The InfoSet
Generator for HR InfoSets remains active, meaning that if InfoSets are created using logical databases
PNP, PCH or PAP, then this generator is used to provide predefined contents.
There are two different Generators for InfoSets. Additional Generators that are used either generally and
for all Infosets or only for particular data sources can also be used. Technical details as to how these
Generators are connected, is described in more detail below (application specific enhancement).

Text fields
In the above sections it was already mentioned that as of release 4.6C it would be possible to determine
texts for fields values automatically. For this, different processes are used (check tables, fixed values and
so on). When you use a field like this in a query, you can choose whether you want ot use the value or the
assigned text.
With the InfoSet maintenance, a check is run for each data source field to see whether a text can be
provded for a field value or not. The result of this investigation is displayed through the icons before the
field (icons single field or Field with text , see above). Otherwise there are no other features for fields with
texts. If a field like this is transferred to a field group, the InfoSet user can always use the value and the
text. If a field like this is removed from a field group, the user can no longer use the value or the text. This
means that you cannot only transfer the text, for example, of this field to the field group.
The new technique automatic text identification can be used for already existing InfoSets. For this, the
function InfoSet -> Other functions -> Update text fields -> must be chosen once per InfoSet from the
initial screen of the transcation SQ02. Texts are then available in this InfoSet for all fields to which this
applies.
It is conceivable under some circumstances that you do not want text retrieval to be automatic. In this
case, automatic text identification can be switched off in the first dialog box by selecting the relevant
checkbox. For an already existing InfoSet you can switch off the automatic text identification by choosing
the function InfoSet -> Other function -> Update text fields via the transaction SQ02 initial screen. This
function only works if none of the text fields is used in a query.

The standard process for text identification is quite detailed and complicated. Although there will be cases
where this process is insufficient. It is therefore possible, like with the generators, to use other process for
text identification (see below, application- specific enhancements).

Additonal structures
Every InfoSet is based on a data source that can be accessed by additional information. Until
now, additional tables and additional fields were possible additonal information. The additonal fields are
restricted in that they must have a simple (scalar) data type.
As of Release 4.6C, the so-called additional structures were added to the additional information.
Additional structures are actually additional fields with a non-scalar data type, whereby this data type
must always be a (flat) structure from the Data Dictionary.
An additional structure is created much in the same way as an additional table. By definiton of the
additonal structure, the structure must be specified from the Data Dictionary and the calculation formula.
An additional structure must be assigned in the same way as an additional field is assigned to the node of
the data source. But this data source node contains all the single fields from the additional structure.
Additional structures therefore present an easy way of calculating several additional structures at once.

Code for time AT

SELECTION-SCREEN

For every selection that is defined in the InfoSet or retrievd by the logical database, you can make a code
for the time AT SELECTION-SCREEN to carry out checks. To do this, place the cursor on a selection in
the overview screen for the existing selections and choose the function check code for element .
As for the call-up point for selections, the semantics of the selection criteria that are created in the InfoSet
itself are also changed. Using the FOR field that should be assigned to every selection criterion, you can
make the assignment of the selection criterion to the data source node. The selection criterion is now only
put on the selection screen of a query if the relevant data source node is referred to in any way in the
query.
Coding at the AT SELECTION-SCREEN has to be decided upon separately for each selection. When a
query report is generated, a check is made to ensure that the check coding for all selections is collected
together in AT SELECTION-SCREEN and that only the selections that appear on the screen are referred
to.

Non-summarizable Fields
For every numerical field there is the option of marking the field as 'non-summarizable'. To do this, the
technical information for the field has to be displayed in the lower right-hand part of the screen. This is
where you will find the relevant checkbox.
A numeric field that cannot be summarized is treated as a character type field in the query.

Application-specific Enhancements
SAP Query is a generic tool that can be used for all applications within SAP systems for reporting tasks.
This generic approach has, until now, prevented SAP Query from utilizing specific application knowledge
(special application logic).
The application HR is, however, an exception. There is a range of specific HR solutions integrated into
SAP Query (InfoSet generation, query target groups , and so on). These solutions are strictly coded,
meaning that changes or enhancements are only possible if you modify SAP Query.

From Release 4.6c, work has begun on enhancing SAP Query so that it is possible to evaluate
application-specific logic without having to modify SAP Query itself. The procedure for setting up these
enhancements is similar to that for defining and implementing Business AddIns (BAdI).
Specific interface methods are called at different times, for example, when creating an InfoSet or during a
query runtime. These interface methods are either implemented by a basis class (standard) or from a
special class containing additional application logic. If you want your queries to use application-specific
functionality rather than basis functionality for a particular service using an InfoSet, then you can deposit
the class that implemented the corresponding interface in the InfoSet. The InfoSet then becomes a carrier
for all the information on application-specific logic.
A practical example should help explain the procedure:
The interface methods IDENTIFY_TEXT or READ_TEXT for the IF_TEXT_IDENTIFIER interface are
called for automatic text identification when creating an InfoSet and for reading relevant texts on query
runtimes. This interface is implemented by the basis class CL_TEXT_IDENTIFIER and this
implementation in turn is used by default. Texts that cannot be identified by the basis class could possibly
be determined by additional logic in a particular application context. For example,
the CL_HR_TEXT_IDENTIFIER class in the HR environment. In principle, the application classes can
either re-implement the IF_TEXT_IDENTIFIER interface or be derived from the basis class. The
relevant class for text identification is specified in the InfoSet, corresponding implementation for the
interface method is called for reading texts in all queries for this InfoSet.
You can use the program RS_TEXT_IDENTIFY_TEXT to test text identification. Essentially, the
class CL_TEXT_IDENTIFIER evaluates the ABAP dictionary. It can happen that texts exist for particular
fields, but the link between value field and text field is not apparent in the ABAP dictionary. If this occurs,
you can define exceptions in Customizing: You can, for example, specify a function module for creating a
text, or create a text for a field in a table directly. The procedure for defining exceptions is described in the
documentation for program RS_TEST_DENTIFY_TEXT .
The following interfaces are defined for Release 4.6C:

Text

identification

Interface: IF_TEXT_IDENTIFIER
Methods: IDENTIFY_TEXT,
READ_TEXT
Basis
class: CL_TEXT_IDENTIFIER
Automatic text identification. A special class can be entered in the initial popup when creating an
InfoSet (button "More options").

InfoSet

Generator

Interface: IF_QUERY_INFOSET_GENERATOR
Methods: MODIFY_INFOSET
Basis
class: CL_QUERY_DATASOURCE_GENERATOR
Generation and preassignment of field groups (see above). A special class can be entered in the
initial popup when creating an InfoSet (button "More Options").
In InfoSet maintenance, the specified service classes are displayed in the tab Application-specific
Enhancements .

Enhancements for query maintenance

A few enhancements to the functionality of queries is explained in the following section. The first two
functionalities are not available in the InfoSet Query. The following therefore refers to the processing of
queries using transaction SQ01.

Rounding in basic lists

Output from numerical values can be rounded up and down in basic lists. This happens in the same way
as is already possible for statistics and ranked lists: With numerical fields, you can specify the number of
places (before the decimal point) to which the field is to be rounded. This number has to specified either
in the field settings within the Query Painter or in the Output options for fields screen.
Rounding only takes place with the field output in the list. Internally, only the original value, meaning the
value that has not been rounded, is ever used. The values that have not been rounded are therefore also
used for summation or for passing on to other tools (such as ALV or EXCEL).

New options for selection criteria

Until now in the data fields tree display for the Query Painter, or in the Selection fields screen, you could
determine that each field be available as a selection criterium. You could also determine the selection text
in the Selection fields selection field screen.
Now you can also determine the selection criteria sequence in this screen by entering a sequence
number. Defined selection criteria are still always arranged in the queryafter the selection criteria for the
logical database or InfoSet. Additionally, you can determine that only the individual value entry is allowed
for a selection criterium, meaning that this selection criterium functions almost as a parameter.

Determining the number or ranked list places dynamically

The number of places in a ranked list is determined at the same time as the ranked list itself is defined.
From Release 4.6C the parameter Number of ranked list places is provided as standard on the query
selection screen for every query that contains at least one ranked list. The number of available ranked list
places for all query ranked lists can be determined here dynamically during the query runtime.

Query runtime enhancements

Using the SAP List Viewer
As has already been mentioned sevreal times, as from Release 4.6C, the SAP List Viewer is the standard
output medium for the SAP Query. A restructuring of the selection screen is part of this change. The
frame Direct passing on of the list has been renamed as Output form. The button SAP List Viewer is the
first radio button and therefore the available standard. The radio button No passing on, has been
renamed as ABAP List.
An entry field in which a SAP List Viewer layout variant for the relevant query can be entered, is assigned
to the radio button SAP List Viewer. Input Help for this entry field is available. Information on the
maintenance of layout variants is contained in the SAP List Viewer documentation. It is possible to create
variants for queries that use special SAP List Viiewer layout variants.
The entry field for layout variants is available from Release 4.6C only if the query is started form the initial
screen for transaction SQ01 or from the menu. If the query is started from the InfoSet Query or from a
maintenance screen for transaction SQ01, then this entry field is not available.