Apostila Webdynpro For Abap PDF

Treinamento SAP
Desenvolvimento de Aplicações Web com a Tecnologia SAP

Web Dynpro for ABAP com Introdução a ABAP Objects
Data: 23/01/12
Versão 1.0
Instrutores:
Alexandre Izefler
Consultor SAP NetWeaver PI / WebDynpro for ABAP
aizefler@grupomult.com.br
Antônio Nicácio
Consultor SAP NetWeaver WebDynpro for ABAP
anicacio@grupomult.com.br
Tecnologia da Informação Mult Services Ltda

Rua Rio de Janeiro, 2702, 10º andar
Lourdes, Belo Horizonte, MG, CEP 30160-042
Tel 55 31 3223-0400
www.grupomult.com.br
Treinamento SAP Web Dynpro For ABAP
Índice
1 Sobre o Curso...........................................................................................................................................4
1.1 Duração / Tipo de Treinamento ..........................................................................................................4
1.2 Software release / Ambiente ...............................................................................................................4
1.3 Pré-Requisitos .....................................................................................................................................4
1.4 Publico Alvo.........................................................................................................................................4
1.5 Objetivo ...............................................................................................................................................4
2 Curso Orientado a Projeto ........................................................................................................................5
2.1 Exemplo de Negócio ...........................................................................................................................5
2.2 Casos de Uso ......................................................................................................................................5
2.3 Diagrama entidade relacionamento ................................................................................................. 11
2.4 Diagrama de classes ........................................................................................................................ 12
2.5 Diagrama de componentes .............................................................................................................. 12
3 Introdução .............................................................................................................................................. 14
3.1 Visão Geral Plataforma SAP (Netweaver) ....................................................................................... 14
3.2 Introdução a Linguagem ABAP ........................................................................................................ 15
3.3 ABAP Workbench............................................................................................................................. 16
3.4 Dicionário de Dados ......................................................................................................................... 16
3.5 Client Dependente e Client Independent ......................................................................................... 17
3.6 Tabelas ............................................................................................................................................. 17
3.7 Elemento de Dados .......................................................................................................................... 19
3.8 Domínio ............................................................................................................................................ 19
3.9 Manipulando dados no ambiente SAP ............................................................................................. 19
3.10 Estendendo Programas Standard .................................................................................................... 20
3.11 Transporte de requests .................................................................................................................... 21
4 Introdução ao ABAP Objects ................................................................................................................. 22
4.1 Conceitos de OO .............................................................................................................................. 22
4.2 Introdução a programação Abap Objects ........................................................................................ 23
4.3 Tratamento de exceções baseadas em classes .............................................................................. 30
5 Web Dynpro ........................................................................................................................................... 33
5.1 O que é Web Dynpro ....................................................................................................................... 33
5.2 O que é Web Dynpro for ABAP........................................................................................................ 33
5.3 O que é Web Dynpro for Java .......................................................................................................... 34
5.4 Quais são as semelhanças e diferenças entre as ferramentas? ..................................................... 35
5.5 Benefícios Web Dynpro for ABAP.................................................................................................... 37
5.6 MVC (Model-View-Controller) .......................................................................................................... 37
6 Web Dynpro Arquitetura ........................................................................................................................ 38
6.1 Componentes ................................................................................................................................... 38
6.2 Ciclo de Vida dos Componentes ...................................................................................................... 39
6.3 View .................................................................................................................................................. 39
6.4 Layout’s em Web Dynpro ................................................................................................................. 40
6.5 Window............................................................................................................................................. 44
6.6 Plug e Link’s de Navegação............................................................................................................. 44
6.7 Plugs Inbound e Outbound .............................................................................................................. 45
6.8 Controladores ................................................................................................................................... 48
6.9 Eventos ............................................................................................................................................ 50
6.10 Context ............................................................................................................................................. 52
6.11 Data binding e Mapping ................................................................................................................... 53
6.12 Metodos e Atributos de Sistema ...................................................................................................... 55
6.13 Interface View................................................................................................................................... 57
6.14 Interfaces de Componentes Web Dynpro ........................................................................................ 58
6.15 Web Dynpro Application ................................................................................................................... 58
6.16 Elementos UI WDA .......................................................................................................................... 59
6.17 Fases do Processo de Execução..................................................................................................... 82
6.18 Programação Cross-Component ..................................................................................................... 84
6.19 Wizards ............................................................................................................................................ 85
2
Desenvolvimento de Aplicações Web com a Tecnologia SAP Web Dynpro for ABAP com Introdução a ABAP
Objects
6.20 Classe de Assistência ...................................................................................................................... 85

6.21 Trabalhando com Caixa de Dialogos (Popup) ................................................................................. 86
6.22 Ajuda na Entrada de Dados ............................................................................................................. 86
6.23 Mensagens da Aplicação ................................................................................................................. 87
6.24 ALV (ABAP List Viewer) ................................................................................................................... 88
6.25 Debugging Aplicações Web Dynpro ABAP ...................................................................................... 88
6.26 Dicas de Performance ...................................................................................................................... 91
7 Referências ............................................................................................................................................ 92
Objects
1 Sobre o Curso
Esta seção apresenta as informações permitinentes ao treinamento em questão.
1.1 Duração / Tipo de Treinamento

Cinco dias da semana, distribuídos em 4 horas por dia, somando um total de 20 horas.
Este treinamento será presencial e orientado a projeto, ou seja, a prática é baseada no
desenvolvimento de um problema de negócio que contempla todos tópicos ensinados.
1.2 Software release / Ambiente

