Skip to Content

Imagine a purely abstract situation. You are displaying a list of your customers, received by calling BAPI_CUSTOMER_GETLIST function module. On the list you want to have a special column containing a checkbox which is checked if customers phone number is the same as their fax number.

The first thing one does is creating an adaptive RFC model. After that, the next obvious thing to do is bind the Context of the Controller to the Model. The Context of the Controller looks like this:


The next obvious thing to do is to bind view Context with the Controller’s and apply table template to the view. But it is not so easy. The BAPI does not provide explicit information whether the phone and fax numbers are identical. You can of course write your own function module wrapping the BAPI and providing the required data or extend the BAPI. Still, you probably won’t get more than a TextView inside the table displaying either “X” or a space. Why only TextView – because of the data type that CheckBox requires for the “checked” property. BAPI return tables are converted into set of Strings, and CheckBox requires bindery of boolean node attribute.

The answer for this case is to extend the Context node with some extra nodes/attributes of correct type and fill them with data after executing the RFC Model. The extended Context (it is best to do it inside the Controller) could look this:


The next thing to do is to set properties of the newly created attribute and node

attribute properties:

node properties:

Some explanations

cardinality 1..1 guarantees that there is always one and only one element in the node for one parent element
singleton false – there is a new Object for each parent node, so once the values are supplied by a supply function for a given parent element, the supply function is not called anymore. This way they can be modified and don’t get overwritten

Now you can add a CheckBox to the table and bind the “booleanAttribute” to the CheckBox’s “checked” property. But it won’t work yet. The final step is to implement the supply function. In our case the source would look like this

The supply function is called every time a data for the node was not yet supplied for the parent node. If the node is a Singleton node the function is called every time parent node’s lead selection changes.

Now, you can try to connect all pieces together. If you have little experience in WebDynpro look on the blogs. There are many interesting courses for beginners – ie. Table Handling in WebDynpro by Harsh Chawla would be useful here.

Try to experiment more too – by giving the additional value node other type than boolean – for example Visibility – you could control display parameters of the View. Imagine that you can create a View that can be used as an edit and view form just by changing the readOnly and Visible properties for InputField and Button – and have it’s behavior controlled by just a single “X” in the function module output.

To report this post you need to login first.


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

  1. Former Member
    Hi Marcin,
        “BAPI return tables are converted into set of Strings, and CheckBox requires bindery of Boolean node attribute.” I noticed in the BAPI’s with single character length attributes defined on ABAP side the corresponding models (on the Dynpro side) contained Boolean attributes. Just thought I’d mention it. Nice Blog… a very simple and step by step approach.


    1. Thanks for your information. Might be that specific ABAP Dict. domain gets converted – anyone can check it? ๐Ÿ™‚ My own single-char fields in my function modules got converted to strings.
      1. Former Member

        If your parameters are defined as type FLAG on the ABAP side they are defined as booleans in the Web Dynpro side.

        Hope this helps.

        Gareth Ryan.

  2. Former Member
    Excellent Weblog, Marcin!

    This is not an abstract but a rather common scenario.
    In an application scenario where the business data, the application logic and the presentational directives are decoupled from each other– it becomes critical to distribute the components in an according fashion.
    As in this case, like you correctly pointed out, it wouldn’t make a lot of sense to pass minor conditions that are used for determining output back and forth between the systems. Such a simple condition should be getting evaluated up front (presentation layer) and that is where the technique your Weblog teaches is very helpful.

    Again, this Weblog is very well done.

    1. Hello Vik,

      Thank you for a very interesting comment. Nothing more i can add here. ๐Ÿ™‚



Leave a Reply