Skip to Content

So you’ve done the ABAP Webdynpro course, and you’ve maybe built a few simple webdynpros. Perhaps you now need to build something rather more complex, and what you learnt on the course doesn’t seem to answer all your questions? Having recently been through that situation myself, in this blog I hope to pass on a few tips that might help you.

I will try to avoid repeating information that’s already out there, so don’t treat this as a complete development guide – remember to look at other SDN posts, SAP Notes and the online help as well.

I intend to keep my tips fairly brief – I’m aiming to give pointers rather than a step-by-step guide. But over time I may be able to expand on some of it – in response to your feedback and as I continue to learn myself. I have provided links to the relevant sections in SAP Help for most topics. So let’s get started…

Windows and Views

I was confused about these when I started my development. Did I need a window for every view? Basically:

  • a window is a collection of related views.
  • navigation between the views is defined in the window.

For example your application may have an initial selection view, a report view and a details view. The user should see only one view at a time, and they should all be shown fullscreen. That’s three views, and you would require a single window to define navigation between them.

For clarity, it may be useful to have a naming convention to distinguish between windows and views when programming. For example you could start view names with ‘V_’ and window names with ‘W_’.

A situation where a second window may be needed is for popups.


In the example above, it could be that you want the details view to appear as a popup. In this case a second window is required for the popup.

Note: in the web dynpro code wizard there’s an option to create and open a popup – you just need to provide the window name.

See example component WDR_TEST_POPUPS_RT_00.

View Layout

Of the three types of view layout available, I generally favour using Matrix layout – I found this easy to use and it produces tidy-looking screens. However the other layouts will have their uses also – for example I may use Flow layout to put ‘from’ and ‘to’ fields next to each other when showing a range.

I also make extensive use of transparent containers in my view layouts:



In the example above, I’ve divided my ‘item basic data’ fields into two columns by using transparent containers – I then have three groups of fields in each column. You can set the type of layout independently in each container. So it is quite possible to have a view where some parts have a Matrix layout, and other parts have a Flow or Grid layout.

In my ‘ITEMBASICDATA’ container, I’ve used the horizontal stretch option, along with width of 100%:



The groups themselves also have width set to 100%. By doing this my two columns cover the full width of the screen, rather than adjusting according to the lengths of the fields. In the groups I am not using either of the stretch options. So the fields and their labels are left-aligned, rather than spread out across the column:


Assistance Class

You can create an assistance class for your webdynpro, which must inherit from CL_WD_COMPONENT_ASSISTANCE. The name of the class just needs to be entered on the webdynpro component definition, underneath the description:



An instance of the class is created automatically for you at runtime. You can then access that instance from your methods using attribute WD_ASSIST, which is provided automatically.

With an instance class in place, you are now able to use text symbols in your webdynpro, which are stored in the text pool of the assistance class.

Aside from texts, some judgement is required in deciding what to put in the assistance class, and what to put in the webdynpro itself. When deciding keep in mind:

  • The assistance class may be used by any number of webdynpro components. Therefore an assistance class provides a means of re-using methods, attributes and constants between a number of different components. Originally ‘faceless’ components were designed to serve this purpose, but in practice assistance classes can achieve the same result more easily ( see )
  • The methods and attributes of the assistance class are available globally in the webdynpro component – you can access them from both component and view controllers.
  • References to webdynpro context nodes and elements may be imported and used in the assistance class methods. But pass the references into the methods rather than storing them in the class – the context could change.

Using the context

Coming from background of developing dynpro applications, I found it hard initially to understand how best to use the context. What follows are my thoughts on the subject so far – your suggestions, comments or corrections are most welcome.

First, it is helpful to be very clear about the various terms that are used in describing the context:

NODE – a data structure within the context.

ATTRIBUTE – a single data field under a node

ELEMENT – an instance of a node (there may be many, e.g. for a table of data)

Things to note about the context:

  • Any data that you want to see in a view, must be in the context of the view controller.
  • You can use context attributes to control UI elements dynamically (discussed in more detail below).
  • You should not treat the context as a repository for all of your data.

