Às vezes pergunto-me qual será, no mundo, a percentagem de código ABAP desnecessário. Um exemplo paradigmático de como se pode desperdiçar tempo a escrever código que não serve para nada e só prejudica é a tão frequente definição das descrições dos campos de uma ALV directamente em ABAP.

Durante doze anos Quando quis contar As linhas de uma itab Fazia o que todos fazem: DESCRIBE TABLE itab LINES linhas.

Até que outro dia Vi uma coisa que, Parece mentira, Nunca antes vira: LINES( itab ).

Dá no mesmo E sem ter de declarar O raio da variável.

Assim, em vez de:

DATA: linhas TYPE i.
DESCRIBE TABLE itabl LINES linhas.
IF linhas = 42.
  WRITE 'A tua tabela é a verdade'.
ENDIF.

Basta fazer:

IF LINES( itbl ) = 42.
  WRITE 'A tua tabela é a verdade'.
ENDIF.

É a prova de que Se a SAP quisesse Fazia um esforço E o ABAP seria Uma coisa fixe.

Nos módulos AT SELECTION-SCREEN de um REPORT é-te possível lançar mensagens de erro e voltar ao ecrã de selecção. Mas uma vez que passes do START-OF-SELECTION, se lançares uma mensagem de erro, o programa termina. A solução para dar um erro e, ainda assim, regressar ao ecrã de selecção, é travestir a mensagem:

START-OF-SELECTION.
  IF condicao_desejada.
    MESSAGE S208(00) with 'Erro!' DISPLAY LIKE 'E'.
    EXIT.
  ENDIF.
  WRITE 'Olá, eu sou o resto do programa'.

A mensagem do tipo S mascarou-se de E. Parece que É, mas não É.

Nunca te aconteceu esbarrares com uma coisa no ABAP que parece que é mas não é? A documentação diz que é, tudo indica que assim seja, e depois afinal não é.

Provavelmente já precisaste de, ao definir um parâmetro no ecrã de selecção de um relatório, limitar as possibilidades do que o utilizador pode introduzir aos valores disponíveis no tipo de dados desse parâmetro, certo? Para isto existe o VALUE CHECK. Parece simples. Por exemplo, presumia-se que isto funcionasse:

Classes. Sempre as houve entre as pessoas. Mas no ABAP ainda há poucos que as tenham em conta. Se ser classicista na sociedade pode resultar em pedantismo, no ABAP, a única luta de classes é a que alguns travam para que estas sejam mais usadas.

Há dois tipos de classes: as globais e as locais. As globais são criadas na transacção SE24. As locais, que por sinal dou por mim a usar cada vez mais, são feitas declarativamente na SE38. Se soubermos que a nossa classe vai ser usada amiúde, faz sentido criá-la global. Se, pelo contrário, a classe for particular a um programa, não há porque fazer dela um objecto autónomo, bastando assim criá-la local ao programa que a vai usar.

Aqui vos mostro uma forma criativa de preencher uma tabela interna com constantes que aprendi num programa standard. Imagina que querias criar uma tabela interna com os seguintes tipos de documento financeiro:

AB AF CH DG DZ EX F3 F4.

A forma mais convencional seria assim:

DATA: t_blart TYPE STANDARD TABLE OF blart,
      wa_blart LIKE LINE OF t_blart.

wa_blart = 'AB'.
APPEND wa_blart TO t_blart.
wa_blart = 'AF'.
APPEND wa_blart TO t_blart.
wa_blart = 'CH'.
APPEND wa_blart TO t_blart.
wa_blart = 'DG'.
APPEND wa_blart TO t_blart.
wa_blart = 'DZ'.
APPEND wa_blart TO t_blart.
wa_blart = 'EX'.
APPEND wa_blart TO t_blart.
wa_blart = 'F3'.
APPEND wa_blart TO t_blart.
wa_blart = 'F4'.
APPEND wa_blart TO t_blart.

Mas há uma forma muito mais sintética e curiosa:

Volta não volta aparece um cliente que pede a um funcional que pede a um programador que crie um parâmetro protegido contra escrita no ecrã de selecção de um programa. É um bocado cretino visto que a ideia dos parâmetros é serem parametrizáveis.

Mas enfim, vê-se de tudo.

Os clientes têm tanta imaginação que a SAP devia criar um módulo de cinema, SAP CI, especialmente para eles poderem realizar os tantos filmes que lhes vão na cabeça. Estou certo de que se criariam grandes sucessos de ficção científica. E muitas comédias também.

Qual é a tua cor preferida?

SELECTION-SCREEN BEGIN OF BLOCK b1.
PARAMETERS: p_azul BUTTONGROUP GROUP COR DEFAULT 'X',
            p_verde BUTTONGROUP GROUP COR,
            p_roxo BUTTONGROUP GROUP COR.
SELECTION-SCREEN END OF BLOCK b1.

Se respondeste azul sobrevives e podes atravessar a ponte.

De qualquer das formas, em ABAP costuma fazer-se o seguinte para descobrir a cor que o utilizador escolheu:

IF p_azul = 'X'.
  lv_cor = 'AZUL'.
ELSE IF p_verde = 'X'.
  lv_cor = 'VERDE'.
ELSE IF p_roxo = 'X'.
  lv_cor = 'ROXO'.
ENDIF.

Mas há uma forma curiosa e muito mais elegante de conseguir o mesmo. É aquilo a que se pode chamar de CASE de pernas para o ar:

Quando se quer obter um único registo de uma tabela da base de dados é costume usar-se o SELECT SINGLE que, como toda a gente sabe, na sua forma mais básica reza assim:

SELECT SINGLE *
  FROM KNA1
  WHERE KUNNR = '1234567890'.

Vou ensinar-te uma fórmula mágica para gerar um RANGE em que praticamente é só juntar água.

Imagina que queres fazer um RANGE a partir de uma seleção da base de dados para depois o utilizar num outro SELECT qualquer. Claro que o poderias fazer assim:

DATA: lt_kunnr TYPE STANDARD TABLE OF kunnr,
        lr_kunnr TYPE RANGE OF kunnr,
        wa_kunnr LIKE LINE OF lr_kunnr.
FIELD-SYMBOLS: <kunnr> LIKE LINE OF lt_kunnr.

SELECT kunnr
  INTO TABLE lt_kunnr
  FROM kna1.

wa_kunnr-sign = 'I'.
wa_kunnr-option = 'EQ'.
LOOP AT lt_kunnr ASSIGNING <kunnr>.
  wa_kunnr-low = <kunnr>.
  APPEND wa_kunnr TO lr_kunnr.
ENDLOOP.

E assim usaste 15 linhas de código e 4 variáveis. Mas vê lá agora esta alternativa: