Output Conversion (Method OUTPUT_CONVERSION)
Definition
Implementation of this method is mandatory.
This method is the counterpart of method INPUT_CONVERSION , introduced in the subsequent topic.
Use
The name of the screen structure for which the conversion class is called is passed in parameter
SCREEN_STRUCTURE_NAME
. Moreover, the current infotype record is passed in parameter
PNNNN
. The foremost task of method
OUTPUT_CONVERSION
is to fill parameter
SCREEN_STRUCTURE
with the corresponding infotype values that should be presented on the user interface.
In the simplest case – where all fields have the same technical names in the infotype structure as in the screen structure – a
MOVE-CORRESPONDING
statement, as shown in the first example at the end of this topic, is sufficient to perform output conversion.
As illustrated in the second example at the end of this topic, in more complex cases, where the screen structure contains fields whose field names differ from the field names in the infotype structure, appropriate source code must be composed to fill all fields that belong to the screen structure … unless descriptive texts for fields that hold key values are to be retrieved. With this sole exception (as described in the topic
Automatically Retrieving Descriptive Texts
), no source code is required; provided that the corresponding Customizing has been performed, the de-coupled framework will automatically retrieve these texts immediately after method
OUTPUT_CONVERSION
is called.
Note
In the event that errors are encountered during output conversion, a corresponding message can be issued via the Message Handler (that is, parameter
MESSAGE_HANDLER
). All messages stored in this manner will subsequently be presented, when called for, on the user interface. Three types of messages can be issued – type
I
(for information), type
W
(for warnings), or type
E
(for errors). If error messages (of type
E
) are to be called, then parameter
IS_OK
must be set to the value
“ ”
(that is,
IS_OK = false.
). In all other cases – and especially when no message is to be issued at all – then parameter
IS_OK
must be set to the value
“X”
(that is,
IS_OK = true.
).
Importing parameter
MODE
currently is not used in the standard system; it is, however, intended for future use. Under no circumstances should this parameter be used in customer source code.
Importing parameters
MASSN
and
MASSG
respectively specify the action and reasons in which the infotype is currently running. In the event that the infotype has specific user interface requirements when run in a certain action, then it may be appropriate to code on these parameters.
Parameter
PNNNN2
provides the current record of the secondary infotype (that is, infotype view), while parameter
PREF
provides the cost assignment of the current infotype record.
In principle, from the perspective of
conversion classes
in the de-coupled framework, all fields of the screen structure are considered to be editable in the user interface … although the technology of the user interface in question ultimately determines whether or not the contents of a particular field truly can be edited. For all editable fields, appropriate processing must be defined in the implementation of method
INPUT_CONVERSION
. To this end, if a particular field should not be editable, or if that field should receive any other attribute, then the field property must be set accordingly in exporting table
FIELD_ATTRIBUTES
.
In that table, exactly one entry must be created for the corresponding field. The entry to be created in turn consists of the appropriate value in field
OBJECT_KEY
, as well as a nested table named
FIELD_ATTRIBUTE
. Field
OBJECT_KEY
should be set to the same value as the object key in parameter
SCREEN_STRUCTURE
. In the nested table
FIELD_ATTRIBUTE
, all fields must be stored by their technical names defined in the screen structure and with a corresponding property. The following three properties are supported:
A signifying read-only,
B signifying hidden, and
C signifying mandatory.
Any field that is not expressly listed in the nested
FIELD_ATTRIBUTE
will be assigned the properties of standard editable fields.
When setting the field attributes, the field metadata passed in parameter
FIELD_METADATA
can be taken into account. This metadata is read from
tables T588MFPROPS and T588MFPROPC
(the SAP and customer tables, respectively) and relates to the infotype fields of
structure
Pnnnn
, as defined in the (back-end) business logic. If you would like the fields of the screen structure to inherit the same attributes, implement method
CONVERT_AND_MERGE_FIELD_ATTRBS
of service class
CL_HRPA_FIELD_ATTRIBS_SERVICES
, as demonstrated in the first example below. It is important to note that this class cannot be used unless the user interface fields bear identical field names in both the screen structure and the infotype structure.
Note
Specification of the appropriate field attributes in the conversion class is a prerequisite for any working user interface. Nonetheless, the technology of the user interface in question – and by extension the application that is providing the UI – ultimately determine whether or not that user interface truly will reflect the field attributes specified in the conversion class.
Caution
Special attention must be paid to field
OBJECT_KEY
of parameter
SCREEN_STRUCTURE
. Although
SCREEN_STRUCTURE
is an exporting parameter, the de-coupled framework can nonetheless set the value of field
OBJECT_KEY
before calling method
OUTPUT_CONVERSION
, since parameter
SCREEN_STRUCTURE
is passed as “call-by-reference.” It is therefore imperative to note that in the de-coupled framework, the field
OBJECT_KEY
is strictly reserved for internal use. Never change or clear the value of field
OBJECT_KEY
!
Example
The first example provided below illustrates the simplest case where this method could be implemented, while the second example demonstrates a more complex case.
Example
METHOD IF_HRPA_UI_CONVERT_STANDARD~OUTPUT_CONVERSION.is_ok = if_hrpa_ui_convert_standard~true.CLEAR field_attributes. * ensure that method is called for the correct screen structureIF screen_structure_name <> 'ZHCMT_BSP_PA_XX_R9001'. RAISE EXCEPTION TYPE cx_hrpa_violated_assertion.ENDIF. * move values of fields with identical namesMOVE-CORRESPONDING pnnnn TO screen_structure. * set field attributes in accordance with field metadataCALL METHOD cl_hrpa_field_attribs_services=>convert_and_merge_field_attrbs EXPORTING field_metadatas= field_metadatas CHANGING field_attributes = field_attributes.ENDMETHOD.
Example
METHOD IF_HRPA_UI_CONVERT_STANDARD~OUTPUT_CONVERSION. * infotype structure P9001 contains these fields:* NACHN – Last Name* VORNA – First Name* GBDAT – Date of Birth* GBPAS – Date of Birth According to Passport* NCHMC – Last Name (Field for Search Help) -> not needed on UI* ANRED – Form-of-Address Key (key values 1, 2, … representing ‘Mr.’, ‘Ms.’,…) * screen structure ZHCMT_BSP_PA_XX_R9001 contains these fields:* NACHN – Last Name* VORNA – First Name* FULL_NAME – Full Name (Concatenation of First Name and Last Name)* GBDAT – Date of Birth* AGE – Employee age (Derived from Date of Birth)* ANRED – Form-of-Address Key* FORM_OF_ADDRESS_TEXT – Form-of-Address Description (descriptive texts ‘Mr.’, Ms.’,…)FIELD-SYMBOLS <p9001> TYPE p9001.FIELD-SYMBOLS <zhcmt_bsp_pa_xx_r9001> TYPE zhcmt_bsp_pa_xx_r9001.FIELD-SYMBOLS <field_attribute_wa> TYPE hrpad_obj_field_attribute.DATA field_attribute TYPE hrpad_field_attribute.is_ok = if_hrpa_ui_convert_standard~true.CLEAR field_attributes. * ensure that method is called for the correct screen structureIF screen_structure_name <> 'ZHCMT_BSP_PA_XX_R9001'. RAISE EXCEPTION TYPE cx_hrpa_violated_assertion.ENDIF. * assign and type structuresASSIGN pnnnn TO <p9001>.ASSIGN screen_structure TO <zhcmt_bsp_pa_xx_r9001>. * move values of fields NACHN, VORNA, GBDAT, ANRED (and header fields)MOVE-CORRESPONDING <p9001> TO <zhcmt_bsp_pa_xx_r9001>. * calculate field AGE based on the date of birth in GBDAT<zhcmt_bsp_pa_xx_r9001>-age = sy-datum+0(4) - <p9001>-gbdat+0(4).IF <p9001>-gbdat+4(4) > sy-datum+4(4). SUBTRACT 1 FROM <zhcmt_bsp_pa_xx_r9001>-age.ENDIF. * calculate field FULL_NAME based on names in NACHN and VORNACONCATENATE <p9001>-vorna <p9001>-nachn INTO <zhcmt_bsp_pa_xx_r9001>-full_name SEPARATED BY space. * no action required for field FORM_OF_ADDRESS_TEXT; this* descriptive text for field ANRED is derived from Customizing* set field attributes in accordance with field metadataCALL METHOD cl_hrpa_field_attribs_services=>convert_and_merge_field_attrbs EXPORTING field_metadatas= field_metadatas CHANGING field_attributes = field_attributes.READ TABLE field_attributes ASSIGNING <field_attribute_wa> INDEX 1. * delete field attributes for fields not supported in the screen structureDELETE <field_attribute_wa>-field_attribute WHERE field_name = 'GBPAS' OR field_name = 'NCHMC'. * set field AGE to readonlyCLEAR field_attribute.field_attribute-field_name = 'AGE'.field_attribute-field_property = if_hrpa_ui_convert_standard~read_only.APPEND field_attribute TO <field_attribute_wa>-field_attribute. * set field FORM_OF_ADDRESS_TEXT to readonlyCLEAR field_attribute.field_attribute-field_name = 'FORM_OF_ADDRESS_TEXT'.field_attribute-field_property = if_hrpa_ui_convert_standard~read_only.APPEND field_attribute TO <field_attribute_wa>-field_attribute. * set field FULL_NAME to mandatoryCLEAR field_attribute.field_attribute-field_name = 'FULL_NAME'.field_attribute-field_property = if_hrpa_ui_convert_standard~obligatory.APPEND field_attribute TO <field_attribute_wa>-field_attribute. * set field NACHN to readonlyCLEAR field_attribute.field_attribute-field_name = 'NACHN'.field_attribute-field_property = if_hrpa_ui_convert_standard~read_only.APPEND field_attribute TO <field_attribute_wa>-field_attribute. * set field VORNA to readonlyCLEAR field_attribute.field_attribute-field_name = 'VORNA'.field_attribute-field_property = if_hrpa_ui_convert_standard~read_only.APPEND field_attribute TO <field_attribute_wa>-field_attribute.ENDMETHOD.