É com pena que vos digo que não será possível ao Abapinho continuar a publicar também em inglês. Peço desculpa aos leitores que não sabem português. O objectivo principal do Abapinho sempre foi a criação de conteúdos sobre ABAP em português. Mas a possibilidade de publicar também em inglês era uma vantagem pois permitia-nos alcançar um público mais vasto. Pudemos fazê-lo durante vários anos porque as traduções eram patrocinadas. Infelizmente, pelo menos por agora, tal não será mais possível.

Sabias que quando invocas uma função com a opção DESTINATION ‘NONE’ estás a iniciar uma nova LUW? Isto pode parecer apenas uma curiosidade, mas há um caso em que pode fazer toda a diferença: sabes aqueles módulos de função que ao serem chamados uma segunda vez têm um comportamento diferente da primeira vez? Isto acontece porque eles hão-de ter alterado alguma variável global ao grupo de funções. Ora se iniciares uma nova LUW quando chamares a função, o seu grupo de funções é automaticamente inicializado e assim garantes que o comportamento da função é o esperado.

Para fazeres debug a um programa que faça parte de um job faz o seguinte:

Se ainda não usas classes de excepção fazes mal. Porque são muito boas para a saúde do código. Além de nutritivas, emagrecem-no e tornam-no mais resistente a doenças.

Mas há casos em que ainda é preciso lidar com as antigas excepções. Por exemplo quando se invoca um módulo de função.

Neste artigo apresento uma sugestão um bocado rebuscada mas que funciona muito bem para integrar as excepções antigas com classe de excepção de uma forma simples. A solução é rebuscada mas só tem de ser feita uma vez. Uma vez feita, a forma como se a usa não tem nada de rebuscado.

O Flávio Pagoti, do blog ABAP101 publicou um livro em português sobre SAPUI5/OPENUI5. Aqui está o artigo do ABAP101 a anunciar o livro. Lá encontras um link para o comprar. Custa $9,99. A minha principal motivação quando decidi criar o Abapinho foi exactamente combater a gritante falta de conteúdos técnicos de qualidade escritos em português. Hoje as coisas estão um pouco melhores, em particular no mundo do ABAP onde há vários blogs de óptima qualidade.

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.

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.

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.

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.