,

Web Dynpro In a Nutshell

Web Dynpro In a Nutshell

Web Dynpro

From a technological standpoint, SAP’s Web Dynpro for ABAP/Java is a ground-breaking measure in the development of internet-based user interfaces. It’s entirely unlike any design paradigm used by SAP and signifies a quantum leap in the development of internet-based, ERP programs.

DynPro in SAP refers to Dynamic Programming relating to the screens and flow logic, which controls the processing and display of these screens. On a broader scale, a screen is also referred to as a DynPro.

Design Philosophy Behind Web Dynpro

Web Dynpro programs are constructed using declarative programming techniques based on the Model View Controller (MVC) design paradigm. That’s, you define where those components will get the client’s data from, and what user interface elements you want on they. All the code is subsequently created automatically within a runtime framework. This relieves you from the repetitive coding jobs called for in writing HTML and making it interactive with JavaScript.

Web Dynpro Primary Advantages

The primary objective of web Dynpro is to empower application programmers with at least effort using illustrative tools in a structured design procedure to create powerful Web applications. The key will be to describe a program – any programming is only going to be an extremely minor part of program development. The programs should run on numerous kinds of network and on a variety of devices.

One guiding principle in the Web Dynpro approach is:

the fewer lines of handwritten code there are in the UI, the better.

Web Dynpro pursues this aim in two ways. Web Dynpro creates a declarative language for defining qualities of an user interface without writing any code. From this subjective definition, code is generated by Web Dynpro for a prepared-to-run application skeleton of the user interface, and in addition, it derives metadata which the generic engine can interpret at runtime. Handwritten code has its area, but it’s reduced to the absolute minimum. Second, it supplies practical characteristics including support for flicker free interaction, internationalization and a clean separation of the user interface and the business logic. To ensure this separation Web Dynpro applies the Model View Controller (MVC) paradigm implemented in Smalltalk 80.
From the meta data created during the design stage, Web Dynpro can create code for runtimes like J2EE and ABAP, and may also support .NET runtime.

Metamodel Theory and Declarative Programming

Web Dynpro supplies support for the development of Web applications in the shape of a declarative programming strategy. You use specific tools to describe the properties of a Web Dynpro program in the kind of Web Dynpro metadata. The crucial source code executed at runtime and is subsequently created mechanically. For a Web Dynpro application, it is also possible to define your own occasions besides the occasions supplied by the framework. For this goal, the source code includes places that are different, specially marked.

With the exception of the individual interface elements for each program, every user interface is consistently composed of the same fundamental components, in a Web Dynpro application. You declare these components of the metamodel. It’s additionally possible to execute components of the metamodel in applications and incorporate them at runtime. Using these executions, you can make improvements or changes to an user interface that declarative systems have created by creating new interface arrangements at runtime. The metadata of a Web Dynpro application is separate of the platform on which the program is executed. The metadata is transported to the platform specific development environment; the source code needed for this platform is created. Just the source code you’ve programmed for the event management, for instance, would need to be adapted to satisfy the new platform.

Program Scenarios with Web Dynpro

The Web Dynpro programming version supports the backend systems that are following:

  • BAPIs in the ABAP backend system. With support of the SAP Enterprise Connector, Java proxies can be generated fast and comfortably by you. The BAPI call is done by an interface that is created from the SAP Java Connector (SAP JCo).
  • Enterprise JavaBeans (EJBs) which encapsulate the program logic
  • Web Services
  • XMI versions that are outside (TogetherSoft / Rational Rose): The source code can be created from an UML definition of the Web Dynpro interface. The Web Dynpro program An UML definition can be imported by programmer as XMI file with wizard support (Web Dynpro Model Tools).

Layout-established UI Layout

An UI design is a remedy to an interaction issue in the context of an user job. Technically, there is an UI design a generic, configurable Web Dynpro UI component group that’s been assembled to deal with jobs common to several programs. Using UI patterns has the following advantages:

  • An unified design both across and within programs
  • A sharp separation between backend and front end thus changes to the UI
  • don’t affect the business logic
  • Rapid and efficient software development
  • Lower development prices
  • Reuse
  • Reduced care conditions
  • Developments to designs can be made after centrally

Client-Side Framework (CSF)

A JavaScript-based client software application, the Client-Side Framework (CSF) runs in the user’s browser. The CSF enables the browser to send an http-based subjective definition of the user interface. The CSF evaluates this advice while the program data is passed individually. The entire program is subsequently created by the CSF from program data and the user interface definition. CSF offers these advantages:

  • Quicker display creation: Upgrading of displays is limited to the region that is altered
  • Flicker free display of screen output signal: The end user sees a display that is stationary
  • Decrease in the amount of server requests through intelligent use of caches
  • Higher degree of security for the Web application

Web Dynpro Tools

The SAP NetWeaver Developer Studio includes a variety of Web Dynpro tools, to support the declarative programming theory

  • In a tree structure, the Web Dynpro Explorer supplies a reasonable review of the Web Dynpro application.
  • The navigation modeler provides navigation definition for the flow sequence of the interface elements, and complete graphical support for program layout, Execution of interface elements and their alignment on the display.
  • The biew designer is a graphical program.
  • Version tools: The information for a Web Dynpro application is supplied using versions. There are particular version types for all the various backend scenarios.
  • The information modeler provides support for the definition of custom controls and models and their use, and for the creation of data links for mapping definitions. It is also possible to use this tool to create perspectives.
  • The control/circumstance editor provides graphical support for the execution of the data stream.
  • Message editor: A message wizard provides support for the rapid definition of user output signals.

