In a world of Web Dynpro and cool UI5 libraries, I still find myself working with ABAP Reports and classic Dynpros. Being a techie, it is easy to imagine why I don't see these kinds of tasks very intriguing. Yet I wish to make it interesting by exploring modern (and better) ways to improve development.
So... This is a short guide on how to implement an ABAP report using the BUS-Screen Framework. Although this was initially intended for internal SAP usage only, it is not publicly available.
Misconception
If you search online on how to use BUS-Screen Framework, besides not getting a lot of results, you will also get some wrongful information. BUS-Screen Framework cannot dynamically create Dynpros. It is merely a way to structure reports in an object-oriented way.
Still interested? ... Great!
First and foremost, I have to recommend the book Anwendungsentwicklung mit ABAP Objects by Thorsten Franz and Tobias Trapp, which contains a whole subchapter dedicated to the BUS-Screen Framework.
All SAP objects related to this framework can be found in package BUS_TOOLS. This package also contains a small demo transaction, but I think it's a little unclear.
The following steps describe the basis for a screen implementation using BUS-Screen Framework:
- Create a new report with a normal screen. (I've named my screen '2000').
In the Flow Logic of Screen 2000, call modules dynpro_pbo for output, respectively dynpro_pai for input.
PROCESS BEFORE OUTPUT.
MODULE dynpro_pbo.
PROCESS AFTER INPUT.
MODULE dynpro_pai.
- Declare these two modules either directly in the report or inside an include.
MODULE dynpro_pbo OUTPUT.
cl_bus_abstract_screen=>dynpro_pbo(
iv_dynpro_number = sy-dynnr
iv_program_name = sy-repid ).
ENDMODULE.
MODULE dynpro_pai INPUT.
cl_bus_abstract_screen=>dynpro_pai(
iv_dynpro_number = sy-dynnr
iv_program_name = sy-repid ).
ENDMODULE.
NOTE: These modules must only be declared once and then reused for every screen (both normal and sub screens).
- One of the conditions for instantiating screens using this framework is to declare a form routine inside the program.
FORM bus_screen_create USING value(im_program_name) TYPE bus_screen-program_name
value(im_dynpro_number) TYPE bus_screen-dynpro_number
CHANGING ch_screen ##called.
CASE im_dynpro_number.
WHEN '2000'.
" This is the name of the wrapper class for Screen 2000
" If the called iv_dynpro_number is not found and the ch_screen is not instantiated,
" a dummy screen of type CL_BUS_ABSTRACT_SCREEN will be return.
CREATE OBJECT ch_screen TYPE lcl_demo_main_screen
EXPORTING
iv_program_name = im_program_name
iv_dynpro_number = im_dynpro_number.
ENDCASE.
ENDFORM.
- Now it's time to define the screen logic in an object-oriented way using a local ABAP class.
NOTE: Although class CL_BUS_ABSTRACT_SCREEN is the base, it is important to implement the correct inheritance. In this case, CL_BUS_ABSTRACT_MAIN_SCREEN must be used since 2000 is a normal screen. (For sub screens, the corresponding CL_BUS_ABSTRACT_SUB_SCREEN should be used)
CLASS lcl_demo_main_screen DEFINITION
INHERITING FROM cl_bus_abstract_main_screen
FINAL.
PUBLIC SECTION.
" The constructor method can be used for initializations.
METHODS constructor
IMPORTING
value(iv_program_name) TYPE bus_screen-program_name
value(iv_dynpro_number) TYPE bus_screen-dynpro_number.
PROTECTED SECTION.
" The following two methods must be redefined as ABAP Objects
" does not support the CALL SCREEN statement.
METHODS call_screen REDEFINITION.
METHODS call_screen_starting_at REDEFINITION.
PRIVATE SECTION.
" This method is the central handling for all PAI events in this screen.
METHODS handle_pai FOR EVENT process_after_input OF cl_bus_abstract_main_screen
IMPORTING iv_function_code.
ENDCLASS.
CLASS lcl_demo_main_screen IMPLEMENTATION.
METHOD constructor.
super->constructor(
EXPORTING
iv_program_name = iv_program_name
iv_dynpro_number = iv_dynpro_number ).
" The GUI Title of the application is set using the following method
set_title( 'DEMO BUS-Screen Framework' ).
SET HANDLER handle_pai FOR me.
ENDMETHOD.
METHOD call_screen.
CALL SCREEN iv_dynpro_number.
ENDMETHOD.
METHOD call_screen_starting_at.
CALL SCREEN iv_dynpro_number
STARTING AT iv_xstart iv_ystart
ENDING AT iv_xend iv_yend.
ENDMETHOD.
METHOD handle_pai.
CASE iv_function_code.
" For the default GUI Status, global constants can be used to evaluate the function code.
" However, if you set your own GUI Status using method set_status( ),
" then you will have to evaluate your specific function codes.
WHEN gc_function_code_back
OR gc_function_code_exit.
leave( ).
WHEN gc_function_code_cancel.
LEAVE PROGRAM.
ENDCASE.
ENDMETHOD.
ENDCLASS.
- Now that our screen is defined, we can call it. For this, the following code should be used in the START-OF-SELECTION event:
DATA lo_main_screen TYPE REF TO lcl_demo_main_screen.
" This statement will try to call the BUS_SCREEN_CREATE form routine that we previously defined.
cl_bus_abstract_screen=>get_screen(
EXPORTING iv_program_name = sy-repid
iv_dynpro_number = '2000'
IMPORTING ev_screen = lo_main_screen ).
IF lo_main_screen IS BOUND.
lo_main_screen->show( ).
ENDIF.
This pretty much sums up the basic functionality. In the next blogs, I will show you how to use the tabstrip wrapper (CL_BUS_TABSTRIP and CL_BUS_TABSTRIP_TAB classes) and also how to handle messages (CL_BUS_MESSAGE).
- SAP Managed Tags:
2 Comments
| User | Count |
|---|---|
| 6 | |
| 5 | |
| 3 | |
| 3 | |
| 2 | |
| 2 | |
| 2 | |
| 1 | |
| 1 | |
| 1 |
