Claro que já conheces a transacção SE30 (Análise de tempo de execução) e claro que a usas amiúde para analisar programas standard e descobrir nele tabelas, funções, BADIs e quejandos.

Ora se fores como eu, manténs uma relação de amor-ódio com esta transacção: se por um lado a amas por graças a ela consegues ver as entranhas de um programa sem ter de fazer debug, por outro lado odeia-la porque normalmente a lista de entranhas costuma ter milhares de linhas e tornar-se ingerível.

Mas eu já não sou como eu porque, desde que descobri que a SE30 permite fazer análises parciais, a minha relação com ela passou a ser de puro amor. E a partir de agora também tu poderás amá-la na sua totalidade porque vou ensinar-te este segredo.

1. Transacção SE30;
2. No bloco “Restrições de medição” cria uma variante com um nome qualquer diferente do DEFAULT;
3. Na variante activa o pisco “Unidades determinadas”;
4. Insere a transacção ou programa ou módulo de função a analisar;
5. Carrega em “Executar” (normalmente agora a análise começaria mas, como escolhemos “unidades determinadas”, começa desligada e é preciso ligá-la explicitamente);
6. Navega dentro do programa que estás a analisar até chegares ao ponto que queres analisar;
7. Activa a análise escrevendo /ron lá em cima no campo de comandos;
8. Faz o que tens a fazer;
9. Desactiva a análise escrevendo lá em cima /roff;
10. Sai do programa, voltando ao ecrã da SE30.

Acabaste de fazer uma análise parcial que, em vez dos típicos milhares de linhas, tem apenas as dezenas ou centenas de linhas que ocorreram entre os comandos /ron e /roff. Mais útil, não?

Aproveita o balanço e explora as outras possibilidades disponibilizadas pelas variantes de “restrição de medição”.

Obrigado a Michael Opoczynski pelo ensinamento.

E obrigado a * Cati Kaoe * pela foto.

O Abapinho saúda-vos.

O SAP é um grande poliglota. Mas o ABAP nem sempre. O ABAP até tem muita facilidade em aprender e falar várias línguas, mas às vezes os programadores não o deixam.

Muitos programadores cinzelam os textos literais directamente no programa, deixando-o irremediavelmente incapaz de comunicar em vários idiomas. Imagino duas razões para se agrilhoar um programa a uma única língua:

• A preguiça, que é a principal razão para se fazerem as coisas mal feitas;
• A legibilidade. Realmente a forma de tornar um programa ABAP localizável é pejá-lo com referências a textos, tipo TEXT-001, o que pode torná-lo bastante ilegível.

Então aqui fica uma dica para ter o melhor dos dois mundos: um programa localizável que não perca a legibilidade:

Em vez de seres preguiçoso e fazeres:

WRITE: 'Eu quero ver auroras boreais'.

E em vez de seres obscuro e fazeres:

WRITE: TEXT-001.

Sê esperto e faz:

WRITE: 'Eu quero ver auroras boreais'(001).

E já está.

Se o text TEXT-001 estiver definido na língua em que o programa estiver a correr este TEXT-001 será usado. Caso contrário, o texto literal escrito directamente no programa será usado. Assim mantém-se a legibilidade do código, pode traduzir-se os textos à vontade e ainda por cima temos a certeza de que, mesmo quando faltar traduzir algum texto, mesmo assim aparecerá o texto que está no programa.

Obrigado Sérgio Lopes pela dica.

(E obrigado doug88888 pela foto)

O Abapinho saúda-vos.

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.

Mas parece que não quer
E o ABAP que se lixe.

Merda de poema. Foi o que se arranjou.

