Official ABAP Programming Guidelines (page 34): [Quando um bloco de processamento clássico for necessário], deves imediatamente delegar a execução para um método apropriado (ver a regra 6.37, Não implementes código dentro de Módulos de Função nem dentro de Subrotinas, e a regra 6.44, Não implementes código dentro de Módulos de Diálogo nem de Blocos de Evento).

Pequeno truque para acelerar a introdução de (alguns) dados.

Deverás implementar todos os novos desenvolvimentos usando ABAP Objects excepto quando isso se reveler impossível (RFC, IN UPDATE TASK, ecrãs, etc). Quando tiverem de ser alterados, deverás também tentar converter em OO os desenvolvimentos existentes, se isso se mostrar realista. Official ABAP Programming Guidelines (página 32) regra 3.1: Usa ABAP Objects sempre que possível para desenvolvimentos novos ou existentes. Blocos de processamento clássicos podem ser criados só em casos excepcionais.

Aqui está uma forma simples de programaticamente ter acesso aos textos de um programa qualquer. DATA: t_textos TYPE TABLE OF textpool. READ TEXTPOOL sy-repid INTO t_textos LANGUAGE sy-langu STATE 'A’. Agora tens os textos todos disponíveis na tabela interna T_TEXTOS. Como se isto não bastasse, podes também alterar os textos programaticamente. Com os seguintes comandos: INSERT TEXTPOOL sy-repid FROM t_textos LANGUAGE sy-langu. DELETE TEXTPOOL PROGRAM LANGUAGE 'E’. A SAP diz que estes dois últimos comandos são só para uso interno.

Provavelmente por razões históricas, os programadores ABAP não exploram as possibilidades do SQL. Muitos há que em vez de usarem INNER JOINs, ainda julgam que é mais rápido fazer vários SELECTs para tabelas internas e depois trabalhar os dados em ABAP. Mas a verdade é que, mesmo que se haja excepções, a regra é: quanto menos acessos à base de dados, melhor a performance. E faz sentido porque, afinal, porque foram escritas explicitamente para isso, as bases de dados relacionais são muito mais peritas em processar dados relacionais do que um programa ABAP. Mas claro que há coisas que, pela sua complexidade, não podem ser feitas com um simples INNER JOIN. Ainda assim, algumas dessas coisas podem ser feitas num único SELECT.

Aqui está uma funçãozinha fixe para obter alguns detalhes de um sistema remoto acessível por RFC: RFC_SYSTEM_INFO Não posso dar aqui nenhum exemplo porque estaria a revelar informação segreda importantíssima sobre o meu cliente que depois seria certamente utilizada pelos maus para fazerem espionagem industrial. Mas é fácil de testar na SE37. Obrigado kingofthebigmacs pela foto. O Abapinho saúda-vos.

Se em debug consultares a variável de sistema UNAME dentro de uma chamada RFC podes achar estranho encontrar um utilizador que não o teu. O que acontece é que o sistema adopta um utilizador específico a chamadas remotas e uma nova sessão é iniciada. Uma nova sessão implica um novo contexto de execução e, consequentemente, todos os nossos breakpoints , já estrategicamente colocados, não serão reconhecidos. Este problema pode dificultar um debug simples obrigando-nos a percorrer o código à procura DAQUELA chamada remota ÀQUELE sistema em particular. A SAP tem a solução.

Há inúmeras funções standard para fazer cálculos com datas. São muitas, são demais, são redundantes e, em muitos casos, são obscuras ou impossíveis de compreender. Andava há que tempos para fazer um artigo aqui com uma lista das mais úteis. Mas agora já não é preciso.

Toma lá uma forma simples de começares a fazer debug a um job: Vai à transacção SM37; Clica no job a que queres fazer debug; escreve JDBG na linha de comando (sem /) e carrega em ENTER; e… zás! estás a fazer debug ao job. Obrigado Ricardo Monteiro pela dica. E obrigado Ingolf pela foto. O Abapinho saúda-vos.

Há uns meses atrás mostrei como transformar o debugger numa máquina do tempo. Hoje a dica é singela mas escorreita: há um atalho de teclado para tornar ainda mais simples este viajar enviesado: shift + F12 Pões o cursor na linha para onde queres viajar e depois… shift+F12. Obrigado Maxsuel Maia pela dica. O Abapinho saúda-vos.

E pronto, se leste o título, a dica está dada. Agora umas dicas sobre a dica:

Olá, chamo-me Abapinho e tenho 5 anos. Ainda estou em crescimento. Obrigado a todos os que me visitaram na minha curta vida e um obrigado especial àqueles que me enviaram dicas e ideias e em particular aos que já colaboraram com artigos. Eu, Abapinho, saúdo-vos.

Ao longo dos últimos tempos compilei um conjunto de boas prácticas que fui adoptando para mim próprio. Resolvi partilhá-las aqui, criando para isso uma nova categoria (que aparecerá em breve no menu à esquerda) sob a qual serão agrupadas. A ideia original era fazer um PDF mas, como elas estão em constante revisão e ampliação, tornava-se pouco práctico. Como tal, serão publicadas uma a uma. O objectivo é que estas possam ser vistas no seu conjunto como uma referência acessível de fácil consulta.

Em SAP, quando um desenvolvimento está concluído, chega finalmente o momento de o enviar para outros sistemas onde pode ser devidamente testado e por fim executado pelos utilizadores. Mas antes disso, é crucial verificar se não existem lapsos, erros e afins que possam levar ao aparecimento de alguns comportamentos imprevisíveis por parte dos nossos programas. Existe uma ferramenta muito útil que permite filtrar alguns desses erros e lacunas. Chama-se ABAP Code Inspector.

Quantas vezes te aconteceu ficar com uma janela “pendurada” quando terminas um debug?