We use a custom ABAP web dynpro application that makes use of the data and object provider (OADP) component OBJECTDATAPROVIDER:
This component provides the functionality to search for and display an HR org unit hierarchy. In the screen shot above, the hierarchy is displayed as a tree on the left and a customizable grid appears on the right to display selected columnar information.
We recently had a problem where one user was not seeing the organizational structure tree, in fact the entire navigational area was not displayed on screen, what that user saw was this:
The user needed to see the navigational tree in order to be able to select HR objects, and without this functionality the application wasn't of much use.
Interestingly we had a similar user in the same organizational unit with a similar profile who was able to see the navigational tree. The usual first suspect in this case would have to be user authorizations, but in this case there were no authorization failures which was confirmed by an ST01 authorization trace.
So, as many developers do, I set about debugging the system extensively. However, the problem was an insidious one as a side-by-side comparison of the component calls in the debugger for both a working and not-working user showed identical code execution of the components. Looking at just the call to the OBJECTDATAPROVIDER component, the MODEL and UI-settings were exactly the same, and the same NAVIGATIONVIEW and EXPLORERVIEW methods got called.
At first the problem did not seem to be one of personalization, or at least not one of portal personalization (this application normally runs within the portal). Calling the web dynpro application directly in the browser showed the same problem. And although it was obvious that the grid of the object and data provider could be personalized by clicking the "settings" hyperlink on the far right, this personalization seemed to only apply to the ALV grid:
There didn't seem to be anything else that was obviously clickable that the user could have clicked to personalize the web dynpro application.
However, this was indeed a case of personalization, which only became apparent after performing an SICM trace of the application. For the problem user, the personalization class CL_WDR_P13N_UTILITIES was being called differently. Debugging how this class was being called, it became apparent that user personalization (not admin personalization) of the ABAP web dynpro component had taken place. This personalization was stored on table WDY_CONF_USER.
There were two ways in which we could remove this personalization:
(1) Remove the user personalization that was made, or
(2) Restrict the personalization that is allowed on the web dynpro component (Edit->Configuration Data)
The latter option was not really available for us in this situation, as it would have involved an unnecessary modification to the OBJECTDATAPROVIDER component. And, removal of the user specific authorization by directly deleting the table entry in WDY_CONF_USER also was not possible, as this table is delivered restricted so that it may not even be viewed in SE16.
What was the solution then? In this case we performed the usual obscure method of holding down Control and Right clicking on the component in the browser. A hidden context menu opened up which allowed for the restoration of non-visible UI elements.
So, bear this in mind in future before reaching for the debugger. Try control and right click FIRST to determine if either user or administrator personalization may have taken place.
Certainly, it would help in diagnosis if there could be some sort of visual indication on screen that personalization of a component had taken place, and this might be something worth recommending to SAP.
2 Comments
