Skip to Content

This blog might look like SAP marketing. It is not. It might sound a little pathetic or provocative, ok, might be. But the things I am going to describe are very important for me and should for every developer. This is my opinion and you don`t have to agree.

When I was just an ABAP kid, I used to write ABAP as if it is PHP or Pascal. I had no idea how to use standard, how to debug standard or what treasury is hidden in there. My codes were very talkative and most of things I needed to do I did through SELECTs and LOOPs plus standard types (like I and C and TYPES command). Not the right way how to do ABAP, but this is how I began. Maybe you can even recognize some pieces of your own experience here.

In next weeks I started using some function modules, but only those I had to. READ_TEXT, SAVE_TEXT is just so important and saves so much work. It is also easy to understand how they work, so it was not difficult to start using things like that. Same applies on printing for example, the function modules are well known and the only way how to do the printing.

I didn`t have to use much of the standard. I was not forced to do that. I didn`t have anybody to ask how to do that. I was scared about the complexity. So I was spending time building things by myself. But that`s nonsense. Now I know.

One of the things I regret the most since I started with SAP is that I didn`t care enough about the standard. I didn`t understand how powerful it is and how much work/ time/ effort can one spare this way. That`s why I am writing this blog. To explain the importance of reusing SAP standard and to thank the SAP developers for building the code the way we can reuse their work in most cases.

If you`re young and can spend nights and weekends finishing things you were not able to finish during the work week, you can spend time building things from scratch. In that case you only care about the result – works or does not work. But there is much more to care about:

  • Number of custom objects – well this is not a typical concern; it is not a problem when you create few more objects. But what if all the developers create “some more” dictionary objects than are necessary and they keep doing that for weeks? Months? Years? Don`t you feel that this could be wrong? Or that it could cause some problems in the future? Maybe it is not considered best practice, but before creating a data type, why don`t you check SE11 if a similar data type you could reuse, is not there already? My favorite example: you need a table type for a standard structure. In my opinion a good way of building things is to check “where-used list” for the standard structure. You will most like find an existing table type. My point is that we should care more about the customer and his system and understand the big picture. Developer`s responsibility does not end at 5 o`clock. 
  • Custom code management – the example about numbers is mainly about feeling the problem. That it might cause problems. Most people don`t care because they finish their development and move on (another project). Or they “only build things and that`s it”. You think you only a small fish in a big pond, aren`t you? Some people don`t see the big picture (or they simply ignore it?): system full of custom development becomes insecure, can`t be upgraded (at some point in time, not like tomorrow), code maintenance costs are too high, changes of the custom code cause unpredictable behavior, stuff like that. Who cares about these things, throw a stone. Every one of us adds a small piece to the problem which arises after a longer period of time, but sooner or later it will arise. If we all try to be slightly more precise the big picture could change considerably.
  • Team work – when you`re working in a team, why bother your colleagues explaining how is your super great function module working when there is a comparable standard one – stable (tested), documented, part of the standard (already in all the systems), used in standard development (so one can use debug to see how it works, how it is called). I used to bother my colleagues: “hey guys, see what I have built”. I feel so ashamed now, when I realize I caused them extra problems instead of being helpful. Other example: what if two of the team members build their own function modules doing the same? Inconsistency! Or at least a risk. Create similar data dictionary objects? Can you feel how much hassle you add to the development process instead of simplifying?
  • Documentation – everything you create you`re supposed to document. The more you create the more you have to document. So you add the amount of work at least twice: you create more and then document more. And if we would discuss the topic carefully we would find even more extra or repetitive work caused by the careless reuse of SAP standard.
  • Reusing not only how it “works” but also the “look and feel” – quite often you don`t build something completely new. You don`t build new SAP module like every day, right? You`re trying to build something what you miss in the standard, tweak the standard behavior a little. So every time you build something, there are user expectations (based on the current user experience) about how the new report/ transaction will look like, interact with them etc. My point is that in such cases one could consider the best practice to reuse the existing dialogs (screens + behavior). Ok, let`s do that. How do you reuse them? You copy the screens? Recreate them? No way, you will look for a way, how to call the existing dialog, right? That means you will look for a function module I guess (thanks SAP guys that so many of the dialogs are nicely wrapped up in a function modules). So because of the UI you will most probably reuse “some” functionality behind it. And I could continue like that. If you believe in this way, you can get to 50% of standard code reusability, 60%, 70% etc.
  • When the upgrade comes… – well, this point was a part of the custom code management bullet above, but maybe I should emphasize it as a separate point. Example: you copy a function module into a Z-one, change it and happily finish your development. Then the upgrade comes. Then your code must be revised and fixed manually although the upgrade brought the fix for free. Or you handle things the way you found in the standard code, but then adapted the algorithm in your custom code. Then the upgrade comes and the standard table you were reading with your custom code changes. Boom. You have to fix it manually. I am sure you get my point.


One of the reasons for writing this blog is that I think that understanding the concept of reusability made me a better developer. It taught me a lot about SAP builds its software. It taught me about features I didn`t know before. It taught me about additional costs I didn`t realize when I was just an ABAP kid. It made me realize that I was not top efficient. And many other things…

Maybe I am explaining something obvious. Something you know for years. Ok, I am not here to tell the pros how they`re supposed to build their code. But still hope that there are some beginners there or even experienced programmers, who can admit that they could do better, who will follow my advice. 

