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.


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.

     MODULE dynpro_pbo.
     MODULE dynpro_pai.

– Declare these two modules either directly in the report or inside an include.

MODULE dynpro_pbo OUTPUT.
          iv_dynpro_number    = sy-dynnr
          iv_program_name     = sy-repid ).
MODULE dynpro_pai INPUT.
          iv_dynpro_number    = sy-dynnr
          iv_program_name     = sy-repid ).

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
                         iv_program_name  = im_program_name
                         iv_dynpro_number = im_dynpro_number.

– 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
" The constructor method can be used for initializations.
          METHODS constructor
                    value(iv_program_name) TYPE bus_screen-program_name
                    value(iv_dynpro_number) TYPE bus_screen-dynpro_number.
" 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.
" 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.
CLASS lcl_demo_main_screen IMPLEMENTATION.
     METHOD constructor.
                    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.
     METHOD call_screen.
          CALL SCREEN iv_dynpro_number.
     METHOD call_screen_starting_at.
          CALL SCREEN iv_dynpro_number
                                   STARTING AT iv_xstart iv_ystart
                                       ENDING AT iv_xend iv_yend.
     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.

– 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.
     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( ).

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).

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

    1. Tudor Riscutia Post author

      Although the Screen wrappers are local classes, they still need to be instantiated by the framework. The form routine is called from outside the program in order to both instantiate and register the local class as a BUS object.


Leave a Reply