Programming User Interfaces in the De-Coupled Framework

Purpose

The de-coupled framework primarily consists of two areas – one area that relates to the back-end business logic of an infotype, and a second area that enables the infotype to be displayed, and if necessary edited, in the user interface.

The business logic area of the de-coupled framework covers a number of requirements, including:

checking the consistency of infotype data,
handling time constraints,
triggering retrocalculations (where necessary), and
storing infotype data on the database.

However, if the infotype is to be displayed on the screen, and if the user should be able to maintain it, then additional requirements arise. The user interface area of the de-coupled framework covers these requirements, including:

the display of specific values via input help.
the display of additional, read-only information. (For example, you may wish to display the age of an employee derived from his or her date of birth.)
the display of descriptive texts for key values stored in the infotype. {For example, when the employee gender is displayed as Male or Female instead of (or in addition to) the technical values of 1 and 2 that are ultimately stored in the database.}
dividing the value of one infotype field into several fields shown on the user interface, or vice versa.
performing any kind of calculation that converts values entered on the user interface to values that are to be stored in the infotype, or vice versa.
setting metadata based on values entered – for example, mandatory, read-only, and so on.

In short, the de-coupled framework requires programmers to consider the business logic of an infotype separately from its user interface. The division of (back-end) business logic from (front-end) user interfaces makes each area independent and therefore ultimately simplifies the manner in which the user interface is presented by various applications.

Prerequisites

In the de-coupled framework for creating infotypes, the existence of de-coupled business logic is a prerequisite for the creation of de-coupled user interfaces. Thus, if you wish to create a new Personnel Administration infotype in the de-coupled framework and program its user interface accordingly, you are required to have created the corresponding business logic already.

Note Note

To this end, we recommend that you consult the Business Logic Guidelines for Creating and Migrating Infotypes , which describe aspects of this process in detail.

End of the note.

Process Flow

In the de-coupled framework, for any infotype that is to be displayed (or edited) in the user interface, the following entities must exist:

A Data Dictionary structure (known as a screen structure ), which contains all of the infotype fields that should be part of the user interface.
An ABAP-OO class (known as a conversion class ), which defines the conversion of the infotype fields from their representation in the back end to their representation on the user interface.
An entry in the Assignment UI Structures and UI Conversion Classes view (V_T588UICONVCLAS), which defines the conversion class that the system will apply to the corresponding screen structure, and which thereby governs the assignment of conversion classes to screen structures .

As stated above, the screen structure contains all of the infotype fields that should be part of the user interface. The fields defined therein include editable fields, read-only fields, and descriptive texts. Everything that is related to the infotype and that should be presented on its user interface requires the explicit definition of a corresponding component within the screen structure.

To support the country-specific requirements of Personnel Administration infotypes, screen structures themselves are defined to be either international or country-specific . If a screen structure is defined to be international, then that screen structure will only contain fields that are country-independent. In contrast, if a screen structure is defined to be country-specific, then it will contain fields that are valid for the country version in question. For additional information, consult the Screen Structures topic.

The conversion class converts infotype data from the back end for representation on the user interface. Conversion classes therefore convert data that is stored for the corresponding Pnnnn structure into data for the screen structure, and vice versa. Output conversion denotes the conversion of Pnnnn structure data into screen structure data, while the conversion of screen structure data into Pnnnn structure data is called input conversion .

In addition to converting data, conversion classes also provide field attribute information , as well as input help , for the user interface fields. To this end, conversion classes not only specify whether a particular field is mandatory, read-only or hidden, but also furnish the supported field values to populate drop-down list boxes or input help on the user interface. For additional information, refer to the Conversion Classes topic.

As stated above, an entry in the Assignment UI Structures and UI Conversion Classes view ( V_T588UICONVCLAS ) is required to establish the link between a screen structure and the corresponding conversion class. The entries in this view enable the de-coupled framework to call the correct conversion class when processing a particular screen structure. For additional information, review the Assigning Conversion Classes to Screen Structures topic.

Note Note

In the event that the infotype in question lacks specific user interface requirements, then it is not necessary to assign a dedicated conversion class to it. In such cases, the default conversion class – CL_HRPA_UI_CONVERT_BASIC – can be assigned instead, as described in the topic referenced immediately above. For a description of this default conversion class, consult the topic Conversion Classes .

End of the note.

To simplify the programming of user interfaces in the de-coupled framework, the standard system features many types of generic functionality, which users can activate by performing the corresponding Customizing. This functionality includes a generic approach to provide input help values , the automatic retrieval of descriptive texts for fields that hold key values and the automatic handling of repeat fields . For additional information on any aspect of this functionality, choose the corresponding link.

Finally, when you have finished creating a new Personnel Administration infotype in the de-coupled framework, you can execute the Test Interface for ITF Conversion Classes transaction (transaction code PUIT_UI) to ensure that the user interface of your infotype functions properly. For additional information on this test tool, review the documentation provided with it.

In summary, the process of displaying and editing an infotype in the user interface consists of the following phases.

Output Conversion

