ABAP Web Dynpro - Fundamentos

Slide 1

Página | 1
ABAP Web Dynpro - Fundamentos

Slide 2

O que é Web Dynpro

De um ponto de vista tecnológico, Web Dynpro, Java e ABAP, são
passos revolucionários para o desenvolvimento de interface de
usuário para Web, dentro da estratégia da SAP. É completamente
diferente do paradigma até então estabelecido pela SAP e
representa um grande avanço no desenvolvimento de aplicações
ERP baseadas em Web.
Aplicações Web Dynpro são construídas usando técnicas de
programação declarativa baseadas no padrão de projeto MVC
(Model View Controller), largamente difundido na indústria. Isto é,
você define quais objetos deverão estar disponíveis para o cliente e
de onde estes os valores para estes objetos deverão ser
recuperados/armazenados. Você define também quais são os
possíveis caminhos de navegação, declarativamente em sua
aplicação. Todo o código necessário é, então, gerado
automaticamente dentro do runtime framework. Este modelo isenta
o desenvolvedor das tarefas repetitivas de codificação/marcação
HTML e interatividade, como JavaScript.
ABAP Web Dynpo está disponível desde a versão NetWeaver 2004s
(Application Server 7.0). Para o desenvolvimento componentes e
aplicações Web Dynpro ABAP, a transação SE80 (ABAP Workbench)
foi aprimorada.

Página | 2
ABAP Web Dynpro - Fundamentos

Web Dynpro foi concebido para suportar desenvolvimento

estruturado e as unidades de modularização são os chamados
Componentes Web Dynpro, que podem ser combinados para formar
aplicações complexas.

Página | 3
ABAP Web Dynpro - Fundamentos

Slide 3

Declarações Meta Modelo vs. Código Customizado

Considerando o modelo de programação declarativa do Web
Dynrpo, dentro do Workbench, existem certas ferramentas que
permitem ao desenvolvedor construir uma representação abstrata
na forma de Meta Modelo Web Dynrpo. O código necessário é
então gerado, em conformidade com uma arquitetura padrão,
conhecida como o Framework Web Dynpro.
Este framework permite, então, que o desenvolvedor injete, em
locais predefinidos, código customizado para atender aos requisitos
de negócio da aplicação. Isto diferencia uma aplicação Web Dynpro
das outras, que por definição, são compostas das mesmas unidades
básicas.
Este modelo permite que nem todas as decisões de implementação
sejam feitas na fase de desenho da aplicação. Isto permite, por
exemplo, que a aparência da interface com o usuário seja decidida
em tempo de execução, de acordo com parâmetros do usuário ou
requisitos de negócio. Isto permite que uma aplicação Web
altamente flexível seja construída sem a necessidade de códigos
complexos DHTML e Javascript.

Página | 4
ABAP Web Dynpro - Fundamentos

Slide 4

Cenários de aplicações Web Dynpro

Aplicações ABAP Web Dynpro podem acessar uma variedade de
fontes de dados (Models), tanto diretamente, como chamadas a
módulos de função e métodos de objetos, ou indiretamente, através
do consumo de Web Services ou de conexões com EJB (Enterprise
JavaBeans) usando o conector Java (JCo).
É possível ainda, apesar de ser altamente não recomendado,
causando uma confusa mistura entre a camada de negócios e o
modelo de dados (Model e Controller), o acesso direto a um
comando OpenSQL SELECT.
Um Objeto ABAP (instância de uma classe) até o presente momento
não pode ser usado como modelo. A maneira recomendada para se
ter objetos reutilizáveis que representem lógicas de negócio é
construir Classes ABAP para conter este tipo de código. É possível
ainda se criar um Componente faceless, ou seja, um componente
WebDynpro sem nenhum elemento visual, apenas para fim de
reusabilidade.

Página | 5
ABAP Web Dynpro - Fundamentos

Slide 5

Benefícios do Web Dynpro

