Embedding Webtop Advanced Search in an iFrame

A recent client uses a custom web application as a front-end to a mashup of several applications including a database, email, and Documentum. They wanted an easy way to search the content in Documentum, so we installed xPlore.  We were then faced with what UI to use.  As a start, we thought we would simply embed Webtop’s Advanced Search screen in an iFrame in the front-end application. That seemed reasonable, and turned out to be a fairly good solution.  However, getting there took some work.

Ticketed login URL

First of all, we had to figure out how to call the Webtop Advanced Search component from a URL. This wasn’t too tough, the Documentum Web Development Kit Development Guide  discusses this and how to use tickets to seamlessly login as a named user. We soon discovered that the order of the parameters passed on the URL was important, and that the Documentum Web Development Kit Development Guide had it wrong: the user’s ticket must be the last parameter passed.

A correctly formatted URL looks like this:

https://&lt;hostname>:<port>/webtop/component/advsearchcontainer?component=advsearch&docbase=docbase>& username=<username>&ticket=DM_TICKET%3dT0J...

(Thanks to Ryan Chadwick for figuring this out.)

So, to redirect the iFrame content to this URL, we simply added this to the iFrame definition:


Where <%=link%> is the URL specified above. (A lot of JSP and Java was used to acquire the individual components of the URL, like the user’s name and login ticket. The acquisition of these components is way beyond the scope of this post.)

Surprisingly, this simple solution worked for the Adanced Search component. However, it wouldn’t display any results because of the following error:

Message: Access is denied.
Line: 1736
Char: 1
Code: 0
URI: https://<host&gt;:<port>/webtop/wdk/include/datagrid.js

This amounted to some kind of cross-domain scripting error. Solving this problem proved to be a little more difficult.


Using the built-in Internet Explorer Developer Tools (F12), we were able to pin-point the source of the problem.  It is important to note that we were using Webtop 6.5 SP3 P21. The code and line numbers discussed below may vary a bit if you are using a different release.

On or about line 1732 begins the following if block:

if (!isGridHeightSpecified(contElem))

On line 1736 this script tries to access a window.frameElement that doesn’t exist (because we are not running in a full Webtop context). To remedy this situation, we copied the /webtop/wdk/include/datagrid.js file to /webtop/custom/include/datagrid.js and made the following changes to the code block at line 1732.

if (!isGridHeightSpecified(contElem))
// if in a frameset
var inFrame = false;
inFrame = (window.frameElement && window.frameElement.scrolling == "yes");
} catch (ex) {
// If we hit an exception, likely we're in a x-domain iFrame, but we still want to proceed...
inFrame = true;
//if (window.frameElement && window.frameElement.scrolling == "yes")
if (inFrame)
if (g_clientInfo.isBrowser(ClientInfo.MOZILLA))
// This will fail if we're in a x-domain iFrame, but only on Mozilla...
// Save original scrolling value which is going to be used on restore
window.frameElement._originalScrolling = window.frameElement.scrolling;
window.frameElement.scrolling = "no";
document.body.style.overflow = "hidden";
document.body.style.overflow = "hidden";

(Thanks to Mark Jeweler for figuring this out.)

Unfortunately, Webtop doesn’t have a customization mechanism for /wdk/include/*.js files. So even though this code fixed the problem, and we moved the file to the /custom directory, Webtop did not use it, and the error persisted.

URL rewriting

Step three of this process involved implementing a little URL rewriting in Tomcat. The idea was that anytime the server thought it was going to server /webtop/wdk/include/datagrid.js, rewrite the path so it served /webtop/custom/include/datagrid.js instead.  To accomplish this feat, we used the Tuckey UrlRewriteFilter (http://tuckey.org/urlrewrite/). See the website for installation and configuration details.  The most significant configuration we made for this filter was the rewrite rule in the urlrewrite.xml file. This is the rule:

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE urlrewrite
PUBLIC "-//tuckey.org//DTD UrlRewrite 4.0//EN"
<rule enabled="true">
<note>redirect for datagrid.js problem</note>
<from casesensitive="false">/wdk/include/datagrid.js</from>
<to type="redirect">/webtop/custom/include/datagrid.js</to>

(Thanks to maheshg for this suggestion and help. See EDN discusion, https://community.emc.com/message/657942)


Users can now seamlessly search content directly from the front-end application without knowing they are leveraging Webtop to do it.  Too bad it took rewriting some core Webtop code and the introduction of URL rewriting to make it happen.

I have previously stated that I am not a Webtop guy, so perhaps there is a better solution than this. If you have one, I’d love to hear about it. That said, based upon the EDN discussion cited above, it seems like this is perhaps the best solution.  Is this easier/different in Webtop 6.6, 6.7, 7.0?


About Scott
I have been implementing Documentum solutions since 1997. In 2005, I published a book about developing Documentum solutions for the Documentum Desktop Client (ISBN 0595339689). In 2010, I began this blog as a record of interesting and (hopefully) helpful bits of information related to Documentum, and as a creative outlet.

One Response to Embedding Webtop Advanced Search in an iFrame

  1. Pingback: Documentum Login Tickets « dm_misc: Miscellaneous Documentum Tidbits and Information

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: