Skip to Content

Some handy ABAP tricks

I am sharing some very useful ABAP tricks which I came across. Again, these might not be new for some people but still some of us are not aware of it.

“Somewhere, something incredible is waiting to be known” 🙂

Un-typed Field symbols

While dealing with un-typed field symbols of type ANY or ANY TABLE without any structure, I have seen most of people moving the data from the field symbols to an internal table and then the data manipulations are done on internal table.


While I came across a simple method of using field symbol while sorting and reading the data. We can specify the field name inside (‘Field name’). Doing this we can avoid the intermediate internal table and instead directly operate on the field symbol.


Similarly, we can use it for READ also.

Find the Enhancement name from the user-exit function module name.

While activating a customer exit, we need to have the SAP enhancement name to activate in CMOD. Now, it might be difficult to find out the SAP enhancement name from the function module name from the package name (traditional approach). A package name might have 100 or more exits enhancements and it might become herculean task. 😕

SAP has provided a table MODSAP wherein we can give the function module name and it will return the enhancement name. Then we can directly use the enhancement name to activate the exit.


Change status of any IDoc.

We can’t reprocess any successful idoc with 53 status. Now either way is we create a new idoc through WE19 and test again but that will generate a new idoc number or there might be a another scenario where few idocs are stuck in inbound queue. We can directly change the status of idocs in such cases and the successful idocs can be reprocessed again.


For that execute a report RC1_IDOC_SET_STATUS, provide the idoc number, old idoc status and new idoc status. There is also a test mode available to check if the new idoc status is possible.

Insert custom values in standard domains fixed values.

We can add our own custom values to the fixed values of the data dictionary standard domains. Like if we are creating a new custom status and we need to append the status to the domain.

In the menu bar navigate to Goto > Fixed Value Append


Provide the append name and the specify the fields.



Performance tip while using FOR ALL ENTRIES when the data becomes large

While I was doing the performance analysis of a code in SAT tool, I noticed a strange thing while using FOR ALL ENTRIES. When the data in the FOR ALL ENTRIES tables becomes huge close to 100 thousand or more, in such cases it is better to fetch the whole data of the table instead of using FOR ALL ENTRIES. I notices a significant change in the above case.

But I must say this is not a conclusion but a subjective observation and it might be helpful in some cases.

