Archive

Posts Tagged ‘Docbase’

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…

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.

Utilities for Easy Handling of Administrator Work in Documentum

December 1, 2010 Comments off

Apart from installation and setting up of documentum server and client
environment, there are many important tasks which needs to be handled by an  Administrator in order for smooth and proper functioning of the set up.

Some of the tasks are mentioned below:
1. Modifying the configurations of servers, docbroker.
2. Creating new Docbases.
3. Maintaining Docbases.
4. Configuring, starting and shutting down servers.
5. Changing session configuration.
6. Managing content storage areas and content files.
7. Managing users and groups.
8. Managing security.

Utilities for Easy Handling of Administrative Task:

1.dm_error utility
We encounter various content server errors with just with an error code
without much information about it. Documentum has defined all the errors
with an expanded statement of the error, possible causes of it and
prescribes possible solutions for the error. Utility should be executed in the
command prompt of the content server.
Syntax: dm_error <error_code>

2.PreLoad Utility
Administrator operations include activities called Dumping and Loading Docbase.Dump and Load operations can be used to do the following activities:
a. Move a Docbase to one location to another.
b. Duplicate a Docbase.
c. Duplicate or move some portion of the Docbase.
A dump operation creates a binary file of objects dumped from a Docbase. If a dumped object has associated content files, the content files are either
referenced by full path or included directly in the dump file. The load operation loads the objects and content files into another Docbase.
PreLoad utility can be run on a dump file created to tell what all objects that
should be created in the new Docbase before loading the dump file. Utility can also be used to create a DQL script that you can edit and then run to create the needed objects.
Syntax:
preload docbase [-Uusername] -Ppassword -dump_file filename [-
script_file name]
The docbase is the name of the Docbase into which you are loading the dump
file. Filename is the name of the dump file, and name defines a name for the
output DQL script. If you do not include a username, the current user is
assumed.
Note: This utility does not report all storage areas in the source Docbase, but
only those that have been copied into the dump file.

3.dmclean Utility
Every Docbase requires a scheduled clean up need to be performed by
administrator. One such clean up includes removing orphaned content files.
When users delete a document, or any object that has a content file associated with it, the system deletes the object and marks the content as an orphan. The system does not delete the actual content file. This must be done using the dmclean utility. Dmclean can be run using:

a. Documentum Administrator.
b. A DQL EXECUTE statement.
Syntax:
EXECUTE do_method
WITH method = ’dmclean’,
arguments = ’-no_content -no_note -no_wf_template’
c. An Apply method
Syntax:
apply,session,NULL,DO_METHOD,METHOD,S,dmclean, ARGUMENTS,S,’-no_content -no_note -no_wf_template’
d. From Content Server command prompt
dmclean -docbase_name docbase -init_file init_file_name
-no_content -no_note -no_wf_template
Where wheredocbase is the name of the Docbase and init_file_name
is the name of the server.ini start up file for the Docbase’s server.

4.dmfilescan Utility
This utility is used to scan the one or more storage area and find any content
files that do not have associated content objects. The utility scans for orphaned files which are over 24 hours old.
Running the utility using EXECUTE statement:
EXECUTE do_method WITH method = ’dmfilescan’,
[arguments = ’[-s storage_area_name] [,-from directory1]
[,-to directory2]’]
The utility automatically saves the output to a document that is stored in
the Temp cabinet. FALSE.) The output is a generated script that includes
the informational messages generated by the utility.
Running the utility using Content Server command prompt:
dmfilescan -docbase_name name -init_file init_file_name
[-s storage_area_name][-from directory1][-to directory2]
The init_file_name is the name of Content Server’s server.ini file. This is
one of the server start up files.

5.dm_crypto_change_passphrase Utility
Every installation of a Content Server creates a key called Administration
Encryption Key (AEK). This is used to encrypt:
a. The Docbase keys.
b. Documentum passwords, such as those used by Content Server to
connect to the RDMS or any other Docbase.
This AEK is stored at: %DOCUMENTUM%\dba\secure\aek.key and this key also are encrypted using a default passphrase provided by Documentum. It is always advisable to change the default passphrase. To change the default passphrase we can use dm_crypto_change_passphrase Utility.
Syntax:
dm_crypto_change_passphrase [-location location][-passphrase
[old_passphrase]][-newpassphrase [new_passphrase]][-noprompt][-help]
Location is the place where AEK is placed for which we need to change the
passphrase.
old_passphrase is the old passphrase name.
new_passphrase is the new passphrase name.
-noprompt should be used if any one the argument mentioned above is not
used. It’s like the end specify mentioning the end of arguments.
-help returns help information for the utility.

6.IAPI Utility
IAPI Utility is used to issue direct method call to the server.
Running the utility from the server command prompt:
iapi32 [-Uusername|-ENV_CONNECT_USER_NAME]
[-Pos_password|-ENV_CONNECT_PASSWORD] [-Llogfile] [-X][-E]
[-V-][-Q] docbase|-ENV_CONNECT_DOCBASE_NAME [-Rinputfile]
[-Ftrace_level][-Sinit_level][-Iescape_character][-zZ]
[-Winteger][-Ksecure_mode]
Order of the parameter does not hold importance.
Username- Identifies the name who is starting the session.
ENV_CONNECT_USER_NAME- User name in looked in the environment
variable DM_USER_NAME.
Password- User’s operating system password.
ENV_CONNECT_PASSWORD- Password is looked in the environment
variable DM_PASSWORD.
-Llogfile – Directs the server to start a log file for the session.
You must include the file name with the argument. You can specify a
full path.
-X Allows prompt for domain.
-E Turns on echo.
-V- Turns verbose mode off. The utility runs in verbose
mode by default. If you turn verbose mode off, the
system does not display the IAPI prompt, error
messages, or any responses to your commands
(return values or status messages).
-Q Directs the utility to provide a quick connection test. The utility attempts to connect and exits with a status of zero if successful or non-zero if not.
It provides error messages if the attempt is not successful.
Docbase- Docbase name which is intended to access.
ENV_CONNECT_DOCBASE_NAM – finds the name of the docbase
from environment variable DM_USER_NAME.
-Rinputfile input file with API methods.
-Ftrace_level Turns tracing on.
-Sinit_level Defines the connection level established when you
start the API session.

-Iescape_character Defines an escape character for certain symbols
such as a forward slash (/).
-zZ Specifies Windows NT Unified Logon.
7.IDQL Utility
IDQL is also a useful as a tool for testing and other tasks that support an
application or installation because it allows you to run scripts and batch files.
Running the utility from the server command prompt:
idql32 [-n] [-wcolumnwidth]
[-Uusername|-ENV_CONNECT_USER_NAME]
[-Pos_password|-ENV_CONNECT_PASSWORD][-Ddomain]
docbase|-ENV_CONNECT_DOCBASE_NAME [-Rinput_file]
[-X][-E][-Ltrace_level][-zZ][-Winteger][-Ksecure_mode]
The parameter being the same as mentioned in above utility.

Upgrading Documentum Environment from 5.2 to 6.5

November 22, 2010 Comments off

The process of upgrading Documentum Content Server from 5.2.5 SP2 to 6.5 SP2 can be divided in two steps:

a)    Upgrading 5.2.5 SP2 to 5.3 SP5

b)    Upgrading the 5.3 SP5 to 6.5 SP2

Part A: Upgrading 5.2.5 SP2 to 5.3 SP5

Following are the steps for the upgrading Documentum environment from 5.2.5 SP2 to 5.3 SP5:

  1. Before upgrading the Documentum content server the database needs to be upgraded from Oracle 8i to Oracle 10g. Before upgrading the Oracle 10g take the db backup and restore them once oracle is upgraded.
  2. Now install the Documentum 5.3 SP5 on the same location where 5.2.5 SP2 is located. Here while installing 5.3 SP5 it will check whether older version of Documentum content server is installed. Since already Documentum is installed it will ask whether to proceed with upgrading the content server or not. Click OK to continue.