During output conversion, back-end data is converted into screen structure data, which in turn is displayed – and, if necessary, edited – on the user interface.
- If the default conversion class CL_HRPA_UI_CONVERT_BASIC is used, all user interface fields that bear the same technical names in the back end are automatically filled.
- Assuming that the corresponding Customizing has been performed, generic functionality to provide input help values is applied; input help automatically becomes available for all fields.
- Assuming that the corresponding Customizing has been performed, the automatic retrieval of descriptive texts is applied; descriptive texts for fields that hold key values are automatically displayed.
- Based on the metadata defined for the back-end fields, field attribute information (for example, mandatory, read-only, and so on) is automatically provided.
  
  If additional processing is required for the infotype in question, then the default conversion class cannot be applied. Rather, a dedicated conversion class must be created and assigned to the infotype screen structure in view V_T588UICONVCLAS. In practice, the OUTPUT_CONVERSION method of the corresponding conversion class therefore must be implemented.
Input Conversion

Screen structure data – which has been displayed (and, if necessary, edited) on the user interface – is converted into back-end data for subsequent database storage.
- If the default conversion class CL_HRPA_UI_CONVERT_BASIC is used, all back-end fields that bear the same technical names on the user interface are automatically filled.
- No action is required for input help values; these values are only relevant when the infotype is maintained in the user interface.
- No action is required for descriptive texts; these texts are read-only by default, and therefore require no conversion for storage in the database.
- No action is required for field attribute information, as this information is already defined in the database.
  
  If additional processing is required for the infotype in question, then the default conversion class cannot be applied. Rather, a dedicated conversion class must be created and assigned to the infotype screen structure in view V_T588UICONVCLAS. In practice, the INPUT_CONVERSION method of the corresponding conversion class therefore must be implemented.

For infotypes that contain repeat fields, a generic approach is also provided; for additional information, see Repeat Field Screen Structures (Type LINE) . If the generic approach for repeat fields is insufficient, then a dedicated conversion class must be created and assigned to the infotype screen structure in view V_T588UICONVCLAS, and the OUTPUT_TABLE_CONVERSION and INPUT_TABLE_CONVERSION methods of that conversion class must be implemented.

Example

Suppose that you wish to create the user interface for infotype 9001, an international customer-specific infotype that is to be processed in the de-coupled framework and whose structure (P9001) consists of the fields shown below.

Note Note

Subsequent examples in the present guidelines may refer to the customer-specific infotype (9001) introduced below.

End of the note.

P9001 Structure Fields

Field Name	Short Description
NACHN	Last Name
VORNA	First Name
GBDAT	Date of Birth
GBPAS	Date of Birth According to Passport
NCHMC	Last Name (Field for Search Help)
ANRED	Form-of-Address Key

Because Infotype 9001 is to be processed in the de-coupled framework, a corresponding screen structure must be created. It therefore is incumbent on the programmer to decide which fields are to become part of the user interface and will consequently require representation within the screen structure.

Field NCHMC is considered to be strictly technical; therefore, it is not needed in the user interface, and will not require corresponding representation within the screen structure.
Field GBPAS is considered to be relevant for certain countries, but not for others. Because the screen structure to be created corresponds to an international (rather than country-specific) infotype, this field also is not needed in the user interface, and also will not require screen structure representation.
All other fields – NACHN , VORNA , GBDAT and ANRED – are considered to be relevant for the user interface. Therefore, these fields require corresponding representation in the screen structure, where they are defined, to facilitate processing, with the same technical names.

Using the same technical names provides a distinct advantage, because it enables the programmer to use the default conversion class – CL_HRPA_UI_CONVERT_BASIC – if desired. This class simply uses a MOVE-CORRESPONDING statement to pass the field values to the screen structure. (Even if a dedicated conversion class is required, the same statement can be used to simplify programming.) Moreover, using the same technical names ensures that the relationship between infotype fields and screen structure fields remain transparent.

In addition to the fields from structure P9001, suppose that the following fields are required on the user interface:

FULL_NAME

This field should provide a concatenation of the first and last name of the employee. With this field, users should be able to enter the full employee name in a single user interface field.
AGE

This field should display the current age of the employee.
FORM_OF_ADDRESS_TEXT

This field should display the descriptive text for field ANRED ( Form-of-Address Key ). In other words, in addition to the key (numerical) values that are stored in field ANRED , the corresponding descriptive text ( Mr. , Ms. , Dr. , and so on) should be displayed on the user interface.

In summary, the screen structure should contain the following fields:

Screen Structure Fields for Infotype 9001

Field Name	Short Description
NACHN	Last Name
VORNA	First Name
FULL_NAME	First and Last Name in One Line
GBDAT	Date of Birth
AGE	Employee Age
ANRED	Form-of-Address Key
FORM_OF_ADDRESS_TEXT	Form-of-Address Description

Because of the screen structure fields FULL_NAME and AGE , specific requirements exist for this infotype, and the default conversion class CL_HRPA_UI_CONVERT_BASIC cannot be used. Therefore, a dedicated conversion class for this screen structure is required, and the programmer must implement methods OUTPUT_CONVERSION and INPUT_CONVERSION therein. However, for field FORM_OF_ADDRESS_TEXT , the automatic retrieval of descriptive texts can be applied, meaning that only the appropriate Customizing is required, rather than dedicated source code.