You must be Logged on to comment or reply to a post.
  • /
  • But I must say this is not a conclusion but a subjective observation and it might be helpful in some cases

    This is how "performance fads" are born, do not present half-baked facts. If you think this is your "subjective observation" then at least present the results of the SAT analysis to back it up.

    - Suhas

    • Thank you for pointing it out.

      Well that was definitely not a half baked fact and lets not pretense it as a performance fad. 🙂 But that was a scenario based observation and I could have explained the scenario as well. I will definitely try to take this topic separately as it is difficult to elaborate it here.

    • I don't think any half baked 'facts' are presented by Sanyam. Sanyam has clearly said it is not a conclusion. How does that become a fact?

      Please appreciate that someone has gone through the effort of sharing. If you do not agree with something, you can present your point politely without getting rude!

      • What exactly are you finding rude in the Suhas's comment? When someone makes a performance suggestion, it should be backed up by some solid evidence, which was not done in this case. That's exactly the problem - there are no facts here, the author just makes a statement and then hides behind a "disclaimer".

        SCN is a professional site, not a preschool, so simply "effort of sharing" doesn't cut it, I'm sorry. The information shared needs to be valid, otherwise what purpose would such sharing serve? Actually I'm not sure why it was necessary to open that FAE can of worms again. I thought it was put to rest sufficiently in this post and many others.

        Try to understand that our goal is not to assault anyone personally or discourage SCN members from sharing, but our common goal is to ensure that information that people receive on SCN is not misleading. A lot of damage can be done with "tricks" like that (e.g. the IDoc report mentioned could also be very dangerous) and we all need to be cognizant of the effects of what we post here.

        Thank you.

        • Jelena,

          Many thanks for taking time to reply. I appreciate your effort too.

          It is the language and not the technical content of Suhas's message that I had a issue with. It surely is discouraging. Same message could have been communicated in a much more polite way and that was my point. The intent in the language sounded to me (and I am sure to a few others) like Suhas was trying to prove something than provide a genuine feedback.

          Please read Suhas's message again as if it was written to you and see how it sounds.

          As far as SCN sharing is concerned, people are free to share their observations if they think it might help others. It is the role of experienced members like yourself to politely correct the author if you do not agree.

          Now about SCN rules... as far as I am aware, nowhere in SCN's rules it states that same topic cannot be discussed if it is already covered in a different post. So I don't get why you got upset if someone wants to discuss FAE.

          As far as Sanyam's post is concerned, he has sighted his own observation (some of which I do not agree with) and I think he has the right to do so. If you think otherwise, then I think SCN will need moderators who will approve each and every post which will make it a very dull place.

          At least Sanyam's post wasn't discussing Food at TechEd Vegas?!

          In the interest of not hijacking this thread to discuss personal difference of opinion, please feel free to drop me a line at <removed by moderator> if you have more to share and I promise a reply.




          • It is against the RoE to post your email address here. If you want someone to be able to contact you privately, then you should maintain and email address in your profile.

            As a moderator of this section of the site, I will remove any content that suggests that FAE is better than Inner Joins. In the vast majority of cases it has been proven that Inner joins are more efficient than FAE, and should be the construct of first choice.

            This is not in the RoE, but it is part of the operating rules of this space, as determined by the moderators and as agreed by the community (we even had a poll about it). Not everything that is acceptable/unacceptable is covered by the RoE. Moderators are permitted wide discretion.

          • Apologies Matthew. I agree I should not have put my email address in there. Thanks for removing it for me.

            As far as FAE discussion is concerned, I agree with your technical analysis and never supported author's view.

          • Jayesh, you might be confusing discussions and blogs. Perhaps this document will clarify the difference. Also searching before posting and not opening the same discussions over and over again is actually one of the main rules in ROE.

            Actually we've already had an earily similar conversation on SCN and I really don't have much to add to this blog by Otto Gold.

            I'm not sure what my old question (which was posted as a discussion, by the way) has to do with this, although making such personal remark publicly and then quickly suggesting to take the conversation offline is, sadly, the level of maturity we see on SCN lately...

  • My performance tip is not not use FOR ALL ENTRIES.

    99% of the time an INNER JOIN will be more efficient. This is even more so in a HANA environment.

    FAE is old and inefficient - it belongs to the same era as using tables with header lines.

        • Well,

          Actually, it doesn't.

          You wrote: "My performance tip is not not use FOR ALL ENTRIES. ... FAE is old and inefficient - it belongs to the same era as using tables with header lines".

          However, there are many cases in which Inner join isn't feasible at all (regardless any performance comparison).

          As I understand, "99% of the time an INNER JOIN will be more efficient." talks only about performance issues.

          • There are not many cases where it isn't feasible - there are only a handful. I've been developing since before INNER JOIN was invented, so I've a fair amount of experience on this subject. 🙂

            Hence - performance aside, the tip is: don't use FAE, use INNER JOIN. FAE is old technology, requires check that the reference table isn't empty, and generally results in more complex code.

          • Could you provide a link to the documentation or other evidence for this? I've heard that "5 table rule" applies to MS SQL database, but this might as well be an urban legend. Purely from the practical standpoint very large JOINs could be difficult to troubleshoot, but as far as actual technical limitation - I have yet to see any "proof link".

          • Quite. Does this "rule" apply to HANA? Oracle? DB2?  Well, it seems no it doesn't. You can have as many as you like (subject to resource availability).

            I've joined more tables than 5 without any problems whatsoever.

          • I'm sorry, because I do not know if this is valid for SAP Hana, also found no official documentation SAP confirming this information. But we must be very careful with the use of JOIN dtabs because depending on JOIN, redundant data, can they be returned, and depending on the volume of data that ends up having a cost of RAM at runtime (TSV_TNEW_PAGE_ALLOC_FAILED). (Translation: Google Translate)

          • /
          • Hi,

            There is no rule about using JOIN. But it is important to analyze the situation and find the most efficient solution. It is up to the developer to define the best solution. But we can not forget that it depends on the environment (SGBD, Server, etc).

            (Translate by Google Translate).

          • Hi,

            I saw this information in an article, but could not find it. I will look and post here. I did not find this information in any official SAP documentation. However, the performance of JOINS, dependende much of the SGBD. This information we can see in the official SAP documentation "TAW10_2". Follows the print: (translation by Google Transalate)./wp-content/uploads/2014/03/print_409792.png

          • But this only says "use a field list" when you do a join. Select * with mkpf and mara and marc and mard is of course going to return a lot of data. The point being made is that with a join, you are getting ever more fields with each table and so you can greatly increase data volumes. But this is true of using * with a single table, and if your WHERE clause if badly constructed. It's not an issue with joins, per se.

  • Regarding user exits - not sure where "traditional approach" comes from, but I just use Google and 100% of the time find all the BADIs, user exits, enhancements, etc. if they're at all available together with the code samples, known issues and tons of other information. I doubt SAP is coming up with the user exits faster than they're shared on SCN. 🙂