The remaining installation steps are similar to the normal content server installation.

3.    Now the content server has been upgraded to 5.3 SP5.

4.    Now docbroker, docbase needs to be upgraded.

Run the server configuration to upgrade the docbroker and docbase respectively. Check the two check boxes as shown in the following screen shot to upgrade the docbroker and docbases.

5.    First docbroker needs to be upgraded. Click on the upgrade docbroker option to upgrade the docbroker.

A confirmation dialog box will pop up informing about upgrading the connection broker. Click on OK to proceed.

6.    Once the docbroker is upgraded, docbase needs to be upgraded. Select continue with server configuration option to upgrade the docbase.

7.    Select upgrade the existing repository option to upgrade the docbase.

A confirmation dialog box will pop up informing about upgrading the connection broker. Click on OK to proceed.

8.    Once the dobase is upgraded, restart the Documentum server, connection broker and docbase. Test the connectivity through da and webtop.

9.    Check all the existing docapps are functioning as they were in the previous environment.

Part B: Upgrading 5.3 SP5 to 6.5 SP2

The second part of the upgrade process involves upgrading from 5.3 SP5to 6.5 SP2.

Following are the steps for upgrading Documentum environment from 5.3 SP5 to 6.5 SP2:

Assuming Documentum 5.3 SP5 is installed on windows 2003 server with database as Oracle 10g.

1.    Now install the Documentum 6.5 SP2 on the same location where 5.3 SP5 is located. Here while installing 6.5 SP2 it will check whether older version of Documentum content server is installed. Since already Documentum is installed it will ask whether to proceed with upgrading the content server or not. Click OK to continue.

The remaining installation steps are similar to the normal content server installation.

2.    Now the content server has been upgraded to 6.5 SP2.

3.    Now docbroker, docbase needs to be upgraded.

4.    Run the server configuration to upgrade the docbroker and docbase respectively. Check the two check boxes as shown in the following screen shot to upgrade the docbroker and docbases.

5.    First docbroker needs to be upgraded. Click on the upgrade docbroker option to upgrade the docbroker.

A confirmation dialog box will pop up informing about upgrading the connection broker. Click on OK to proceed.

6.    Once the docbroker is upgraded, docbase needs to be upgraded. Select continue with server configuration option to upgrade the docbase.

7.    Select upgrade the existing repository option to upgrade the docbase.

A confirmation dialog box will pop up informing about upgrading the connection broker. Click on OK to proceed.

8.    Once the dobase is upgraded, restart the Documentum server, connection broker and docbase. Test the connectivity through da and webtop.

9.    Check all the existing docapps are functioning as they were in the previous environment.

Alias Sets and Permission Sets

November 18, 2010 Comments off

In my previous post i discussed about the Aliases and Permission templates, today lets see what are Alias Sets and Permission sets and how exactly security works in Documentum.

What is Alias Set?

An alias set is simply a list of aliases (like “reviewer” or “supervisor”) and the values that they resolve to. Whenever an object is referenced the permission set applied on it will be taken and if this set refers to an alias set then the alias value will be resolved and applied on the object and access will be restricted based on it.

Please Note in some circumstances you may assign an empty alias value and let the client application prompt the user for a value when it is needed.

Alias Sets are an important part of a complex Documentum system’s architecture, providing a level of abstraction that can significantly reduce the effort needed to administer the Docbase. Alias sets remove the need to hard-code the names of users, groups, locations, and permission sets throughout your application and instead provide a means for setting these values dynamically as your personnel changes and your business processes evolve.

What are Permission Sets?

Access Control Lists (s) [ACLs] are Documentum’s method of restricting access to important documents and folders. ACLs control Documentum’s security layer, one of the most flexible and powerful security schemes around. The permission can also be applied on workflow access and lifecycle application also.

