ABAP Web Dynpro - Fundamentos

Slide 1

ABAP Web Dynpro

DIA 1
CONCEITUA E S
ABAP OBJECT S RESUMO

AR QUITE T UR A DE COM PON EN TE S WEB

DYN PR O (M VC)

Pgina | 1

ABAP Web Dynpro - Fundamentos

Slide 2

Parte 1 - Conceituaes

O que Web Dynpro

De um ponto de vista tecnolgico, Web Dynpro, Java e ABAP, so
passos revolucionrios para o desenvolvimento de interface de
usurio para Web, dentro da estratgia da SAP. completamente
diferente do paradigma at ento estabelecido pela SAP e
representa um grande avano no desenvolvimento de aplicaes
ERP baseadas em Web.
Aplicaes Web Dynpro so construdas usando tcnicas de
programao declarativa baseadas no padro de projeto MVC
(Model View Controller), largamente difundido na indstria. Isto ,
voc define quais objetos devero estar disponveis para o cliente e
de onde estes os valores para estes objetos devero ser
recuperados/armazenados. Voc define tambm quais so os
possveis caminhos de navegao, declarativamente em sua
aplicao. Todo o cdigo necessrio , ento, gerado
automaticamente dentro do runtime framework. Este modelo isenta
o desenvolvedor das tarefas repetitivas de codificao/marcao
HTML e interatividade, como JavaScript.
ABAP Web Dynpo est disponvel desde a verso NetWeaver 2004s
(Application Server 7.0). Para o desenvolvimento componentes e
aplicaes Web Dynpro ABAP, a transao SE80 (ABAP Workbench)
foi aprimorada.
Pgina | 2

ABAP Web Dynpro - Fundamentos

Web Dynpro foi concebido para suportar desenvolvimento
estruturado e as unidades de modularizao so os chamados
Componentes Web Dynpro, que podem ser combinados para formar
aplicaes complexas.

Pgina | 3

ABAP Web Dynpro - Fundamentos

Slide 3

Parte 1 - Conceituaes

Declaraes Meta Modelo

Cdigo Customizado

Garantia de padronizao
Uso de Ferramentas para auxiliar o
desenvolvimento
Desenho de Telas e aninhamento
Navegao e tratamento de erros
Fluxo de dados
Componentizao e reutilizao

Garantia de Universalidade
Bom para aplicaes dinmicas e baseadas
em Dados
Implementaes de regras de negcio
Modificaes dinmicas na interface com
usurio
Acesso a servios (arquivos, etc)
Portal eventing (comunicao entre iViews)

Declaraes Meta Modelo vs. Cdigo Customizado

Considerando o modelo de programao declarativa do Web
Dynrpo, dentro do Workbench, existem certas ferramentas que
permitem ao desenvolvedor construir uma representao abstrata
na forma de Meta Modelo Web Dynrpo. O cdigo necessrio
ento gerado, em conformidade com uma arquitetura padro,
conhecida como o Framework Web Dynpro.
Este framework permite, ento, que o desenvolvedor injete, em
locais predefinidos, cdigo customizado para atender aos requisitos
de negcio da aplicao. Isto diferencia uma aplicao Web Dynpro
das outras, que por definio, so compostas das mesmas unidades
bsicas.
Este modelo permite que nem todas as decises de implementao
sejam feitas na fase de desenho da aplicao. Isto permite, por
exemplo, que a aparncia da interface com o usurio seja decidida
em tempo de execuo, de acordo com parmetros do usurio ou
requisitos de negcio. Isto permite que uma aplicao Web
altamente flexvel seja construda sem a necessidade de cdigos
complexos DHTML e Javascript.

Pgina | 4

ABAP Web Dynpro - Fundamentos

Slide 4

Parte 1 - Conceituaes

Cenrios de aplicaes Web Dynpro

