Firing plug shows wite content area

[michael_voss2]

Hello everybody!

Currently we encounter a strange problem in one of our WebDynpro applications. When a certain user clicks on a button that fires a plug to navigate to another view, the contet area gets white and nothing else happens. This happens to this user only, it happens whenever the navigation t a certain view is triggered. For every other user, this navigation works perfectly, even with the same data loaded. Another user experiences similar behaviour when navigation to another view; again, for every other user the navigation works fine.

When entering any view, we check if the user is member of a certain UME group. But this check is performed identically (for the same UME group) in every view and that works fine in every case except for those two user-view-combinations.

Did anyone come across something like that or have any idea on what might be going wrong ? I'd happily supply any information necessary...

Thanks

Michael

[ErvinSzolke · Accepted solution]

One addition: if the end user faces this behaviour using IE, did you check the compatibility mode of the browser?

[michael_voss2 · Accepted solution]

Hi Ervin!

Thank you for your hints. Usually, we use IE9 only, the WebDynpro version is 7.31 SP 13, my basis team will inform me about the patch level. I'll make the users check with another browser and with deleting the browser cache. I'm going to post again when I have more information.

Michael

[michael_voss2 · Accepted solution]

Compatibility mode is off in IE and the browser does not show any compatibility issue when working with this application os when the white content area is shown.

We'll have another look at our coding...

Thanks

Michael

[christian_santej · Accepted solution]

hi michael,

just to be clear -  you've also checked the version of the endusers browser (working and not working one) if one uses the 32bit and another one the 64bit version?

a couple of months ago we had some displaying issues in our WD applications and in the portal itself. the issue was layout related - to be precise the matrixlayout. we have opened an OSS and the final solution was the sap note 2040655 mentioned by ervin earlier.

in our coding the following combination caused a blank screen/section: if an UI container element (group or transparent container) with layout = MatrixLayout and attribute stretchedHorizontally = false AND it only has one direct child element added.

regards,

christian

[michael_voss2 · Accepted solution]

Hi Christian!

Thanks for your reply. Since all users are working under Citrix on a Windows Server 2008, the are all using the same IE version (32bit). The other checks I mentioned earlier were performed using Windows Server 2008, Citrix, all browsers with their 32bit versions, or Windows 7 Professional 32bit, all browsers with their 32bit versions. The deletion of the Windows profile did not have any effect, the problem occurs with whatever browser the users use.

The problem shows up in two views, one having a TransparentContainer with GridLayout as root element, the other a TransparentContainer with a FlowLayout, both with one Group as only child. But this combination works fine for all users except one in each case.

Do you know if there is a built-in way to check if there are circular relationships in UME or portal roles ? Or does UME check that when groups or roles are persisted ? We once had a similar problem on a .net Windows desktop application with a circular reference in our Active Directory.

Thanks

Michael

[ErvinSzolke · Accepted solution]

Hi Michael,

reading all the posts I am kind of running out of idea.

I only would like to reflect to what you asked last time about circular dependencies. I remember that if you logged on to DTR webui with a user that had circular dependency issues then DTR crashed with StackOverFlowError. Just a hint, crossed my mind when reading your post, I cannot guarantee it'll really work, and if yes, this is only to figure out whether circular dependency exists. How to resolve such an issue I don't know, only the manual way, but in case of a complex group-role-user setup in UME this is not an easy task for sure.

Does the tool in note perhaps able to detect this ?

1016283 - UME Consistency Check Tool

Unfortunately I am not a security guy.

Still I hope it makes any sense.

Cheers,

Ervin

[michael_voss2 · Accepted solution]

Hello Ervin!

Thanks, I'll give the UME Consistency Check Tool a try. And I'm going to build some tool that will be able to detect circular dependencies (starting from an IUser instance) anyway.

Next, we're going to assign a new UME account to those two users and see what happens...

Thanks

Michael

[christian_santej · Accepted solution]

hi michael,

a thought crossed my mind - to rule out an enduser error: the enduser is not able to change the visibility manually by performing a right click on the view and alter (e.g. hide view elements) the user settings?

try to clear the personalization data within the portal of those users and check again ( - the chapter "Deleting the Personalization through Personalization Clean up" also applies for NW7.31)

for investigation reasons - maybe the technical info of the wd application offers some hints. to call/show them press ctrl+shift + right click on the view - a pop-up "Technical Info" should appear.

regards,

christian

[michael_voss2 · Accepted solution]

Hi Christian!

I cannot check with the affected users, but will do that asap and come back with the result. I did not think of that as a possible cause for the problem since in my opinion it's hardly possible to do this accidentally.

Usually, we have personalization switched off at iView level in development. According to the documentation, this setting should be preserved during transportation. I just looked at our production system and can see the personalization menu item in the breadcrumb of the application, so apparently this setting is wrong in our production system.

But anyway, I checked some other applications with personalization switched off at iView level, but I was still able to hide view elements there although the Personalization menu entry was missing. So it does not seem to be sufficient to switch off personalization of this iView in the Content Administrator anyway (which we thought is was, but we never tested that). Where else would I be able to prevent users from hiding whole views? Is there any way to switch off personalization of certain views or view elements at application or view level (maybe in NWDS) ? E. g. I'd like the user to be able to rearrange table columns or hide buttons, but not to hide complete views.

Thanks

Michael

[christian_santej · Accepted solution]

hi michael,

i hope i got your question right ( Is there any way to switch off personalization of certain views or view elements at application or view level (maybe in NWDS) ?):

in our applications, if we do not want the endusers to personalize certain view elements we manage that by setting the certain visbility state of the view element. by default a view element is set to "*visible" which means that an enduser is able to personalize this element (right click user settings). to prevent an enduser to hide certain view elements we set the visibility to "always". programmatically you can still set the visibility at another point/time.

regards,

christian

[christian_santej · Accepted solution]

hello again,

i've talked with my colleague () about your other question.

parameter "AllowUserPersonalization" : "Enables the end user to implicitly configure the Web Dynpro interface, for example to adapt fields or tables." per default this value is set to true.

Configuring the Web Dynpro Runtime Environment - Developing Java Web Dynpro Applications - SAP Libra...

maybe this is of some kind of help too.

regards,

christian

[michael_voss2 · Accepted solution]

Hello Christian!

