Em tempos falámos na SAAB e nas vantagens de a utilizar para melhor conseguir analisar e descobrir problemas no nosso código. Nesse artigo não expliquei uma coisa que é realmente importante: variantes de activação.

Já todos usámos enhancements implícitos para adicionar código ao início ou final de funções, forms ou métodos standard. Mas é menos conhecido o facto de que também podemos adicionar campos a estruturas de dados, estejam elas declaradas como TYPES ou ou directamente como DATA.

Na escola aprende-se que o código deve ter sempre comentários. Depois, na vida real, descobrimos que nem toda a gente prestou atenção na escola.

Sempre tive o cuidado de comentar os vários passos do meu código, especialmente as partes mais obscuras ou que não são auto-explicativas.

Mas depois de ler o livro Clean Code do Uncle Bob, a minha opinião mudou. Hoje acredito que quanto menos comentários melhor. E no entanto não acho que esta mudança seja contraditória.

Ainda que o SAP nos apareça como um todo, este é constituído por várias partes independentes interligadas. Há um pequeno programa standard que verifica se os relógios de cada uma destas partes estão correctos e sincronizados.

Provavelmente não será de grande utilidade no dia-a-dia. Mas não deixa de ser uma curiosidade engraçada.

O vídeo abaixo demonstra como é simples criar condições para facilmente injectar comandos ABAP em programas em produtivo. Ponderei sobre partilhar este vídeo pois o seu conteúdo pode ser usado para fins menos nobres. Mas, como já aconteceu no passado, acredito que é preferivel que isto seja divulgado pois é fundamental que os administradores de sistema estejam conscientes desta possibilidade e protejam os seus sistemas dela. Pois é algo verdadeiramente perigoso.

Criaste uma tabela e os seus ecrãs de manutenção como objectos locais.

Quando mais tarde te arrependeres e decidires transportar a tabela, como fazes para os transportar também os ecrãs de manutenção?

Transportar só o grupo de funções não chega, vai dar erro.

Podia jurar que já tinha feito um post sobre isto mas não consigo encontrá-lo por isso aqui vai.

Há funções que guardam dados globais que serão depois usados por outra função do mesmo grupo. Ora se quiseres testar as duas juntas é fundamental que corram sequencialmente dentro da mesma transacção.

Toda a gente sabe que a transacção SE37 permite testar uma função. O que pouca gente sabe é que a transacção SE37 permite testar uma sequência de funções dentro da mesma transacção. Quem não sabe isto normalmente acaba por criar um pequeno programa de testes para chamar as várias funções em sequência. Fica agora a saber como o pode evitar.

Os PARAMETERS e os SELECT-OPTIONS até têm algumas opções de configuração. Mas muitas vezes dava jeito conseguir configurá-los ainda mais. E curiosamente, ainda que não seja assim tão simples, é possível fazê-lo, através de uma função standard.

Num sistema bem protegido, os utilizadores não têm permissões para debug. Mas muitas vezes isso complica a vida dos ABAPers que, ao quererem resolver um problema desse utilizador, não podem fazer debug à sua sessão.

Mas há uma forma legítima, ainda que pouco óbvia, de contornar o problema.

Estamos perante mais um daquelas dilemas: esconder porque é perigoso e alguém pode fazer o mal usando esta informação ou ensinar porque não o fazer é paternalista porque presume que os leitores não são responsáveis. O regimes de ditadura costumam optar pela primeira: queimam livros e censuram. O Abapinho gosta de acreditar que os seus leitores são pessoas responsáveis que merecem ter acesso ao conhecimento.

E, por isso, aqui está. Não, não é um manual de como criar urânio enriquecido nem uma fórmula para nitroglicerina caseira. Mas anda perto: é um truque para conseguir alterar objectos standard sem precisar de chave.

Como todos nós sabemos os administradores de sistemas são pessoas más, insensíveis e crueis. A prová-lo está o incontornável BOFH.

Nós, programadores ABAP, somos vítimas indefesas nas mãos destas criaturas maléficas.

Mas nem sempre somos obrigados a deixar-nos esmagar pelos dedos peludos dos seus caprichos.

A SE16N mostra-te os valores dos campos no formato externo. Até há pouco tempo eu usava a arcaica SE17 para ver os valores no formato interno. Mas o Rui Nunes explicou que há uma forma de o conseguir fazer na SE16N.

Aqui está uma forma pouco ortodoxa de lidar com o ecrã de selecção de um programa. Se tiveres um parâmetro que pretendes manter escondido dos olhos dos utilizadores e mesmo assim poder ter acesso a ele (ex.: um pisco para entrar em modo de debug) podes usar a palavra mágica ABRACADABRA para lhe aceder. Funciona assim: DATA: unhide_parameters TYPE flag. PARAMETERS: p_debug AS CHECKBOX. AT SELECTION-SCREEN. CASE sy-ucomm. WHEN 'ABRACADABRA'. unhide_parameters = abap_true.

No outro dia encontrei um programa que gerava um comando SQL com base em várias variáveis fixadas no código. Mas, por distracção ou ignorância, a alminha que fez aquilo achou que fazia sentido associar essas variáveis a símbolos de texto. Algo assim:

Às vezes uma SALV pode ter inconsistências que passam despercebidas a quem as programa. Um exemplo é uma estrutura com um campo WRBTR sem um campo de moeda associado: