Quando eu explico tratamento de exceção na academia ABAP, o pessoal não dá muita bola, até porque os alunos ainda estão tentando se recuperar das aulas de polimorfismo e interface, mas entender o funcionamento dela é vital para desenvolver boas soluções usando orientação a objetos (não somente para aprender a escrever a palavra exceção).

Nesse post, vou explicar dois conceitos ligado ao tratamento de exceções baseado em classes, propagação e comando CLEANUP.

Começando Pelo Básico

Vamos entender primeiro o funcionamento básico do tratamento de exceções baseado em classes. Quando usamos as classes de exceção, devemos usar a estrutura de comandos TRY-CATCH-CLEANUP.

Usarei a classe LCL_EXCEPTION_DEMO que está no include ZABAP101_EXCEPTION_CLASSES nos programas de exemplo.

O primeiro programa que mostrarei é um programa cuja saída é … um DUMP!? Sim, quando o sistema chega a alguma situação onde ele não consegue seguir com o programa, como por exemplo uma divisão por zero.

Quando o programa tenta fazer uma divisão por zero a seguinte tela é mostrada. Toda a pilha de execução é eliminada e toda a memória usada pelo programa é apagada.

Mas graças ao tratamento de exceção por classes, você pode dizer para o sistema “tente executar essa operação, e se caso aconteça divisão por zero, execute isso”.

Nesse primeiro programa onde o DUMP é evitado, o método SIMPLE_CATCH( ) é chamado. Na implementação do método, ele tenta (TRY) executar uma divisão por zero, que é tratada (CATCH) dentro do próprio método.

Repare que a a exceção é tratada dentro do próprio método, portanto a mensagem “Executou o CATCH do método SIMPLE_CATCH.” é impressa no lugar do DUMP. A saída do programa acima é mostrada abaixo:

Propagação de Exceção

Conheço muitas equipes onde esse conceito é muito bem difundido, ou seja, uma pessoa decide não ser responsável pelo erro que cometeu e decide passar o erro para outra pessoa corrigir. Pois é, no ABAP temos algo parecido. Veja esse programa:

Quando o método PROPAGATING( ) é chamado, uma divisão por zero é executada. Observe que esta divisão não está sendo tratada com o TRY-CATCH e veja a saída do programa:

O segredo está na declaração do método: “METHODS propagating RAISING cx_sy_zerodivide.” Existe uma instrução RAISING que diz exatamente o que algumas pessoas que conheço fazem, “olha, pode ser que uma divisão por zero aconteça e se isso acontecer você [quem está chamando o método] deverá tratar essa exceção”.

Sendo assim, a exceção precisou ser tratada na chamada do método e não mais dentro do método.

Qual forma usar, a do primeiro programa ou essa? Depende. Se você quer passar a responsabilidade do tratamento para quem chama o método então o segundo programa deve ser usado. Mas se o erro é algo interno do método e precisa ser tratado de maneira transparente do usuário, então você deverá tratar a exceção dentro do próprio método, assim como fora feito no primeiro programa.

O que acontece se não tratarmos a exceção na chamada do método? Experimente…

CLEANUP não é WHEN OTHERS do Tratamento de Exceções

Essa é a primeira conclusão que os meus alunos chegam quando olham para definição do comando no Help do ABAP.

Não, o CLEANUP não é uma espécie de WHEN OTHERS do TRY-CATCH. Para ilustrar o uso do CLEANUP, veja o programa abaixo:

O objetivo do CLEANUP é para a limpeza de variáveis (memória) quando acontece uma exceção que será propagada. Seria o equivalente ao “quero limpar a bagunça antes de passar a exceção para ser tratada por quem chamou o método”. Pela saída do programa, você consegue entender a sequência de execução do programa. Ocorre a exceção, o CLEANUP é executado e então o CATCH no programa principal.

CLEANUP Morto

O CLEANUP somente é usado para “limpar a bagunça” quando a exceção está sendo propagada. No programa abaixo, o CLEANUP nunca será chamado.

Na saída do programa vemos claramente que o sistema não executou o CLEANUP, pois a divisão por zero é tratada dentro do próprio método.

Conclusão

Os conceitos de tratamento de exceção por classes não fica somente nisso, mas nesse post quis apenas expor os conceitos de propagação e CLEANUP. Para o uso correto de classes de exceções, é necessário entender encadeamento de exceções, hierarquia de exceções e textos da exceção. Isso será explorado em futuros posts.

Aprenda a usar corretamente as classes de exceções e você entregará programas muito elegantes e de fácil manutenção.

Semana passada, mais especificamento no dia 12 de Abril tive a oportunidade de participar do SAP Inside Track Vancouver 2012. Gostaria de compartilhar detalhes do evento já que este evento também ocorre no Brasil.

Para quem não sabe o SAP Inside Track é um evento aberto a comunidade e gratuito. Ano passado, participamos do evento realizado em São Paulo e em São Leopoldo. Nele são apresentados novas tecnologias, tendências de mercado, demonstrações de produtos e outras atividades bem interessantes. No caso do evento em Vancouver, o tema foi mobilidade. Como o número de vagas é limitado, não hesitei quando li na SDN o anúncio do evento, 2 meses antes do mesmo. Sugiro o mesmo caso queira participar do evento no Brasil. Por isso, fique sempre ligado na SDN e leia os newsletters.

Registro

Ao fazer o registro, recebi um ticket virtual no EventBrite em forma de QR Code. Para entrar no evento, bastei apenas mostrá-lo a partir do meu celular. A questão da mobilidade já estava presente antes de entrar no prédio da SAP, mostrado na imagem abaixo. Ainda na entrada foram distribuídas senhas para usar a rede wireless durante o evento, algo que seria muito importante.

Abertura e Quebra-Gelo

