Skip to Content

Web Dynpro for ABAP – Thoughts on MVC and WD4A Observations


I’m a long time ABAP’er (amongst other things) who also got involved in Web Dynpro for JAVA early on.  There were a few interesting features and stability issues in the past, but the whole approach for WD4J was pretty straightforward and aligned to MVC pretty well. 

However, when it came to transferring my understanding of WD4J to WD4A, I was a little confused at first as the Window Controller and assistance class threw me.   I had previously developed quite a few smaller WD4A apps, however, recently I had the chance to developer a larger scale development which required component development and leveraging all the features of Web Dynpro and came away with a few thoughts around how MVC is established and potentially a pattern for building WD4A applications.

First for the observations:

  • The Assistance Class seems to be a much better global data storage location than the context or local variables withina controller (assuming they don’t need to be mapped through a context). Not to mention, the performance is supposedly much better (according to SAP help)
  • The Window Controller seems to own things much more than the Component Controller making me wonder whether the Component Controller could just be wrapped into the Window Controller.  i.e. The Component Controller can’t navigate; but it can tell the window controller to navigate.  All the Component Controller seems good for is interfacing and Context Definitions.
  • It’s funny how the Window inbound plug hides its parameters (that would be passed via the URL) within the code section where on all other plugs on views, it’s there in the definition screen (that one hurt me one day).
  • All the tutorials out there have views navigating to other views which from an MVC pattern seems strange unless you want to throw the View Controller in as a real controller (I don’t typically) –To get around this, the Component Controller can tell the Window Controller to fire plugs provided you include it as a reference in the Component Controller.
  • It’s kind of annoying that if you want to reuse one interfacing component in another component multiple times, that the node structure can’t really be more than 1 deep as otherwise you need to map to new nodes within the Component Controller.  i.e. The underlying code makes the Node Name specific, henceif you had NODE1 and NODE2 and mapped an interface node to each NODE but the node you were mapping had child nodes; you would need to map these separately (or something like this).
  • WDDOINIT of the component controller is correctly called prior to the Window DEFAULT plug, but this means if you have parameters passed within a URL; you cannot initialise much in WDDOINIT. (solution is to call an initialise method from the default plug on the Component Controller)


So what’s this all about MVC…

Well my understanding of MVC is that the Model is separate from the View, and the controller controls what data is retrieved from the Model plus what view to display and what model data to pass to the View.

So first I was thrown by the fact that WDDoInit is called without any application context information except sy-uname that’s running the application (as per my last point above). So this got me to thinking…For a component that is not going to be interfacing to another component, the Window Controller is actually more powerful than the Component Controller.  Now because I have the WD4J background,I’m going to assume that I’ve missed the point somewhere, and I’m still going to focus on the Component Controller being my main controller. 

Unfortunately, from an MVC perspective, the controller is more than what the Component Controller can do as I cannot navigate directly from it to a different View.  I could fire an event and asynchronously tell a view to fire a plug (which is not a good idea); pass parameters back from methods called by the View (also not great) or I could call a method on the Window Controller to fire a plug.

If I do the latter, I would consider the Component Controller and Window Controller as one (A perfect match made in Waldorf).

So what does this look like:

WDDOINIT of Component Controller – Initialises anything global looking that requires initialisation.

Start plug of Windows Controller – This calls method on the Component Controller to initialise the model data and navigate appropriately.

All navigation gets initiated by the Component Controller by calling an appropriately defined Window Controller which fires it’s own outbound plug to change views. Note – There will be exceptions to this especially if you just want a basic navigation from one view to another like in a tab control or something but in this scenario, I would consider the View Controller as a mini controller quite capable of performing these types of tasks.

Main context is all stored in the Component Controller. The Window Controller just handles navigation and entry points to the application.

