Procedure

As you are implementing checks, it is important to consider the means you will use to indicate error conditions. Unlike prior releases, where message statements are issued to draw attention to errors, you may no longer use message statements in this release, as such statements now lead to errors in their own right.

In this release, you must therefore employ interfaceIF_HRPA_MESSAGE_HANDLERto handle messages. To add a message to this interface, employ methodADD_MESSAGE

Unlike prior releases, messages in this release are always created dynamically. For this reason, the Where-Used List in this release can no longer determine where messages are used. It is therefore useful to employ the statement“IF 1 = 0”to hard-code a “dummy” message. Alternatively, one could falsely assume that it is correct to employ theMESSAGE INTOstatement, so that breakpoints, where needed, could be set at this statement. However, this approach is unnecessary, because interfaceIF_HRPA_MESSAGE_HANDLERalready fulfills the requirement of setting breakpoints wherever needed; any breakpoints atMESSAGEwill always stop in methodADD_MESSAGE

Example

The following example demonstrates a case where the methodCHECK_REQUIRED_FIELDof check classCL_HRPA_INFTY_NNNNis called; for background information on the use of this check class, refer to a subsequent background topic .

METHOD check_required_field. DATA msg TYPE symsg. DATA field_list TYPE hrpad_field_tab. IF field_name IS INITIAL. RAISE EXCEPTION TYPE cx_hrpa_invalid_parameter EXPORTING parameter = 'FIELD_NAME'. ENDIF. IF required_field IS NOT INITIAL. is_ok = true. ELSE. IF 1 = 0. * 055 Make an entry in all required fields MESSAGE ID '00' TYPE 'E' NUMBER '55'. ENDIF. msg-msgid = '00'. msg-msgty = 'E'. msg-msgno = '55'. APPEND field_name TO field_list. CALL METHOD message_handler->add_message EXPORTING message = msg field_list = field_list cause = if_hrpa_message_handler=>infotype_specific. is_ok = false. ENDIF. ENDMETHOD.

The parameters shown in this example convey the corresponding meanings:

MESSAGE contains the actual text of the message.

FIELD_LIST contains the list of fields that the message affects. In dynpro terms,FIELD_LIST in this release is used in lieu of statement CHAIN, which was employed in prior releases. Because of this change, these fields are no longer determined by the dynpro, but rather by the logic that creates the message. In other words, the field list in this release is now contained within the business logic itself, rather than on the screen.

CAUSE informs the message handler why the error occurred, which allows the system to prioritize errors by their respective semantics. This command allows the system to handle errors caused by authorization checks, for example, in a different fashion than errors encountered by the infotype. This prioritization, in turn, facilitates the debugging process.

In addition to the above example, it is important to remember that filling the message variables with theMOVEcommand, unlike prior releases, no longer serves to perform output conversions. Therefore, if you wish to move data or time information into any of these variables, you should use theWRITE INTOcommand, rather thanMOVE. The same principle holds for any other variables that require output conversion.

Finally, it is also important to remember that whenever you add a message to interfaceIF_HRPA_MESSAGE_HANDLER, the system will always return control to your method. In the standard system, it therefore is possible (and indeed explicitly supported) for processing to continue, even after an error message has been issued. As a rule of thumb, it is reasonable to check all required input fields, even if one of them lacks the appropriate input. However, if you determine that you cannot continue your checks – for example, because you wish to compare two required fields, but one of these fields lacks the required input – then you should exit the method.