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.

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.

Este artigo é da autoria de José Vília.

A ovelha Dolly está no ABAP e eu não sabia.

Depois de criar uma instância de uma classe, gostava de partilhá-la com outro programa totalmente independente para que este outro programa posso usá-la como se a tivesse instanciado.

Como se de uma fábrica de ovelhas Dollies se tratasse, o ABAP pode utilizar serialização para resolver o problema.

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