Há várias desculpas para não usar a nova sintaxe funcional do ABAP 7.4. Uma delas é dizer que é impossível fazer debug.

Só que não é.

Não sei há quanto tempo é que isto está disponível mas só agora descobri que é muito fácil ver numa ALV o conteúdo de uma tabela interna durante debug.

Em tempos falámos na SAAB e nas vantagens de a utilizar para melhor conseguir analisar e descobrir problemas no nosso código. Nesse artigo não expliquei uma coisa que é realmente importante: variantes de activação.

Num sistema bem protegido, os utilizadores não têm permissões para debug. Mas muitas vezes isso complica a vida dos ABAPers que, ao quererem resolver um problema desse utilizador, não podem fazer debug à sua sessão.

Mas há uma forma legítima, ainda que pouco óbvia, de contornar o problema.

Embora uma parte substancial do trabalho de um ABAPador seja depurar código, a maior parte dos ABAPadores que eu conheço investem muito pouco em explorar a ferramenta que o permite, o depurador. Talvez por terem passado anos a aturar um depurador arcaico e limitado. Mas o novo pode fazer muito mais do que lhe costuma ser pedido. E o Abapinho vai tentar ensinar como.

Hoje ensina-te apenas uma pequena tecla.

Quando fazes debug usas a tecla F5 para avançar para a próxima instrução (ou entrar para dentro de uma sub-rotina). Mas imagina um IF com várias condições:

IF A = 1 AND B = 2 AND C = 3.
  WRITE 'Gosto da palavra glauco'.
ENDIF.

Ao fazeres debug àquele IF com F5 e alguma das expressões for falsa saltas logo para fora do IF e ficas sem saber qual delas falhou.

Mas o novo debugger tem uma nova funcionalidade muito catita que te pode ajudar a entender melhor o que aconteceu ali.

Checkpoints é uma framework muito poderosa do ABAP que no entanto quase ninguém a usa. Porquê? Provavelmente pela mesma razão que quase ninguém ouve Sun Ra e que quase ninguém sabe que o Frank Zappa tem 102 álbuns. Porque embora seja bom, é obscuro e pouco comercial. Os checkpoints são, de facto bons e pouco comerciais. Mas deviam ser mais como o Mozart, que é bom e comercial.

Hoje temos um convidado, Tamás Holics. Ele é dono da STA Consulting, uma empresa Húngara que criou 2 produtos muito interessantes para SAP. Neste artigo o Tamás apresenta o STA Ticket System.

O Problema

Desperdiça-se muito tempo nos processos de teste e manutenção SAP dado que os relatórios de erros produzidos pelos utilizadores serem muitas vezes incompletos ou incorrectos. A resolução do problema reportado normalmente fica pendente até a informação estar toda completa. Ora como em boa parte dos incidentes reportados a equipa de manutenção (analistas, programadores) tem de pedir mais informação sobre o erro, há uma enorme perda de tempo valioso em iterações desnecessárias, tanto de quem reporta incidentes como de quem lhes dá suporte.

Já estás a meio de um debug e queres que a execução pare numa determinada mensagem.

O que fazer?

Para fazeres debug a um programa que faça parte de um job faz o seguinte:

Imagina que tens um programa a executar um ciclo infinito ou, pelo menos, um ciclo com 70x7 iterações. Nunca mais acaba e tu queres saber o que lá se passa.

No passado tinhas de ir à SM50, seleccionar o processo e escolher no menu “Administração | Programa | Depuração”.

Mas agora há uma forma muito mais simples.

Se em debug consultares a variável de sistema UNAME dentro de uma chamada RFC podes achar estranho encontrar um utilizador que não o teu. O que acontece é que o sistema adopta um utilizador específico a chamadas remotas e uma nova sessão é iniciada. Uma nova sessão implica um novo contexto de execução e, consequentemente, todos os nossos breakpoints , já estrategicamente colocados, não serão reconhecidos.

Este problema pode dificultar um debug simples obrigando-nos a percorrer o código à procura DAQUELA chamada remota ÀQUELE sistema em particular.

A SAP tem a solução.

Toma lá uma forma simples de começares a fazer debug a um job: Vai à transacção SM37; Clica no job a que queres fazer debug; escreve JDBG na linha de comando (sem /) e carrega em ENTER; e… zás! estás a fazer debug ao job. Obrigado Ricardo Monteiro pela dica. E obrigado Ingolf pela foto. O Abapinho saúda-vos.

Há uns meses atrás mostrei como transformar o debugger numa máquina do tempo. Hoje a dica é singela mas escorreita: há um atalho de teclado para tornar ainda mais simples este viajar enviesado: shift + F12 Pões o cursor na linha para onde queres viajar e depois… shift+F12. Obrigado Maxsuel Maia pela dica. O Abapinho saúda-vos.

Quantas vezes te aconteceu ficar com uma janela “pendurada” quando terminas um debug?