O objetivo principal do Web Dynpro é fornecer ao desenvolvedor de
aplicações uma maneira de criar aplicações Web poderosas com o
mínimo de esforço (repetitivo) usando ferramentas e processos
declarativos em um processo de desenho estruturado.
Uma regra de oura da filosofia do Web Dynpro é: Quanto menos
linhas de código escritas pelo desenvolvedor, melhor. Este objetivo é
alcançado considerando-se dois princípios:
Usando uma técnica declarativa, com Meta Modelo independente
de linguagem para definir a interface com usuário e, desta definição
declarativa, o ambiente de desenvolvimento pode gerar o código
fonte necessário. Código manual ainda tem seu lugar, mas está, ou
deveria estar, restrito apenas a manipulação de dados de negócio e
nunca de interface com usuário (View).
Artifícios técnicos prontos, como I18N, baixo número de reloads de
páginas através de AJAX (flicker-free interaction), e uma clara
separação da camada de negócio (Controller) e interface com
usuário (View).

Página | 6
ABAP Web Dynpro - Fundamentos

Slide 6

Página | 7
ABAP Web Dynpro - Fundamentos

Slide 7

Model-View-Controller
O Web Dynpro é fundamentado no padrão de projeto MVC,
concebido originalmente pelo projetista de software norueguês
Trygve Reenskaug, enquanto trabalhava na Xerox, no PARC no final
dos anos 70. Sua primeira implementação ocorreu no lançamento
da linguagem Smalltalk-80.

Este padrão de projeto foi considerado uma revolução, pois foi o

primeiro a descrever componentes de software em termos de:
• As responsabilidades funcionais correspondentes a cada
componente.
• Os protocolos de mensagem a qual cada componente deveria
responder, ou reagir.

A SAP modificou e estendeu a especificação original do MVC para

criar o conjunto de ferramentas Web Dynrpo.

Página | 8
ABAP Web Dynpro - Fundamentos

Slide 8

Componentes Web Dynpro

Os componentes permitem uma complexa estruturação de
entidades de aplicação Web interativas e sua reutilização. Isto
permite o aninhamento em grandes aplicações.
Podemos enxergar o componente como um container para outros
objetos relacionados a interface com o usuário (View) e o código
fonte Web Dynpro (Controller).
Os elementos principais de interface com o usuário, são as Windows
e as Views. Uma View representa uma área retangular que será
exibida em uma página no cliente, um Web Browser por exemplo.
Esta contém elementos de interação, como caixas de texto, imagens
e botões. Uma página completa enviada para o cliente pode ser
composta de apenas uma View, mas também pode ser uma
combinação de virtualmente qualquer número de Views. Esta
combinação de Views e o fluxo entre estas é definido em uma
Window. O relacionamento entre Views e Windows, fazendo uma
analogia ao DER, seria N:N.
O código fonte de uma aplicação Web Dynpro está localizado nos
Controllers. O armazenamento lógico dos dados globais de um
Controller é hierarquicamente definido em um Context.

Página | 9
ABAP Web Dynpro - Fundamentos

Slide 9

Context Mapping e Data Binding

As variáveis definidas em um Context de Controller Web Dynpro
podem ser referenciadas dentro de Contexts de outros Controller.
Chamamos isto de Context Mapping. Isto permite o
compartilhamento de dados comuns entre diferentes Controllers,
retirando a necessidade de se efetuar cópias destes dados entre
contextos.

Os valores de elementos de interação com o usuário devem ser

ligados a atributos de um Context do Controller corrspondente: ao
Context do View Controller, por exemplo. A isto chamamos de Data
Binding. Através desta técnica, ocorre o transporte automático dos
dados de campos de entrada para os atributos (variáveis) do
Context.

Combinando estas duas técnicas, vemos que o transporte de dados

entre elementos de diferentes Views é definido de uma forma
puramente declarativa.

Página | 10
ABAP Web Dynpro - Fundamentos

Slide 10

Context Mapping
Permite que um nó em um Controller seja automaticamente
preenchido com os dados de um nó correspondente em um
Context, geralmente de uma View. Este é o mecanismo principal
para compartilhar dados comuns entre Controllers.

Quando dois Controllers dentro do mesmo Componente

compartilham dados através deste relacionamento, isto é chamado
de Mapping interno. O Context que atua como fonte dos dados é
chamado Nó de Origem, enquanto o nó que recebe os valores é
chamado de Nó Mapeado.