So I finally learned about the difference between "visible" and "always" (I've been wondering for years). We'll have to change that on a lot of elements in our applications. But anyway...

Until now, I could not get hold of any of my two users to verify if that's the cause of the "error", but until now it's the most likely reason.

Regards

Michael

[michael_voss2 · Accepted solution]

That would influence the personalization for all WebDynpros, which we definitely do not want. But thanks you anyway.

Regards

Michael

[michael_voss2 · Accepted solution]

Hello everybody!

O. k., so today I got the confirmation from one of the two users: After removing the user personalization, the page reappeared. I guess it's the same problem for the second user, too.

We could establish that a right click on any view element is sufficient to show the personalization menu and another klick will hide the root element, so it's two clicks and it's gone.

So thank you very much for your help!

Michael

[christian_santej · Accepted solution]

hi michael,

that's great news - you're welcome!

regards,

christian

[michael_voss2 · Accepted solution]

Hello everybody!

Just as a last followup, I buildt a webdynpro application that visualizes ume group dependencies (including circular ones) starting at some UME group assigned to a user and found no circular references regarding my "problematic" users. Maybe one day this tool will even be able to edit these dependencies (should not be too complicated to add editing capabilities).

Thanks

Michael

[michael_voss2]

Oops... sorry for the title typo, the content area is "white", of course 😉

[ErvinSzolke]

yeah, I figured that out.

[christian_santej]

hi michael,

you've mentioned that you're using IE9/Citrix - maybe the version of your IE9 (32/64bit) is causing the issue. we faced some similar issues where out of the blue applications didn't work for some endusers (problem was the IE9 64bit). also please check with firefox.

regards,

christian

[michael_voss2]

Hi Christian,

I'll have that tested, see my reply to Ervin...

Thanks

Michael

[ErvinSzolke]

Hi Michael,

I assume this is not related to the note 2040655 or is it?

I suspect not because else the issue would be not user specific still this is the note that crosses my mind when I read about blank screen issues.

Else I have only general questions to ask like: I

s the test environment always the same? The user that faces the problem is using the very same browser? Does browser cache deletion make any improvement? Is it reproducible for that user with other browsers like IE , FF, Chrome ?

I hope this helps.

Ervin

[michael_voss2]

Hi!

After a quick check with my basis team, we are using 7.31 SP12, not SP13, with

Component	Version
WD-RUNTIME	1000.7.31.12.5.20140812180300
WD-RUNTIME-EXT	1000.7.31.12.0.20140410205600
WDEXTENSIONS	1000.7.31.12.0.20140411020400

Would that be o. k. ?

I am still waiting for a check against Chrome or Firefox...

Thanks

Michael

[ErvinSzolke]

if it was about that note then everyone would face the problem, and as per the note the fix is available in SP12 PL4 while you have PL5, so that should be ok. From that note's point of view SP13 PL0 is ok too.

[michael_voss2]

Hi!

I had a look at the SCA dependencies of WDRUNTIME12P_11-20007087.SCA, and found that it requires AJAX RUNTIME 7.31 with minimum patch level 6 (ours is 3), FRAMEWORK EXTENSIONS 7.31 with patch level 6 (ours is 3) and PORTAL BASIS 7.31 wih minimum patch level 12, while ours is 7. I'll try to make our basis team install the latest patches on everything, even if that does not help with my problem.

Yes, there are only two users (of about 30 to 40 that use this application) having that problem, each of them when navigating to another view, but the white content area displays everytime these users try to navigate to their "special" view. Clearing the browser cache did not help, and the problem remains even when using Chrome instead of IE9. Both users are working on terminal services (Citrix), currently we are checking if something changes when they use ordinary Windows 7 workstations.

Funny enough, the application initially worked fine for both users, the behaviour changed some weeks ago for the first user and a few days ago for the other one. As far as I know, there was no change in portal configuration, no patches were applied and we did not deploy another version of our application at these times. And this happens on our production machine, only, of course.

Since we are checking UME memberships when navigating to any view, I was wondering if there is a circular reference in the UME group or role definition, but since we are checking for membership in the same group in every view using the same class, I can hardly imagine why this should fail in one view only (and a different one for both users).

Anyway, if anyone might come up with another idea, I'd be grateful...

Thanks Michael

[ErvinSzolke]

I am curious how the app would behave if the end users would access it not via citrix. Can you test that ?

[michael_voss2]

Thanks a lot for your help!

Yes, that's a test I requested a few hours ago. I'm still waiting for a result; since the department uses Citrix only and I do not have access to the users, it might take a while to locate a workstation and make the users try it from there.

We are going to test against IE10 using Citrix and on an ordinary workstation, too, as Christian suggested, but this will take even more time since this is not our standard environment and we'll have to set up a special terminal server and a new workstation profile for that. Maybe we'll even manage to get Firefox onto a workstation to test that, although this might violate our security policies. And I cannot test myself, obviously, since I cannot reproduce the error.

Oh, and IE Compatibility Mode is turned off by default, so I'd guess that the users are not using it, but this still has to be verified.

I'll keep you informed.

Michael

[christian_santej]

hi michael,

thank you for your reply. @ firefox - maybe the portable version will work/is enough (Mozilla Firefox, Portable Edition | PortableApps.com - Portable software for USB, portable and cloud...)

regards,

christian

[michael_voss2]

Hi Christian!

Maybe we'll manage to install Firefox to a workstation; I guess the mobile version might be even more problematic. I'd need an o. k. from our CSO for that.

Meanwhile, I learned that the problem remained when using Chrome on a Windows workstation (not Citrix). Until now, none of the users tested using IE9 on a workstation. Still waiting for more results.

Thanks

Michael

[michael_voss2]

O. k., some more information:

No changes in the behaviour using IE10 or Chrome on another Citrix server, no changes in behaviour using Chrome on another workstation. A test with firefox seems not to be possible without large effort.

Our next try will be to delete one user's Windows profile and see what's happening then...

Any other suggestions ?

Thanks

Michael