Como de praxe, durante a abertura do evento foi mencionada a nova SCN e a importância da mesma. Alguns números bem surpreendentes quanto a comunidade foram mostrados para demonstrar sua importância. Após isso houve uma atividade quebra-gelo que foi uma excelente oportunidade para fazer networking com os demais participantes. Foi nos dado uma espécie de cartela de bingo e canetas. Em cada quadrado da cartela havia uma afirmação referente a diversos assuntos (estilo de vida, esportes, vida profissional, hobbies, gostos etc). A atividade consistia em colecionar assinaturas dos participantes que tinham alguma das afirmações na cartela como verdade. Por exemplo, um dos quadrados continha a frase “Prefiro Pepsi a Coca-Cola”. Os primeiros a completar a cartela ganhariam algumas camisas, os primeiros prêmios dos muitos que foram distruibuídos. Após 30 minutos eu estava carregado de cartões de contato e tinha conversado não só com pessoas que trabalham na SAP, mas também com consultores, responsáveis em empresas sem fins lucrativos, estudantes etc. Esta com certeza uma das grandes vantagens de participar de qualquer tipo de evento: conhecer pessoas.

Palestras

As palestras (veja a lista na página da SCN sobre o SAP Inside Track Vancouver) foram bem voltadas ao mercado. Nada muito técnico foi abordado e siglas diversas foram distribuídas, algo que para alguém que não trabalha com mobile como eu, faz você se perder sobre o assunto. De toda maneira, as palestras foram dadas por pessoas que encabeçam assuntos relacionados com mobile dentro da SAP. Algo que merece destaque foi uma demonstração ao vivo do Afaria durante uma das palestras usando celulares dos participantes.

Demo Jam

O que para muitos é o ápice do evento, o Demo Jam foi marcado por muitos risos e descontração. Nele participantes (a maioria funcionário da SAP – apesar de ser aberto para qualquer um no evento) demonstraram seu trabalho usando tecnologias relacionadas com mobile. Foi interessante ver que um dos participantes que não tem formação em TI e não trabalha em um departamento técnico apresentou um trabalho bem interessante para localizar bebedouros em Vancouver usando o GPS. Cada um teve 5 minutos para apresentar seu trabalho e no final a votação para decidir o vencedor foi realizada pelo público, para variar, usando celulares e smartphones. O vencedor tinha que escolher seu prêmio entre um blackberry ou um playbook.

Prêmios e Brindes

No fim, uma grande quantidade de brindes foi sorteada. Todos os brindes tinham uma relação com mobile indo desde a ipod nanos e shuffes até luvas especiais para usar telas touch screen. Fui sorteado e acabei ganhando um case para playbook.

Patrocínio + Desconto

O evento foi patrocinado pela SAP Press. Foram distribuídos panfletos que continham cupons de 10% desconto para livros na SAP Press validos até o dia 30 de Abril. Você também pode utilizar o cupon para a compra de qualquer livro na SAP Press. Para isso basta apenas usar o código SITVAN12 ao fazer checkout da sua compra.

Participe!

Reforço a importância e os benefícios do evento. Se você tiver a oportunidade de participar de um evento como o SAP Inside Track, não fique de fora.

Veja algumas fotos do evento aqui.

O que é um programa ABAP orientado a objetos? Se um programa usa somente CALL METHOD e nenhum PERFORM, então trata-se de um programa orientado a objetos? Acredito que não.

O uso de sintaxe de orientação a objetos não é evidência suficiente de que o programa foi pensado na forma de objetos trocando mensagens entre si.

Trago para vocês dois pogramas com saídas idênticas, mas um usando uma “orientação a objetos” capenga e outro que considero uma melhor forma de resolver o problema pensando em objetos.

O Requisito

Relatório de impressão de pedidos, com um total e a porcentagem de cada item em relação ao total do pedido. Os itens do pedido foram criados no próprio programa por uma questão prática e didática. No mundo real esses dados estariam armazenados numa tabela no banco de dados.

Orientação a Objetos “para inglês ver”

A listagem abaixo é a solução usando orientação a objetos incompleta, ou seja, o programa tem uma classe para os objetos que representam itens do pedido. Cada objeto é um item do pedido, mas ainda tem alguns problemas.

ZFAKE_OO

Qual o problema com esse programa? Minha crítica a esse programa é a presença de regras de negócio no programa principal. É no programa principal que o cálculo do total do pedido é feito bem como o cálculo do percentual de cada item em relação ao pedido total. Se seguirmos o padrão MVC, esses cálculos deveriam estar encapsulados em alguma classe, fazendo o papel do Modelo. É exatamente isso que o próxima solução leva em conta na hora de refatorar o código.

Refatorando Para Melhorar o Código

Refatoração é um conceito no desenvolvimento de software onde melhoramos o projeto de software sem alterar os requistos do mesmo. Ou seja, vou alterar o programa para que a solução fique mais robusta, elegante, melhorando a legibilidade e possibilitando o reuso. Nessa primeira rodada de refatoração, eu procurei encapsular todos os cálculos em classes, para que possam ser reutilizadas em futuros desenvolvimentos. Repare que eu criei uma nova classe onde os cálculos são executados e o próprio relatório é impresso.

ZBETTER_OO

Próximos Passos

Esse é a melhor implementação? Com certeza não. Escolhi não aplicar o MVC de maneira forte para dar chances para vocês pensarem em outras melhorias possíveis nesse programa.

O que vocês fariam? Deixem nos comentários quais melhorias vocês fariam nos dois programas.

Boa diversão!

Saídas dos Dois Programas Acima

Então você já aprendeu como declarar uma classe, chamar um método e aplicar os conceitos de herança e polimorfismo (já né?). Parabéns você completou a primeira parte do aprendizado em programação orientada a objetos. Agora só falta mais uns 95% para poder ser considerado um Mestre Jedi em Orientação a Objetos.

Vamos ganhar mais um ponto porcentual e falarmos de Singleton.

Singleton é um Padrão de Projeto (ou do inglês Design Patern). Os padrões de projetos tem como objetivo o reuso do projeto (não de código). É o reuso de uma solução para um problema simples e comum dentro da programação orientada a objetos.

O problema do Singleton resolve é muito simples: criar uma classe que permita uma e somente uma instância da classe em questão.

Vamos discutir abaixo a solução clássica em ABAP.

Gist: https://gist.github.com/2174007

Descrevendo a Classe

A classe em que será aplicada o Singleton é a LCL_HELLO_SINGLETON. Vamos começar com a declaração dela pois ela já nos trás algumas novidades:

CLASS lcl_hello_singleton DEFINITION FINAL CREATE PRIVATE.