O Mapping de Nós entre Context de Controllers localizados em

diferentes Componentes é chamado de Mapping Externo.

Para o Mapping de nós ser declarado, é preciso que alguns pré-

requisitos sejam cumpridos:
• É preciso que exista um Nó de origem no Context de
Controller agindo como a fonte dos dados.
• O Controller que contem o Contex com o Nó Origem não
pode ser um View Controller.

Página | 11
ABAP Web Dynpro - Fundamentos

• O Controller com o Nó Mapeado deve declaras o Controller

com o Nó de Origem como um Controller usado.

Página | 12
ABAP Web Dynpro - Fundamentos

Slide 11

Data Binding
É a técnica pela qual os dados são transportados de um Context de
uma View para os elementos de interação nolayout desta View, e
vice versa. Você não pode ligar um elemento de interface com o
usuário com um nó ou atributo localizado em um Context de outro
Controller, apenas o contido na própria View.
Sendo assim, os elementos de interface com o usuário sempre serão
privados àquela View onde foram declarados.

Esta técnica separa os elementos de interface com o usuário do

código fonte da aplicação, localizado dentro dos Controllers. Desta
forma, para se manipular valores de propriedades em um elemento
de interface com o usuário, o código fonte do Controller da View em
questão precisará apenas modificar os nós e atributos do Context
desta View, considerando que estes elementos estejam ligados por
Data Binding. O framework Web Dynpro executa então as duas
tarefas a seguir:
• O transporte dos dados do nó ou atributo para o elemento de
interface com usuário ao qual este esteja ligado, durante o processo
de renderização da página.
• A atualização de todos os nós e atributos correspondentes
que sofreram modificações nos elementos de entrada de dados por

Página | 13
ABAP Web Dynpro - Fundamentos

parte do usuário. Neste processo, os dados são automaticamente

convertidos e checados para que correspondam a seus respectivos
tipos declarados, caso ocorra alguma falha, uma mensagem é
imediatamente exibida para que o usuário possa corrigir este valor.

Data Binding não se restringe, porém, a ligação com valores de

elementos de interação com atributos do Context, mas pode-se, por
exemplo controlar propriedades destes elementos como
visibilidade, aparência, etc. Desta forma podemos controlar as
propriedades de qualquer elemento de uma View de dentro do
Controller desta View, modificando valores de nós e atributos do
seu Context.

Página | 14
ABAP Web Dynpro - Fundamentos

Slide 12

Navegação entre diferentes Views

A navegação entre as Views é acionada configurando e,
eventualmente, disparando-se Outbound Plugs. Isto causa um
evento de navegação. Estes eventos são organizados, de modo
assíncrono, em uma fila. Múltiplos Outbound Plugs podem ser
disparados de uma única View. Cada chamada pode redefinir a
interface com o usuário, apresentando-lhe um novo conjunto de
Views, Esta fila contendo os eventos de navegação é processada em
um determinado ponto da fase de processamento, gerenciada pelo
framework Web Dynpro. Até este ponto, esta pilha de chamada
pode ser modificada, incluindo-se ou retirando-se eventos de
navegação. Convêm-se que Outbound Plugs sejam nomeados de
acordo com a ação que causou a navegação desta View para uma
outra.

Do outro lado, existes métodos manipuladores de eventos especiais,

que são associados aos eventos de navegação gerados pelos
Outboud Plugs. Estes são chamados de Inbound Plugs. Quando da
fase de processamento do framework Web Dynrpo, estes métodos
são chamados para cada evento na fila de navegação. É interessante
notar que, para estes eventos serem acionados, todas as Views do
conjunto atual tenham disparado seus Outbound Plugs e que

Página | 15
ABAP Web Dynpro - Fundamentos

nenhum erro de validação de dados tenha ocorrido, cancelando a

navegação. Inbound Plugs, em nome da clareza, deveriam ser
nomeados em razão do motivo pelo qual a View a que corresponde
está sendo exibida.

Outbound Plugs e Inbound Plugs são ligados através de Navigation

