Slides ALV

Prévia do material em texto

ALV
Modelo
Conceito
O Alv (Abap List Viewer) Grid é uma ferramenta flexível para exibição de relatórios comuns ou em formato árvore.
Diferente da exibição de dados via comando WRITE, as funções e métodos existentes para ALV disponibilizam botões que permitem ao usuário manipular os dados (classificar, filtrar e somar), exportar todo o conteúdo do relatório para excel e até mesmo ocultar colunas. 
Além dos botões standards do sistema, é possível criar novos botões conforme a necessidade do usuário.
O Abap List Viewer padroniza e simplifica o uso de listas e relatórios no sistema R/3. Além disso, também fornece interfaces e formatos de lista padronizados para todas as listas e relatórios. 
Pode-se especificar os campos a serem exibidos no relatório e modificar a sequencia em que esses campos são exibidos. Além disso, pode-se ajustar a largura das colunas individuais para atender a requisitos específicos. 
Conceito
O List Viewer permite :
Usar variantes de exibição standard predefinidas pela SAP.
Ordenar os dados: crescente e decrescente.
Definir um filtro.
Exibir somente colunas desejadas.
Formar totais e subtotais.
		Em uma lista, é possível calcular totais e 
		subtotais de uma ou mais colunas selecionadas.
Conceito
Conceito
Exibição de informações detalhadas.
	Pode-se acessar informações detalhadas de 	linhas individuais da lista.
Pesquisa por informações específicas.
		
Impressão do relatório.
Exportação de dados.
Deslocar colunas.
O Alv Grid é formado basicamente por :
			Uma barra de ferramenta
			Um título
			Uma lista de saída.
