With Web Dynpro, SAP sets out to replace the dynpro programming model
for a new generation of browser- and platform-independent user interfaces.
Judging from the name alone, it will come as no surprise that Web Dynpro
includes many of the familiar goodies that served developers so well in
its predecessor, the dynpro, which defined user interface development
for SAP applications over the decades. In Web Dynpro, you’ll still
find features such as automatic input help and error handling, data formatting
and checking based on data dictionary information, and a rich set of controls
for use in your interfaces.
But Web Dynpro is a significant departure
from the dynpro model when it comes to client technology, platform, and
architecture. Here the new Web Dynpro programming model takes a big leap
forward:
User
interfaces based on Web Dynpro are targeted to run in the Internet browser.
The
Web Dynpro programming model is fully independent of the ABAP language
— in fact, the first version of Web Dynpro runs on the Java platform.
The
dynpro allows for separating frontend and backend in an application, but
the Web Dynpro requires such a separation by design.1
In this article, I’ll explore one
more benefit of Web Dynpro: the ability to build applications from components
that are truly reusable.
The Web Dynpro Programming Model
Web Dynpro’s approach to creating UIs ensures you can isolate concerns
when you build, change, or extend an application. With Web Dynpro, the
development process lets you distinguish between, among other things,
allocating screen space, organizing data flow, and leveraging similarity
for more efficient UI design.
Web Dynpro is built around a generic meta-model
for user interfaces, based on the well-known Model-View-Controller (MVC)
paradigm, which dictates separating an interface into specified layers
during design. If you look at the Web Dynpro Explorer (see Figure
1), in addition to models — the underlying
business data and business models that support the application —
you’ll also find views and controllers,
both contained in Web Dynpro components. These components
are your key to reusability in Web Dynpro applications.
 |
Figure
1 |
Elements of a Web Dynpro Application Viewed in the Web
Dynpro Explorer |
Allocating Screen Space with Views
With Web Dynpro, the developer defines views to allocate
screen space and determine what will appear on the end-user’s screen
simply by arranging the basic UI elements. You then string these views
together with navigational links (see Figure 2) to define
the possible sequences of views the user will see. You can also define
nested views, or view sets, that divide the screen into
smaller areas, each capable of showing one view at a time.
 |
Figure
2 |
Navigation Displayed in the Web Dynpro’s Application
Modeler |
For instance, a part of your application
may follow the design shown in Figure 2. This view set divides the screen
into three areas: the “Left” area will always contain the
“ObjectTree” view; the “Top” area toggles between
the “Standard Tools” and “Advanced Tools” views.
Together, these three views control the navigation between views in the
“Right” work area.
Note that the view set’s composition
is independent of the views’ layout or functionality. Later, you
can fill these views with the appropriate screen details. Conversely,
you can easily tinker with an interface by rearranging the views —
without even touching any code.
Organizing Data Flow with Controllers and Contexts
While views determine what the end-user sees on screen, a controller
handles the actions that are invoked from the screen — clicking
a button, selecting data in a table, etc. — or passes them on to
other controllers so that they can handle them. The controllers can be
thought of as the active entities in the user interface. Any data managed
in a Web Dynpro UI is attributed to some controller; the hierarchy of
data that a controller “owns” is its context.
For data to automatically travel from
one controller to the other, you can assign mappings
between the contexts of different controllers. For other relationships,
you set bindings to define automatic, bi-directional
data flow between some part of a context and:
- Some UI elements in a view’s layout or
- Some part of the model layer, which encapsulates the backend
In Figure 3, for example,
the ID and Description fields are shown in a View Layout.
The developer binds these controls to elements in the View Controller.
Then, to pass this data along to other controllers, you can map to corresponding
elements in another controller. Mapping and binding relations guarantee
automatic data flow from the screen into the controllers and back.
 |
