✒️ABAP La lógica de procesamiento en el PAI y la ejecución de las acciones

Conditional Execution of Modules

• When the clause ON INPUT is specified after MODULE in a FIELD statement, the module is executed only if the field in question contains a value different from the initial value.

PROCESS AFTER INPUT.
FIELD wa_screen_0100-dni
MODULE validate_dni_0100 ON INPUT.

• In the CHAIN-ENDCHAIN statement, use the ON CHAIN-INPUT instruction. Then, the module is processed only if at least one of the fields on the screen in the CHAIN-ENDCHAIN statement contains a value different from the initial value.

PROCESS AFTER INPUT.
CHAIN.
FIELD wa_screen_0100-dni,
<screen field>.
MODULE <module> ON CHAIN-INPUT.
ENDCHAIN.

NOTE: You can use the ON INPUT addition only if the MODULE statement is specified within a FIELD statement.

• If the ON REQUEST clause is specified after MODULE in a FIELD statement, the module is executed only if the field has a new entry.

PROCESS AFTER INPUT.
FIELD wa_screen_0100-dni
MODULE validate_dni_0100 ON REQUEST

• In the CHAIN-ENDCHAIN statement, use the ON CHAIN-REQUEST instruction. Then, the relevant module is processed only if at least one of the fields on the screen in the CHAIN-ENDCHAIN statement has a new entry.

PROCESS AFTER INPUT.
CHAIN.
FIELD wa_screen_0100-dni,
<screen field>.
MODULE <module> ON CHAIN-REQUEST.
ENDCHAIN.

NOTE: You can use the ON REQUEST addition only if the MODULE statement is specified within a FIELD statement.

• AT EXIT COMMAND: It is used to exit the screen using standard functions Back, Exit, and Cancel. We will use this clause in programs where the user is allowed to go back or exit the current processing screen of the program, i.e., in dialog programs or also known as module pools.

This dialog module is called before the automatic input checks defined in the system or in the ABAP Dictionary. If within the PAI of a module pool there are several MODULES that have the AT EXIT-COMMAND declaration, only the first one will be executed.

MODULE <ABAP_module> AT EXIT-COMMAND.
MODULE exit_0100 INPUT.
LEAVE PROGRAM.
ENDMODULE.

*&---------------------------------------------------------------------*
*& Module EXIT_0300 INPUT
*&---------------------------------------------------------------------*
* text
*----------------------------------------------------------------------*
MODULE exit_0300 INPUT.
MOVE ok_code TO v_ucomm.
CLEAR ok_code.

CASE v_ucomm.
WHEN 'RW'.
LEAVE TO SCREEN 0200.
WHEN 'EN'.
LEAVE TO SCREEN 0200.
WHEN 'EX'.
LEAVE TO SCREEN 0200.
ENDCASE.
ENDMODULE.

To use an AT EXIT-COMMAND on a field button, it will be necessary to assign the value E to the Function Type field attribute in the screen editor.

Handling Function Codes

When a user in a dialog transaction presses a push button, icon, or ENTER key, the entered data is passed to the modules defined in the PAI for processing along with a function code indicating which function the user requested.

Whenever we define a dynpro, we create a field of the function code type called OK_CODE.

In the processing logic of each dynpro, we need to handle the OK_CODE. For this, we'll use the USER_COMMAND module, which should be the last one in the PAI event, meaning it will execute once all input data has been validated.

• Module USER_COMMAND
  • After processing the function module, we clear the content of OK_CODE, initializing it for the next dynpro.
  • We can save the content of OK_CODE in an intermediate variable and initialize it immediately.

Difference between SY-YCOMM and OK_CODE in a dialog program:

• SY-UCOMM is mainly used in menus and contains the last action performed by a user.

• OK_CODE, declared in programs of type SY-UCOMM, is generally used in screens.

• OK_CODE acts solely as a temporary variable that stores the value of SY-UCOMM.

In our programs, we work with OK_CODE, not with SY-UCOMM, because:

• The program has complete control over the declared fields.

• Never change the value of a system variable.

*&---------------------------------------------------------------------*
*& Module USER_COMMAND_0100 INPUT
*&---------------------------------------------------------------------*
* text
*----------------------------------------------------------------------*
MODULE user_command_0100 INPUT.
MOVE ok_code TO v_ucomm.
CLEAR ok_code.

CASE v_ucomm.
WHEN 'BORRAR_D'.
CLEAR wa_screen_0100-dni.
WHEN 'LEAVE'.
LEAVE PROGRAM.
WHEN 'BUSCAR_U'.
CALL SCREEN 0200.
ENDCASE.
ENDMODULE.

*&---------------------------------------------------------------------*
*& Module USER_COMMAND_0300 INPUT
*&---------------------------------------------------------------------*
* text
*----------------------------------------------------------------------*
MODULE user_command_0300 INPUT.
MOVE ok_code TO v_ucomm.
CLEAR ok_code.

CASE v_ucomm.
WHEN 'CONFIRMAR'.
CALL FUNCTION 'POPUP_TO_CONFIRM'
EXPORTING
titlebar =
'Confirmación de la modificación' = ' '
text_question = 'Seguro?'
text_button_1 = 'Si'(001) " v_answer = '1'.
text_button_2 = 'N0'(002) " v_answer = '2'.
importing
answer = v_answer
exceptions
text_not_found = 1
others = 2.

IF sy-subrc <> 0.
MESSAGE e001(zprueba) WITH 'An error has occurred'.
ENDIF.

IF v_answer = '1'.
UPDATE zuser_table_jega SET: nombre_ape = wa_screen_0300-nombre_ape
direccion = wa_screen_0300-direccion
fnacimiento = wa_screen_0300-f_nacimiento
WHERE dni = wa_screen_0300-dni.

ELSEIF v_answer = '2'.
CALL SCREEN 0100.
ENDIF.

WHEN 'CANCELAR'.
CALL SCREEN 0100.
ENDCASE.
ENDMODULE.

Dynamic Sequence of Screens

In a dialog program/dialog transaction, we can control the execution sequence of each dynpro composing the transaction.

There are two instructions that allow us to move to another existing dynpro within the same program:

• The SET SCREEN statement "SET SCREEN <screen_number>."
  
  • This temporarily rewrites the next screen to be processed. The next screen must belong to the same Module Pool.
  • The next screen is processed after processing the current screen or until the execution of the current screen is finished with the LEAVE SCREEN statement. Upon executing this statement, the next screen is immediately executed.
  • If you want to end the processing of the current screen and go directly to the next screen in a single instruction, use the LEAVE TO SCREEN statement "LEAVE TO SCREEN <screen_number>."

• The CALL SCREEN statement:
  • It interrupts the processing of the current screen to process screen X and subsequent screens.
  • Its syntax is "CALL SCREEN 0200."
  • The screen called with this instruction must belong to the same Module Pool.
  • Any of the instructions: SET SCREEN 0, LEAVE SCREEN, LEAVE TO SCREEN 0, returns control to where the CALL SCREEN instruction was executed.
  • If any of the above instructions are used when not in call mode, i.e., when control has not been passed to another dynpro, then the program terminates.
  • Using the STARTING AT and ENDING AT clauses, you can specify the position and size of the screen to be called. For example:
  • If the screen appears incomplete, a scroll bar is included in it.