Aplicaes ABAP Web Dynpro podem acessar uma variedade de
fontes de dados (Models), tanto diretamente, como chamadas a
mdulos de funo e mtodos de objetos, ou indiretamente, atravs
do consumo de Web Services ou de conexes com EJB (Enterprise
JavaBeans) usando o conector Java (JCo).
possvel ainda, apesar de ser altamente no recomendado,
causando uma confusa mistura entre a camada de negcios e o
modelo de dados (Model e Controller), o acesso direto a um
comando OpenSQL SELECT.
Um Objeto ABAP (instncia de uma classe) at o presente momento
no pode ser usado como modelo. A maneira recomendada para se
ter objetos reutilizveis que representem lgicas de negcio
construir Classes ABAP para conter este tipo de cdigo. possvel
ainda se criar um Componente faceless, ou seja, um componente
WebDynpro sem nenhum elemento visual, apenas para fim de
reusabilidade.

Pgina | 5

ABAP Web Dynpro - Fundamentos

Slide 5

Parte 1 - Conceituaes
Web Dynpro pode ser

acessada atravs de vrios

tipos de dispositivos.
Aspecto importante para
um ambiente empresarial
altamente colaborativo.
vlido lembrar que em
alguns dispositivos
suportados, nem todos os
recursos estaro
disponveis.

Benefcios do Web Dynpro

