RTTS, RTTI, RTTC e você: tudo a ver – Parte 2

E aí, como vai aquele desenvolvimento bizarro em que você precisa identificar qual o tipo de uma determinada variável em tempo de execução? Hoje vamos explorar alguns exemplos do RTTS para fazer esse trabalho sujo.

Lembrando que na Parte 1 você entende a teoria por trás do RTTS e aprende um pouco sobre casting e o operador “=?”. Esta é a Parte 2 e, na Parte 3, iremos analisar como criar variáveis em tempo de execução.

Pegue a sua lupa de Sherlock Homes e vem comigo identificar essas variáveis safadas.

Analisando o tipo de uma váriável

Muita gente conhece o bom e velho DESCRIBE para tentar descobrir alguma coisa sobre as variáveis em tempo de execução. Nós mesmo já falamos um pouco do DESCRIBE TABLE por aqui. Porém, se você ler o HELP do describe, vai ver que a recomendação é usar o RTTS ao invés do DESCRIBE e variações, por conta da flexibilidade que as classes do RTTS proporcionam.

Como ignorar essas recomendação é algo abapossauriano, vamos fuçar um pouco no funcionamento do RTTS para analisar uma variável. No exemplo abaixo a variável “material” está referenciada ao DDIC. Experimente trocar de “mara-matnr” para outros tipos para ver diferentes resultados:

DATA: material  TYPE mara-matnr,
      texto     TYPE string.

DATA: relative_name TYPE string.

DATA: o_typedescr TYPE REF TO cl_abap_typedescr.

DATA: x031l TYPE TABLE OF x031l,
      x030l TYPE x030l.

* Criando o objeto para análise. Este objeto fará referência ao
* tipo da variável "material".
o_typedescr = cl_abap_typedescr=>describe_by_data( material ).

* Nome absoluto contém o nome + identificador. No caso, será \TYPE=MATNR
* que indica que este objeto é referente a um TYPE MATNR(elemento de dados).
* Experimente trocar o tipo do campo para PSTAT, e você verá que o TYPE muda
* para o elemento de dados, que é o PSTAT_D.
WRITE / o_typedescr->absolute_name.

* Nome utilizado para referência no programa.
relative_name = o_typedescr->get_relative_name( ).
WRITE / relative_name.

* Métodos que só funcionam se o tipo referenciado veio do DDIC.
* Se você trocar de "material" para "texto" na hora de chamar o
* método describe_by_data, irá tomar um DUMP na cabeça.
x031l[] = o_typedescr->get_ddic_object( ).
x030l   = o_typedescr->get_ddic_header( ).

* Tipo da Variável, neste caso C de CHAR
WRITE: / o_typedescr->type_kind.

* Tamanho da variável, para o elemento de dados MATNR - 18
WRITE: / o_typedescr->length.

Neste caso utilizamos o método describe_by_data, mas você pode utilizar outros métodos para buscar a instância, como o describe_by_name. No caso do e describe_by_name, você teria que passar o nome do tipo direto – “MATNR” ( pelo describe_by_data voccê passa a variável).

Para quem não está acostumado com OO, este exemplo pode levar a uma pergunta importante…

Ué, mas onde foi parar o CREATE OBJECT?

Quando você precisa utilizar um objeto, nem sempre isso quer dizer que você precisará criá-lo. É extremamente comum no mundo do ABAP Objects delegar a atividade de criação para algum método de alguma classe. Tipo aqueles chefes que só delegam, delegam, delegam e não fazem nada.

Sério agora: no caso do exemplo anterior, quem irá executar o “CREATE OBJECT” é o método “cl_abap_typedescr=>describe_by_data“. Esse método é um método estático, ou seja, não precisa ser acessado a partir de uma instância. Se você não entendeu nada, imagine que chamar um método estático público de uma classe da SE24, é igual a chamar uma função, no sentido de ser um pedaço de código que está em algum lugar e que pode ser acessado por qualquer programa.

Pelo lado do design do RTTS, imagine que você está fazendo a seguinte requisição: “Hey RTTS, me devolva a instância certa, preenchida com todos os dados dessa variável que estou te enviando“. Saber disso, por hora, é o suficiente .

Para os curiosos de plantão, existe uma construção clássica (design pattern) em OO que se chama Factory. Ela abusa de métodos estáticos para que a classe crie a instância da melhor maneira possível. Dê uma olhada neste link para saber como funciona, com exemplos em ABAP. Diz a lenda que eu vou fazer um post disso algum dia, mas é só uma lenda urbana e pode ser mentira, tipo bicho papão, saci pererê, geisy arruda…

Descobrindo os campos de uma estrutura

Agora que você entendeu como instanciar objetos do RTTS, e como fazer análises em uma variável simples, está na hora de utilizar a maravilinda análise de estruturas.