Prática
Para demonstrarmos na prática o conceito de ALV, demonstraremos 5 tipos mais utilizados.
Em nosso ambiente de treinamento está disponível um programa para cada um dos tipos de ALVs que apresentaremos.
ZTREINA_001 – ALV OO simples
ZTREINA_019 – ALV REUSE LVC (utiliza o ALV OO simples em seu interior)
ZTREINA_020 – ALV REUSE simples
ZTREINA_021 – ALV REUSE em formato lista
ZTREINA_018 – ALV OO Salv Table
Prática
Ao executar a criação de um ALV, primeiramente precisamos validar os requisitos necessários. Por exemplo. Ao construir um relatório simples que exibe dados de materiais. Geralmente não temos materiais o suficiente cadastrados no ambiente para que o relatório gerado seja extremamente custoso em relação à memória e tempo. Ou seja, para casos como estes, não existe necessidade da execução do relatório em Background.
Com esta informação, podemos filtrar quais tipos de ALV são interessantes para nosso desenvolvimento. Por exemplo, como não precisamos contemplar a execução em background, podemos excluir da nossa análise o ALV exemplificado no programa ZTREINA_021 – ALV REUSE em formato lista.
Prática
Após identificar qual tipo de ALV mais se encaixa na necessidade, precisamos iniciar o fluxo de seleção de dados.
Independente de qual ALV será montado, ou como será montado. Todo ALV precisa começar pela sequência de seleção dos dados que serão exibidos, e da montagem destes dados em apenas uma tabela interna.
Podemos executar um select inner join com várias tabelas, ou, dependendo da necessidade, executar alguns selects for all entries, e então, utilizando os comandos LOOP e READ TABLE, executar a leitura e montagem dos dados.
Prática
Todos os relatórios que demonstraremos como exemplo utilizam o mesmo fluxo de seleção e exibirão os mesmos dados. Então, demonstraremos o select e a montagem de dados apenas uma vez, e em seguida demonstraremos cada tipo de ALV que podemos montar com estes dados.
Inicialmente, dividimos o fluxo de construção de dados em etapas. Como nosso relatório é simples, teremos apenas duas etapas, divididas em performs:
Prática
Em relatórios maiores e com mais detalhes, podemos ter performs que executam outras tarefas, como validação de campos na tela, tratamentos de autorização, execução de funções antes ou depois da seleção de dados para buscar parâmetros ou outros dados dos quais nosso fluxo de seleção possa depender.
Prática
A seleção de dados em nosso relatório ficou da seguinte forma:
Prática
O tratamento dos dados ficou da seguinte forma:
Prática
No slide anterior, podemos observar que durante o tratamento, temos o comando APPEND na tabela TG_ALV, que declaramos para ser nossa tabela base para exibição dos ALVs. Os campos que escolhemos para exibir foram os demonstrados abaixo:
Prática
Agora que já possuímos os dados selecionados, temos a base para qualquer ALV. Inclusive, poderíamos exibir os dados utilizando comando WRITE se desejássemos, pois os dados já estão completamente tratados da forma como desejamos.
ALV OO Simples (ZTREINA_001)
Definido pela classe CL_GUI_ALV_GRID. Abaixo podemos visualizar como ficaria o fluxo de exibição para o ALV OO simples:
Observe que abaixo do fluxo que já existia, executamos uma chamada de uma tela auxiliar, exclusiva para o ALV.
ALV OO Simples (ZTREINA_001)
No fluxo da tela que executamos podemos observar que se assemelha a um module pool, pois utilizamos o mesmo conceito:
ALV OO Simples (ZTREINA_001)
No module before output temos a declaração do status e do título da tela, e além disso, temos o tratamento da criação do objeto que exibe o ALV. Este objeto foi declarado como referência à classe CL_GUI_ALV_GRID.
Podemos executar a criação desde objeto em um modulo separado, e isso é extremamente recomendado para o caso de termos um tratamento maior. Como neste caso apenas validamos se o objeto já está criado, executei a validação no próprio modulo do status.
ALV OO Simples (ZTREINA_001)
Nos modules after input executamos os tratamentos de botões padrão. Além disso, podemos executar tratamentos específicos, como por exemplo. O relatório pode ter uma funcionalidade de exibir dados da linha em um formulário SMARTFORMS. Caso o usuário selecione a linha que quer processar, ele pode clicar em um botão extra na tela, que executará esta funcionalidade para ele, e isso é tratado nos modules after input.
ALV OO Simples (ZTREINA_001)
Dentro do modulo status da tela chamada, podemos observar que existe o perform f_exibe_alv. Este perform é o responsável por executar o método que demonstrará o ALV na tela.
ALV OO Simples (ZTREINA_001)
O fluxo do perform para exibir ALV é o seguinte:
ALV OO Simples (ZTREINA_001)
Praticamente todos os tipos de ALV possuem este mesmo fluxo, mudando apenas os métodos e funções que serão chamados. Agora, será definido a utilidade de cada um destes fluxos, e como é o mesmo para praticamente todos os ALV, executaremos esta definição apenas uma vez.
ALV OO Simples (ZTREINA_001)
No trecho de código demonstrado abaixo, definimos o catálogo de campos. Este catálogo define informações sobre cada coluna do relatório. Para executar o preenchimento, devemos transmitir ao menos o nome da tabela interna, o nome do campo que estamos definindo e sua descrição. Chamamos esta definição de fieldcat ou fieldcatalog:
ALV OO Simples (ZTREINA_001)
O perform que preenche o fieldcat no slide anterior possui o seguinte fluxo:
Observe que neste perform alimentamos o valor de 5 campos do fieldcat. O primeiro campo (tabname) representa o nome da tabela interna, o segundo campo (fieldname) o nome do campo declarado no TYPES, o terceiro campo (reptext) representa o texto do título da coluna, o quarto campo (edit) representa um flag, indicando se aquela coluna do relatório pode ou não ser editável, e o quinto campo (do_sum) representa se o campo específico deve ser exibido de forma sumarizada (funciona apenas com campos numéricos).
ALV OO Simples (ZTREINA_001)
Da forma como construímos o fieldcat, este é o resultado do relatório:
ALV OO Simples (ZTREINA_001)
O próximo trecho de código do fluxo de exibição do ALV que demonstraremos é o trecho abaixo:
Este trecho é responsável por preencher o layout do relatório. Existem diversas opções que podemos modificar apenas preenchendo dados na estrutura de layout, porém, os que utilizaremos para este caso são os dois demonstrados acima.
O primeiro campo preenchidodefine se o layout do relatório sairá em forma “zebrada”. Isso significa que o relatório intercalará as cores entre cada linha. No próximo slide podemos visualizar a diferença entre exibir o relatório em forma “zebrada” e não “zebrada”.
ALV OO Simples (ZTREINA_001)
Relatório “zebrado”:
Relatório não “zebrado”:
ALV OO Simples (ZTREINA_001)
A outra opção de layout que utilizamos é um flag que indica se o tamanho das colunas devem ser otimizados de acordo com seus conteúdos ou se devem ser exibidas do tamanho em que foram declaradas, esta opção é definida no flag cwidth_opt (column width optimize).
Lembrando que o tamanho das colunas sempre pode ser modificado manualmente como em uma planilha do excel.
ALV OO Simples (ZTREINA_001)
Relatório com tamanho de colunas otimizado:
Relatório sem tamanho de colunas otimizado:
ALV OO Simples (ZTREINA_001)
O próximo trecho de código do fluxo de exibição do ALV que demonstraremos define variantes para o relatório:
Variantes são layouts de colunas específicas que podem ser salvas para cada relatório. Supondo que um relatório tenha mais de 100 campos, e cada setor da empresa utiliza X campos, então, cada usuário responsável pode salvar uma variante própria para o relatório, para que sempre possa visualizar os campos necessários. Esta opção é habilitada com os dois comandos destacados acima. O flag ‘A’ indica que a variante pode ser salva, e a workarea wl_variant, recebe o nome do programa como parâmetro para executar a busca no repositório de variantes caso o usuário já possua alguma variante salva.
ALV OO Simples (ZTREINA_001)
Botões de layouts caso não seja transmitido o flag i_save = ‘A’:
ALV OO Simples (ZTREINA_001)
Botões de layouts caso seja transmitido o flag i_save = ‘A’:
ALV OO Simples (ZTREINA_001)
Botões de layouts caso não seja transmitido a estrutura is_variant = wl_variant
ALV OO Simples (ZTREINA_001)
E por fim, o trecho final de código:
O método demonstrado acima é responsável por exibir o ALV. O fluxo demonstrado até agora, onde executamos a seleção de dados, preenchimento do fieldcat, preenchimento do layout e da estrutura que indica que podemos salvar as variantes é comum para praticamente todos os tipos de ALVs, modificando apenas o método final que chamaremos. Nestes métodos ou funções, sempre passamos como parâmetros as estruturas de layout, variante e fieldcat, e também passamos a tabela com os dados. No nosso caso, é a TG_ALV.
Diferenças entre ALVs
Como dito anteriormente, temos que definir qual ALV atende melhor nossas necessidades antes de cada desenvolvimento.
Mas se quase todos tem o mesmo fluxo, então qual seria a diferença?
Todos tem suas diferenças principais que são óbvias, e também diferenças simples, que podem facilitar no desenvolvimento. Por exemplo, a principal diferença obvia do ALV OO simples demonstrado nos slides anteriores para alguns outros é que ele não pode ser executado em background da forma como nós construímos ele. Isso já seria um fator de relevância no momento da escolha desde tipo de ALV.
Uma diferença simples que podemos citar é que este ALV que demonstramos pode ser considerado simples de se transformar em um ALV editável, e também é simples de se tratar os dados em cada coluna editável. Já o ALV salv table, que demonstraremos em próximos slides, não pode se tornar editável. 
Este ALV é executado por meio de um módulo de função (REUSE_ALV_GRID_DISPLAY_LVC). É um “facilitador” para utilização do ALV OO simples.
Podemos utilizar as mesmas declarações de tabelas e workareas que utilizamos no ALV OO simples, e passar como parâmetro para o alv reuse LVC. A diferença principal é que não existe a necessidade da criação da tela, então, nosso fluxo de exibição ficará da seguinte forma:
ALV REUSE LVC (ZTREINA_019)
Repare que ao invés da chamada de uma tela, existe um terceiro perform responsável por exibir o ALV:
Este perform possui exatamente o mesmo fluxo, apenas substituindo o método de exibição pelo módulo de função:
ALV REUSE LVC (ZTREINA_019 )
Outro facilitador do REUSE LVC é que, caso não seja executada a criação de botões customizados na tela, este modulo de função tem seu próprio tratamento de botões. Eliminando a necessidade de criar um status de tela e criação de modules para tratamento de botões.
ALV REUSE LVC (ZTREINA_019 )
O próximo ALV que mencionaremos é o alv REUSE simples. Chamado pela função REUSE_ALV_GRID_DISPLAY.
Este ALV é uma alternativa ao ALV OO. Em questão de execução, suas diferenças são pouquíssimas, porém, a construção deste ALV utiliza estruturas com tipos completamente diferentes.
Mesmo possuindo tipos diferentes, o fluxo é exatamente o mesmo. Por exemplo, a tabela que armazena o fieldcat nos ALVs LVC (OO e REUSE) possui o tipo lvc_t_fcat, enquanto no ALV REUSE simples, possui o tipo slis_fieldcat_alv.
Observe as diferenças nas declarações.
ALV REUSE simples (ZTREINA_020)
ALV LVC (OO simples e REUSE LVC)
ALV REUSE simples (ZTREINA_020)
ALV REUSE Simples
Observe que para o REUSE Simples é necessário declarar um TYPE-POOLS, que armazena os tipos de workareas necessários pra este tipo de ALV
Já o fluxo de exibição de dados ainda é o mesmo:
ALV REUSE simples (ZTREINA_020)
E o fluxo da chamada da função que exibe o ALV também é o mesmo:
ALV REUSE simples (ZTREINA_020)
Este ALV executa praticamente as mesmas funcionalidades que o ALV REUSE Simples demonstrado anteriormente, porém, diferente do REUSE simples, este pode ser executado em background. A função chamada para executar este ALV é REUSE_ALV_LIST_DISPLAY.
Caso estejamos utilizando o ALV REUSE e o programa esteja sendo chamado em background, então a variável sy-batch estará preenchida com X. Podemos validar isso para que, ao invés de chamarmos a função original do ALV REUSE simples, podemos apenas chamar esta função, e poderemos executar em background normalmente.
ALV REUSE em formato lista (ZTREINA_021)
O fluxo de exibição de dados ainda é o mesmo:
ALV REUSE em formato lista (ZTREINA_021)
E o fluxo da chamada da função que exibe o ALV também é o mesmo:
ALV REUSE em formato lista (ZTREINA_021)
Comparação entre ALV REUSE Simples e ALV REUSE em formato lista
ALV REUSE Simples
ALV REUSE em formato lista
Este ALV é executado CL_SALV_TABLE. É o ALV que possui o fluxo menos semelhante a todos os outros ALVs anteriores. Este ALV não pode ser modificado para editável, e uma de suas vantagens é que pode ser executado em background normalmente.
Seu fluxo de seleção e exibição de dados é igual a qualquer outro ALV:
ALV Salv Table (ZTREINA_018)
Sua principal diferença é a forma com quem executamos a chamada do método de exibição. Este ALV não precisa de fieldcat. A classe de exibição busca o fieldcat da própria declaração dos campos da tabela. Por isso para este tipo de ALV é bem importante declarar os campos da tabela com um tipo que venha do dicionário de dados, e não tipos primitivos, como “TYPE I” ou “TYPE P LENGTH 3”.
ALV Salv Table (ZTREINA_018)
Todo o código necessário para apenas exibir o ALV Salv Table da maneira mais simples possível é o código abaixo:
ALV Salv Table (ZTREINA_018)
Caso o ALV Salv Table seja exibido exatamente da forma como foi demonstrado no slide anterior, funcionará perfeitamente, porém, a tela não terá nenhum botão, e nenhuma funcionalidade extra será definida. Observe o resultado da exibição:
ALV Salv Table (ZTREINA_018)
Para sanar este problema, executamos métodos derivados da classe CL_SALV_TABLE que executam funcionalidades diferentes cara cada necessidade que temos. No próximo slide veremos alguns exemplos que utilizamos no programa ZTREINA_018.
ALV Salv Table (ZTREINA_018)
ALV Salv Table (ZTREINA_018)
Resultado final após exibição do relatório com os métodos utilizando as funcionalidades extras:
ALV Salv Table (ZTREINA_018)
Obrigado!