A classe precisa necessariamente ser final, ou seja, ela não aceitará que nenhuma outra classe herde dela. Não é possível criar uma subclass da LCL_HELLO_SINGLETON, pois isso seria uma brecha onde o usuário criaria uma subclasse e que não respeitaria a regra de não permitir mais de uma instância dela.

A classe LCL_HELLO_SINGLETON também deve ter a sua regra de instanciação como privada. Isso significa que um objeto dessa classe somente pode ser criado dentro dela mesma. Isso garante o controle da criação dos objetos seja somente dela mesma. Nossa pequena classe é dona de seu próprio destino.

A segunda característica dessa classe é a presença de um construtor estático (método CLASS_CONSTRUCTOR). Um construtor estático é chamado apenas uma única vez durante toda a vida da classe. Ele difere do construtor da instância (método CONSTRUCTOR – não usado nesse exemplo) por ser chamado apenas uma única vez quando a classe é usada pela primeira vez (seja na criação de um objeto ou na chamada de um método estático – usado no exemplo). Um construtor de instância é chamado no momento da criação do objeto com o comando CREATE OBJECT.

O método estático GET_INSTANCE( ) é usado para retornar o valor que está no atributo estático R_INSTANCE, que é a referência do único objeto criado para essa classe.

O único objeto a existir para a classe LCL_HELLO_SINGLETON é criado no construtor estático e a sua referência é o R_INSTANCE.

Os métodos SET( ) e GET( ) são os chamados métodos de acessores, que servem para definir e retornar os atributos da classe, respectivamente.

Executando o Programa

Ao executar o programa, precisamos chamar o método estático GET_INSTANCE( ) para que a classe nos retorne a referência do objeto que ela mesma criou e está gerenciando. Mas nesse instante o objeto ainda não fora criado?! Erro na implementação do Padrão de Projeto!!! Calma…

A criação do objeto está no construtor estático que será chamado apenas uma única vez, quando a classe for usada. Sendo assim, quando chamarmos o método GET_INSTANCE( ) o construtor estático é chamado primeiro criando o objeto a ser retornado pelo parâmetro RE_INSTANCE( ). Genial? Não, programação orientada a objetos.

Agora todas as vezes que o programa precisar usar recuperar a referência do objeto filho único, ele deve chamar o método GET_INSTANCE( ).

Conclusão

Quando devemos usar um Singleton? A resposta é simples, economia de memória. Fato que um mesmo volume de dados representado em objetos pode consumir mais memória do que o seu equivalente em procedural, para uma boa ilustração disso, veja o post onde o Fábio fez uma comparação de consumo de memória entre uma tabela interna e os mesmos dados dessa tabela interna usando um objeto para cada linha da tabela.

Em geral, um programa ABAP manipulará os dados de duas maneiras, um Objeto de Negócio por vez, ou um conjunto de objetos por vez.

Em nossa vida de programador ABAP não é lá muito comum trabalharmos um objeto de negócio por vez, pois os programas standard já fazem isso. Geralmente trabalhamos um registro por vez quando estamos desenvolvendo algum module pool e os modules pools mais legais já foram feitos pela SAP.

A Claudia já comentou isso e é verdade, a maioria dos nossos programas são relatórios. E quando trabalharmos com relatórios invariavelmente seguimos a sequência, tela de seleção – seleção de dados – tratamento dos dados – apresentação dos dados. Então, quando estamos tratando os dados fazemos um LOOP AT na tabela interna e para cada registro a ser tratado usamos as regras de negócio encapsuladas nos métodos dessa classe. Portanto, não precisamos de todos os objetos criados ao mesmo tempo, apenas uma instância de nossa classe, sendo atualizada para cada registro a ser tratado.

Sem dúvida, uma das atividades mais realizadas por um programador ABAP é a emissão de relatórios.

Como não estamos na era dos dinossauros, “não conhecemos” o relatório “write” e vamos direto aos “ALV’s”.

Este post tem como objetivo exemplificar algumas funcionalidades de um ALV OO (Orientado a Objetos),  são elas:

• Exclusão de botões do toolbar de um ALV OO
• Inclusão de botões no toolbar do ALV
• Utilização de eventos
• Como desabilitar um botão (ele aparece, mas não é possível clicar)
• Geração de um ALV sem necessidade de criação de um container

Veja também:

• Como encontrar ícones
• Utilização de interfaces

A modelagem utilizada, foi construída de forma a permitir a utilização dos pontos acima citados.

Especificação

Na tela de seleção, o usuário poderá determinar uma ou mais cias aéreas.  Deve ser gerado um relatório ALV com os dados desta(s) cia(s), a serem extraídos da tabela SCARR.

Neste relatório, ao selecionar uma determinada cia, deve haver um botão que gere um segundo ALV, desta vez exibindo as informações dos vôos (conexões) referentes à seleção realizada (dados a serem extraídos da tabela SPFLI).

E então, vamos ao que interessa!?

No programa principal, devemos criar a tela de seleção e um include, onde codificaremos nossas classes.

Tela de seleção:

Declara-se o select-options para possibilitar a determinação do range das cias aéreas:

include: z_classes.
 
tables: scarr,
        spfli.
 
data: wa_scarr type scarr.
 
data: r_companies type ref to lcl_companies.
 
selection-screen begin of block filter with frame title text-001.
select-options s_carrid for wa_scarr-carrid.
selection-screen end of block filter.

Selection Screen

