Archive

Posts Tagged ‘docbases’

kVisia: Product Overview

March 18, 2015 Comments off

Howdy Users and Buddies,

Today I want to share on kVisia, a product that provides the core functionality to automate, control and deliver an organization’s engineering and enterprise business processes to the desktop or Web. It holds the business rules, executes the XML configurations, builds the business forms, and implements the lifecycles that automate an organization’s business processes.

I think the only Prerequisites that you need to know is , Basic concept of client-server applications and Documentum Architecture.

Let me put it in Content Wise for better understanding with a bit of background of what’s there , what’s missing and how this can be achieved.

  1. Abstract

Today the current era is defined by the terms like data, information, knowledge, wisdom etc. and in this electronic world the difficulty to manage data in abundance has begotten many technologies and one of them is the Documentum.

Documentum is nothing other than a Content Management Tool but its vastness and its ability to cater to almost all sorts of data types available are so rich in itself that these days it is widely used. If we undo the Documentum technically then it gives an edge over the Relational Database Management System by not storing only the Meta data but also storing the content in its native format.

kVisia blends with Documentum to bolster the level and depth of automation which can be achieved by the Documentum alone and this is what this document discusses in detail.

  1. Introduction

kVisia comes of McLaren Software Limited and users need to have a license before using it. McLaren is ISO 9001 certified and it has been accredited Independent Software Vendor for Documentum and FileNet. It has got 360+ customers worldwide and it operates from UK, USA and Switzerland.

In fact kVisia is an Enterprise Engineer product that encapsulates best practices and domain expertise. This is a user configurable application consisting of XML files managed by repository and standardized on a single ECM platform. It is also believed to be powered by Documentum.

For better understanding of the kVisia we can go through the following questions and answers that will help one to identify the need.

How does it help me?

Very quickly configure the user interface and deliver it to the Desktop and Web users.

Is it easy to change?

Very easy, configuration files are stored in the Docbase in XML format.

Configurable interface using objects and tables.

Do the configuration files allow me to control inputs?

Very complex business rules can be enforced via the XML files.

Validations at creation, promotion and check in.

  1. kVisia suite

kVisia suite consists of following three components:

  1. McLaren Studio
  2. McLaren_Core DocApp
  3. McLaren_Foundation DocApp

3.1 McLaren Studio

McLaren Studio provides a user-friendly desktop application that allows users to create and edit XML configuration files that will conform to the rules of the Document Type Definition (DTD).

An XML (eXtensible Markup Language) configuration file is a structured file consisting of many elements. Elements are ordered into a tree structure or hierarchy. Elements may have parent or child elements, and may also contain attributes. An element without a parent element is the highest in a tree structure and is called a root element. Not all of the elements will have child elements.

The structure of a valid XML file is defined in a DTD (Document Type Definition) file. The DTD contains the rules that apply to each XML configuration file; these include the definitions of parent and child elements, element attributes, and how each element can be used

The appearance and behaviour of user dialogs can be modified without the need to change programme code simply by changing settings in the appropriate XML configuration file. A definition of the appearance and behaviour of a dialog is referred to as a “configuration”. A common need, however, is to display different configurations under different circumstances. For example, members of different groups may need to fill in different properties on documents, and the document’s properties may change as it moves from state to state in a lifecycle. The definition of such a scenario is referred to as a “mapping”. When you do not want to differentiate functionality between different groups, lifecycles and states, there is a value called {default} that will apply to all circumstances.

The Actions for which dialogs can be defined using an XML configuration file are:

 New

When the user issues the New command, a customized dialog can be displayed. Commonly deployed features include automatic document numbering, interactive project allocation and any additional attributes (optional or mandatory), which may be required to be stored for the document.

 Properties

A customized Properties dialog can be displayed. Fields can be made editable or read-only as required.

 Import

When the user performs an import, a customized dialog can be displayed which may typically employ features similar to those used in the New dialog.

 Copy

