No outro dia estava a aprender sobre ST (Simple Transformations) e lembrei-me que, ainda que tenha sido desenvolvida para transformar dados, é uma forma práctica de guardar dados XML.
Temos o seguinte XML:
<cocktails>
<cocktail id="gt" nome="Gin Tonic"/>
<cocktail id="ws" nome="Whiskey Sour"/>
<cocktail id="cl" nome="Campari Laranja"/>
</cocktails>
É frequente ao programar começar a sentir um cheiro desagradável. Normalmente não consigo logo identificar o que é. Sinto apenas uma leve mas incómoda fragrância. À medida que vou cheirando com mais propósito vou conseguindo perceber de onde vem. Mas mesmo nessa altura, muitas vezes ainda não me é perfeitamente claro porque é que aquele cheiro dali vem.
Desde 1998 que oiço colegas ABAPers dizerem que não vale a pena meter determinado código numa função ou método porque não lhes parece que este vá tornar a ser reutilizado. E lá vão continuando na SE38 a fazer os seus reports cheios de includes.
A ideia de que a principal razão para encapsular código é poder reutilizá-lo é um dos maiores mal entendidos da história do nosso planeta.
No mundo do SAP, o código ABAP onde cai é onde fica.
Num dia o Manel faz uma coisa mal porque está com pressa ou não sabe fazer melhor. Um ano depois pedem ao António para fazer uma pequena alteração. O António vê a asneira do Manel mas não a melhora porque, por alguma razão, no mundo do SAP, alterar código que está a funcionar, por muito mau que seja, é tabu. Em vez disso, acrescenta o seu código ao já existente de forma geralmente acrítica.
Esta atitude, quando adoptada por todos, contribui para uma inevitável erosão do código de um sistema que, após alguns anos, se tornará ingerível.
No meu entender, isso está errado e vai contra os interesses do cliente. Aliás, mesmo se o cliente não quiser que se mexa no código antigo… eu mexo. Quem é ele para me dizer como é que se programa?
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 João estuda Engenharia Informática na Universidade onde aprende Java, polimorfismo, encapsulamento e uma série de outras técnicas e boas prácticas. Quando termina o curso é contratado por uma empresa para trabalhar em SAP. No curso de introdução ao ABAP que a empresa lhe oferece, a primeira coisa que ensinam é como fazer o programa ZJOAO. Explicam assim:
_“Vais à SE38, crias o programa ZJOAO e crias logo os includes ZJOAO_TOP, ZJOAO_FRM e ZJOAO_SEL. Depois metes as variáveis todas no _TOP, o ecrã de selecção no _SEL e todos os FORMs no FRM. A partir daqui é só ires programando. Primeiro escreves START-OF-SELECTION e a seguir fazes todos os SELECTs e depois escreves END-OF-SELECTION e mostras tudo numa ALV. É simples, vês? Bem-vindo ao ABAP."
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.
A transacção SE37 permite testar módulos de função. Por vezes esses módulos de função utilizam tabelas. Pode dar-se o caso de precisarmos de carregar muitas linhas de dados de teste em uma ou mais dessas tabelas.
Aqui fica um truque para o conseguir fazer a partir de um ficheiro.
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.