Use

The information that is stored in infotypes is mainly comprised of key values. To illustrate, entries in the Gender Key field (GESCH) are stored with the key value of 1 to represent male employees, and the key value of 2 to represent female employees. However, the descriptive texts of Male and Female are not stored in the infotype itself, but rather in a language-dependent text table. From a business logic (that is, back-end) perspective, the descriptive texts are of no importance. From a user interface (that is, front-end) perspective, the descriptive texts are of great importance; when the infotype is represented in the UI, users expect to view the corresponding descriptive texts, rather than the underlying key values.

To satisfy the fundamental requirement of displaying texts, rather than values, on the user interface, a corresponding field must exist in the screen structure for every field in the infotype structure whose value is to be represented by a descriptive text. Once the screen structure fields are defined, the de-coupled framework can fill them with the corresponding texts.

Because this fundamental requirement is shared by all infotypes, generic functionality is delivered with the de-coupled framework to retrieve descriptive texts automatically. The present topic introduces this functionality, which relies on Customizing, and therefore greatly reduces the effort of implementing it.

Prerequisites

Two views are delivered in the standard system to determine Customizing for the automatic retrieval of descriptive texts. For all standard Customizing, which is delivered by SAP, the Assignment of Text Fields for Generic Text Reader view (V_T588AUTO_TEXT) determines the automatic retrieval of descriptive texts. For all customer-specific Customizing, the Assignment of Text Fields for Generic Text Reader (for Customers) view (V_T588AUTO_TEXTC) determines this process. Customers are therefore required to maintain entries in the latter view if they wish to implement this approach, while SAP maintains the entries that are delivered in the former view. To facilitate the necessary Customizing, the structure of each view is summarized below, along with an explanation of the fields contained therein.

The following chart summarizes the three fields that, taken together, comprise the structure of the Assignment of Text Fields for Generic Text Reader (for Customers) view (V_T588AUTO_TEXTC).

In the Name of Screen Structure field (SCREENSTRUC), the name of the screen structure must be specified.

In the second and third fields of this view, you must respectively specify the name of the field in the screen structure that is to receive the descriptive text and the name of the field in the screen structure that contains the key value.

The following chart summarizes the four fields that, taken together, comprise the structure of the Assignment of Text Fields for Generic Text Reader view (V_T588AUTO_TEXT).

As a comparison of the two views will demonstrate, the structure of view V_T588AUTO_TEXT is almost identical to the structure of view V_T588AUTO_TEXTC, with the exception of an additional field, Structure Holding the Key Field (VALUESTRUC). As in view V_T588AUTO_TEXTC, the first field of view V_T588AUTO_TEXT contains the name of the screen structure, the second field contains the name of the field in the screen structure that is to receive the descriptive text, while the fourth field contains the name of the field in the screen structure that contains the key value. In the third field of this view, one can specify either the name of the screen structure – in other words, the identical entry contained in the first field – or the name of the infotype structure whose data, during output conversion , is converted into screen structure format for representation on the user interface. No other entries are supported.

If you choose the first option and specify the name of the screen structure in Structure Holding the Key Field (VALUESTRUC), then the de-coupled framework processes entries in views V_T588AUTO_TEXT and V_T588AUTO_TEXTC in an identical manner. In other words, the field that contains the key value (specified in VALUEFIELD) is understood to be part of the same screen structure.

If you choose the second option and specify the name of the infotype structure in Structure Holding the Key Field (VALUESTRUC), then the field that contains the key value (specified in VALUEFIELD) is understood to be part of the infotype structure, rather than the screen structure. For this reason, the second option should only be applied in exceptional cases; the field containing the key value customarily should be part of the screen structure.

Procedure

During the automatic retrieval of descriptive texts, the system first evaluates whether Customizing has been performed in the Assignment of Text Fields for Generic Text Reader (for Customers) view (V_T588AUTO_TEXTC). If such Customizing is present, then the system responds accordingly. If no such Customizing is present, then the system reverts to the standard Customizing delivered in the Assignment of Text Fields for Generic Text Reader view (V_T588AUTO_TEXT).

Once the appropriate view is determined, the system then applies generic functionality known as the text identifier to retrieve the necessary texts. (Several standard applications, including SAP Query and Ad-hoc Query, use the text identifier themselves to retrieve descriptive texts automatically.) To this end, the text identifier evaluates all Data Dictionary information that is available for the field that contains the key value and is specified in VALUEFIELD. As information in the Data Dictionary – for example, domain fixed values, foreign key relationships, check tables and text tables – is evaluated, the system attempts to determine the location where the text for this field is stored. If a text source is located, and if this text source contains a text for the given key value, then the text identifier extracts and returns this text. The system, in turn stores this text in the screen structure field specified in TEXTFIELD.

In cases where the generic text retrieval functionality is not suitable, it is theoretically possible – although not recommended – manually to specify the descriptive text in method OUTPUT_CONVERSION of the conversion class . A preferable – and recommended – approach is to enhance the text identifier by means of the corresponding exception concept. By applying the exception concept, one can make use of the generic functionality for automatic text retrieval, yet simultaneously derive texts that cannot otherwise be retrieved from the Data Dictionary. Moreover, the exception concept provides a decisive advantage over manual specification of the descriptive text in the conversion class, because once an exception has been defined for the text identifier, that exception can always be re-used by the text identifier, regardless of the application that is using it. The exception theoretically could be re-used within the text identifier itself.

Result

By using the automatic retrieval of descriptive texts, as well as the text identifier and the corresponding exception concept, manual coding efforts are greatly reduced, and a consistent presentation of data across all applications is guaranteed.

Example

The following example demonstrates an entry that could theoretically be found in a customer system in the Assignment of Text Fields for Generic Text Reader (for Customers) view (V_T588AUTO_TEXTC).

Three of the many standard entries delivered in the Assignment of Text Fields for Generic Text Reader view (V_T588AUTO_TEXT) are summarized below.