SAP NetWeaver 7.02 for ABAP.
MiniSap é o ambiente para pratica do treinamento.
1.3 Pré-Requisitos
Conhecimentos intermediários no desenvolvimento de software com linguagens orientadas a
objetos (C#, JAVA, ABAP Objects e etc).
Conhecimentos básicos no desenvolvimento de software com a linguagem ABAP (ABAP e/ou

ABAP Objects).
1.4 Publico Alvo

Consultores ABAP com objetivos de construir aplicações e executar manutenções de
desenvolvimentos Web com a tecnologia Web Dynpro for ABAP.
Profissionais que desejam conhecer as características desta tecnologia e dos recursos

oferecidos.
Profissionais desenvolvedores de outras tecnologias que desejam migrar para o desenvolvimento

Web Dynpro for ABAP.
1.5 Objetivo
Depois de ter participado deste curso e implementados os cenários do projeto, você terá o
conhecimento suficiente para implementar a nova interface de usuário SAP com a estratégia
baseada na estrutura WD4A (Web Dynpro para ABAP).
O objetivo deste curso é criar uma fundação que pode ser usado com o Portal da Ajuda SAP
(http://help.sap.com) e o SAP Developer Network (http://sdn.sap.com) para atender às exigências
e desafios de novos projetos sobre Web Dynpro ABAP e para encontrar uma solução sempre
quando necessário.
Objects
2 Curso Orientado a Projeto

2.1 Exemplo de Negócio
A empresa XPTO precisa que seja desenvolvido um frontend Web que permita ao departamento
de reservas gerenciar as reservas realizadas pelos atendentes e os supervisores.
Os atendentes criam as reservas, consultam reservas realizadas pelo sistema customizado e

cátalogo de voo, sendo que para criar uma reserva deve ser primeiramente informado o cliente.
Os supervisores além de poder fazer as mesmas funções do atendente ele pode aprovar ou
rejeitar reservas.
2.2 Casos de Uso

Conforme as entrevistas realizadas com os usuários chaves deste negócio, o seguinte diagrama
de casos de uso foi gerado.
Criar Reserva
Consultar Reservas
Atendente <<extend>>
Listar Clientes
Consultar Voos <<extend>>
<<extend>>
Supervisor
Aprovar/Rejeitar Reservas
A seguir são apresentados as descrições dos casos de uso.
• 01 - Caso de Uso – Criar Reserva

Permitir o atendente da Cia Aérea incluir reservas no sistema.
Objects
Pré-condições
• Possuir acesso ao sistema.
• Os dados para os campos de seleção devem existir no armazenamento de dados.
Fluxo Principal
1. Usuário atendente acessa o sistema de reservas
2. Usuário atendente clica no link “Criar Reserva”
3. Sistema apresenta o formulário de cadastro
4. Usuário atendente informa os seguintes campos:
a. Selecionar o cliente [Obrigatório]
b. Selecionar linha aérea [Obrigatório]
c. Selecionar conexão [Obrigatório]
d. Selecionar agencia [Obrigatório]
e. Data do vôo [Obrigatório]
f. Fumante sim ou não
g. Peso da bagagem
h. Unidade da bagagem
i. Primeira classe sim ou não
5. Usuário atendente clica no botão criar reserva
6. Sistema valida a entrada do usuário [FA01] [FA02]
7. Sistema cria a reserva no armazenamento de dados com status “Pendente”
8. Sistema notifica com uma mensagem de sucesso e informando o código da reserva
criada
9. Fim.
Fluxos Alternativos
1. FA01 – Entrada de dados inválidos

a. O usuário deve ser notificado com as mensagens de erros encontrados no
momento da criação da reserva, e a operação deve ser encerrada.
2. FA02 – Validar existência de reserva

a. Deve ser validado se para o cliente selecionado já existe uma reserva, neste
caso deve ser notificado o usuário com a mensagem “Já existe uma reserva para
o cliente XPTO” e o caso de uso é abortado.
b.
Protótipo
Objects
• 02 - Caso de Uso – Consultar Reservas

Permitir o atendente da Cia Aérea consultar reservas no sistema.
Pré-condições
Fluxo Principal
2. Usuário atendente clica no link “Consultar Reserva”
3. Sistema lista os clientes cadastrados [CU05]
4. Usuário atendente seleciona o cliente desejado
5. Sistema apresenta as reservas do cliente
6. Fim.
Fluxos Alternativos
N/A
Protótipo
Objects
• 03 - Caso de Uso – Consultar Catálogo de Voos

Permitir o atendente da Cia Aérea consultar o catálogo de vôos no sistema.
Precondições
Fluxo Principal

2. Usuário atendente clica no link “Consultar Livro de Vôos”
3. Sistema lista os clientes cadastrados [CU05]
4. Usuário atendente seleciona o cliente desejado
5. Sistema apresenta os vôos do cliente
6. Fim.
Fluxos Alternativos
N/A
Protótipo
Objects
• 04 - Caso de Uso – Aprovar/Rejeitar Reservas

Permitir o supervisor da Cia Aérea aprovar/reprovar as reservas no sistema.
Precondições
• Possuir acesso ao caso de uso CU02.
Fluxo Principal
1. Usuário consulta as reservas de um cliente [CU02]
2. Usuário supervisor clica no botão “Aprovar Reserva” [FA01]
3. Sistema cria uma entrada no catálogo de vôo já confirmada
4. O status da reserva é alterado para “Aprovado”
5. Sistema notifica com uma mensagem de sucesso informando o código do catálogo de
vôo e o preço do ticket
6. Fim.
Fluxos Alternativos
1. FA01 – Usuário supervisor clica no botão “Rejeitar Reserva”
a. O status da reserva é alterado para “Rejeitado” e a operação é encerrada.
Protótipo
Objects
• 05 - Caso de Uso – Consultar Clientes

Permitir a consulta de clientes pelo atendente e pelo supervisor no sistema.
Precondições
Fluxo Principal
1. O sistema exibe a listagem de todos os clientes cadastrados no sistema com os

seguintes campos:
a. Número do cliente
b. Nome do cliente
c. Forma de tratamento
d. Rua
e. Caixa Postal
f. Código postal
g. Cidade
h. País
i. Região
j. Número de telefone do cliente
k. Email do cliente
2. Fim.
Fluxos Alternativos
N/A
Protótipo
10
Objects
2.3 Diagrama entidade relacionamento

O diagrama entidade relacionamento apresenta a visão das tabelas envolvidas e seus
relacionamentos.
SCARR SBOOK
SFLIGHT
MANDT CLNT (3) <pk> SPFLI MANDT CLNT(3) <pk,fk1,fk2>
MANDT CLNT(3) <pk,fk>
CARRID CHAR(3) <pk> BOOKID NUMC(8,0) <pk>
MANDT CLNT(3) <pk,fk> CARRID CHAR(3) <pk,fk>
CARRNAME CHAR(20) CARRID CHAR(3) <fk1>
CARRID CHAR(3) <pk,fk> CONNID NUMC(4,0) <pk,fk>
CURRCODE CUKY(5) CONNID NUMC(4,0) <fk1>
CONNID NUMC(4,0) <pk> FLDAT E DAT S <pk>
URL CHAR(255) FLDATE DATS <fk1>
CUSTOMID NUMC(8,0) <fk2>
ZRESERVA
MANDT CLNT(3) <pk,fk1,fk2,fk3,fk4>
ST RAVELAG RESERVAID NUMC(8,0) <pk>
SCUSTOM
CARRID CHAR(3) <fk1>
MANDT CLNT (3) <pk> CONNID NUMC(4,0) <fk1> MANDT CLNT(3) <pk>
AGENCYNUM NUMC(8,0) <pk> FLDATE DAT S <fk1> ID NUMC(8,0) <pk>
CUSTOMID NUMC(8,0) <fk2>
SMOKER CHAR(1)
LUGGWEIGHT QUAN(8,4)
WUNIT UNIT(3)
CLASS CHAR(1)
AGENCYNUM NUMC(8,0) <fk4>
STATUS CHAR(1)
BOOKID NUMC(8,0) <fk3>
Legenda:
SCARR – Contém as informações das companhias aéreas.
SPFLI – Contém as rotas ou conecções oferecidas pelas companhias aéreas da tabela SCARR.
SFLIGHT – Contém os vôos que servem as rotas ou conecções da tabela SPFLI.
SBOOK – Catálogo de voo, contém as reservas para os vôos disponíveis na tabela SFLIGHT.
SCUSTOM - Clientes
STRAVELAG - Agências de viagens
ZRESERVA - Reservas realizadas pela aplicação customizada
11
Objects
2.4 Diagrama de classes

O diagrama de classes a seguir apresenta uma visão das classes e seus relacionamentos.
FlightBooking
FlightCustomer
+ CreateFromData ()
+ GetList ()
+ GetList ()
+ Confirm ()
0..*
0..*
0..*
0..1
0..1
0..1
WD_ASSIST
ZCL_BO_CURSO_RESERVA
+ ReservaInserir ()
+ ReservaListar () + Inserir ()
+ ReservaAprovar () 0..1 + Listar ()
+ ReservaRejeitar () 0..* + Aprovar ()
+ ClienteListar () + Rejeitar ()
+ CatalogoVooListar ()
2.5 Diagrama de componentes

O diagrama de componentes a seguir apresenta uma visão dos componentes WebDynpro e seus
relacionamentos.
12
Objects
13
Objects
3 Introdução
3.1 Visão Geral Plataforma SAP (Netweaver)
A primeira versão do SAP era um sistema de contabilidade financeira chamado R/1 lançado
em 1973.
O SAP R/2 foi uma versão baseada em mainframe que foi muito bem sucedida nos anos
1980 e início dos anos 90.
O SAP R/3 foi lançado em 1992 sendo uma solução de software integrado para
cliente/servidor e sistemas distribuídos. O SAP R/3 é o software de negócios cliente/servidor mais
utilizado no mundo atendendo às necessidades de um cliente de mercearia pequena com 3
usuários às empresas multibilionárias. O software é altamente personalizável utilizando a
linguagem de programação proprietária da SAP, ABAP / 4.
Após a versão 4.6c o SAP R/3 foi renomeado para SAP R / 3 Enterprise e a plataforma foi a
mudança de SAP Basis para SAP Application Web 6.20 Server.
Em 2004 a SAP muda o nome do produto para o mySAP ERP 2004, com o conjunto de
aplicações conhecidos como SAP ECC 5.0, a plataforma técnica mudou de Web AS para SAP
Netweaver 2004, com suporte ao ambiente ABAP e Java.
A última versão é SAP ERP 6.0 com o SAP ECC 6.0, a plataforma técnica SAP Netweaver é 7.0.
SAP NetWeaver é uma plataforma abrangente de aplicativos e integração que trabalha com
a infra-estrutura de TI já existente nas empresas para permitir e administrar mudanças. Com o
SAP NetWeaver, pode-se projetar, construir, implementar e executar novas estratégias
empresariais de forma rápida e flexível, assim como executar novos processos de negócios.
14
Objects
Também é possível conduzir a inovação ao combinar sistemas existentes, enquanto

mantém uma estrutura de custos sustentável.
O SAP Netweaver foi desenvolvido sob uma arquitetura que permite ser totalmente
interoperável com o Microsoft .NET e IBM WebSphere (J2EE), fornecendo aos clientes a
flexibilidade para gerenciar infra-estruturas heterogêneas e minimizar a complexidade.
É um conjunto de tecnologias integradas e metodologias, baseado numa profunda e longa
experiência em desenvolvimento de soluções corporativas, resultando em maior escalabilidade,
tempo contínuo de funcionamento e gerenciabilidade de software, bem como suporte e
extensibilidade ao ciclo de vida.
A plataforma NetWeaver serve ainda como base para a Enterprise Sevices Architecture
(ESA), uma nova infra-estrutura de TI que combina soluções baseadas em serviços em
ambientes heterogêneos e rompe possíveis barreiras técnicas existentes dentro da corporação. A
ESA oferece níveis sem precedentes de adaptabilidade, flexibilidade e abertura, combinando a
experiência da SAP em soluções corporativas com Web Services e outros padrões abertos.
Suporte ao conceito BPM - Business Process Management - Nascendo sob o amparo da
evolução de outras tecnologias (Workflow, GED, EAI, WebServices, etc.), o BPM permite a
análise, definição, execução, monitoramento e administração de processos, incluindo o suporte
para a interação entre pessoas e aplicações informatizadas diversas. O BPM, acima de tudo,
permite que as regras de negócio da organização, na forma de processos, sejam criadas e
informatizadas pelas próprias áreas de gestão, sem interferência das áreas técnicas.
A plataforma SAP Netweaver promove a redução do custo total de propriedade (TCO) ao
facilitar a integração e alinhamento de pessoas, informações e processos de negócios nos limites
organizacionais e tecnológicos.
Sendo assim, a plataforma SAP NetWeaver se traduz na melhor forma de se fazer:
- INTEGRAÇÃO DE PESSOAS - SAP Portals

- INTEGRAÇÃO DE INFORMAÇÕES - SAP BI/BW
- INTEGRAÇÃO DE PROCESSOS - SAP XI
- PLATAFORMA DE APLICAÇÃO - J2EE / ABAP
- Application Server - SAP WAS / WebSphere IBM
Diferenciais SAP NetWeaver:

- Plataforma de integração completa em um único produto.
- Amplo conteúdo de negócios disponível para a camada de integração baseado no
conhecimento da SAP em processos de negócios em mais de 20 diferentes indústrias.
- Arquitetura confiável, escalável, segura e provada em mais de 30 anos de experiência e 20.000
clientes.
- Suporte a Java/J2EE e .Net.
- Composição de novos processos sobre os sistemas existentes.
- Capacidade de oferecer soluções de negócios completas, e não apenas a plataforma técnica.
3.2 Introdução a Linguagem ABAP

O ABAP é uma linguagem de programação originalmente concebida como uma linguagem para
construção de relatórios para o SAP R/2 (o significado original de ABAP é Allgemeiner Berichts
Aufbereitungs Prozessor, que em alemão significa processador genérico para preparação de
relatórios). O objetivo original da linguagem era ser uma ferramenta de programação simples para
15
Objects
ser usada pelos utilizadores finais. No entanto, o ABAP é uma linguagem que necessita de
conhecimentos avançados de programação e é principalmente utilizada pelos programadores da
SAP que desenvolvem o software e por consultores que adaptam o software às necessidades dos
clientes.
O ABAP é a principal linguagem utilizada no software cliente-servidor SAP R/3. Em 1999,
com a versão R/3 4.5, a SAP lançou uma versão de ABAP que suporta programação orientada a
objetos. A versão mais recente da plataforma de desenvolvimento da SAP, o NetWeaver, suporta
programação em ABAP e em Java.
3.3 ABAP Workbench

O componente ABAP Workbench (transação SE80) é um ambiente de desenvolvimento completo
para aplicações na linguagem ABAP. Com ele, você pode criar, editar, testar e organizar estes
programas de aplicação. É totalmente integrado no NetWeaver AS ABAP e com outras aplicações
ABAP e possui como principais ferramentas integradas:
• ABAP Editor para escrever e editar relatórios programas, sub-rotinas, módulos (SE38)
• ABAP Dictionary para definições de tabelas, dados (SE11)
• Menu Painter para projetar a interface de usuário (barra de menus, barra de ferramentas
padrão, barra de ferramentas do aplicativo) (SE41)
• Screen Painter para projetar telas e lógica de fluxo (SE51)
• Function Bulilder para módulos de função (SE37)
• Class Builder para as classes ABAP Objects e interfaces (SE24)
3.4 Dicionário de Dados

O Dicionário ABAP é usado para criar e administrar definições de dados. Habilita todos os
dados usados no sistema a serem descritos centralmente, sem redundância.
Todos os dados que entram no Dicionário ABAP estão disponíveis ao longo do sistema SAP.
Alterações entram em vigor em todos os componentes pertinentes ao sistema pelo mecanismo de
ativação.
O Dicionário ABAP é um componente ativo, integrante do ABAP Development Workbench.
Os objetos do Dicionário ABAP são utilizados na maioria dos programas, portanto torna-se
essencial na programação o seu conhecimento.
Mudanças feitas no dicionário afetam imediatamente os programas evolvidos e telas de ABAP.
Os objetos básicos para definir dados no Dicionário ABAP são: tabelas, domínios e
elementos de dados.
Tabelas são usadas para o armazenamento físico dos dados.
Domínios são usados para a definição técnica de um campo de tabela (por exemplo: tipo de
campo, tamanho de campo).
Elementos de dados são usados para a definição semântica (por exemplo: descrição pequena).
As tabelas são responsáveis pelo armazenamento físico dos dados.
O SAP possui suas tabelas standards as quais armazenam todos os dados de negócio do cliente
através dos módulos, e permite também a criação de tabelas novas. Após criá-las e ativá-las no
16
Objects
Dicionário de ABAP , elas são geradas automaticamente pelo utilitário do banco de dados no
banco de dados.
Uma estrutura corresponde a uma série de campos agrupados sob um nome comum. É
muito semelhante a uma tabela, porém não existe armazenamento de dados físicos nela, apenas
seu esqueleto é usado. Como uma tabela, ela pode ser utilizada dentro de um programa na
instrução TABLES para definir uma área de trabalho.
Matchcodes são utilizados com Help online (F4) para acessar dados gravados por meio de um
critério suplementar onde a chave é desconhecida.
• Se você relacionar um campo com um objeto do Dicionário de ABAP através do search

help, valores possíveis são automaticamente disponibilizados para você.
• Escolha a tecla F4, o sistema aciona no dicionário a verificação do search help,
associando um campo diretamente ou indiretamente.
• Se este for o caso o search help correspondente será mostrado em caixa de dialogo.
• Um search help definido do dicionário permite a possibilidade de selecionar os dados que
você necessita.
3.5 Client Dependente e Client Independent

Estes conceitos estão ligados a estrutura de dados do sistema, tabelas e relacionamentos.
Deve-se entender que Client Dependent são tabelas ligadas a um único Mandante, isto é, uma
determinada tabela somente é válida para o ambiente mandante no qual se efetuou o login.
Mandante é uma unidade autônoma dentro do sistema SAP que separa os registros
mestres e seu próprio conjunto de tabelas e dados. Explicando, são núcleos de sistemas SAP R/3
independentes, como se fossem servidores distintos, os quais são utilizados para várias tarefas
distintas, como implantação, testes, aprendizado, etc.
Deve-se entender que Client Independent são tabelas que não estão ligadas a um
Mandante específico, isto é, uma determinada tabela é válida para todos os Mandantes de uma
Instância.
Na prática estes conceitos são caracterizados pelo primeiro campo de uma tabela. Para
uma tabela Client Dependent este campo é sempre do tipo CLNT, com tamanho de 03 posições e
por convenção é sempre identificado como MANDT. Se o primeiro campo não for do tipo CLNT, a
tabela é Client Independent.
3.6 Tabelas
Há no dicionário de dados três tipos de tabelas: Transparentes, Pool e Cluster. O primeiro
tipo é o mais comum e provavelmente sempre será o tipo a ser utilizado ao se criar uma nova
tabela em customizações do sistema. Pool e cluster são tipos de armazenamentos proprietários
da SAP.
• Transparente: Uma tabela transparente no dicionário tem relacionamento um-para-um com
uma tabela no banco de dados. Sua estrutura no dicionário de dados corresponde a uma
única tabela de banco de dados. Para cada definição de tabela transparente no dicionário,
há uma tabela associada no banco de dados. A tabela de banco de dados tem o mesmo
nome, o mesmo número de campos e os campos têm os mesmos nomes que a definição
17
Objects
de tabela do ERP. Quando examinar a definição de uma tabela transparente do ERP você
pode achar que está olhando para a própria tabela de banco de dados.
• Pool: Uma tabela de pool tem um relacionamento muitos-para-um com uma tabela no
banco de dados. Para uma tabela no banco de dados, há muitas tabelas no dicionário de
dados do ERP. A tabela no banco de dados tem um nome diferente do das tabelas no
dicionário de dados, tem um número de campos diferente e os campos também têm
nomes diferentes. O ERP utiliza pools de tabela para armazenar um grande número
(dezenas a milhares) de tabelas muito pequenas (aproximadamente de 10 a 100 linhas
cada uma). Os pools de tabela reduzem a quantidade de recursos de banco de dados
necessários quando muitas tabelas pequenas têm de ser abertas ao mesmo tempo. A SAP
os utiliza para dados de sistema.
• Cluster: São utilizadas para armazenar dados de algumas (aproximadamente de 2 a 10)

tabelas maiores. As tabelas de cluster seriam utilizadas quando essas tabelas tivessem
uma parte de suas chaves primárias em comum e se os dados nessas tabelas fossem
todos acessados simultaneamente. Os clusters de tabela contêm menos tabelas que os
pools de tabela e, diferente dos pools de tabela, a chave primária de cada tabela dentro do
cluster de tabelas começa com o mesmo campo ou campos. As linhas das tabelas de
cluster são combinadas em uma única linha no cluster de tabelas. As linhas são
combinadas com base na parte da chave primária que elas têm em comum. Assim, quando
uma linha é lida de qualquer uma das tabelas no cluster, todas as linhas relacionadas em
todas as tabelas de cluster também são recuperadas, mas apenas uma única operação de
I/O é necessária. Um cluster é vantajoso no caso em que os dados são acessados a partir
de múltiplas tabelas simultaneamente e essas tabelas têm pelo menos um de seus campos
de chave primária em comum. As tabelas de cluster reduzem o número de leituras do
banco de dados e assim melhoram o desempenho.
As tabelas de pool e de cluster são normalmente utilizadas somente pela SAP e não pelos
desenvolvimentos dos clientes, provavelmente por causa do formato proprietário dessas tabelas
dentro do banco de dados e por causa das restrições técnicas colocadas sobre sua utilização
dentro dos programas ABAP/4, como a seguir:
• Não se pode criar índices secundários;
• Não se pode utilizar select distinct ou group by;
• Não se pode utilizar SQL nativo;
• Não se pode especificar nomes de campos depois da cláusula order by. A única variação
permitida é order by primary key.
• No caso específico das tabelas de cluster, não é possível realizar leitura através de joins,
nem a criação de views.
Uma tabela deverá ser buferizada quando:

Tabela pequena, com poucas linhas ou poucas colunas com tamanho de campos pequenos
Mais acessada para leitura
Alterações não ocorrem freqüentemente
Tabelas de controle/tabelas de customização são boas candidatas a buferização.
18
Objects
3.7 Elemento de Dados

Contém os rótulos de campo e a documentação on-line (ajuda F1) para o campo. Ele é
puramente descritivo, contém as características semânticas para o campo, também conhecidas
como “contexto do negócio”. Os rótulos que você oferece dentro de um elemento de dados serão
exibidos na tela ao lado de um campo de entrada. O elemento de dados também contém
documentação que é exibida quando o usuário pede ajuda nesse campo pressionando a tecla F1.
3.8 Domínio
Contém a característica técnica de um campo, como o comprimento do campo e o tipo de
dado. Tanto o domínio quanto o elemento de dados são objetos independentes que podem ser
utilizados em diversos campos de diversas tabelas. Deve-se porém, tomar as devidas precauções
quando da atribuição destes objetos aos campos de tabelas, uma vez que a alteração de um
elemento de dados ou de um domínio implica na alteração das características de todos os
campos que estejam utilizando este(s) objetos(s) alterados.
3.9 Manipulando dados no ambiente SAP

Open SQL é uma linguagem de manipulação de dados (DML) que compõem um
subconjunto do padrão SQL, que é totalmente integrado com o ABAP. O acesso aos dados é
realizado independentemente do sistema de banco de dados instalado no ERP (Oracle, SQL
Server).
Além disso, o Open SQL vai além padrão SQL, fornecendo instruções que podem simplificar
ou acelerar o acesso de banco de dados em conjunto com outras construções ABAP. Utilizando o
Open SQL é possível criar armazenamento em buffer de tabelas, reduzindo o acesso excessivo
ao banco de dados. Os dados nos buffers são sincronizados em intervalos definidos pelo
gerenciamento de buffer
Algumas palavras-chave Open SQL:
SELECT - Lê dados de tabelas de banco de dados.
INSERT - Acrescenta linhas em tabelas de banco de dados.
UPDATE - Ele muda o conteúdo de linhas de tabelas de banco de dados.
MODIFY - Insere linhas em tabelas de banco de dados ou altera o conteúdo das linhas
existentes.
DELETE - Apaga linhas de tabelas de banco de dados.
CURSOR OPEN, FETCH, CLOSE CURSOR - Lê-se linhas de tabelas de banco de dados usando
o cursor.
Os dois campos do sistema são preenchidos com os códigos de retorno por todas as declarações
Open SQL:
19
Objects
SY-SUBRC: O campo de sistema SY-SUBRC contém o valor 0 após cada declaração Open SQL
se a operação foi bem sucedida.
SY-DBCNT: O campo de sistema SY-DBCNT contém o número de linhas do banco de dados

processados depois de uma instrução SQL aberto.
3.10 Estendendo Programas Standard

Existem 4 maneiras diferentes de se modificar o sistema SAP segundo as suas necessidades:
Customização: Configuração do sistema através do uso de parâmetros específicos de uma

interface especialmente criada para isto. As possíveis modificações podem ser pré planejadas e
organizadas. Customização é sempre requerida durante as implantações do sistema.
Modificações no Standard SAP: Alterações no Repositório de objetos SAP em forma de

mudanças de desenvolvimento, quando as mudanças desse tipo ocorrem, a versão customizada
e a nova versão do SAP precisam ser reconciliadas manualmente.
Conceito de Enhancement: Alterações no Repositório SAP, porém sem mudanças no Standard.
Desenvolvimento do Cliente: Criação de objetos dentro do escopo possível de nomes

permitidos ( Z e Y ).
Antes de modificar, sempre verifique se as suas necessidades não podem ser feitas através da
Customização ou do conceito de Enhancement.
Enhancements (Ampliações)
São aberturas do sistema disponibilizadas pela SAP para fazer customização nos programas,
telas, menus e tabelas.
1-Se desenvolvida corretamente, as alterações não irão afetar os outros países.

2- A aplicação de Hot Packages não irá apagar as alterações
3-Durante o upgrade a alteração não será apagada pela SAP, porém será necessário analisa-la /
testa-la.
4- A alteração é feita em uma área permitida pela SAP. Portanto, o suporte SAP para o programa
está mantido.
O programador tem as possíveis modificações quando estiver criando projetos de Enhancements:

User-Exit: Criando módulos de função com as partes administrativas, de interface e
documentação.
Menu-Exit: Definindo Códigos de Funções Novos para os Menus
Screen-Exit: Definindo áreas específicas nas sub-telas do SAP.
Como um programador, você pode implementar então os seguintes Enhancements:

20
Objects
Escrever seu próprio código nas funções do SAP ( User-Exit )

Definir novos Códigos de Função (Menu Exits )
Criar subtelas para as áreas de sub-tela Standards(Screen-Exits)
Adicionar novas funções para os elementos de dados ( Field-Exits )
3.11 Transporte de requests

Request é uma funcionalidade utilizada para registrar todas as modificações feitas em objetos
desenvolvidos e/ou customizados. Estas modificações são organizadas em tarefas e
transportadas entre ambientes do sistema após a liberação do processo de Change Request.
Associando objetos à Request assegura-se que todas as modificações feitas no Abap
Workbench serão registradas, possibilitando inclusive o controle das diversas versões de um
objeto.
As change requests do tipo customizing são reservadas para transportar conteúdo de tabelas
do tipo customizing, que são tabelas que contém informações de configuração dos módulos
funcionais (FI, MM, SD etc.) ou configurações do sistema.
Já as change requests do tipo Workbench são para os outros tipos de objetos do repositório,
como packages, tabelas transparentes, classes e programas.
21
Objects
4 Introdução ao ABAP Objects

4.1 Conceitos de OO
Orientação a objeto é um método de resolução de problemas no qual o solução do software
reflete objetos do mundo real.
Sistemas de software complexos se tornam mais fáceis de serem compreendidos, já que a
estrutura orientada a objeto fornece uma representação muito mais próxima da realidade do que
as outras técnicas de programação.
Em um sistema orientado a objeto bem desenvolvido, é possível implementar mudanças a
nível de classe, sem ter que realizar alterações em outros pontos do sistema. Isto reduz a
quantidade total de manutenção requerida.
Através do polimorfismo e herança, a programação orientada a objeto permite que reutilize
componentes individuais.
Em um sistema orientado a objeto, a quantidade de trabalho de manutenção e revisão
envolvido é reduzido, já que muitos problemas podem ser detectados e corrigidos em fase de
projeto.
Objetos
Um objeto é seção de código fonte e que contém dados e fornece serviços. Os dados
formam os atributos do objeto. Os serviços são conhecidos como métodos (também conhecido
como operações ou funções). Tipicamente, métodos operam em dados privados (os atributos, ou
estado do objeto), que é apenas visível para os métodos do objeto. Logo os atributos de um
objeto não pode ser modificado diretamente pelo usuário, mas apenas pelos métodos do objeto.
Isso garante a consistência interna do objeto.
Classes
Classes descrevem objetos. De um ponto de vista técnico, objetos são instâncias em
tempo de execução de uma classe. Em teoria, você pode criar qualquer número de objetos
baseados em uma única classe. Cada instância (objeto) de uma classe tem uma identidade única
e seu próprio conjunto de valores para seus atributos.
Referências a Objetos
Em um programa, você identifica e endereça objetos usando referências únicas a objetos.
Referências a objetos permite que acesse os atributos e métodos de um objeto.
Encapsulamento
Objetos restringem a visibilidade de seus recursos (atributos e métodos) aos outros
usuários. Todo objeto tem uma interface que determina como os outros objetos podem iteragir
com ele. A implementação do objeto é encapsulada, isso é, invisível fora do próprio objeto.
Polimorfismo
Métodos idênticos (mesmo nome) se comportam diferentemente em diferentes classes.
Orientação orientada a objeto contém construções chamadas interfaces. Elas permitem que
enderece métodos com mesmo nome em diferentes objetos. A implementação do método é
específica para cada um classe.
Herança
22
Objects
Você pode usar uma classe existente para derivar uma classe nova. Classes derivadas
herdam os dados e métodos da superclasse. No entanto, eles podem substituir métodos
existentes, e também adicionar novos.
Modelamento orientado a objeto

O modelamento orientado a objeto de um sistema de software é o mais importante, mais
demorado, e o requerimento mais difícil para alcançar os objetivos. Design orientado a objeto
envolve mais do que apenas programação orientada a objeto e fornece vantagens lógicas que
são independentes da verdadeira implementação.
4.2 Introdução a programação Abap Objects

Antes do R/3 Release 4.0, o equivalente mais próximo de objetos no ABAP eram módulos
de funções e grupos de funções. A diferença principal entre a real orientação a objeto e grupo de
funções é que apesar de um programa poder trabalhar com instâncias de diversos grupos de
funções simultaneamente, ele não pode trabalhar com diversas instâncias do mesmo grupo de
funções.
Objetos ABAP permite que você defina dados e funções em classes ao invés de grupo de
funções. Usando classes, um programa ABAP pode trabalhar com qualquer número de instâncias
(objetos) baseados no mesmo template (classes).
Ao invés de carregar uma única instance de um grupo de funções dentro de uma memória
implícita quando um modulo é chamado, o programa ABAP pode agora gerar as instâncias de
classes explicitamente.
ABAP Objects
ABAP Objects é o termo dado para programação orientada a objeto feito em ABAP, este
modelo de programação une dados e funções. OO ABAP é construído em linguagem ABAP
existente e são executados no mesmo ambiente que os programas normais ABAP. OO ABAP faz
parte da ABAP desde R / 3 versão 4.0
Classe
Classe é um protótipo que define os dados e o comportamento comum a todos os objetos

de certo tipo. Podemos dizer classes descrevem objetos.
Classes podem ser declaradas globalmente ou localmente. Classes globais podem ser
declaradas utilizando a transação SE24. Classes locais são declarados em um programa ABAP
(relatórios etc).
23
Objects
Objetos
Objetos são instâncias de uma classe. Nós podemos criar qualquer número de objetos a
partir de um modelo de classe. Todos os objetos criados têm identidade única e cada um contém
conjunto diferente de atributos. Objetos que criamos em um programa só existem enquanto o
programa existir. Para instânciar objetos utilizamos o comando ABAP CREATE OBJECT.
Encapsulamento
Por meio de encapsulamento nos restringir a visibilidade dos atributos e métodos no

objeto. Existem três níveis de visibilidade em OO ABAP.
• Público
• Protegido
• Privado
24
Objects
Nas classes, há normalmente uma divisão estrita entre o público e o protegido ou privado,
mas em alguns casos, as classes precisam trabalhar juntas precisando de acesso aos
componentes uns dos outros protegidos ou privados.
Uma classe pode conceder a outras classes e interfaces a sua “amizade”. Para isto é
necessário acrescentar o comando FRIENDS na definição da classe. Ex: CLASS ... DEFINITION
LOCAL FRIENDS cif1 ... cifn.
A “amizade” é unilateral: Uma classe de concessão de uma amizade não é
automaticamente um amigo de seus amigos e se a classe de concessão a “amizade” quer
acessar os componentes privada de um amigo, então este último tem de conceder explicitamente
a “amizade” à primeira.
Herança
Em ABAP OO, utilizamos uma classe existente para derivar uma nova classe, a nova
classe contém os atributos da classe pai (deriva de acordo com a visibilidade dos atributos e
métodos), além de novos atributos e métodos adicionados a ele. A classe filha deriva todos os
atributos e métodos declarados na classe pai como a visibilidade pública. A classe filha não pode
herdar membros privados. Os membros protegidos da classe pai são derivados para a classe filha
alterando a sua visibilidade para o privado.
25
Objects
A parte esquerda do gráfico demonstra como você pode derivar uma subclass c2 de uma
superclasse c1 usando a adição INHERTING FROM no comando CLASS. A parte direita do
gráfico demonstra como a distribuição da subclasse dentro da árvore de herança, que alcança
classe vazia default OBJECT. Uma subclass contém todos os componentes declarados acima
dela na árvore de herança, e pode endereçar todas elas que são declaradas públicas ou
protegidas.
26
Objects
Este gráfico ilustra herança simples. Uma classe pode apenas ter uma superclasse direta,
mas pode ter mais do que uma subclasse direta. A classe vazia OBJECT é o nó-raiz de toda
árvore de herança em objetos ABAP.
As adições ABSTRACT e FINAL nos comandos METHODS e CLASS permitem que você
defina métodos e classes abstratos e finais.
Um método abstrato definido dentro de uma classe abstrata e não pode ser implementado
naquela classe. Ao invés, é implementada em uma subclasse da classe. Classes abstratas não
podem ser instanciadas. Um método final não pode ser redefinido em uma subclasse. Classes
finais não podem ter subclasses. Eles concluem uma árvore de herança.
Polimorfismo
O nome do método é o mesmo, mas eles se comportam de forma diferente em classes

diferentes. Que significa a implementação do método (ou seja, o corpo do método) é diferente em
classes diferentes. Ele pode ser alcançado de duas maneiras diferentes em OO ABAP.
• Interfaces
• Substituição de métodos ou redefinindo os métodos de cada classe após a herança
Este gráfico demonstra como variáveis referenciais definidas com referência para uma
superclasse pode indicar objetos de subclasses. O objeto a direita é uma instancia da classe
class3. As variáveis referenciais de classe CREF1, CREF2, e CREF3 são digitadas com
referência a class1, class2, e class3. Todas as três indicam ao objeto. No entanto, CREF1 pode
apenas endereçar os componentes públicos da classe class1, CREF2 pode endereçar os
componentes públicos da class1 e class2. CREF3 pode endereçar componentes públicos de
todas as classes.
Se você redefinir um método de uma superclasse em uma subclasse, você pode usar uma
variável referencial definida com referência a superclass para endereçar objetos com diferentes
implmentações de métodos.. Quando você endereça a superclasse, o método tem a
implementação original, mas quando você endereça a subclasse, o método tem a nova
27
Objects
implementação. Usando uma simples variável de referência para chamar métodos com mesmo
nome que se comportam diferentemente é chamado polimorfismo.
Interfaces
Interfaces são definidas como classes. Eles também contêm atributos e métodos. Mas as
interfaces não têm parte de implementação. Seus métodos são implementados na classe que
implementa a interface.
Então, é fornecida uma implementação diferente para os métodos definidos na interface em
classes diferentes que implementam a interface, esta é uma das formas de obter o polimorfismo.
A figura a esquerda do diagrama demonstra a definição de uma interface local I1 e as

partes da declaração e implementação da classe local C1 que implementa a interface I1 em sua
seção pública. O método de interface I1~M1 é implementado na classe. Você não pode
implementar interfaces em outras seções de visibilidade.
A figura a direita ilustra a estrutura da classe com os componentes em suas respectivas

áreas de visibilidade, e a implementação dos métodos. Os componentes da interface ampliam o
corpo público da classe. Todos os usuários podem acessar os components públicos específicos
da classe e daqueles da interface.
Para criar um objeto da classe <class>, você deve primeiro ter declarado uma variável
referencial <cref> com referência a classe. Se a classe <class> implementa uma interface <intf>,
28
Objects
você pode usar a seguinte atribuição entre a variável referencial da classe <cref> e uma
referência de interface <iref> para fazer com que a referência de interface em <iref> indique o
mesmo objeto da referência de classe <cref>:
<iref> = <cref>
Se a interface <intf> contém um atributo de instance <attr> e um método de instance

<meth>, você pode endereçar os componentes da interface como a seguir:
Usando a variável referencial de classe <cref>:

Para acessar um atributo <attr>: <cref>-><intf~attr>
Para chamar um método <meth>: CALL METHOD <cref>-><intf~meth>
Usando a variável referencial de interface <iref>:

Para acessar um atributo <attr>: < iref>-><attr>
Para chamar um método <meth>: CALL METHOD <iref>-><meth>
Em relação a componentes estáticos de interfaces, você pode apenas utilizar o nome da

interface para acessar constants:
Endereçando uma constante <const>: < intf>=><const>
Endereçando um atributo estático <attr>: < class>=><intf~attr>

Chamando um método estático <meth>: CALL METHOD <class>=><intf~meth>
Assim como referênciais de classes, você pode atribuir referências de interfaces para
diferentes variáveis referenciais. Você pode também fazer atribuições entre ariáveis referenciais
de classes e variáveis referenciais de interfaces. Quando você usa o comando MOVE ou o
operador de atribuição (=) para atribuir variáveis referenciais, o sistema deve estar apto a
reconhecer na verificação de sintaxe se a tribuição é possível.
Suponha que tenhamos uma referência de classe <cref> e referências de interfaces <iref>,
<iref1>, e <iref2>.
As seguintes atribuições com referências de interfaces podem ser checadas estaticamente:
<iref1> = <iref2>
Ambas referências de interfaces devem indicar à mesma interface, ou a interface de <iref1> deve
conter a interface <iref2> como um componente.
<iref> = <cref>
A classe da referência de classe <cref> deve implementar a interface da referência de interface
<iref>.
<cref> = <iref>
A classe de <cref> deve ser predefinida como a classe vazia OBJECT.
Em todos os outros casos, você teria que trabalhar com o comando MOVE …?-TO ou o casting
operator (?=). O casting operator substitui o operador de atribuição (=). No comando MOVE…?-
29
Objects
TO, ou quando você utiliza o casting operator, não há verificação de tipo estático. Ao invés, o
sistema verifica em tempo de execução se a referência do objeto na variável de origem indica um
objeto cuja referência de objeto no alvo a variável também pode indicar. Se a atribuição é
possível, o sistema a faz, senão, o erro em tempo de execução MOVE_CAST_ERROR ocorre.
Você deve sempre usar casting para atribuir uma referência de interface a uma referência de
classe se <cref> não indica a classe predifinida vazia OBJECT:
<cref> ?= <iref>
para o casting ter sucesso, o objeto o qual <iref> indica deve ser um objeto da mesma classe
como o tipo da variável de classe <cref>.
Classes persistentes
Para usar o serviço de persistência para os objetos, as classes desses objetos devem ser
criados como classes persistentes no Construtor da classe. O termo classe persistente não
implica que uma classe é persistente. (Como um modelo de objetos, toda classe é persistente).
Pelo contrário, significa que os objetos dessa classe e seu estado são geridos pelo Serviço
de Persistência. Por exemplo, os objetos dessas classes são instanciados no programa ABAP
com um método do serviço de persistência, o que garante que a inicialização está correta (não
com utilização do comando CREATE OBJECT).
Quando o Class Builder cria uma classe persistente, ele automaticamente gera uma classe
associada, conhecido como classe ator ou classe agente, cujos métodos gerenciam os objetos de
classes persistentes. Bem como a sua identidade, classes persistentes pode conter atributos-
chave que permitem que o serviço de persistência garanta que o conteúdo de cada objeto
persistente é único.
4.3 Tratamento de exceções baseadas em classes

A ocorrência de uma exceção é utilizada para mostrar uma situação de erro, o uso de
exceções baseadas em classe é um novo conceito para tratamento de exceções ocorridas em um
código ABAP e não se restringe apenas a ABAP Objects, pelo contrário, exceções baseadas em
classe são projetados para substituir os conceitos anteriores para tratamento de exceções.
Exceções baseadas em classe pode, portanto, ser levantadas e tratadas em todos os contextos
ABAP (programas, blocos de processamento). Em particular, todos os erros de execução
capturáveis da forma antiga podem ser tratadas como exceções baseadas em classe.
Exceções baseadas em classe são levantadas pela instrução RAISE EXCEPTION ABAP ou
pelo ambiente de execução ABAP. Se uma exceção baseada em classes ocorre, o sistema
interrompe o fluxo normal do programa e tenta encontrar um manipulador adequado. Se ele não
encontrar um manipulador, um erro de execução ocorre.
30
Objects
Bloco TRY
O bloco TRY contém a codificação de aplicações cujas exceções devem ser tratadas. Este bloco
de declaração é processada sequencialmente. Ele pode conter estruturas de controle além de
chamadas de procedimentos ou outros programas ABAP.
Bloco CATCH
Um bloco catch contém o manipulador de exceção que é executado quando uma determinada
exceção ocorre no bloco TRY. Uma estrutura TRY ENDTRY pode conter vários manipuladores de
exceção. Após ocorrer uma exceção o sistema procura pelo manipuladores de exceções listadas
na ordem especificada e a verificação de sintaxe garante que os manipuladores sejam listados de
exceções mais específicas para exceções mais gerais (superclasses).
Bloco CLEANUP
Se o sistema não encontrar um manipulador para uma exceção em uma estrutura TRY ENDTRY,
mas encontrar um manipulador em uma estrutura TRY ENDTRY externa ou tentar propagar a
exceção para o chamador do procedimento o bloco CLEANUP é executado antes de sair da
estrutura TRY ENDTRY.
Os atributos de um objeto de exceção pode conter informações sobre a situação do erro.

Todas as classes de exceção são parte de uma hierarquia de herança com uma superclasse
comum, CX_ROOT. Classes de exceção são subclasses das seguintes classes globais, que
determinam o comportamento para propagação da exceção :
• CX_STATIC_CHECK
• CX_DYNAMIC_CHECK
• CX_NO_CHECK
• Se as exceções que são definidas usando as subclasses de CX_STATIC_CHECK são

propagadas a partir de um método, elas devem ser explicitamente declarados na interface do
método. A verificação de sintaxe estaticamente verifica se todas as exceções desencadeadas no
método usando RAISE EXCEPTION ou declaradas nas interfaces dos métodos são manipulados
com CATCH ou são declarados explicitamente na interface. Se não for, a verificação de sintaxe
emite um aviso.
31
Objects
• Se as exceções que são definidas usando as subclasses de CX_DYNAMIC_CHECK são

propagadas a partir de um método, eles devem ser declarados explicitamente na interface do
método. Este não é, porém, verificado estaticamente pela verificação de sintaxe, mas é verificada
de forma dinâmica, em tempo de execução.
• Exceções que são definidas usando as subclasses de CX_NO_CHECK não devem ser
declaradas explicitamente na interface do método. O classe CX_NO_CHECK e suas subclasses
são implicitamente sempre declaradas e são sempre propagadas através do método.
32
Objects
5 Web Dynpro
5.1 O que é Web Dynpro

Web Dynpro é a tecnologia da SAP UI para desenvolvimento de aplicações empresariais
que possuem interfaces de usuários baseadas na Web. Consiste em um ambiente de execução e
um ambiente gráfico de desenvolvimento com ferramentas especiais que são integrados em
ABAP ou ambientes de desenvolvimento Java.
Web Dynpro é baseado em uma arquitetura poderosa e flexível que utiliza o padrão de
desenho Model-View-Controller. Esse padrão cria uma separação clara de interfaces de usuário
dos serviços de back-end e lógica de negócios, suporta reutilização e melhor manutenção,
extensibilidade e flexibilidade (usando componentes), e fornece ferramentas gráficas declarativas
para minimizar os esforços de desenvolvimento.
Além disso, a definição da interface do Web Dynpro é independente da tecnologia de

cliente, portanto, a aplicação Web Dynpro pode rodar em diferentes plataformas (browsers, rich
clients, dispositivos móveis e clients de futuras tecnologias) sem desenvolvimento ou
configuração adicional.
5.2 O que é Web Dynpro for ABAP

ABAP (Advanced Business Application Programming) é uma linguagem de programação
proprietária para desenvolvimento de aplicativos de negócios dentro de um sistema SAP.
Web Dynpro ABAP (WDA) é o principal padrão de tecnologia SAP UI para o desenvolvimento de
interfaces de usuário para aplicativos Web no ambiente ABAP. Consiste em um ambiente de
execução e um ambiente gráfico de desenvolvimento com ferramentas especiais que são
completamente integrados no ambiente de desenvolvimento ABAP - o ABAP Workbench
(transação SE80):
33
Objects
Esta integração total com o ambiente de desenvolvimento ABAP fornece acesso direto aos
dados ABAP, lógica de negócios e Ajuda a Pesquisa no Dicionário de Dados.
WDA está disponível desde Outubro de 2005 (SAP NetWeaver 7.0 (2004s) - Web
Application Server 7.0) e é amplamente utilizada pela SAP Business Suite e continuará a ser a
tecnologia UI de escolha para aplicações Suíte principais de negócios (ERP, PLM, SCM , SRM,
FIM).
5.3 O que é Web Dynpro for Java

Java é um padrão, uma plataforma de linguagem de programação independente e orientada
a objetos para desenvolvimento de aplicações de negócios baseadas na web.
WDJ é o padrão de tecnologia SAP UI para o desenvolvimento de interfaces de usuário de

aplicativo da Web no ambiente Java. Consiste em um ambiente de execução Java / JEE e um
ambiente de desenvolvimento baseado em Eclipse (3.x) - o SAP NetWeaver Developer Studio,
que oferece um ambiente de desenvolvimento para facilmente projetar, desenvolver, implementar
e manter aplicações de negócios.
34
Objects
5.4 Quais são as semelhanças e diferenças entre as ferramentas?

Web Dynpro Java e ABAP possuem recursos semelhantes para a criação de interfaces de
usuário, mas também possuem recursos e capacidades únicas e algumas diferenças:
35
Objects
Tal como é descrito pelo diagrama acima, ambas as ferramentas web-based criam UIs de
aplicativos de negócios e utilizam os padrões de projeto MVC para suportar uma separação
estrita de negócio e lógica de apresentação.
Além disso, ambos apoiarão (em EhP1) a integração com consoles de alta interatividade
para enriquecer a base Web Dynpro oferecendo UI com alta qualidade, modelos animados e mais
ricos com Islands Flash ou Silverligth (Integração).
Naturalmente, também há diferenças, principalmente porque WDJ é implementado em Java

e oferece um ambiente de desenvolvimento baseado em Eclipse, enquanto WDA é implementado
em ABAP e completamente integrado na pilha ABAP.
36
Objects
Com WDJ, os desenvolvedores podem criar suas aplicações de interface de usuário com
base em várias fontes de dados tais como web services ou EJBs para anexar nas UIs, e também
possui integração com o novo BPM (Business Process Modeling) da ferramenta (estará
disponível com CE7.1.1) .
Por outro lado, quando usando a lógica de negócio padrão SAP dos sistemas operacionais é
muito mais fácil de acessá-lo usando WDA e consumir os dados diretamente do sistema através
da codificação nativa ABAP. Além disso, WDA oferece um repositório de MIME para gerenciar e
utilizar diferentes objetos, como gráficos e ícones.
5.5 Benefícios Web Dynpro for ABAP

Web Dynpro oferece as seguintes vantagens para os desenvolvedores de aplicação:
• O uso de ferramentas gráficas declarativa reduzindo significativamente o esforço de

implementação
• Separação rigorosa entre layout e dados de negócio
• Reutilização e melhor sustentabilidade, utilizando componentes
• O layout e a navegação pode ser facilmente alterada utilizando as ferramentas de Web
Dynpro
• Aplicações Stateful são suportados - isto é, se a página é alterada e os dados necessários
permanecem intactos para que você possa acessá-lo a qualquer momento em todo o
contexto da aplicação inteira
• Transporte automático de dados utilizando a ligação de dados (binding)
• Verificação de entrada automática
• Acessibilidade da interface do usuário é suportado
• A plena integração no ambiente de desenvolvimento ABAP
5.6 MVC (Model-View-Controller)

Model-view-controller (MVC) é um modelo de desenvolvimento de Software, atualmente
considerado uma "arquitetura padrão" utilizada na Engenharia de Software. O modelo isola a
"lógica" (A lógica da aplicação) da interface do usuário (Inserir e exibir dados), permitindo
desenvolver, editar e testar separadamente cada parte.
37
Objects
6 Web Dynpro Arquitetura

6.1 Componentes
Componente Web Dynpro é uma entidade reutilizável.
O conceito de componente Web Dynpro oferece uma série de vantagens:
■ Estruturação da programação
■ Criação de blocos de aplicação facilmente gerenciáveis
■ Reutilização de componentes
O componente Web Dynpro contém qualquer número de Windows e Views e seus

controladores correspondentes.
A criação de um componente Web Dynpro é sempre obrigatória, pois a existência das

Windows, das views e dos controladores que ele contém está ligada à existência do próprio
componente. A comunicação entre os elementos de dois componentes Web Dynpro é
implementado usando as interfaces de componentes, por isso não faz sentido considerar as
partes individuais do componente separadamente.
O componente Web Dynpro pode incorporar outros componentes Web Dynpro, e

consequentemente um componente Web Dynpro pode ser incorporado em qualquer outro
38
Objects
componente Web Dynpro. Esta comunicação ocorre também sobre as interfaces dos
componentes.
6.2 Ciclo de Vida dos Componentes

A vida componente Web Dynpro começa a primeira vez que é chamado em tempo de
execução e termina com o tempo de vida do aplicativo Web Dynpro que o chamou. Os
componentes incorporados são instanciados apenas no momento em que eles são necessários e
sua vida termina ao mesmo tempo que o componente incorporado, quando o aplicativo Web
Dynpro que foi originalmente chamado é encerrado.
Também é possível para o componente incorporado ser criado ou destruído através de uma
API e, assim, controlar a sua vida.
6.3 View
Uma View descreve o layout e o comportamento de uma área retangular de uma interface
de usuário.
Cada aplicativo Web Dynpro tem pelo menos uma View. O layout de uma View é composto
de elementos diferentes ou iguais de interface de usuário, que podem ser aninhados em outro
elemento. O posicionamento dos elementos de interface em uma View é definido pelas opções de
layout fornecidos.
39
Objects
Além da parte visível, o layout de uma View também contém um controlador e um

contexto. Os dados a que os elementos da View podem ser vinculados são armazenadas e
gerenciados no âmbito da View, permitindo-lhes a representação na tela. O controlador de
exibição pode conter métodos para recuperação de dados ou para o processamento da entrada
do usuário.
6.4 Layout’s em Web Dynpro

Os layouts em aplicações Web Dynpro são associados com Containers e como os controles
são posicionados em uma view.
Existem 5 tipos de layouts:
• FlowLayout
40
Objects
Cada elemento da UI é posicionado na mesma linha (row). É o layout padrão para os

containers e não podem ser definidos quebras de linha.
Tecnicamente a tag em HTML usada é: <span>

A aparência final depende da tecnologia do cliente e do tamanho da janela do navegador.
• RowLayout
Este layout permite inserir quebras de linhas.
A RowLayout tem um comportamento semelhante ao MatrixLayout. No entanto, ele atribui

seqüencialmente os elementos de UI exatamente uma coluna.
Uma vez que um elemento de interface do usuário no container define essa propriedade
como RowHeadData, todos os elementos UI do processo irá aparecer atrás dela na
mesma linha, até que um elemento UI é encontrado com esta propriedade definida como
RowHeadData, uma nova linha será iniciada.
41
Objects
No exemplo acima a raiz TransparentContainer está definido para RowLayout. Todos os

elementos da interface do usuário tem o rótulo layoutdataset propriedade para
RowHeadData. O botão também está definido para RowHeadData de modo que aparece
em sua própria linha. Note que não há controle de espaçamento vertical.
É uma grande vantagem do RowLayout é que você pode facilmente criar estruturas de
layout consistentes utilizando as classes de células pré-definidos, que também são
fornecidas no MatrixLayout.
• MatrixLayout
É o mesmo que o RowLayout com uma funcionalidade extra, o posicionamento vertical dos
controles.
A MatrixLayout organiza os containers filhos em um formato tabular, semelhante ao

GridLayout. Você pode utilizar as propriedades stretchedHorizontally stretchedVertically
para especificar se os elementos de UI correspondem ao tamanho do container. Você não
pode definir explicitamente o número de colunas que você pode ao utilizar o GridLayout.
É uma grande vantagem da MatrixLayout sobre o GridLayout que você pode facilmente
criar estruturas layout consistente.
• GridLayout
A Grid Layout é similar ao MatrixLayout com a diferença que é possível definir o

posicionamento vertical e horizontal.
42
Objects
NOTA: Em vez de o GridLayout, use o MatrixLayout sempre que possível.
A GridLayout organiza os containers filhos em uma grade bidimensional, com um número

de coluna definidos e qualquer número de linhas. Quebras de linha podem ser definidas.
Quebras de linha são inseridas automaticamente quando um elemento de interface do
usuário for muito longo a ser exibido dentro de uma linha.
• FormLayout
Um novo tipo de layout disponível a partir da versão 7.0 Ehp2, que permite a distribuição
automática das colunas com alinhamento vertical dos elementos do formulário através de
grupos de formulários.
Os labels são alinhados a esquerda e um asterico é apresentado para elementos

obrigatórios.
43
Objects
6.5 Window
Uma Window é utilizada para combinar várias Views. Uma View só pode ser exibida pelo
navegador se tiver sido incorporada em uma Window. Uma Window sempre contém um ou mais
Views, que são conectados por links de navegação, sendo uma destas especificada como a View
de início e é exibida pela primeira vez quando a Window for chamada.
6.6 Plug e Link’s de Navegação

A navegação entre View’s é feita por meio de plug`s. Os plug`s podem ser divididos em
inbound e outbound. Enquanto plug`s de inbound define os possíveis pontos de entreda de uma
View, os plug`s de outbound de uma View são utilizados para chamar outra View. Plugs fazem
parte do controlador da View. Eles estão sempre atribuídos a exatamente uma View.
Várias Views são geralmente incorporados em uma Window Web Dynpro. Portanto, é
necessário qualificar uma View como a que será exibida em primeiro lugar, quando uma Window
for chamada. Essa View é atribuída a propriedade Default. A estrutura de navegação
subseqüente é criada usando esta View.
A entrada de uma View através de um plug inbound sempre causa a chamada de um método
manipulador de evento. É por isso que um método manipulador de evento (cuja utilização é
opcional) é gerado automaticamente para cada plug inbound. Neste caso, o plug inbound em si
representa o evento a ser tratado.
Para navegar de uma para outra View, cada plug outbound da primeira View deve estar
relacionada com o plug inbound da segunda View com a ajuda de um link de navegação.
44
Objects
• Um link de navegação pode ser provenientes de um plug outbound, é possivel chamar uma
série de Views de destino.
• Em contraste, um plug inbound pode ser controlado por vários plug`s outbound
6.7 Plugs Inbound e Outbound

Uma Window tem um ou mais plugs outbound e inbound. Usando esses plugs, uma Window
pode ser incluída em uma cadeia de navegação. O conceito destes plugs, corresponde ao
conceito de plugs de View. Cada plug de uma Window é visível dentro da Window inteira e pode
ser usada para navegar dentro desta Window. Além disso, um ou mais plugues podem ser
acessíveis para a Interface de componentes de modo que sejam visíveis, mesmo para além dos
limites do componente em questão. Eles, portanto, pertencem a Interface View da Window em
questão.
Plugs da Interface View
45
Objects
Se um plug existente de uma Window é adicionado à interface de componente, então é parte da

Interface View que pertencem a esta Window.
Estes plugs de interface são necessárias sempre:
■ Uma Window componente é incorporado em uma janela de outro componente a exibição na

tela se desloca para lá.
■ Um aplicativo da Web Dynpro deve ser pulgado de modo que possa ser chamado.
■ Um aplicativo da Web Dynpro deve ser encerrado.
Para chamar ou fechar um aplicativo da Web Dynpro usando uma interface plug, o plug relevante
inbound deve ser declarado como um plug start, e o plug de outbound relevante como um exit
plug. Você precisa interface plugs de inbound e outbound do tipo padrão para usos de
componentes - que é, precisamente quando um componente externo está sendo ligado a um
componente interno.
Plugs outbound
Plugues de outbound dentro de uma Window de condução a partir da Window do plug de inbound
de uma View. Usando esses plugs de outbound, é possível iniciar a navegação dentro da Window
com diferentes Views em vez de usar uma View de início predefinida. Você define o controle
como a que é chamado de plug de outbound usando o método de manipulador de evento da
interface do plug de chamada de outbound.
46
Objects
Plugs Inbound
Plugues de inbound dentro de uma Window pode ser chamado através do plug de outbound de
uma View. Assim como todos os outros plugs de inbound, eles representam um evento e, assim,
chamar o manipulador de eventos que lhes são atribuídas. Desta forma, é possível controlar
dentro da Window do controlador, que plug de outbound interno deve ser chamado. Desta forma,
você pode dinamicamente definir a chamada da view que será apresentada na Window.
47
Objects
6.8 Controladores
Os controladores são as partes ativas de uma aplicação Web Dynpro. Eles determinam a forma
como o usuário pode interagir com o aplicativo Web Dynpro. Os dados que um controlador pode
acessar é definido no contexto correspondente. Diferentes instâncias de controladores e
contextos existem dentro de uma aplicação Web Dynpro. Além de ver os controladores, que
controlam o comportamento de uma visão individual, há também os controladores globais que
oferecem serviços mais gerais para todas as Views de um componente.
View Controller
Cada View tem exatamente um View Controller, que processa as ações executadas pelo usuário
na exibição. A View também tem exatamente um View Context, que contém os dados
necessários para a exibição.
Um View Controller possui um Context correspondente, pelo menos, enquanto View é visível no
navegador. Se a View é substituída por Views sucessivas, os dados locais já não estarão
disponíveis. No entanto, a vida do context também pode ser conectada à vida útil do componente
ao redor.
Controllers Global
Cada componente Web Dynpro contém pelo menos um controlador global que é visível dentro do
componente para todos os outros controladores. Uma vez que os dados para esse componente
controlador foram criados a primeira vez que eles são acessados, o tempo de vida se estende
para cobrir todo o período durante o qual o componente está em uso.
48
Objects
Você pode adicionar outros controladores global sob a forma de controladores customizados.
Estes também duram enquanto o componente e os dados neles contidos estão disponíveis para
todas as exibições do componente.
Toda vez que há uma Window Web Dynpro, um controlador adicional global (o controlador de
Window) é adicionada ao componente.
Controladores podem conter sua própria fonte de código nas seguintes áreas:
• Manipulador de eventos
Os manipuladores de eventos são executados quando uma View é inicializada, no termino ou

na entrada, quando um elemento de interface do usuário de uma View desencadeia uma ação
ou quando os controladores de outros desencadeiam um evento registrado.
• Métodos
Métodos podem ser chamados por outros controladores.
• Supply Functions
As funções de abastecimento são executadas quando necessário para inicializar os elementos

do contexto.
49
Objects
Interface Controller
Cada componente Web Dynpro contém exatamente um controlador de interface. Este controlador
é um controlador global que é visível também no exterior do componente. É, portanto, parte da
interface de um componente Web Dynpro.
Comunicação de um controlador para o próximo é feito chamando os métodos de um controlador

diferente, ou pelo desencadeamento de um evento em que outros controladores já estão
registrados.
Cada controlador possui áreas do programa em que você pode inserir seu próprio código-fonte.
Portanto, uma Application Programming Interface (API) existe para o tratamento de nós de
contexto e seus atributos e dados. A inicialização necessária de nós também pode ser executada
usando esta API. Há ainda APIs disponíveis, por exemplo, a camada de abstração de servidor
para acessar o ambiente do sistema, e as APIs para manipulação de mensagens e programação
dinâmica.
Um controlador Window é atribuído a cada Window Web Dynpro. O controlador Window é um

controlador global. É visível por todos os outros controladores dentro do componente.
6.9 Eventos
O controlador de componente permite criar eventos.
Os eventos são usados para comunicação entre controladores e permitir que um controlador
acione manipuladores de eventos de controladores diferentes.
A comunicação entre componentes pode ser implementada usando eventos do controlador

interface. Eventos que foram criados no controlador de componente são visíveis dentro do
componente.
Plugs de entrada (Plugs Inbound)
Plugues de entrada em uma visão também reage como um evento. Portanto, quando uma visão é
chamado usando um plug de entrada, o manipulador de eventos que está opcionalmente
disponível para o plug de entrada é sempre chamado em primeiro lugar. Neste caso, o tratamento
de eventos ocorre dentro do controlador da view atual.
50
Objects
O mesmo se aplica para plugs de entrada de uma view interface. No controlador Window
correspondente, um manipulador de eventos é criado. Então ele pode ser programado se,
necessário.
Elemento Eventos UI
Alguns elementos da interface, como um botão têm eventos especiais que estão relacionados
com as ações do usuário. Estes eventos são pré-definidos e devem ser ligados com uma ação
em tempo de design.
Ações para Eventos elemento UI (Actions)
Alguns elementos da interface como o elemento Button pode reagir a interação do usuário:
clicando no botão correspondente pode desencadear um método de manipulação a ser chamado
dentro do controlador da view. Tais elementos UI estão equipados com um ou vários eventos em
geral, que podem ser ligados com uma ação específica em tempo de design (a mudança para
uma visão posterior, por exemplo). Se tal ação é criado, um método manipulador de eventos para
esta ação é criado automaticamente. Desta forma, você pode associar a um evento de um
elemento de UI (que foi inserida várias vezes em uma visão) com diferentes ações, se
necessário. O evento é então processado pelo manipulador de eventos correspondente,
dependendo da ação que está vinculado.
51
Objects
O parâmetro WD_EVENT é usado nas actions, este referencia ao tipo

CL_WD_CUSTOM_EVENT, que contém várias informações do evento que foi disparado.
6.10 Context
Os dados utilizados no componente ou no modo de exibição são armazenados no contexto.
Leitura e gravação a esses dados estão disponível usando os controladores como um ponto de
partida.
Estrutura
Os dados dos contextos são gerenciados como uma estrutura hierárquica. Cada Context tem um
nó raiz, abaixo dos quais os campos de dados individuais (atributos) são armazenados em uma
estrutura de árvore. Você pode criar esta estrutura de árvore de acordo com a estrutura do seu
aplicativo.
Cada nó de contexto contém campos de dados que pode mostrar o seguinte:
• Uma instância individual de um tipo de objeto

• Instancias de tabela
52
Objects
Esta propriedade de um nó é conhecido como sua cardinalidade. A seguinte tabela resume as

cardinalidades possíveis de um nó:
Cardinalidades
1:1 -> O nó contém apenas uma instância do elemento, que é instanciada automaticamente.
0:1 -> O nó contém apenas uma instância do elemento, que não deve ser instanciado.
1:N -> O nó pode conter múltiplas instâncias do elemento, dos quais pelo menos um deve sempre
ser instanciado (e é instanciado automaticamente).
0:N -> O nó pode conter múltiplas instâncias do elemento, nenhuma das quais tem que ser
instanciado.
Recursão Nodes
É possível dentro de um contexto, a criação de nó de recursão. O nó que é usado para a

recursividade é sempre um predecessor do novo nó. O nó recursão recém-criado é uma
referência a um nó predecessor e, portanto, não podem ser tratados separadamente. Em vez
disso, assume a estrutura do nó a ser repetido.
6.11 Data binding e Mapping

Dentro da arquitetura Web Dynpro, os contextos dos controladores podem ser ligados de
maneiras diferentes:
53
Objects
Um elemento de interface do usuário em uma view pode estar relacionada com um elemento do
contexto.
Um mapeamento pode ser definido entre os dois contextos controlador global, ou de um contexto
de view para um controlador de contexto global.
O contexto de um controlador global pode estar ligado a um modelo Web Dynpro (Wizard).
Os elementos de um contexto de exibição podem ser definidos localmente. Neste caso

(representado no gráfico abaixo como um nó local), todos os atributos contidos só são visíveis
dentro da visão relevantes. Quando a visão desaparece, os valores do atributo são excluídos.
54
Objects
6.12 Metodos e Atributos de Sistema

Para os controladores de componentes Web Dynpro, métodos e atributos de sistemas são
criados automaticamente.
Atributos
● WD_CONTEXT
Este atributo é uma referência para o node raiz do contexto do controlador. Independentemente
do controlador é feito referência ao tipo IF_WD_CONTEXT_NODE. Você pode usar
WD_CONTEXT e os métodos de interface para editar o conteúdo de um node de contexto em um
dos seus métodos do controlador.
method INVALIDATE_TABLE_NODE .
data: TABLE_NODE type ref to IF_WD_CONTEXT_NODE.
TABLE_NODE = WD_CONTEXT->GET_CHILD_NODE( 'MY_TABLE_NODE' ).
TABLE_NODE->INVALIDATE( ).
endmethod.
● WD_THIS
55
Objects
Cada controlador contém uma interface local que pode ser acessado no controlador. O atributo
WD_THIS do controlador é uma referência a esta interface local. Dependendo do controlador,
uma variável de referência é do seguinte tipo:
· IF_COMPONENTCONTROLLER
· IF_<MY_CUSTOM_CONTROLLER>
· IF_<MY_VIEW>
· IF_<MY_WINDOW>
Metodos
Todos os controladores possuem os seguintes métodos:
● WDDOEXIT:
Método de limpeza do controlador. Este método é chamado automaticamente quando um

controlador é encerrado. No caso do controlador de componente, este método tem um parâmetro
opcional Importing (REASON) através do qual a razão para sair do componente pode ser
passado. Este parâmetro só é preenchido quando há um tempo limite da sessão. Se o
componente é retirado regularmente (por exemplo, usando um plug outbound), o parâmetro é
definido como Initial.
● WDDOINIT:
Este é o método de inicialização do controlador. Ele sempre é executado automaticamente na

primeira vez que o controlador é chamado.
O controlador do Componente também é equipado com os seguintes métodos:
● WDDOBEFORENAVIGATION:
De tratamento de erros antes da navegação através da aplicação.
● WDDOPOSTPROCESSING:
Manipulação de erros que ocorreram durante a validação de contexto.
Um controlador de view recebe automaticamente o método:
● WDDOMODIFYVIEW:
Método para modificar a visão antes da renderização.
Este é o único método em que dinamicamente é permitido a modificação dos controles de

interface do usuário. Um parâmetro possui a informação se a view é executada pela primeira vez.
56
Objects
6.13 Interface View

Cada Window tem uma única Interface View atribuída. Esta Interface View representa a visão
exterior da Window. A Interface View está ligada com uma aplicação Web Dynpro para que a
Window possa ser chamado através de uma URL.
Além disso, a Interface View permite que a Window possam ser reutilizada por múltiplos
componentes Web Dynpro. Isto significa que, além de todas as Views do componente específico,
a Interface View das windows de todos os componentes são conhecidos pelo componente atual
(ou seja, para o uso do componente que foi criado) pode ser embutido em uma Window. Assim
como a View, a Interface View possui plug`s inbound e outbound que podem ser integrados na
estrutura de navegação de uma outra Window com estes plug`s. Estes plug`s de Window são
convenientes que sejam explicitamente marcados como plugs de interface e poder serem
fornecidos para a interface do componente.
57
Objects
Cada View pode ser exibida apenas uma vez na Window atual ao mesmo tempo, isto também se
aplica a uma Interface View de um componente usado. É possível, no entanto, declarar diversos
usos, para um mesmo componente. Desta forma, você pode exibir uma Interface View várias
vezes.
6.14 Interfaces de Componentes Web Dynpro

Cada componente tem uma interface, a fim de permitir a comunicação entre os componentes
Web Dynpro e para permitir que um componente seja chamado por um usuário. Esta interface
consiste de duas partes:
• Interface View
• Interface Controller
Uma interface view de uma windows Web Dynpro é usado para ligar uma Window com uma
aplicação Web Dynpro que pode ser chamado pelo usuário.
6.15 Web Dynpro Application

A aplicação Web Dynpro é uma aplicação que pode ser chamado a partir da interface do usuário.
Como uma unidade de programa independente que conecta uma URL que pode ser acessado
pelo usuário com uma janela no componente Web Dynpro.
58
Objects
Application
O Web Dynpro aplicação é meramente ligadas a uma view interface de Web Dynpro por um plug
de entrada declarado como um plug de inicialização.
6.16 Elementos UI WDA

Vários elementos de interface de usuário (UI elementos) estão disponíveis no Web Dynpro
Explorer para criação de layout de interface. Estes elementos de UI estão categorizados
conforme a lista a seguir:
● Favorites
● text
● action
● selection
● complex
● layout
● graphic
● integration
Elementos de UI
Favorites
Esta categoria está vazia por padrão. Você pode, porém, adaptá-lo para atender às suas
necessidades específicas, movendo os elementos da interface do usuário mais freqüentemente
utilizados a partir de suas respectivas categorias para os favoritos usando Drag & Drop. Isto
permite-lhe ter todos os seus elementos de UI juntos e evita que você tenha que escolher
novamente elementos únicos de suas categorias individuais.
Text
● Caption
59
Objects
Este elemento UI é utilizado por uma row de elementos UI, por exemplo, Group, Tab, Table,
TableColumn e Tray, para fornecer um cabeçalho ou um título.
Exemplo:
● Explanation
Este elemento UI é usado para exibir textos de ajuda de linha única ou múltiplas linhas o
elemento de interface do usuário ou uma aplicação Web Dynpro.
Exemplo:
● FormattedTextView
Este elemento da suporte a diversos tipos de tag’s XML, XHTML, dentre outros, é utilizado para
formatação de textos simples.
Tag’s suportadas:
http://help.sap.com/saphelp_nw70/helpdata/en/08/5696420cc2c56ae10000000a155106/content.ht
m
● InputField
O elemento UI inputField permite ao usuário editar ou exibir um texto de linha única.
Exemplo:
60
Objects
● Label
O elemento UI Label é usado para rotular elementos de interface do usuário.
Exemplo:
● TextEdit
UI elemento TextEdit torna possível inserir e exibir várias linhas de texto.
Exemplo:
● TextView
O elemento TextView UI permite exibir um texto.
Exemplo:
Action
● Button
O elemento UI botão representa o botão na tela.
Exemplo:
● ButtonChoice
61
Objects
A ButtonChoice é um botão que oferece várias opções através de um menu.
Exemplo:
● LinkToAction
O elemento UI LinkToAction é um link de hipertexto. A navegação dispara uma Web Dynpro

action.
Exemplo:
● LinkToURL
O elemento UI LinkToURL é um link de hipertexto.
Exemplo:
● TimedTrigger
UI TimedTrigger elemento automaticamente e periodicamente dispara um evento com um

intervalo especificado.
Selection
● CheckBox
Com um CheckBox você pode implementar um único interruptor para ligar / desligar.
Exemplo:
● CheckBoxGroup
O CheckboxGroup permite aos usuários selecionar um elemento de um conjunto de opções pré-

definidas usando a caixa de seleção.
Exemplo:
Single Column Two Column Three Column

62
Objects
● DropDownByIndex
A DropDownByIndex elemento UI oferece ao usuário uma caixa de lista suspensa.
Exemplo:
● DropDownByKey
A DropDownByIndex elemento UI oferece ao usuário uma caixa de lista suspensa.
Exemplo:
● ItemListBox
63
Objects
Este elemento UI é similar ao conceito clássico de GUI uma lista de seleção com a seleção
simples e múltipla (caixa de listagem).
Exemplo:
● RadioButton
O RadioButton elemento UI é um botão com dois estados (on / off) que permite aos usuários
selecionar as opções.
● RadioButtonGroupByIndex
O RadioButtonGroupByIndex elemento UI representa um número de grupos de botões de rádio

em colunas e linhas.
Exemplo:
● RadioButtonGroupByKey
O RadioButtonGroupByKey UI é grupos de elementos múltiplos de RadioButtons em uma tabela.
Exemplo:
● ToggleButton
O elemento UI ToggleButton representa o botão na tela.
Exemplo:
64
Objects
● ToggleLink
O ToggleLink elemento UI é usado para exibir um link de hipertexto para uma busca estendida.
Exemplo:
● TriStateCheckBox
Este elemento da interface do usuário é similar a um CheckBox, com a diferença que ao clicar
sobre as opções o estado pode ser variável:
● Opção pode ser ativado (selecionado)

● Opção não pode ser ativada (não selecionado)
● Opção é indeterminado
Exemplo:
Selected Not Selected Not Specified
Complex
● BreadCrumb
A BreadCrumb exibe a página atual no contexto de um caminho de navegação.
Exemplo:
● DateNavigator
O DateNavigator elemento UI permite aos usuários visualizar e introduzir datas.
Exemplo:
65
Objects
● Legend
O Legend elemento UI permite que você exiba um texto descritivo para diferentes cores utilizadas
em um elemento UI atribuído.
Exemplo:
● PhaseIndicator
Semelhante à do elemento UI RoadMap, o elemento UI PhaseIndicator exibe as etapas de um

assistente.
Exemplo:
● RoadMap
O RoadMap elemento UI mostra os passos seguidos em um assistente.
Exemplo:
● Table
Em uma tabela Dynpro Web, os dados são exibidos em duas dimensões em células de tabela
organizada em linhas e colunas.
Exemplos:
66
Objects
67
Objects
68
Objects
● Tree
Hierarquias definidas no contexto pode ser visualizada usando o elemento UI Tree.
Exemplo:
69
Objects
Layout
● HorizontalContextualPanel
Este elemento da interface do usuário fornece uma estrutura de navegação similar ao

ContextualPanel com uma hierarquia de navegação de dois níveis.
Exemplo:
One-level
Two-level
● ContextualPanel
Este elemento da interface do usuário fornece funções de navegação. A lista de navegação pode
incluir mais de três níveis.
Exemplo:
● MessageArea
70
Objects
O MessageArea elemento UI representa um espaço reservado que especifica onde as

mensagens, e como mensagens de erro ou avisos, deve aparecer na view.
● NavigationList
O NavigationList fornece uma área de navegação e é usado, por exemplo, no Contextual Panel.
Exemplo:
● PageHeader
Com o PageHeader, você pode criar um título para uma página.
Exemplo:
71
Objects
● ButtonRow
A ButtonRow é usado para organizar vários botões em uma ordem regular. Botões e
ToggleButtons pode ser inserido.
Exemplo:
● HorizontalGutter
O elemento UI HorizontalGutter ajuda a estruturar o layout e as partes do texto da tela Web

Dynpro, semelhante à <hr> tag HTML.
Exemplo:
● InvisibleElement
O InvisibleElement elemento UI é um elemento invisível na tela. Usado para orgarnizar os

controles na tela.
● MultiPane
O Multipane elemento UI é usada para ordenar o conteúdo na forma de um GRID, semelhante ao

MatrixLayout, mas com a diferença que o dataSource é obrigatório.
72
Objects
Exemplo:
● TabStrip
O TabStrip elemento UI permite a exibição em tabs.
Exemplo:
● ViewContainerUIElement
O elemento UI ViewContainerUIElement é uma área dentro de uma view que contém uma outra
view.
● Group
73
Objects
O Grupo elemento UI é um container elemento UI que pode ser usado para agrupar elementos
múltiplos de UI.
Exemplo:
Group with Primary Color
Group with Secondary Color and Tool Bar
Group mit SAP Color
● TransparentContainer
O TransparentContainer é um container UI que não pode ser exibida.Usado para orgarnizar os

controles dento de uma view.
● Tray
O elemento UI Tray (IWDTray) é um conatiner de elementos UI como o elemento container Grupo

UI que e pode ser usado para agrupar um conjunto de elementos de interface do usuário.
Exemplo:
Tray with Plain Design
74
Objects
Tray with Fill and Menu Design
Collapsed Tray with Transparent Design
Graphic
● Gantt
75
Objects
● Network
76
Objects
● BusinessGraphics
77
Objects
● GeoMap
● ValueComparison
78
Objects
● Image
Crontrole para exibir imagens.
● ProgressIndicator
Interation
● InteractiveForm
Você pode usar o InteractiveForm elemento UI para inserir um formulário interativo no formato
PDF em uma view.
● BIApplicationFrame
Em um BIApplicationFrame, Templates Web que são baseados em aplicativos BEx Web pode ser
acessado usando uma URL. Vários atributos podem ser definidos para um modelo de Web. Eles
são transferidos como parâmetros usando a URL. Ao usar o BIApplicationFrame, estes
parâmetros podem ser definidos como propriedades do elemento UI.
Exemplo:
79
Objects
● OfficeControl
Você pode usar OfficeControl elemento UI para adicionar um documento do Office para uma
view. Isto significa que você pode exibir os documentos do Office seguinte dentro de uma
aplicação Web Dynpro:
● Microsoft Word
● Microsoft Excel
Exemplo:
80
Objects
● FileDownload
FileDownload é usado para carregar arquivado a partir do servidor para o cliente.
● FileUpload
O FileUpload elemeto UI pode fazer upload de arquivos do cliente para o servidor.
● IFrame
A interface do usuário elemento IFrame representa uma área separada por um frame, que contém
uma página separada do navegador, dentro de uma view.
Observações!
Para maiores detalhes dos controles, como as suas classes e métodos correpondentes acesso o
link a seguir:
http://help.sap.com/saphelp_nw70/helpdata/en/cd/422b035f01914e80251a660e39ab14/content.ht
m
81
Objects
6.17 Fases do Processo de Execução

Esta seção fornece informações sobre o transporte de dados durante o processamento de
requisições Web Dynpro.
O gráfico a seguir mostra esquematicamente o fluxo do processo durante o transporte de dados:
O fluxo do processo de manipulação de eventos é mostrado em detalhes no gráfico a seguir:
82
Objects
1) Transferencia de dados do cliente para o Data Container, é feita para um armazenamento

temporário avaliado em tempo de execução.
2) Validação da entrada do usuário, todas as entradas são checadas, em caso de erros
detectados a verificação não é interrompida, os dados validos são transportados e os
invalidados não são.
As validações são baseadas nos tipos de dados referenciados no context. Para as

