"
Etiqueta > debug
Apoiado por

Ó Tempo Volta Para Trás

“Ó 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.

Ler o resto do artigo! »

Cria variantes de teste em funções a partir do debugger

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:

Ler o resto do artigo! »

Debug em janelas de diálogo modais

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:

Ler o resto do artigo! »

Análises parciais na SE30

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.

Mas eu já não sou como eu porque, desde que descobri que a SE30 permite fazer análises parciais, a minha relação com ela passou a ser de puro amor. E a partir de agora também tu poderás amá-la na sua totalidade porque vou ensinar-te este segredo.

  1. Transacção SE30;
  2. No bloco “Restrições de medição” cria uma variante com um nome qualquer diferente do DEFAULT;
  3. Na variante activa o pisco “Unidades determinadas”;
  4. Insere a transacção ou programa ou módulo de função a analisar;
  5. Carrega em “Executar” (normalmente agora a análise começaria mas, como escolhemos “unidades determinadas”, começa desligada e é preciso ligá-la explicitamente);
  6. Navega dentro do programa que estás a analisar até chegares ao ponto que queres analisar;
  7. Activa a análise escrevendo /ron lá em cima no campo de comandos;
  8. Faz o que tens a fazer;
  9. Desactiva a análise escrevendo lá em cima /roff;
  10. Sai do programa, voltando ao ecrã da SE30.

Acabaste de fazer uma análise parcial que, em vez dos típicos milhares de linhas, tem apenas as dezenas ou centenas de linhas que ocorreram entre os comandos /ron e /roff. Mais útil, não?

Aproveita o balanço e explora as outras possibilidades disponibilizadas pelas variantes de “restrição de medição”.

Obrigado a Michael Opoczynski pelo ensinamento.

E obrigado a * Cati Kaoe * pela foto.

O Abapinho saúda-vos.

SAT – A nova ferramenta de análise de execução

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.

Aparentemente os senhores da SAP concordam e resolveram substitui-la pela fantástica nova ferramenta SAT – ABAP Runtime Analysis, em tudo mais sofisticada. Pode ser acedida, como seria de esperar, através da transacção SAT.

Se ainda não existir no teu sistema, terás de esperar por um upgrade. Se já existir, boas investigações.

Aqui está um conjunto de screencasts da SAP a ensinar a usar a nova SAT.

O Abapinho saúda-vos.

Depuração telepática

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.

Uma alternativa muito mais comodista é a seguinte:

  • Ir à transacção SE38;
  • Menu Utilitários -> Opções;
  • Escolher separadores “Editor ABAP” -> “Depuração”;
  • No caixa “Depuração externa” introduzir o código de utilizador de quem se quer bisbilhotar;
  • Criar breakpoints de sistema (não de sessão) no programa a depurar;

Agora é só dizer ao utilizador (ou utilizadora) para desatar a correr o programa lá longe no seu computador. No momento em que, na sessão alheia, for atingido um breakpoint, aparece no ecrã do programador (ou programadora) uma janela de debugger ligada a essa sessão alheia. E já está.

O Abapinho saúda-vos.

Procurar uma BADI no palheiro

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.

Ler o resto do artigo! »


Acerca do Abapinho
O Abapinho é suportado pelo WordPress
Artigos (RSS) e Comentários (RSS).