O que podemos fazer quando as noites não são suficientes para os processamentos diários?

Historicamente os programas ABAP tendem a ser muito loooongos. Todas as boas prácticas de programação ensinam que não há uma única vantagem nisso. Se uma rotina, seja ela um programa, um método, uma função ou outra coisa, tiver mais do que 200-300 linhas, desconfia e considera seriamente modularizá-la em várias sub-rotinas. Esta abordagem tem a vantagem adicional de potenciar a reutilização de código. Mas a maior vantagem é o encapsulamento, isolando variáveis no seu contexto local, em vez de as ter todas juntas, tendo como resultado código mais seguro e mais claro. O livro Official ABAP Programming Guidelines aconselha istos no capítulo 2.2 KISS (páginsa 32-34). https://help.sap.com/abapdocu_731/en/abenencapsulation_guidl.htm

Se o mesmo pedaço de código estiver repetido mais do que uma vez, pergunta-te porquê e tenta evitá-lo, criando uma rotina reutilizável. Se, num programa, existir mais do que um SELECT para a mesma tabela, tenta fundi-los num único. Por vezes a utilização inteligente de RANGES para unificar parâmetros pode evitar a necessidade de múltiplos SELECTs a uma mesma tabela. Se o mesmo código for usado em dois programas diferentes tenta, ao invés, mover esse código para uma classe que possa ser partilhada pelos dois. https://abapinho.com/2012/06/mais-ranges-menos-selects/

Quanto mais variáveis globais existirem num programa, mais obscuro ele se tornará. Evita-as. Esta é uma das regras mais básicas da boa programação e deve ser seguida o mais possível. Mesmo se muitas variáveis tiverem de ser passadas entre rotinas. O esforço é um pouco maior, mas daí resultará código muito mais claro e seguro. Excepções podem ser feitas no caso de relatórios muito simples que revolvam à volta de uma única tabela interna, tabela esta que poderá ser declarada globalmente sem comprometer a clareza do código.

Há muito tempo atrás dizias “porreiro pá”. Depois começaste a dizer “baril”. Depois era “fixe”. Hoje dizes “altamente”. É importante não te baralhares para não dares mau aspecto.

E como perguntas a uma tabela interna se a linha existe?

Há módulos de função standard que lançam mensagens e não deviam. Não deviam porque depois queremos usá-las em programas não interactivos e, em vez de devolverem o erro, atiram com uma mensagem para o ecrã que dá cabo do processo.

Mas, provavelmente por ter tomado consciência deste problema, a SAP disponibilizou uma forma elegante (mas muito mal documentada) de resolver o problema.

A SAP não sabe fazer as coisas bem à primeira. As WebDynpros são um bom exemplo disso. Aquilo nem sequer permite pesquisar texto. É triste.

Felizmente o Sérgio Fraga descobriu uma forma, ainda que rebuscada:

Tenho 6 anos!

(Obrigado Caleb Prichard pela foto)

É comum encontrar as estruturas de dados das ALVs declaradas explicitamente no código. Quando isto é feito, o catálogo de campos tem de ser criado manualmente. Se em vez disso se usar uma estrutura pré-definida (do DDIC ou como TYPE), o catálogo de campos pode ser criado automaticamente. Esta abordagem é sempre melhor resultando em menos código, mesmo que o catálogo de campos tenha de ser reajustado aqui e ali. https://abapinho.com/en/2011/12/automatizar-catalogo-alv/

Muitas vezes fazes READ TABLE itbl ou LOOP AT itbl apenas para verificar se um registo existe (CHECK SY-SUBRC = 0). Ora para isso, os dados do registo não são realmente necessários. Nestes casos usa sempre TRANSPORTING NO FIELDS. Assim evitas ter de declarar uma estrutura destino e o programa fica mais rápido porque não tem de perder tempo a copiar dados.