Anyway, that’s the gist of it.  I’m really hoping for someone from SAP (Thomas perhaps – hint hint – Congratulations on the birth of Ryan Thomas Jung again) to conduct a “best practice patterns” style presentation covering the best “typical” approach to things like larger WD4A applications, but this is my short version of it for now that I’d love to hear from others how they maintain the MVC pattern within WD4A.

Thanks all who got this far and hopefully see you at SDN Day in Brisbane next month or at Tech Ed Phoenix.


You must be Logged on to comment or reply to a post.
  • Hi Matt,
      I try to adopt the MVC pattern as much as possible too.
      I had the opportunity to develop some relevant WDA applications and at the begin I tried to find the “suggested” MVC pattern.
      I often say that SAP build TOOLs (e.g. WDA) and APPLICATIONS(e.g. ECC, SRM) and I try to develop custom applications in the same way as SAP does.
      Before defining “my way”, I studied a lot of standard WDAs but to be honest until SAP ECC EhP3 I found nothing I liked so much.
      They were basically BIG WDC (several views and few component reutilization) with BIG Component Controller (large Component Controller methods and few Model Classes).
       In these days a colleague is just implementing SAP ECC EhP4 and I’m looking forward to studying the new WDAs.
      I’ll also soon have the opportunity to login into a SAP SRM 7.0 that is WDA based.
      What I would add to your considerations is that the Web Dynpro Wizard is really very very powerful but unfortunately it implements everything in the Web Dynpro Component itself (e.g new methods in custom controllers, new context node, new statements in local methods and so on) and probably it’s not so MVC oriented.
      The most important consideration is indeed related to FPM – Floorplan Manager. It’s the new and strategic way to implement WDA. At the beginning it’s a bit complex but it add new options in terms of flexibility, modularization and configuration.
      You should try FPM (available since NW 7.01) and even if your considerations will be still important, you should reallocate them to the new abstraction layer.
      Personally, within the large WDA projects I’m conducting, I instructed my team to implement as less code as possible within WDC. Instead we define and implement the MODELs as classic ABAP OO Classes (SE24) to represent the Business Objects (Customer, Invoice,…) and we save into WD Assistance Class the instances of the MODELs (ABAP OO Classes). We specialize the MODELs via new Classes to add some functions dedicated to Web Dynpro (e.g. context management) or we implement specific methods into the assistance class (also for the multi-language feature).  So all the modules of the WDC (and even the subcomponents via shared Assistance Classes ) access the MODELs via an attribute of the assistance class (e.g. wd_assist->customer->get_id( )). In my team, we accept to lose some interesting features of the WD Wizard to stay more aligned to MVC or to say better we use the wizard as a starting point and then we cut&paste pieces of code auto generated code in the right module of MODEL.
      Some of the main benefits are: the possibility to use powerful ABAP tools like (Search/Replace), Code Inspector, Easy Test from SE24 of each method without going trough the whole application, where-used-list that within a WDC work with some restrictions.


    • Thanks for the detail Sergio.

      FPM is available to me and in all honestly, is something I haven’t looked into too greatly.  My understanding of FPM is that it’s quite a specified UI style (which is standard), but my requirements have been quite specialised.  That said, I need to research FPM more and get my hands dirty with a demo to understand it better.  Unfortunately, is a little wordy for learning this (more pictures please) and no one has really produced a “how to from scratch” guide to accelerate my learning but hopefully I can pick this up.
      And in terms of OO classes, you’re talking my language, and that’s how I’ve done it too.  Though I do admit to letting my OO classes return GUI structures sometimes for simplicity/performance reasons (I’m not an academic when it comes to OO).
      Oh – And the wizard…Well I’m looking forward to 7.02 for statement chaining as I always seem to be cleaning up my code after I use the wizard (removing redundant element tags for example).
      Thanks again for the feedback,

  • Hi Matt,
    I too have been looking for a pattern for business logic accessing when developing larger webdynpro applications, looking at SAP applications for guidance my findings are

    – the lean sales order application “lord_maintain” uses a faceless component which facades the model logic (CL_LORD_MODEL_ADMIN).

    – the travel expense application “FITE_EXPENSES” – the FPM controlls component usage and application parameters allowing data to be shared between components, on the whole the
    assistance class is used for sharing class data and manipulating the screen ui elements.

    After reading the FPM Cookbook it looks like the Shared Data Component is a standard
    approach but does that mean that we are to create faceless components for separation of concerns.


  • Hi Matt,
    Thanks for sharing your insights. It’s nice to see that others, too, are still trying to get the best grip on how and where to cut when using Web Dynpro. 🙂
    This is what I try to do:
    * Make the WD layer thin, it should be a pure UI layer. Business objects and business logic should not be implemented in a WD component, they should only be *used* there.
    * Encapsulate the model and the technical details of accessing at least it in a faceless component within the same WD development component (WD4J).
    * If reuse of the faceless component is the least bit likely or the application is large enough to justify further modularization, give it a WD development component of its own.
    * Design the component interface (especially the context) of the faceless model component with the needs of the consuming component and view controllers in mind. Avoid showing details of the technicalities of how the model is accessed (REQUEST_blababla nodes).
    * Follow the MVC pattern. Keep views clear of process and business logic, keep the model component clear of UI knowledge, and have the main component controller broker between them or “pull the strings”.
    * Assume that views will be used in different screen layouts. Give them clear interfaces and make them as agnostic of their environment as possible.
    * Keep the window controllers as lean as possible. They are between the component controller and the view controller and can often remain empty. But if knowledge about navigation and different layouts must be programmed, put that into the window controller.


  • It looks like I may not be too far off the mark based on everyone’s comments and it’s great to get other people’s approaches (which are all fairly similar).

    Note – I’ve just remembered the FPM document that was published not long ago (which doesn’t come up in the search) so I’ll give that a read and see if that changes my thinking.


  • Hello,
    while working on a problem with WebDynpro for ABAP i stumbled over your blog entry (
    I was lucky, because you experienced the same problem like me.

    It’s kind of annoying that if you want to reuse one interfacing component in another component multiple times, that the node structure can’t really be more than 1 deep as otherwise you need to map to new nodes within the Component Controller.  i.e. The underlying code makes the Node Name specific, henceif you had NODE1 and NODE2 and mapped an interface node to each NODE but the node you were mapping had child nodes; you would need to map these separately (or something like this).

    We have to use a web dynpro component multiple times in our target web dynpro component. The Context of the muliple used component is hierarchically structured like this:

    |  |
    |  |->SUBNODE_1
    |  |  |
    |  |  |->SUBSUB_NODE_1
    |  |  |  |
    |  |  |  |->ATTRIBUTE_1_1_1
    |  |  |  |->ATTRIBUTE_1_1_2
    |  |  |->SUBSUB_NODE_2
    |  |  |->SUBSUB_NODE_3
    |  |  |->ATTRIBUTE_1_1
    |  |  |->ATTRIBUTE_1_2
    |  |->ATTRIBUTE_1
    |  |->ATTRIBUTE_2
    |  |->ATTRIBUTE_3

    It is not possible to map the context node (NODE_1) of both used components in the target component. Renaming is only allowed for the root node. But there are still naming conflicts with the child nodes.
    Also mapping each child node seperatly and renaming it doesn’t work, because WebDynpro seems to have a bug in this case.
    When changing the lead selection of the mapped NODE_1, it does not affect the data stored in the subnodes. So in the subnodes there is still the data belonging to the old lead selection.

    Do you know or have you found a solution for this problem? Is it really not possible to use the same web dynpro component multiple times and mapping the hierarchically structed context?

    I also opened a thread in sdn for it:

    • Hi Florian,

      Unfortunately, I didn’t do extensive investigation to try resolve this though it was obvious the meta data used meant there’s no easy solution.  I just went with a flat structure which was annoying but it did the job.  Maybe name your flat structure in a hierarchical way to at least make it readable?

      Good luck,