This last point is a mistake I made myself, partly because of the way I used the Service Call wizard to call a BAPI (see below). It is more efficient, and easier to code, if you store and access your data through either controller attributes, or in your assistance class (I now use the assistance class).

Leaving aside attributes for controlling UI element properties, it may be helpful to think of the context in the same way as a screen structure in dynpro applications. Fill the context with current data before displaying the view. When responding to events, read the context data (which may have changed), and copy it back to your data structures. Any logic can then access the data structures directly, rather than having to repeatedly access the context via method calls.


  • It may be useful to structure the context in the same way as your views.

For example you may intend to display data over a number of tabs. There maybe some advantages in having a separate node defined for each tab.


  • Context nodes are created with the ‘singleton’ property checked by default. You should normally switch this off – Thomas Szücs explains why:

Basic Concepts – The Pain With Using Singleton Context Nodes


Further advice on the context is available in SAP Help:

The Service Call wizard and calling function modules

You can use a wizard to create service calls to web services, function modules and class methods. The wizard will only create the calls in either the component controller or a custom controller. This fits with the MVC model – we should not be making service calls in the view controller, which should only be concerned with displaying data in the view. Note that using this Service Call option is not obligatory – it is quite possible to code service calls yourself.



In creating the service calls, the wizard can also create context nodes and elements for the interface parameters of the BAPI. The key thing to note is that you can choose how each parameter is implemented:



Rather unhelpfully, both ‘Controller Attribute’ and ‘Context’ are shown abbreviated as ‘Cont’. So to be sure of what is selected, it may be useful to expand the width of this field so you can see the full description.

Do not make the mistake of creating everything in the Context:

  • Many of the parameters won’t need to be shown on views, or bound to UI attributes. Therefore they do not need to be in the context
  • We may prefer to structure the context to reflect the way the views are structured, rather than taking the structure from the service interface.

With the other two options, either controller attributes or method parameters are created for you automatically. This may be useful, but doesn’t save a huge amount of labour – personally I prefer to write my own function module calls, which leaves me full control over the process.

Mandatory Fields

In webdynpro, UI input fields can be given status ‘required’. This causes them to be marked on screen with a red star.



Unlike in dynpro applications, no check is made automatically to see if the fields have been filled. To make the check yourself, obviously one option is to code a simple check for each input field. However you may have an application that determines dynamically what input fields are mandatory – if so the check must be dynamic also. Fortunately a static method is available to perform such a check:


– any fields with missing data produce a generic error message, and the field is highlighted.

Error Messages

Messages are reported using methods of IF_WD_MESSAGE_MANAGER.

  • By using the REPORT_ATTRIBUTE_* methods, you can link a message to a specific input field, which will be highlighted on the view.
  • Unlike in dynpro programming, processing does not stop when you have raised an error message. Therefore you need to consider if you should exit the method after an error has been raised; or just continue, possibly to identify further errors to report.
  • Similarly, raising an error message does not automatically cancel any screen navigation. If you want the user to stay on the same screen when an error message is raised, then you need to set the ‘CANCEL_NAVIGATION’ parameter.

Responding to user input

When creating SAPGUI-based dynpro applications, we can respond to user input in PAI. By using ‘on input’ and ‘on request’ we can react to changes to specific fields. It may be useful to do the same thing for a web dynpro view, but how can we know what has changed?

Fortunately, the Context Change Log is provided for this purpose:

Using methods of IF_WD_CONTEXT you can switch the log on and off, retrieve a table of changes or reset it. The table of changes tells you exactly what context attributes changed, along with the old and new values.

In dynpro applications, PAI runs following any kind of user action, such as pressing enter, or calling a search help, or pressing a button. In webdynpro we have control over when to respond to user changes. In the view layout, each UI element has a list of possible events as part of its properties. For example all input fields let you respond to the user hitting ‘enter’ on that field:



In this example I’ve created an event called ‘SUBMIT’. I’ve used this with all UI elements where I want to respond to the user’s input. Within the event handler method, I read the context change log and respond to any changes that have been made.

Automatic refresh

You may have an application where you want to automatically refresh the data selection periodically, without intervention from the user. This can be achieved using a TimedTrigger UI element:

Drill down