When the user performs a copy and paste action, a customized dialog can be displayed which may typically employ features similar to those used in the New dialog.

 QuickFind

For each document type, a search dialog referred to as QuickFind can be defined and viewed by the user in the Docbase through the McLaren menu. The attributes that can be searched on are configurable and search options such as Between, Greater Than, Containing, etc., can be specified.

 3.2 McLaren_Core DocApp

Having installed kVisia you get two sets of Docapps in the Docbase, one is the McLaren_core and the other one is McLaren_foundation. The McLaren_core Docapp is available to the user of a Documentum repository. It is always suggested that one should have the overview of the additional functionality as a result of the deployment of the kVisia before configuring the product to suit the business need.

As the name suggests McLaren_core Docapp provides the basic functionality like New, Import, Properties, Copy, QuickSearch etc to be configured. As discussed above, we use the XML configuration tool McLaren Studio to configure it.

For each Object Type used in the repository, an XML Configuration File can be created and configured to define the appearance and behavior of the various dialogs for documents of that Object Type. The definition of the appearance and behavior of a dialog is referred to as a configuration, and different configurations can be displayed in different circumstances.

3.3 McLaren_Foundation DocApp

The McLaren_foundation installation enables you to deploy a pre-configured implementation of the Core technology which transforms it into a user application specifically adapted to the engineering environment, providing a ready-for-use engineering repository. It deals with the following configurations:

User Roles that is associated with Menu Systems and User Dialogs that are adapted to those roles.

Object Types for documents and folders.

XML Configuration Files that define the content, appearance and behavior of the New, Copy, Properties, Import and QuickFind dialogs for the supplied Object Types in accordance with the current user’s User Role and the document’s lifecycle and state, including pre-configured, automatically generated document numbering.

Check in dialogs which are specifically adapted for each supplied type of engineering document.

Automated document revision numbering that reflects common design practice. Revision numbers start at 0 and the first issued version is 1, the second 2, the third 3, etc. When a document is checked in for the first time, a numeric value is assigned and incremented each time it is checked in.

  1. Traditional – VB (Desktop) Vs kVisia(Desktop & Web)

Following Comparison lets you know how much flexibility kVisia provides and how much time and effort it saves.

Traditional – VB (Desktop) kVisia (Desktop and Web)
Ø  Obtain VB source code.

Ø  Open VBP.

Ø  Edit GUI.

Ø  Add code to populate list.

Ø  Add validation rules.

Ø  Save source code.

Ø  Compile DLL.

Ø  Create CAB file.

Ø  Open DocApp in Composer

Ø  Edit the component ACX and

replace CAB file.

Ø  Check DocApp back in.

Ø  Not available until next user login.

Ø  Check out XML.

Ø  Edit XML kVisia Studio.

Ø  Add XML tag.

Ø  Specify properties.

Ø  Save and Check back in.

Ø  Change available immediately (no logout required).

  1. Benefits
  • Easy to manage development process as applications are configured via XML using Studio
  • Fast route from innovation to user acceptance
  • Shorter time from design through to development
  • Shorter time to deploy to the business users
  • Reduces development costs
  • Future upgrades are minimised
  • Simple deployment and at a local level of control
  • Speeds up implementation process through rapid configuration

Hope you like the post, Feel free to post your comments and I will reply back to any queries that you have.

Adios , Have a great day ahead…

Changing Documentum’s Installation Owner

November 24, 2010 1 comment

When initially installing Documentum, the installation owner is set to the logged-in user that performs the Documentum installation. It is preferable to install Documentum and never change the installation owner. However, sometimes company policy dictates that the original installation must be changed. Reasons for the change may be that the user name does not conform to a new naming policy or that originally the user was not a domain user but now should be.Changing the installation owner involves changes to both the operating system and the docbase configuration. This is not a minor change within Documentum, so upfront planning and coordination between the Documentum System Administrator and Infrastructure Team is required.

To get the most from this article, you should already have:

  • A detailed knowledge of Documentum Content Server
  • A detailed knowledge of your company’s implementation of Documentum
  • A detailed knowledge of Windows 2000 Operating System

For purpose of this document, we are going to refer to the following users:

Original Installation Owner:

username = “dmadmin”

password = “dmadmin”

domain = “it”

New Installation Owner:

username = “new_dmadmin”

password = “new_dmadmin”

domain = “dctm”

How Documentum uses the installation owner ?

The Documentum installation owner is the operating system user that owns the server executable and other related files along with the OS process when the server is running. The installation owner is originally determined when the server is installed; it is the logged-in user that performed the Documentum installation. This user is given the following privileges:

  • Operating System:
    • ‘Log On As’ rights to start Documentum Services such as Docbase, Docbroker, Java Method Server and other installed Documentum products (i.e. Site Caching Services).
    • Permission to change the Content Server configuration (i.e. upgrade, create, and delete docbases)
    • Folder level permission to view data, configuration, and many log files located under the %DOCUMENTUM_HOME% directory.
  • Docbase & Content Server:
    • Superuser and System Administrator rights
    • Assignment to administrator (Web Publisher), docu, and admingroup groups
    • Set as the r_install_owner value in the dm_server_config object.
    • Set as the operating system user to run several Administrative jobs such as dm_DataDictionaryPublisher and dm_FulltextMgr

Preparing to Make the Change

Preparation is an important step when making any major change within your Documentum environment. The following are steps recommended to make your life easier when updating the installation owner.

  • Determine best approach for changing the installation owner. The three documented approaches are:
    1. Minimal Impact – Update only the operating system user and the user_os_name of the docbase user
    2. Medium Impact – Create a new user in the docbase to be the installation owner while letting the old installation owner continue to own any existing objects
    3. Largest Impact – Create a new user in the docbase to be the installation owner and reassign the previous installation owner’s objects to the new user.
  • Communicate and Make a Plan – Have your team ready and ensure everyone is aware of the plan. Communication is an important factor for success. Ensuring everyone is aware of their role will help make the change go smoothly.
  • TEST – Set up a test docbase to test updating the installation owner prior to making any change in a Production environment
  • Purge all old log files – Changing the installation owner requires updating permissions on Documentum data and log files. Reducing the amount of unneeded data will greatly speed up the process. This is especially important if you will be following Approach 3
  • Run the Consistency Checker – This report gives you a list of bad data within your system. Cleaning up inconsistent data before making the change will speed up the process and in the end make your life easier.
  • Back up all environments – Before performing any major change within Documentum you should ALWAYS back up your environment. This is a System Administration best practice. Work with your database administrators and infrastructure team to back up both the content server files and the database.
  • Set up the new installation user
    • Add the new installation user to the Administrator group on the Windows 2000 machine
    • Set the user to act as part of the operating system on the Windows 2000 machine. This setting can be found under Control Panel\Administrative Tools\Local Security Settings\Local Policies\User Rights Assignment\Act as part of the operating system
    • Update permission on all folders, subfolders and files under %DOCUMENTUM_HOME%> to remove the old installation owner and add new installation owner with full control

Approach 1: Updating only the installation user OS name  

The simplest way to change the installation owner is to change the existing docbase user’s user_os_name/user_domain. This is the recommended solution in most cases.

Pros

  • Simple way to change the installation owner. This solution does not require updating Documentum objects therefore it reduces the risk of error and amount of work required with large Docbases.

Cons

  • The user_name within Documentum remains the same therefore the previous installation owner name will appear as the display name within Documentum.

Steps

  1. Log into Documentum as an administrator
  2. Update the current Documentum installation user’s user_os_name to the new installation owner:
    update dm_user object set user_os_name = ‘new_dmadmin’, set user_domain = ‘dctm’ where user_name = ‘dmadmin’;
  3. Log onto the Windows 2000 server as current installation owner
  4. Stop Services for all Documentum services (i.e. Docbases, DocBroker, Java Method Server, Site Caching Services)
  5. Edit the install_owner and user_auth_target parameters in the server.ini file to reference the new installation owner and domain for each Docbase in the installation. The server.ini file is located in %DOCUMENTUM_HOME%\dba\config\docbase_name\server.ini or it can be accessed through the Documentum Server Manager.
  6. Within Windows Explorer, change permission to give the new installation user full control on the all directories, subdirectories and files under the Content Server installation root directory (%DOCUMENTUM_HOME%). To update permission within Explorer:
    • Select the directory and right click to display a menu; choose Properties from the menu
    • Select the Security tab on the Properties dialog box
    • Select ‘Add’ to add a new user; select the new installation owner
    • Check Allow for Full Control
    • Remove the previous installation owner from the list of users with permission on the directory; Click Ok

Many subfolders and files under %DOCUMENTUM_HOME% are not set out of box with the allow inheritable permissions from parent to propagate to this object checked. Therefore you cannot assume that a subfolder or file is inheriting permission from its parent and you must ensure that you update the permission on ALL files and subfolders located under %DOCUMENTUM_HOME%. %DOCUMENTUM_HOME% subfolders and files that need to be update because they are not inheriting permission from its parent include but may not be limited to: \data; \data\[docbase_name]\’all subfolders’; \dba; \dba\auth; \dba\config\[docbase name]\dbpasswd.txt; \dba\config\[docbase name]\webcache.ini; \dba\config\[docbase name]\webcache.ini.old; \dba\log\’subfolders’; \dba\secure; \dba\secure\aek.key; \fulltext; \product; \share; \share\data\common\’subfolders’; \share\data\events\’subfolders’; \share\temp\replicate\’subfolders’; \share\temp\dm_ca_store\’subfolders’

Note: If your content storage directories are not located under the %DOCUMENTUM_HOME%\data directory, change the permissions on each content storage directory as well.

  1. Edit the Windows Registry with new installation owner:
    • Update HKEY_LOCAL_MACHINE\SOFTWARE\Documentum\Server\version_no
      • Change the value of DM_DMADMIN_USER to the new installation owner user name
      • Change the value of DM_DMADMIN_DOMAIN to the new installation owner user domain
  2. Set up the appropriate start-up information for Documentum Services
    • Choose Control Panel -> Administrative Tools -> Services
    • Select Documentum Services (i.e Documentum Docbase docbase_name, Documentum Docbroker, Documentum Java Method Server, Documentum SCS_Source)
      • Right click on Service and select Properties
      • On the Log on Tab, enter the new installation name and password under Log On As: This Account
  3. Move any Documentum-related Programs in start menu (C:\Documents and Settings\old_user_name\Start Menu) to the new installation owner
  4. Restart Windows 2000 Server; Log in as the new installation owner
  5. Start the Docbases; View logs to check for errors

Approach 2: Creating a new Documentum installation user without Object Reassignment

This procedure is recommended if your policies require that the docbase user’s user_name be changed but do not requite that existing objects be assigned to the new user.

Pros

  • The user_name within Documentum is updated to the new installation owner therefore it will appear as the display name within Documentum (similar to how it would appear if the docbase had been installed originally as this user).

Cons

  • The old installation user remains within the docbase. However, if the old operating system user has been removed no one will be able to log in as this user
  • Tasks that were previously assigned to the old installation owner will not be accesible

Steps

  1. Log onto the Windows 2000 server as current installation owner
  2. Stop Services for all Docbases and the DocBroker.
  3. Edit the install_owner and user_auth_target parameters in the server.ini file to reference the new installation owner and domain for each Docbase in the installation. The server.ini file is located in %DOCUMENTUM_HOME%\dba\config\docbase_name\server.ini or it can be accessed through the Documentum Server Manager.
  4. Within Windows Explorer, change permission to give the new installation user full control on the all directories, subdirectories and files under the Content Server installation root directory (%DOCUMENTUM_HOME%). To update permission within Explorer:
    • Select the directory and right click to display a menu; choose Properties from the menu
    • Select the Security tab on the Properties dialog box
    • Select ‘Add’ to add a new user; select the new installation owner
    • Check Allow for Full Control
    • Remove the previous installation owner from the list of users with permission on the directory; Click Ok

Many subfolders and files under %DOCUMENTUM_HOME% are not set out of box with the allow inheritable permissions from parent to propagate to this object checked. Therefore you cannot assume that a subfolder or file is inheriting permission from its parent and you must ensure that you update the permission on ALL files and subfolders located under %DOCUMENTUM_HOME%. %DOCUMENTUM_HOME% subfolders and files that need to be update because they are not inheriting permission from its parent include but may not be limited to: \data; \data\[docbase_name]\’all subfolders’; \dba; \dba\auth; \dba\config\[docbase name]\dbpasswd.txt; \dba\config\[docbase name]\webcache.ini; \dba\config\[docbase name]\webcache.ini.old; \dba\log\’subfolders’; \dba\secure; \dba\secure\aek.key; \fulltext; \product; \share; \share\data\common\’subfolders’; \share\data\events\’subfolders’; \share\temp\replicate\’subfolders’; \share\temp\dm_ca_store\’subfolders’

Note: If your content storage directories are not located under the %DOCUMENTUM_HOME%\data directory, change the permissions on each content storage directory as well.

  1. Edit the Windows Registry with new installation owner:
    • Update HKEY_LOCAL_MACHINE\SOFTWARE\Documentum\Server\version_no
      • Change the value of DM_DMADMIN_USER to the new installation owner user name
      • Change the value of DM_DMADMIN_DOMAIN to the new installation owner user domain
    • Update – HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DmServerdocbase_name
      • Change the -install_owner parameter in the value for ImagePath to the new installation owner user name
  2. Set up the appropriate start-up information for Documentum Services
    • Choose Control Panel -> Administrative Tools -> Services
    • Select Documentum Services (i.e Documentum Docbase docbase_name, Documentum Docbroker, Documentum Java Method Server, Documentum SCS_Source)
      • Right click on Service and select Properties
      • On the Log on Tab, enter the new installation name and password under Log On As: This Account
  3. Move any Documentum-related Programs in start menu (C:\Documents and Settings\old_user_name\Start Menu) to the new installation owner
  4. Restart Windows 2000 Server; Log in as the new installation owner
  5. Start the Docbases; View logs to check for errors

 

Approach 3: Creating a new Documentum installation user with Object Reassignment

If the requirements around changing the installation owner include changing the Documentum Installation user_name and removing the old installation user from Documentum, then you must create a new installation Documentum user and reassign the previous user’s objects and tasks to the new user. This is the most complex, time consuming, and risky procedure and is not recommended unless completely necessary.

Pros

  • The user_name within Documentum is updated to the new installation owner therefore it will appear as the display name within Documentum
  • The previous Documentum installation owner will be removed from the Docbase

Cons

  • Reassigning the previous installation owner to the new installation is error prone and time consuming for large docbases. However, risk can be reduced by purging old log files prior to changing the installation owner

Steps

The steps are the same as in Approach 2 with the following steps required at the end:

  1. Log into Documentum Administrator as the new installation owner
    • Navigate to Administration -> User Management -> Users
    • Select the previous installation owner (’dmadmin’)
    • Select Tools -> Reassign User
    • Repeatedly run the following query: select count(*), acl_name from dm_sysobject where acl_domain = ‘dmadmin’ group by acl_name Note: The job may take a while to run depending on the amount of data. Once the query returns no rows the job is complete.

Smoke Testing the Change

