WITH HEADER LINE – should you use it anymore?

By | February 2, 2012 | Case Study | 4,194 | 7

We all know that WITH HEADER LINE is obsolete in ABAP Objects. But it you can still use it in procedural programming. I am sure, after reading this you would agree not to use it.

The Problem

At one of the client’s place, we have implemented lot of Interfaces. Inbound IDocs were used widely to implement majority of the interfaces. Inbound interfaces uses the process code to process the business logic. This process code is attached to a Function Module. Generally this FM would be extract Inbound IDOC data, Validate them, Process Business Functions or call BAPI, Populate Status table and Clear Global Variables.

Consultant 1 has implemented the logic and is working as expected with low volumes. When the Volume gets increased, interface started complaining about the performance. Consultant 2 has found that the clearing the global variables is not implemented in the FM. Because of this same data was keep on repeating. Since the business purpose was to only update certain things, it was not actually creating any new transaction documents. So, Consultant 2 has implemented similar to this code:

clearing - version 1

  clear: i_data, i_messages, i_var2.

Real Problem

On one fine day, when the interface went live in the production and the partner system sent all of the business transactions at once, support team noticed exceptional increase in the DB. So, Consultant 3 found out that there are lot of IDOCs created for the interface with thousands of Status messages – totaling to few millions.

After research consultant 3 figured out that the clear statements introduced in the inbound process code FM are incomplete. It revealed that the table I_MESSAGES which is being moved to Status messages of the Inbound IDOC was declared WITH HEADER LINE. Due to this fact, it makes the changes done by Consultant 2 as incomplete. They should be like this. Consultant 2 made changes and had moved to production. Life came to normal!

clearing - final version

  clear: i_data, i_messages, i_var2.
  refresh: i_messages.

Why it was missed as WITH HEADER LINE table was used along with the other tables which are defined by the type. So, those tables were getting cleared with the simple CLEAR statement. Clear on I_MESSAGES was only clearing the header line.

Ripple Effect

Now, the discussion has been started to remove those unwanted status messages as they were occupying space. It was also degrading the performance, as table was huge and taking more time to process each request. It has been decided to archive all those IDOCs. Consultant 3 went ahead and schedule a job to remove all those IDOCs.

As I mentioned earlier, there were huge number of records to be deleted. System suddenly stop creating IDocs while job was running. Due to this problem all of the interfaces stopped working as System has locked the entire Status table. System couldn’t find any more memory to perform the delete operation and it gave. System has started rolling back the changes. This Rollback would was going on and on. It took long long time of about 8 hours to finish. Till this time all the interfaces were stopped, all the jobs were put on hold, system was on its knees.

Too much effect of HEADER LINE!

Lessons Learnt

You can outline these lessons:

  • Don’t use WITH HEADER LINE along with other tables declared by TYPE. If possible, refrain using HEADER LINE.
  • Schedule deletion jobs with smaller chucks with often commit

Have you even faced this type of problems?

Like It? Share!!

Don't miss an Update

Get notified of the new post, right into your inbox

Naimesh Patel{273 articles}

I'm SAP ABAP Consultant for more than a decade. I like to experiment with ABAP especially OO. I have been SDN Top Contributor.
Follow :

Explore all of his 273 articles.

Load comments


  • There are sometimes some difficult pitfalls… :)

  • jeevan

    This is one of the best articles i hav ever read.

  • vivek

    I came across this issue many times where consultants have forgotten to clear internal table or the header ( work areas) resulting in extremely poor performance with larger volumes. as usual , when the program is moved to prodn this folly is caugtht.
    BTW I like all your blogs.
    keep up

  • Yes, absolutely correct. It might be too late sometimes to realize them.

  • Hello Vivek,

    I guess thats reason, we should avoid using the header lines.

    Naimesh Patel

  • Shyam

    I have faced this issue many a time, this is even a part of the “Code Review Checklist”, but the consultants rarely pay enough attention to these “silly looking” issues which become a “mammoth” in the PROD environment.

    Excellent Case Study, I must say !!


  • Hello Shyam,

    Most of the times it is part of the Code Review checklist, but the problem is due to subsequent changes. Sometimes they are urgent and doesn’t go through the process and impose a greater risk, if this type of scenarios occur.

    Naimesh Patel

Comments on this Post are now closed. If you have something important to share, you can always contact me.

You seem to be new here. Subscribe to stay connected.