¿Qué es la Web Dynpro?

Web Dynpro de SAP para Java y ABAP es un paso revolucionario en el desarrollo de interfaces de usuario basadas en Web.

Aplicaciones Web Dynpro se construyen utilizando técnicas de programación declarativa basada en el paradigma Modelo Vista
Controlador (MVC).

especifica que el usuario los elementos de interfaz que desea tener en el cliente y en aquellos elementos obtienen sus datos

definirá las posibles rutas de navegación de forma declarativa en su aplicación.

el código para crear la interfaz de usuario se genera entonces automáticamente dentro de un marco de tiempo de ejecución
estándar no hay tareas de codificación repetitivas en la escritura de HTML y lo es interactivo con JavaScrip

Web Dynpro ABAP ha estado disponible desde SAP NetWeaver 7.0 (SAP NetWeaver Application Server 7.0).

Para el desarrollo de Web Dynpro, se usa la transacción SE80)

Web Dynpro está diseñado para apoyar el desarrollo estructurado.

Las unidades de modularización del software son componentes Web Dynpro, que se pueden combinar para construir
aplicaciones complejas.

Meta Model Declaration vs. Custom Coding

Una aplicación Web Dynpro se desarrolla utilizando un enfoque de programación declarativa.

En ABAP Workbench, hay herramientas especiales que le permiten construir una representación abstracta de su aplicación en la
forma de un modelo de meta Web Dynpro. El código fuente necesario se genera automáticamente y se ajusta a una arquitectura
estándar conocido como el Web Dynpro framework.

Web Dynpro framework. le permite colocar el código fuente personalizada en las posiciones predefinidas en el código generado.

Todas las aplicaciones Web Dynpro se construyen a partir de las mismas unidades básicas.

Sin embargo, mediante el uso de codificación personalizada, el marco estándar se puede extender a suministrar cualquier
funcionalidad de negocio requerido.
No todas las decisiones de aplicación deben hacerse en tiempo de diseño. Es posible para implementar una aplicación Web
Dynpro en el que la interfaz de usuario se define en tiempo de ejecución. Esto permite que una aplicación altamente flexible para
ser escrita sin la necesidad de escribir directamente cualquier HTML o JavaScript.
Application Scenarios with Web Dynpro
Aplicaciones Web Dynpro pueden acceder a diferentes tipos de fuentes de datos:

• Desde una aplicación Web Dynpro ABAP, todo tipo de componentes de reutilización pueden dirigirse directamente:
1. Los métodos de clases definidas en el propio sistema.
2. Los módulos de funciones definidas en el propio sistema o (a través de RFC) en el sistema de back-end.
3. Servicios Web a través de un objeto de cliente de servicio Web.

• No coloque una instrucción SELECT en sus métodos de controlador directamente, ya que esto conduce a una mezcla entre la
lógica de flujo y la lógica de negocio.

Model objects no están soportados en Web Dynpro ABAP. La mejor manera de tener entidades reutilizables encapsular la lógica
de negocio es crear global class de ABAP que contengan el código fuente. También es posible desarrollar UI-free (faceless) que
sonWeb Dynpro component, que sólo ofrecen una funcionalidad reutilizable. Estos componentes pueden ser accedidos por otros
componentes Web Dynpro a través de la reutilización de componentes.

Beneficios de la Web Dynpro

El objetivo principal de Web Dynpro es permitir a los desarrolladores de aplicaciones para crear potentes aplicaciones Web con
el mínimo esfuerzo utilizando herramientas descriptivas en un proceso de diseño estructurado.
Un principio rector en la filosofía Web Dynpro es: "The fewer lines of hand-written code, the better". Web Dynpro persigue este
objetivo de dos maneras.

Web Dynpro utiliza declarative meta model

para definir las interfaces de usuario. El entorno de desarrollo genera el código fuente requerida desde esta definición
abstracta. Sin embargo, la UI también se puede manipular desde el código fuente que es necesario implementar cambios

dinámicos que no se conocen en tiempo de diseño.

 dinámicos que no se conocen en tiempo de diseño.

• Web Dynpro ofrece características técnicas tales como el apoyo a la internacionalización, flicker-free interaction, y una
separación limpia de la lógica de negocio y la interfaz de usuario. Esta separación se logra a través de una aplicación modificada
del Model View Controller (MVC) en un paradigma de diseño.

El Wizards soporta la definición de froms and tables de la UI y su código fuente en los controller methods . Esto reduce
significativamente el esfuerzo de desarrollo.

Dado que las tareas repetitivas de codificación de UI han sido eliminados, el desarrollador puede centrar su atención en el flujo
de datos de negocio a través de la aplicación. Aplicaciones Web Dynpro pueden ser incrustados en el entorno de portal, pueden
ser mostradas por la SAP NetWeaver Business Client o bien pueden visualizarse mediante un navegador.

Web Dynpro Architecture: Entities and Concepts

Web Dynpro components allow you to structure complex Web applications and develop reusable, interacting entities. This
enables the nesting of large application sections.

Web Dynpro components are containers for other entities related to the UI and the Web Dynpro program.

Web Dynpro components permiten estructurar aplicaciones Web complejas y desarrollosreutilizables y entidades interactúan.
Esto permite el anidamiento de grandes sectores de aplicación. Web Dynpro components son contenedores de otras entidades
relacionadas con la UI y el programa Web Dynpro.

Las entidades relacionadas con la UI son

windows and views. El esquema de vista es la parte rectangular de una página visualizada por el cliente (por ejemplo, en un
navegador). La view contiene elementos UI tales como input fields y buttons. La página completa se envía al cliente puede ser
configurado por un solo punto de vista, pero también puede ser una combinación de múltiples vistas. Las posibles
combinaciones de puntos de vista y el flujo entre los puntos de vista se define en una ventana. Una window puede contener
cualquier número de views.
Una view puede tener adentro cualquier número de ventanas.

El Web Dynpro source code se encuentra en Web Dynpro controllers.

Global variables de los controladores se definen como atributos del controlador. Los datos globales relacionados con la UI (que
aparecen por elementos de la UI o el programa usado para manipular propiedades de los elementos de la UI) tiene que ser
almacenado en un almacenamiento jerárquico llamado context.

Web Dynpro components pueden direccionarse de tres maneras diferentes:

• Using a Web Dynpro application, a Web Dynpro component can be linked to a URL, which can be called from a Web browser or
• Using a Web Dynpro application, a Web Dynpro component can be linked to a URL, which can be called from a Web browser or
another Web Dynpro client.

When reusing a Web Dynpro component as a subcomponent, the visual interface of a Web Dynpro component can be
combined with the visual entities of the main component to form the UI.

When reusing a Web Dynpro component as a subcomponent, all methods and data defined in the programming interface
can be accessed by the main component.

¥ Los valores de los elementos de una UI que permiten la entrada del usuario tienen que ser conectados a los atributos
de contexto del controlador correspondiente. Esto se conoce como el enlace de datos. A través de enlace de datos, los
atributos se establece un transporte de datos entre los elementos de interfaz de usuario y el contexto.

Las variables definidas en un Web Dynpro controller context pueden ser referenciados desde otros controladores de
Web Dynpro. Esto se llama context mapping. Mapeo de contexto le permite compartir atributos comunes entre diferentes
controladores, por lo que la copia de estos atributos entre los contextos de controlador no es necesario.

¥ La combinación de estos dos conceptos, el transporte de datos entre los elementos de UI ubicados en diferentes
puntos de vista se puede definir de una manera puramente declarativo.

Context mapping permite que un nodo de contexto en un controlador a ser suministrada de forma automática con datos
de un nodo de contexto correspondiente en otro controlador. Este es el mecanismo principal para el intercambio de datos
entre los controladores. Para una relación de proyección que se establezcan, los siguientes pasos primero se deben
realizar:

A node must exist in the context of the controller acting as the mapping origin. This node may also have child nodes or
attributes.
(Un nodo debe existir en el contexto del controlador que actúa como el origen de mapeo. Este nodo también puede tener
(Un nodo debe existir en el contexto del controlador que actúa como el origen de mapeo. Este nodo también puede tener
nodos secundarios o atributos.)

The mapping origin controller must not be a view controller.

(El controlador de origen de asignación no debe ser un controlador de vista.)

The controller containing the mapped node must declare the use of the mapping origin controller as a used controller.

(El controlador contiene el nodo asignado debe declarar el uso del controlador de origen de mapeo como un controlador
usado.)

Data binding es el medio por el cual los datos son transportados automáticamente a partir de un controller’s context to a
un elemento de una UI en su diseño, y viceversa.

No se puede obligar a los elementos de UI tales como nodos de contexto o atributos definidos en otro controlador.

Los elementos de UI son privados para el controlador de vista en el que se declaran.

El data binding process desacopla

los elementos de la UI de objeto del código de la aplicación en el view controller

. Por lo tanto, para manipular propiedades de los elementos de las UI, el código de la aplicación en el controlador de vista
necesita sólo para manipular los valores de los context nodes, y los attributes a que están obligados a la UI.

Web Dynpro framework realiza las dos tareas siguientes:

• El transporte de los datos del context attribute al UI element durante el proceso screen rendering process.
• El transporte de los datos del context attribute al UI element durante el proceso screen rendering process.

• Repoblación del context attribute

desde el UI element después de que los datos han sido introducidos por el usuario y el siguiente servidor de ida y vuelta se
inicia.

Los valores introducidos por el usuario son automáticamente convertidos y comprueba la conformidad con el tipo.

Si se produce un error, se muestra un mensaje.

Data binding es un instrumento poderoso ya que no sólo el valor de un UI element se puede enlazar a un atributo de
contexto, sino también otras UI properties como visibility
. Esto significa que las propiedades de los UI element pueden ser manipulados desde el controlador de vista actuando
sobre loscontext attributes.

La navegación entre vistas es lanzada por un firing outbound plugs

. Firing an outbound plug provoca un evento de navegación a elevarse. Navigation events son eventos asíncronos
especiales que se colocan en una navigation queue. Multiple outbound plugs
pueden ser disparados por una vista. Esto puede ser usado para definir la siguiente interfaz de usuario, que consta de
múltiples vistas. La cola de navegación se procesa en un cierto punto en el tiempo en la fase de procesamiento de Web
Dynpro. Hasta este punto del tiempo, la pila de navegación puede ser extendido por un pelotón de tapones de salida
 Dynpro. Hasta este punto del tiempo, la pila de navegación puede ser extendido por un pelotón de tapones de salida
adicionales, o la pila de navegación completa se puede eliminar. Tapones de salida deben ser nombrados de acuerdo con
la acción que causó la navegación fuera de la vista actual.

Inbound plugs son special event handler methods que se suscriben a los eventos de navegación lanazdos cuando se
disparan los outbound plugs. Inbound plug methods se llaman sólo cuando se procesa la navigation queue. Esto sólo tiene
lugar una vez que los puntos de vista en el conjunto de vista actual han disparado sus navigation queues y no se han
producido errores de validación que causaría la navegación al ser cancelada. Inbound plugs deben ser nombradas de
acuerdo a la razón por la cual se muestra la view.

Outbound and inbound plugs se unen entre sí mediante enlaces de navegación. Técnicamente, la vinculación de un
inbound plug to an outbound plug quiere decir registrar el inbound plug event handler methodde navegación llamado por el
disparo de unoutbound plug. Los enlaces de navegación se definen en una window.

Outbound plugs and event handler methods related to the inbound plug can have parameters, allowing you to pass data
between the views.

An Action is used to link a client side event to an event handler method (automatically defined with the action) in the
corresponding view controller.

Windows and Nested Views

Windows and Nested Views

A window defines which views are displayed in what combination and how the view combination may be changed by firing
outbound plugs. So when you create a window, you define three things:

All the possible views that could exist in the component’s visual interface must be embedded in the window.

If multiple views need to be displayed in parallel, the layout and

position of these views is defined by a special view containing ViewContainerUIElements in its layout. This container view is
embedded in the window and, inside each area defined by a ViewContainerUIElement, all possible views for this view
container area are embedded (nested embedding). For each ViewContainerUIElement, there is one default view displayed
at startup.

The navigation links between the different views must be defined.

Sólo un punto de vista se puede mostrar en la zona de contenedores vista a la vez.

Navigation links deben ser definidos entre las vistas para que el contenido de una zona de contenedores vistas a sustituir.
Ver áreas de contenedores pueden ser borradas mediante la incorporación de la EMPTYVIEW vista (creado
automáticamente con el componente) cuya clavija de entrada responde a un evento de navegación apropiada.
Outbound plugs are the triggers that cause a view container area to contain a particular view.

Para una definición determinada ventana en la que múltiples puntos de vista están incrustados en las zonas de contenedores de
vista, muchas permutaciones de puntos de vista pueden ser visibles. La permutación que es visible depende de qué enlaces de
navegación sigue el usuario. El subconjunto de puntos de vista visibles en cualquier momento se conoce como un view
assembly.
SAP’s Web Dynpro is built on the foundation of the Model View Controller (MVC) design paradigm. MVC was originally invented
by the Norwegian software designer Trygve Reenskaug while working at Xerox PARC in the late 1970s. The first implementation
of this design paradigm was with the release of the Smalltalk-80 programming language.

MVC was a revolutionary design paradigm because it was the first to describe software components in terms of:

The functional responsibilities each should fulfill

The message protocols to which each component should respond

SAP has modified and extended the original MVC specification to create the Web Dynpro toolset.

Web Dynpro Component Architecture

 La arquitectura de un componente Web Dynpro se puede dividir en dos partes: La línea de trazos horizontal en la figura
anterior separa las entidades que son visibles desde fuera del componente de las que sólo son visibles dentro del
componente.

Las partes internas visibles pueden dividirse en visual entities and programming entities.. Entidades visuales son los
relacionados con la interfaz de usuario, generada por el Web Dynpro framework y pasa al cliente. Las entidades
internamente visibles consisten en windows and views.

A view consists of a view layout and the corresponding view controller. The view controller can contain navigation plugs,
methods, and a context.

A window embeds one or more views and has a corresponding window controller. A window controller can contain
navigation plugs, methods, and a context. Each view can be embedded in multiple windows.

The outbound plug of a window can be connected to any inbound plug of embedded views and the outbound plug of a view
can be connected to any inbound plug of the embedding window. However, navigation between windows of the same
component is not possible.
El component controller actúa como un component-wide controller.
(controlador de todo el componente). La lógica del programa se refiere únicamente a un determinado punto de vista -
control de entrada del usuario, por ejemplo - se codificará en el controlador de vista relacionado. Declaraciones de uso
entre los controladores le permiten acceder a los datos de contexto, los atributos públicos, y los métodos del controlador
declarado (used controller). Un controlador de vista no puede ser declarado como un controlador utilizado para otros
controladores, ya que esto violaría la buena práctica de programación (paradigma de programación MVC).

La lógica de negocio no debe ser parte del componente Web Dynpro, sino que debe ser definida fuera del componente a
tener una alta reutilización. Es preferible que las clases ABAP mundial ser utilizados para encapsular el código fuente
correspondiente.
Los controladores personalizados están controladores opcionales que deben ser definidos por el desarrollador. Estos
controladores pueden utilizarse para modularizar contenido de componente. Por ejemplo, los controladores
personalizados pueden actuar como controladores locales para algunas vistas, o pueden ser utilizados para encapsular la
lógica relacionada con una cierta clase de modelo (la lógica de negocio). Esto le permite reducir el contenido del
controlador componente poblando subfunciones.
Si componente Dynpro una Web (parent component) necesita tener acceso a otro componente Web Dynpro (
child component), el componente de los padres puede declarar el uso del componente secundario. Se crea entonces una
instancia específica el uso de componente y el componente principal accede a la funcionalidad del componente
secundario a través de su controlador de interfaz de componente.

The only parts of a Web Dynpro component that are visible to the user are the interface controller and the interface
view(s).

All Web Dynpro components have only one interface controller. Via the interface controller, data, methods, and event
handlers can be made accessible to other components.

Interface views represent the visual interface of a Web Dynpro component. There is a one-to-one relationship between
a window and an interface view. Each time a window is defined, a related interface view is automatically generated
which makes the window accessible from outside the component. The interface view only exposes those inbound and
outbound plugs to the component user that have the interface property checked. Methods and context data of the
window are not accessible via the related interface view.

If the component has no views, there is no need to have windows. In this case, the component does not implement an
interface view. Components without any visual interface are called faceless components.
A Web Dynpro application is an entry point into a Web Dynpro component and is the only Web Dynpro entity that can be
addressed via a URL

Hay a menudo (pero no siempre) una relación de uno a uno entre una vista de interfaz y una aplicación

There is often (but not always) a one-to-one relationship between an interface view and an application.

In the same way that the functionality in an ABAP module pool can be accessed by defining multiple transaction codes,
the functionality of a single Web Dynpro component can be accessed by defining multiple applications, each addressing a
different interface view and/or a different inbound plug of the interface view.

To define a Web Dynpro application, you must specify:

The component to be instantiated; this component is then known as the root component.

Which interface view of the root component is used; the default view(s) in this interface view define(s) the default view
assembly.

Which inbound plug acts as the entry point for the nominated interface view (this inbound plug must be of type Startup).