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.¹

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!

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.

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.