Skip to Content
I have several weblogs that have been sitting in my drafts folder for some time now. They aren’t the most exciting weblogs, nor do they cover cutting technologies. For that reason they keep getting pushed to the bottom of my work pile. I decided this week it was time to get caught up.

My first catch-up weblog really grew out of the same question that I hear over and over again: My company only has R/3 46C. How can I as an ABAP programmer prepare myself for the new Netweaver technologies (such as BSP, WebDynpro, Portal, Java, etc)? My answer is always the same: start writing as much ABAP OO as possible. There are plenty of good weblogs on ABAP OO on SDN. I would also suggest looking through the sessions from TechED of this year and the year before. However what I would like to do today is share a detailed example of a typical ABAP Dialog Report written as a Global ABAP OO class. My purpose it so show those that may not have given ABAP OO a try yet how powerful and flexible it can be. This weblog is also for anyone who might have some experience with ABAP OO in controls programming, but who has never really tried Global Classes for this type of programming.

The Application
Well let’s start off by having a look at what my application is trying to do and how it does it. What we are going to look at is a basic Bill of Materials Report. It is similar in form and function to the standard SAP transaction CS11. However my company wanted to add extra information (such as linked Document Information Records, Texts, and AMPLs-Approved Manufactures’ Parts List) that the standard report didn’t have. We also decided to structure the report as an ABAP Column Tree so that the levels of the BOM could be represented as indented nodes. The following is a screen shot of the report (sorry I had to blur much of the data to protect my company – hopefully everyone still can see how the report works).


The main screen of the report is made up of a custom container with a Tree Control and a Custom ToolBar in it (divided by a splitter control). So we know that we will have control based events to program for. However some of the buttons on the standard Dialog bar (such as back, exit, etc.) are also active. Therefore we will also have standard Dialog events.

Like any good report we have a selection screen. For this I have used normal ABAP Select-Options and Parameters.


Finally before we get into the coding itself there is one last element to consider. If the user doesn’t choose an alternative on the main screen and there is more than one on the BOM, we display a popup screen and make the user choose one. The follow is what this popup looks like.


The Dialog Program
We will start by looking at the dialog program itself (and the lack of code that is contained there). Basically the dialog program will still be our entry point. We also still need the dialog program because of some limitations in ABAP OO, the main one being that you can’t work with dialog screens. That means that our Call Screen and any PBO or PAI logic has to reside still in a dialog program. Also I had to put my selection screen definition in the dialog program. You should see that even with these limitations, there are still ways to put the majority of your logic in your global ABAP Class. We will look at each section of the program in pieces with comments. However at the end of this section I will include the complete coding for the dialog program so that it can be view in context.

We will start off by looking at the global Data section. You will see that I still need a variable for my OKCode from the dialog screen. Other than that all I have is an instance declaration for my global class.

Next up is my Selection Screen definition. Nothing really very interesting here until we get to the value-request selection and at selection-screen validation. This is really the first piece of application logic we encounter. I wanted to put this in my class, but it isn’t instantiated yet (You will see later why I wait to instantiate). Therefore I implemented this logic as static methods of the application class.

Finally we reach the start-of-selection logic itself. We will start this section with another call to a static method in order to perform more checks. We are now ready to instantiate our class. With this we pass into the class constructor many of the selection screen fields. Next you can see that even our custom authorization check is contained in the ABAP OO class. At this point we pass in the name of the calling dialog program. This way not only do we have security inside the class, but also for every dialog program that might consume it. Next you can see how the dialog program can work directly with global attributes of our application class. Finally we see that if everything has progressed correctly up to this point, our dialog program will call our main screen (which as far as screen elements, only contains one full screen custom container).

You might notice that I passed a selection option (dokar) into my constructor. To make this easy I created a table type with the structure that would match this range table.


The only other thing about this to pay attention to is the fact that I passed the selection option with a [] on the end of it. Selection Options automatically create ABAP internal tables with header lines. Internal Tables with header lines are no longer allowed in the OO context. Therefore I strip the header line as I pass it to the constructor by using the [] addition (which means – just process the body of the internal table).

