Expand +



Web Dynpro — Not Just for Java Developers Anymore

by Karl Kessler | SAPinsider

January 1, 2006

by Karl Kessler, SAP AG SAPinsider - 2006 (Volume 7), January (Issue 1)

Karl Kessler,

One of the standout features of SAP NetWeaver is its support for open technology and user interfaces that are browser-based, model-driven, device-independent, and accessible — in short, everything today's Web applications require. SAP NetWeaver's UI technology, Web Dynpro, is a first-class approach to building application content designed to run in SAP NetWeaver Portal. And because Web Dynpro is language-independent by design, it's not just for Java developers. Those application developers who are fluent in ABAP and have mastered Web enablement through BSPs will now be able to build Web Dynpro applications in a familiar development environment with substantial support for efficient, reliable development that they can reuse and — best of all — that requires minimal coding.

Some Background on Web Dynpro

From the very beginning, the Web Dynpro metamodel was designed in a programming-language-neutral way. Web Dynpro uses the model-view-controller (MVC) approach to Web interface development (see sidebar below, "Similar Functions, Different Tools"), so that a Web Dynpro component and all its pieces have the same semantics whether they are written in ABAP or Java. The very first version of the Web Dynpro development environment to be delivered was for Java-based projects. It included strong tool support from SAP NetWeaver Developer Studio based on the powerful, open-source tooling platform Eclipse. The resulting customer projects typically target SAP NetWeaver Application Server Java as the runtime environment.

But what if your team has strong ABAP skills and a background in BSP programming? Or perhaps the backend services you would like to address are not fully exposed as the Web services or remote function modules required for Java model binding? Or what if, from a performance point of view, you cannot afford a decoupling of UI logic executed on the server and the underlying business logic? What if you already have working ABAP software maintenance in place but cannot quickly set up a development infrastructure for Java? In all these cases, Web Dynpro ABAP can help.

This article takes you on a quick tour through the tools of Web Dynpro ABAP and walks you through a simple flight report example to highlight new and updated tools in the familiar ABAP environment.

Web Dynpro ABAP is part of SAP NetWeaver 2004s, which is the foundation for the shipment of the mySAP Business Suite, most prominently mySAP ERP 2005. As its name suggests, Web Dynpro ABAP uses exactly the same metamodel as its cousin Web Dynpro Java, and their views, models, and controllers share the same semantics — so there is no need for developers to learn a new UI paradigm. The main differences between Web Dynpro Java and ABAP are simple ones designed to make it easy for developers to transition between traditional ABAP projects and Web Dynpro applications:

  • The Web Dynpro ABAP design-time environment is embedded directly in the ABAP Workbench. (For a look at how the tools are similar in functionality, see the sidebar "A Brief Guide to Web Dynpro Terminolgy for ABAP Developers.") Web Dynpro artifacts (components, views, models, etc.) are listed just like any other of your ABAP-based projects and BSP applications. ABAP developers can access all projects in the same way and in a familiar environment.

  • ABAP developers won't find any surprises in the development infrastructure, either. The correction and transport system keeps track of all changes, versions them, and helps propagate the Web Dynpro application from development to production — just as you would do with any BSP or dynpro-based applications.

  • The execution platform is the ABAP server, rather than the Java server. This ABAP server produces application content ready to be seamlessly integrated into the SAP NetWeaver Portal. Features like portal eventing can be used between applications written in ABAP and in Java or generated by Visual Composer.

The story of Web Dynpro ABAP sounds simple: it's easy and efficient to create a modern Web UI with very little coding and in a familiar ABAP development environment. As with Web Dynpro for Java, however, while creating the UI is simple, the Web Dynpro tools within the ABAP Workbench are highly sophisticated. This article takes you on a quick tour through the tools to showcase their capabilities, walking through a simple flight report example that touches all major editors (see the result in Figure 1). We created this same interface with Web Dynpro Java in a previous column.1 As with Web Dynpro Java, you might be surprised by how little coding is required.

Figure 1

The Final Flight Search Interface, Automatically Generated and Viewed in the Browser

A Brief Guide to Web Dynpro Terminology for ABAP Developers

Web Dynpro strictly follows the model-view-controller (MVC) paradigm, meaning that any application you design with Web Dynpro cleanly separates the layout and the interaction code from the business data.* In this widespread UI-development paradigm, the component consists of three basic parts:

  • Model — The model indicates the business data to be manipulated and corresponds to the global data and tables of the module pool.

  • View — The layout information is all held in the view, which corresponds roughly to fields and subscreens in the traditional dynpro model.

  • Controller — The controller manages the interaction of the interface. This corresponds to the flow logic in the classical dynpro model.
Some other Web Dynpro terms include:
  • Context — The context is technically a hierarchy of variables related to the user interface. ABAP developers can think of the context as being similar to the field list, while the dynpro fields are similar to the view. The field transport then automatically copies the values from the program to the user interface and vice versa. Likewise, variables of the Web Dynpro context are copied back and forth to corresponding Web Dynpro view fields.

  • Service controller — A service controller is a controller that encapsulates a service call. In the example we walk through in this article, this is a simple BAPI call.

  • Component — A component is a modular unit with various interfaces (both programmatic and UI-oriented).
* For an overview of MVC, see my article in the April-June 2003 issue of SAP Insider, as well as the article by Dr. Peter Tillert in the October-December 2003 issue, entitled "How to Streamline User Interfaces: Web Dynpro Makes Software Reuse a Reality" (

Similar Functions, Different Tools

Here is a quick look at the tools used for various designing tasks with dynpro and their corresponding tools when using the Web Dynpro model.

Tool Aspect Dynpro Web Dynpro
Layout Screen Painter
Field List Editor
View Designer
Context Editor
Outline of program/component Object Browser Web Dynpro Explorer
Event code ABAP Editor ABAP Editor
Navigation Implicit in code Navigation Modeler
Data flow Implicit in code Data Modeler

New Workbench Tools for Web Dynpro ABAP

This article will introduce new or updated tools that SAP has added to the familiar ABAP environment, including:

  • Web Dynpro Explorer

  • Web Dynpro Designer

  • Web Dynpro Wizard

  • New updates to editing code in the ABAP Workbench

Let's jump directly into our example, beginning with the ABAP Development Workbench (transaction SE80). In Figure 2, you can see that the dropdown box now includes a new category for Web Dynpro Component/Interfaces. Here's where our work starts.

Figure 2

Launching the ABAP Development Workbench in SAP NetWeaver 2004s

The Web Dynpro Component

You can think of a Web Dynpro component as a modular unit with various interfaces (both programmatic and UI-oriented). To start the process, name your new component (z_bapiflight in our example). Once you enter this component name, a dialog pops up to actually begin creating the Web Dynpro component in the Web Dynpro Explorer. Here, you'll be asked to fill in the typical correction and transport information. In our result, shown in Figure 3, the outline of the newly created Web Dynpro component is on the left and some dependency information is on the right.

Figure 3

Viewing the Newly Created Web Dynpro Component

One of the outstanding features of the Web Dynpro model is its ability to have data attached on various levels (e.g., the view and the controller). This is much like the classic dynpro, which had a similar feature based on field lists and dynpro fields; a field transport then automatically copied the values from the program to the UI and vice versa.

Web Dynpro follows this tradition, but in a much more fine-grained way. This is the context, which is technically a hierarchy of variables related to parts of the user interface. You can attach a context to a view on the view level and to a component on the component level, which is not necessarily visualized. Once you have defined the contexts at the various levels, you can then graphically map context nodes in the Context Editor and the information flows automatically — you will see this in our example.

Web Dynpro View and Designer

A view contains all visual controls, such as buttons, labels, and fields. From the outline menu, we create a new view, which can be edited in the Web Dynpro Designer (see Figure 4). The Web Dynpro Designer is a WYSIWYG tool that immediately renders what you have changed so far. On the left you see a rich palette of graphical controls at your disposal, grouped by category. You simply drag and drop controls into your layout. On the upper right, the control is incrementally built, and below you find the usual list of properties for that control.

Figure 4

A View of the Web Dynpro Designer

Web Dynpro Wizard

Now that the view is complete, we need to manage how these controls function — in this case, we'll focus on a key control in our interface, the "Search Flights" button (the Get List function). At the controller level, we could start to maintain the layout manually, but there is a much faster method: the Web Dynpro Wizard. This wizard helps you derive a lot of properties for input fields and output fields automatically. Launch the wizard from the context menu of the Web Dynpro Explorer and a dialog pops up asking you for the specification of a service controller. In our example, this is a simple BAPI call, but it could be a simple function module or a Web service call as well.

The wizard guides you through a series of steps (see Figure 5) where you first select a controller that should contain the service call (I simply used the component controller), then you specify a service type (function module), then the name of the function module or BAPI to be called, and finally the parameters of the BAPI that should be reflected in the context.

Figure 5

The Web Dynpro Wizard for Generating the Service Call

The final result of the wizard is the context for the service call triggered by the Get List button, as shown in Figure 6. The context hierarchy on the right side contains the DESTINATION_FROM and DESTINATION_TO fields, which will serve as search criteria, and the FLIGHT_LIST as the result table.

Figure 6

The Controller Context for the Service Call Invoked by the Search Flights Button, Generated from the Web Dynpro Wizard

Defining the Graphical Layout of the Interface

Now that we have created the context for the service call, let's quickly specify the graphical layout of our application (see Figure 7), including mapping the controller to the view. In Figure 7, you see how the controller context and the view context are mapped. The Web Dynpro runtime will transport the search fields (in our example, DESTINATION_FROM and DESTINATION_TO) from the view to the BAPI call, execute the BAPI, and place the result table back in the view context again so that the Web Dynpro rendering can produce the output page in the browser.

Figure 7

Mapping the Controller and View Contexts

Once you've defined the mapping, you can derive a container form that renders all the fields plus their labels derived from the BAPI definition simply by selecting a context node for DESTINATION_FROM and selecting the relevant fields.

To launch the BAPI from the user interface, we need to add a button, associate an action with the button, and place the BAPI call inside. The code is then presented in the brand-new ABAP Editor, which is full of features that make it worthy of its own "Under Development" column (see sidebar, "The New ABAP Editor with Web Dynpro ABAP").

But, as I mentioned above, Web Dynpro is not the place to dive into code. Of course, you probably won't get away with no coding, but the Web Dynpro development environment is designed to capitalize on reuse and keep manual coding to a minimum. So instead, we'll focus here on the last step, where we add a table to the layout and specify its binding. The result is shown in Figure 8.

Figure 8

The Final Layout of the Flight List Interface with Table Binding and Object Properties

The New ABAP Editor with Web Dynpro ABAP

A complete discussion of the new ABAP Editor is certainly beyond the scope of this article, but here is a list of some of its more outstanding features:

  • Coloring and highlighting that reflects the ABAP syntax.

  • Source code compression that allows you to fold and unfold a syntactical structure, such as method…endmethod. For example, you can expand or collapse a "while loop" so you can hide the code inside the loop.

  • Macros, which mean less typing for developers. For example, you can generate "if-then-else" constructs to save development time and effort.

  • Code snippets, which allow developers to cut and later paste some lines of code. For example, you can reuse a sort function later on that you don't currently need.

  • A lot of personalization extras, including color assignments, indentation rules, etc.

A future "Under Development" column will cover the ABAP Editor in more detail. For more on the new ABAP Editor, please see --> Web Application Server --> ABAP.

 New ABAP Editor

Launch the Application

We're almost done. What is missing is the proper embedding of the view in the component's window (see Figure 9) and the creation of a starting point for the application. Once you test your application, data flows from the input fields to the BAPI call, and the results of the BAPI call are immediately and automatically sent back to the table control, which is finally rendered in the browser, as shown back in Figure 1.

Figure 9

Web Dynpro Builder

This step completes our quick tour. Although the application was a simple example, it touched on the important areas of the Web Dynpro tools set inside the ABAP Workbench.

More Advanced Features of Web Dynpro ABAP

Web Dynpro has much more to offer than simple input/output handling. Maybe you saw the rich palette of controls in the view layer back in Figure 4. Besides offering nice features such as predefined business graphics and embedded Microsoft Office applications, Web Dynpro hosts a complete form design environment based on Adobe Designer. Here you can define interactive forms that exchange contextual data with Web Dynpro controls as if they were properly built in. During runtime the Adobe formula is then processed in the Web Dynpro context. Features like context mapping are applicable here as well.

Other features also ease development and make for richer interfaces. For example, you can take advantage of personalization features that allow an end user to customize the order of columns that are displayed — and hide columns that are not needed — in a large table. In addition, portal integration (e.g., portal eventing), definition and reuse of Web Dynpro components, and the Web Dynpro ALV, which has similar capabilities as its counterpart in the ABAP controls world,2 are also now available with Web Dynpro ABAP.

For more information, please visit --> Web Application Server --> ABAP to view tutorials about Web Dynpro ABAP's additional features.


Web Dynpro ABAP is a strong model-driven tooling environment based on the classical ABAP infrastructure. The focus of Web Dynpro ABAP is not just on getting interfaces ready for use as iViews or for browser-based access.

It's also on making it easier for developers to create these interfaces, whether it's functionally, with a familiar development environment, or technically, with final Web application interfaces that can integrate with and run in SAP NetWeaver Portal.

The best news of all for ABAP developers is that you'll be typing in less code and making better use of the applications you've already built: coding is reduced to a minimum in Web Dynpro applications, and reuse is a key part of the Web Dynpro strategy.

If you currently develop applications based on BSP, you should look at whether Web Dynpro offers additional choices and more abstraction than low-level HTML code.

For more information, please visit --> Web Application Server --> ABAP or (and search for Web Dynpro ABAP).

1- See "Under Development: Your 'Easy Way In' to Web Dynpro Development: New Design-Time Tools Now Available with SAP Web Application Server 6.30" in the April-June 2003 issue of SAP Insider (

2- Beyond the Web Dynpro controls layer, Web Dynpro ALV offers a lot of prebuilt functions for filtering, sorting, and totaling similar to the classic ALV.

Karl Kessler joined SAP in 1992. He is the Product Manager of the SAP NetWeaver foundation, which includes SAP NetWeaver Application Server, Web Dynpro, ABAP Workbench, and SAP NetWeaver Developer Studio, and is responsible for all rollout activities. You can reach him via email at

An email has been sent to:

More from SAPinsider


Please log in to post a comment.

No comments have been submitted on this article. Be the first to comment!