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.

A lei do menor esforço, esse grande axioma da Humanidade, tem, no mundo da programação, a particularidade de, em muitos casos, acabar por ser simplesmente a lei do esforço adiado. Porque é muito provável que algo que tenha sido desenvolvido de acordo com esta lei venha mais tarde a precisar de um grande esforço extra. Seja dos utilizadores que vão utilizar esse algo ou dos programadores que mais tarde terão de o manter. Atire a primeira pedra aquele que não se deixou guiar por esta lei ao desenvolver este ou aquele programas. Eu não atiro.

Prólogo Quando digo que gosto de usar diagramas de classes UML para documentar o meu código as pessoas acham que sou maluco. Introdução O UML ganhou má fama porque as pessoas pensam que primeiro se faz o diagrama de classes todo em UML e só depois o programa. Mas isso era em 1996, quando se achava que a primeira coisa a fazer era o desenho técnico todo, mesmo que na práctica ninguém nunca o fizesse. Hoje em dia felizmente já não temos vergonha de dizer que o próprio acto de programar é já em si uma forma de desenhar.

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:

Mais uma vez o SAPGui me surpreende com mais um atalho obscuro que desconhecia. Usemos a transacção de visualização de clientes XD03 como exemplo: Entras no ecrã de selecção da transacção escrevendo lá em cima /NXD03 Introduzes o número do cliente que queres visualizar e carregas em ENTER Fazes lá o que tens a fazer e depois sais da transacção Mas… de repente… precisas de ver mais qualquer coisa desse cliente

No meu cliente tenho três ambientes de desenvolvimento. Dantes tinha só um. E foi nesse que configurei a variante do Code Inspector que uso para correr o Abap Test Cockpit. Quando apareceram os outros dois, antes de me decidir a replicar a variante à mão em cada um deles, decidi investigar um pouco. Para minha surpresa encontrei no GitHub o projecto upDOWNci que faz exactamente o que eu precisava: exportar e importar variantes do Code Inspector.

Se num relatório chamado APP1 precisares de gravar um ficheiro numa determinada pasta do servidor (ex.: /export/app1/) e não quiseres que esta pasta seja um parâmetro, como fazes?

Estas no editor. Introduzes um ( ou [ ou { ou ' e o SAP é mongo e não o fecha certo? Ora bem, Clica no ícone em baixo à direita que acede às opções do SAPGui onde adicionamos template. Na opção formatting , activas o Enable Auto Brackets e voilá, o SAP começa a fechar automaticamente as portas que tu abres. Mais valia que isto viesse activado de raiz.

Todos os dias o ABAP me revela coisas novos. Às vezes coisas que mais valia eu nem saber que existem. Como esta. A tabela T056P tem um campo com uma data. Fazendo um SELECT a esta tabela filtrando pela data não conseguia obter nada de jeito. Mas o código parecia correcto. Na SE16N descobri que o intervalo de datas também não funcionava conforme esperado: só apresentava resultados quando a data final era colocada no LOW e a inicial no HIGH. Bizarro.

O Manelinho criou a transacção ZFB01 associada ao programa ZFB01 que faz lá umas coisas e depois faz CALL TRANSACTION à FB01. A seguir veio o Joãozinho e correu a transacção ZFB01. Conseguiu começar a corrê-la porque tem permissões para a transacção ZFB01. Mas a meio teve um erro porque não tem permissões para a transacção FB01. Tanto o Manelinho como o Joãozinho sabiam que os administradores de sistema nunca na vida deles darão ao Joãozinho autorizações para correr a FB01.

Quem lê o Abapinho sabe quanto gosto de classes de excepções. No entanto, este não é o único mecanismo que o ABAP disponibiliza para controlo de erros. Há outro, chamado ASSERT, que devia ser mais usado, e que hoje trago à baila.

Nos dias que correm se não estás a usar objectos és totó. Se usas objectos, espero que estejas a seguir a boa práctica de usar classes de excepções. E se usas classes de excepção é bom que entendas a melhor forma de as usar, particularmente as vantagens de as encadear. Com tudo isto esclarecido, chegamos ao que nos traz aqui hoje. No artigo sobre cadeias de excepções mostrei como, para obter o texto da excepção mais profunda, a que foi inicialmente espoletada, se pode fazer um DO WHILE:

Tenho usado cada vez mais referências em ABAP. Primeiro usava REF TO só para classes mas vou percebendo cada vez mais as vantagens de as usar também para estruturas de dados. Mas, tal como acontece em C++, há que ter cuidado quando se lida con referências para dados pois facilmente a coisa pode dar para o torto. Neste artigo tento mostrar como usar e como não usar o REF TO data. Comecemos por ver um exemplo de como não usar:

Estava a tentar actualizar uma linha de uma SORTED TABLE e não estava a conseguir.