ABAP Web Dynpro - Pratica

ABAP Web Dynpro – Prática

Treinamento ABAP Web Dynpro – Tutorial prático: Flight Model O objetivo deste tutorial é utilizar o modelo de negócio Flight Model, fornecido pela SAP, para montar um sistema de busca e reservas de vôos utilizando ABAP Web Dynpro.

O modelo de dados é simples, e iremos considerar que os dados para estas tabelas já estejam carregados no Client utilizado. Para tal, poderemos executar o programa SAPBC_DATA_GENERATOR:

Página | 1

ABAP Web Dynpro – Prática Após a execução, as seguintes tabelas estarão preenchidas com dados para teste: SCURX: Moedas SBUSPART: Parceiros STRAVELAG: Agências de Viagem SCUSTOM: Clientes SCARR: Companhias Aéreas SCOUNTER: Pontos de Venda por Companhia aérea SPFLI: Itinerários de Vôos SFLIGHT: Vôos SBOOK: Reservas de Vôos

Página | 2


Primeiro Componente Web Dynpro No primeiro exemplo, iremos criar um Componente Web Dynpro, que irá conter as Views necessárias para que o usuário possa pesquisar por vôos disponíveis, utilizando diversas opções para filtros.

Passo 1 – Criação do Componente Para criar um Componente Web Dynpro ABAP, utilizaremos o ABAP Workbench, transação SE80: Na aba Repository Browser, escolha a opção Web Dynpro Comp. / Intf.

Entre com o nome para o novo Componente e clique em

Responda que Sim, deseja criar um novo Objeto.

Página | 3

ABAP Web Dynpro – Prática Entre com os dados para o novo Objeto. Observe que já é sugerido um nome para uma nova Window e uma nova View. Aceite as sugestões e clique em

Indique o pacote. Para o nosso exemplo, utilizaremos a opção

Temos a seguinte estrutura criada:

Página | 4

.

.


Passo 2 – Criando um Model No passo anterior, pudemos notar que, ao criarmos um Componente Web Dynpro, duas camadas do modelo MVC já são claramente visíveis: View e Controller. Neste passo, usaremos uma BAPI para criar um Model. Abra o menu de contexto do Componente Web Dynpro: Create -> Service Call.

Um novo Wizard é apresentado. Seguindo os seus passos, é possível, de forma declarativa, criar uma chamada uma BAPI, ou a um módulo de função arbitrário, um método de uma classe ABAP ou ainda consumir um WebService, através da geração de um Proxy.

Página | 5

ABAP Web Dynpro – Prática Para criar tal chamada, é preciso selecionar um Controller. Pode-se também criar um novo Controller. Neste momento, usaremos o Controller do Componente.

Para o tipo do serviço a ser chamado, selecionemos Function Module.

Vamos usar, para nossa busca de vôos, a função BAPI_FLIGHT_GETLIST. Deixe o campo Destination em branco.

Página | 6


Na tela seguinte, ó possível determinarmos como serão nomeados os parâmetros da chamada ao serviço e como estes parâmetros se comportarão dentro no nosso Componente Web Dynpro. Na coluna New Name, podemos aceitar a sugestão, onde os nomes dos parâmetros no Componente Web Dynpro, ou seja, as variáveis declaradas dentro de nosso Controller, serão idênticos aos parâmetros do serviço a ser chamado, respeitando-se o limite de 20 caracteres para se nomeá-los. Esta é uma boa prática, por isso vamos segui-la. Quanto ao tipo dos parâmetros, ou seja, como será seu comportamento em nosso Componente Web Dynpro, devemos configurar a coluna Object Type de cada parâmetro. Aqueles parâmetro que são do tipo Root Node e Parameter Group, sempre serão transformados em Nós dentro do Context. Esta é uma boa hora para pensarmos em quais parâmetros estarão de fato disponíveis para a pesquisa em nossa View, pois neste momento devemos configurar seu tipo como Context (Nós/Atributos). Isso nos permitirá executar as tarefas de Context Mapping e Data Binding para dentro da View, construindo assim a nossa interface com o usuário. Vamos configurar os parâmetros AIRLINE, DESTINATION_FROM, DESTINATION_TO, DATE_RANGE, FLIGHT_LIST como do tipo Context.

Página | 7


Finalmente, devemos definir um nome de método que será usado para fazer a chamada ao Serviço. Aceitaremos a sugestão do assistente.

Um resumo é então exibido e podemos completar a tarefa de gerar a chamada ao Serviço.

Página | 8


O resultado é que, dentro do Controller, geramos todos as declarações necessárias para a chamada ao serviço escolhido, um módulo de função, que corresponderá a camada Model.

Página | 9


Passo 3 – Construindo a View Pesquisa de Vôos Context Mapping

Clique duas vezes na View MAIN, a aba Context: Do lado esquerdo, temos os nós e atributos do View Context. Do lado direito temos os Contexts dos Controllers usados por esta View. Por padrão, o Controller do Componente sempre estará disponível para as Views.

Página | 10

ABAP Web Dynpro – Prática Para mapearmos os dados a serem passados entre o Controller e a View, simplesmente arrastamos os nós ou atributos, aqueles que desejamos estar disponíveis na interface com o usuário, do Context do Controller para o Context da View. Para nosso caso, vamos arrastar os nós DESTINATION_FROM, DESTINATION_TO e FLHIGHTS_LIST para o lado esquerdo.

Repare que para cada nó no Context, existe uma propriedade chamada Cardinality. Caso essa propriedade seja 1:1, como nos nós DESTINATION_FROM e DESTINATION_TO, significa que para estes nós será representado na memória como uma estrutura. No caso do nó FLHIGHTS_LIST, analogamente como acontece com um módulo de função, a propriedade Cardinality é 0:n. Neste caso, este nó será representado em memória como uma tabela interna.

É interessante notar também a propriedade Selection, que indica como será a seleção dos dados por parte do usuário, mais especificamente quantas linhas poderão ser marcadas numa representação gráfica destes dados, em uma tabela ou em um elemento ALV. Ao arrastarmos um nó ou atributo de um Context para outro, já estamos automaticamente definindo um Context Mapping. Ou seja, sempre que os dados de qualquer dos Context sofrerem Página | 11

ABAP Web Dynpro – Prática alterações, seja por comunicação com o Model, seja por intervenção do usuário, o outro lado será atualizado. Data Binding

Vamos agora para a aba Layout da View MAIN:

É nesta aba que poderemos definir como será a apresentação desta View para o usuário. Do lado esquerdo, temos uma barra de ferramentas com os possíveis elementos de exibição e de interação com o usuário. Como rótulos de texto, caixas de entrada de texto, tabelas, etc. Podemos definir cada elemento e cada mapeamento isoladamente. Mas o View Designer nos fornece ferramentas para aumentar a produtividade, fortalecendo o paradigma de programação declarativa. Primeiro vamos definir as áreas onde os conjuntos de campos serão posicionados. Podemos usar o objeto Group, da barra de ferramentas layout:

Página | 12


Para cada elemento Group criado, o View Disigner define um elemento Caption, que definirá o texto título do grupo de campo. Como se pode observar, o View Designer mantém um registro hierárquico dos elementos contidos na View. A cada novo elemento criado, uma numeração é atribuído ao seu ID, para fins de universalidade. Por exemplo, acionemos o menu de contexto do elemento GROUP: clique na opção Create Container Form.

Ao clicarmos no botão da janela que se apresenta, poderemos escolher com quais dados do Context criaremos o Form em questão: Selecione o nó DESTINATION_FROM.

Página | 13


Temos então a seguinte tela:

Nesta tela, poderemos selecionar, a partir do nó do Context escolhido, quais dados, e como, serão exibidos. Poderemos selecionar de uma lista, de que forma este atributo será representado em nossa View. Vamos marcar a coluna Binding para os 3 primeiros atributos, deixando o Cell Editor como InputField.

Página | 14


Para elemento container dentro da View, é possível definir propriedades que irão ditar como os elementos internos a este container irão se conportar. Vamos definir por exemplo, a propriedade Layout do elemento GROUP com o valor GridLayout. Da mesma forma, vamos definir o Grupo “To ”.

Para manter a organização, vamos modificar a propriedade Width de cada elemento Group como 400px.

Desta forma já temos boa parte da interface com o usuário bem definida. Mas onde está o Data Binding? Bem, com o auxílio do assistente para criarmos os Forms, vimos que os dados são ligados diretamente aos atributos do Context. Quando selecionamos quais atributos do nó do Context serão exibitos, pudemos notar que há uma coluna que indica como será feito o Data Binding para cada elemento:

Página | 15


Aqui se define a propriedade do elemento Cell Editor que terá seu valor ligado ao atributo do Context.

Para cada campo de entrada (elementos InputField) criados, a propriedade “value” será ligada a

seu respectivo atributo no Context:

Página | 16

ABAP Web Dynpro – Prática Como resultado de nossa pesquisa, ou seja, a chamada ao Serviço que nos atende como Model, esperamos receber uma lista de Vôos que correspondam aos critérios de pesquisa selecionados. Para exibir esta lista, usaremos um elemento Table abaixo dos filtros de pesquisa.

No menu de contexto do elemento Table em nossa View, temos a opção Create Binding.

Assim como quando criávamos Forms para conter os filtros de pesquisa, usaremos o Context para ligar os dados do elemento Table ao nó do Context que desejamso exibir. Clique em

Página | 17

e então selecione o nó FLIGHT_LIST.

ABAP Web Dynpro – Prática Neste ponto podemos definir quais serão os atributos deste nó a serem exibidos no elemento Table.

Página | 18

ABAP Web Dynpro – Prática Passo 4 – Disparando um evento

Finalmente, devemos providenciar um meio para que o usuário possa, após ter preenchido os filtros, disparar a pesquisa e exibir os resultados. Para isso, criaremos um botão entre os grupos de filtros e o resultado:

Após posicionar o elemento Button dentro da View, devemos codificar o que acontecerá quando o usuário pressionar este botão. Para isso, usaremos o evento onAction, disponível neste elemento:

Página | 19

ABAP Web Dynpro – Prática Após configurarmos a Action para este botão, são criadas na View as seguintes declarações: Um elemento Action

Um método manipulador de evento

Cliquemos no botão ABAP Routine

para codificar o método:

Para implementar o método, é possível acionar um Assistente, clicando no botão . A seguinte janela nos permitirá escolher em qual Controller está localizada a lógica de negócios a ser acionada:

Página | 20


Preencha com as informações como mostra a figura e pressione ENTER. O método ONACTIONPESQUISAR é então codificado da seguinte forma: method ONACTIONPESQUISAR . DATA lo_componentcontroller TYPE REF TO ig_componentcontroller . lo_componentcontroller = wd_this->get_componentcontroller_ctr( ). lo_componentcontroller->execute_bapi_flight_getlist( ). endmethod.

Página | 21


Passo 5 – Configurando uma Web Dynpro Application Como podemos observar, a Window criada automaticamente junto com o nosso Componente Web Dynpro já tem embutida nossa View MAIN e também um Inbound Plug do tipo Startup, chamado DEFAULT. Este Inbound Plug funciona como ponto de partida para nossa pesquisa de Vôos.

Para que possamos ter um meio de acessar esta aplicação, devemos criar um último artefato: uma Web Dynpro Application. No menu de contexto do Componente Web Dynpro, selecione a opção: Create -> Web Dynpro Application:

Página | 22

ABAP Web Dynpro – Prática Simplesmente especifique uma descrição para a aplicação e pressione ENTER:

As propriedades para a Web Dynpro Application são exibidas:

A partir deste ponto, podemos salvar e ativar os objetos criados. Podemos então testar nossa aplicação:

Página | 23


Passo 6 – Testando a aplicação Ao testar a aplicação, iremos percebe que todos os objetos de ajuda de pesquisa já estarão disponíveis. Para isso, basta que estejam definidos no ABAP Dictionary, de onde vêm as referências para os dados da tela.

Página | 24

ABAP Web Dynpro - Pratica

Recommend Documents