Finally before we leave the dialog program we have to look at the dialog flow logic modules.

You can see that once again any of the logic of the program is actually implemented in the class. Even the constants for the OKCode check come from the class (more on that in a minute).

Finally as I promised earlier, the following is the complete code of the dialog program:

The Class Layout
We are ready to start looking at the application class itself. The first interesting thing that we see is from the Properties tab. From here you can see that my application class actually has a higher level Superclass.


Remember that this report is about Bill of Materials. My company has several applications and reports that all read BOM data. Therefore we decided to build one class that would have all the necessary data retrieve routines. Not only would this class contain the logic to read a full exploded multi-level BOM (provided by SAP Function module CS_BOM_EXPL_MAT_V2), but also to gather any additional details about the BOM we might need. The following are the methods and attributes that our report class will be inheriting from this Basic Data Retrieval Class.



Our next little bit of inheritence magic comes in the form of an interface that our application class implements.


My company has written many dialog programs structured like the one here. There are quite a few things (like OKCode constants) that are the same in each one of them. Therefore we place all these items in a general dialog application interface.



Before we move into the some of the logic in our application class itself, let’s first look at the structure of some of its methods. You can see in the following screen shots that we have our two methods from our interface that have been redefined in our main class (MAIN_SCREEN_PBO and MAIN_SCREEN_PAI). In light blue you can see our inherited methods from our super class. Later you can see that very few of the exposed methods are public. Only those that needed to be called from the dialog program are marked public. Everything else is defined as Private to make sure that no programmer is tempted to take a short cut and change any of the internal logic from within the dialog program. Finally you can see that a few methods are marked with the event handler icon. These are the event handlers for the controls (toolbar and Tree).


The Class Logic
Once inside the application logic that is implemented in the class, there really isn’t that much that is special. However there are a couple of special features that I would like to discuss. The first of which is the control event handlers. This is one of my favorite reasons for creating global application classes. I used to just create my control event handlers as local classes. Not only is this a lot of coding to build the definition of the event handler and its parameters, but I found it difficult to keep them organized in the containing program. Even if I broken them up into includes, this just seemed messy to me. However you will see how nicely everything is organized in the global class builder. First of all our event handler stand out from our other methods because they are marked with the event handler icon. Now if we select one of these methods and hit the detailed view button, we can see what class and event they are a handler for.


Furthermore it is also very easy to pull in all the parameters for the event handler. There is a special button on the Method Parameters screen that will copy all parameters from the event definition. That sure saves on the typing and eliminates the possibility of mistakes compared to local classes.


The last thing that I want to discuss about the logic in the class itself has to do with the before mentioned restriction on interacting with screens from within classes. Remember that we had the requirement to call a popup subscreen from within the class processing. This means the within the class we must call a function module to do this. The other option would have been to use the dialog box container control, but that doesn’t fill every need to interact with screens. I know that WebDynpro is the way of the future, but my #1 request for ABAP is still to have an OO implementation of the classic Dynpro screen.

Also to come out of this limitation is that sometimes you might want to trigger navigation (perhaps within a control event handler). I have a sort of trick to accomplish this. First I set a global attribute in my class to a particular value signifying what screen I want to navigate to. Then I use a call to the control framework to trigger a PBO/PAI dummy event. I then have corresponding logic in my PBO/PAI dialog module to direct the flow to the screen signified. Have a look at the following code for an example:

If you have read this far, I assume that I have bored you with the details of my little BOM report. Hopefully this example shows just how functional ABAP OO is in 46C for writing just about anything. It also shows a few of the limitations that I really wish that SAP would address at some point in the future.

