Category > Articles
Supported by
Supported by Inetum

Automating the ALV field catalogue

images/thumbnail.jpg - Thumbnail
Sometimes I ask myself what percentage of the world’s ABAP code is unnecessary. A paradigmatic example of how time can be wasted writing code which is of no use to anyone and only creates problems is the ALV’s all-too-common field description definition sitting directly in ABAP.

The *_SINGLE_READ functions

images/thumbnail.jpg - Thumbnail
When you need to derive a single record from a database table, you normally use SELECT SINGLE, which is like this in its most basic form, as everyone knows: SELECT SINGLE * FROM KNA1 WHERE KUNNR = '1234567890'. Of course, if you are interested in just a few fields, ideally you select them explicitly to avoid copying unnecessary data from one side to the other: DATA: lv_name1 TYPE name1. SELECT SINGLE name1 INTO lv_name1 FROM KNA1 WHERE KUNNR = '1234567890'.

LOOP ASSIGNING instead of LOOP INTO

images/thumbnail.jpg - Thumbnail
In the beginning there was INTO. Actually, in the beginning it was not even INTO.

On your marks, get set, go!

images/thumbnail.jpg - Thumbnail
Ladies and gentlemen, boys and girls, the race is about to begin. Introduction The four competitors are as follows. They are 4 internal tables, of different races and creeds, which will fight for the athletics title of speed LOOP. Here they are: Competitor 1: DATA: LT_ITEM TYPE TABLE Competitor 2: DATA: LT_ITEM_HASHED TYPE HASHED TABLE Competitor 3: DATA: LT_ITEM_SORTED TYPE SORTED TABLE Competitor 4: DATA: LT_ITEM TYPE TABLE + INTO INDEX

<!--:pt-->Como encavalitar tabelas<!--:-->

images/thumbnail.jpg - Thumbnail
À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).

<!--:pt-->SELECT com mais olhos que barriga<!--:-->

images/thumbnail.jpg - Thumbnail
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.

<!--:pt-->Import/Export = Contrabando<!--:-->

images/thumbnail.jpg - Thumbnail
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&hellip; 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.

<!--:pt-->Procurar uma BADI no palheiro<!--:-->

images/thumbnail.jpg - Thumbnail
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.

<!--:pt-->Evernote - No anotar é que está o ganho<!--:-->

images/thumbnail.jpg - Thumbnail
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.

<!--:pt-->O maravilhoso mundo do Application Log<!--:-->


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.

<!--:pt-->Macros - Velocidade de ponta<!--:-->


Normalmente quando há um pedaço de código que pretendemos reutilizar várias vezes, transformamo-lo numa sub-rotina que pode depois ser invocada repetidamente. Embora a SAP não saiba estruturar o seu próprio código, ainda assim, o ABAP, coitadinho, permite-o. E até disponibiliza várias alternativas para modularizar o código. Eu conto quatro alternativas que listo aqui, da mais rígida para a mais flácida: METHOD, FUNCTION, FORM, DEFINE. Se os 3 primeiros são já familiar de todos, o último - DEFINE - quase ninguém usa. O DEFINE permite definir macros em ABAP. E o que são macros? São sub-rotinas aparentes. Aparentes porquê?

<!--:pt-->Constantes inconstantes<!--:-->


As constantes não o são. Toda a gente sabe. Quando se define uma constante, é certo como a morte que mais cedo ou mais tarde alguém vem e muda-a. Quando isto acontece, quem usa os valores directamente no código ABAP está feito ao bife; Quem define constantes no código só tem de alterar o valor num sítio mas vê-se ainda assim obrigado a editar o programa e a transportá-lo, coisa que, dependendo do grau de burocracia do ambiente em que se está, se pode revelar complicada. Este artigo apresenta uma solução simples mas sofisticada para gerir de forma centralizada todas as constantes de um sistema SAP através do uso de uma tabela de utilizador central onde se manterá todos os valores constantes e de uma classe com alguns métodos estáticos que serão usados para os obter.

<!--:pt-->Melhorar os melhoramentos<!--:-->


No princípio era o INCLUDE. Depois vieram os CMODs, Seguiram-se logo as BADIs, Agora são os Enhancements. E no entanto, o caos continua. Crítica Na maior parte dos projectos SAP em que já trabalhei, a metodologia de utilização de todas estas modificações é a tudo-ao-molho-e-fé-em-SAP e é normal encontrar num único include - como o MV45AFZZ - extensões de código tão grandes que, se o SAP fosse a princesa Rapunzel, dava para lhe fazer umas tranças até cá abaixo para o príncipe subir à sua torre. Este código normalmente implementa várias funcionalidades diferentes e independentes que, ao longo do tempo, se vão emaranhando quase irreversivelmente umas nas outras (tipo trança mesmo). Como consequência, qualquer alteração ao código existente requer cuidados redobrados e é sempre vista como um risco para o funcionamento de tudo o que lá está. Venho aqui propor uma solução simples e eficaz para este problema.

<!--:pt-->Change pointers<!--:-->


Neste artigo tento explicar o que são change pointers e revelar como são úteis e fáceis de usar. O que é um change pointer Um change pointer é um mecanismo de registo de alteração de dados baseado em change documents desenvolvido pela SAP especialmente para ALE. Permite saber, de forma simples e eficiente, quais os registos alterados em uma ou nas várias tabelas por ele monitorizadas. Os change pointers são utilizados maioritariamente como gatilhos para a criação de IDOCs. Mas não devem ser vistos apenas como tal e espero que este artigo traga alguma luz a este mecanismo tão útil mas tão descurado no SAP.