In this case the customer complained that some of the pages running in his portal fail to execute when using Chrome.
He got this annoying message:
The portal shell (TLN, DTN, etc.) – was rendered well.
What could the issue be?
The first thing I checked was the value of the Supported User Agents property on one of the pages that triggered this message.
The value should be (MSIE, >=5.5, *) (Netscape, *, *) (Mozilla,*,*) (Safari, >=3.1, *) (MSIE, >=5.5, *) (Netscape, *, *) (Mozilla,*,*) (Safari, >=3.1, *) (Chrome,*,*)
If the (Chrome,*,*) part is missing from this list – the page won’t be rendered in Chrome.
Well, the value for that page was OK.
Now this was getting interesting! What could be the issue then?
The next thing I did was to change the framework page. This specific customer has a custom framework page, and I thought that maybe there was something he had added to the pages in this framework page that missed the (Chrome,*,*) value and caused the page failure. If any object within the page is missing this value the entire page will fail!
The issue was reproduced also in the Classic Framework Page. So it wasn’t an issue with the framework page.
At this stage I raised the log level of the userAgent location to “All”. The location of userAgent is com.sap.portal.portal. I did it through the logWatch. You can learn how to use logWatch here.
In the recorded log I found the culprit! – There was a log at debug level for every UI element which specifies the supported userAgents.
One of the elements was the layout, and the layout didn’t have the (Chrome,*,*) value!
So it was the layout. It didn’t have the (Chrome,*,*) value and it caused the failure of the entire page.
You won’t see the layout object in the Portal Catalog, but you can see it if you explore the page in the PCD Inspector.
So I opened the object through the PCD inspector and there I saw that the property of the layout object was indeed missing the (Chome,*,*) value.
In this specific case it wasn’t only a single iView that wasn’t supported by Chrome, but many of the portal iViews. That meant that the root cause was the layout template object.
You can view the layout inheritance hierarchy by selecting it and clicking the “DL” button in the PCD Inspector:
The layout object inherits the property value from the template, so it should be fixed in the template and it will affect all the objects that inherit from it, unless one of the objects overrides the default value of the template.
After the “SupportedUserAgent” was reset for the layout template – the issue was fixed and the pages rendered well in Chrome.
This blog is the first support case that I document.
The entry point to my support blogs will be from here
See you in my next blog…