Tenho usado cada vez mais referências em ABAP. Primeiro usava REF TO só para classes mas agora vou percebendo as vantagens de as usar também para estruturas de dados. Recentemente descobri um comportamento muito lamentável do seguinte comando: INSERT wa INTO itbl REFERENCE INTO ref. Mas antes de me queixar sobre isso, dou um bocado de contexto.

Se, ao construir uma ponte, um engenheiro civil fizer mal as contas a ponte cai. Mas não é só a ponte que cai. Esse engenheiro civil provavelmente também cai. Ou pelo menos desequilibra-se. Porque quando fez o projecto da ponte assinou-o, assumindo responsabilidade pelo que fez. Nós os programadores ABAP não temos esses problemas.

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.

[Artigo por Artur Moreira] A SAP introduziu a partir da versão 7.4 do ABAP o conceito de Code PushDown, que significa utilizar mais a base de dados para cálculos (agregação de dados, somas e vários cálculos prévios).

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.