cancel
Showing results for 
Search instead for 
Did you mean: 
Read only

Url Iview - Automatic Height problem

Former Member
0 Likes
441

I'm having a problem using the automatic height option with a Url Iview. It seems that the only way this option works is when the Url for the iview points to the same domain as the user's browser--in this case, since the browser is pointing at the portal instance this means that the url has to be pointing back to the portal server in order for the automatic height to work.

I believe this is a javascript security restriction when trying to resize the iframe on a different domain. I've scanned SDN documentation for any references, and found the following suggestion referring to iViews made from BW templates:

<b>"</b> <i>The automatic height function will not work because there is no domain resolvment done in that case (The BW Reporting Agent is not portal aware) and therefore the browser is not able to access the iframe for changing its size.

However it will work if you add javascript for resolving the domain to their web template.

<script language="Javascript">

var lsDomain = "";

var liBehindFirstDot = location.hostname.indexOf( "." ) + 1;

if (liBehindFirstDot > 0) document.domain = location.hostname.substr( liBehindFirstDot );

</script></i><b> "</b>

Could this approach work for my Url Iview issue? Can I make a new template from the current Url Iview template (so not to affect the default Url Iview template)?

Any help or suggestions would be appreciated.

Thanks,

Curt

Accepted Solutions (0)

Answers (3)

Answers (3)

Former Member
0 Likes

Hello Curt,

I face exactly the same problem. In addition, I'm not able to change any sources of the target application. So I would appreciate very much if you can send me your embedded iview workaround. I will reward you with as much reward points as possible.

Much thanks in advance,

Elmar

Former Member
0 Likes

Hello Detlev,

I hope you still watch this topic!

I have a similiar problem: I want to use the automatic height with url iviews pointing to pages on the same server and if possible avoid to add the JS to every page.

If I understood this right, the problem in my case is, that the portal relaxes it's domain let's say from server.sub.top.de to sub.top.de and the HTML-Pages are still on server.sub.top.de.

Is it possible to keep the portal from relaxing it's domain completeley or for one page? Then both would be on same domain again and the portal could access the pages's properties.

Thanks and Greetings,

Reinhard

detlev_beutner
Active Contributor
0 Likes

Hi Curt,

several points:

(a) Use the

Code

button instead of the italic button for code; makes it much more readable.

(b) Line <i>var lsDomain = "";</i> is superfluous.

(c) It only works if portal is in domain a.b.c and the integrated domain is x.b.c.

(d) The JS part has to be within the integrated HTML.

(e) Please reward points for helpful answers, also see your thread

Hope it helps

Detlev

Former Member
0 Likes

The issue seems to be caused by the fact that the call to

EPCM.relaxDocumentDomain()

inserted into the page by the pagebuilder component only relaxes the domain to that portion of the hostname following the first dot.

We utilize domain names as follows: servername.location.country.company.com

Ideally, we need to set the document domain, leaving only the last dot--domain="company.com"

I've found a temporary workaround, which is to add an embedded iview to the bottom of each page, that simply sets the document domain as required above. Is there a better / more permanent option? Are there any configuration options in Portal that can control the level of domain relaxing that occurs?

Thanks,

Curt

detlev_beutner
Active Contributor
0 Likes

Hi Curt,

(a) This sounds like a tricky workaround if you don't have access to the original sources. If you have, you should add the domain relaxing code within it.

(b) Please reward points for helpful answers, also see your thread ... (second try)

Regards

Detlev

Former Member
0 Likes

Hi Detlev,

I think maybe we're misunderstanding each other a bit here.

I have no problem modifying the source (and thus controlling the domain) of the resources that my Url iViews point to (the content rendered inside of the iFrame).

My problem is with the page that contains the individual Url iViews. Pagebuilder, when rendering the page and the iFrames pointing to my Urls, initially adds a call to

EPCM.relaxDocumentDomain()

to the page before rendering the iViews. This relaxing will only relax to the portion of the hostname after the first dot.

Example. My Url iView points to http://server1.location1.us.company.com/someResource. The Portal page url may be something like http://server2.location2.us.company.com/pcd/paths/par/etc. I can control the domain that the Url iView points to, making the domain any portion of the hostname. Let's say I alter the domain of the URL resource from server1.location1.us.company.com to company.com. The most relaxed domain I can get from Portal/Pagebuilder/EPCM.relaxDocumentDomain() is location2.us.company.com. The automatic height adjustment javascript attached by Portal to the iFrame for my Url iView (domain = company.com) will not be allowed to change the height because of domain differences (location2.us.company.com vs company.com).

My temporary solution of adding an embedded isolation mode iView to the page, which simply adds javascript to alter the page domain, seems to work. However, I'm wondering if there is a better, more robust solution to what I'm trying to do. Is there any way within the Portal configuration, perhaps, to control the level of domain relaxing that the EPCM javascript performs? Or, is there another option?

Thanks for your help,

Curt

detlev_beutner
Active Contributor
0 Likes

Hi Curt,

ok, now I've also got the rest of the story.

(a) The topic is known for BSPs inside EP - but only from the BSP side, see http://help.sap.com/saphelp_nw04/helpdata/en/28/7c383f717b5f03e10000000a114084/frameset.htm

(b) An approach could be to edit the JS of EPCF.relaxDocumentDomain() to do a maximum relaxing as described in the link given. At a first glance, this shouldn't produce additional problems.

(c) As usual, third try (even if <i>this</i> thread didn't help you 'til now, the other should have?!)

Hope it helps

Detlev