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 erroneous context node.
So I go through the following trouble shooting process:
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.
Go to tcode SE91, use where used list on that message, only one hit in below method.
2. figure out why the error message is raised
Set a breakpoint on the method found in step 1, 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.
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.
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.
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 relationship.
Set a breakpoint on the method and restart the workbench again and navigate to component controller:
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.
Have you noticed the hard coded string 'DO_CONTEXT_NODE_BINDING' in line 46?
5. figure out where and how binding relationship is maintained by UI workbench
Final finding: every time 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 ).
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 favorite 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.
- SAP Managed Tags:
2 Comments
