Estás a fazer um LOOP AT a uma tabela com 1000 linhas e sabes que a linha que te interessa é a 853. Até há pouco tempo tinhas duas hipóteses: ou carregavas 852 vezes na tecla F8, arriscando-te a carregar 853 e teres de começar tudo de novo ou então criavas um watchpoint com a condição SY-TABIX = 852 ou lá perto e rezavas para que funcionasse.
Agora tens uma terceira alternativa.
Todo os funcional, até o mais funcional dos funcionais, sabe que para começar a depurar (vá, a fazer debug a) um programa ABAP se usa o comando /H. Mas raro será o programador, mesmo o mais programador dos programadores, que saberá para que serve o comando /HS.
Baixa a música. Fecha a porta. Olha à volta. Está alguém a olhar para ti? Não estás a ser observado? Nem câmaras de vigilância? Então, podemos continuar.
“Ó tempo volta para trás Dá-me tudo o que eu perdi Tem pena e dá-me a vida A vida que eu já vivi Ò tempo volta p’ra trás Mata as minhas esperanças vãs Vê que até o próprio sol Volta todas as manhãs” - António Mourão
Ó Tony, é para já. Vou mostrar-te como podes voltar atrás no tempo.
Imagina que estás a fazer debug de uma transacção e entras numa função e encontras algo interessante. Tão interessante que tens de lhe fazer debug várias vezes. A via convencional é tornar a iniciar o debug da transacção desde o início. Que seca.
Mas há uma via mais directa. Quando estás a fazer debug de uma função podes, directamente a partir do debugger, criar dados de teste para essa função com os valores com que a função tiver sido chamada nessa instância. É assim:
Há determinados momentos em que não é possível fazer /H para iniciar o debugger. O caso mais comum é durante uma janela de diálogo modal (aquilo que os estrangeiros chamam de popup ). Mas há uma forma simples, ainda que rocambolesca, para o conseguires:
Claro que já conheces a transacção SE30 (Análise de tempo de execução) e claro que a usas amiúde para analisar programas standard e descobrir nele tabelas, funções, BADIs e quejandos. Ora se fores como eu, manténs uma relação de amor-ódio com esta transacção: se por um lado a amas por graças a ela consegues ver as entranhas de um programa sem ter de fazer debug, por outro lado odeia-la porque normalmente a lista de entranhas costuma ter milhares de linhas e tornar-se ingerível.
Desde pequenino que uso a transacção SE30 para duas coisas diferentes: Analisar um programa que desconheço (normalmente standard) para saber que funções usa, que BADIs disponibiliza, etc; Analisar um programa meu em busca de problemas de performance. A verdade, nua e crua, é que a transacção SE30 é uma porcaria pegada. Extremamente limitada e inflexível, não dá jeito nenhum para qualquer análise mais complexa.
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.