To report this post you need to login first.


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

  1. Peter Inotai
    Hi Thomas,
    Thanks for this weblog. One of the most useful/interesting weblog I’ve seen in SDN!
    Hope you’ll write more weblogs about this topic.
  2. Igor Barbaric
    Hello, Thomas!
    Not only that it’s a good content, but also very nice outlook of your weblog. I’m happy to see one more person being thrilled about OO ABAP.
    I have also posted a weblog on very similar matter: OO ABAP and design patterns – from novice to success.
    Here I described how I’ve created not only a great application based on OO ABAP and generic design patterns, but a system of global components for building complex applications. I proved it’s value by making and maintaining more applications based on this frame.
    Basically, it’s a command tree to the left and objects which respond to commands via a special interface. They can open in auto-shrinking docking containers to the right, or do something else.
    One of interface implementations contains an improved ALV grid which is capable, among other custom features, of maintaining content of a DDIC table completely independantly.
    Unfortunately, my weblog looks very boring – it’s a plain text because I didn’t know how to put some rich formatting in it.
    Please give me some suggestions, because your weblog looks really great! For instance, how do I upload a picture?

    Now, again about OO. The idea that tickles me is how to overcome one great disadvantage of OO. While being good with trees and tables, OO doesn’t have a good form control (at least I haven’t found it) where you could lay the fields in any way you want, so that it looks to the user exactly as some dynpro form with fields with search help, tabs, buttons etc. I was thinking in 2 directions:
    1. Try to use dynamic documents or other HTML based control – there are many disadvantages: for example, you can’t easily attach search help or dictionary field checks to the fields (besides, I’m not very good at HTML – maybe that’s why my weblog looks bad)
    2. Create a hybrid component: an OO component which communicates with standard dynpro and abstracts as much as possible of it – disadvantage is, ofcourse, that it would be a hyb rid which couldn’t meet all of the object paradigm requirements (encapsulation, polymorphism).
    What do you think? I can see that you were also lead by the idea of abstracting the dynpro stuff as much as possible.
    Kind regards,

    1. Thomas Jung
      I’m glad you enjoyed the weblog.  I remember reading your weblog shortly after it was originally posted.  You certainly took ABAP OO to new areas! 

      As far as the formatting of the weblog, that’s all basic HTML.  I believe there was a weblog that Mark Posted some time back about the dos and don’ts of writting a weblog.  You can also do a view/source in your browser on a weblog page to see some of the HTML tags that people are using. 

      For uploading picture, you can do this from the same menu where you create draft weblogs.  There should be an option on the end of the top menu that says Upload Image.  You can then cut an paste the generated URL into your weblog.

      Now to the good stuff:  I too have faced the limitation of ABAP OO and forms elements.  It is a shame that all the classic screen elements are not exposed as ABAP OO classes.  It seems like SAP stopped half way by implementing the control framework, but never exposing screens or form elements to it.  I think that the technology somewhere got distracted by the whole WebDynpro is the way of the future theory.

      I have heard people try the deynamic documents, but I personally don’t care for the implemenation.  I would think that trying to control a standard dynpro though OO would be difficult given the missing hooks in the OO implementation. 

      This is one of the main reasons (frustations) why I took up BSP application programming.  I think that you would really Love the Model-View-Controller framework in BSP.  It is ABAP OO at its finest. 

      1. Igor Barbaric
        Hi, Thomas!
        Thanks for your weblog hints and oppinion on dynpro forms.
        It depresses me to learn that, after creating many good controls, SAP came into a dead end. I consider lack of a form control a critical bottleneck for developing good applications. That’s why I considered making something on my own. But other experts’ pessimism discourages me too.
        I guess that I’ll try to switch to BSP too, but I must express my regrets. I believe that hybrid programming doesn’t have a bright future, and developing good applications can’t be possible without forms. Which means that my effort on generic application framework (apart from already made applications) was more or less wasted. Well, at least I gained some experience.
        What would be a good starting point for BSP? Is there a book, help file, weblog, or anything for beginners?
        Kind regards,
        1. Thomas Jung
          You might want to have a look at the following weblog:

          Using .Net Windows Controls in the ABAP Control Framework

          With the technology described here I wrote my own form elements into ABAP OO.  However I haven’t used them extensively due to SAP’s direction change away from controls technology.

          As far as BSP – you are in the right place.  There is an excellent forum in SDN where you can learn a ton just by lurking.  You will find lots of weblogs on the subject as well.  There are a couple of books.  Check the SAP Press website:

    2. John Patterson
      I agree with you in point 2 a requirement of any true object-oriented programming is polymorphism and encapsulation, inherent with ABAP and ABAP workbench are restrictions, to get round this we have to create a hybrid solution, ABAP and the ABAP workbench are second to non.

      As you point out promoting abstaction of the dynpro as much as possible and creating a ui controller framework will enable you to get that much further. I found you that a nice trick is if you re-define and instantiate a class locally in a program ( module or function pool ), you can bind the business data to the dynpro through the controller in a similar manner to the described appl->pbo / pai.

  3. Randy Gibbons
    Horst Keller and Gerd Kluger’s Sept/Oct 2004 SAP Professional Journal article on “eight reasons to use ABAP Objects” makes a fine theoretical case and has an appendix “Decoupling Classical Screen Programming from Application Programming Using ABAP Objects” that gives a skeleton example. But most ABAPers I know need the kind of detailed example you have presented here before they are willing to take the plunge.
    1. Thomas Jung
      I read anything I can find written by Horst Keller.  Those works combined with several excellent SAP TechED sessions in the past years are the foundation that many of my ABAP OO applications are based upon. 

      Anyone who found this weblog interesting would do good to lookup those items.

  4. Rohit Surya Venkataraman
    Thanks Thomas.
    This weblog came as a blessing as I’m stuck in a similar situation. This shows how to adopt ABAP OO is our daliy reporting developments and also prepare for the SAP Netweaver league.


  5. John Patterson
    After working on WebAS based systems for the last couple of years, where available are existing UI frameworks like BDT, UAP, BSP and even webdynpro, which promote these new concepts and practices. I found it hard when asked to go back to developers who work on 4.6 system and explain to them MVC and web services, and tell them their future is ABAP Objects, Design Patterns and SOC, learn now before the upgrade.

    Sure enough in 4.6 you can access the Class Builder, but without real world examples the concepts explained in “eight reasons to use ABAP Objects” become a challenge to developers wanting to take the next step.

    Your blog shows the baby steps necessary before the sprint. I like what you did with the general application interface class, this is the first step to creating the foundation framework. The concept of reuse is not only a powerful tool for teaching good practice, but also the concepts of inheritance, abstraction, encapsulation etc

    Keep up the good blogging and may i make a request and ask for a blog on the next step – MVC for ABAP 4.6

  6. Stefan Kozlowski
    Hi Thomas,

    thank you for this interesting weblog. I have a comment on the PBO/PAI handling. Of course in this scenario it will work perfectly; adopting the here used mechanism by directly calling appl->main_screen_pbo / appl->main_screen_pai for a multiple screen program with navigation may lead to a raising call stack which each navigation (if I understood it right).

    I am currently implementing an User Command Handler method, which calls the Dynpros (via functions) dependent on the Command, which contains a loop with the Exit Commands as condition, and I am leaving the Dynpros directly (LEAVE TO SCREEN 0) to return to the User Command Method. I don´t know if this solution is a good one.

    Are there some best practice scenarios out here, that show dialog transactions with multiple screens implemented as ABAP OO approach?

    Best regards,

    1. Thomas Jung Post author
      I have to admit I am a few years out of practice from a lot of classic dynpro programming.  I’ve been doing mostly Web Dynpro ABAP and a bit of BSP these days.

      You do have to be careful how you use call screen.  From the online help:
      In a dynpro sequence started by a transaction code, you can nest up to 50 other dynpro sequences.

      Leave to Screen does work around this issue because it resets the processing block of the program and dynpro.  However it has its own issue that it can’t be called within Control Framework events.


Leave a Reply