You are on page 1of 25

No portion of this publication may be reproduced without written consent.

3
Put your integrated WebSphere environments into production fast
For years, SAP teams with ABAP experience have longed for a solution
whereby ABAP developers could write professional, Web-based applica-
tions without having to learn HTML or JavaScript. At the same time, SAP
has longed for a solution to bridge the divide between SAP applications
written in ABAP and those written specifically for the Web. Until now,
ABAP developers were left with the daunting task of having to learn an
unfamiliar technology, such as Business Server Pages (BSPs) or (worse yet)
Java, and SAP grew to rely heavily on a gateway, such as SAP Internet
Transaction Server (ITS), to dynamically convert (i.e., screen paint) SAP
GUI Dynpro screens to HTML. With SAP NetWeaver 2004s, SAP
customers, partners, and even SAP itself finally have a viable solution.
Web Dynpro for ABAP (WD4A) — a form-based version of the stable,
proven classic Dynpro technology underlying ABAP — promises to change
how both SAP and SAP customers design, develop, and deploy new
business applications. If this sounds like I’m overstating its significance,
consider that SAP is in the process of migrating its entire product portfolio
to Web Dynpro over the upcoming months. The first completely Web
Dynpro ABAP-based releases, which were introduced to the market
recently, are SAP Supplier Relationship Management (SRM) 6.0 and
SAP’s new mid-market solution, SAP All-in-One. Since there
are no plans to upgrade SAP Enterprise Resource Planning (ERP) 2005 to
a new version until 2010, the Web Dynpro ABAP-converted applications
will be shipped in SAP ERP 2005 enhancement packages.
1
At this point, perhaps you’re wondering: Why is Web Dynpro for ABAP
so revolutionary? How is it superior to SAP’s existing Web development
Get started developing Web-
native custom SAP applications
with Web Dynpro for ABAP
by Ulli Hoffmann
Ulli Hoffmann
Managing Director
INIDFAB Computing GmbH
Ulli Hoffmann is Managing
Director of INIDFAB Computing
GmbH, a company that focuses on
the development and technology
of Web-based applications and
processes running on the SAP
NetWeaver platform. Besides
developing the business of
INIDFAB, Ulli is involved in
various projects with SAP AG
and SAP customers as a senior
consultant. Currently, his major
project is designing and
implementing a Web Dynpro
ABAP-based extension framework
for SAP SRM 6.0. Ulli is the
author of a book on Web Dynpro
for ABAP published by SAP
PRESS. You may contact him at
ulli.hoffmann@inidfab.com.
1
Examples of this massive project are component LORD_MAINTAIN_COMP, which replaces the
SAP GUI transactions for sales order processing VA01 through VA05, and component MMPUR_
LEAN_PO_COMP, which replaces the SAPGUI transactions for purchase order processing ME21
trough ME23. SAP is already urging customers to begin using Web Dynpro for all future
development projects.
This article originally appeared in the July/August 2007 issue of SAP Professional Journal and appears
here with the permission of the publisher, Wellesley Information Services. For information about SAP
Professional Journal and other WIS publications, visit www.WISpubs.com.
SAP Professional Journal • July/August 2007
4 www.SAPpro.com ©2007 SAP Professional Journal. All rights reserved.
options such as BSPs, SAP ITS, and the classic
Dynpro development? There are four key reasons:
• Web Dynpro for ABAP is based on a metamodel
concept. When a Web Dynpro application is dev-
eloped, the data is stored in tables as metadata.
Depending on the rendering technique used by
the client, the source code, which is executed at
runtime, is generated from the data residing in
the metadata tables. With this approach, the appli-
cation developer doesn’t need to consider during
design time which client will run the application.
The WD4A framework provides adapter modules
that generate the client-specific rendering. Pro-
viding the availability of such adapters, Web
Dynpro ABAP applications are able to run on the
Web, mobile devices, smart clients, and so forth.
• Web Dynpro for ABAP applications can be
written by ABAP developers. Over the years,
SAP customers have trained and educated armies
of developers and business process analysts in
the specifics of SAP’s proprietary programming
language, ABAP. Their huge investment is
preserved by letting these experts now write
feature-rich applications based on ABAP that can
be run on the Web or in any other environment.
• Web Dynpro for ABAP applications provide
easy access to comprehensive ABAP stack
functionality. SAP applications deliver many
features that increase the efficiency of developers
and users of business applications, and therefore
any application that carries the SAP logo should
include these features. With Web Dynpro for
ABAP, functionalities such as the F1 and F4 help
systems, T100 messaging, modification-free
enhancements, and many more are now available
to be integrated into Web Dynpro for ABAP appli-
cations via a few mouse clicks.
2
• Web Dynpro for ABAP separates business logic
from presentation logic. Web Dynpro for ABAP
implements the Model-View-Controller paradigm
(MVC).
3
The clear separation of logic layers
allows a better understanding of the design and
development process, urges developers to improve
the quality of their work, and lowers project and
maintenance cost at the end of the day.
With all of these benefits, it’s not hard to under-
stand why SAP is migrating business applications to
WD4A, but also why SAP’s emerging form-based
client technologies such as SAP NetWeaver Business
Client and SAP Interactive Forms by Adobe will be
based on Web Dynpro for ABAP as well.
Note!
Web Dynpro for ABAP is a new development
option for programmers writing complex
business applications. Web Dynpro for ABAP
does not replace SAP Visual Composer
4
within
SAP NetWeaver Portal or the Web Application
Designer within SAP NetWeaver Business
Intelligence (BI), which continues to enable
non-programmers to develop only simple,
Web-based reports without programming.
This article provides an introduction to Web
Dynpro for ABAP programming and some guidance
for your future development projects and decisions.
The new Web Dynpro design time, which is integrated
into the ABAP Workbench, provides a number of
tools for developing WD4A applications. I describe
these tools throughout this article to help you become
familiar with their core functionalities. I also cover
when to use them and for what purpose.
2
Implementing such functionalities in a Web Dynpro Java application
either is not feasible or requires much more effort compared to Web
Dynpro ABAP. The developer needs not only to write complex Java
scenarios to get the desired behavior, but also to extend the ABAP
back end to provide the data through remote function calls (RFCs)
or Web services.
3
For information on the MVC paradigm, go to Wikipedia, the online
encyclopedia, at http://en.wikipedia.org/wiki/Model-view-controller.
4
For information on this development tool, refer to the SAP Professional
Journal article, “Get started creating SAP Enterprise Portal iViews with
Visual Composer — a purely model-driven, code-free development
approach” by Karl Kessler (November/December 2005).
Get started developing Web-native custom SAP applications with Web Dynpro for ABAP
No portion of this publication may be reproduced without written consent. 5
With WD4A you can develop applications in
two manners, one is called declarative program-
ming — you create the layout including the screen
elements and the containers providing the data to
the screen elements using tools such as the View
Editor and Controller Editor. In addition to using
these graphical tools, you can design your user
interface (UI) by writing pure ABAP code. In
WD4A this is called dynamic programming in
which you develop your application in a way that
decisions towards the structure of the layout and
data containers as well as navigation are made
during runtime. This enables the developer to
implement generic components that can be used
for a variety of application scenarios. However,
dynamic programming requires a deep under-
standing of the inner workings of the framework.
Because this article serves as an introduction
to WD4A framework, its focus is on declarative
programming.
To help you become familiar with the develop-
ment environment and the process of component
development, I step you through developing a
component that can be used to display purchase
order data. The goal of the example is to show
the steps required to develop a component that is
able to display the header and item data of a given
purchase order. Another important characteristic
of WD4A is its component-based structure, which
focuses on component reuse. To help illustrate
this functionality, I show you how you can inte-
grate and use an existing component in a broader
business case. The idea is to develop a component
that displays the header data of a particular
purchase order and provides the functionality of
displaying the items of that purchase order in a
list as well as the detailed data of a single selected
item. During development of the example, we’ll
take into consideration that the component can
be used in a business application that can create,
change, and delete purchase orders and identify
where items can be added to these purchase orders.
The article is aimed at the ABAP developer
community, which has become familiar with the
ABAP Workbench over years of implementing
classic Dynpro applications. Having some experi-
Note!
You can use this article as a starting point to get
insight into the concepts, behavior, and advan-
tages of the Web Dynpro for ABAP framework.
It should encourage you to try to develop more
complex scenarios and enable you to estimate
development effort for developing feature-rich
user interfaces (UIs) in WD4A.
Note!
Classic Dynpro development
5
still remains an
option for development of design and adminis-
trative tools. An example is SAP’s integrated
development environment (IDE) for ABAP
development, better known as ABAP
Workbench. You should consider using BSP for
UI development in the following cases:
• The application is going to run only in a
Web environment
• The customer’s requirements are based on
pixel-exact rendering and positioning of
screen
• The application requires rich graphic and
plug-in support
• The application runs in stateless mode
5
For more information on dynpro programming, see the SAP
Professional Journal articles, "Take another look at ABAP dynpros —
practical programming techniques for better user interfaces with more
control and fewer surprises" and "Take another look at ABAP dynpros
— advanced programming techniques for better user interfaces with
more control and fewer surprises" by Doris Vielsack and Arndt
Rosenthal (March/April 2006).
SAP Professional Journal • July/August 2007
6 www.SAPpro.com ©2007 SAP Professional Journal. All rights reserved.
ence in BSP
6
will help you to understand the way
view elements (which are the controls of the visible
area of a user interface) are positioned on the screen
and how to modify their appearance. In general,
developing Web Dynpro ABAP applications means
dealing a lot with object-oriented methodologies and
design patterns. Therefore, you should have a well-
grounded understanding of how object-oriented
paradigms are treated in ABAP Objects.
7
This will
definitely speed up your development cycles.
The Web Dynpro component
and its parts
AWeb Dynpro component is the heart of a Web
Dynpro application. It is the basis of your application
development and for the reuse of the component itself.
Acomponent can be seen as a modular unit repre-
senting a set of tasks. Components can be embedded
within other components. Acomponent cannot be
executed on its own. To run a component, it must be
assigned to an application. In the Web Dynpro context,
the application is a technical entity that defines:
• The component, which is the entry point to the
application
• An interface view of the entry component, which
displays during startup
• The navigation plug of the interface view, which
is called during startup
Figure 1 shows the parts that comprise and
support a Web Dynpro component.
• Component interface: You can assign certain
parts of a component to the interface of the
component. The component interface provides the
user or other components access to the inner work-
ings of a component. However, you can define
interfaces that are independent of a component.
Such an interface is called a Web Dynpro compo-
nent interface definition. You define an interface
in case different components need to implement
a common interface, or the development of a
component and the development of the use of a
component need to be separated. The interface
contains a visual part (interface view) and a
programmatic part (controller and context).
• Component usage: By defining a component
usage, you can embed other components into a
component. In that way you will be able to use
and access the functionality developed in the used
component. Consider this example: Assume that
you have to create a component to register users of
a Web site. The user data, which is to be collected,
comprises the name and the address. You know
that a colleague has already developed a generic
component for maintaining address data. You can
now reuse the component by defining a usage in
the component for registering users and access the
functionality for maintaining the address data
without further development effort.
• Controller: Controllers handle data flow and
binding. Every view belongs to a dedicated view
Figure 1 Parts of a Web Dynpro component
6
For more information on the BPS application development, see the
following SAP Professional Journal articles: "Developing Custom
Applications for SAP Enterprise Portal — Starting with the 'Right'
Options in Light of SAP NetWeaver" by Patrick Dixon (March/April
2005) and "Develop More Extensible and Maintainable Web
Applications with the Model-View-Controller (MVC) Design Pattern"
by Ken Huang and Markus Wieser (January/February 2004).
7
For information on ABAP Objects, see the SAP Professional Journal
article "Not Yet Using ABAP Objects? Eight Reasons Why Every
ABAP Developer Should Give It a Second Look" (September/October
2004) by Horst Keller and Gerd Kluger.
Get started developing Web-native custom SAP applications with Web Dynpro for ABAP
No portion of this publication may be reproduced without written consent. 7
controller, every window belongs to a window
controller, and the heart of every component is
the component controller. You can add custom
controllers for further structuring of tasks and data
(for example, for separating header and item data
in a sales order application). A view controller
performs event handling based on the actions
invoked in the view. Besides event handling
(which is implemented in event handler methods),
controllers may perform other activity imple-
mented in hook methods, such as WDDOINIT
or WDDOMODIFYVIEW.
• View: A view is the visible area of the UI. The
view contains controls, known as view elements.
Actions are properties of view elements used to
trigger events for designated user input (i.e.,
selecting a link or pressing a button). An event is
always connected to a handler method, where the
user input is processed. You can add navigation
plugs to a view for navigating between views.
Note!
SAP proposes defining only a maximum
number of 15 views per component. Exceeding
this number will lead to a noticeable
performance reduction of your application.
• Window: You can arrange views in complex
screen layouts using windows. The window also
defines navigation links between navigation plugs.
Looking at a component from the outside, the term
interface view is used instead of the term window.
• Context: All data processing in a Web Dynpro
application is done via contexts. Each controller
has a context, which represents a hierarchical
structured data container, in which you can enter
nodes and attributes. The attributes represent your
data elements; the nodes are used to group attrib-
utes and other lower-level nodes. Typically, a view
controller’s context keeps the data to be presented
in the view elements (e.g., input fields, tables, etc.)
of the view, and a binding exists between the view
element properties and the context elements. A
component controller’s context keeps the data
required in the component and shared among
multiple views and windows of that component.
Context elements can be mapped across context.
Through context mapping the framework ensures
that the data is available in all mapping contexts
at runtime.
• View element: View elements are the smallest
parts of a view. In most of the cases, they can
describe a graphical, visible area in the client
(e.g., buttons, input fields, check boxes, etc.).
However, in certain cases they can also describe
a piece of functionality that is added to the view
and executed in the client. An example is the
TimedTrigger view element, which adds a piece
of code to the view (in the case of a Web browser
client, these are JavaScript functions) that causes
the client to send periodic requests to the server.
The appearance and functionality of all view
elements are described by their properties.
Examples of view element properties are height,
width, design, and so on.
Web Dynpro Explorer toolset
Your starting point for developing Web Dynpro appli-
cations is the ABAP Workbench (transaction SE80).
The Web Dynpro Explorer, which contains the toolset
for editing the different parts of a component, is inte-
grated into the ABAP Workbench, which means you
don’t need to memorize another transaction code. Just
Note!
SAP proposes defining only a maximum
number of eight usages per component.
Exceeding this number will lead to a noticeable
performance reduction of your application.
select the entry Web Dynpro Comp./Intf., and you can
start working with the Web Dynpro Explorer either by
creating a new component or interface or displaying
an existing one. Let’s look at each of the tools in the
toolset:
• Component Editor
• Controller Editor
• View Editor
• Window Editor
• Web Dynpro Code Wizard
Component Editor
After you select the component you want to work on
from the object list in the Web Dynpro Explorer, the
Component Editor is displayed, as shown in Figure 2.
The Component Editor provides an overview of the
parts of which your component consists. The initial
framework creates a component controller, a compo-
nent interface, and a window to which you add all
the other parts, such as views, usages, and custom
controller. As you can see, the selected component
(i.e., Z_WDC_SAPPJ_SIMPLE) consists of a compo-
nent controller, a component interface including the
SAP Professional Journal • July/August 2007
8 www.SAPpro.com ©2007 SAP Professional Journal. All rights reserved.
interface view W_DISPLAY_UNAME, the view
V_DISPLAY_UNAME, and the window
W_DISPLAY_UNAME.
Note!
Every window added to a component is
automatically added to the interface controller
of that component (that’s why W_DISPLAY_
UNAME appears twice: once under Interface
Views and again under Windows). When you
talk about the interface controller of a compo-
nent, the window is then referred to as an
interface view.
To add a new part to the component, you right-
click on the component name in the Component Editor
and then select the part you want to add from the
context menu. If you create a new component, the
component name is entered in the input field of the
object list. After you press the Enter key, the frame-
work leads you through the creation process by asking
you to assign a package and a transport request to
the object.
As you can see, the Component Editor also lists
the Web Dynpro applications to which the component
is assigned. In the example, the entry point is the
application Z_WDA_SAPPJ_SIMPLE, which defines
component Z_WDC_SAPPJ_SIMPLE.
Note!
Multiple applications can use the same
component as an entry point. The component
will behave differently because of the different
interface views and start plugs defined in each
application.
Figure 2 Component Editor
Get started developing Web-native custom SAP applications with Web Dynpro for ABAP
No portion of this publication may be reproduced without written consent. 9
Controller Editor
You program the behavior of a component in its
controllers. There you can create the context, define
attributes, and implement methods. The component
controller allows you to provide the component’s
interface to other components via methods, events,
and context nodes to be specifically identified. The
methods, events, and context nodes of this interface
then make up the interface controller. The interface
controller itself cannot be changed separately; you
must make modifications to the interface via the
component controller. The interface controller is
editable only in cases where you create a Web
Dynpro component interface definition.
There are component-global controllers, such as
the component controller, custom controller, and
interface controller. You can access these controllers
by selecting its respective name in the Component
Editor. You create and maintain the individual parts
of all component-global controllers in this area of
the Web Dynpro Explorer. In Figure 3 the compo-
nent controller is selected in the Component Editor
and its parts are shown in the right pane of the
window.
In every controller, you can implement several
different types of methods. You can use hook
methods to interfere in the program flow at
certain times. Names of hook methods start with
“WDDO”; examples are WDDOINIT() and
WDDOMODIFYVIEW(). In their initial state, these
methods do not contain statements. Furthermore,
in all controllers, you can implement additional
methods that manage your data and control logic.
These methods are the instance methods of a compo-
nent, called using the self-reference WD_THIS
−>[method_name]. Event handler methods are imple-
mented to respond to events of controllers, to events
of navigation plugs, and to actions that are received
from the client. If you want to create an event handler
method, which registers an event that can be triggered
within another controller, you can assign its name on
the Methods tab of the controller. Then you can select
the event handler method type and the event to which
to react. You use supply function methods to populate
the context attributes of the context node elements. If
it exists, the supply function method is always called
before the initial read access to that context node.
Supply function methods are assigned to context
nodes by binding the Supply Function property to the
respective method.
Views and windows also have controllers. To
access these controllers, you can switch to the View
Editor or Window Editor by selecting the name of the
Figure 3 Accessing the Controller Editor of the component controller
SAP Professional Journal • July/August 2007
10 www.SAPpro.com ©2007 SAP Professional Journal. All rights reserved.
respective view or window from the Component
Editor’s list.
Note!
You can access the data and functionality of
the component-global controllers from every-
where in the component; whereas, the data of
the lower-level controllers of the views and
windows is only visible in the respective view
or window.
View Editor
The View Editor consists of a graphical layout editor,
called the view designer, and a view controller. You
access the View Editor from the Component Editor by
selecting the name of the particular view. You open
the view designer by selecting the Layout tab in the
View Editor. Figure 4 shows the View Editor of the
view V_DISPLAY_UNAME. Under the Layout tab,
you can see a number of view elements arranged by
the view designer in a tree-like structure.
You use the view designer to define the visual
appearance of the UI by adding and arranging
view elements to the layout. You access the view
elements from the Layout tab of the View Editor.
The view designer is divided into two parts: a tree
representation of the view starting at a root node
(the ROOTUIELEMENTCONTAINER) and a
WYSIWYG tool. The WYSIWYG tool renders
immediately the view elements that you have added
to the layout. You can turn this tool on and off using
the Show/Hide Layout Preview button.
Finally, you use the view controller to implement the
logic of the view. In a view controller, you can define
the context, methods, actions, and navigation plugs.
Window Editor
The Window Editor consists of a graphical part, the
navigation modeler, and a window controller.
You access the Window Editor from the
Component Editor by selecting the name of the
particular window. You open the navigation modeler
Figure 4 Accessing the view designer as part of the View Editor
Get started developing Web-native custom SAP applications with Web Dynpro for ABAP
No portion of this publication may be reproduced without written consent. 11
by selecting the Window tab of the Window Editor.
Figure 5 shows the Window Editor of the window
W_DISPLAY_UNAME. Under the Window tab, you
can see the embedded views including their inbound
and outbound plugs.
You can link all views of the component with each
other by defining navigation links between the plugs.
The linkage specifies the navigation path between the
views at runtime. You can also create inbound and
outbound plugs for a particular window. These plugs
are used to manage component behavior when the
component is either called from the application or
other components or when the component is left.
Web Dynpro Code Wizard
The Web Dynpro Code Wizard helps to derive ABAP
statements when you edit controller methods and auto-
mates the layout design when you are creating form
containers or tables. You can launch the wizard from
every controller editor by clicking on the Web Dynpro
Code Wizard button on the Web Dynpro Explorer
toolbar, as shown in Figure 6 (or by pressing the short
key Ctrl+F7).
The wizard provides a list of functions that depend
on the location from which you call it. The wizard
offers support in the following cases:
Figure 6 Accessing the Web Dynpro Code Wizard
Figure 5 Accessing the navigation modeler as part of the Window Editor
SAP Professional Journal • July/August 2007
12 www.SAPpro.com ©2007 SAP Professional Journal. All rights reserved.
• Calling a method in the controller
• Calling a method in a used controller
• Creating a used component
• Read access to a context node
• Adding messages to the message manager
• Accessing the portal manager
• Triggering navigation by calling an outbound plug
• Triggering events
• Creating tables in the view designer
• Creating forms in the view designer
Steps to building a simple
Web Dynpro application
Web Dynpro development involves a variety of tools
for creating and editing all necessary parts. The
following is a simple application that shows in what
order you need to create the various parts and what
tools you need to use. The purpose of this applica-
tion is to output the SAP user name to the browser
window. Using what you’ve learned about the parts of
a Web Dynpro application and the development tools
provided by the Web Dynpro Explorer, let’s build a
simple application that welcomes the user at startup.
1. Use transaction SE80 to enter the ABAP
Workbench, and then select Web Dynpro
Comp./Intf. from the object list to start Web
Dynpro Explorer.
2. Enter a name for the Web Dynpro component you
are creating (e.g., Z_WDC_SAPPJ_SIMPLE), as
shown in Figure 7. See the sidebar on the next
page for naming recommendations.
Figure 7 Creating a new component
Figure 8 Specifying the component description and window name
Replace the default window
name with a new name
3. Press the Enter button, and when asked whether
you want to create a new object, confirm the query.
4. After you confirm the query, the dialog in Figure 8
appears. Here you can enter a short description
of the component, and specify whether you are
creating a Web Dynpro component (already
selected) or a Web Dynpro component interface.
Also in this dialog, you assign a name for the
window. The framework defaults the component
name as the window name, but to avoid any con-
fusion that might be caused by having the same
names, enter a different name for the window (e.g.,
W_DISPLAY_UNAME), and then click on .
Get started developing Web-native custom SAP applications with Web Dynpro for ABAP
No portion of this publication may be reproduced without written consent. 13
Note!
The sample applications described in this
article were developed on an SAP NetWeaver
Application Server (AS) ABAP 7.00 SP10,
which is included in SAP NetWeaver 2004s
and SAP ERP 2005. In case you have access to
the follow-up release, which is SAP NetWeaver
AS ABAP 7.10, included in SAP NetWeaver
2007, the screen shown in Figure 8 might also
include a field for entering the name of a view.
5. Enter a package name and assign a transport task.
These queries are standard ABAP behavior and
don’t differ from any other scenario involving
the creation of any ABAP object.
6. Web Dynpro Explorer now displays the
component, including the component controller,
the interface controller, and the window. Right-
click the component name and select Create →
View from the context menu, as shown in
Figure 9, and then enter the view name, e.g.,
V_DISPLAY_UNAME.
The framework opens the View Editor and defaults
Naming Web Dynpro parts
Use these recommendations for naming your Web Dynpro parts to avoid confusion and make your
architecture better to be understood by others:
• Use the literal “_WDC_” in the Web Dynpro component name (e.g., Z_WDC_SAPPJ_SIMPLE)
• Use the literal “_WDA_” in the Web Dynpro application name (e.g., Z_WDA_SAPPJ_SIMPLE)
• Prefix view names with “V” (e.g., V_DISPLAY_UNAME)
• Prefix window names with “W” (e.g., W_DISPLAY_UNAME)
Figure 9 Creating a view
SAP Professional Journal • July/August 2007
14 www.SAPpro.com ©2007 SAP Professional Journal. All rights reserved.
to the tab for editing the view layout. Our example
application will output a greeting to the user using
the SAP user name; therefore, we need to add two
TextView view elements to the layout: one for the
greeting text and the other for the user name.
7. Right-click on the ROOTUIELEMENTCON-
TAINER entry of the layout, enter the name
of the element you want to create (e.g., TXV_
GREETING), and then select the type of element
(e.g., TextView), as shown in Figure 10. All subse-
quent UI elements added to a view layout will be
hierarchically subordinate to the UI element called
ROOTUIELEMENTCONTAINER. The root node is
always of type TransparentContainer and is always
called ROOTUIELEMENTCONTAINER. You
cannot change this — it is hard coded!
8. Create the second TextView type element, and
name it TXV_UNAME. The resulting layout
structure is shown in Figure 11.
9. The TXV_GREETING TextView view element
will write the text “Welcome” to the browser
screen. To assign the static text string to the
property text, select TXV_GREETING in
the view layout, and then edit its properties in
the lower portion of the screen, as shown in
Figure 12.
Note!
All text literals assigned to properties of view
elements (e.g., caption, labels, button texts, etc.)
become part of the translation process and are
automatically entered into a translator’s work
list (transaction SE63).
Figure 10 Adding view elements to a view
Figure 11 View layout containing two TextView view elements
this scenario we will use the functionality of a
supply function method. Enter the name of the
supply function method (e.g., supply_greeting) into
10. Next to the Welcome text, we want to display the
SAP user name. The user name is determined by
calling an application programming interface (API)
and is written into a context attribute. First, we
need to create a context node that will contain the
attribute. In the View Editor, switch from the
Layout tab to the Context tab. Right-click the node
CONTEXT and select Create →Node. The Create
Nodes screen is displayed.
11. Enter the name for the context node (e.g.,
GREETING). Leave all the other settings
proposed by the framework (see Figure 13).
12. The context node will contain one attribute, which
will hold the user’s name and to which the prop-
erty text of the TXV_UNAME TextView view
element will be bound. To create the attribute,
right-click on the context node, and then select
Create →Attribute, as shown in Figure 14 on
the next page.
13. Assign the name UNAME to the attribute, and set
the type to STRING.
14. Now we will implement reading the SAP user
name and writing it to the context attribute. For
Get started developing Web-native custom SAP applications with Web Dynpro for ABAP
No portion of this publication may be reproduced without written consent. 15
Figure 12 Editing view element properties
Figure 13 Creating a context node
Note!
A characteristic of the context node is its
cardinality. There are four possible settings:
• 1..1 — At the time of context initialization,
exactly one element is created that is main-
tained at runtime.
• 0..1 — At runtime, a maximum of one con-
text element can be used.
• 1..n — At the time of context initialization,
one or more elements can be created, but at
least one element must exist at runtime.
• 0..n — At runtime, any number of context
elements can be used.
SAP Professional Journal • July/August 2007
16 www.SAPpro.com ©2007 SAP Professional Journal. All rights reserved.
the Supply Function property field of the context
node GREETING, as shown in Figure 15.
15. Double-click on the name of the Supply Function
value (i.e., supply_greeting) to navigate to the
method editor. To implement the steps for reading
the SAP user name from the API and assigning it
to the context attribute, add the code shown in
Figure 16 to the supply function method.
16. To display the value of attribute UNAME, we need
to bind the property text of the TextView view
element TXV_UNAME to the context attribute.
Select the view element in the layout of the View
Editor, and then select the button in the Binding
column on the right side of the property table of
the View Editor, as shown in Figure 17.
17. In the next screen, which displays all available
context nodes and attributes, select the attribute
UNAME, and confirm the selection by clicking on
. The attribute is then assigned to the property
text. The binding of a property to a context is
indicated by an icon in the Binding column.
Figure 15 Creating a supply function method
Note!
Depending on the value of the property cardi-
nality of the context node, you have different
options for writing data to the context:
• Methods bind_element(), bind_structure(),
set_attribute(), and set_static_attributes()
are used to bind data to context nodes of
cardinality 0..1 or 1..1.
• Methods bind_elements() and bind_table()
are used to bind data to context nodes of
cardinality 0..n or 1..n.
Figure 14 Adding attributes to a context node
Right-click on the component name and select
Activate, or click on the Activate button on the
Web Dynpro Explorer toolbar.
20. Now that we have added all our components,
views, and attributes, we create the Web Dynpro
application. Right-click on the component name,
and select Create →Web Dynpro Application
from the context menu. Enter an application name,
e.g. Z_WDA_DISPLAY_UNAME. Add a short
description to explain the use of the application.
To identify the component entry point for the
application, we need to define the window or inter-
face view and an inbound plug. Because we have
only one window and only one default inbound
plug added by the framework when the window
was created, the framework provides their names,
which, in this case, we’ll leave. Don’t forget to
save your application.
Get started developing Web-native custom SAP applications with Web Dynpro for ABAP
No portion of this publication may be reproduced without written consent. 17
18. Next we need to embed the view into the window.
For this purpose, switch to the Window Editor by
double-clicking the window W_DISPLAY_
UNAME on the left side of the Web Dynpro
Explorer. The Window Editor is displayed and
opens the navigation modeler, which is located
under the Window tab. Right-click on the window
name, and then select Embed View from the
context menu, as shown in Figure 18. The system
proposes all views available to the component.
The view that we need to display the user name is
V_DISPLAY_UNAME. After we’ve selected the
view, the system adds it to the window structure.
19. It’s time to save and activate the component.
DATA l s_gr eet i ng TYPE i f _v_di spl ay_uname=>el ement _gr eet i ng.
DATA l s_user _dat a TYPE usr 03.
*- - - - Get user det ai l s CALL FUNCTI ON ' SUSR_SHOW_USER_DETAI LS'
EXPORTI NG
bname = syst - uname
no_di spl ay = ' X'
CHANGI NG
user _usr 03 = l s_user _dat a.
*- - - - - Cr eat e user name
CONCATENATE l s_user _dat a- name1 l s_user _dat a- name2 ' ! '
I NTO l s_gr eet i ng- uname SEPARATED BY space.
*- - - - - Bi nd t o cont ext
node- >bi nd_st r uct ur e( new_i t em= l s_gr eet i ng ) .
Figure 16 Code for implementing a supply function method
Figure 17 Binding a view element property to a
context node attribute
Figure 18 Embedding a view into a window
SAP Professional Journal • July/August 2007
18 www.SAPpro.com ©2007 SAP Professional Journal. All rights reserved.
Note!
AWeb Dynpro application consists of one or
more Web Dynpro components. The Web
Dynpro application defines only the entry point
of the starting component and provides the
URL. All programming logic is implemented in
components.
You can start the Web Dynpro application by
pressing F8. In the browser window, you should see
your name displayed because it is maintained in the
SAP system you’ve been working on.
Note!
Web Dynpro applications are able to run on the
following client platforms:
• JavaScript-enabled Web browsers (MS IE
5.5 and higher, Mozilla 1.7 and higher)
• Web Dynpro client for Windows (included
in SAP NetWeaver Business Client —
NWBC version 1.0)
That concludes our exercise of building a simple
Web Dynpro application, but we aren’t done yet.
Let’s take what you’ve learned and apply it to a
“real-world” purchase order application.
Web Dynpro component to
display purchase order data
Now that you are familiar with the basics of Web
Dynpro development, let’s take a step further into
implementing a component to retrieve and display
purchase order data. The difference between this Web
Dynpro application and the first one we created is that
we will now implement a more common UI scenario
involving header and item data of business objects. To
help illustrate the purpose of the development steps
that follow, let’s first look at the result of the develop-
ment effort, as shown in Figure 19.
The purchase order output is displayed in the Web
browser. The screen is divided into three sections:
Purchase Order Header, Purchase Order – Item
Overview, and Purchase Order – Item Detail. When
creating the layout, you will include each of these
three sections in a Group view element.
The Purchase Order Header section displays a
number of properties, e.g., the purchasing document
number 4500000008, the company code AR01, etc.
The Purchase Order is divided into two areas. The
Item Overview displays the items purchased in a table
format — where, in this example, the item with
number 00010 is selected in the table. For each
selected item, the item detailed data is shown in the
Item Detail section. Switching between items in the
table will automatically update the detailed data of the
selected item.
The application is started in display mode; there-
fore, all input fields are read-only (that is, you can’t
enter data; the fields are inactive). The icons at the
end of some of the input fields indicate that an input
help is available. Clicking on the icon displays a pop-
up with information regarding the data presented in
the input field (e.g., a description to the purchase
order number).
The purchase order data is retrieved by calling
the function module BAPI_PO_GETDETAIL, which
uses the purchase order number as importing param-
eter. The function module returns the purchase order
header data in a structure and the item list in an
internal table format. In this example, we’ll run the
application in display mode only. Then we will extend
the implementation of the purchase order component
by adding the functionality to switch to edit mode to
modify existing item data and add new items to the
purchase order.
Whenever you develop a component, keep its reuse
in mind. In this example, since the component will
display the item detail data of a particular purchase
order, it should be possible to integrate the component
Get started developing Web-native custom SAP applications with Web Dynpro for ABAP
No portion of this publication may be reproduced without written consent. 19
into applications in which it can be called with any
purchase order number. Examples of applications in
which you might use the component are:
• An application in which purchase orders are
created manually by users, similar to the classic
Dynpro transactions ME21, ME22, ME23.
• An application in which purchase requisitions are
created by users, and after approval purchase
orders are created automatically by the system,
similar to scenarios common in SAP SRM. You
can review and modify the automatically created
purchase orders and their items using the compo-
nent developed in this article.
To call the component from other components
or applications and refer to a certain purchase order,
you have to implement the purchase order number as
the importing parameter to the component. The Web
Dynpro application provides this parameter through a
URL parameter, which we will name PO_NUMBER.
We’ll name the parameter that controls the mode in
which the data is presented to the user (that is,
whether the user is able to modify the data) —
DETAIL_MODE. Considering these definitions, the
caller of the application needs to provide the purchase
order number and the mode parameters. So in our
example, the mode needs to be set to DISPLAY.
Note!
The prefixes “sap-” and “sap-wd-” are reserved
for SAP and should not be used in URL
parameter names.
Before adding the purchase order specific function-
ality, you need to complete steps 1 through 6 to create
the new component for the purchase order example.
1. Create component Z_WDC_SAPPJ_PO with
window W_DEFAULT.
Figure 19 Web Dynpro application for displaying purchase order data
SAP Professional Journal • July/August 2007
20 www.SAPpro.com ©2007 SAP Professional Journal. All rights reserved.
2. Create a view with the name V_DEFAULT.
3. Switch to the Window Editor and embed the view
V_DEFAULT.
4. Activate the component.
5. Create an application with name
Z_WDA_SAPPJ_PO, using component
Z_WDC_SAPPJ_PO, interface view
W_DEFAULT, and plug DEFAULT.
6. Save the application.
With the Z_WDC_SAPPJ_PO component
created, we can begin to add new functionality to it.
The context data for the purchase order header
data and item data is accessed from the window
controller and from the view controller. For that
reason, it makes sense to keep the data globally avail-
able in the component controller. We will create three
context nodes in the component controller, and create
copies and mappings of these context nodes in the
window controller and in the view controller. We will
name the first node PO_HEADER and assign the
data type BAPIEKKOL. Note that the property cardi-
nality of the context node is set to 1..1 because we
will only display a flat field structure. See Figure 20.
Not all fields of structure BAPIEKKOL are of
interest to us. We will select a few important fields
and add them as attributes of the context node
PO_HEADER: PO_NUMBER, CO_CODE,
DOC_CAT, DOC_TYPE, STATUS, CREATED_ON,
CREATED_BY, VENDOR, and CURRENCY —
some of which are shown in Figure 21.
Next, we need to create the second context node
for the item overview and item detailed data with the
name PO_ITEMS and set it to type BAPIEKPO.
From the BAPIEKPO structure, select the fields
PO_ITEM, STATUS, SHORT_TEXT, MATERIAL,
QUANTITY, UNIT, NET_PRICE, CUSTOMER,
PRICE_UNIT, PLANT, MAT_GRP, NET_VALUE,
and GROS_VALUE, and set them as attributes of
the context node. Because the item data consists of
multiple elements that are displayed in a table, we
need to set the property cardinality to the value 0..n.
This means that during runtime the context node
may contain zero or more elements.
In a third context node, we’ll keep the informa-
tion that is used to control the setting of properties
of the view elements depending on the user mode.
There will be just one attribute called READ_
ONLY, which is set to X when the application is
started with the URL parameter DETAIL_MODE
set to DISPLAY. This causes all input fields on
the screen to be inactive (or in other words, they
can’t be edited). We’ll name this context node
USER_MODE. Because the node contains an
attribute to control only a view element property,
we don’t need a Digital Display Indicator Control
(DDIC) type defined here. Set the property cardi-
nality to 1..1, and set the attribute READ_ONLY
to type WDY_BOOLEAN.
Now, switch to the view controller context, and
copy the component controller context nodes, and
map the view controller context to them. You can
do this by simply dragging and dropping the nodes
from the right pane, which shows the component
controller context, to the left pane’s root node with
the name CONTEXT. See Figure 22.
After mapping the view controller context
nodes to the component controller context, we’ll
proceed by following the same steps in the window
controller. Switch to the Window Editor, select the
Context tab, copy the component controller context
into the window controller, and then map the
window controller context to the component
controller context.
Figure 20 Setting the cardinality to 1..1
Get started developing Web-native custom SAP applications with Web Dynpro for ABAP
No portion of this publication may be reproduced without written consent. 21
Note!
The modifications to a context node to which
other nodes are mapped are not automatically
copied to the mapping nodes. You need to carry
out an update for mapping each context node
manually; otherwise, the modifications are not
available in the mapping context node.
The first method, which is called when the appli-
cation is started, is the event handler method of the
inbound plug of the window, which is flagged as
DEFAULT. In our example, the name of this method
is HANDLEDEFAULT(). In this method, the parame-
ters, which are passed by the application, are read, and
the data of the given purchase order number is
retained by calling the function module BAPI_
PO_GETDETAIL. Then the context nodes are filled.
The implementation of the event handler method is
shown in Figure 23 on the next page.
To specify the parameters used in the URL, add
the parameters PO_NUMBER and DETAIL_MODE
to the parameter definition of method HANDLEDE-
FAULT(). They will be defined as importing
parameters of type STRING, as shown in Figure 24
on the next page.
Next, we’ll create the layout of the view, which
consists of three areas that display the purchase order:
header data, item overview, and item detail data.
These three areas are defined in the layout using
the Group view element. Add these view elements
to the layout, and then assign the following IDs:
Figure 22 Copy and map context nodes
Figure 21 Selecting and adding attributes to a context node
Drag and drop to copy and
map the component controller
node to the view controller
SAP Professional Journal • July/August 2007
22 www.SAPpro.com ©2007 SAP Professional Journal. All rights reserved.
GRP_POHEADER, GRP_ITEM_OVERVIEW, and
GRP_ITEM_DETAIL. The layout of your view
should look like the one shown in Figure 25.
Next, we’ll add the fields to display the purchase
order header data. There are nine fields with their
labels shown in the browser. We could add these view
METHOD handl edef aul t .
DATA l v_po_number TYPE ebel n.
DATA l s_bapi ekkol TYPE bapi ekkol .
DATA l t _bapi ekpo TYPE STANDARD TABLE OF bapi ekpo.
DATA l r _node TYPE REF TO i f _wd_cont ext _node.
DATA l s_po_header TYPE i f _w_def aul t =>el ement _po_header .
DATA l t _po_i t ems TYPE i f _w_def aul t =>el ement s_po_i t ems.
DATA l s_po_i t em TYPE i f _w_def aul t =>el ement _po_i t ems.
DATA l s_user _mode TYPE i f _w_def aul t =>el ement _user _mode.
FI ELD- SYMBOLS <f s_bapi ekpo> TYPE bapi ekpo.
*- - - Read PO number and get PO det ai l dat a
l v_po_number = po_number .
CALL FUNCTI ON ' BAPI _PO_GETDETAI L'
EXPORTI NG
pur chaseor der = l v_po_number
I MPORTI NG
po_header = l s_bapi ekkol
TABLES
po_i t ems = l t _bapi ekpo.
*- - - Fi l l PO header cont ext node
l r _node = wd_cont ext - >get _chi l d_node( ' PO_HEADER' ) .
MOVE- CORRESPONDI NG l s_bapi ekkol TO l s_po_header .
l r _node- >bi nd_st r uct ur e( new_i t em= l s_po_header ) .
*- - - Fi l l PO i t emcont ext node
LOOP AT l t _bapi ekpo ASSI GNI NG <f s_bapi ekpo>.
MOVE- CORRESPONDI NG <f s_bapi ekpo> TO l s_po_i t em.
APPEND l s_po_i t emTO l t _po_i t ems.
ENDLOOP.
l r _node = wd_cont ext - >get _chi l d_node( ' PO_I TEMS' ) .
l r _node- >bi nd_t abl e( new_i t ems = l t _po_i t ems ) .
*- - - Set oper at i onal mode
l r _node = wd_cont ext - >get _chi l d_node( ' USER_MODE' ) .
I F det ai l _mode EQ ' DI SPLAY' .
l s_user _mode- r eadonl y = abap_t r ue.
ELSEI F det ai l _mode EQ ' CREATE' .
l s_user _mode- r eadonl y = abap_f al se.
ENDI F.
l r _node- >bi nd_st r uct ur e( new_i t em= l s_user _mode ) .
ENDMETHOD.
Figure 23 Code for implementing the method HANDLEDEFAULT()
Get started developing Web-native custom SAP applications with Web Dynpro for ABAP
No portion of this publication may be reproduced without written consent. 23
elements manually step by step; however, the Web
Dynpro framework provides a much easier way to do
this based on the Web Dynpro Code Wizard. Right-
click on the group GRP_POHEADER, and then select
Create Container Form from the context menu, as
shown in Figure 26.
In the next screen, you:
1. Select which context node contains the fields to be
used on the form
2. Set a default field type (cell editor) to be used for
all fields
3. Overwrite the default field type for each context
attribute
4. Deselect the Bind column check box so the field
does not appear on the screen
5. Select the Bind column check box, and assign a
property in the next column you can define to
which attribute the particular view element prop-
erty is bound (for an InputField view element, the
property value is used)
To display the purchase order data, we’ll use input
fields only. Why this? When checking the data types of
the context node attributes, we can see that all of them
have a length greater than one and represent a string, a
character set, or a number. Other view elements that
are suitable for a form are check boxes, radio buttons,
and so on. However, the context node doesn’t contain
any attributes of type XFLAG or ABAP_BOOL
(internal ABAP Boolean type). All of the nine attrib-
utes of the context node will be displayed on the
screen. That’s why the property values of all of the
InputField view elements are bound to the context
attributes (see Figure 27 on the next page).
After you confirm your input, the Web Dynpro
Code Wizard displays the next screen and adds for
each attribute a Label view element and an InputField
view element to the layout without any interaction
with the user. This is especially time-saving if you
need to create input forms with many fields. In our
case, the wizard adds nine (one for each attribute)
Label view elements and InputField view elements to
Figure 24 Importing parameters of the method HANDLEDEFAULT()
Figure 25 The layout containing three Group view
elements
Figure 26 Creating a form using the Web Dynpro
Code Wizard
SAP Professional Journal • July/August 2007
24 www.SAPpro.com ©2007 SAP Professional Journal. All rights reserved.
the layout of the view in seconds. Because the input
fields are bound to context attributes that have a
DDIC type assigned, the label texts are also automati-
cally pulled from the DDIC definition of the particular
data element. In case the text is not suitable, you can
overwrite these descriptions by manually editing the
property text of the Label view element.
In the next step, we’ll edit the second part of the
layout (i.e., the area in which the item overview table
of the purchase order is displayed). This area is
contained in the Group view element GRP_ITEM_
OVERVIEW. Our focus here is to add a Table view
element and the columns of the table. Right-click on
the GRP_ITEM_OVERVIEWelement, and from the
list of available view elements, select the Table view
element. Assign an ID to the Table view element (e.g.,
TBL_ITEM_OVERVIEW). As shown in Figure 19,
the Item Overview has nine columns. Adding columns
to the table is also supported by the Web Dynpro
Code Wizard. To start the wizard, select the ID of the
Table view element, and then select Create Binding
from the context menu (see Figure 28).
The screen in which you can define the columns of
a table looks similar to the one for defining the form
container (Figure 27). We first have to select the
context node that contains the attributes representing
the columns of the table. In our case, we select the
context node PO_ITEMS. In the next step, we can
either select a standard cell editor type that is used for
all of the table columns in the Standard Cell Editor
field, or define the cell editor individually for each
column in the table shown below the Standard Cell
Editor field. See Figure 29.
The Standard Cell Editor field is set to InputField;
however, since we don’t want to edit the values shown
in the item overview, we’ll use the TextView view
Figure 27 Creating a container form from context attributes
Figure 28 Calling the Web Dynpro Code Wizard to
add columns to a table
Get started developing Web-native custom SAP applications with Web Dynpro for ABAP
No portion of this publication may be reproduced without written consent. 25
element as the cell editor. Only the data that offers the
user enough information regarding a particular item
will be shown in the table. In case the user wants to
get more detailed data of a purchase order item, the
user can select the item from the list and all available
fields are displayed in the item detailed area. In our
example, the columns of the table will be created for
the attributes PO_ITEM, STATUS, SHORT_TEXT,
MATERIAL, QUANTITY, UNIT, NET_PRICE, and
CUSTOMER only, because we selected the check box
in the Bind column. Attributes such as PRICE_UNIT,
PLANT, and MAT_GRP will not appear in the table,
but they will be displayed in the item detailed area,
configuration of which is described later.
The property of the TextView element, which
needs to be bound to the context node attributes to
transport their value, is text. Select this property in the
last column of the wizard popup. After confirming all
of the entries were made, the Web Dynpro Code
Wizard starts running and adds for each attribute
selected in the Bind column a TableColumn view
element in the table layout, as shown in Figure 30.
Until now, we have defined the output areas of the
purchase order header and the item overview table.
What is left is the part considered for the item detailed
data. Looking at the screen displayed in Figure 19,
you can see that the way the fields are arranged and
displayed in the item detailed area looks similar to the
purchase order header. So defining the layout for the
item detailed data is done in a similar way compared
to the purchase order header. To start, right-click the
Group view element with the ID GRP_ITEM_
DETAIL, and then select Create Container Form from
the context menu. Follow the steps that we used to
create the purchase order header data. When it comes
to selecting the attributes that will represent the fields
on the screen, select all attributes of context node
PO_ITEMS. After you have created the container
form, save your work and activate the component.
Figure 29 Creating table columns from a context node
Figure 30 Columns added to the Table view element
SAP Professional Journal • July/August 2007
26 www.SAPpro.com ©2007 SAP Professional Journal. All rights reserved.
You usually start a Web Dynpro application by
selecting the application name in the Component
Editor and pressing F8. However, in our example, we
need to add the URL parameter PO_NUMBER and
DETAIL_MODE and their values to the URL gener-
ated by the framework. Without these parameters, the
framework will not be able to identify a purchase
order. Add the parameters to the URL by copying the
framework-generated URL from the application’s
Property tab to the address field of your Web browser.
Next, identify a valid purchase order in your SAP
ERP system, and add it as a value of the URL param-
eter PO_NUMBER. Make sure the value of URL
8
parameter DETAIL_MODE is DISPLAY.
Consider that depending on which system you
work, the values for the domain name, the port
number, and the client might be different. The resulted
output of the application is shown in Figure 19.
Conclusion
This article introduced you to the fundamentals of
Web Dynpro for ABAP programming. It hopefully has
increased your curiosity to dig deeper into the
concepts and functionality to develop feature-rich
applications that not only run in a Web environment
but can also be integrated into SAP’s NetWeaver
Business Client.
Although the focus of this article is on the devel-
opment and integration of just one component, I
hope you realize that the strength of the Web Dynpro
framework lies in the ability to componentize your
application, i.e., to develop self-contained logical
units components that can be reused instead of
implementing one and the same functionalities
multiple times.
I have not covered the implementation of such
usages of components (which might become the
topic of a future article). However, you should
consider componentization in an early stage of your
development process and also use the SAP-delivered
components to provide comprehensive functionality
to your customers by enriching your application.
Some examples of components that are part of the
SAP NetWeaver 2004s release and its follow-up
Service Packages are:
• SALV_WD_TABLE: This component provides
common list operations to tabular structures of
data. It implements similar functionality that is
offered by the classic Dynpro ALV.
• POWL_UI_COMP: This component provides
functionality to create user-definable work lists.
The user can define and optionally store queries
in a similar way these tasks are done from classic
Dynpro selection screen variants.
• WDR_OVS: In addition to the simple input helps
in which the search screen consists of fields for
restricting the search and the search result list
only, the object value selector (OVS) component
WDR_OVS provides the option of implementing
extended search functionalities. WDR_OVS builds
on a uniform process and a uniform layout that
allow the developer to implement search helps for
any values and objects while always retaining the
same user interaction.
• WDR_SELECT_OPTIONS: The component
provides different and more complex select options
for defining search criteria. These include, for
instance, the definition of areas and individual
values to be included in the search and the values
to be excluded from the search. The functions of
select options were also converted from the classic
Dynpro programming into the WD4A framework.
When designing your Web Dynpro application, try
to incorporate such predefined components instead
of implementing the relevant functions manually.
Reuse of software components allows faster develop-
ment cycles and reduces expenses. Web Dynpro for
ABAP supports these development processes using a
constantly growing library of predefined components.
8
The complete URL to call the application on the system used to develop
the example for this article is http://ld1052.wdf.sap.corp:50017/sap/bc/
webdynpro/sap/z_wda_sappj_po?sap-client=300&sap-language=
EN&PO_NUMBER=4500000008&DETAIL_MODE=DISPLAY.
Answers at your fingertips.
Extend your learning throughout the year with a license to SAP Professional Journal Online, where developers
and administrators are never more than an arm's length away from thousands of best practices and step-by-step
tutorials to implement, maintain, and extend SAP R/3 and SAP NetWeaver technology.
www.sappro.com
To learn about licenses for individuals, teams, and entire sites,
visit www.sappro.com.