LESSON 18 SEARCH HELP

SEARCH HELP:



The input help (F4 help) is a standard function of the R/3 System. It permits the user to display a list of possible values for a screen field. A value can be directly copied to an input field by list selection.

The fields having an input help are shown in the R/3 System by the input help key to the right of the field. This key appears as soon as the cursor is positioned on the corresponding screen field. The help can be started either by clicking on this screen element or with function key F4.

If the number of possible entries for a field is very large, you can limit the set of displayed values by entering further restrictions.

The display of the possible entries is enhanced with further useful information about the displayed values. This feature is especially useful if the field requires the entry of a formal key.

Since the input help is a standard function, it should look and behave the same throughout the entire R/3 System. The development environment therefore provides tools for assigning a standardized input help to a screen field.

The precise description of the input help for a field is usually defined by its semantics. For this reason, the input help for a field is normally defined in the ABAP Dictionary.

A number of requirements must be met for the input help of a screen field (search field):

Information (about the context) known to the system must be taken into consideration in the input help. This includes entries the user already made in the current input template as well as information obtained in previous dialog steps. Normally the input help uses the context to limit the set of possible values.

The input help must determine the values that can be offered to the user for selection. The data to be displayed as supplementary information in the list of possible values must also be determined. When the possible values are determined, the restrictions resulting from the context and from further search conditions specified by the user must also be taken into consideration.


The input help must hold a dialog with the user. This dialog always contains the presentation of the possible values (with supplementary information) in list form and the possibility to select a value from this list. A search template in which the user can define conditions for the values to be displayed is also sometimes required .

If the user selects a value, the input help must return it to the search field. The input template often contains more fields (often only display fields) containing further explanatory information about the search field. The input help should also update the contents of these fields in this case.

The ABAP Dictionary object search help is used to describe an input help. The definition of a search help contains the information the system needs to satisfy the described requirements.

The interface of the search help controls the data transfer from the input template to the F4 help and back. The interface defines the context data to be used and the data to be returned to the input template when a value is selected.

The internal behavior of the search help describes the F4 process itself. This includes the selection method with which the values to be displayed should be determined as well as the dialog behavior describing the interaction with the user.

As with a function module, search helps distinguish between the interface with which it exchanges data with other software components and the internal behavior (for function modules, the latter is defined by the source text).

It only makes sense to define a search help if there is a mechanism available with which the search help can be accessed from a screen. This mechanism is called the search help attachment and will be described later.

Like the editor for function modules, the editor for search helps also enables you to test an object. You can thus test the behavior of a search help without assigning it to a screen field.

The possible values displayed for a field by the input help are determined at runtime by a selection from the database. When a search help is defined, you must define the database object from which the data should be selected by specifying a table or a view as the selection method.

It makes sense to use a view as selection method if the data about the possible values that is relevant for the input help is distributed on several tables. If this data is all in one table or in the corresponding text table, you can use the table as a selection method. The system automatically ensures that the text of the text table is used in the user's logon language.

If there is not yet a view that combines the data that is relevant for an input help, you must first create it in the ABAP Dictionary.

Maintenance views may not be used as the selection method for search helps. Normally a database view is used. However, you should note that database views (in the R/3 System) are always created with an inner join. As a result, only those values having an entry in each of the tables involved are offered in the input help. Sometimes the values should be determined with an outer join. In this case you should choose a help view as the selection method.

If the selection method of a search help is client-dependent, the possible values are only selected in the user's logon client.

The possible values are presented in the dialog box for displaying the hit list and the user can select values from here. If the possible values are formal keys, further information should also be displayed.

If the hit list is very large, the user should be able to define further restrictions for the attributes of the entry. Restricting the set of data in this way both increases the clarity of the list and reduces the system load. Additional conditions can be entered in a further dialog window, the dialog box for restricting values.

The dialog type of a search help defines whether the dialog box for restricting values should be displayed before determining the hit list.

