Skip to Content

In this blog I want to introduce a smooth and handy way of navigating in Web Dynpro. I use the following technique in every Web Dynpro application ever since the idea came into my mind. I’m sure you will be able to integrate it in your application and gain the benefit of it.

I do not restrict the guide to WD Java or WD ABAP, it is not relevant how it is programmatically done, the idea itself counts and according to that it is usable for both application servers. Nevertheless I will use some Web Dynpro ABAP screenshots at the details.

Classic navigation in Web Dynpro


Right now the framework offers navigation plugs for navigation as inbound and outbound plugs. The plugs are part of views as entry or exit points. When the user navigates the user will be taken from one view to the next. A typical scenario could be you have two views, View1 and View2 where you have one outbound plug at View1 and one inbound plug at View2 which are connected via a navigation link. The definition of plugs and their navigation links is handled in the applications windows. When an action in View1 is triggered to navigate to View2 the action handler in the view fires the outbound navigation plug. The framework realizes by the navigation link to show View2 now and instantiates the view and calls some handler methods (wdDoInit, handlePlugXy, wdDoModify).
That is basic knowledge and there is no alternative to that of how to navigate between views. Fact is that you will have links between navigation source views and navigation target views. You can only navigate in the views, you cannot fire plugs from controller code. You therefore have a so called point to point navigation. You have to take care that the navigation state, meaning the screen you are in and where you may navigate to, is handled by yourself.
In short form:


  • Easy design of navigation
  • Simplestructur, easy to understand in small scale


  • Navigation only in views
  • Hard to maintain when reaching a certain complexity
  • No navigation state

Concern of chaos

Before actually going more into detail, there is one scenario which explicitly shows you the need of more control over the navigation. The scenario would be the example from above, having two views in which you can navigate. Now we additionally imagine a third view which is always visible above the two views between we can switch. The third view shows a roadmap UI element which tells us in which screen we are:

When we navigate from one view to the other, the state of the roadmap should change. Now technically the only thing the framework offers is the navigation between the views. What should also be possible is to navigate via the roadmap, by clicking on the target view. What we will need now are more plugs and navigation links.
The more complex your application becomes the more navigations you will most likely have. Now looking beyond three simple views, you might have an application with lots of views where it is possible to switch from one view to all the others. What you will come across is a spider web of navigations you will end up being tangled up in.

Believe it or not, I’ve seen something like that. Now imagine you want to create a new view with all the navigation plugs and links. Probably you have certain restrictions of navigation etc. you will really be in trouble.
There is yet a way for avoiding chaos and gain more control over the navigation.



What I aim for is a way to control complex navigation and make use of the power of the framework. To achieve that I take coding out of the view into the component controller (or custom if you prefer). The idea is to have one view in the whole application which really navigates This one view, I call it navigation view, is the only one with outbound plugs. Still every visible view has its inbound plug of course, but no view will really navigate any more (except navigation view).

This simple idea requires more thinking of course. You have to let the navigation view know that you need to navigate, every source view still needs a way to navigate and the most important are clean up and initialization operations.


The heart of the idea is basically one navigation view which navigates (fires plugs) and two events which are needed to clean up and initialize views: “prepare navigation” and “commit navigation”. The first event will be called if any source view or controller wants to start a navigation from one screen to the next. If every view and controller being involved in that feels fine the navigation will be committed via the “commit navigation” event.
If you have a “dirty flagged” view (changed, unsaved data) for example, you will save it as soon as you get the navigation prepare event. If the saving went fine the commit will be executed. In a usual case the prepare navigation event will come from the source screen. The navigation commit will be called from a controller (component or custom) after the clean up process. When the commit event is called the target step will need to initiate itself and load the data. In case something goes wrong here, you will still keep control of it and navigate back… Let’s see


Every participating view will have one ore more inbound plugs. The navigation view in contrary has several outbound plugs, one to each destination screen. The navigation view must not be a view with UI elements but I usually use one central view which is always visible, you will definitely need to have the view instantiated before you navigate

If a source view wants to navigate (by hitting a next button for example) the view will call a method in a central controller. I usually call the method “prepare_navigation” with the parameter “sourcestep” and if available a parameter “targetstep”. “Targetstep” is usually not necessary the controlling logic of when to navigate where should definitely not be in the view.
The controller then does its clean up logic if necessary and broadcasts out the “prepare navigation” event. Now every controller or view which is active and involved might do his clean up processes. After that the source view itself or any responsible controller will confirm the navigation by calling the “commit_navigation” method in the controller which will broadcast the commit navigation event by passing also the source and now definitely the target step. The navigation view reacts upon the commit event and fires the plug. The target view will do his initialization when receiving the commit event.


The navigation controller (component controller or custom) is responsible for accepting navigation requests and sending out the events. The prepare navigation method and event is intended to take control over the cleaning up, the logic of input validation and things like that. It is also really cool to have the navigation commit method for other uses. You can navigate every time you want from every possible view.
When using good naming conventions you can have a context node with the navigation steps as attributes and make use of it in the views (like road map) and use the constants as step names for dynamic context manipulation and event handling etc.
In case a navigation is not committed nothing happens and in case the target view is not in the mood of displaying because of a faulty state or bad data, the controller or the view itself has the information what the source step was, so the target view can undo the navigation to the initial view if necessary or to an error view.
There is just more control in your code, well structured in methods which are repeating in every control or view.


Introducing the approach to a small application can be fairly easily done and the good thing about it is the scalability. Every new view just fits in the system and will cause the same effort. When you have a huge navigation structure you will experience the power of the Two-Step-Navigation.
When you have applications with sub-steps you can also use the concept – it is just the same behaviour. Even in used components you can make use of it via eventing and method calling.


Using the concept of prepare and commit events as the basis of navigation and not view logic as well as one navigation view as central navigator with outbound plugs makes it very easy to control navigation. You reduce the code fragments to centralized methods and may keep track of the navigation state. When introducing new views to the application they can be easily integrated now and will not cause you hours of searching navigation, validation, clean up and initialization code.
As I mentioned in the beginning it is not restricted to Java or ABAP, I’ve used the concept in projects on both application servers successfully, there is no difference.
Have fun!

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Thorsten Franz
    Hi Stefan,
    I agree that this is sometimes a very helpful design pattern, especially when you want to embed views into a a framework of other views and you need to standardize communication between them.
    Even when building relatively simple applications (think the user management application in NWA on AS Java), you can benefit greatly from having an object that encapsulates the navigational state of the application. What’s also nice is to have a “navigation request” object which represents the desired navigational state. Such an object can be used to jump from another application precisely into a particular navigational state of the target application.
    Best regards,
    1. Stefan Bungert Post author
      You’re absolutely right. I will have a look at the user management. In a Web Dynpro Java application I’ve been using a class which represented the navigation state, it kept track of the state and the possible navigation paths. that is what you could really take advantage of when reusing such a system. Also you can think of having a config file which describes the navigation map…
  2. Jan Penninkhof

    I think this way of applying navigation is much better and more natural than using the plugs. Just like you, I often ended up in the connector-chaos between the views-plugs, and decided to move aboard of the navigation-view train as well.

    I have only once used the plugs for a project that was very much roadmap based (as in the Roadmap UI control). That was, until the customer decided that he wanted to click on the roadmap steps to navigate more randomly. Instead of creating all possible plugs-combinations, I quickly transformed my project back to a project using a navigation view.

    Kudos for the blog and taking the courage to write this down.


  3. Siarhei Pisarenka
    First of all thanks for posting the nice idea…

    I worked with Webdynpro Java, not Webdynpro ABAP, so, please, correct me if something is not relevant…

    The first comment is related to Prepare event. I see a restriction here that the only one view can confirm a navigation by invoking Confirm method. How will the view know that all other views also confirm the navigation?

    The second comment is that an event handling is not very convenient way in general when we use embedded Webdynpro components providing the navigation views. Because events are not propagated from parent component to children.

    Maybe I also write a blog some time later where I answer to the questions and explain how I implemented navigation in a big Webdynpro Java application.


Leave a Reply