Access control lists are stored as persistent objects in the Docbase. Although ACLs are persistent objects having an object ID, they are not SysObjects. Version cannot be created for. If modification is done an, the server either overwrites with the changes or copies the changes the copy. What option it chooses depends on whether the directly to make the changes or reference an object that uses the.

Some Uses can be:

  • You can assign seven different levels of access to your documents in the system
  • You can assign access to individual users or to groups of users
  • Users can create their own private s that only they can use
  • System Admins can create System-Wide s that can be used by everyone
  • Extended Permissions let you really tweak what a user can do to an object
  • Different folders can have different ACLs based on requirement irrespective of their hierarchy.

This contains information about which users and groups have access to the document, and what level of access each has. When a user attempts to access an object, the Documentum Server looks in to determine which groups have access. It then looks in these groups to determine if the user is in any of the groups. It determines the user’s access level by awarding the user the highest level of access taking into account all the groups that the user is a member of.

Please Note even if you explicitly assign NONE access to a user, if they are also in a group that has READ access, the user will have READ access to the object. Always the individual privilege will be overridden by the group privilege.

Now does the Security feature Works in Documentum:

When an object is applied with some permission set then corresponding entry will be made in the backend with the reference to the applied ACL. Now when an object is accessed after that if the ACL is referring to any alias set then first the alias is converted in to actual value and from where it map’s the current accessing user’s access and provides access based on the ACL entries for that user to that specific Object that is being currently accessed. Because of this Documentum has provided wide variety for the application of security across the System. It can be like a person who is an administrator of one cabinet will have max permit of delete in those folders and cabinets where as in the other folders and cabinets and documents that are present in the system he will be having normal read permission or different based on the requirement.

 

Hope this is useful ,appreciate your comments and corrections if any.

Documentum Business Objects Registry

May 4, 2010 Comments off

When creating a new document of document type ‘dm_document’ using WebTop application, internally DFC system will create instance of DFC classes DfSysObject, DfDocument and so on, thus limiting the functionality to that provided by DFC standard classes.

When using business objects, classes mapped to an existing object type (or custom object type) can be extended to provide our own business logic; this is done while developing TBO. Through object oriented mechanism called polymorphism, methods of these new classes gets called in bottom up order, i.e., methods in the parent class can be overridden in the new classes written. These new methods will be called automatically by DFC system.

The object factory guarantees that the correct object will be instantiated at runtime. This applies to TBO but not necessarily to SBO. When a TBO is developed and deployed on application server or content server, the framework guarantees that the new object gets called automatically. Two things make this happen. One is Documentum Business Object Repository (DBOR) . The other is that use of registry is now an integral part of DFC. Whenever someone attempts to access a custom-type Docbase object, DFC first checks the registry for a mapping to a custom Java class, then loads and instantiates that class.

DBOF provides the following mapping at runtime:

1. Docbase Type name to Java Class mapping: When the DFC core loads a Docbase object, its type name is looked up in the registry. If the name is found, its corresponding Java class is loaded and instantiated.

2. Service Interface name to Java Class mapping: When requesting the client to load a service, the service is identified by its published interface name, such as com.documentum.IInbox. If DFC finds the interface name in the registry, the corresponding service class is loaded and instantiated and returned to the caller.

Session Manager: Whenever an application requires access to a DocBase, authentication is required. Session Manager encapsulates the DFC session object and automatically manages the session pool. To get session in SBO java class, one has to acquire it using Session Manager and release it when not needed. Whereas in TBO’s, a reference to TBO’s session is embedded inside the object by default.

Session Pooling: Session Pooling provides for an application to connect and disconnect from DocBase session many times without incurring the overhead of real sessions with the server. Session Manager puts back the session into the pool when the client releases it, free to be used by other requests for sessions.

The concept of TBO and SBO is similar to the EJB in J2EE, TBO represent entity beans
and SBO represent stateless session beans

%d bloggers like this: