Sie sind auf Seite 1von 6

Tips for Developing


Developing automated test scripts for WDK based applications such as Webtop,
DCM, Webpublisher and your custom applications can be quite challenging,
due to the complexity of the WDK.

This document outlines the best practices, top tips and common pitfalls as learned
by the engineers in Documentum’s Performance and Capacity Planning group
during the development of our own internal benchmark scripts and utilities.

Chase Harris
Sr. Staff Engineer

Tips for Developing WDK/Webtop-based Benchmarks

1. URLs change depending on your current location

The URL to show the inbox is different depending on whether you are in Streamline or Classic
mode, whether you are currently displaying your home cabinet or subscriptions view.
For example, the URLs to open the inbox by clicking on the tabbar from the streamline home
cabinet view are:
POST: /webtop/webtop/streamline/tabbar.jsp

POST: /webtop/webcomponent/navigation/homecabinet/homecabinet_drilldown.jsp

And the URLs to open the inbox by clicking on the tabbar from the streamline subscriptions view
POST: /webtop/webtop/streamline/tabbar.jsp

POST: /webtop/webtop/streamline/streamlineview/subscriptions.jsp

For the most flexibility in your benchmark kit, modularize the operations an always have
each operation return to a “central” location, such as the user’s home cabinet or inbox as
the final step of the operation. Each operation will also start from that same location.
This will ensure that virtual users can perform the actions in any order or combination.

2 of 6 6/10/2004
Tips for Developing WDK/Webtop-based Benchmarks

2. Each Frame has a different __dmfRequestId value to track

For example, in streamline view:


Content Area=__clientId6


Be sure to parse each page to retrieve the __dmfRequestId values for that frame, and store
them in different variables for substitution in later URLs.

3. The error “Configuration Base has not been established” is almost always
due to errors with __dmfRequestId values.
The value may be old (used in a prior URL), null or from the wrong client number (frame).
Never hard code dmfRequestId values in URLs.
Use the text in the previous pages to identify what the issue might be.

3 of 6 6/10/2004
Tips for Developing WDK/Webtop-based Benchmarks

4. Identify and process page redirections appropriately

Many jsp pages return a new page with embedded framesets or onLoad redirects. You must
parse the page to retrieve the next URL, which will be presented as:
For example, on login with:

The next page contains:

function onLoad()
var strUrl = new Object;
strUrl.src =

This in turn returns:

<frameset rows='0,38,*,30' frameborder='0' border='0' framespacing='0'

<frame name='timeoutcontrol' id='Main_timeoutcontrol_0'

rol_0' marginwidth='0' marginheight='0' frameborder='0' scrolling='no' noresize/>
<frame name='titlebar' id='Main_titlebar_0'
title='Title Bar Documentum Webtop' frameborder='0' scrolling='no' noresize/>
<frame name='view' id='Main_view_0'
ew_0' title='Streamline View. Use column header links to sort files' frameborder='0' scrolling='no'
<frame name='status' id='Main_status_0'
title='Status' frameborder='0' scrolling='no' noresize/>
In both cases, the next URL will be retrieved via a GET, not POST HTTP request, so they will be
easy to identify in the proxy recordings.
For easiest maintainability, write a script to parse the file and pull the next URL based on a
pattern. If the pattern changes, you only need to modify it in one place, not dozens.

5. When you get “an error has been encountered”, be sure to follow the error
URLs to display the full error.
The stack trace returned will often highlight the root of the problem and is vital for debugging

4 of 6 6/10/2004
Tips for Developing WDK/Webtop-based Benchmarks

6. Content Transfer Download (ie View/Checkout) can be easily simulated

By moving the content transfer location on the app server to a location that can be URL
addressable, you can easily download the properties XML file and content file to the client. This
location is app-server specific, and can be modified in wdk/app.xml.




The URL to download the content would be:


7. The Content Transfer Applet for uploading content cannot be

programmatically simulated without some re-engineering.
With each release, changes to the content transfer applet will likely break your benchmark scripts
for Import, Check In or any other operation that pulls content from the client to the application
Plan for this when upgrading your WDK/Webtop based application if you plan on performing
additional performance tests.
Non-applet content transfer upload is planned for future versions of WDK which should simplify
the scripting of these operations.

8. Use the Proxy Recorder tool to get the exact URLs and expected content
for each operation
The URL sequence, actual returned pages and HTTP header information returned by the Proxy
Recorder is extremely useful for debugging purposes.
This tool is available on the Documentum Developer website.

5 of 6 6/10/2004
Tips for Developing WDK/Webtop-based Benchmarks

9. Where possible, parameterize the following variables:

− Host
− Port
− Docbase
− User ID prefix
− Password
− Application root (ie. /webtop, /mywebtop)
− Navigation structure (ie. Root cabinet for navigation testing)
− Object Type name (for properties, viewing and other URLS that pass the type name

10. The state of an object determines the actions and controls that are
available for the object
Therefore, an unlocked object will have different options available than an object that is locked by
you, and an object locked by you will have different options available than an object that is locked
by someone else.
Be sure that your kit can randomly select documents for a given action based on a known pattern.
For example, the checkout operation should only choose documents that are currently unlocked.
The checkin operation should only choose documents that are locked by the current user. Use
the proxy recorder output to identify the pattern indicating the correct “state” for the version you
are testing against, and be aware that the pattern may change with each release.

11. For Checkout and Checkin operations, or operations that change data
(such as modify properties, perform workflow or inbox tasks) avoid
problems by having each user use their own “area”, such as their home
If documents to be checked out are located in a central location, the likelihood that two users in a
multi-user test might try to concurrently checkout the same document is fairly high. By separating
them (ie. Having each user checkout documents in their home directory only) you can avoid this

6 of 6 6/10/2004