abap web dynpro - pratica

ABAP Web Dynpro – Prática

Página | 1

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 | 2

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 | 3

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 | 4

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 | 5

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 | 6

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

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 | 8

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 | 9

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 | 10

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 | 11

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 | 12

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 | 13

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 | 14

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 | 15

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 | 16

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

seu respectivo atributo no Context:

Aqui se define a

propriedade do elemento

Cell Editor que terá seu

valor ligado ao atributo

do Context.


Página | 17

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 e então selecione o nó FLIGHT_LIST.


Página | 18

Neste ponto podemos definir quais serão os atributos deste nó a serem exibidos no elemento

Table.


Página | 19

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 | 20

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 | 21

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 | 22

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 | 23

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 | 24

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.

abap web dynpro - pratica

Documents