inconsistências encontradas uma mensagem de erro é gerada e exibida na aplicação.
3) Transporte dos dados do container é feita para o context.

4) O evento WDDOBEFOREACTION é executado, este pode ser usado para as validações
customizadas.
5) O tratamento de actions e eventos é realizado, idependentemente se os houve o transporte
dos dados container para o context. Quando erros são identificados o desenvolvedor tem
acesso as mensagens e pode realizar um tratamento destes dados.
6) O evento WDDOAFTERACTION é executado, centralizando os códigos comuns que são
executados em vários eventos, reduzindo o esforço na manutenção do código.
7) O método WDDOBEFORENAVIGATION é executado e pode ser usado para uma
validação adicional dos contextos do controlador que são necessárias na aplicação, mas
não foram validadas no ciclo de request/response. Isso é importante para aplicações mais
complexas Web Dynpro, em particular. Este método só pode ser usado para o controlador
de componente.
8) A navegação disparada por um evento correspondente é agora executada. O Plug Inbound
da view posterior é chamado e o manipulador de eventos correspondente é processado.
9) O evento WDDOMODIFYVIEW da view é executado, neste momento a visualização é
criada conforme a arvore de controles, o desenvolvedor pode usar este evento para
manipular dinamicamente estes controles ou adicionar novos.
10) WDDOPOSTPROCESSING , este método é chamado na última etapa do processo antes
da renderização. Portanto, permite que você adicione aplicações específicas de limpeza
processos.
11) Renderização, durante o processamento, a interface do usuário é exibido na tela - ou seja,
a estrutura da árvore de UI e do preenchimento dos elementos do contexto.
83
Objects
6.18 Programação Cross-Component