Within SAPGUI applications it’s common to provide a drill down facility from an ALV grid. For example if you are reporting a list of order numbers, you may want the ability to click on an order number and have the order appear. This kind of facility is not so easy to provide from webdynpro – unless you are drilling down to a another webdynpro. The following SDN thread discusses the options:

Web Dynpro ABAP call transaction in the foreground

The favoured solution seems to be creating a shortcut object. When called this opens SAPGUI, navigates to the transaction required, and can also fill parameter fields on the front screen. Skipping directly to the next screen does not seem to be possible, unlike when using a call transaction. Function SWN_CREATE_SHORTCUT may be helpful for creating the shortcut.

Dynamically changing UI Elements

Something you may want to do in response to user input, is to dynamically change properties of your UI elements. Specifically, we may want to change:

  • Visibility
  • Read Only
  • Required
  • Enabled

There are at least three ways of doing this:

1) Binding to Context Attributes

In this method you create context attributes and bind them to the properties of your UI elements. This may be particularly effective when a large number of UI elements should behave in the same way for particular situation. For example I may have an application that can run in ‘change’ or ‘display’ modes. I could create a single ‘readonly’ context attribute, and bind it to the ‘readOnly’ property of all my input fields. When the user switches between display and change modes, I can set the value of my context attribute to switch the field properties.

2) Binding to Context Attribute Properties

For a more complex application you may want to control the four attributes of every input field individually. Using the above method, this would involve creating huge numbers of context elements (four for every input field). Fortunately this is not necessary – context attributes have these four properties available automatically:

To use the context attribute properties: when binding select the context attribute and then choose ‘Bind to the Property of the Selected Attiribute’, along with the actual property from the dropdown.



3) Dynamic Programming using WDDOMODIFYVIEW

For each view, inside hook method WDDOMODIFYVIEW you are given a reference to the view itself. Using this it is possible to get references to the view’s UI elements. Using methods of the various UI element classes, you can change the UI element properties directly, without them being bound to anything in the context.

Note that WDDOMODIFYVIEW is the only place you can get the view reference, and should be the only place where you make these kinds of changes.

Because the UI elements are not bound, this method has the advantage that you can still set the properties in the view layout, which will be your default values. You only need the dynamic programming to run when you want to change from those defaults.


Each of these three methods has its own advantages and disadvantages, and the best method to use may vary according to circumstances. Something you may wish to consider is the use of a bespoke configuration table to control the UI properties. Such a table will need these fields:

  • The data fields which you want to affect the layout. For example these could be Document Type, Company Code, application mode etc. These will be key fields.
  • Fields to identify the UI element. These will probably be Webdynpro Component, View name and Element name. These will also need to be key.
  • Simple flags for the four UI properties.
  • A free text comment field may be useful for explaining your logic in words .

In my own application I used a config table like this, combined with dynamic programming. The UI elements took their default properties from the view layout, and my table only needed to control when they changed from those defaults. I coded my selection so that I could create generic config records, such as a rule to apply to all fields in display mode. That’s to say, you don’t need a config record for every possible combination of key field values. To make this possible I just had to allow space as a valid value in my select:

  select *
    from zmsd_wbd_fields
    into table wd_this->gt_field_config
   where auart          in (space, x_auart)
     and vbtyp          in (space, x_vbtyp)
     and poart          in (space, x_poart)
     and appl_mode      in (space, x_appl_mode)


Note that you could bind to context attribute properties (method 2 above), and still use a configuration table in this way. You would however need more records, as you could not define default values on the view layout.

Calling Input Help dynamically

The various methods of implementing input help are described in SAP Help:

But what if you want to call input help dynamically from your method code? For example you may want the input help to appear automatically, in response to the user changing an input field. A suitable method is available, but it’s SAP internal:


To use it we simply need to pass in a reference to the context element, and the name of an attribute. It will then run the value help defined in the context for that attribute.

However being SAP internal, the method could change or disappear at any time. So if anyone can find an alternative way to trigger a help dialog, then please let us know and I’ll update this section.

Application Parameters

When creating Webdynpro applications, various parameters can be set that alter the behaviour of the application:


Some of these options affect the look and feel of the application and are described below.

Additional parameters that may be of particular interest are:

  • WDDELTARENDERING (performance)
  • WDSHAREDREPOSITORY (performance)


Configuration offers a further option for changing view layouts. Configuration may be thought of as being equivalent to transaction variants in dynpro applications. Within a configuration, the properties of UI elements may be changed in much the same way as the dynamic options described above.


Once created, a configuration is linked to an application using parameter WDCONFIGURATIONID. This makes it possible to create a number of different applications, which are all just versions of the same underlying component.

To the best of my knowledge, a configuration cannot be changed dynamically at runtime. So for example if you created separate configurations for ‘Display’ and ‘Change’ modes, the user would not be able to switch between them at runtime. Therefore in that situation, the methods to change UI elements dynamically may be more useful.

Look and Feel

The look and feel of your ABAP webdynpro applications can be changed using themes. A theme is a collection of style sheets (.CSS files) and graphics.

This ability is highly significant: your applications are not restricted to the standard SAP look and feel. Minor changes such as text size can easily be made via the theme editor (described below). With more extensive CSS knowledge, the entire look and feel of the application can be customised. An obvious use for this would be to apply corporate branding.

When running the webdynpro through a portal, application parameter WDFORCEEXTERNALSTYLESHEET may be useful to ensure that webdynpro always uses the style sheet from the portal. Themes may be developed using the Theme Editor supplied with the portal:

Alternatively, application parameter WDTHEMEROOT may be used to specify a theme for the webdynpro, different to that of the portal. A number of standard themes are available to choose from.  The exact logic for theme determination is explained in SAP help, and also on the SDN:

EP 7 Portal stylesheet with WD ABAP


Without a portal, we may also like to create and use bespoke themes. The Theme Editor supplied with the portal, can also be downloaded from the SDN to be used stand-alone: 

This is quite a complex procedure, requiring you to install Java and Eclipse, and then adding a plug-in to Eclipse for the theme editor. Once complete you can copy a standard theme, such as sap_tradeshow, and then modify it.

Be careful to download the versions of Java and Eclipse specified – it may not work with more recent versions. If you have more than one version of the Java runtime environment installed, you may need an extra ‘-vm’ parameter to make it work – explained here:

Re: Eclipse Theme Editor

In my own case I had difficulty in adding the parameters to my Eclipse shortcut, so instead I added to .cmd file to my desktop with the following script:

cd Program FilesEclipse
eclipse.exe -vm “C:Program FilesJavaj2re1.4.2_17 injavaw.exe” -consolelog -vmargs -Xmx512M 

Once we have created our own theme, we need to upload it to the MIME repository and then use it in our webdynpro application. This is process is explained here, by Bastian Preissler and Matthias Grün:

Two possible URL parameters are mentioned here: I found ‘SAP-EP-THEMEROOT’ to work much better than ‘SAP-CSSURL’. 

Note that it is possible to set the theme from within the webdynpro code. This is enormously powerful: if required, your application could run logic to choose from a number of themes at runtime.

Here’s a screenshot from an application using a modified theme. The text is all much larger than normal, and the colours used in the table have been changed:


Running webdynpro applications via SAP GUI

It is very simple to create a SAP GUI transaction that will run a webdynpro application. The transaction can be created in SE93, calling transaction WDYID with the application name as one of the parameters (thanks to Glen Simpson for this tip): 

Transaction WDYID uses function module WDY_EXECUTE_IN_PLACE. This may be used to run a webdynpro application inside a browser control on a dynpro screen.


Webdynpro ABAP code can be debugged by setting external breakpoints. When the breakpoints are hit, the (new) debugger will be launched. Note that you must not already have the maximum number of SAP GUI sessions open – if you do the debugger cannot launch and the application will not stop.

Within the debugger a special tool is available to help you to debug the webdynpro itself:


Example webdynpro application

An example of a full-scale, complex, webdynpro is LORD_MAINTAIN_COMP. This can be used to create, maintain and display sales orders.

The Future: forthcoming features

ABAP Webdynpro is still evolving, and Netweaver enhancement pack 1 (NW 7.01) brings a selection of excellent new features. Some of the most eye-catching are:

  • ‘Light Speed’ rendering. This is a massive leap foward – quite simply web dynpros will have much better performance and a more ‘web 2.0’ look and feel. Expect a look and feel remarkably similar to CRM 2007.
  • Drag & Drop: until now, it has not been possible to put drag and drop functionality into your webdynpros – with EhP 1 this becomes possible. For NW 7 and below, check out David Lees’ excellent blog describing drag and drop using dynpro controls technology: ABAP Controls, Tree’s and editable ALV with drag & drop
  • Flash Islands: it is now possible to integrate Adobe Flash into your webdynpros.

I have yet to develop on a 7.01 system, so I can’t offer any further insight on the features just yet. However much more detailed information is available in SAP Help:

To report this post you need to login first.


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

  1. Suresh Datti
    I attended the WDA Class in Dec’07.. contemplating on replacing one of our Transaction iViews with a WDA iView.. thanks a ton for your tips.. I look forward to more of such stuff from you.. keep them coming pl..


  2. Alan Nicholson
    Hey, very interesting – only just skimmed through…but having examples that actaully exist on our system will be such a help 🙂

    if only all SAP Blogs where like that!!!!



  3. Thomas Szücs
    It’s an excellent web log summarizing many aspects of Web Dynpro ABAP while provding links to detailed information.

    One note though. You wrote:
    >But what if you want to call input help
    >dynamically from your methods? Fortunately a
    >method is available:

    Well, everything (which a few exceptions) that starts with cl_wdr is SAP-internal. Using this class and calling this method should not be done as SAP might change this class and method at any time without notice.

    A better way to call up a value help dynamically is to register it at the corresponding context attribute at runtime by using dynamic programmming.

    Best regards,

    1. Roger Sainsbury Post author
      Hi Thomas,

      glad you like the blog! It’s a very good point about the method – I hadn’t appreciated it was internal.

      However in the blog I didn’t really explain in detail why I was using it. I had five inputfields which were all bound to the same value help in the context. Only certain combinations of values were allowed for the five fields. If the user selected the dropdown button on any of the fields, they would get the same help dialog to choose a valid combination.

      Two of the fields were simple text inputfields. For these, if the user changed the value, I wanted to trigger the help dropdown automatically. This would prompt the user to select valid values for the other four fields.

      So my value help was already registered against the context attributes. What I was struggling with, was to force the value help dialog to run in response to changed input, rather than the user hitting the dropdown button. In traditional dynpro programming there’s a simple function module you can call. When I found this method I thought it was the WebDynpro equivalent – it certainly solved my problem! Is there a better way I could have achieved the same thing?

      By the way – I’ve just read some of your own blogs, which are excellent! The Webdynpro’ers out there should definitely check them out. In particular, the blog on singleton nodes provides the definitive advice on the subject (‘The first thing after creating a context node is to switch off the singleton checkbox. It will save you a lot of trouble.’)
      Basic Concepts – The Pain With Using Singleton Context Nodes


      1. Roger Sainsbury Post author
        I’ve now updated the blog to warn that the help method is internal. I’ve also added a note about singleton context nodes with a link to Thomas’s blog. The updated version should be online shortly.
  4. Alejandro Bindi
    Man, I wish you’d published this blog months ago when facing my first WD project. A lot of this items were learned by me the hard way, by several trial and error. Thankfully on the next one this info will be readily available in a unique place.
    Many thanks!
  5. John Jakabcsin
    This is an excellent example.

    Thank you.

    On a related note, what is the future of ABAP Web Dynpro – especially when compared to BSP?

    Is SAP doing future developments in BSP or Web Dynpro? 

    1. Roger Sainsbury Post author

      thanks for all the positive feedback!
      A very good question from John. Note that I can only answer this one to the best of my knowledge. If any of my SAP colleagues out there are in a better position to comment, then please go ahead!
      As I understand it, ABAP Web Dynpro is now SAP’s UI technology of choice for new developments. Exceptions to this are:
      – Self-service applications, which use Java Webdynpro.
      – CRM, which has been built using BSPs , and continues to use them in the latest version (CRM 2007).
      So from SAP’s perspective ABAP Webdynpro is considered to be the future, and I would expect the technology to keep being improved over time.
      Note that with the Netweaver Business Client, a user can run applications in any of the UI technologies: Dynpro, BSP and Webdynpro.
      Which technology you wish to use for customer developments is entirely your choice. BSPs argueably offer you more power and flexibility than Web Dynpro, but are more complex to write and maintain, and require additional skills. Just because SAP are not building new BSPs, does not necessarily mean that you shouldn’t – I think you should consider which technology best meets your requirements, and what skills you have available.


  6. Asgarali Mia
    In using context functionality,is it best to define all the data that you’ll be using in CRM functionality(business partners,cases,etc) using data dictionary or is there a best practice approach to access these CRM tables (BUPA) and use them in the views and context programming?
    1. Roger Sainsbury Post author

      sorry for the late response. I’m not an expert on CRM programming, so I can’t really advise on best practice. However I imagine there probably are BUPA BAPIs or function modules available to use. Regarding the context, I’m suggesting you should only include attributes in the context that you actually intend to show on the screen. So I wouldn’t suggest defining your context using standard BUPA structures, unless you genuinely intend to use most of the fields on your views. If the available BAPIs/functions return more data than you need, then you could store the selected data in an assistance class. You can then fill the context with only those fields that you actually need.


  7. Glen Simpson

    I have to add my congratulations too! 🙂
    We need more blogs like this one with simple, pratical tips for situations that could otherwise take hours of trial and error to understand let alone resolve.

    I’m really only new to WDA myself but I’d like to add some of my own discoveries that might add to or (respectfully) contradict parts of your blog.

    In your section on Dynamically Changing UI Elements you mentioned creating a custom table to enable the configuration of the display properties of UI elements however I believe this can be done without custom coding using Implicit Component Configuration

    Also, rather than writing a custom program to use function module WDY_EXECUTE_IN_PLACE to run a Web Dynpro app in SAP GUI you can simply create a custom parameter transaction that calls standard transaction WDYID with the appropriate WD app name, configuration and where you want it to execute (in the GUI or in a browser).

    Hope these help…


    1. Roger Sainsbury Post author
      Hi Glen,

      thanks very much for your message – I’m glad you like the blog. Your tip for creating transactions is fantastic – I think this will prove to be very useful. I don’t think it was previously possible, so perhaps it was introduced via an enhancement pack. I’ve added it to the blog under the appropriate section.
      I’ve also added a section on configuration. These are slightly different to the dynamic methods I described, in that they are assigned to the application, and then apply for the lifetime of the application. Whereas the dynamic methods may be used to change the UI properties at runtime. So for example in an order application, you may want to change the UI elements depending on what order type the user selects at runtime.
      I’ve also added a note about drag and drop – I recently became aware this is not possible in ABAP web dynpro, although I believe that should change relatively soon.


  8. Jodie Gaisbauer
    Thanks for the tip in section View Layout with example ‘ITEMBASICDATA’ container having a consistent width.  This is something really useful to have a consistent UI look and feel!
    1. Roger Sainsbury Post author
      No problem Jodie, I’m glad you found it useful. I certainly found it was small things like that, which can make an application look really professional.
  9. Malcolm Will
    Very useful thanks, good job.

    I have what should be something simple that I wasn’t able to figure out yet. I have created a transportable VIEW for a Web Dybnpro report using the MODE=CONFIG…. and would like to set this as the Initial View for ALL users, rather than the [Standard View]. Any ideas how this can be done? Thanks

  10. Ron Sargeant

    Hi Roger,

    The explanation of the context is not quite right.

    A node is the equivalent of an internal table in classic ABAP. Even if the cardinality is 0:1 or 1:1 the base object still operates as a table.

    The element is the classic ABAP ‘structured row’ equivalent, i.e. the node contains 0..n elements (rows) at runtime.

    The attributes are the ‘columns’ of an element.

    All nodes below the root are known as indepent nodes as they have no depnecy other than the root providing a path to them. All nodes below these nodes are dependent nodes as they require the parent to exist before they can be instantiated.




Leave a Reply