Vamos criar também, duas telas (as quais nomeei de “0100″ e “0200″, que serão utilizadas na exibição dos ALV’s.

Screens

No include criado, segue declaração da interface:

interface: zif_data_reader.
  types: ty_scarr type range of scarr-carrid.
 
  methods: read_data
              importing
                im_scarr type ty_scarr,
 
           generate_alv
              importing
                im_structure  type char30.
 
endinterface.             "zif_data_reader

Observe que temos os métodos read_data e generate_alv, que foram declarados na interface, porque serão utilizados em ambos os relatórios.

Agora vamos à definição da classe lcl_companies, que será responsável pela leitura dos dados das cias aéreas.

*----------------------------------------------------------------------*
*       CLASS lcl_companies DEFINITION
*----------------------------------------------------------------------*
*
*----------------------------------------------------------------------*
class lcl_companies definition.
  public section.
    interfaces zif_data_reader.
 
    methods: constructor,
 
             set_toolbar
                for event toolbar of cl_gui_alv_grid
                importing e_object,
 
             get_ucomm
                for event user_command of cl_gui_alv_grid
                importing e_ucomm,
 
             refresh_table
                for event after_user_command
                of cl_gui_alv_grid.
 
  private section.
    data: r_grid        type ref to cl_gui_alv_grid,
          r_connections type ref to lcl_connections.
 
    data: gt_scarr      type table of scarr,
          gt_exc_button type ui_functions.
 
endclass.                                "lcl_companies DEFINITION

Observe que a classe tem como atributos privados:

• Objeto r_grid (para criação do grid do alv)
• Objeto r_connections para referência e criação dos objetos referentes aos vôos (conexões)
• Tabela gt_scarr, contendo as informações da(s) cia(s) aérea;
• Tabela de botões a serem excluídos

Através da keyword “INTERFACES”, declaramos a utilização da interface zif_data_reader, com isso, na classe lcl_companies devemos implementar todos os métodos contemplados na interface.

Seguem Implementações:

• Constructor: será responsável pela criação do grid do alv, registrar os eventos a serem utilizados e determinar os botões a serem excluídos.

method: constructor.
    create object r_grid
      exporting
        i_parent          = cl_gui_container=>screen0
      exceptions
        error_cntl_create = 1
        error_cntl_init   = 2
        error_cntl_link   = 3
        error_dp_create   = 4
        others            = 5.
 
    if sy-subrc ne 0.
      message id sy-msgid type sy-msgty number sy-msgno
                 with sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4.
    endif.
 
*--------------------------------------------------------------------*
* Registra os eventos a serem utilizados
*--------------------------------------------------------------------*
    set handler get_ucomm     for r_grid.
    set handler set_toolbar   for r_grid.
    set handler refresh_table for r_grid.
*--------------------------------------------------------------------*
* Informa os botões a serem excluídos
*--------------------------------------------------------------------*
    append cl_gui_alv_grid=>mc_fc_graph to gt_exc_button.
 
  endmethod.                              "constructor

Nota: quando informamos “cl_gui_container=>screen0″ no parâmetro “i_parent” não temos a necessidade de declarar um container (recomenda-se gerar o ALV sem container apenas em casos de real necessidade, pois esteticamente o programa será prejudicado, visto que o ALV ocupará a tela inteira).

Para entender melhor, vá até a transação SE24, na classe CL_GUI_ALV_GRID.

Na aba “métodos” você encontrará o “constructor”, clique em “Parâmetros” e verá que o parâmetro “i_parent” é do tipo “CL_GUI_CONTAINER”.

Parameter - "I_PARENT"

Clicando em CL_GUI_CONTAINER, na aba atributos, você encontrará “Screen0″.

Attribute - Screen0

Ou seja, o atributo “Screen0″ utiliza a tela como nosso container.

Entendendo a exclusão de botões

Novamente na transação SE24, consulte o método “SET_TABLE_FOR_FIRST_DISPLAY”.

Ao clicar em “parâmetros” você encontrará o “IT_TOOLBAR_EXCLUDING”, de tipo “UI_FUNCTIONS”.

Parameter - toolbar_excluding

Vamos agora para a aba de atributos da classe, onde encontraremos os botões.

CL_GUI_ALV_GRID - Botões

Desta forma, basta inserirmos os botões a serem excluídos na tabela declarada, e informá-la no momento em que chamarmos o método “SET_TABLE_FOR_FIRST_DISPLAY” (neste exercício, excluí apenas o botão utilizado para geração de gráficos).

O próximo passo é selecionarmos os dados da tabela SCARR conforme dados da tela de seleção.

• zif_data_reader~read_data

Observe que quando implementamos um método de uma interface, este é denominado: nome_da_interface~nome_ do_ método.

method: zif_data_reader~read_data.
 
      clear gt_scarr.
    refresh gt_scarr.
 
    select *
      from scarr
      into table gt_scarr
      where carrid in im_scarr[].
 
    if sy-subrc ne 0.
      message: text-002 type 'E'.
 
    else.
      call method me->zif_data_reader~generate_alv
        exporting
          im_structure = 'SCARR'.
    endif.
  endmethod.                               "zif_data_reader~read_data

Neste método, selecionamos os dados conforme critérios informados na tela de seleção.

Quando sy-subrc não é “0″ (valores não encontrados), exibimos uma mensagem de erro, caso contrário, chamamos o  método “zif_data_reader~generate_alv”, vide implementação abaixo:

method: zif_data_reader~generate_alv.
 
    call method r_grid->set_table_for_first_display
      exporting
        i_structure_name              = im_structure
        it_toolbar_excluding          = gt_exc_button
      changing
        it_outtab                     = gt_scarr
      exceptions
        invalid_parameter_combination = 1
        program_error                 = 2
        too_many_lines                = 3
        others                        = 4.
 
    if sy-subrc NE 0.
      message id sy-msgid type sy-msgty number sy-msgno
                 with sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4.
    endif.
 
    call screen 100.
  endmethod.                               "zif_data_reader~generate_alv

Com os dados selecionados e exibidos na tela, precisamos incluir o botão para visualizarmos as conexões das cias aéreas.

• set_toolbar - será chamado cada vez que o evento “TOOLBAR” (registrado no constructor!) for disparado pela classe CL_GUI_ALV_GRID.

Consultando os parâmetros deste evento, na transação SE24, podemos verificar que ele exporta o parâmetro “E_OBJECT”, de tipo  “CL_ALV_EVENT_TOOLBAR_SET”.

Nos atributos desta classe, encontraremos o “MT_TOOLBAR”, de tipo “TTB_BUTTON”, finalmente tipo “STB_BUTTON”, onde estão as informações que precisamos.

Veja a implementação do método “set_toolbar”:

method: set_toolbar.
    data: wa_toolbar type stb_button.
    case sy-dynnr.
      when '1000'.
 
        clear wa_toolbar.
        wa_toolbar-butn_type = 3.               "Separador
        append wa_toolbar to e_object->mt_toolbar.
 
        clear wa_toolbar.
        wa_toolbar-function  = '100_CONN'.
        wa_toolbar-icon      = icon_object_folder.
        wa_toolbar-quickinfo = 'Visualiza Conexões'.
        wa_toolbar-butn_type = 0.              "Botão Normal
        wa_toolbar-text      = 'Visualizar Conexões'.
        append wa_toolbar to e_object->mt_toolbar.
 
      when '0100'.
        clear wa_toolbar.
        wa_toolbar-butn_type = 3.              "Separador
        append wa_toolbar to e_object->mt_toolbar.
 
        clear wa_toolbar.
        wa_toolbar-function    = '100_CONN'.
        wa_toolbar-icon        = icon_object_folder.
        wa_toolbar-quickinfo   = 'Visualiza Conexões'.
        wa_toolbar-butn_type   = 0.              "Botão normal
        wa_toolbar-text        = 'Visualizar Conexões'.
        if sy-ucomm            = 'BACK'.
          wa_toolbar-disabled  = ' '.
        else.
          wa_toolbar-disabled  = 'X'.
        endif.
        append wa_toolbar to e_object->mt_toolbar.
      when others.
    endcase.
 
  endmethod.                                 "set_toolbar

Observe que temos duas tratativa diferentes para o botão: quando estamos na tela 1000 (chamando a tela 0100, que contém os dados das cias aéreas), quando deve estar habilitado, e quando estamos na tela 0100 (chamando a tela 0200, que conterá os dados das conexões), quando o botão deve estar desabilitado.

Para melhor compreensão, faça este exercício, coloque um BREAK-POINT no método e debugue! Assim você entenderá os momentos em que ele é chamado e sua tratativa!

Dica: lembre-se de utilizar text-symbols. Na implementação acima, escrevi as informações diretamente no código para facilitar o entendimento!

Nota: informamos o ícone: icon_object_folder, este nome é encontrado na tabela “ICON”, porém, algumas vezes precisamos do parâmetro “internal” quando trabalhamos com ícones. Este pode ser encontrado no programa “SHOWICON”.

• get_ucomm – é através deste que nosso botão funcionará:

method: get_ucomm.
    data: lv_row   type lvc_s_row,
          wa_scarr like line of gt_scarr.
 
    data: r_cias  type range of scarr-carrid,
          wa_cias like line of r_cias.
 
    if e_ucomm eq '100_CONN'.
      call method r_grid->get_current_cell
        importing
          es_row_id = lv_row.
 
*--------------------------------------------------------------------*
      if lv_row is initial.
        message: text-003 type 'I'.
*--------------------------------------------------------------------*
      else.
        read table gt_scarr into wa_scarr index lv_row-index.
 
        clear wa_cias.
        wa_cias-sign    = 'I'.
        wa_cias-option  = 'EQ'.
        wa_cias-low     = wa_scarr-carrid.
*        wa_cias-high   = ' ' .
        append wa_cias to r_cias.
 
        create object r_connections
          exporting
            im_grid = r_grid.
 
        call method r_connections->zif_data_reader~read_data
          exporting
            im_scarr = r_cias.
*--------------------------------------------------------------------*
      endif.
    endif.
  endmethod.                             "get_ucomm

Lembrando que este método será chamado cada vez que o evento “user_command” for disparado (conforme sua declaração), devemos verificar se o “sy-ucomm” é “100_CONN”, ou seja, se nosso botão foi “clicado”.

Com isso, chamamos o método get_current_cel para verificarmos qual foi a linha selecionada.

Verificamos em nossa tabela qual é  cia aérea referente a linha selecionada, para então criarmos o objeto referente à classe das conexões e ler seus dados.

Observe que utilizamos o range r_cias para informar a cia aérea. O range é como se fosse o select-options, por isso precisamos informar:

• sign      = “I” (Include)
• Option = “EQ” (Equal, porque informaremos uma única cia aérea.
• Low      = wa_scarr-carrid (cia aérea da linha selecionada).
• High    = Não precisamos informar, pois utilizamos “option = EQ”.

Para a classe lcl_companies, ainda precisamos implementar o método:

• refresh_table:

method refresh_table.
 
    check sy-dynnr = 100 and
          sy-ucomm = 'BACK'.
 
    call method me->zif_data_reader~generate_alv
      exporting
        im_structure = 'SCARR'.
 
  endmethod.                              "refresh_table

Este método será chamado após o user_command.

É necessário para atualizar as informações do grid quando voltamos da tela 200 para a tela 100. Sem ele, os dados das conexões permanecem na tela.

Para melhor compreensão, debugue!

Finalmente, vamos à declaração da classe “lcl_connections”.

*----------------------------------------------------------------------*
*       CLASS lcl_connections DEFINITION
*----------------------------------------------------------------------*
*
*----------------------------------------------------------------------*
class lcl_connections definition.
  public section.
    interfaces: zif_data_reader.
 
    methods: constructor
                importing
                  im_grid type ref to cl_gui_alv_grid.
 
  private section.
    data: gt_spfli       type standard table of spfli,
          gt_exc_button  type ui_functions,
          gv_carrid      type scarr-carrid.
 
    data: r_grid_conn type ref to cl_gui_alv_grid.
 
endclass.                              "lcl_connections DEFINITION

Como podem ver, esta é uma classe bem simples. Verifiquem sua implementação:

class lcl_connections implementation.
  method: constructor.
    r_grid_conn = im_grid.
  endmethod.                              "constructor
 
  method: zif_data_reader~read_data.
    clear   gt_spfli.
    refresh gt_spfli.
 
    select *
      from spfli
      into table gt_spfli
      where carrid in im_scarr.
 
    if sy-subrc = 0.
      call method me->zif_data_reader~generate_alv
        exporting
          im_structure = 'SPFLI'.
    else.
      message: text-004 type 'I'.
    endif.
 
  endmethod.                    "zif_data_reader~read_data
 
  method: zif_data_reader~generate_alv.
    data: wa_exclude like line of gt_exc_button.
 
    call method r_grid_conn->set_table_for_first_display
      exporting
        i_structure_name              = im_structure
      changing
        it_outtab                     = gt_spfli
      exceptions
        invalid_parameter_combination = 1
        program_error                 = 2
        too_many_lines                = 3
        others                        = 4.
 
    call screen 200.
 
  endmethod.                    "zif_data_reader~generate_alv
 
endclass.

Observe que o constructor é responsável apenas por “importar” o grid gerado na classe lcl_companies.

Vejam abaixo o resultado do nosso exercício:

Tela 0100 - Cias aéreas

Tela 0100, com os as informações das cias aéreas e botão habilitado.

Observe que não há o botão responsável pela geração de gráficos.

Tela 0200 - Conexões

Tela 0200, com informações das conexões e botão desabilitado.

E então, gostaram? baixe o código (Z_ALV_OO ), estude e nos envie suas dúvidas e sugestões!

Veja neste post como utilizar o arquivo.

Se você já conhece o ABAP101.com, sabe que uma das nossas principais iniciativas é a inserção de iniciantes no mundo ABAP através de projetos Open Source. Fazemos isso sem custo nenhum e por puro prazer de deixar nosso legado adiante. Se você é novo por aqui, é fácil de entender: temos um processo parecido com uma empresa que procura um profissional de ABAP. Temos um critério de decisão que decidirá quem trabalhará conosco em um dos nossos projetos open source. A partir do momento que a escolha é feita, começamos a trabalhar desde a definição do escopo do projeto até a submissão de uma versão estável do projeto na plataforma Code Exchange da SAP. Saiba mais sobre nossa iniciativa de projetos open source ABAP.

Quando o Furlan e eu estávamos conversando sobre os projetos e seus objetivos ficou claro que nosso objetivo, veja só você, não era apenas ensinar ABAP. Queríamos aproximar o que é ensinado nas academias da KA Solution com o que é vivenciado no dia-a-dia de um ABAPer. Foi então que definimos o conceito dos 5 P’s do ABAP, baseado no Marketing Mix. Continue lendo para entender a definição de cada um dos P’s e entender no que cada um influencia na sua entrada ou na sua boa permanência no mercado de ABAP.

O 5 P’s do ABAP regem a forma de trabalharmos e nos guiam em relação ao que deve ser deixado como legado. Vamos a cada um deles.

1º P – Programação

Este com certeza é o que mais se relaciona com ABAP. Se você quer trabalhar com ABAP, você tem que programar. Se você não sabe programar, entenda o primeiro P como “Prática”. Temos um conjunto de exercícios para quem está começando e já tivemos um campeonato de ABAP que intrigou até os mais experientes. Um bom programador tem que sonhar com código, tem que pensar em código no ônibus e traduzir bem a língua do funcional para a lingua do aplication server. Antes de querer entender o que é um cabeçalho, deve saber usar uma work area e antes de querer entender o que são itens deve saber usar uma tabela interna. Deve gostar de programar a ponto de baixar a versão trial do SAP para instalar e praticar em casa depois de um dia cansativo. Um bom ABAPer deve sempre evitar de fazer um trabalho repetitivo por horas/dias que possa ser substituído por um programa Z. Um bom ABAPer não constrói tudo do zero. Ao invés disso ele sempre que possível usa orientação a objetos de forma a facilitar a reusabilidade do seu código e reutiliza APIs prontas criadas por terceiros. Para aumentar a manutenabilidade de um programa, um bom ABAP vai muito além de simplesmente usar o Pretty Printer e comentar no código a descrição dos componentes de uma estrutura. Um bom ABAPer documenta e evita ao máximo gambiarras. Um bom programador entende e que há vida fora do mundo ABAP. Um bom ABAPer tem a tecla F1 gasta. Um bom ABAPers não somente tem cadastro mas é colaborativo na SDN: não faz perguntas vagas em fóruns, fecha as questões que abriu no fórum e dá a opinião sobre aquilo que lê.

O primeiro P pode parecer trivial a primeira vista, mas não é fácil levá-lo a risca. Além de tudo isso um bom ABAPer gostará de saber os outros 4 P’s.

2º P – Processo

Se você não trabalha com ABAP, você provavelmente não conhece um exemplo de 2º P. Se você já trabalha com ABAP, provavelmente você gostaria de não ter conhecido alguns deles. Processo são as regras que você como ABAPer é pago para seguí-las e não questioná-las ou burlá-las (algo que será discutido no 5º P). Pode parecer cruel ou duro demais, mas é a verdade. Qualquer empresa que tem poder aquisitivo para implementar o SAP deve ter maturidade suficiente para entender a importância de se ter um bom processo. Se as pessoas não seguem um processo, nenhum ERP resolverá os problemas da empresa. Por isso, se no processo da sua empresa a documentação é exigida, você deve fazer a documentação. Se você precisa pedir permissão para realizar algum tipo de atividade, você deve fazê-lo. Processos são tão bons para as empresas que os tem quanto bons para proteger aqueles que evitam “camaradagens e pequenos favores”.

Se você quer participar de um projeto conosco, saiba que temos processos desde como definir o escopo, passando por regras de convenção de código até de submissão de releases. Hoje este tipo de experiência não é vivenciado em faculdades ou academias e queremos trazer isso para fora do ambiente empresarial também pois faz parte da nossa profissão, gostemos ou não.

3º P – Prazo

Se você já trabalhou com SD, pode pular este P. – você entende o que digo. Infelizmente o prazo é geralmente o último dos vértices do triângulo de ferro a ser reajustado. O go/no go geralmente tem uma possibilidade de resposta unária quando se trata de um requesito legal que o governo resolveu pedir para ontem. O prazo pode sim estar contido dentro de um requesito e se você não atender o prazo significa que você não atendeu o cliente. Se você não faz ideia do quanto tempo leva para desenvolver uma solução, codificar um método ou corrigir um dump, não se preocupe desde que você alerte as partes envolvidas  uma melhor estimativa após um tempo de melhor compreensão do problema. Reportar problemas no final do prazo que lhe deram somente gera mais um problema. O prazo faz parte da vida de um ABAPer seja ele júnior ou sênior. Se quem demorou foi o funcional e não você pergunte ao usuário o que ele acha e ele te responderá que a culpa é do pessoal de TI como um todo.

No caso dos nossos projetos open source, sempre existirá prazos previamente negociados. Se você não é capaz de cumprí-los, não se inscreva neles pois outros podem estar dispostos a abdicar mais do que você.

4º P – Pressão

3 da manhã de um sábado. Você chega em casa depois de um bom Happy Hour e recebe uma ligação. Por algum motivo desconhecido um transporte desconhecido subiu até produção e sua empresa parou (parcialmente ou não de funcionar). Como você se sente para debugar um código comentado em alemão? E se disser que não importa se foi sua culpa ou não? A pressão não estará presente só nesses casos extremos (que por sinal o 2º P pode proteger você e sua empresa) mas também em cada objeto customizado que você cria. Se você lida bem com pressão saiba que sempre há uma expectativa em relação a algo que você constrói. E essa expectativa se não atendida pode gerar inúmeros problemas.

Como dito anteriormente, funcionamos de maneira similar a uma empresa. Como qualquer empresa, há um critério de captura de novos integrantes bem como há um critério para  a substituição dos mesmos que não rendem o que é esperado.

5º P – Profissionalismo

Voltando a falar de camaradagem, para que se preocupar com processos chatos, lentos e burros? Afinal, o ABAPer tem alguns jeitos de resolver um problema. “Faz um programinha”, “aproveita essa request aberta”, “ajusta a lógica que depois eu documento”, “inclui um IF aí”, “marreta a tabela” são frases que você provavelmente já ouviu e que as respostas “Sim” medem o quanto o 5º P é valorizado por você.  Pensamentos/argumentos do tipo “isso não foi pedido, então não vou fazer”, “está especificado errado, por isso o programa está errado”, “no cenário sem erros funciona então isso é o que interessa” e “rodei o programa para um registro e funcionou, vamos transportar!” também interferem no resultado do seu 5° P. Guardar informações com você por qualquer forma de receio também contam negativamente neste item. Você compraria um carro que quebrasse no primeiro buraco que passar? Por que fazer gambiarras no código então? O SAP é bem mais caro que muito carro por aí.

Cuidado com sua imagem pois ela pode ser superior a todas as suas habilidades de trabalhar com os outros 4 P’s.

Conclusão

Participando nos projetos open source do ABAP101.com, você tem a oportunidade de trabalhar em cima de cada um destes conceitos, algo que ajuda muito quem está apenas iniciando.

Importante: já recebemos uma boa quantidade de exercícios de leitores que se mostraram interessados e que com certeza irão receber preferência na hora da escolha dos participantes. No momento estamos atualizando nossos projetos existentes no Code Exchange e testando ferramentas que nos ajudarão na hora de submeter e recuperar código da plataforma.

Mais uma vez, queremos ouvir sua opinião: o que você achou dos 5 P’s do ABAP? Qual o mais importante em sua opinião e por quê? Você acha que a participação em projetos open source podem contribuir para a formação de cada um destes conceitos? Contamos com sua resposta!

Abraço5!

Hoje mandamos a primeira newsletter para as pessoas que fizeram sua inscrição para nossos projetos open source em nossa página sobre o assunto.

Todas as novidades relativas aos projetos, seleção dos candidados, situação de cada projeto e muitas outras informações que serão divulgadas apenas pela newsletter.

Caso você tenha interesse em participar de nossos projetos, faça a sua inscrição hoje mesmo. A nova edição será enviada daqui duas semanas, já com a seleção dos participantes dos próximos projetos.

Leia o texto na íntegra nesse link abaixo:
ABAP101 Open Source Projects – Edição 1 – Apresentação dos Projetos

Uma das etapas mais importantes de um projeto, porém muitas vezes ignorada, é a de documentação do mesmo.

Muitas empresas,  desenvolvedores e analistas não tem o hábito de gerar documentação, porém, se forem definidos alguns detalhes (modo de atualização, nível de detalhamento, complexidade) o custo-benefício e tempo investido serão vantajosos.

Podemos considerar a documentação sob duas vertentes: “Documentação de Requisitos” e “Documentação do Programa”. Neste post, vamos analisar a documentação do Programa.

Por exemplo: quantos de vocês já necessitaram refazer / alterar por diversas vezes um programa que no início do projeto não teve seus requisitos bem compreendidos? O fato é que se este levantamento for bem feito e documentado, os riscos de rework, falhas, não atendimento aos prazos propostos, dentre outros, certamente serão minimizados, além de permitir uma visualização global do projeto, facilitando o seu gerenciamento e identificação de melhorias.

Considerando a documentação de programas, podemos citar alguns benefícios, tais como:

Facilidade de manutenção: todos nós sabemos que comumente um programa é desenvolvido por uma pessoa e recebe manutenção por outra (ou outras). Já pararam para pensar em quanto tempo de análise de código e qualidade podemos ganhar caso haja uma documentação bem feita e atualizada?

Transmissão de conhecimentos: muitos não costumam pensar sob a perspectiva que vou expor agora, mas independentemente de sermos contratados direta ou indiretamente por uma empresa, como CLT ou como PJ, somos contratados para gerar lucros e DEVEMOS pensar como empresa. Desta forma, é através da documentação que transmitimos nossos conhecimentos, seja de negócios, seja da parte técnica, a continuidade do projeto não deve depender dos conhecimentos de uma só pessoa.

Re-utilização de API´s: quando bem documentadas podem facilitar muito a rotina de um programador, que pode reutilizar de maneira fácil e rápida trechos de códigos já existentes (como classes e function modules, por exemplo), ganhando em tempo de desenvolvimento, qualidade e padronização de código.

Existem algumas ferramentas para auxiliar na geração de tais documentos, dentre elas, recomendamos o projeto open source ABAPDoc2, que gera as doumentações em HTML (o que possibilita sua análise sem a necessidade de acessar o SAP) e fornece informações sobre a composição de classes e seus métodos, function groups e seus function modules (parâmetros de importação / exportação, tabelas, dentre outros), assim como possibilita a exibição de comentários inseridos no header dos códigos, facilitando o entendimento técnico  e suas funcionalidades.

Este projeto é bastante indicado para documentar outros projetos open source, porém não é aplicável nos casos de documentação de requisitos, pois a necessidade é outra.

E então, prontos para colocar a  mão na massa? Baixe já e conheça o ABAPDoc2.

Uma coisa que não mais iremos discutir aqui no ABAP101 é usar ou não programação orientada a objetos, por isso estamos abolindo procedural do ABAP101, caso você veja alguma coisa procedural aqui no site, por favor avise-me!

Programação procedural pode parecer mais fácil, mas é porque estamos mais acostumados com esse tipo de programação do que orientada a objetos. Tome uma resolução em sua vida ABAPer, faça tudo em ABAP OO, mesmo um simples relatório. Comece com uma simples classe e daí vá evoluindo, mas fuja da “primeira dose” do procedural. Acredite a vida é bem melhor sem procedural!

A orientação a objetos nos permite abstrações muito mais elegantes do que a procedural sendo os programas orientados a objetos muito mais fáceis de fazer manutenção, permitindo reuso real e muitas outras coisas que somente usando no dia-a-dia podemos perceber.

Pensando nisso, criei esse post onde mostro uma série de versões do famoso programa Hello World orientados a objetos. A primeira vez que o programa Hello World em ABAP apareceu por aqui foi em 2007, nesse post aqui. A solução vai crescendo mostrando algumas formas de abstração resolvendo o mesmo problema de várias maneiras possíveis.

Primeira Versão

Nessa versão temos uma classe chamada LCL_HELLO com apenas um único método DISPLAY_MESSAGE( ).

ZP_HELLO_OO

Nessa versão contém apenas uma única classe com um único método. Não temos muito de programação orientada a objetos aqui, mas já estamos deixando a sementinha do OO entrar em nossos programas.

Procedural Orientado a Objetos

Vamos adicionar um parameter em nosso programa e começar a discutir algumas opções de abstração. A primeira opção eu chamo de “Procedural Orientado a Objetos”. Aqui não estamos pensando numa solução orientada a objetos, mas pensando em procedural.

ZP_HELLO_OO_2

Veja que poderíamos substituir perfeitamente por um FORM/PERFORM sem grandes mudanças na abstração, mas lembre-se que queremos evitá-los de qualquer maneira, mesmo assim essa versão é muito melhor que qualquer outra versão procedural.

Melhorando a Impressão da Mensagem

Uma verão mais interessante que eu proporia seria a mostrada abaixo:

ZP_HELLO_OO_3

O resultado é o mesmo, mas agora temos um objeto LCL_HELLO que recebe um nome para saudação na sua construção e daí mostra a mensagem pelo método DISPLAY_MESSAGE( ). Já conseguiu imaginar um objeto que tem a responsabilidade de mostrar uma mensagem na tela?

Permitindo Operações No Objeto LCL_HELLO

Ainda sim não estou contente com a solução. E se quisermos alterar o atributo NAME antes de mostrarmos a mensagem? E se quisermos saber o atributo NAME antes de mostrar para o usuário? Por isso é aconselhável criamos os métodos de acesso, os famosos SET e GET. Veja como ficaria nosso programa:

ZP_HELLO_OO_4

Pense que agora temos um objeto HELLO no qual podemos alterar seu estado (SET e GET) quantas vezes quisermos. A abstração está muito melhor agora, mas dá para melhorar ainda mais!

MVC no Hello World, Pode?

Que história é essa do programa principal verificar se a mensagem é correta ou não!? Esse programa deveria cuidar apenas em receber a entrada do usuário e chamar o objeto para mostrar a mensagem. Não deveria ter nenhuma regra (de negócio). Essa verificação deveria estar no modelo, ou seja, classe LCL_HELLO. Então, vamos melhorar ainda mais o nossa classe:

ZP_HELLO_OO_5

Mesmo que algum Perform Fanboy invada seu programa na calada da noite, você já contará com uma certa proteção dentro do seu programa contra maus programadores terá protegido seu programa (já que ele não saberia alterar a classe :-p ). Além do mais, você também terá o conceito de encapsulamento aplicado aqui. Repare que a regra de não permitir o parâmetro NAME como “procedural !!” está agora embutido no método SET( ). Isso impede que o atributo seja alterado indevidamente por qualquer outro programador mal comportado que venha dar manutenção em seu código. Ou seja, podemos alterar quantas vezes quisermos o atributo NAME, mas seguindo a regra definida no método SET( ). Mas será que daria para melhorar ainda ainda mais? Resposta é sim!

Versão Final! (Será?)

ZP_HELLO_OO_6

Agora sim, temos uma separação bem definida entre quem é responsável por tratar com o usuário (programa principal, com PARAMETERS e WRITE) e quem cuidará das regras do texto (classe LCL_HELLO). Ainda sim, estaremos protegidos do Performa Fanboy e deixamos nosso programa reutilizável.

Quando você começa a usar programação orientada a objetos você naturalmente começa a pensar nesses conceitos, como robustes, facilidade de manutenção, encapsulamento

Como regra prática, procure deixa comandos WRITEs fora das classes de negócio (Model).

Conclusão

Podemos ver que um simples problema de impressão do Hello World!! pode ganhar diversas soluções. Enquanto estou escrevendo esse parágrafo, já pensei mais outras duas. Isso prova que em programação orientada a objetos não existe certo ou errado, existe sim um equilíbrio, um balanço de quanto de reuso, abstração ou encapsulamento você quer aplicar ao seu problema. Isso dependerá muito de caso para caso. Mesmo assim não importa, continue programando somente em OO, acredite, um dia você irá me agradecer por isso.

Será que essa é a versão final? Será que você ficou contente com apenas 6 versões? E aquelas duas que eu pensei, como seriam? Deixe sua versão do Hello World OO nos comentários. Estou muito curioso em saber como você resolveria o Hello World!! além do

WRITE: ‘Hello World!!’.

Arquivo Nugget. (SAPLink)

Já ouviu falar de um jornal de SAP? Pois é… não só existe um como vários. Você conhece algum? Leia o post por completo caso queira saber mais a respeito.

Outro dia achei pelo twitter um jornal eletrônico no paper.li que fala sobre SAP. É o SAP Affinity Group Daily, ele contém informações sobre SAP dos mais diversos assuntos: Negócio, tecnologia, educação etc.. como qualquer outro jornal. Outro jornal com bastante conteúdo no paper.li de SAP é o The #SAP Daily.

O mais legal dos jornais no paper.li é que você consegue facilmente assinar o seu newsletter. Este é uma das poucas fontes de informação fora SCN que considero boa. Vale a pena conferir.

Você também consegue acompanhar o SAP Affinity Group via twitter.

Para comentar: quais outras fontes além da SCN você considera relevante no mundo SAP/ABAP?

Abraços!