- Issue description
- Issue analysis
- 1. I could reproduce this issue in my laptop with my colleagues’ user
- 2. compare the final native html source code
- 3. Use mini-system approach to isolate and locate root cause
- 4. Debug the nutshell
- 5. why I could see entries with my own user?
- 6. Why the native HTML source code is different based on different personalization setting?
Today I received a ticket with priority very high complaining that the drop down list for Business Role in Work center “Sales Operation” is empty:
However, Using my user I could indeed see lots of drop down list entries there:
I didn’t start debugging immediately but made the following analysis beforehand:
1. I could reproduce this issue in my laptop with my colleagues’ user
Based on this finding I made the following comparison between my colleague’s user and mine:
a. compare the authorization settings:
result: The two are exactly the same ( both copied from the same user group and we didn’t have authorization to make changes ).
Also there is no corresponding entries found in SU53 when I test with my colleague’s user.
b. compare the user parameter in tcode SU3
result: no difference found related to this issue
c. compare the business switch setting
result: the same setting for both user
2. compare the final native html source code
I do believe there must be differences when the page is rendered via different users. So I use the development tool ( click F12 ) in IE, and soon found the difference:
This one is the html source code generated by my user and it works perfectly:
And this below is the one generated by my colleague’s user. The title are completely missing!
3. Use mini-system approach to isolate and locate root cause
Since this issue occurs in CRM Organizational Model management and the underlying business model is huge and complex. In this situation I always prefer to use mini-system approach I described in this blog to try to make the issue also reproducible in the small nutshell. At least I could have the following benefits from the nut shell:
a. the nut shell could eliminate all impacts from unrelated components so that I could concentrate on the key part of program which might lead to the issue
b. the nut shell makes debugging be more efficient. For example sometimes I have to debug how does webclient framework class reacts to my input for my UI component, the method is so generic so that it would be triggered too frequently( like method PROCESS_NAV_QUEUE of class CL_BSP_WD_VIEW_MANAGER, which have helped me to resolve many issues 🙂 ). Using nutshell I do not need to press “deactivate all BPs again and again.
I just spent 5 minutes to build a nutshell, which contains a view, a value node and one attribute. The attribute contains GET_V and GET_P method whose source code are copied from standard Org management UI component.
The nutshell in the runtime looks like below. The issue could be reproduced within it by using my colleague’s user.
4. Debug the nutshell
When I debug the GET_V, I soon found the root cause:
The following code plan to retrieve profile and description from table crmc_ui_prof_t:
profile will act as drop down list key and description as drop down list value:
Unfortunately between profile and description column in table crmc_ui_prof_t there is another column LANGUAGE:
As a result the select statement does not work as expected at all. The SELECT xxx INTO CORRESPONDING FIELDS OF TABLE must be used instead.
5. why I could see entries with my own user?
First of all, the entries displayed with my own user are not correct at all, they are just the wrong entries populated in internal table LT_ROLES, column PROFILE in screenshot above. In the wrong implementation, only drop down list key is filled with the incorrect entries.
For my user, I have enabled that key will also be displayed in dropdown list, so I could see the incorrect keys in UI. However my colleague didn’t enable this so he could only see nothing there, since the drop down list value is not filled due to wrong implementation.
6. Why the native HTML source code is different based on different personalization setting?
Why my user could see the not initial title attribute in native html source code but my colleague’s user could not?
It is related to your personalization settings regarding whether dropdown list key must be displayed or not.
Just set a breakpoint on method CL_THTMLB_PERSONALIZATION~GET_DDLB_KEY_MODE, start the nutshell.
It stops at the place where the drop down list UI element is to be rendered. The callstack is also very helpful if we would like to study how the UI element defined by SAP tag like chtmlb, thtmlb is finally converted to html source code.
This setting is evaluated here and populating drop down list entries accordingly:
All the entries to be displayed in drop down list is available in the current callstack: