Web Dynpro for ABAP and Java

What’s Web Dynpro?

From the technological perspective, SAPâ€™s Web Dynpro for ABAP and Java is really a revolutionary part of the introduction of web-based UI technology. It’s totally unlike any design paradigm ever utilized by SAP before and signifies a quantum leap in the introduction of web-based, ERP programs.

What’s the Design Philosophy Behind Web Dynpro?

Web Dynpro programs are made using declarative programming techniques in line with the Model View Controller(MVC) design paradigm. That’s, you specify which interface elements you want to wish to have on the client, and where individuals elements can get their data from.All the code to create the user interface is then generated automatically within a standard runtime framework. This relieves you from the repetitive coding tasks involved in writing HTML and then making it interactive with JavaScript.

Web Dynpro Primary Benefits

Web Dynproâ€™s main goal is to enable application developers to create powerful Web applications with a minimum of effort using descriptive tools in a structured design process.
One guiding principle in the Web Dynpro philosophy is: the fewer lines of hand-written code there are in the UI, the better. Web Dynpro pursues this goal in two ways.
Web Dynpro uses a declarative, language-neutral metamodel for defining a user interface. From this abstract definition, The development environment generates the required Java/ABAP code.Â Hand-written code still has its place but is confined to that required to manipulate the business data, not the user interface.
Web Dynpro provides technical features such as support for internationalization, flicker-free interaction and a clean separation of the business logic and the user interface. This separation is achieved through a modified implementation of the Model-View-Controller (MVC) design paradigm.Â MVC was invented by Trygve Reenskaug in the late seventies and first implemented in the Smalltalk-80 language.
Since the repetitive tasks of UI coding have been all but eliminated, the developer can focus their attention on the flow of business data through the application.
Web Dynpro applications can run on a range of devices and on various types of network â€“ an important feature for collaboration scenarios.

Metamodel Concept and Declarative Programming

Web dynpro Metamodel Concept

A Web Dynpro application is developed using a declarative programming approach. Within the ABAP Workbench, there are special tools that allow you to build and abstract representation of your application in the form of a Web Dynpro metamodel. The necessary source code is then generated automatically and conforms to a standard architecture known as the Web Dynpro Framework (WDF).
The WDF allows each controller within a component to have a set of standard hook methods. It is within these hook methods that any required custom coding can be placed.
In addition to the events provided by the WDF, you can also define your own events for a Web Dynpro application.
All Web Dynpro applications are constructed from the same basic units. However, through the use of custom coding in the standard hook methods, the standard framework can be extended to supply any required business functionality.
Not all implementation decisions need to be made at design time. It is perfectly possible to implement a Web Dynpro application in which the appearance of the user interface is decided at runtime. This allows a highly flexible application to be written without requiring the need to directly write any HTML or JavaScript.

Application Situations with Web Dynpro

nA Web Dynpro Model Object can be supplied with information from the following types of backend system:

RFC Modules, for example, BAPIâ€™s within an SAP ABAP after sales system. This interface is supplied by the Adaptive RFC Layer (aRFC).
Enterprise JavaBeans (EJBs) which encapsulate application logic.
Web Services

Context Mapping

Webdynpro Context mapping

Context mapping allows a context node in one controller to be supplied automatically with data from a corresponding context node in another controller. This is the primary mechanism for sharing data between controllers.

Mapping Terminology

When two controllers within the same component share data through a mapping relationship, this is known as â€œInternal Mappingâ€. The context node that acts as the data source is known as the â€œMapping Origin Nodeâ€, and the context node that is mapped is known as the â€œMapped Nodeâ€. There is also a type of mapping known as â€œExternal Mappingâ€, but this will not be dealt with in this chapter.

Requirements

In order for a mapping relationship to be established, the following steps must first be performed:

A node must exist in the context of the controller acting as the mapping origin. This node need not have any declared child nodes or attributes.
The mapping origin controller must be a custom controller.
The controller containing the mapped node must declare the use of the mapping origin controller as a required controller.

