Todo os funcional, até o mais funcional dos funcionais, sabe que para começar a depurar (vá, a fazer debug a) um programa ABAP se usa o comando /H. Mas raro será o programador, mesmo o mais programador dos programadores, que saberá para que serve o comando /HS.

As expressões regulares já existem há que tempos. Mas ainda são muito pouco conhecidas e ainda menos usadas. São uma espécie de linguagem descritiva que permite efectuar pesquisas e substituições muito sofisticadas em cadeias alfa-numéricas.

Ora aprende lá como invocar dinamicamente um método. Vamos a isso.

Este artigo é um dois em um. Ou seja, vais aprender duas coisas de uma só vez. Mas prepara-te, o que vais aprender é dinamite e, nas mãos erradas, pode fazer implodir o teu universo. Primeiro vais aprender a ir ler conteúdo à net. E logo a seguir, assumindo que esse conteúdo é código ABAP, aprendes de rajada a executá-lo.

A dica de hoje não é uma dica. É um conselho. Criada uma tabela, depois crias as suas vistas de manutenção. As vistas de manutenção vivem dentro de um grupo de funções. Grupo de funções esse que te é pedido aquando da criação delas. Porque afinal aquilo não passa de um conjunto de código gerado, sendo que a maior parte são ainda assim includes standard. Montes deles. Apresento-te o problema: há quem crie funções Z suas e as coloque em grupos de função que contêm vistas de manutenção. É verdade. Há quem o faça.

Nos maus velhos tempos em que o ABAP era ainda mais antiquado do que é hoje, as declarações de variáveis eram quase todas feitas com LIKE e referenciadas a campos de tabelas: DATA: V_KUNNR LIKE KNA1-KUNNR.

Já avisei aqui que, em tabelas com muitos campos, é sempre de evitar fazer SELECT *, devendo-se sempre seleccionar explicitamente apenas os campos necessários. Mas não avisei ainda que há ainda outra optimização que merece ser feita: evitar o INTO CORRESPONDING FIELDS OF TABLE.

A SAP começou a semana passada a dar um curso grátis sobre HANA. Corram!

Esta dica vem, no meu entender, uns anos tarde demais, visto ser já raro usar o comando WRITE para escrever directamente coisas para o ecrã. É, portanto, digamos assim, uma dica retro. Uma dica vintage. Mas vamos supor que estamos ainda no século XX a debater-nos com o comando mais barroco do ABAP, o WRITE. Imagina-te então, sentado à frente do SAP, a ouvir Pearl Jam, com uns auscultadores de cor preta, e a escrever WRITEs de uma série de valores no ecrã sobre os quais gostavas que o utilizador pudesse ter mais informação.

Queres invocar uma função RFC noutro sistema mas, porque não és necrófago, só o queres fazer se ele estiver vivo. Precisas então de uma forma de saber se esse determinado sistema destino RFC está vivo. Como fazes? O Charles Santana faz assim: DATA: rfcdest TYPE rfcdest, ping_status TYPE /sdf/e2e_traffic_light_numeric. CALL FUNCTION '/SDF/RFC_CHECK' EXPORTING iv_destination = rfcdest iv_ping = 'X' iv_logon = 'X' iv_latency = 'X' IMPORTING ev_ping_status = ping_status. if lv_ping_status <> 1.

Chamas uma função. Imagina que ela não responde. Pode ser por ter ficado calada. Ou por ser tímida. Ou muda. Ou, ai tragédia!, por não existir. Para teres a certeza e ficares descansado fazes assim:

Há quem leia a TCURX para descobrir o número de casas decimais de uma MOEDA quando precisa de escrever um campo endinheirado para uma variável ALFANUMERICA. És assim? Não sejas.

Espatifaste o sistema produtivo: fizeste uma alteração a um método de uma classe (ou a uma função, vá). Outra pessoa faz outra alteração a outro método da mesma classe (ou a outra função do mesmo grupo de funções, vá) e grava-a num transporte diferente. Quando transportas as tuas alterações para produtivo descobres que a classe (ou função, vá) agora tem um erro de sintaxe porque as alterações tinham dependências. Descobres também que agora, e até resolveres este problema, todos os teus colegas funcionais te odeiam.

Finalmente, com o SAP NetWeaver 7.0 Enhancement Package 2 o ABAP começa a parecer-se com uma linguagem de programação normal. Até já dá para encadear expressões, vê lá tu!

Ao ler um ficheiro com valores numéricos para uma tabela interna ou vice-versa, o sucesso da conversão destes depende de o utilizador tem definido o ponto ou a vírgula como separador decimal. É costume ir então ler a configuração do utilizador e depois, adaptar os valores vindos do ficheiro com ponto ou vírgula conforme. Mas isto é lamentável e pouco elegante. Devia haver uma forma de não fazer a coisa depender do utilizador. E há.