Using /h should be something you do like every day. Call stacks, local and global variables tab in the debugger and much more. It will not take long and you will understand the prefixes of the function groups. You have to start thinking about that and it will come to you.

I was going to end my story here, but realized that I might get some suggestions to learn about BADIs, user exits, enhancement points. I know how they work. I saw some cool nightmares in the customer system caused by these modifications. So not everything is Gold that shines…

To report this post you need to login first.


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

  1. Former Member
    Good Article… Not only it summarized the common ABAP pitfalls very well but it also provides a good guideline to the new ABAP developers.  Having been in ABAP related development field, I observed the following.

    Number of custom objects – As a rule, ABAP developers must try to find standard DDIC objects (like Data element, domain, search help, structure, table types etc) before deciding to create new.  90% of the time, they will find the one that will fit their requirements. Also, the mature ABAP shops normally have a Pre QA review process in place to approve specific DDIC objects (mainly tables, views and structures) before they are created in Development Box.

    Custom code management – Though the individual developer is important part of the equation but the responsibilities also lies on leadership (development manager/director).  The leadership should embrace and reward the principle of development of reusable code rather than finishing the current assignment fast and move on the next.  Service Oriented architecture principles can very well be adopted in ABAP development by exposing the self sustained functionality using well defined interface. It is better to use classes and methods to house the re-usable code because classes can be inherited and extended and methods can be overridden without changing the origin class.

    Cloning – As you mentioned, the cloning of the program shall be done only in the cases when there is no other alternative available. There is not much difference in core modification and cloning because both seem to pose a lot of difficulty during upgrade.  Thanks to SAP for providing enhancement framework implicit enhancement points, which makes it much more easier to change and modify the standard SAP behavior without using code modification and cloning.

    1. Otto Gold Post author
      I am very happy to read your detailed comment. I can see the time and effort you put into the comment as well as into the education of yours. If I will few more comments like yours I will most probably compile the ideas in the continuation of this blog. I consider the topic to be VERY important. And something I was not told much about.
      cheers Otto
  2. Ivan Femia
    I used to be, as much as I can, compliant to SAP standard; find already build-in function modules, data elements, classes and even more try to be close to the standard behavior when I had to extend some standard functionality.

    As you said you do not need to reinvent something that is already working (and it is “certified”).

    You are right also for the upgrade: I performed several upgrades and two of the worst problems, that I faced, are:
    1. standard modifications (sometimes without the assistant) that risk to modify standard logic instead of the use of user exits or Badi.
    2. Cloning several standard function module to modify just few lines of codes (sometimes we solved with simple standard customizing)

    1. Otto Gold Post author
      It is important to share the idea of feeling the responsibility for the code, because I have seen systems, which were unupgradeable after all the modifications and custom development.
      This is something the customers can`t accept.
      Thanks for kind and supportive words,
      cheers Otto
  3. Former Member
    Hi Otto,

    good blog, I fully agree with you. It makes me realize that it would be helpful to post a blog on how we find standard objects. I believe we all have our tricks to find what we are looking for. A main part of being an “ABAP adult” is to find your way through the jungle of standard objects. Ironically, standard ABAP OO, such as classes and methods, are often the most difficult to find and reuse.


  4. Juan Reyes
    Good Blog Otto, shame I can’t add anything to the subject as I’m not an ABAPer but using the standard code to the ABAPer advantage is not only good / greener / more traceable, but also help your “Basis fella” hit the jackpot in case of a problem. ๐Ÿ˜€


  5. Former Member
    Great Concept!  Wonderful to be able to do.  Much harder to be able to do.  I struggle with doing it.  Maybe a great programmer could find/use classes easy.  Create objects at the drop of a hat!

    I am not one of those developers.  So I do all of the above as much as possible.  (Some of it on my time.)  But when it comes to the end of timelines – projects need to be done.  Reusability slips.  I tend to write what needs to be written to get the job done.  (Yes, I still do things like performance tuning, Staying up with our standards, but those are not as hard as reusable code.)

    Bird dogging – Keeping an eye on consultants – becomes a real issue as well.  I’ve found that the OK consultants tend to use programs that are developed for their projects.  They do not set them up as reusuable.  The great ones – they do think about future use.

    Anyway – keep these blogs coming!  I strive to be a better developer every day.  ๐Ÿ™‚


  6. abilash n
    Yes Otto you are correct. I Completely agree with you.
    Can we expect tricks to find what we are looking for finding standard objects in this blog as continous or in new blog….
  7. Luke Marson
    A good blog.

    I am currently at a client where they use a custom table that links to HRP1050 using EVPTS (evaluation points). Only in their custom table they store the EVPTS requivalent value as 2 digits (without the trailing zeros, e.g. 59) when in HRP1050 EVPTS is stored as 5 digits (e.g. 00059). This isn’t too bad for the purposes of ABAP, but they didn’t consider an application like SVSN OrgChart where the data cannot be displayed because it cannot match the two different values together (00059 = 59). Some foresight from the person that built these custom tables would’ve meant that they just re-used the data element for HRP1050-EVPTS…


Leave a Reply