WEB DYNPOR ARCHITECTURE

WEB DYNPOR ARCHITECTURE

Definition
Web Dynpro is the SAP NetWeaver programming model for user interfaces and provides support when developing the Web representation of business applications. The Web Dynpro model is based on the Model View Controller paradigm, and has the following features that build on the classic dynpro model:
· Clear separation of business logic and display logic
· Uniform metamodel for all types of user interfaces
· Execution on a number of client platforms.
· Extensive platform independence of interfaces

Structure
In Web Dynpro, each user interface is always made up of the same basic elements (such as UI elements or events triggered by the user). These basic elements are declared using Web Dynpro tools. The event handling is programmed in separate source code areas, which are executed automatically at runtime when the event is triggered.
Metamodel Concept
When creating a Web Dynpro application, you use the Web Dynpro tools to describe the properties and functions of the application. The data created in this way is stored in tables as metadata. At a later time, the necessary source code, which is executed at runtime, is created from this metadata. Therefore, the metadata itself is independent of the rendering technique used at runtime.
Graphical Development Tools
To support this declarative concept, the SAP NetWeaver Developer Studio contains a range of Web Dynpro tools. You can therefore generate a large proportion of a Web Dynpro application using the tools provided, without having to create your own source code. This applies to the following parts of the application:
· Data flow between the front end and back end
· Layout of the user interface
· Properties of user interface elements.
The Web Dynpro tools enable you to create source text areas manually within generated source texts. These areas are not changed if the source code is regenerated.

Separation of Business Logic and Display Logic
Web Dynpro enables you to clearly separate business logic and display logic. A Web Dynpro application runs on the front end and has local or remote access to the back end system via a service. This means that the display logic is contained in the Web Dynpro application, while the business logic and the persistence of the business objects run in the back end system.

The following options are currently available for connecting Web Dynpro applications and the back end system:

· An interface generated using adaptive RFC, through which BAPIs of an SAP system can be called
· An interface for calling Web services.
· A self-generated interface

The source code required for connecting the Web Dynpro application can be generated from a UML definition of the Web Dynpro interface. A UML definition can be imported into the Web Dynpro tools as an XML file.

Implementation of the Model View Controller Paradigm
Every Web Dynpro application is structured according to the Model View Controller paradigm:
· The model forms the interface to the back end system and thus enables the
· Web Dynpro application access to data.

· The view is responsible for the representation of the data in the browser.

· The controller lies between the view and the model. The controller formats the model data to be displayed in the view, processes the user entries made by the user, and returns them to the model.


Web Dynpro Application
A Web Dynpro application is an application that can be called from the user interface. As an independent program unit it connects a URL that can be accessed by the user with a window in the Web Dynpro component.

The Web Dynpro application is merely linked to an interface view of a Web Dynpro window by an inbound plug. It therefore contains no information whatsoever about the elements of the corresponding component or components behind the interface view.

Web Dynpro Component
The creation of applications using Web Dynpro is structured in Web Dynpro components
Definition
A Web Dynpro component is a reusable entity. It summarizes all components that are required as part of this programming unit for an executable Web Dynpro application.
The Web Dynpro component concept offers a number of advantages:
 Structuring of the programming
 Creation of easily manageable application blocks
 Reusability of whole components
 Decoupling of software projects in both time and space.

The creation of a Web Dynpro component is always mandatory, since the existence of the Web Dynpro window and the views and controllers that it contains is linked to the existence of the component itself. Communication between the elements of two Web Dynpro components and their call by a user is implemented using the component interfaces, so it does not make sense to consider the individual parts of the component separately.

A Web Dynpro component can embed other Web Dynpro components, and correspondingly a Web Dynpro component can be embedded in any other Web Dynpro components. This communication also takes place over the component interfaces.

Lifetime of a Web Dynpro Component
A Web Dynpro component’s lifetime begins the first time it is called at runtime, and ends with the lifetime of the Web Dynpro application that called and thereby instantiated the component.
For embedded components this means that during the lifetime of the embedded component, they are not instantiated until the moment when they are required. Their lifetime ends, however, at the same time as the embedded component when the Web Dynpro application that was originally called is ended.
It is also possible for the embedding component to create or destroy the embedded component using an appropriate API and thus control its lifetime.

Interfaces of Web Dynpro Components
Each component has an interface in order to enable communication between Web Dynpro components and to enable a component to be called up by a user.
This interface consists of two parts:
1. Interface View of a Window Contained in a Component
2. Interface Controller of a Component.

Interface View of a Window Contained in a Component
The interface view of a Web Dynpro window is used to link a window with a Web Dynpro application that can be called by the user.
An embedded component can also be integrated in one of the windows of the embedded component using inbound and outbound plugs. The window of the embedded component can behave like a view with regard to navigation
The window of the inner component does not have to have graphical elements. It can also be available for the functions contained in your component controller or for contexts for the embedding component.

Interface Controller of a Component
As well as the visual part, the interface of a Web Dynpro component also has a programmatic part, the interface controller. This is visible inside and outside of the component, and performs the program side of the exchange of business data. An embedding component can also call an embedded component using this controller.
An additional option for data exchange between the embedding and embedded component is cross-component context mapping.
The interface of a Web Dynpro component can also be defined independently without implementation. It is therefore possible to separate the development of the Web Dynpro component and the development of one use of the Web Dynpro component. You can also create multiple interface implementations for a Web Dynpro component. For each interface, the required implementation is not selected until runtime. The interface and implementation are linked by the same name.

The Web Dynpro component contains any number of
Windows
Views
Controllers

Window
Definition
A window groups together multiple views and view sets. A view can only be displayed by the browser if it has been embedded in a window. A window always contains one or more views, which are connected by navigation links. One of these views, or a view set, is specified as the start view and is displayed the first time the window is called.

Interface View
Each window has a uniquely assigned interface view. This interface view represents the outward view of the window. The interface view is linked with a Web Dynpro application so that the window can be called using a URL.

The interface view enables windows to be reused by multiple components .
This means that in addition to all component-specific views, the interface views of windows of all components that are known by the current component (that is, for which a component use has been created) can be embedded in a window. Just like the view, the interface view has inbound plugs and outbound plugs and can be integrated in navigation structure of another window using these plugs.
Each view can be displayed only once in the current window at the same time; this also applies to an interface view of a used component. It is possible, however, to declare several uses for one and the same component. In this way, you can display an interface view multiple times.

View
Definition
A view describes the layout and behavior of a rectangular area of a user interface.

Use
Every Web Dynpro application has at least one view. The layout of a view is made up of different user interface elements, which can be nested in each other. The positioning of interface elements in one view is supported by the supplied layout variants.
In addition to the visible part, the layout, a view also contains a controller and a context.
The data to which the elements of the view can be bound are stored and managed in the view context, enabling them to be represented or used on the screen.
The view controller can contain methods for data retrieval or for processing user input.


Empty View
The empty view is a special type of view. It is always generated automatically in a window or a view set area, provided that no view has been embedded manually. It may also be preferable to embed an empty view in a non-empty window as well. Just like a normal view, the empty view occupies a certain area of a window at runtime and can be used to hide a different view, for example, using specific controls.
When you create an empty view, an inbound plug with the default name ShowEmptyView is created.

View Set
A view set provides a visual frame with predefined subsections into which you can embed your views at design time.
Using view sets is particularly advantageous when you design, implement, or display the user interface of a Web Dynpro application:
· Structured option to display more than one view in a screen
· Efficient support when designing user interfaces
· Possibility of using the predefined areas to make changes to the layout at later stage
· Reuse of views within a Web Dynpro window.

The Web Dynpro framework provides the following preconfigured view sets:
T layout
T layout 90°
T layout 180°
T layout 270°
Grid layout
Tab strip

Displaying a view and its embedded view sets always occupies 100% of the screen display area.


However, you can define a view set and, at design time, embed an empty view in a selected area of a view set. This area is displayed as an empty area at runtime.



Controllers
Definition
Controllers are the active parts of a Web Dynpro application. They define how the user can interact with the Web Dynpro application. The data that a controller can access is defined in the corresponding context. Different instances of controllers and contexts exist within a Web Dynpro application.

There are two types of controllers:
View Controller
Global Controllers.

View Controller
Each view has exactly one view controller, which processes the actions performed by the user in the view. A view also has exactly one view context, which contains the data required for the view.

A view controller and the corresponding context exist at least as long as the view is displayed in the browser; if the view is replaced by a subsequent view, the local data is no longer available. However, the lifetime can also be connected to the lifetime of the surrounding component.

Global Controllers
Each Web Dynpro component has at least one global controller. Once the data for this component controller have been created the first time they are accessed, the lifetime extends to cover the whole period during which the component is in use.
You can add additional global controllers in the form of custom controllers. These also last as long as the component and the data they contain are available to all views of the component.
Communication from one controller to the next is achieved by calling methods from a different controller, or by triggering an event on which other controllers are already registered. You define these controller uses when you create a controller.

Controllers can contain their own source code in the following areas:
· Event handlers – these are executed when a view is initialized, ended, or entered, when a user interface element of a view triggers an action, or when other controllers trigger a registered event
· Methods – these can be called by other controllers
· Supply functions – these are executed when necessary to initialize elements in the context.

Context
Definition
The data used in the component or in the view are stored in the context. Read-write access to this data is available using the controllers as a starting point.
Structure
The data from the contexts is managed in a hierarchical structure. Each context has a root node, underneath which the individual data fields (attributes) are stored in a tree structure. You create this tree structure according to the structure of your application.
Each node contains data fields that represent one of the following:
1.An individual instance of an object type
2.A table of instances.

Cardinality of a Context Node
When a node is created in the context of a Web Dynpro component, the cardinality of a node is specified. The cardinality defines how often a node is to be instantiated at runtime – that is, how many elements of this node are available at runtime.
1…1 Only one element is instantiated.
0…1 At runtime, no more than one element is instantiated, but it
is also possible that no element is instantiated.
1…n n elements can be instantiated, but at least one element must be instantiated.
0…n The number of instantiated elements of the context node can vary.

Recursion Nodes
Dynamic node nesting is possible within a context, creating what is called a recursion node. The node that is used for recursion is always a predecessor of the new node. The newly created recursion node is a reference to a predecessor node and therefore cannot be processed separately. Instead it takes on the structure of the node to be repeated.
The root node of a context cannot be used for a recursion.

Data Binding and Mapping
Within the Web Dynpro architecture, the contexts of the different controllers can be linked in different ways:
· A UI element of the user interface of the view can be linked with an element of the view context.
· A mapping can be defined between two global controller contexts, or from a view context to a global controller context.
The context of a global controller can be linked to a Web Dynpro Model.

Defining Mapping Between Two Contexts
The elements of a view context can be locally defined. In this case (represented in the graphic below as a "Local Node"), all the contained attributes are only visible within the relevant view. When the view disappears, the attribute values are deleted.

A second option for defining context elements is to link a context node to a node of another context. The graphic above represents the definition of a mapping between the node "Node 1" from the context of View 1, and the node of the same name in the context of the component controller. Also displayed is a mapping from the node "Node 2" from the context of View 2, also to a node with the same name in the component controller context. The global context of the component controller is visible for both view controllers, and all the controllers involved have both read and write access to the contained attributes. The values for the attributes of the component controller context are contained here as long as the user does not exit the component. The values are retained even if the view that you used last is no longer displayed on the screen. It is therefore possible to transport data across different contexts within a component. A data value that, for example, has been read from an input field of the first view, can be forwarded to the context of the component controller using a suitable mapping. The value then still exists in the memory if the navigation has already led to the next view. If a corresponding mapping is already defined for the successive view, the view can then process this value.
If the value is then changed in the second view, any subsequent views for which a similar mapping is defined then find the current value in their context.

Note:All global controller contexts (visible component-wide) can be linked to each other. A mapping can also be defined from a view context element to an element of a global context. Conversely, however, it is not possible to define a mapping to an element of a view context: An element of a view context cannot be mapped to an element of a global context. This is because the lifespan of the view context is generally shorter than that of the global controller context.

Binding a UI Element to a Context Attribute
Properties of the user interface elements contained in the view can be bound to attributes of a view context. This enables the context data to be displayed in the browser. Any user changes to the view displayed in the browser are stored in the context. Multiple properties can be bound to one context element.
Within a context, all elementary data types are available for the definition of attributes. The information stored here is also used by a Web Dynpro application for creating value help, and for creating error messages if invalid entries are made.

Defining a Binding to a Web Dynpro Model
You can also define a binding between the context of a component controller and the data of a Web Dynpro model.

Plugs and Navigation Links
Navigation between different views is enabled by plugs. These can be divided into inbound and outbound plugs. While inbound plugs define the possible starting points of a view, the outbound plugs of a view can be used to call a subsequent view. Plugs are part of the controller of a view. They are always assigned to exactly one view.

Note:Since interface views behave exactly the same as views with regard to navigation, the properties described below also apply to interface views.
Several views are generally embedded in a Web Dynpro window. Therefore, it is necessary to qualify one view as the view that is displayed first of all when a window is called. This view is assigned the Default property. The subsequent navigation structure is then created using this view.
The entering of a view using an inbound plug always causes an event handler method to be called. This is why an event handler method (whose use is optional) is automatically generated for every inbound plug. In this case, the inbound plug itself represents the event to be handled.
Note:If a view is flagged as the default view in a window, it is not called using the inbound plug.

To navigate from one view to another, each outbound plug from the first view must be linked with an inbound plug of the second view with the help of a navigation link.
Exactly one navigation link can originate from one outbound plug, although this can lead to a series of target views. The arrangement of these target views is not qualified, which means that all target views are controlled at the same time.In contrast, an inbound plug can be controlled by several outbound plugs .

Note: Information about which plugs are connected with each other is not contained in the individual views. This information is stored separately in navigation.
By implementing the navigation you create a static, potential connection between two views of a Web Dynpro application. You thus define the view sequence for when the Web Dynpro application is executed. You must define a navigation link for each possible view change.

Event
Component controllers and interface controllers enable events to be created.
Events are used to communicate between controllers and enable one controller to trigger event handlers in a different controller.
Cross-component communication can be implemented using the interface controller’s events. Events that were created in the component controller are visible within the component only.

Inbound Plugs
Inbound plugs in a view also react like an event. Therefore, when a view is called using an inbound plug, the event handler that is optionally available for the inbound plug is always called first. In this case event handling takes place within the current view controller, however.

Even the controller of an interface view reacts to the starting point in the view by calling the event handler method that belongs to the corresponding inbound plug. An event handler is therefore created and can be programmed suitably for every inbound plug in an interface view.

UI Element Events
Some UI elements, such as the button element have special events that are linked with user actions. These events are predefined and have to be linked with an action at design time.

Action
Actions for UI Element Events
Some UI elements such as the button element can react to a user’s interaction: clicking on the corresponding pushbutton can trigger a handling method to be called within the view controller. Such UI elements are equipped with one or several general events, which can be linked with a specific action at design time (switching to a subsequent view, for example). If such an action is created, an event handler method for this action is created automatically. In this way, you can equip a UI element event (which has been inserted several times into a view) with different actions as necessary. The event is then processed by the corresponding event handler depending on the action that is linked.
Actions can also be reused within a view. This means that an action can be linked to the events of several (or even different) UI elements.
Note: Unlike cross-controller events, UI element events are always handled within their own view controller; there is no cross-controller communication. UI element events themselves are predefined and cannot be changed.

Web Dynpro Model
Definition
Web Dynpro technology is based on the Model View Controller paradigm, to ensure a clear division between the definition of the user interface and the implementation of the application logic. Within this concept, the model retrieves the application data from the back-end system. If you want to define multiple models, the model must be bound to the relevant Web Dynpro component that the model is to use.
The data for a Web Dynpro application can originate from different sources. You can
1.Call and use SAP data from a SAP back-end system using BAPIs
2.Define new data
3.Call and use Web services
4.Combine the three above procedures
5.Import an external model using the appropriate tools.