Show TOC

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
3. InfoSet maintenance
4. Enhancements to InfoSet maintenance
5. Enhancements to the query maintenance
6. Enhancements for query runtime

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:

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

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

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 for Open 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:

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.

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, customer-specific 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:

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 non-temporary 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 or SAP_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 key SAP_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 left section 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.

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:

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 query after 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.