After any major change to your Documentum infrastructure you should Test, Test, Test. Detailed test steps vary based on your Documentum application environment. It is important to have a test plan defined during your preparation. However, below are some brief smoke test steps which should prove helpful:

  • If you are using Web Publisher:
    • Log into Web Publisher as the new installation owner
    • Create content based on a template
    • Start a workflow; Log in as the workflow approver to ensure the task went to the correct user
    • Access Web View
  • If you are using Documentum Administrator:
    • Log into Administrator as the new installation owner
    • Spot check jobs (i.e. dm_DataDictionaryPublisher, dm_FulltextMgr , etc.) to ensure they are successfully running
  • If you are using Site Caching Services:
    • Log into Administrator as the new installation owner
    • Navigate to Site Publishing Configuration
    • Check a configuration; run an ‘End to End’ test
  • If you are using any other Documentum products:
    • Log into each application
    • Perform everyday user tasks
  • Run Consistency Checker (dm_ConsistencyChecker) Job. This report appears under System/SysAdmin/Reports

Common Issues/Helpful Hints

  1. Setting user permission on %DOCUMENTUM_HOME% can be cumbersome, is there an easier way to perform this task?
    Yes. It would be recommended to have a system administrator run a windows scripts to update all folders and files under %DOCUMENTUM_HOME%. Another shortcut would be to set the local Administrator group on the Windows 2000 with Full Control permission on all subfolders and files under %DOCUMENTUM_HOME%. Later, when updating an installation owner you would just need to add/remove users from the local Administrator group. Setting the Administrator group permissions in this fashion also eases backing up Content Server files.
  2. Can you update only the user domain?
    Yes. To update only the user domain you will need to:  

    • Add the new domain user to the Administrator group on the Windows 2000 server; Set up the user as act as part of the operating system
    • Update the user_domain attribute of the installation owner:
      update dm_user object set user_domain = ‘[new domain]‘ where user_name = ‘[installation owner]‘
    • Edit the user_auth_target parameters in the server.ini file to reference the new domain for each Docbase in the installation.
    • Update permission on all subfolders and files under %DOCUMENTUM_HOME% to use the new domain user.
    • Update Windows Registry – HKEY_LOCAL_MACHINE\SOFTWARE\Documentum\Server\version_no
      • Change the value of DM_DMADMIN_DOMAIN to the new domain
    • Set up the appropriate start-up information (Log on As: This Account) for Documentum Services to use the new domain user
  3. Can you update only the user password?
    Yes. Stop all Documentum services (Docbases, DocBroker, Java Method Server, Site Caching Services). Within the service properties under the Log on Tab, enter the new password under Log On As: This Account.
  4. What if after running the Reassign User job there are still objects referencing the old user?
    This sometimes happens if there are many objects (such as log files) owned by the old installation owner. A solution to this is to wait for the job to complete and then recreate the previous installation owner within Documentum then run ‘Reassign User’ again. Continue this until the following queries return 0 rows:
  5. select count(*), acl_name from dm_sysobject where acl_domain = '[old installation owner]‘ group by acl_name;
  6. select r_object_id from dm_sysobject where owner_name= ‘[old installation owner]‘;

Hope this experiment is useful .

Changing the Installation owner in Documentum

October 30, 2010 Comments off

Although changing the installation owner is not recommended in Documentum but when need demand you can try the below steps to change the installation owner:

1. Log in as the Windows NT system administrator.

2. Stop Services for all Docbases and the DocBroker.

3. Edit the install_owner parameter in the server.ini file for each Docbase in the installation to reference the new installation owner.

a. The server.ini file is found in %DOCUMENTUM%\dba\config\Docbase_name\server.ini.

4. Change permissions on the data, dba, product, and share subdirectories under the eContent Server installation root directory (%DOCUMENTUM%). For each directory:

a. In Explorer, select the directory.

b. Right click to display a menu; choose Properties from the menu.

c. Select the Security tab on the Properties dialog box.

d. Click Permissions to display the Directory Permissions dialog box.

e. Click Add to add the new installation owner to the list of those with permissions on the directory.

f. You will be asked for the new owner’s domain.

g. Give the new owner Full Control permission.

h. Check “Replace Permissions on Subdirectories” and “Replace Permissions on Existing Files”.

i. Remove the old installation owner from the list of those with access permission on the directory.

j. Click OK.

5. If your content storage directories are not located under the %DOCUMENTUM%\data directory, change the permissions on each content storage directory also. Use the procedure in Step 4 to change their permissions.

6. Edit the Registry to reflect the change in ownership:

a. In the following key:

HKEY_LOCAL_MACHINE\SOFTWARE\Documentum\Server\version_no

i. Change the value of DM_DMADMIN_USER to the new owner.

ii. If needed, change the value of DM_DMADMIN_DOMAIN to the domain of the new owner.

b. In the following key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DmServer Docbase_name

Change the –install_owner parameter in the value for ImagePath to the new owner.

7. For each Docbase in the installation, use regedt32 to change the security permissions on the following Registry keys:

a. HKEY_LOCAL_MACHINE\SOFTWARE\Documentum\Docbases\Docbase_name

b. HKEY_LOCAL_MACHINE\SOFTWARE\Documentum\Server\version_no

c. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog\Application\Documentum

d. For each key:

I. Select the key and right click to display a menu.

II. Choose Security .Permissions.

III. Add the new installation owner user with Full Control

IV. Remove the old installation owner.

8. For each Docbase, set the appropriate start-up information:

a. Choose Control Panel .Services.

b. Select the Service: Documentum Docbase Docbase_name

c. In the Startup dialog, enter the new owner and the owner’s password under Log On As: This Account.

9. Move the Documentum-related Program Items in Start menu to the new owner.

Move:

Documentum

Documentum Docbase Docbase_name

From:

WinNT\Profiles\old_owner\Start Menu\Programs\

To:

WinNT\Profiles\new_owner\Start Menu\Programs\

10. Update the r_install_owner and r_install_domain in the server_config object to reflect the new installation owner.

11. Restart Windows NT

Configurational Tips for Documentum Webtop

March 30, 2010 Comments off

Below i tried to cover the scenario where multiple docbases are configured and provides a solution to various business requirements that may arise out of this kind of set up. It also illustrates the configurational change that makes webtop (till version 5.3 SP4) compatible with Internet Explorer 7.0.

1.   Accessing multiple docbases from single machine

Business Scenario: There are multiple environments (say Development, Test, Staging and Production). Each has its individual content server but the requirement is to connect to any one of these environment through a single application server.

Solution: Add the different docbrokers in dmcl.ini as backup. This allows the application server to connect to the docbase for which the login credentials are passed.

The content server requires user id, password and docbase name as the parameter for creating a session for the user. The request from application server first goes to the docbroker specified as primary. If the parameters passed in the request matches with that of the docbase listening on the primary docbroker, the session will be created otherwise the request will be forwarded to the backup docbroker specified in the dmcl.ini in the ascending order.

Configuration Text File

This solution works for the following scenarios:

  1. If the docbase name in the different environments is different (or even if the case is different i.e. docbase_name and DOCBASE_NAME are treated as different docbases).
  2. User id or login ticket is unique.

2.   Defaulting docbase on login screen in webtop

Business Scenario: Multiple content management applications are sharing the same set of content and application server. The docbase and webtop is separate for each of the application. The requirement is to default the docbase name in the webtop login screen for each of the application.

Solution: Add the following code snippet in the app.xml file located under webtop\custom folder.

<authentication>

        <!– Default domain and docbase to authenticate against –>

       <domain></domain>

       <docbase>docbase_name</docbase>

</authentication>

3.   I.E. 7 Compatibility

Add the following code snippet to app.xml file located under webtop\custom folder to make webtop (till version 5.3 SP4) compatible with Internet Explorer 7.0.

<browserrequirements>

     <windows>

          <ieversions>6.0,7.0</ieversions>

          <netscapeversions>7.2</netscapeversions>

          <firefoxversions>1.5</firefoxversions>

     </windows>

</browserrequirements>

%d bloggers like this: