Web Dynpro Makes Software Reuse a Reality

Feature Article | November 24, 2003 by admin

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, users 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 their 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.

One more pivotal benefit of Web Dynpro is the ability to build applications from components that are truly reusable.

The Web Dynpro programming mdel

Web Dynpro’s approach to creating User Interfaces (UIs) enables the user to isolate concerns when he builds, changes, or extends an application. With Web Dynpro, the development process allows it to distinguish between, among other things, allocating screen space, organizing data flow, and leveraging similarity for more efficient UI design.

A look at the Web Dynpro Explorer

A look at the Web Dynpro Explorer

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. A look at the Web Dynpro Explorer exhibits in addition to models — the underlying business data and business models that support the application —views and controllers, both contained in Web Dynpro components. These components are the user’s key to reusability in Web Dynpro applications.

Allocating screen space with views

Navigation Displayed in the Web Dynpro’s Application Modeler

Navigation Displayed in the Web Dynpro’s Application Modeler

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. One has to string these views together with navigational links to define the possible sequences of views the user will see. It is also possible to define nested views, or view sets, that divide the screen into smaller areas, each capable of showing one view at a time.
For instance, a part of an 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.
The view set’s composition is independent of the views’ layout or functionality. Later, it is possible to fill these views with the appropriate screen details. Conversely, it is easy to 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 – 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, it is possible to assign mappings between the contexts of different controllers. For other relationships, one may 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.
Binding and mapping

Binding and mapping

In Figure 3 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, one can map to corresponding elements in another controller. Mapping and binding relations guarantee automatic data flow from the screen into the controllers and back.

Leveraging similarity with components

User interface programming affords plenty of opportunities for reuse, and Web Dynpro components are designed to help to 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, 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 the user´s disposal:
Web Dynpro comes with a pre-defined set of some 30 basic controls – input fields, buttons, check boxes, table views – that can be used in the layout of a view. These controls typically cover 80-90 percent of what is needed in a user interface. But what about the 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 one needs for these views can all be devised as individual components. It is simple to implement these components once and then reuse them, just as if they were controls.
Components can dynamically adjust their behavior:
Suppose a user wants to incorporate a table into his UI. He designs his component to contain a static, fixed number of table view controls. At design time, however, he doesn’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, the user 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 and others. By using these dynamic features, the user can make components more generic – and therefore more reusable. After all, a component that gives a master-detail display of customer orders is fine, but a component that can give 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, 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.

Significant advantage

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. Web Dynpro will 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.
More information

Source: SAP Insider

Peter Tillert

Peter Tillert

Tags: , ,

Leave a Reply