O Abapinho saúda-vos.

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 S001(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 É.

Se experimentares vais ver que o sistema dá erro mas não sai completamente do programa; Volta ao ecrã de selecção e não corre o resto do programa (por causa do EXIT).

Obrigado Sérgio Lopes pela dica.

(E obrigado Tiago Celestino pela foto)

O Abapinho saúda-vos.

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:

PARAMETERS: P_BUKRS LIKE T001-BUKRS OBLIGATORY VALUE CHECK.

Vais a ver e não funciona.

O campo T001-BUKRS é do tipo BUKRS que é do domínio BUKRS que por sua vez tem definida a tabela de valores T001 para a qual BUKRS é a única chave primária. Mesmo assim, pateticamente, isto não funciona. Não funciona porque, por alguma razão lamentável, ao contrário do que faria sentido e se subentende na documentação, o VALUE CHECK não tem em conta o domínio do campo que valida. Pelo contrário, para este funcionar é preciso que o campo referido tenha uma chave externa para a tabela de valores.

Portanto, no nosso caso, embora a tabela que contém a lista de valores possíveis do BUKRS seja a T001, para o VALUE CHECK funcionar temos antes de fazer referência a uma outra tabela qualquer que tenha a T001 definida como chave externa. Como por exemplo, a T001K:

PARAMETERS: P_BUKRS LIKE T001K-BUKRS OBLIGATORY VALUE CHECK.

E assim já funciona.

Em resumo: conhecendo já tu a tabela com os valores possíveis, em vez de a poderes usar, tens de ir procurar outra que a defina como chave externa. É complicar o simples com rodeios. Um retórico chamar-lhe-ia circunlóquio. Eu chamo-lhe estupidez. Aposto que é um bug que a SAP decidiu orgulhosamente ignorar para sempre.

Obrigado Luís Rocha pela dica.

O Abapinho saúda-vos.

Quando se está a desenvolver um relatório com um ecrã de selecção, é muito chato de cada vez que o testamos ter de preencher o ecrã de selecção com os dados de teste. Normalmente acabamos por criar uma variante de teste para nos poupar a esse chatice. Mas mesmo assim, de cada vez que corremos o relatório, temos de invocar manualmente esta variante.

Aqui está uma forma simples de invocar automaticamente uma variante. Este código pode ser inserido no evento INITIALIZATION durante o desenvolvimento do programa:

INITIALIZATION.

  CALL FUNCTION 'RS_SUPPORT_SELECTIONS'
    EXPORTING
      report                     = sy-repid
      variant                    = 'TESTE'
 EXCEPTIONS
   VARIANT_NOT_EXISTENT       = 1
   VARIANT_OBSOLETE           = 2
   OTHERS                     = 3.

Obrigado Sérgio Fraga pela dica.

(E obrigado a Telstar Logistics pela foto)

O Abapinho saúda-vos.

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.

Não é impossível que uma classe local se venha mais tarde a revelar útil noutro sítio. A hipótese mais estúpida, ainda que não inédita, é copiar o código de um programa para outro. Outra hipótese é colocá-la num “include” partilhado pelos vários programas que a usem. Mas mesmo isto também foleiro. Se é usada em mais que um sítio, ficará sempre mellhor como objecto global da SE24.

Os senhores da SAP, pensando já na possibilidade de uma classe local se emancipar, criaram uma ferramenta para isto. Funciona assim:

1. Vai à SE24
2. No menu “Tipo de objecto” escolhe a opção “Importar” e depois “classe local de programa”
3. Escolhe o programa
4. Aparece uma lista das classes locais desse programa
5. scolhe as classes locais que queres tornar globais
6. Dá-lhes um nome
7. E pimbas

Se esta ferramenta não te parecer útil, vai comprar o livro ABAP para totós.

O Abapinho saúda-vos.

O SAP GUI tem boa memória. Vai decorando os valores que lhe vamos metendo nos campos e depois sugere-os quando, mais tarde, voltamos a esses campos. Mas às vezes decora coisas que mais valia esquecer. Como por exemplo quando introduzimos um valor errado e a seguir ele insiste em sugerir-nos esse valor errado.

Há uns tempos descobri que este pequeno drama tem solução. Quando, no campo, aparece a combo box com as várias hipóteses, usa as setas do teclado para te posicionares no valor que queres esquecer e depois carrega na tecla DELETE. E assim se faz o SAP GUI esquecer um valor.

(Obrigado a cloois pela foto)

O Abapinho saúda-vos.

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:

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

lv_blart_list = 'AB AF CH DG DZ EX F3 F4'.
SPLIT lv_blart_list AT space INTO TABLE t_blart.

O preenchimento da tabela é feito em apenas 2 linhas, bem menos que as 16 da forma convencional.

Fica aqui mais um exemplo copiado do standard que é interessante por ter dois níveis:

l_action_list = 'A01 A02 A03 A04'.
SPLIT l_action_list AT ' ' INTO TABLE lt_action.
LOOP AT lt_action INTO l_action.
  CASE l_action.
    WHEN 'A01'. l_refdoc_list = 'R01 R02 R03 R04 R05 R06 R14'.
    WHEN 'A02'. l_refdoc_list = 'R07 R08 R10 R12'.
    WHEN 'A03'. l_refdoc_list = 'R07 R08 R10 R11 R12 R13'.
    WHEN 'A04'. l_refdoc_list = 'R09'.
  ENDCASE.
  SPLIT l_refdoc_list AT ' ' INTO TABLE lt_refdoc.
  LOOP AT lt_refdoc INTO l_refdoc.
    ls_cust-action = l_action.
    ls_cust-refdoc = l_refdoc.
    APPEND ls_cust TO t_cust.
  ENDLOOP.
ENDLOOP.

O Abapinho saúda-vos.

Como todos sabem, pode fazer-se selecções de blocos de texto verticais e horizontais em quase todo o lado do SAPGUI carregando em CTRL-Y e depois arrastando o rato para fazer a selecção. Como todos também sabem, isto não funciona no editor de ABAP. Mas o que provavelmente nem todos sabem é que há uma forma de fazer este tipo de selecções no editor de ABAP: primir e manter o ALT. Assim já podes seleccionar blocos de texto. Bom, não?

Obrigado Sérgio Fraga pela dica.

O Abapinho saúda-vos.