In this blog I will demonstrate how I resolve the error message “endless binding loop” raised by UI workbench. I would not emphasize the issue itself, but would rather share with you how I would deal with such error messages raised by UI workbench in my daily life.

The issue is we have the context node PARAMS defined in component controller, which is bound to node with same name defined in view LogView02.

However, the node in view LogView02 is again set to be bound to the node in component controller by mistake, leading to an endless binding loop ( A is bound to B and B is also bound to A ). So the error message is raised by workbench. I planned to use the context menu item “Delete binding” to delete the binding from component controller node to view controller node, but there is no such context menu item available on the errorous context node.

So I go through the following trouble shooting process:

/wp-content/uploads/2014/02/clipboard1_397522.png

1. find where the error message is raised by workbench

This is quite easy, just click on the red icon of the error message, and we get required information on the technical help: message class id BSP_WD_TOOLS, message number 082.

/wp-content/uploads/2014/02/clipboard2_397538.png


Go to tcode SE91, use where used list on that message, only one hit in below method.

/wp-content/uploads/2014/02/clipboard3_397539.png

2. figure out why the error message is raised

Set a breakpoint on the method found in step1, go to UI component workbench and double click on component controller again, breakpoint is triggered.

Now we get to know the error is caused by the failed internal table insertion done in line 12.

/wp-content/uploads/2014/02/clipboard4_397540.png


The insertion failed because a duplicate record is tried to be inserted to the internal table while the record with the same key( cnode_name and cnode_class ) already existed there. This duplicate record just represents the wrong data binding from component controller context node to view controller context node, which is what we expect to delete.

/wp-content/uploads/2014/02/clipboard5_397544.png

3. figure out why the duplicate record is created

It is expected that the duplicate record in step 2 should never be created, so it is necessary to find out where it is being created. We have to go to the outer callstack of the record insertion, that is callstack layer 22. Now we know the generation of the duplicate record is caused by the evaluation of variable lv_target_controller_class in line 83.

/wp-content/uploads/2014/02/clipboard6_397545.png

4. figure out why the binding target controller class is not initial

from the method get_cnode_type in step3, we know the lv_target_controller_class is filled by CL_BSP_WD_APPL_MODEL~GET_CNODE_TYPE.

We are now quite near to the issue root cause: if we find out how the UI workbench determines the binding relationship, we should then know how such relationship is maintained or determined. Based on the finding we will finally know how to delete the wrong relatinship.

Set a breakpoint on the method and restart the workbench again and navigate to component controller:

/wp-content/uploads/2014/02/clipboard7_397546.png


Now workbench is loading the source code of method CREATE_PARAMS of component controller context node PARAMS’s implementation class and stored it into internal table LT_SOURCE.

/wp-content/uploads/2014/02/clipboard8_397550.png

Have you noticed the hard coded string ‘DO_CONTEXT_NODE_BINDING’ in line 46?

/wp-content/uploads/2014/02/clipboard9_397551.png

5. figure out where and how binding relationship is maintained by UI workbench

Final finding: everytime we define a context node binding, UI workbench will automatically generate the following code ( starting with owner->do_context_node_binding )in method CREATE_<context node name>. When UI workbench is displaying the context node, it will locate that hard coded string and get the necessary information by parsing the source code ( via ABAP keyword SCAN ABAP-SOURCE ).

/wp-content/uploads/2014/02/clipboard10_397552.png

/wp-content/uploads/2014/02/clipboard11_397553.png

after we delete the automatically generated code for wrong binding on context node ( line 16 ~ 23 ) in method CREATE_PARAMS, the endless binding loop is resolved.

Summary

my favourite way to deal with message raised by UI workbench:

find out where the message is raised -> find out why the message is raised -> find out the wrong setting / development object which leads to the message

-> correct the mistake.

To report this post you need to login first.

2 Comments

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

  1. siva 9533

    Wow Great explanation and it worked. I just want to add few easy steps to simply the above logic ( I am using above concept only but making it simply) .

    1. Run the report program RS_ABAP_SOURCE_SCAN  by entering context node name in String searched = PARAMS .( you have to enter your own context node)
    2. Execute -> 
    3. in result search with CREATE_PARAMS ( ).( Here instead of params enter your own context node)
    4. in that method delete line number 16 to 23.

    Thanks & Regards,

    Siva Krishna

    (0) 

Leave a Reply