Links. Tecnicamente, ao se definir um Navigation Link entre um
Outbound Plug e um Inbound Plug significa registrar o método
manipulador de evento de um Inbound Plug ao evento de
navegação de um Outbound Plug. Desta forma, assim que um
Outbound Plug é disparado, automaticamente o método do
Inbound Plug correspondente é executado.

É possível definir parâmetros entre o disparo de um evento de

navegação de um Outbound Plug e o método manipulador de
evento do Inbound Plug, permitindo que dados sejam transferidos
de uma View para outra.

Página | 16
ABAP Web Dynpro - Fundamentos

Slide 13

Windows e Views aninhadas

Uma Window é, por definição um conjunto de todas as Views
necessárias para a construção de uma página visível. Uma Window
pode ter zero ou mais Views ebutinas. Uma Window pode conter
elementos denominados View Containers, permitindo assim o
aninhamento de Views dentro de uma Window.

Uma Window define quais combinações de Views estarão visíveis e

em que momento, através do uso de Outbound Plugs. Desta forma,
ao criar uma Window, você terá que definir três aspectos:
• Todas as possíveis Views que poderão ser exibidas devem ser
embutidas na Window.
• Se for necessário que várias Views sejam exibidas em
paralelo, deve-se definir o layout e a organização destas Views
através de um elemento View Container. Para cada elemento View
Container, uma View padrão deve ser definida para ser exibida
inicialmente
• Os Navigation Links entre as Views devem ser definidos,
ligando-se Outbound e Inbound Plugs.

Página | 17
ABAP Web Dynpro - Fundamentos

Apenas uma View pode ser exibida para o usuário, em tempo de

execução. É possível definir uma View vazia, a fim de se conseguir
limpar a tela visível para o usuário.

O conjunto de Views utilizado para de compor uma Window é

conhecido como View Assembly.

Página | 18
ABAP Web Dynpro - Fundamentos

Slide 14

Interface View e Interface Controller

As partes de um Componente Web Dynpro visíveis, para outro
Componente Web Dynrpo, são os chamados Interface View(s) e
Interface Controller.

Apenas um Interface View por Componente é automaticamente

criado, e dentro dele podem ser expostos dados (Context), métodos
e manipuladores de evento, para outros Componentes.

As Interface Views representam as interfaces visuais com o usuário

de um Componente Web Dynpro. Há uma relação de 1:1 entre as
Windows e as Interface Views, ou seja, cada vez que se define uma
Window, uma nova Interface View é automaticamente criada,
expondo esta Window para outros Componentes Web Dynpro. Esta
Interface View obedece a propriedade interface de cada Outbound e
Inbound Plug para decidir se estes serão expostos. Os métodos e
dados da Window não serão acessíveis através deste mecanismo.

Para um Componente que não possui Views, não há a necessidade

de se gerar Windows e, portanto, não existirão Interface Views. Um
Componente que não tenha interface visual é conhecido como
faceless.

Página | 19
ABAP Web Dynpro - Fundamentos

StartUp Plug e Web Dynpro Application

Finalmente, é preciso definir um ponto de partida para o uso das
Views e seus a lógica contidas nos Controllers, que se comunicam
com os Models do Web Dynpro.

Este ponto de partida é definido através de um Inbound Plug

especial, do tipo StartUp. É preciso ainda que seja criado uma Web
Dynpro Application, que representa uma URL e é associado ao
StartUp Plug da Interface View.

Na maioria dos casos, uma Interface View será chamada por apenas
uma Web Dynpro Application. Porém, assim como um ABAP Módulo
Pool pode ser invocado por transações diferentes, seguindo fluxos
de tela diferentes, também podem existir várias Web Dynpro
Applications tendo pontos de partida no mesmo Componente Web
Dynrpo, sendo que posem ser criados vários StartUp Plugs em
diferentes Interface Views.

Para se definir uma Web Dynpro Application é necessário:

• Definir qual Componente será invocado. Este será conhecido
como o Componente Root para a Application.
• Qual Interface View deste Componente será usado, definindo
assim qual o View Assembly será exibido por padrão pela
Application.
• Qual Inbound Plug desta Interface View, que deve ser
mandatoriamente do tipo StartUp, agirá como ponto de partida
para Application.

Página | 20