Quem lê o Abapinho sabe que eu defendo o uso e abuso do ABAP Package Concept. Hoje em dia a primeira coisa que eu faço quando começo um desenvolvimento novo é criar-lhe um pacote encapsulado que guardará todos os seus objectos que, nos casos mais complexos, será um pacote “Main” ainda subdividido em vários sub-pacotes.

Fica aqui a minha modesta proposta para criar uma árvore de pacotes Z que ajude a organizar aquilo que é normalmente uma confusão danada.

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.

Se tu que estás a ler isto achares que tudo o que está escrito no Abapinho é literalmente verdade, o que te vou dizer a seguir vai desiludir: quando disse mágico não quis dizer que era sobrenatural. É só uma forma mais abrilhantada de dizer que é surpreendente e inesperado. Tomei esta liberdade um bocado como quando dizes estou morto de sede e no entanto ainda estás vivo. Tendo clarificado isto, podemos continuar.

O SAP está replecto de recantos refundidos e rebuscados raramente reconhecidos que o Abapinho se regozija por revelar.

O comando %pc é equivalente à opção de menu Sistema/Lista/Gravar/File local:

O sistema do cliente onde trabalho actualmente foi finalmente actualizado para o 7.50 e, depois de tantos anos preso ao ABAP convencional, posso desfrutar as maravilhas introduzidas no 7.40.

São às dúzias essas maravilhas, e não vou começar aqui a fazer artigos sobre cada uma porque já existem artigos espalhados pela net sobre quase todas elas o Abapinho faz sempre o possível por ensinar algo novo ou, pelo menos, pouco conhecido.

Mas há uma singela funcionalidade que, não sendo nada de extraordinário, me agrada: já não é preciso fazer IS INITIAL no comando IF quando a condição é um método que retorna um booleano.

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.

Já todos usámos enhancements implícitos para adicionar código ao início ou final de funções, forms ou métodos standard. Mas é menos conhecido o facto de que também podemos adicionar campos a estruturas de dados, estejam elas declaradas como TYPES ou ou directamente como DATA.

No outro dia estava a aprender sobre ST (Simple Transformations) e lembrei-me que, ainda que tenha sido desenvolvida para transformar dados, é uma forma práctica de guardar dados XML.

Temos o seguinte XML:

  <cocktails>
    <cocktail id=&quot;gt&quot; nome=&quot;Gin Tonic&quot;/>
    <cocktail id=&quot;ws&quot; nome=&quot;Whiskey Sour&quot;/>
    <cocktail id=&quot;cl&quot; nome=&quot;Campari Laranja&quot;/>
  </cocktails>

É frequente ao programar começar a sentir um cheiro desagradável. Normalmente não consigo logo identificar o que é. Sinto apenas uma leve mas incómoda fragrância. À medida que vou cheirando com mais propósito vou conseguindo perceber de onde vem. Mas mesmo nessa altura, muitas vezes ainda não me é perfeitamente claro porque é que aquele cheiro dali vem.

Desde 1998 que oiço colegas ABAPers dizerem que não vale a pena meter determinado código numa função ou método porque não lhes parece que este vá tornar a ser reutilizado. E lá vão continuando na SE38 a fazer os seus reports cheios de includes.

A ideia de que a principal razão para encapsular código é poder reutilizá-lo é um dos maiores mal entendidos da história do nosso planeta.