O objetivo principal do Web Dynpro fornecer ao desenvolvedor de
aplicaes uma maneira de criar aplicaes Web poderosas com o
mnimo de esforo (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 cdigo escritas pelo desenvolvedor, melhor. Este objetivo
alcanado considerando-se dois princpios:
Usando uma tcnica declarativa, com Meta Modelo independente
de linguagem para definir a interface com usurio e, desta definio
declarativa, o ambiente de desenvolvimento pode gerar o cdigo
fonte necessrio. Cdigo manual ainda tem seu lugar, mas est, ou
deveria estar, restrito apenas a manipulao de dados de negcio e
nunca de interface com usurio (View).
Artifcios tcnicos prontos, como I18N, baixo nmero de reloads de
pginas atravs de AJAX (flicker-free interaction), e uma clara
separao da camada de negcio (Controller) e interface com
usurio (View).

Pgina | 6

ABAP Web Dynpro - Fundamentos

Slide 6

Parte 1 - Perguntas

Pgina | 7

ABAP Web Dynpro - Fundamentos

Slide 7

Parte 2 Arquitetura de componentes Web Dynpro (MVC)

Camada de interao com o negcio
Controla qualquer
intermediao necessria
entre o negcio e o usurio.

Gerencia os dados
da aplicao sem
qualquer
preocupao sobre
como sero
exibidos.

Model

Camada de ligao

Controller
Camada de interao com usurio

Request
Response

View

Visualiza os dados
da aplicao sem
qualquer
preocupao sobre
somo so gerados
ou armazenados.

Model-View-Controller
O Web Dynpro fundamentado no padro de projeto MVC,
concebido originalmente pelo projetista de software noruegus
Trygve Reenskaug, enquanto trabalhava na Xerox, no PARC no final
dos anos 70. Sua primeira implementao ocorreu no lanamento
da linguagem Smalltalk-80.
Este padro de projeto foi considerado uma revoluo, 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 especificao original do MVC para
criar o conjunto de ferramentas Web Dynrpo.

Pgina | 8

ABAP Web Dynpro - Fundamentos

Slide 8

Parte 2 Arquitetura de componentes Web Dynpro (MVC)

Partes de

Componente WD

Window
Views
Elementos IU
Layouts

(View) Controller
(View) Context

Controller do
Componente

Context

Componentes Web Dynpro

Os componentes permitem uma complexa estruturao de
entidades de aplicao Web interativas e sua reutilizao. Isto
permite o aninhamento em grandes aplicaes.
Podemos enxergar o componente como um container para outros
objetos relacionados a interface com o usurio (View) e o cdigo
fonte Web Dynpro (Controller).
Os elementos principais de interface com o usurio, so as Windows
e as Views. Uma View representa uma rea retangular que ser
exibida em uma pgina no cliente, um Web Browser por exemplo.
Esta contm elementos de interao, como caixas de texto, imagens
e botes. Uma pgina completa enviada para o cliente pode ser
composta de apenas uma View, mas tambm pode ser uma
combinao de virtualmente qualquer nmero de Views. Esta
combinao 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 cdigo fonte de uma aplicao Web Dynpro est localizado nos
Controllers. O armazenamento lgico dos dados globais de um
Controller hierarquicamente definido em um Context.

Pgina | 9

ABAP Web Dynpro - Fundamentos

Slide 9

Parte 2 Arquitetura de componentes Web Dynpro (MVC)

Context
Um container para
armazenar dados.
O transporte dos
dados entre os
Controllers pode ser
estabelecido com a
definio de
Mappings entre os
Contexts.

Context Mapping e Data Binding

As variveis 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 cpias destes dados entre
contextos.
Os valores de elementos de interao com o usurio devem ser
ligados a atributos de um Context do Controller corrspondente: ao
Context do View Controller, por exemplo. A isto chamamos de Data
Binding. Atravs desta tcnica, ocorre o transporte automtico dos
dados de campos de entrada para os atributos (variveis) do
Context.
Combinando estas duas tcnicas, vemos que o transporte de dados
entre elementos de diferentes Views definido de uma forma
puramente declarativa.

Pgina | 10

ABAP Web Dynpro - Fundamentos

Slide 10

Parte 2 Arquitetura de componentes Web Dynpro (MVC)

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 atravs 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 Ns entre Context de Controllers localizados em
diferentes Componentes chamado de Mapping Externo.
Para o Mapping de ns ser declarado, preciso que alguns prrequisitos sejam cumpridos:

preciso que exista um N de origem no Context de Controller

agindo como a fonte dos dados.

Pgina | 11

ABAP Web Dynpro - Fundamentos

O Controller que contem o Contex com o N Origem no pode ser

um View Controller.

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

N de Origem como um Controller usado.

Pgina | 12

ABAP Web Dynpro - Fundamentos

Slide 11

Parte 2 Arquitetura de componentes Web Dynpro (MVC)

Data Binding
a tcnica pela qual os dados so transportados de um Context de
uma View para os elementos de interao nolayout desta View, e
vice versa. Voc no pode ligar um elemento de interface com o
usurio com um n ou atributo localizado em um Context de outro
Controller, apenas o contido na prpria View.
Sendo assim, os elementos de interface com o usurio sempre sero
privados quela View onde foram declarados.
Esta tcnica separa os elementos de interface com o usurio do
cdigo fonte da aplicao, localizado dentro dos Controllers. Desta
forma, para se manipular valores de propriedades em um elemento
de interface com o usurio, o cdigo fonte do Controller da View em
questo precisar apenas modificar os ns e atributos do Context
desta View, considerando que estes elementos estejam ligados por
Data Binding. O framework Web Dynpro executa ento as duas
tarefas a seguir:

O transporte dos dados do n ou atributo para o elemento de

interface com usurio ao qual este esteja ligado, durante o processo
de renderizao da pgina.

Pgina | 13

ABAP Web Dynpro - Fundamentos

A atualizao de todos os ns e atributos correspondentes que

sofreram modificaes nos elementos de entrada de dados por
parte do usurio. Neste processo, os dados so automaticamente
convertidos e checados para que correspondam a seus respectivos
tipos declarados, caso ocorra alguma falha, uma mensagem
imediatamente exibida para que o usurio possa corrigir este valor.
Data Binding no se restringe, porm, a ligao com valores de
elementos de interao com atributos do Context, mas pode-se, por
exemplo controlar propriedades destes elementos como
visibilidade, aparncia, etc. Desta forma podemos controlar as
propriedades de qualquer elemento de uma View de dentro do
Controller desta View, modificando valores de ns e atributos do
seu Context.

Pgina | 14

ABAP Web Dynpro - Fundamentos

Slide 12

Parte 2 Arquitetura de componentes Web Dynpro (MVC)

Navegao entre diferentes Views

A navegao entre as Views acionada configurando e,
eventualmente, disparando-se Outbound Plugs. Isto causa um
evento de navegao. Estes eventos so organizados, de modo
assncrono, em uma fila. Mltiplos Outbound Plugs podem ser
disparados de uma nica View. Cada chamada pode redefinir a
interface com o usurio, apresentando-lhe um novo conjunto de
Views, Esta fila contendo os eventos de navegao 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
navegao. Convm-se que Outbound Plugs sejam nomeados de
acordo com a ao que causou a navegao desta View para uma
outra.
Do outro lado, existes mtodos manipuladores de eventos especiais,
que so associados aos eventos de navegao gerados pelos
Outboud Plugs. Estes so chamados de Inbound Plugs. Quando da
fase de processamento do framework Web Dynrpo, estes mtodos
so chamados para cada evento na fila de navegao. interessante
notar que, para estes eventos serem acionados, todas as Views do
conjunto atual tenham disparado seus Outbound Plugs e que
Pgina | 15

ABAP Web Dynpro - Fundamentos

nenhum erro de validao de dados tenha ocorrido, cancelando a
navegao. Inbound Plugs, em nome da clareza, deveriam ser
nomeados em razo do motivo pelo qual a View a que corresponde
est sendo exibida.
Outbound Plugs e Inbound Plugs so ligados atravs de Navigation
Links. Tecnicamente, ao se definir um Navigation Link entre um
Outbound Plug e um Inbound Plug significa registrar o mtodo
manipulador de evento de um Inbound Plug ao evento de
navegao de um Outbound Plug. Desta forma, assim que um
Outbound Plug disparado, automaticamente o mtodo do
Inbound Plug correspondente executado.
possvel definir parmetros entre o disparo de um evento de
navegao de um Outbound Plug e o mtodo manipulador de
evento do Inbound Plug, permitindo que dados sejam transferidos
de uma View para outra.

Pgina | 16

ABAP Web Dynpro - Fundamentos

Slide 13

Parte 2 Arquitetura de componentes Web Dynpro (MVC)

Windows e Views aninhadas

Uma Window , por definio um conjunto de todas as Views
necessrias para a construo de uma pgina visvel. 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 combinaes de Views estaro visveis e
em que momento, atravs do uso de Outbound Plugs. Desta forma,
ao criar uma Window, voc ter que definir trs aspectos:

Todas as possveis Views que podero ser exibidas devem ser

embutidas na Window.

Se for necessrio que vrias Views sejam exibidas em paralelo,

deve-se definir o layout e a organizao destas Views atravs de um
elemento View Container. Para cada elemento View Container, uma
View padro deve ser definida para ser exibida inicialmente

Os Navigation Links entre as Views devem ser definidos, ligando-se

Outbound e Inbound Plugs.

Pgina | 17

ABAP Web Dynpro - Fundamentos

Apenas uma View pode ser exibida para o usurio, em tempo de
execuo. possvel definir uma View vazia, a fim de se conseguir
limpar a tela visvel para o usurio.
O conjunto de Views utilizado para de compor uma Window
conhecido como View Assembly.

Pgina | 18

ABAP Web Dynpro - Fundamentos

Slide 14

Parte 2 Arquitetura de componentes Web Dynpro (MVC)

Interface View e Interface Controller

As partes de um Componente Web Dynpro visveis, para outro
Componente Web Dynrpo, so os chamados Interface View(s) e
Interface Controller.
Apenas um Interface View por Componente automaticamente
criado, e dentro dele podem ser expostos dados (Context), mtodos
e manipuladores de evento, para outros Componentes.
As Interface Views representam as interfaces visuais com o usurio
de um Componente Web Dynpro. H uma relao 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 sero expostos. Os mtodos e
dados da Window no sero acessveis atravs deste mecanismo.
Para um Componente que no possui Views, no h a necessidade
de se gerar Windows e, portanto, no existiro Interface Views. Um
Componente que no tenha interface visual conhecido como
faceless.
Pgina | 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 lgica contidas nos Controllers, que se comunicam
com os Models do Web Dynpro.
Este ponto de partida definido atravs 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. Porm, assim como um ABAP Mdulo
Pool pode ser invocado por transaes diferentes, seguindo fluxos
de tela diferentes, tambm podem existir vrias Web Dynpro
Applications tendo pontos de partida no mesmo Componente Web
Dynrpo, sendo que posem ser criados vrios StartUp Plugs em
diferentes Interface Views.
Para se definir uma Web Dynpro Application necessrio:
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 padro pela
Application.
Qual Inbound Plug desta Interface View, que deve ser
mandatoriamente do tipo StartUp, agir como ponto de partida
para Application.

Pgina | 20