Skip to Content

Usually, as we start ABAPping, we don’t bother to mention the different events in report programming. But, as we get experienced, we learn the importance of mentioning the event names explicitly at the correct places.

About a decade ago, based on a standard SAP report, a custom report was created by replicating the standard one and customizing it based on the user’s requirements. This development was a part of the in-house implementation of SAP, done by the customer. The program was tested successful and sent to production.

A few years back, the customer found it economical to outsource its SAP Application support & this is where we stepped in. As the customer’s database grew larger in these years, the custom reports developed during the implementation phase were starting to slow down with respect to performance.

This is when we took up the task of going through each & every custom report which handled large volumes of data to check for areas of performance improvement.

Most of the reports had the same old story; the use of loop inside loops, use of SELECT-ENDSELECT, improper use of table index, etc.

But one report caught our attention as its performance was already modified to remove the usual performance speed breakers.

The problem was that when the user executed the program in foreground, the program used to give a time out error as the data fetched by the report was too large.

So, the obvious suggestion was to execute the program in background mode to avoid the time out error. But, to our surprise, when the user chose the option of “Execute in Background” from the transaction, the program gave a time out error even before asking for the printer name, which, it normally does.

On multiple code walkthroughs & debugging sessions, the tiny bug finally came into the limelight.

The report had an Initialization event, where the various variables, workareas, etc were initialized; an At Selection Screen Output event for the screen dynamics; End of Selection to display the data fetched in the report using ALV grid.

I’m sure you must have guessed by now what the problem was. So, I thought of writing this blog, so that such blunders can be avoided, which, just waste our efforts in locating the bug.

Yes! The problem was that the event Start of Selection (START-OF-SELECTION) was missing in the program. So, the code written for fetching the data was all considered in the event “At Selection Screen Output”. So, whenever the user chose the option of executing the program in background from the transaction, the program used to perform the fetching of data along with the actually intended code written for the At Selection Screen event, before displaying the usual popup for background execution.

This was a lesson learnt, that one miss of an event name in the program, and it can cause such drastic behavior of the functionality.

The long term action taken after this? Our code review checklist now also has a bullet point mentioning the check for the prudent use of events.

To report this post you need to login first.

1 Comment

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

  1. Uwe Schieferstein
    Hello Dawood

    About a decade ago I started my SAP career at “Cirrus Consulting AG” (http://www.cirrus-group.com) as ABAP developer. Already at that time they had used ABAP templates for quite some time. One of them was a “Report” template which allowed you to select all events required for you specific report. If I remember correctly then START-OF-SELECTION was an obligatory event which always showed up in the reports.

    Even nowadays I frequently stumble over ABAP coding to be classified as “worse” or even “worst”. Fortunately the customer become more and more smart and will sort out such programmers.

    Regards
      Uwe

    (0) 

Leave a Reply