Data Binding

Data binding is the means by which data is automatically transported from a view controllerâ€™s context to a UI element in its layout.You may not bind UI elements to context nodes or attributes that occur in some other controller. UI elements are private to the view controller within which they are declared.

The data binding process decouples the UI element object from the application code within the view controller. Therefore, in order to manipulate UI element properties, the application code in the view controller needs only manipulate the values of context nodes and attributes to which the UI elements are bound. The Web Dynpro Framework then manages the following two tasks:

The transport of data from the context to the UI element during the screen rendering process.
Repopulating the context from the UI element after data is entered by the user.

Outgoing Plugs

Calling an outbound plug method causes a navigation event to be raised. Navigation events are special, asynchronous events that are placed into a navigation queue.Â Only when all the outbound plugs have been called by all the views in the current view assembly, will the Web Dynpro Framework enter its navigation processing phase.Â Outbound plugs should be named according to the action that caused navigation away from the current view.

Inbound Plugs

Inbound plugs are special event handler methods that subscribe to navigation events raised when outbound plugs are fired.Â Inbound plug methods are called only when the navigation queue is processed.Â This will only take place once all the views in the current view assembly have fired their outbound plugs and no validation errors have occurred that would cause navigation to be canceled.Â Inbound plugs should be named according to the reason for which the view is displayed.

Links

Outbound and inbound plugs are joined together using navigation links.

Windows, View Sets and View Areas

webdynpro navigation between views

When creating a Window, you define three things:

All the possible views that could exist in the componentâ€™s visual interface.
The layout and position of those views within view sets and view areas
The navigation links that exist between different views

You can embed either a single view or one or more view sets into a window. Each view set in turn is divided into view areas, each of which can have one or more views or view sets embedded within it.A view area can only display one view at a time. Navigation links must be defined between views in order for the contents of a view area to be replaced.

View areas can be blanked out by creating an empty view whose inbound plug responds to an appropriate navigation event.

View Assembly

Special asynchronous navigation events are the triggers that cause a view area to contain a particular view. For a given window definition in which multiple views are embedded into view areas, there could be many permutations of views visible. The permutation that is visible depends on which navigation links the user follows. The subset of views visible at anyone time is known as a â€œView Assemblyâ€.

Web Dynpro Architecture

The architecture of a Web Dynpro Component can be divided into two parts â€“ externally and internally visibility:

The horizontal dotted line separates the entities that are visible from outside the component, from those that are only visible from within the component.
A view consists of a view layout and the corresponding view controller. A view can contain navigation plugs, methods, and a context.
A window embeds one or more views and has a corresponding window controller. A window can contain navigation plugs, methods, and a context.

A Web Dynpro Component can declare the use of another Web Dynpro Component. A specific component usage is then created and the parent component accesses the functionality of the child component via its component interface controller.The only parts of a Web Dynpro Component that are visible to the outside world, are the interface controller and the interface view(s).

uAll Web Dynpro components have only one Interface Controller.There is a one to one relationship between a Window and an Interface View.If the component has no views, then it will have no Windows, which in turn, means that it will not implement an interface view. Such components have no visual interface and are known as â€œfacelessâ€ components.

Web Dynpro Application

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. 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, so the functionality of a single Web Dynpro component can be accessed by defining multiple applications.

Application definition

To be able to define an Web Dynpro application, you have to specify

The component to be invoked. This component is then known as the â€œrootâ€ component,
Which interface view of the root component will be used as the initial view assembly,
Which inbound plug will act as the entry point for the nominated interface view (this inbound plug must have the Startup check box selected)

Watch out this space as we introduce some tutorials covering every aspects of web Dynpro ABAP.

Floorplan Manager for Webdynpro – Developers Handbook

FPM (Floorplan Manager) is an application provided by Web dynpro Application that provides a framework for developing webdynpro applications interfaces which are consistent with the SAP’s UI guidelines.

Download Developers Guide Floorplan Manager.