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)

Página | 1
ABAP Web Dynpro - Fundamentos

Slide 2

Parte 1 - Conceituações

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

Parte 1 - Conceituações

Declarações Meta Modelo Código Customizado

Garantia de padronização
• Uso de Ferramentas para auxiliar o
desenvolvimento
• Desenho de Telas e aninhamento
• Navegação e tratamento de erros
• Fluxo de dados
• Componentização e reutilização
Garantia de Universalidade
• Bom para aplicações dinâmicas e baseadas
em Dados
• Implementações de regras de negócio
• Modificações dinâmicas na interface com
usuário
• Acesso a serviços (arquivos, etc)
• Portal eventing (comunicação entre iViews)

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

Parte 1 - Conceituações

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

Parte 1 - Conceituações

 Web Dynpro pode ser

acessada através de vários
tipos de dispositivos.
Aspecto importante para
um ambiente empresarial
altamente colaborativo.
 É válido lembrar que em
alguns dispositivos
suportados, nem todos os
recursos estarão
disponíveis.

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

Parte 1 - Perguntas

Página | 7
ABAP Web Dynpro - Fundamentos

Slide 7

Parte 2 – Arquitetura de componentes Web Dynpro (MVC)

Camada de interação com o negócio

Gerencia os dados
Controla qualquer da aplicação sem
intermediação necessária qualquer
entre o negócio e o usuário. Model
preocupação sobre
como serão
Camada de ligação exibidos.

Controller
Camada de interação com usuário

Visualiza os dados
da aplicação sem
qualquer
preocupação sobre
View somo são gerados
Request
ou armazenados.
Response

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

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

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
definição de
Mappings entre os
Contexts.

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

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

Página | 11
ABAP Web Dynpro - Fundamentos

• O Controller que contem o Contex com o Nó Origem não pode ser

um View Controller.
• 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

Parte 2 – Arquitetura de componentes Web Dynpro (MVC)

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.

Página | 13
ABAP Web Dynpro - Fundamentos

• A atualização de todos os nós e atributos correspondentes que

sofreram modificações nos elementos de entrada de dados por
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

Parte 2 – Arquitetura de componentes Web Dynpro (MVC)

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

Parte 2 – Arquitetura de componentes Web Dynpro (MVC)

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

Parte 2 – Arquitetura de componentes Web Dynpro (MVC)

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