Supported backend systems

This backend systems can be used by a Web Dynpro program and are supported:

  • The SAP Enterprise Connector enables easy and fast generation of Java proxies
  • Encapsulation of the processing logic in Enterprise JavaBeans (EJBs)
  • Use of Web services

Model View Controller (MVC) strategy

Model View Controller
Model View Controller

You can get a clear separation of presentation and program logic. A Web Dynpro program has local or distant access to the backend system via a particular service and runs on the front end. The entire demonstration logic is part of the Web Dynpro program, while continuity and business logic of the company objects run in the backend system. Each Web Dynpro program follows the Model View Controller strategy. The version is in charge of supplying data to the whole program and is the interface to the backend system. There is a perspective the essential rational layout component of the Web Dynpro application. It’s in charge of the browser output signal and for processing the presentation logic. A control manages the data stream between the model and the perspective in both ways.

Views and layouts

A perspective describes behaviour and the layout of a rectangular area of an user interface. Every Web Dynpro program has at least one view. A view’s layout consists of distinct user interface elements. The provided layout variations supports the placement of interface elements in one view.

Views, layouts, and navigation

Stoppers enable navigation between distinct perspectives. These may be split into outbound and inbound stoppers. Outbound plugs enable navigation to another view, while inbound stoppers define the potential entry points of a perspective. Generally, several views are embedded within a Web Dynpro window, which is the reason it is essential to qualify a view as the view that’s shown when a window is called. This perspective is assigned the StartView property. The following navigation arrangement is subsequently created using this perspective. The entering of a view always causes an event handler method to be called. This is the reason an event handler method is mechanically created for every inbound plug to browse from one view to another; each outbound plug from the first view must be linked with the aid of a navigation link with an inbound plug from the second view. Just one navigation connection can originate from one plug that is outbound. By comparison, several outbound plugs can control an inbound plug.

View sets and view places

A view set supplies a visual framework with subsections that are predefined (view places) into which you’ll be able to embed your views at design time.

Web Dynpro controller

Controllers are the active parts of a Web Dynpro application. They define how the user interacts with the Web Dynpro application.

Views and controllers

Different instances of controllers and contexts exist within a Web Dynpro application. In addition to view controllers, which control the behavior of an individual view, there are also global controllers, which offer more general services for all the views of a component. 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 for as long as the view is displayed in the browser. If the view is replaced by a successive view, the local data is also no longer available.
Moreover, each Web Dynpro component has at least one global controller, called the component controller.
The lifetime of the component controller is determined by the lifetime of the entire application.

Data binding and context mapping

Every view always possesses a controller, which saves its local data in a view context. A UI element can be bound to a context only if it belongs to the same view. In general, however, the lifetime of a view context is too short, and its visibility too restricted, for it to be suitable for saving data used across several views. This is where the standard context of the Web Dynpro application comes into play. This standard context belongs to the controller of the Web Dynpro component. Its lifetime is determined by the lifetime of the whole application. Moreover, this context can be made visible to some of the view controllers and not others. So that you do not have to copy data explicitly between two contexts, you can map the relevant elements of the two contexts to each other. This is known as context mapping. Whenever an element of a view context is mapped to the corresponding element of the component context, the data is stored in the global component context, not in the local view context.

Web Dynpro models

The model retrieves the application data from the back end. The data for a Web Dynpro application can originate from different sources. You can:

  • Call and use SAP data from a SAP back end using BAPIs
  • Define new data
  • Call and use Web services
  • Combine the three above procedures
  • Import an external model using the appropriate tools

The Component Interface

The component interface consists of two visual parts and one programmatic part.

  • The programmatic interface allows an embedding component to interact with an embedded component by calling methods and reacting to events. Currently, the programmatic interface of a component consists of the interface controller. With 6.40, there will also be a configuration controller.
  • The visual interface allows you to embed the component windows as views in the embedding component. To achieve this, the window has a one-to-one association with an interface view in the component interface. The visual interface of a component is optional.

Embedded Web Dynpro components

A Web Dynpro component is a reusable entity. It contains all basic Web Dynpro application elements that are needed for a Web Dynpro application, plus the Web Dynpro model and the startup entity, the Web Dynpro application. You have the option of nesting Web Dynpro components. This is referred to as embedding. Embedding Web Dynpro components offers the following advantages:

  • The Web Dynpro application is divided into interacting elements.
  • The structure of a large Web Dynpro application is clearer.
  • Working with reusable elements saves costs and development resources.
  • At design time, the embedding Web Dynpro component has no knowledge of the internal structure of the embedded Web Dynpro component; it does not become visible to the embedded Web Dynpro component until runtime.

The interaction between nested Web Dynpro components is implemented using method calls that originate from the embedding Web Dynpro component. The Web Dynpro component interface starts these method calls. When nesting Web Dynpro components, this interface function is obligatory and must be implemented in the program logic. However, an optional visual interface is also available

Web Dynpro Application

An application is like a transaction code in ABAP. It is an entry point to a Web Dynpro component (and its embedded components and used models), addressable via URI.

  • To define an application, the following entities must be named:
  • The root component to be invoked
  • The interface view of the root component (and, therefore, the window to be called)
  • The inbound plug of the specified interface view

Leave a Reply

Your email address will not be published. Required fields are marked *