Componentes Web Dynpro são módulos reutilizáveis. Isto permite construir aplicações Web
Dynpro que consistem em diferentes componentes. De dentro de um componente, uma interface
permite que você use os dados e as funções de outro componente. O pré-requisito para isto é
que o segundo componente deve estar disponível em tempo de execução em uma versão ativa.
Tipos de componentes que podem ser criados:
• Componentes Fornecedores de Dados
Este é usado para fornecimento de dados para outros componentes em uma aplicação web
dynpro, para isso deve ser criado um componente web dynpro e remover os objetos visíveis, ou
seja, window e view.
• Componentes de Interface
Este é usado para criação de um componente com uma interface comum, ou seja, manter a
uniformidade na aplicação web dynpro. Representa o mesmo conceito de OO.
• Componentes Concretos
São componentes que fornece algum serviço ou função especifica que podem ser usados em
vários pontos de uma aplicação ou de aplicações web dynpro.
Usando componentes
Os componentes quando referenciado em um componente Web Dynpro, podem ser das

seguintes formas:
- Componente com controlador de acesso
Este permite ter acesso aos atributos e métodos do controlador além de visualizar as views do
componente.
- Componente sem controlador de acesso
Este permite ter acesso somente a visualização das views do componente.
Chamando Componentes
Para visualizar um componente externo dentro de um componente, deve ser incorporado um

