Archive

Posts Tagged ‘WDK’

Presets in Documentum 6.5

June 9, 2011 1 comment

WDK (web development kit) customizations have been part and parcel of all custom Documentum WebTop applications. The customizations includes copying the WDK components (XMLs, JSPs, custom class etc) into the custom layer. Until version 5.3 SP6 there were no Documentum out of the box features that allowed developers to perform basic customization without having to customize the WDK components manually.

Documentum 6 and above version presented the idea of “Presets”. This versatile out of the box feature in Documentum enable Documentum developers to perform basic WDK customization/configuration with a few clicks of the mouse.

This Post  deals with the basics of Documentum presets and demonstrates a sample preset configuration.

Presets

Presets are out of the box feature in Documentum which enable Documentum developers to perform basic WDK customization/configuration with a few clicks of the mouse.Presets are easy to apply rules or configurations that can be created to bring in WDK configurations and setting without having to configure JSP’s pr XML’s manually. Though presets cannot completely replace WDK customizations, they certainly save time when used to make simple and common WDK changes in Documentum WebTop application.

Below an attempt is made to explain the various options available for presets and the way to configure them. Though all the options are being touched upon, for simplicity I am picking up an example preset which I will be using to disable the “FileàNewàDocument” option for all users except administrators.

 1. Presets option is available in Documentum WebTop once you have logged in as Documentum administrator. It can be seen in the left browser tree under Administration–>Presets

  1. When clicked on “Presets” the right panel will display the list of Presets if any exists.
  2. Use the menu bar option File–>New–>Preset to configure a new Preset

3. This will pull up a screen with the “Setup” tab pre selected. This screen offers the user with four options as shown below.

4. The four options are as follows

  1. Apply to User/Group/Role: This option enables us to configure a preset for a specific user/group or role. For example to configure a preset which would disable “Fileà NewàDocument” option for all users except the members of “admingroup” group, this would be the option to be selected.
  2. Apply to existing location: This option enables us to configure a preset for a specific location. For example if anyone wants to configure a preset that would enable /disable navigations or menu bar options for a particular folder or cabinet this would be the option to be selected.
  3. Apply to specific type: This option enables us to configure a preset for a specific object type. For example if anyone wants to configure a preset for dm_document( or any custom ) object type alone then this would be the best option.
  4. Apply to specific repository: This option enables us to configure a preset at the repository level. For example if anyone wants to configure a preset which would display only custom object types while creating a new document in WebTop for all users who are logged into a repository (docbase) then this would be the option they have to look into.

5. To continue with the steps, here we would be continuing by using option a mentioned above. Using this we would try to create a preset such that “FileàNewàDocument” option is disabled for all users who are members of “admingroup” group.

6. In the screen shown in step 4 click on “Select…” button for Apply to User/Group/Role: option. A screen as shown below will be pulled up to select the required group. In this example we will be selecting “admingroup”.Filter the required group and select it. Click OK

7. Once the group is selected, the next step would be to move to the “Rules” tab. Provide the “Preset name” and “Description” textbox and then click on Next button to move to “Rules” tab.

8. The “Rules” tab will present us with a screen which allows us to configure various entities with respect to the group we selected.

 Note : In this case these entities can be applied for group. As mentioned before (step 5) the same set of entities can be applied for other options,  that is the rules can be applied for type, docbase or location as well.

9. The above screen displays the following rules. For each rules there are configurations/actions that can be selected. Most of the options are self explanatory.

a. Permissions

b. Formats

c. Types

d. Groups

e. Workflows

f. Lifecycles

g. Templates

h. Actions

i. Navigation

j. Attributes

10 .Here since we are going to disable the menu item “File–>New–>Document” we will be selecting the option “Actions

11. When the option action is selected, an “Action Selector” drop down is presented to the user. We have the option to select a particular action and then add them to the “Excluded” list. Here we will be selecting the action “File–>New–>Document”.

12. Click “Finish” .The new preset is created and this will be visible in the Presets list. Refer image below.

13. The comparison between the screen shots taken for “File–>New–>Document” action before and after the preset is created.

Note: As mentioned in the steps above various kinds of Presets can be created. While planning to create presets, one thing to be borne in mind is that if a preset is applied to a group, location, docbase or type, it is not possible to create another preset for the same group, location, docbase or type.

More Details and Limitations of presets

Please refer Documentum WebTop release notes for more details and to know about limitations of presets.

  1. Presets are created as dmc_preset_package objects in Documentum
  2. WebTop presets reside in Documentum under the location given below    “Cabinets/Resources/Registry/Presets/Webtop/Preset Packages”
  3. A preset can be queried using the DQL select * from dmc_preset_package where object_name like ‘%<name of preset>%’

Any Points missed please mention it in the comments , will refresh the Post.

BOCS Implementation

November 13, 2010 Comments off

A BOCS server can be implemented in two different Distributed models.

Single Model-1 and Single Model -2

Lets see How a Single Model-1 Systems Works.

Single repository with content persistently stored at primary site and accessed using ACS or BOCS servers.

In this model, remote users connect through web browser, using a WDK-based client application. They access content stored at the primary site, through either an ACS or BOCS server. The ACS server is a content server dedicated to serving content. It does not process metadata nor write content to storage. It only processes content requests. The BOCS server is a separate product. It is a caching server that communicates only with ACS servers. Like the ACS server, it does not handle metadata requests or write content to storage.

Both the ACS and BOCS servers use HTTP or HTTPS protocol to serve content to clients. Single model 1 is the preferred model when remote users are accessing repository content through a web-based application, such as WebTop. There are two alternative configurations for this model. The configurations differ in how users at remote sites access the content at the primary site. In the first alternative, remote sites have a BOCS server installed and clients at each remote site use that BOCS server to access content. In the second basic configuration, users at remote sites have only web clients, and they access content using the ACS server at the primary site.

Alternative 1: BOCS servers at remote sites communicating with primary site

The Systems are not representing the individual systems or users they are representing the Geographical locations.

 

2: Remote sites, without BOCS servers, using primary site’s ACS server

 

The Model one has architecture of having single repository in an N/W distributed environment, where model one and combined form of alternatives of model one and two are very common Industry configuration, they are preferred over the alternative two for model 1. Or there can be one combined situation also when both of the configuration may exist simultaneously in a combine form, as shown in following figure. It has single BOCS server serving to all of the system irrespective of the geographical location from where the client is accessing the Content Server. But the architecture changes when we have more than one Content storage are referred by the Content server; it is explained in model 2.

 

Two alternatives for single model 1 combined

 

Benets and best use

This model requires the least amount of administrative overhead. It is easy to set up

and configure, and ongoing administration needs are minimal. There are no content

replication jobs to define, administer, and run. This model is not available for users on Desktop clients.

In my next Post , i will bring out the implementation of BOCS in Single Model-2.

Functioning aspects of Documentum

March 21, 2010 Comments off

Documentum has the following functioning sectors:

  1. Client-WebTop or Desktop client – The client can be a web based client (WebTop client) or can be a desktop client.
  2. Content repository – The content repository contains the actual files. It stores data either as File system or External storage
  3. Database – The database contains the address about where the files are actually Stored (metadata).
  4. Web development kit (WDK) – The WDK contains a set of API’s which help to retrieve the relevant data.
%d bloggers like this: