TAW12 - WEB DYNPRO: INTRODUCTION

META MODEL DECLARATIONS VERSUS CUSTOM CODING

To develop a Web Dynpro application, we use a declarative programming approach. The ABAP Workbench contains special tools for constructing an abstract model, a Web Dynpro meta model. The Generator automatically outputs the necessary Generated Code. This standard Web Dynpro framework allows you to place the Custom Code at predefined positions within theGenerated Code.

Web Dynpro Runtime defines the user interface at runtime.

We can list the advantages of Meta Model Declarations:

  They guarantee common application design.

  They offer good support for tools, such as screen layout and nesting; navigation and error handling; data flow; and componentization.

In contrast, Custom Coding has other advantages:

  It guarantees universality.

  It is good for data-driven, dynamic applications, such as implementation of Business Rules; dynamic screen modifications; access to services; and portal eventing. 


APPLICATION SCENARIOS WITH WEB DYNPRO

SAP Enterprise Portal comprises Web Dynpro Application, through which we can access ABAP Web Dynpro Runtime. Web Dynpro applications are created using ABAP Workbench. ABAP Back-End Server processes these applications.RFCs work through RFC-enabled function modules to pass data into the ABAP back-end server, where it is stored as business data. The Web service also carries this data to the Web service provider through SOAP, where it is stored as Business Data.

WEB DYNPRO APPLICATION: DATA SOURCES

Web Dynpro applications can access different kinds of data sources:

You can address all kinds of reuse components directly from a Web Dynpro ABAP application:

  Methods of classes that are defined in your own system

  Function modules that are defined in your own system or in a back-end system using RFC

  Web Services through a Web Service client object

Placing a SELECT statement in your controller methods directly leads to a mixing between flow logic and business logic.

WEB DYNPRO BENEFITS

Web Dynpro uses descriptive tools in a structured design process to enable application developers to create powerful Web applications with minimal effort. It defines user interfaces through a declarative meta model. We can list some other advantages of Web Dynpro:

  Minimized coding and maximized design
  Separate layout and logic
  Reusability of components
  Binding of data
  Availability of multiple platforms
  Browser-enabled manipulation with zero footprint
  508 accessibility support


WEB DYNPRO COMPONENT

Web Dynpro Component houses the entities related to the user interface (UI) and Web Dynpro.

We can list the main Web Dynpro components, which are entities related to the UI:

  Windows define the possible combinations of views.Windows can contain any number of views and a view can also be embedded in any number of windows. Windows also allow for the flow between views and the necessary navigation.

  Views comprise UI elements, such as input fields and buttons, as well as view layouts, such as the rectangular part of a page or a browser displayed by the client. The client can set up a complete page by using just one view or multiple views. View controllers aid these manipulations.

  Component controllers help maintain flow control between all the components of the Web Dynpro. 


CONTEXT AND DATA TRANSPORT

A context is a hierarchical data storage system, which stores data related to the UI.

User input values for UI elements are connected to the context attributes of the corresponding view controller. Through data binding, automatic data transport between the UI elements and the context attributes is possible.

You can reference the variables defined in a Web Dynpro controller from other Web Dynpro controllers through context mapping.

Combining the two concepts – context mapping and data binding – data transport between UI elements located in different views can be defined in a purely declarative way.

CONTEXT MAPPING

A context node in one controller can automatically access data from a context nodein another controller using context mapping.

The controller acting as the mapping origin contains the relevant node in its context, This node also has child nodes or attributes.

The mapping origin controller must not be a view controller.

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

PUTTING DATA ON SCREEN: DATA BINDING

Data binding helps transport data automatically from a view controller’s context to a UI element in its layout, and vice versa.

UI elements, being private to the view controller in which they are declared, cannot be bound to context nodes or attributes defined in another controller.

The Web Dynpro framework performs two tasks, subsequent to data binding:

  It transports data from the context attribute to the UI.

  It repopulates the context attribute from the UI element after the user enters the data and initiates the next server round trip.


NAVIGATION: PRINCIPLE

Navigation links join outbound and inbound plugs together.

An inbound plug is linked to an outbound plug by registering the inbound plug event handler method to the navigation event called by firing an outbound plug.

Navigation links are defined in a window.

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.

NAVIGATION BETWEEN VIEWS

You can define the navigation between two views by creating exit and entry points for each view using outbound and inbound plugs.

You can then specify the navigation flow using navigation links.

WINDOWS AND NESTED VIEWS

When you create a window, you define

  which views are displayed;
  in what combination; and
  how you can change the view combination by firing outbound plugs. 

A window is a set of all possible views that can be adjusted in a visible screen.

The container area in a view is defined by theViewContainerUIElement, which allows nesting within the window.

This ViewContainerUIElement only displays a single view at a time.

VIEW ASSEMBLY

Outbound plugs trigger a particular view in the view container area.

A view assembly consists of the subset of views visible at any time.

A window definition may have multiple views embedded in view container areas. This gives rise to many permutations of views.

The permutation that is visible depends on the navigation links you follow. Through navigation, you can replace either specific views within a view container area or entire view combinations within the window.

MODEL VIEW CONTROLLER

he Model View Controller (MVC) design paradigm is the foundation for SAP’s Web Dynpro. It decoupled presentation and application logic, using three layers:

  The Binding Layer binds the user and interaction layers together. The Controller, which is at the heart of this layer, performs all intermediate processing.

  The Business Interaction Layer consists of the Model, which generates application data without caring how it will be displayed.

  The User Interaction Layer or View visualizes the application data without caring how it was generated. 

INTERNALLY VISIBLE WEB DYNPRO ENTITIES (1)

Two types of entities make up a Web Dynpro component – those that are externally visibleand those that are internally visible.

The internally visible parts can be either visual or programming entities, which consist of 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.

A view can be embedded in different windows, the first view so embedded being the default view.

INTERNALLY VISIBLE WEB DYNPRO ENTITIES (2)

Business Logic is not part of the Web Dynpro component. It is defined outside, so that it has high reusability. Global ABAP classes are preferred for encapsulating the related source code.

The component controller acts as a componentwide controller.

In the related view controller, only the program logic related to a certain view, such as checking user input, is coded.

INTERNALLY VISIBLE WEB DYNPRO ENTITIES (3)

The developer defines optional controllers, which then become custom controllers. They help modularize component content. They can function as local controllers for some views. Alternatively, they help encapsulate the logic related to a certain model class. By creating a usage declaration in the custom controller for the component controller and vice versa, you can reduce the content of the component controller and populate subfunctions.

EXTERNALLY VISIBLE WEB DYNPRO ENTITIES

For one Web Dynpro component (parent component) to access another (child component), the former can declare the use of the latter. A specific component usage instance is then created. Through the component interface controller, the parent component accesses the functionality of the child component.

The externally visible entities of the Web Dynpro component are the interface controller and the interface view(s).

WEB DYNPRO APPLICATION

A Web Dynpro application is the only Web Dynpro entity that can be addressed via a URL, and is an entry point into a Web Dynpro component.

The Interface view in Component Interface has inbound as well as outbound plugs. An application is created here with an inbound plug of the type Startup, called Default. This is because an application is a URL associated with this special inbound plug in the interface view.