interface view em uma das views do componente.
Conforme imagem a seguir:
84
Objects
Para inicializar o componente segue um código de exemplo:
method MY_CONTROLLER_METHOD .
data: L_REF_CMP_USAGE type ref to IF_WD_COMPONENT_USAGE.
L_REF_CMP_USAGE = WD_THIS->WD_CPUSE_MY_COMP_USAGE( ).
if L_REF_CMP_USAGE->HAS_ACTIVE_COMPONENT( ) is initial.
L_REF_CMP_USAGE->CREATE_COMPONENT( ).
endif.
endmethod.
6.19 Wizards
Na na barra de ferramentas do Editor acesse o button Web Dynpro Code Wizard. Uma lista
de wizards mais usados com freqüência são listados em uma janela que permite a geração de
estruturas declaração Web Dynpro.
Você utiliza o assistente para ajudá-lo na criação de códigos Web Dynpro.
6.20 Classe de Assistência

Para cada componente Web Dynpro, você pode criar uma classe de assistência. Esta classe
deve herdar da classe abstrata CL_WD_COMPONENT_ASSISTANCE.
Ao criar uma classe de assistência para um componente os seguintes benefícios são oferecidos:
● Você pode armazenar codificação necessária dentro do componente que não está ligada
diretamente com o layout ou com a função de um controlador. Este poderia ser, por exemplo,
uma chamada de camada de aplicação ou UI baseado edição dos dados.
85
Objects
Chamadas a métodos da classe de assistência são melhores do ponto de vista de desempenho

do que as chamadas de métodos de um controlador de Web Dynpro.
● A segunda função importante da classe de assistência é a gestão de textos dinâmicos. Textos

que são combinados apenas em tempo de execução e/ou conter variáveis que podem ser
armazenados no pool text da classe assistência como símbolos de texto.
A classe de assistência é instanciado automaticamente quando um componente é chamado. A

instância está disponível para cada controlador do componente através do atributo WD_ASSIST.
6.21 Trabalhando com Caixa de Dialogos (Popup)

As janelas popup são usadas para exibir textos ou view com elementos UI, existem dois tipos:
• Modal
Abre na mesma janela atual do navegador, a view principal é bloqueada e somente

liberada após o fechamento da janela modal.
• Externa
Abre uma janela independente da janela atual do navegador, uma nova janela é aberta.
Chamando Janelas Popup
Para criação de uma janela popup uma nova janela deve ser criada e chamada através de um
evento. O controlador do componente contém a interface IF_WD_WINDOW_MANAGER, com a
qual uma nova janela pode ser criada com o conteúdo da caixa de dialogo.
6.22 Ajuda na Entrada de Dados

No contexto de uma aplicação de negócio interativo, a entrada de dados pelo usuário é de grande
importância. Em um grande número de variantes de diálogo, uma entrada válida representa um
elemento de um conjunto limitado de valores. O usuário pode selecionar o valor desejado de uma
tabela contendo os valores possíveis.
No Web Dynpro ABAP você pode reutilizar pesquisa existentes ajuda do Dicionário ABAP. No
entanto, não há busca ajuda para todos os tipos de dados no sistema.
Modelo de ajuda a pesquisa (Search Help)
86
Objects
6.23 Mensagens da Aplicação

No Web Dynpro ABAP você pode criar e exibir mensagens que contêm informações importantes
para o usuário final da aplicação Web Dynpro. Mensagens são dependentes do idioma textos que
são exibidos na tela se, por exemplo, ocorre um erro quando um aplicativo é executado, ou o
usuário entrou dados no formato errado.
Exemplo
87
Objects
Mensagens são integrados no log de mensagens de um componente usando o Message

Manager (interface IF_WD_MESSAGE_MANAGER).
Metodos mais usados desta interface:
• CLEAR_MESSAGES
• REPORT_SUCCESS
• REPORT_WARNING
• REPORT_ERROR_MESSAGE
6.24 ALV (ABAP List Viewer)

SAP ABAP List Viewer (ALV) é uma ferramenta flexível usada para exibir listas e estruturas
tabular. Ele fornece operações de lista comum como funções padrão e pode ser melhorada pelo
usuário com funções específicas. Isso permite que você use ALV em uma grande variedade de
programas de aplicação.
Veja exemplos detalhados do uso deste componente no link abaixo:
http://www.sdn.sap.com/irj/sdn/index?rid=/webcontent/uuid/f0b107e4-dc72-2c10-08a7-
b822c9abf0e2
6.25 Debugging Aplicações Web Dynpro ABAP

