"
Apoiado por

Automatizar catálogo de campos de ALV

À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.


Cenário típico:

  1. define-se uma tabela interna
  2. preenche-se essa tabela com dados
  3. constrói-se o catálogo de campos da ALV
  4. apresenta-se a ALV

Não é incomum a definição do catálogo de campos extender-se por centenas de linhas, as quais se limitam a definir a ordem, o tipo de dados ou as descrições de cada um dos campos.

O problema começa logo no passo 1, a definição dos dados:


TYPES: BEGIN OF ty_data,
             campo1 TYPE char10,
             campo2 TYPE char15,
             campo3 TYPE char10,
             campo4 TYPE i,
          END OF ty_data.
DATA: t_data TYPE STANDARD TABLE OF ty_data.

E continua no passo 3 porque, como esta definição de dados não explicita um contexto semântico para cada campo, depois, claro está, há que construir à mão o catálogo de campos da ALV:


DATA: o_table TYPE REF TO cl_salv_table,
          o_columns       TYPE REF TO cl_salv_columns.

cl_salv_table=>factory(
  IMPORTING
    r_salv_table = o_table
  CHANGING
    t_table      = t_data ).

o_columns = o_table->get_columns( ).

o_column = in_columns->get_column( 'CAMPO1' ).
o_column->set_short_text(  'Textito1' ).
o_column->set_medium_text( 'Texto 1' ).
o_column->set_long_text(   'Textão 1' ).

o_column = in_columns->get_column( 'CAMPO2' ).
o_column->set_short_text(  'Textito2' ).
o_column->set_medium_text( 'Texto 2' ).
o_column->set_long_text(   'Textão 2' ).

o_column = in_columns->get_column( 'CAMPO3' ).
o_column->set_short_text(  'Textito3' ).
o_column->set_medium_text( 'Texto 3' ).
o_column->set_long_text(   'Textão 3' ).

(etc... )

o_table->display( ).

Ora uma solução muito simples para evitar estar a espalhar descrições dos campos pelo código é, em vez de definir a estrutura de dados directamente no código, usar uma estrutura do DDIC em que cada campo tem o seu contexto semântico devidamente definido através de um elemento de dados que contém já as descrições que se pretende ver aparecer no ALV. Assim, já não é preciso definir programaticamente nem as descrições nem a ordem nem o tipo dos campos pois tudo isto será deduzido automaticamente pelas classes/funções das ALV:


DATA: t_data TYPE STANDARD TABLE OF zxxxxx_alv,
          o_table TYPE REF TO cl_salv_table.

cl_salv_table=>factory(
  IMPORTING
    r_salv_table = o_table
  CHANGING
    t_table      = t_data ).

o_table->display( ).

Poupam-se dezenas ou centenas de linhas no programa e além disso, desta forma os campos podem ser traduzidos, o que não é de pouca monta (cristalizar descrições no código é sempre de evitar). E se no futuro for necessário alterar a descrição de um campo basta modificar o elemento de dados a ele associado na estrutura. Cada coisa em seu lugar.

Como exemplo, um cenário real com que me deparei há uns dias: num relatório que apresentava os dados numa ALV foi-me pedido para adicionar a possibilidade de, ao invés, gravar os dados num Excel. Implementei esta opção (recorrendo ao fantástico ABAP2XLSX do qual falarei em breve) e depois constatei que os nomes das colunas no Excel eram todos feios tipo "CHAR10" ou descontextualizados tipo "Description" e "Text". Constatei que o programa até usava uma estrutura, mas os seus campos estavam definidos com elementos de dados genéricos. O catálogo de campos era modificado à mão sendo todas as descrições introduzidas programaticamente. Ora como o ABAP2XLSX também tem um catálogo de campos a solução mais simples e parva seria adicionar também as descrições ao catálogo de campos do ABAP2XLSX. Mas a solução melhor e mais saudável foi definir correctamente os elementos de dados da estrutura. Depois os campos passaram a aparecer automaticamente bem tanto no ALV como no Excel. E ainda pude apagar do programa todas as descrições directamente programadas.

(Obrigado Editor B pela imagem.)

O Abapinho saúda-vos.

4 comentários a “Automatizar catálogo de campos de ALV”

  1. ulisses Diz:

    Nuno,

    Parabéns pelo site! além de ter dicas interessantes, é divertido!
    PS não sou abap, mas FI

    abraço.

  2. admin Diz:

    Olá Ulisses, obrigado :)

  3. Luiz de Carvalho Diz:

    Parabéns pelas dicas,

    agora uma ajuda com relação a esse ALV, como coloco os botões com as funções de filtrar, exportar para excel, e etc.

    Grande abraço.

  4. Bruno Esperança Diz:

    Olá Luiz,

    Explora um bocadinho a classe CL_SALV. Tens muitos métodos à tua disposição para adicionar/remover funcionalidades, e podes também criar o teu próprio status e utilizá-lo com essa classe.

    Abraço.

Deixe um comentário


Acerca do Abapinho
O Abapinho é suportado pelo WordPress
Artigos (RSS) e Comentários (RSS).