Esta dica é simples e rápida mas aposto 200$482 em como poucos a sabem.

Quando, num método de uma classe, crias um parâmetro de retorno que é um TABLE TYPE baseado num tipo declarado na própria classe, às vezes aparece um erro que diz:

“Os parâmetros RETURNING devem ser completamente tipificados.”

Um amigo de um amigo de um amigo disse que um amigo dele conhecia um amigo que, num bar de alterne ali nas docas, lhe explicou como roubar os dados a uma SALV.

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.