You are doing a LOOP AT in a 1000-line table, and you know that you want line 853. Until recently, you had two options: either hit F8 852 times, running the risk of hitting it 853 times and having to start all over again, or create a watchpoint with the condition SY-TABIX = 852 or something close, and pray that it worked.

Now you have a third option.

Most functionals, and even the hardcore functionals, knows that in order to start debugging an ABAP program, we use the /H command. But few programmers, even the hardcode programmers, will know the purpose of the /HS command.

Turn down the music. Close the door. Look around. Is anyone looking at you? Are you being watched? Are there any security cameras? If not, we can go on.

“Oh time turn back Give me everything I have lost Take pity and give me the life The life I have already lived Oh time turn backward Kill off my futile hopes Look how even the sun itself Returns every morning” – António Mourão

Hey Tony, right away. I will show you how you can turn back time.

Imagine that you are debugging a transaction, you enter into a function and find something interesting. So interesting that you have to debug it several times. The conventional way is to start the debug of the transaction again from the beginning. How tedious.

But there is a more direct route. When you are debugging a function you can create test data for this function directly from the debugger, using the values with which the function had been called at that time. For instance:

There are times when you can’t do /H to launch debugger. The most common one is when a pop-up window is open. However there is a simple, if Heath-Robinson, way to do it:

Obviously you already know the SE30 transaction (run time analysis) and obviously you use it often to analyse standard programs and to discover tables, functions, BADIs and similar contained within them. But if you are like me, then you have a love-hate relationship with this transaction – on the one hand you love it because it enables you to see the guts of a program without having to debug it, yet on the other hand you hate it because normally the list of guts tends to have thousands of lines and becomes unmanageable.

Since I was small I have been using the SE30 transaction for two different things: To analyze a (normally standard) program I don’t know in order to find out what functions it uses, what BADIs it offers, etc; To analyze a program of mine to search for performance problems. The simple truth is that the SE30 transaction is a total mess. It’s extremely limited and inflexible and it’s useless for any more complex analysis.

Imagine o seguinte cenário: um utilizador (ou utilizadora) está sentado no escritório dele, a correr uma transacção ou não sei o quê. Tem um problema e chama um programador (ou programadora) para o (ou a) ajudar a entender o que se passa. Normalmente o programador (ou programadora) teria de se deslocar lá, à sala do senhor utilizador (ou senhora utilizadora) e das duas uma: fazer debug no computador dele (ou dela) ou aprender como recriar o problema e depois fazer debug no seu computador.

O SAP é um enorme palheiro. E os ABAPers são pessoas que trepam por esse palheiro acima e nele vasculham e escarafuncham em busca de agulhas de todo o género. Às vezes, desesperados, deitam-se a descansar e vêm uma quantidade enorme de bicharocos que vivem no palheiro fazer-lhes comichão. Para evitar que isso aconteça, o Artur Moreira propõe-nos uma série de diferentes técnicas para procurar BADIs neste grande palheiro que é o SAP.