Às vezes pergunto-me qual será, no mundo, a percentagem de código ABAP desnecessário. Um exemplo paradigmático de como se pode desperdiçar tempo a escrever código que não serve para nada e só prejudica é a tão frequente definição das descrições dos campos de uma ALV directamente em ABAP.
Quando se quer obter um único registo de uma tabela da base de dados é costume usar-se o SELECT SINGLE que, como toda a gente sabe, na sua forma mais básica reza assim:
SELECT SINGLE *
FROM KNA1
WHERE KUNNR = '1234567890'.
Senhoras e senhores, meninos e meninas, a corrida está prestes a começar.
Introdução
Apresento-vos as 4 participantes. São 4 tabelas internas, de diferentes raças e credos, que se vão pelejar pelo título atlético do LOOP em velocidade. Aqui estão elas:
Concorrente 1: DATA: LT_ITEM TYPE TABLE
Concorrente 2: DATA: LT_ITEM_HASHED TYPE HASHED TABLE
Concorrente 3: DATA: LT_ITEM_SORTED TYPE SORTED TABLE
Concorrente 4: DATA: LT_ITEM TYPE TABLE + INTO INDEX
Às vezes temos de criar uma tabela Z. Às vezes temos até de criar várias tabelas Z. Às vezes estas tabelas estão relacionadas de alguma forma. Como quando uma contém dados de cabeçalho e a outra dados de item, por exemplo. Ora se estão relacionadas pode dar jeito que sejam editadas em conjunto. É para isso que servem os Clusters de Visão (view cluster).
Embora seja evidente que, ao fazer selecções de dados de uma tabela da base de dados, devemos ter o cuidado de escolher apenas os campos que necessitamos, a verdade é que há muito boa gente que não se dá a esse trabalho e manda vir tudo.
Mediremos aqui a diferença real entre as duas abordagens.
O Java, uma linguagem de programação bem pensada, ajuda o programador a organizar o seu código obrigando-o a desenvolvê-lo de forma estruturada. A sua própria filosofia potencia o pensamento estruturado e promove coerência e arrumação.
Já o ABAP… promove o caos. Está cheio de caminhos perniciosos que levam direitinho a um inferno confuso e labiríntico. E geralmente são as coisas aparentemente mais convenientes que se revelam as mais perigosas.
Uma das conveniências piores é a parelha IMPORT e EXPORT.
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.
Il faut cultiver notre jardin – Voltaire
No SAP fala-se muito de experiência. Fulano tem muita experiência, sicrano tem pouca experiência. Tenta-se com isso medir a capacidade que alguém tem de usar o seu passado para lidar com o seu futuro. Mas nem sempre ter experimentado uma coisa é sinónimo de ganhar experiência com ela. O exemplo paradigmático ao alcance de todos é o amor: quantos desgraçados, por muitas experiências desgraçadas que tenham tido, se continuam a desgraçar-se no amor! O SAP não é o amor. Ainda assim não nos faltarão exemplos de consultores que no CV descrevem muitas experiências e na prática se revelam uns grandes inexperientes.
A Inteligência terá certamente muito peso nessa capacidade de sublimar as experiências, de as conservar, de fazer delas Compota de Experiência. Mas, pelo menos no que toca ao mirabolante mundo do SAP, quem tem também muito a dizer é a senhora Memória. Ou melhor dizendo, a falta dela.
O mundo do SAP é horizontal e vasto. Para onde quer que se olhe é a perder de vista. E embora seja um mundo bastante populado e onde se viaja muito, não houve até hoje, que eu saiba, cartógrafos de jeito. Os mapas que dele se fizeram são parcos, pobres, distorcidos e normalmente ainda o julgam plano quando toda a gente já sabe há muito tempo que ele é curvo.
Há que cartografar o nosso mapa.
Uma boa parte dos reports, interfaces ou jobs, têm de produzir algum tipo de relatório. É normal ver isso feito recorrendo ao comando WRITE. Ora nos dias que correm, usar o comando WRITE para isto é como recorrer a um par de pedras para acender uma fogueira. Afinal, porque não usar o Application Log que é muito mais simples e prático e standard e é só vantagens?
O Application Log é um sistema standard do SAP para guardar logs aplicacionais e é usado por várias transacções standard. Ao utilizá-lo podemos simplificar e uniformizar os logs dos nossos programas. Vamos aprender aqui como é simples usá-lo nos nossos desenvolvimentos.
Acerca do Abapinho
O Abapinho é suportado pelo WordPress
Artigos (RSS)
e Comentários (RSS).
