Claro que já conheces o botão “Modelo” no editor de ABAP que permite introduzir automaticamente modelos para módulos de função, chamadas a métodos e outros.

Mas o novo editor agora cresceu um bocadinho (já só está 10 anos atrasado em relação ao Eclipse em vez de 20) e já permite completar automaticamente alguns comandos através do atalho CTRL-SPACE.

Se um desenvolvimento necessitar de mais do que uma tabela de parametrização, considera agrupar as tuas vistas de manutenção num “cluster”. Assim será mais intuitivo mantê-las. Isto fará ainda mais sentido se umas dependerem de outras uma vez que na definição do “cluster” estas relações podem ser explicitadas. Exemplo: Como encavalitar tabelas

Tenta seleccionar sempre apenas os campos que vais realmente usar. Escolher todos é um desperdício de recursos. Excepção feita ao uso das FM *_SINGLE_READ que, embora leiam os campos todos, fazem cache dos dados, sendo por isso ainda assim mais rápidos de usar quando usados múltiplas vezes com a mesma chave. Se queres apenas verificar que um registo existe, selecciona apenas um campo, e se possível aquele que estás a usar como critério, evitando assim declarares uma variável extra.

Sempre que achares que um valor que estás a usar num programa pode mudar e não o puderes tornar um parâmetro de entrada ou do ecrã de seleccção, guarda-o numa tabela de constantes (ex: ZCONSTS). Esta tabela nunca deverá ser usada directamente. Em vez disso, cria uma classe ZCL_CONSTS que aceda a ela e usa sempre esta classe para obter as tuas constantes. Como é mostrado neste artigo: Não caias na tentação de usar a T900 ou outras tabelas do género para este propósito.

Quando alteras um objecto e o guardas numa ordem de transporte ele normalmente fica bloqueado. Dentro da ordem de transporte é podes bloquear objectos que não estejam já bloqueados que não estão já bloqueados noutra ordem. Mas, uma vez bloqueados, como é que se desbloqueiam?

Código que seja usado comummente deve estar disponível centralmente, se possível guardado em pacotes bem identificados (ex: ZFERRAMENTAS) para que seja facilmente encontrados e transportados. Há muito código já disponível na Internet que permite executar várias funções comummente necessárias (ex: ABAP2XLSX). Adopta-o; Para as tuas tarefas mais comuns, desenvolve ferramentas que possas reutilizar, juntando-as à biblioteca central; Divulga a biblioteca entre os colegas do teu projecto para evitar que venham a perder tempo a criar código duplicado;

Truquezito catita: quando na SE38 quiseres meter uma palavra ou expressão entre parêntesis ou aspas, basta seleccioná-la e carregar em ( ou [ ou ‘. E imediatamente isto fica (isto) ou [isto] ou ‘isto’. Obrigado Sérgio Fraga pela dica.

Se precisas de adaptar o conteúdo de um ficheiro com valores (CURR) tem sempre em consideração a parametrização do utilizador (USR01-DSCFM). Se precisares de converter um alfa-numérico num número, usa o FM MOVE_CHAR_TO_NUM. Se precisares de converter um número num alfa-numérico, usa WRITE curr TO str [CURRENCY waers].

Uma das únicas situações onde é inevitável é com SELECT-OPTIONS. Em todos os outros casos, declara explicitamente uma variável local com uma estrutura equivalente. Basicamente o comando TABLES cria variáveis globais obscuras que aumentam a ambiguidade do código. E variáveis globais devem ser evitadas na maior parte dos casos.

READ TABLE itbl ASSIGNING é sempre mais rápido que READ TABLE itbl INTO wa. Além disso, quando precisares de alterar dados em registos de uma tabela interna, assim não precisas de usar o comando MODIFY nem da variável auxiliar que às vezes usas para guardar o SY-TABIX. A única situação em que uma variável de estrutura é aconselhada é quando queres adicionar linhas novas a uma tabela interna. Algumas pessoas defendem que as variáveis de estrutura devem ser usadas sempre que não se quiser alterar os dados da tabela interna.

O repositório do R/3 é uma coisa maravilhosa. Um vasto armazém de elementos de dados, estruturas, tabelas e muito mais, prontamente disponíveis a todos. Como programadores, é fácil e conveniente escolher estes objectos e puxa-los para os nossos programas à medida das necessidades sem que a preciosa linha de pensamento seja interrompida. Mas nem tudo é sol e flores. Se não tiveres cuidado com os cogumelos que apanhas podes dar por ti com um envenenado entre mãos.

Às vezes encontras um IMPORT no código mas não fazes ideia onde está o EXPORT correspondente. Quando for necessário comunicar entre programas distintos, isto deverá ser feito através de um par de métodos de uma mesma classe. Assim, quando nos cruzarmos com um, conseguimos facilmente saber qual é o outro. Para implementar esta comunicação, evita utilizar EXPORT/IMPORT sempre que possível. Ao invés, usa um atributo estático da classe.

Estás a contemplar uma classe na SE24, uma tabela na SE11 ou um programa na SE80. Agora queres ver o pacote desse objecto bem como o seu conteúdo. Até há pouco tempo eu faria assim: primeiro via nas características do objecto qual é o seu pacote, depois abria uma sessão nova, ia à SE80 e escrevia lá o pacote.

Agora aprendi uma forma muito mais simples.

Quando precisares de enviar uma mensagem dinâmica por parâmetro, garante que ainda assim usas o comando MESSAGE de forma a que o “where-used” não lhe perca o rasto. Ao fazeres MESSAGE E001 INTO V_DUMMY, os detalhes da mensagem ficam disponível nas variáveis de sistema SY-MSGNO, SY-MSGTY, etc. Além disso, os textos das mensagens nunca devem ficar explicitamente definidos no programa mas sim definidos através da transacção SE91. https://abapinho.com/2009/09/evitar-mensagens-dinamicas/

No outro dia apareceram uma série de coisas espatifadas na nossa máquina de testes. De repente ninguém podia trabalhar na máquina. Na STMS encontrámos uma série de ordens de transporte indevidamente transportadas para lá. O utilizador que aparece associado a cada uma dessas ordens é o dono dela. Mas será que a culpa é dele? Não terá sido outra pessoa a fazer o transporte?

Como saber?