Manja quando você tem aquela estrutura maldita e precisa descobrir se ela tem o campo que você precisa, na posição que você precisa, do tipo que você precisa, do elemento de dados que você precisa, aaaaaaaAAaAaAAa? Pois seus problemas acabaram! Descobrir os campos de uma estrutura, sua posição e outras parafernálias nunca foi tão fácil!

DATA: estrutura TYPE mara.

DATA: componentes TYPE cl_abap_structdescr=>component_table.

DATA: structdescr   TYPE REF TO cl_abap_structdescr,
      campodescr    TYPE REF TO cl_abap_datadescr.

FIELD-SYMBOLS <component> LIKE LINE OF cl_abap_structdescr=>components.

structdescr ?= cl_abap_structdescr=>describe_by_data( estrutura ).

* Aqui você recebe a lista de todos os componentes da estrutura, com outros
* objetos já referenciados de acordo com o tipo do campo. (abra no debug para entender)
* Com isso você pode saber O QUE VOCÊ QUISER sobre QUALQUER CAMPO da estrutura.
* Não é feitiçaria, é SAPLoLogia (só pra rimar)
componentes = structdescr->get_components( ).

* Vamos analisar um campo específico da estrutura:
campodescr = structdescr->get_component_type( 'MATNR' ). "Troque o campo para experimentar!"
WRITE: /01 'MATNR',
       10 'É do tipo',
       20 campodescr->type_kind.

*Ah, mas tudo que eu quero é um lista dos campos e já era!
LOOP AT structdescr->components ASSIGNING  <component>.
*   Tá, toma aí
    WRITE: /01 <component>-name,
            20 <component>-decimals,
            30 <component>-length,
            40 <component>-type_kind,
            50 sy-tabix. "posição na estrutura
ENDLOOP.

Viu ali o operador =? entrando em cena? Isso acontece porque o método “describe_by_data” está declarado na classe pai CL_ABAP_TYPEDESCR, e esse método retorna um parâmetro do tipo TYPEDESCR. Porém, como programadores espertos que somos, sabemos que AQUELE “describe_by_data” da classe CL_ABAP_STRUCTDESCR vai retornar uma instância da classe CL_ABAP_STRUCTDESCR. É aí que o =? entra em jogo, e dizemos para o verificador de sintaxe não encher o saco porque a gente sabe o que está fazendo.

AI MEU DEUS MAURICIO, NÃO ENTENDI NADA DESSE ÚLTIMO PARÁGRAFO!!!1!!1!!1!!

Leia a Parte 1. Se mesmo assim não entendeu, pergunta pra gente aí nos comentários .

Com a classe CL_ABAP_STRUCTDESCR você descobre os campos da estrutura, mas para analisar um campo específico, vai ter que usar a classe para o tipo específico daquele campo. Debugue o exemplo que você vai me entender!

Bom, espero que agora a hierarquia de classes esteja fazendo um pouco mais de sentido para você

Análises em Tabelas

E, por fim, vamos analisar uma tabela interna. Acho que você já sacou que a classe CL_ABAP_TABLEDESCR vai fazer uma análise geral na tabela, mas você vai precisar utilizar a hierarquia de classes para analisar o campos (CL_ABAP_DATADESCR e derivados) de uma linha específica (CL_ABAP_STRUCTDESCR).

DATA: tabela TYPE TABLE OF mara.

DATA: tabledescr  TYPE REF TO cl_abap_tabledescr,
      structdescr TYPE REF TO cl_abap_structdescr.

FIELD-SYMBOLS <key> LIKE LINE OF tabledescr->key.

tabledescr ?= cl_abap_tabledescr=>describe_by_data( tabela ).

* Vamos fuçar na linha da tabela
structdescr ?= tabledescr->get_table_line_type( ).
* Note que o programa faz um downcast do tipo que GET_TABLE_LINE_TYPE retorna para o
* objeto STRUCTDESCR.
* E aqui você pode usar o exemplo de estruturas para fuçar no objeto STRUCTDESCR.
* [insira o código do exemplo anterior aqui]

* Campos da tabela
LOOP AT tabledescr->key ASSIGNING <key> .
  WRITE / sy-tabix.    "Posição do Campo
  WRITE 20 <key>-name. "Números da Mega-Sena (quem sabe assim algúem testa este exemplo!)
ENDLOOP.

* Tem mais um monte de atributos que descrevem outras coisas da tabela
* interna. Explore!

É meu, tô falando… esse tal RTTS é pior que paparazzi na praia de copacabana.

Guarde sua lupa porque por hoje chega pessoal. Espero que os exemplos estejam claros o suficiente para que você possa fazer seus próprios experimentos com as classes do RTTS. Não adianta ficar lendo, tem que executar, testar e estudar!

Abraços a todos aqueles que usam a boina do Sherlock Holmes.