abap web dynpro - fundamentos

ABAP Web Dynpro - Fundamentos

Página | 1

Slide 1

DI A 1

• C O N C E I T U A Ç Õ E S

• A B A P O B J E C T S – R E SUM O

• A R Q UI T E T UR A DE C O M PO N E N T E S W E B DY N PR O ( M V C )

ABAP Web Dynpro


Página | 2

Slide 2

Parte 1 - Conceituações

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


Página | 3

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


Página | 4

Slide 3


Declarações Meta Modelo Código Customizado

Garantia de padronização • Uso de Ferramentas para auxiliar o

desenvolvimento

• Desenho de Telas e aninhamento• Navegação e tratamento de erros

• Fluxo de dados

• Componentização e reutilização

Garantia de Universalidade• Bom para aplicações dinâmicas e baseadas

em Dados

• Implementações de regras de negócio• Modificações dinâmicas na interface com

usuário

• Acesso a serviços (arquivos, etc)• Portal eventing (comunicação entre iViews)

Declarações Meta Modelo vs. Código Customizado Considerando o modelo de programação declarativa do Web Dynrpo, dentro do Workbench, existem certas ferramentas que permitem ao desenvolvedor construir uma representação abstrata na forma de Meta Modelo Web Dynrpo. O código necessário é então gerado, em conformidade com uma arquitetura padrão, conhecida como o Framework Web Dynpro.

Este framework permite, então, que o desenvolvedor injete, em locais predefinidos, código customizado para atender aos requisitos de negócio da aplicação. Isto diferencia uma aplicação Web Dynpro das outras, que por definição, são compostas das mesmas unidades básicas.

Este modelo permite que nem todas as decisões de implementação sejam feitas na fase de desenho da aplicação. Isto permite, por exemplo, que a aparência da interface com o usuário seja decidida em tempo de execução, de acordo com parâmetros do usuário ou requisitos de negócio. Isto permite que uma aplicação Web altamente flexível seja construída sem a necessidade de códigos complexos DHTML e Javascript.


Página | 5

Slide 4


Cenários de aplicações Web Dynpro Aplicações ABAP Web Dynpro podem acessar uma variedade de fontes de dados (Models), tanto diretamente, como chamadas a módulos de função e métodos de objetos, ou indiretamente, através do consumo de Web Services ou de conexões com EJB (Enterprise JavaBeans) usando o conector Java (JCo).

É possível ainda, apesar de ser altamente não recomendado, causando uma confusa mistura entre a camada de negócios e o modelo de dados (Model e Controller), o acesso direto a um comando OpenSQL SELECT.

Um Objeto ABAP (instância de uma classe) até o presente momento não pode ser usado como modelo. A maneira recomendada para se ter objetos reutilizáveis que representem lógicas de negócio é construir Classes ABAP para conter este tipo de código. É possível ainda se criar um Componente faceless, ou seja, um componente WebDynpro sem nenhum elemento visual, apenas para fim de reusabilidade.


Página | 6

Slide 5


Web Dynpro pode ser acessada através de vários tipos de dispositivos. Aspecto importante para um ambiente empresarial altamente colaborativo.

É válido lembrar que em alguns dispositivos suportados, nem todos os recursos estarão disponíveis.

Benefícios do Web Dynpro O objetivo principal do Web Dynpro é fornecer ao desenvolvedor de aplicações uma maneira de criar aplicações Web poderosas com o mínimo de esforço (repetitivo) usando ferramentas e processos declarativos em um processo de desenho estruturado.

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


Página | 7

Slide 6

Parte 1 - Perguntas


Página | 8

Slide 7

Parte 2 – Arquitetura de componentes Web Dynpro (MVC)

Controller

Model

ViewRequest

Response

Camada de ligação

Camada de interação com o negócio

Camada de interação com usuário

Controla qualquer intermediação necessária

entre o negócio e o usuário.

Gerencia os dados da aplicação sem

qualquer preocupação sobre

como serão

exibidos.

Visualiza os dados da aplicação sem

qualquer preocupação sobre somo são gerados

ou armazenados.

Model-View-Controller O Web Dynpro é fundamentado no padrão de projeto MVC, concebido originalmente pelo projetista de software norueguês Trygve Reenskaug, enquanto trabalhava na Xerox, no PARC no final dos anos 70. Sua primeira implementação ocorreu no lançamento da linguagem Smalltalk-80. Este padrão de projeto foi considerado uma revolução, pois foi o primeiro a descrever componentes de software em termos de: • As responsabilidades funcionais correspondentes a cada componente. • Os protocolos de mensagem a qual cada componente deveria responder, ou reagir. A SAP modificou e estendeu a especificação original do MVC para criar o conjunto de ferramentas Web Dynrpo.


Página | 9

Slide 8


Partes de Componente WD

Window

Views

Elementos IU

Layouts

(View) Controller

(View) Context

Controller do Componente

Context

Componentes Web Dynpro Os componentes permitem uma complexa estruturação de entidades de aplicação Web interativas e sua reutilização. Isto permite o aninhamento em grandes aplicações.

Podemos enxergar o componente como um container para outros objetos relacionados a interface com o usuário (View) e o código fonte Web Dynpro (Controller).

Os elementos principais de interface com o usuário, são as Windows e as Views. Uma View representa uma área retangular que será exibida em uma página no cliente, um Web Browser por exemplo. Esta contém elementos de interação, como caixas de texto, imagens e botões. Uma página completa enviada para o cliente pode ser composta de apenas uma View, mas também pode ser uma combinação de virtualmente qualquer número de Views. Esta combinação de Views e o fluxo entre estas é definido em uma Window. O relacionamento entre Views e Windows, fazendo uma analogia ao DER, seria N:N.

O código fonte de uma aplicação Web Dynpro está localizado nos Controllers. O armazenamento lógico dos dados globais de um Controller é hierarquicamente definido em um Context.


Página | 10

Slide 9


Context

Um container para armazenar dados.

O transporte dos dados entre os Controllers pode ser estabelecido com a definição de

Mappings entre os Contexts.

Context Mapping e Data Binding As variáveis definidas em um Context de Controller Web Dynpro podem ser referenciadas dentro de Contexts de outros Controller. Chamamos isto de Context Mapping. Isto permite o compartilhamento de dados comuns entre diferentes Controllers, retirando a necessidade de se efetuar cópias destes dados entre contextos. Os valores de elementos de interação com o usuário devem ser ligados a atributos de um Context do Controller corrspondente: ao Context do View Controller, por exemplo. A isto chamamos de Data Binding. Através desta técnica, ocorre o transporte automático dos dados de campos de entrada para os atributos (variáveis) do Context. Combinando estas duas técnicas, vemos que o transporte de dados entre elementos de diferentes Views é definido de uma forma puramente declarativa.


Página | 11

Slide 10


Context Mapping Permite que um nó em um Controller seja automaticamente preenchido com os dados de um nó correspondente em um Context, geralmente de uma View. Este é o mecanismo principal para compartilhar dados comuns entre Controllers. Quando dois Controllers dentro do mesmo Componente compartilham dados através deste relacionamento, isto é chamado de Mapping interno. O Context que atua como fonte dos dados é chamado Nó de Origem, enquanto o nó que recebe os valores é chamado de Nó Mapeado. O Mapping de Nós entre Context de Controllers localizados em diferentes Componentes é chamado de Mapping Externo. Para o Mapping de nós ser declarado, é preciso que alguns pré-requisitos sejam cumpridos:

• É preciso que exista um Nó de origem no Context de Controller agindo como a fonte dos dados.


Página | 12

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

• O Controller com o Nó Mapeado deve declaras o Controller com o Nó de Origem como um Controller usado.


Página | 13

Slide 11


Data Binding É a técnica pela qual os dados são transportados de um Context de uma View para os elementos de interação nolayout desta View, e vice versa. Você não pode ligar um elemento de interface com o usuário com um nó ou atributo localizado em um Context de outro Controller, apenas o contido na própria View. Sendo assim, os elementos de interface com o usuário sempre serão privados àquela View onde foram declarados. Esta técnica separa os elementos de interface com o usuário do código fonte da aplicação, localizado dentro dos Controllers. Desta forma, para se manipular valores de propriedades em um elemento de interface com o usuário, o código fonte do Controller da View em questão precisará apenas modificar os nós e atributos do Context desta View, considerando que estes elementos estejam ligados por Data Binding. O framework Web Dynpro executa então as duas tarefas a seguir:

• O transporte dos dados do nó ou atributo para o elemento de interface com usuário ao qual este esteja ligado, durante o processo de renderização da página.


Página | 14

• A atualização de todos os nós e atributos correspondentes que sofreram modificações nos elementos de entrada de dados por parte do usuário. Neste processo, os dados são automaticamente convertidos e checados para que correspondam a seus respectivos tipos declarados, caso ocorra alguma falha, uma mensagem é imediatamente exibida para que o usuário possa corrigir este valor. Data Binding não se restringe, porém, a ligação com valores de elementos de interação com atributos do Context, mas pode-se, por exemplo controlar propriedades destes elementos como visibilidade, aparência, etc. Desta forma podemos controlar as propriedades de qualquer elemento de uma View de dentro do Controller desta View, modificando valores de nós e atributos do seu Context.


Página | 15

Slide 12


Navegação entre diferentes Views A navegação entre as Views é acionada configurando e, eventualmente, disparando-se Outbound Plugs. Isto causa um evento de navegação. Estes eventos são organizados, de modo assíncrono, em uma fila. Múltiplos Outbound Plugs podem ser disparados de uma única View. Cada chamada pode redefinir a interface com o usuário, apresentando-lhe um novo conjunto de Views, Esta fila contendo os eventos de navegação é processada em um determinado ponto da fase de processamento, gerenciada pelo framework Web Dynpro. Até este ponto, esta pilha de chamada pode ser modificada, incluindo-se ou retirando-se eventos de navegação. Convêm-se que Outbound Plugs sejam nomeados de acordo com a ação que causou a navegação desta View para uma outra. Do outro lado, existes métodos manipuladores de eventos especiais, que são associados aos eventos de navegação gerados pelos Outboud Plugs. Estes são chamados de Inbound Plugs. Quando da fase de processamento do framework Web Dynrpo, estes métodos são chamados para cada evento na fila de navegação. É interessante notar que, para estes eventos serem acionados, todas as Views do conjunto atual tenham disparado seus Outbound Plugs e que


Página | 16

nenhum erro de validação de dados tenha ocorrido, cancelando a navegação. Inbound Plugs, em nome da clareza, deveriam ser nomeados em razão do motivo pelo qual a View a que corresponde está sendo exibida. Outbound Plugs e Inbound Plugs são ligados através de Navigation Links. Tecnicamente, ao se definir um Navigation Link entre um Outbound Plug e um Inbound Plug significa registrar o método manipulador de evento de um Inbound Plug ao evento de navegação de um Outbound Plug. Desta forma, assim que um Outbound Plug é disparado, automaticamente o método do Inbound Plug correspondente é executado. É possível definir parâmetros entre o disparo de um evento de navegação de um Outbound Plug e o método manipulador de evento do Inbound Plug, permitindo que dados sejam transferidos de uma View para outra.


Página | 17

Slide 13


Windows e Views aninhadas Uma Window é, por definição um conjunto de todas as Views necessárias para a construção de uma página visível. Uma Window pode ter zero ou mais Views ebutinas. Uma Window pode conter elementos denominados View Containers, permitindo assim o aninhamento de Views dentro de uma Window. Uma Window define quais combinações de Views estarão visíveis e em que momento, através do uso de Outbound Plugs. Desta forma, ao criar uma Window, você terá que definir três aspectos:

• Todas as possíveis Views que poderão ser exibidas devem ser embutidas na Window.

• Se for necessário que várias Views sejam exibidas em paralelo, deve-se definir o layout e a organização destas Views através de um elemento View Container. Para cada elemento View Container, uma View padrão deve ser definida para ser exibida inicialmente

• Os Navigation Links entre as Views devem ser definidos, ligando-se Outbound e Inbound Plugs.


Página | 18

Apenas uma View pode ser exibida para o usuário, em tempo de execução. É possível definir uma View vazia, a fim de se conseguir limpar a tela visível para o usuário. O conjunto de Views utilizado para de compor uma Window é conhecido como View Assembly.


Página | 19

Slide 14


Interface View e Interface Controller As partes de um Componente Web Dynpro visíveis, para outro Componente Web Dynrpo, são os chamados Interface View(s) e Interface Controller. Apenas um Interface View por Componente é automaticamente criado, e dentro dele podem ser expostos dados (Context), métodos e manipuladores de evento, para outros Componentes. As Interface Views representam as interfaces visuais com o usuário de um Componente Web Dynpro. Há uma relação de 1:1 entre as Windows e as Interface Views, ou seja, cada vez que se define uma Window, uma nova Interface View é automaticamente criada, expondo esta Window para outros Componentes Web Dynpro. Esta Interface View obedece a propriedade interface de cada Outbound e Inbound Plug para decidir se estes serão expostos. Os métodos e dados da Window não serão acessíveis através deste mecanismo. Para um Componente que não possui Views, não há a necessidade de se gerar Windows e, portanto, não existirão Interface Views. Um Componente que não tenha interface visual é conhecido como faceless.


Página | 20

StartUp Plug e Web Dynpro Application

Finalmente, é preciso definir um ponto de partida para o uso das Views e seus a lógica contidas nos Controllers, que se comunicam com os Models do Web Dynpro. Este ponto de partida é definido através de um Inbound Plug especial, do tipo StartUp. É preciso ainda que seja criado uma Web Dynpro Application, que representa uma URL e é associado ao StartUp Plug da Interface View. Na maioria dos casos, uma Interface View será chamada por apenas uma Web Dynpro Application. Porém, assim como um ABAP Módulo Pool pode ser invocado por transações diferentes, seguindo fluxos de tela diferentes, também podem existir várias Web Dynpro Applications tendo pontos de partida no mesmo Componente Web Dynrpo, sendo que posem ser criados vários StartUp Plugs em diferentes Interface Views. Para se definir uma Web Dynpro Application é necessário: • Definir qual Componente será invocado. Este será conhecido como o Componente Root para a Application. • Qual Interface View deste Componente será usado, definindo assim qual o View Assembly será exibido por padrão pela Application. • Qual Inbound Plug desta Interface View, que deve ser mandatoriamente do tipo StartUp, agirá como ponto de partida para Application.

abap web dynpro - fundamentos

Documents