You must define the characteristics to appear on either (or both) of the dialog boxes as parameters in the search help. You can use all the fields of the selection method (with the exception of the client field) and the non-key fields of your text table as parameters.

You define which parameter should appear in which dialog box (in what order) by assigning the parameters positions in the two dialog boxes. You can thus use different parameters (or different orders) in the two dialog boxes.

Types must be defined for search help parameters with data elements. These define the display in the two dialog boxes. If nothing else is defined, a parameter uses the data element of the corresponding field of the selection method.

When you define a parameter of a search help, you must also define whether it should be used to copy data to the input help (IMPORT parameter) or whether to return data from the input help (EXPORT parameter).

The IMPORT and EXPORT parameters of a search help together make up your interface. (This is also analogous to function modules.)

You can also define interface parameters that do not appear in either the dialog box for displaying the hit list or the dialog box for restricting values. This is useful for example when screen fields that do not appear on either of the two dialog boxes are to be updated when you select a value.

The location from which the IMPORT parameters of a search help get their values and the screen fields in which the contents of the EXPORT parameters of the search help are returned are defined in the search help attachment.

The search field is a special case. Its contents are only used in the input help if it is a search string (that is, if it contains a ´*´ or a ´+´) and the parameter linked with the search field is an IMPORT parameter.

Parameters that only contain additional information about the search field should not be defined as IMPORT parameters since the user must otherwise empty the corresponding screen fields each time before he can define a new value with the input help.

A search help describes the flow of an input help. The search help can only take effect using a mechanism that assigns the search help to this field. This mechanism is called the search help attachment to the field.

Attaching a search help to a field has an effect on the field's behavior. It is therefore considered to be part of the field definition.

The semantic and technical attributes of a screen field (type, length, F1 help, ...) are not normally defined directly when the input template is defined. On the contrary, only a reference to an ABAP Dictionary field (usually with the same name) is specified in the Screen Painter. The screen field takes on the attributes of this field from the ABAP Dictionary.

The same principle is also used to define the input help of a screen field. The search help is thus attached to the ABAP Dictionary search field and not to the screen field.

In the search help attachment, the interface parameters of the search help and the screen fields providing data for the input help or getting data from the input help are assigned to one another. The search field must be assigned to an EXPORT parameter of the search help at this time. This parameter should also be an IMPORT parameter so that the user can take advantage of search patterns that are already entered.

Fields that do not have a search help attachment can also have an input help since further mechanisms (e.g. domain fixed values) are also used for the F4 help.

There are three mechanisms for attaching a search help to a field of the ABAP Dictionary.

A search help can be attached directly to a field of a structure or table. The definition of this attachment is analogous to that of a foreign key. You have to define an assignment (between the interface parameters of the search help and the fields of the structure) for which the system makes a proposal.

If a field has a check table, its contents are automatically offered as possible values in the input help. The key fields of the check table are displayed. If a check table has a text table, its first character-like non-key field is displayed.

If you are not satisfied with the described standard display of the data of the check table, you can attach a search help to the check table. This search help is used for all the fields that have this table as check table. You have to define an assignment between the interface of the search help and the key of the check table when you define the attachment.

The semantics of a field and its possible values are defined by its data element. You can therefore attach a search help to a data element. The search help is then available for all the fields that refer to this data element. In the attachment you must define an EXPORT parameter of the search help for the data transfer.

Attaching a search help to a check table (or a data element) can result in a high degree of reusability. However, there are restrictions on passing further values via the interface of the search help.

In order to be able to offer a meaningful input help for as many screen fields as possible, the R/3 System uses a number of mechanisms. If there is more than one such mechanism available for a field, the one that is furthest left or at the top of the above hierarchy is used.

In addition to the options described above for defining the input help of a field in the ABAP Dictionary, you can also define it in the screen field. The disadvantage, however, is that there is no automatic reuse.

With the screen event POV you can program the input help of a field by yourself. You can adjust the design of the help to the standard help using the function modules
F4IF_FIELD_VALUE_REQUEST or F4IF_INT_TABLE_VALUE_REQUEST.

However, you should check to see if the part of the input help that you programmed yourself should be implemented as a search help exit instead (see appendix).

You can also attach a search help to a screen field in the Screen Painter. There are some functional restrictions on this kind of attachment as compared with attachment in the Dictionary.

You should no longer use the input checks defined directly in the flow logic of the screen, from which it is also possible to derive input helps.

The function Technical info is offered in the hit list in the menu of the right mouse key. It can be used to find out which of the specified mechanisms is being used.

You sometimes have to search a large amount of data with an input help. This means that you might have to wait a long time for the possible entries to be displayed, and can also result in a significant increase in the load on the system.

When you define a search help, you should therefore check whether you should take measures to optimize the accessing behavior for the selection method. This is especially true if the selection uses a view and thus more than one physical table.

If the number of entries in the selection method is very large, you should restrict the hit list with further conditions. This also increases the clarity of the hit list. The additional conditions can directly result from the context, or can be entered in the dialog box for restricting values by the user. The performance of the input help can frequently be significantly improved by creating an index on the fields used to formulate the restrictions.

If the number of entries in the selection method is relatively small, you should always check whether the selection method can be buffered.

In the relational data model, entities are usually represented by formal keys. In real life, however, these entities are often identified by one or more of their attributes. For example, the key for a person is the personnel number. A person will generally describe another with his name and possibly his address.

The attributes used to identify an entity can differ from one user to the next and from situation to situation. A user wants to use these attributes in an input help to define a value for a field that requires that a formal key be entered.

We therefore need search paths permitting access to the data using non-key fields. Several different search paths should be possible for one field.

A search path for a field can be implemented with a search help having the form described above. To describe an input help with more than one alternative search path, a set of search helps can be combined into a new object in the R/3 System. Since this object is the description of the input help for a field, it is also calle d a search help.

In contrast to the elementary search helps described above, the search helps that combine several search paths are called collective search helps .

Collective search helps are sometimes used to map the distribution of the possible entries for a field into several (disjunct) datasets.

Like an elementary search help, a collective search help has an interface of IMPORT and EXPORT parameters with which it exchanges data. Using this interface, the collective search help can be attached to fields, tables and data elements exactly like an elementary search help. Only one search help can be attached to a field, table or data element. Several search paths are therefore attached with a collective search help.

You can omit the components for describing the dialog behavior and data selection when you define a collective search help. The included search helps are listed here. You must assign the parameters of the collective search help to the interface parameters of the included search help for each inclusion.

A search help can also be included in several collective search helps and at the same time itself be attached to fields, tables and data elements. A collective search help can also be included in another collective search help.

When you use a collective search help, you are offered the elementary search helps contained in the collective search help as parallel tab pages. If you repeatedly use a collective search help, the tab page that was last used is automatically active. This is because most users always use the same search path.

The set of search paths that are meaningful for an object greatly depends on the particular circumstances of the SAP customer. The customer often would like to enhance the standard SAP collective search helps with his own elementary search helps. Release 4.6 provides an append technique that permits the enhancement of collective search helps without modifications.


An append search help is a collective search help that is assigned to another collective search help (its appending object) and that enhances it with the search helps it includes. The append search help uses the interface of its appending objects.

The append search help lies in the customer namespace. Normally the search helps included in the append search help are also created by the customer and lie in the customer's namespace. However, the required elementary search help might already be provided by SAP, in which case the customer only has to add it to his own append search help.

Append search helps are used with SAP to improve component separation. Some SAP collective search helps therefore already have one or more append search helps in the standard search help. Customer enhancements should always be made by creating a separate append search help.

SAP collective search helps often contain elementary search helps that are not required by all customers. The search helps you do not need can be hidden using an append search help. To do this, the corresponding search help must be included in the append search help and the hidden flag must be set.