Hoje debruçamo-nos sobre como tentar optimizar o código para transformar um SELECT num RANGE.

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.

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="gt" nome="Gin Tonic"/> <cocktail id="ws" nome="Whiskey Sour"/> <cocktail id="cl" nome="Campari Laranja"/> </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.

No mundo do SAP, o código ABAP onde cai é onde fica. Num dia o Manel faz uma coisa mal porque está com pressa ou não sabe fazer melhor. Um ano depois pedem ao António para fazer uma pequena alteração. O António vê a asneira do Manel mas não a melhora porque, por alguma razão, no mundo do SAP, alterar código que está a funcionar, por muito mau que seja, é tabu. Em vez disso, acrescenta o seu código ao já existente de forma geralmente acrítica. Esta atitude, quando adoptada por todos, contribui para uma inevitável erosão do código de um sistema que, após alguns anos, se tornará ingerível. No meu entender, isso está errado e vai contra os interesses do cliente. Aliás, mesmo se o cliente não quiser que se mexa no código antigo… eu mexo. Quem é ele para me dizer como é que se programa?

A transacção SE37 permite testar módulos de função. Por vezes esses módulos de função utilizam tabelas. Pode dar-se o caso de precisarmos de carregar muitas linhas de dados de teste em uma ou mais dessas tabelas. Aqui fica um truque para o conseguir fazer a partir de um ficheiro.

Este artigo é da autoria de José Vília. A ovelha Dolly está no ABAP e eu não sabia. Depois de criar uma instância de uma classe, gostava de partilhá-la com outro programa totalmente independente para que este outro programa posso usá-la como se a tivesse instanciado. Como se de uma fábrica de ovelhas Dollies se tratasse, o ABAP pode utilizar serialização para resolver o problema.

A lei do menor esforço, esse grande axioma da Humanidade, tem, no mundo da programação, a particularidade de, em muitos casos, acabar por ser simplesmente a lei do esforço adiado. Porque é muito provável que algo que tenha sido desenvolvido de acordo com esta lei venha mais tarde a precisar de um grande esforço extra. Seja dos utilizadores que vão utilizar esse algo ou dos programadores que mais tarde terão de o manter. Atire a primeira pedra aquele que não se deixou guiar por esta lei ao desenvolver este ou aquele programas. Eu não atiro.

Prólogo Quando digo que gosto de usar diagramas de classes UML para documentar o meu código as pessoas acham que sou maluco. Introdução O UML ganhou má fama porque as pessoas pensam que primeiro se faz o diagrama de classes todo em UML e só depois o programa. Mas isso era em 1996, quando se achava que a primeira coisa a fazer era o desenho técnico todo, mesmo que na práctica ninguém nunca o fizesse. Hoje em dia felizmente já não temos vergonha de dizer que o próprio acto de programar é já em si uma forma de desenhar.

Todos os dias o ABAP me revela coisas novos. Às vezes coisas que mais valia eu nem saber que existem. Como esta. A tabela T056P tem um campo com uma data. Fazendo um SELECT a esta tabela filtrando pela data não conseguia obter nada de jeito. Mas o código parecia correcto. Na SE16N descobri que o intervalo de datas também não funcionava conforme esperado: só apresentava resultados quando a data final era colocada no LOW e a inicial no HIGH. Bizarro.

O Manelinho criou a transacção ZFB01 associada ao programa ZFB01 que faz lá umas coisas e depois faz CALL TRANSACTION à FB01. A seguir veio o Joãozinho e correu a transacção ZFB01. Conseguiu começar a corrê-la porque tem permissões para a transacção ZFB01. Mas a meio teve um erro porque não tem permissões para a transacção FB01. Tanto o Manelinho como o Joãozinho sabiam que os administradores de sistema nunca na vida deles darão ao Joãozinho autorizações para correr a FB01.

Nos dias que correm se não estás a usar objectos és totó. Se usas objectos, espero que estejas a seguir a boa práctica de usar classes de excepções. E se usas classes de excepção é bom que entendas a melhor forma de as usar, particularmente as vantagens de as encadear. Com tudo isto esclarecido, chegamos ao que nos traz aqui hoje. No artigo sobre cadeias de excepções mostrei como, para obter o texto da excepção mais profunda, a que foi inicialmente espoletada, se pode fazer um DO WHILE:

Tenho usado cada vez mais referências em ABAP. Primeiro usava REF TO só para classes mas vou percebendo cada vez mais as vantagens de as usar também para estruturas de dados. Mas, tal como acontece em C++, há que ter cuidado quando se lida con referências para dados pois facilmente a coisa pode dar para o torto. Neste artigo tento mostrar como usar e como não usar o REF TO data. Comecemos por ver um exemplo de como não usar:

Todos os objectos criados em SAP têm de estar associados a um pacote. Até recentemente, quando eu queria fazer um teste rápido criava o objecto no pacote $TMP. Tinha assim a garantia de este nunca viria a ser transportado. Mas por vezes há necessidade de criar coisas no sistema de desenvolvimento que não pretendemos nunca vir a transportar mas que queremos que lá existam eternamente. Como o ZSAPLINK e o abapGit, por exemplo. Mas se as associarmos todas as pacote $TMP fica uma valente confusão.