Figure
3 |
Binding and Mapping Between Views and Controllers |
Leveraging Similarity with Components
User interface programming affords plenty of opportunities for reuse,
and Web Dynpro components are designed to help you leverage these opportunities.
Each Web Dynpro component offers reuse at three levels:
- Visual — The component’s views, and the navigation and
nesting that exists between them
- Functional — The methods and events in the controllers
- Data — The context of the controllers and their mappings and
bindings
All components can embed — and be
embedded by — any other component. To do this, each component decides
which parts of the three levels it exposes to other components. The embedded
component provides an interface view, which comprises
the visual part of the component, and an interface controller,
which exposes methods, events, and a context for mapping against other
contexts in the embedding component.
For an example, let’s look back
to Figure 2. If the Search view is a normal view, it will display
one fixed screen layout. However, Search could be an interface
view, so whenever the application navigates to Search, the entire
navigation scenario of this component will become visible in the work
area. In this case, the Search component may alternate between
two views, SearchCriteria and SearchResult, in the “Right”
view area.
Likewise, in Figure 3, the Global
Controller could actually be another component’s interface
controller, making data from inside the component accessible to other
components. For example, the controller could be the interface to a component
that reads business objects from a model layer, presents one of the objects
in its interface context, and also exposes methods to move to another
object in the set. Via binding and mapping, the view layout would always
show the attributes of the object that is currently selected in the component.
Or perhaps the two components are actually
the same, that is, the global controller is the interface controller of
the Search component. An advanced Search component could not only find
business objects, but also allow mapping to one selected element in the
result set.
These examples show how easy it would
be to integrate such a component: Figure 2 shows how the component is
integrated into the navigation of the application, and Figure 3 shows
how to perform data transfer with the search result the component has
found.
Components at Work
In the Web Dynpro world, an application is really just a point of entry
into some Web Dynpro component. In the simplest case, a Web Dynpro component
exists simply to implement a single application and contains all the views
and controllers necessary for this implementation. However, components
can do much more:
Components
Enhance the Set of Controls at Your Disposal
Web Dynpro comes with a pre-defined set of some 30 basic controls —
input fields, buttons, check boxes, table views, etc. — that can
be used in the layout of a view. These controls typically cover 80-90%
of what is needed in a user interface. But what about your custom development
needs? What if a department project requires a group calendar, a special
type of input form, or a particular combination of tree and table views?
Components offer a natural solution for
filling these gaps. The elements you need for these views can all be devised
as individual components. You can simply implement these components once
and then reuse them, just as if they were controls.
Components
Can Dynamically Adjust Their Behavior
Suppose you’re incorporating a table into your UI. You design your
component to contain a static, fixed number of table view controls. At
design time, however, you don’t know how many columns the tables
will have, or what these columns’ titles or data types will be.
With Web Dynpro, this information can be supplied much later in configuration
data — data that the component only receives at runtime. In other
words, you can add code to the controllers in the application design,
which creates more entities (or changes existing ones) at runtime.
Using this technique, components not only
can control their behavior (by the configuration parameters they are given),
they also can control their appearance, interface context, etc. By using
these dynamic features, you can make components more generic — and
therefore more reusable. After all, a component that gives you a master-detail
display of customer orders is fine, but a component that can give you
a master-detail display of arbitrary objects consisting of a
header and a list of line items is far more useful!
Components
Can Implement Patterns
The basic idea behind “pattern-based” user interfaces stems
from task-oriented UI design. This school of software usability requires
that UI development should start with an analysis of users’ real-world
tasks. Then UI “patterns,” each optimally supporting one of
those tasks, should be implemented. Finally, applications should be strung
together from these patterns according to the specific tasks in the business
process that the application tackles.
This approach to user interfaces was given
a “reality check” — and had overwhelming success —
in SAP CRM 3.1. In this release, all the UIs of the main CRM applications
were revamped, and all those new UIs were implemented in pattern mode.
One common “floor plan,” combining standardized patterns for
searching, detail display, etc., was found adequate for all those different
applications.
End-users reported this “people-centric
UI” to be much easier to learn because the same user-interaction
patterns were used over and over again. Once users ran through one CRM
application, they were suddenly able to master them all!
Web Dynpro Resources and References
- “Web Dynpro is Just Around the Corner — Will it
Revolutionize Your Web UI Development and Runtime Environments?”
by Franz-Josef Fritz, SAP Insider April-June 2003.
- “Your ‘Easy Way In’ to Web Dynpro Development:
New Design-Time Tools Available with SAP Web Application Server
6.30” by Karl Kessler, SAP Insider April-June 2003.
|
Components
Can Implement Quasi-Patterns
The reality of pattern-based UIs, however, is that not all applications
are suited for such an approach. Another application currently getting
a UI overhaul is Employee Self-Service (ESS) in the SAP Human Capital
Management offering. Here the basic spirit is the same: one general “floor
plan” helps to streamline user interaction overall, and then standardized
components are plugged into the areas determined by the floor plan.
However, the ESS suite of applications
will take a “quasi-pattern” approach, and applications will
look much less homogenous than the CRM suite — for good reason.
Unlike CRM, which is normally used by specialized users, ESS is for all
employees, so UI designers in ESS need a higher degree of freedom. The
choice of which component does the job best and should therefore perform
in a certain floor plan area can be very different from application to
application. On top of that, there are a few ESS applications (e.g., budget
planning) that require specific — that is, definitely non-generic
— components.
Web Dynpro’s component concept can
support the more dynamic, quasi-pattern approach of ESS just as well as
it can support the more static CRM setting.
Conclusion
Of all its benefits, Web Dynpro’s ability to encapsulate reusable
parts of user interfaces is a significant standout. Here, Web Dynpro offers
developers a huge advantage in comparison to both its forerunners —
the dynpro and the server page models such as JSP and Business Server
Pages.
Look for Web Dynpro to be a major driving
force throughout the development both of SAP standard and custom applications.
Not only does it make development work that much easier, but it also helps
pave the way toward complete, services-based business solutions and supports
SAP’s move to Enterprise Services Architecture (ESA) for enterprise-
scale use of Web services.
1 See resources in the
sidebar at the end of this article for further introduction to Web Dynpro.
Peter
Tillert has a Ph.D. in Computer Science and joined SAP AG in 1989. He
began in Technical Marketing and was a member of the first R/3 rollout
team before he switched to development. Specializing in user interfaces
and desktop integration, he moved up to the ranks of Development Architect.
He returned to Technology Product Management when the Web Dynpro project
was born.
|