SAP ENCAP CLASS INTERF - Guide
Get Example source ABAP code based on a different SAP table
GUIDELINE 5.19
Encapsulating Classical User Interfaces
ABAP_BACKGROUND
The
However, SoC was rarely implemented in classical dialog programming. Here, presentation logic, application logic, and persistency logic were often combined in a monolithic module pool.
ABAP_RULE
Only create classical dynpros and selection screens in the presentation layer programs specifically provided for this purpose. You can use function groups as the program type.
ABAP_DETAILS
When using classical UI technologies, you need to separate the display logic from the application logic for the following reasons:
In addition, the communication between classical dynpros/selection screens and ABAP programs is implemented using global variables. This poses conceptual problems and cannot be combined with a modern, object-oriented approach for application programs.
Since class pools do not support classical dynpros and selection screens, you can only use function groups for encapsulation. In this role, a function group must be considered a global class. Here, the data of the global declaration part assumes the role of the private attributes, and the function modules assume the role of the public methods. The relevant procedure is demonstrated in
Besides UI elements, these function groups can only contain display logic in the form of local classes. The application logic communicates with the display logic using the function modules of this function group. You can still call the first dynpro of a dynpro sequence using a transaction code. This method is used in cases where the user starts the application.
The guidelines described in this book are also valid in function groups. It is especially important that the
Exception
Following the above rule means you cannot use standard selection screens. Therefore, it is necessary to make an exception to this rule for executable programs that are executed during background processing. This is because the required parameter interface must be a standard selection screen defined directly in the program. An encapsulation in a function group is not possible here. However, in this case, the events of selection screen processing should only call one appropriate method of a local class within the executable program.
Bad example
A classic dialog program - usually a single module pool - processes all the facets of an application.
Good example
The following source text shows a part of a function group
PARAMETERS g_name TYPE demo_cr_customer_name.
SELECTION-SCREEN END OF SCREEN 200.
reservations TYPE TABLEVIEW USING SCREEN 0100.
g_customer LIKE LINE OF g_customers.
g_reservation LIKE LINE OF g_reservations.
PUBLIC SECTION.
CLASS-DATA car_rental_service
TYPE REF TO if_demo_cr_car_rentl_service.
CLASS-METHODS: class_constructor,
status_0100,
user_command_0100,
cancel.
PRIVATE SECTION.
CLASS-METHODS: customer_search_by_id,
...
ENDCLASS.
PUBLIC SECTION.
CLASS-METHODS: change_tc_attr,
mark.
ENDCLASS.
...
* Function Module
CALL SCREEN 100.
ENDFUNCTION.
* PBO Modules
screen_handler=>status_0100( ).
ENDMODULE.
customer_table=>change_tc_attr( ).
ENDMODULE.
...
* PAI Modules
screen_handler=>cancel( ).
ENDMODULE.
screen_handler=>user_command_0100( ).
ENDMODULE.
customer_table=>mark( ).
ENDMODULE.
...
* Local Class Implementations
...
Dynpro