O debugger ABAP é uma ferramenta de teste integrado no ABAP Workbench. Você usá-lo
para verificar a lógica do programa e encontrar erros no código fonte de um programa ABAP.
Quando você define um ponto de interrupção (breakpoint) no debugger, ele é criado como
um ponto de interrupção padrão. Um ponto de interrupção só é válido enquanto a instância do
debugger, no qual foi definido, está ativa. Quando o depurador é fechada, todos os pontos de
interrupção definidos são excluídos.
88
Objects
Se você definir um ponto de interrupção no Editor ABAP, por exemplo, este ponto de
interrupção é um ponto de interrupção da sessão. Pontos de interrupção da sessão permanecem
ativas, independentemente da existência de um Debugger e são válidos para todas as sessões
externas de um logon. Dentro do debugger, você pode converter um ponto de interrupção do
debugger em um ponto de interrupção da sessão e vice-versa.
Se a definição de pontos de interrupção da sessão está ativa, você pode definir um ponto
de interrupção da sessão em uma sessão externa de um logon para forçar um programa em
execução no depurador que é executado no logon mesma (por exemplo, em uma sessão externa)
e irá processar onde o ponto de interrupção da sessão foi definido.
Breakpoints de usuário (anteriormente conhecido como pontos de interrupção externa) são

válidas para todos os logons de usuário no servidor atual do sistema atual. Pontos de interrupção
do usuário são especificamente exigidos para a depuração BSP ou aplicações Web Dynpro.
Nestes casos, o logon não é feito utilizando o SAP GUI, mas através de um navegador(browser),
portanto, qualquer ponto de interrupção deve ser definido antes de fazer o logon. Pontos de
interrupção do usuário são válidas apenas por um período de duas horas.
89
Objects
A partir de release 7.00, pontos de interrupção definidos pelo usuário para BSP ou
aplicações Web Dynpro também são válidas para logons pelo SAP GUI.
Através do debugger é possível exibir objetos de dados, juntamente com seus conteúdos atuais e
atributos técnicos.
É possível mostrar e editar o conteúdo e atributos das tabelas.
Permite que você exiba as classes e suas instâncias (objetos), juntamente com seus atributos
técnicos.
90
Objects
6.26 Dicas de Performance

Acesse a seção de notas de programação Web Dynpro ABAP no link a seguir:
http://help.sap.com/saphelp_nw70/helpdata/en/81/809d4e09f84eb98103c4317c9ee9a5/content.ht
m
91
Objects
7 Referências
• Help SAP - http://help.sap.com
• SDN – http://sdn.sap.com
• Wikipédia - http://pt.wikipedia.org/wiki
• Livro Web Dynpro for ABAP – SAP Press
• Livro ABAP Objects – SAP Press
92
Objects

Apostila Webdynpro For Abap PDF

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Apostila Webdynpro For Abap PDF

Enviado por

Direitos autorais:

Formatos disponíveis

Treinamento SAP

Desenvolvimento de Aplicações Web com a Tecnologia SAP

Tecnologia da Informação Mult Services Ltda

6.20 Classe de Assistência ...................................................................................................................... 85

1.1 Duração / Tipo de Treinamento

1.2 Software release / Ambiente

Conhecimentos básicos no desenvolvimento de software com a linguagem ABAP (ABAP e/ou

1.4 Publico Alvo

Profissionais que desejam conhecer as características desta tecnologia e dos recursos

Profissionais desenvolvedores de outras tecnologias que desejam migrar para o desenvolvimento

2 Curso Orientado a Projeto

Os atendentes criam as reservas, consultam reservas realizadas pelo sistema customizado e

2.2 Casos de Uso

Consultar Voos <<extend>>

A seguir são apresentados as descrições dos casos de uso.

• 01 - Caso de Uso – Criar Reserva

1. FA01 – Entrada de dados inválidos

2. FA02 – Validar existência de reserva

• 02 - Caso de Uso – Consultar Reservas

• 03 - Caso de Uso – Consultar Catálogo de Voos

1. Usuário atendente acessa o sistema de reservas

• 04 - Caso de Uso – Aprovar/Rejeitar Reservas

• 05 - Caso de Uso – Consultar Clientes

1. O sistema exibe a listagem de todos os clientes cadastrados no sistema com os

2.3 Diagrama entidade relacionamento

SCARR – Contém as informações das companhias aéreas.

SFLIGHT – Contém os vôos que servem as rotas ou conecções da tabela SPFLI.

STRAVELAG - Agências de viagens

ZRESERVA - Reservas realizadas pela aplicação customizada

2.4 Diagrama de classes

2.5 Diagrama de componentes

Também é possível conduzir a inovação ao combinar sistemas existentes, enquanto

Sendo assim, a plataforma SAP NetWeaver se traduz na melhor forma de se fazer:

- INTEGRAÇÃO DE PESSOAS - SAP Portals

Diferenciais SAP NetWeaver:

3.2 Introdução a Linguagem ABAP

3.3 ABAP Workbench

3.4 Dicionário de Dados

• Se você relacionar um campo com um objeto do Dicionário de ABAP através do search

3.5 Client Dependente e Client Independent

• Cluster: São utilizadas para armazenar dados de algumas (aproximadamente de 2 a 10)

Uma tabela deverá ser buferizada quando:

3.7 Elemento de Dados

3.9 Manipulando dados no ambiente SAP

Algumas palavras-chave Open SQL:

SELECT - Lê dados de tabelas de banco de dados.

INSERT - Acrescenta linhas em tabelas de banco de dados.

UPDATE - Ele muda o conteúdo de linhas de tabelas de banco de dados.

DELETE - Apaga linhas de tabelas de banco de dados.

SY-DBCNT: O campo de sistema SY-DBCNT contém o número de linhas do banco de dados

3.10 Estendendo Programas Standard

Customização: Configuração do sistema através do uso de parâmetros específicos de uma

Modificações no Standard SAP: Alterações no Repositório de objetos SAP em forma de

Conceito de Enhancement: Alterações no Repositório SAP, porém sem mudanças no Standard.

Desenvolvimento do Cliente: Criação de objetos dentro do escopo possível de nomes

1-Se desenvolvida corretamente, as alterações não irão afetar os outros países.

O programador tem as possíveis modificações quando estiver criando projetos de Enhancements:

Como um programador, você pode implementar então os seguintes Enhancements:

Escrever seu próprio código nas funções do SAP ( User-Exit )

3.11 Transporte de requests

4 Introdução ao ABAP Objects

Modelamento orientado a objeto