Hoje em dia quando quero criar uma SALV defino sempre a estrutura dos dados no DDIC já com os elementos de dados com as descrições desejadas em vez de os forçar no código.

O editor de ABAP tem sempre coisas novas para descobrir.

Quando faço CTRL-F para pesquisar texto a opção que costumo usar é a Continuar proc.

Toda a minha vida ABAPiana usei APPEND STRUCTURES para adicionar campos extra a tabelas standard.

Mas aprendi recentemente que afinal servem para mais duas coisas:

Sabes que há uns anos atrás fizeste um método qualquer cujo nome tinha a palavra MALMEQUER. Mas, e agora? Como é que o encontras? Poderias usar a transacção SE24 para pesquisar uma a uma todas as classes alteradas por ti. Mas eras capaz de demorar algum tempo. Não faças isso. Experimenta antes usar a transacção SE84:

Imagina que queres chamar um método mas não sabem quais os seus parâmetros. O que fazes?

Dantes tinhas de usar o pattern ou então abrir a classe numa janela ao lado para ver os parametros do método. Depois apareceu o auto-complete e tornou tudo mais simples.

Mas há ainda outra forma.

Quando quero procurar uma determinada palavra num programa ABAP normalmente uso a função de pesquisa carregando em CTRL-F. E depois vou carregando em NEXT para ir encontrando as várias ocorrências da palavra que procuro.

Mas há outra forma. E não é melhor nem pior. É simplesmente diferente: a pesquisa incremental.

Quando um método devolve um valor como RETURNING este é sempre passado por valor e não por referência. Muitas vezes faço métodos que devolvem tabelas internas, algumas bastante grandes. Mas sempre me preocupou a ideia de que, como está a ser devolvida por valor, o ABAP devolva uma cópia da tabela interna, algo que pode ter impacto na performance e na memória que o programa gasta.

Felizmente fiquei recentemente a saber que não é assim.

Quando tentas inserir um registo numa tabela que já tenha outro registo com a mesma chave primária o programa faz dump. O que em alguns casos é uma chatice porque, mesmo que te estejas nas tintas, te obriga a verificar antecipadamente se aqueles chaves já existem na tabela. Mas o ABAP prevê esses casos e dá-te uma solução: INSERT dbtab FROM TABLE itab [ACCEPTING DUPLICATE KEYS]. Não te preocupes que quando acrescentas o ACCEPTING DUPLICATE KEYS não violas a primeira lei da termodinâmica: os registos não são inseridos.

Às vezes as coisas estão mesmo debaixo do nosso nariz e não as vimos.

No meu cliente actual trabalho com um montes de sistemas diferentes. Quando altero a configuração num deles muitas vezes, por preguiça ou esquecimento, acabo por não o fazer nos restantes.

Mas há uma forma simples de copiar de uma só vez todas as configurações do ABAP Workbench de um sistema para outro.

Por defeito a comparação de versões é horrível. Mostra as duas versões numa única coluna, com as diferenças destacadas, o que resulta numa grande confusão. É a coisa menos práctica de sempre.

Mas não tem de ser assim.

Estava há pouco a fazer QC a um programa que criaram chamado ZSDFAKSPE com quase 1000 linhas e nenhum comentário. Uma óbvia cópia de um programa standard chamado SDFAKSPE.

Decidi então usar o Editor ABAP de tela dividida (Split screen editor) que está na transacção SE39. Introduzi o nome do Z e do standard e depois pude compará-los lado a lado.

Estando habituado a programar em Java e C++, a forma como a SE24 obriga a navegar entre as várias partes de uma classe e o facto de cada método estar isolado no seu próprio include ao início fez-me muita confusão. Mas porque é que a SAP complica sempre tudo? Acabei por habituar-me.

A dado momento a SE24 passou a permitir a opção Basedo em texto fonte que mostra a classe e os métodos todos ligados em texto corrido. Mas por alguma razão que nunca atinei com aquilo.

Imagina que estás a mexer num programa daqueles antigos que têm milhares de linhas (sim porque hoje em dia sabes que não modularizar é errado (pecado mesmo) e os teus métodos (sim porque hoje tu já só usas métodos) nunca passam das 200 linhas).

Quando chamas uma função por RFC tens de lhe dar a RFC DESTINATION do sistema remoto:

CALL FUNCTION ‘ZESPIRREI’
  DESTINATION ’sistema_longe_daqui’.

E se, por alguma razão, precisares que a função que corre no sistema remoto chame uma função no sistema original. Sabes fazê-lo?

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.