Archive

Posts Tagged ‘TBO’

Relationship and Virtual Documents in Documentum

November 26, 2011 Comments off

This Post explains how the concept of relationships and virtual documents can be used to relate objects in Documentum using Documentum Foundation Classes (DFC).

Definitions:

  1. Relationship: A relationship implies a connection between two objects. When an object is related to another object then we can define which object is the parent object or the child object or if they are equal. Relationships are system-defined as well as user-defined. In the BOK, we confine our self to user-defined relationships.
  2. Virtual Document: In Documentum, a document which holds other documents i.e. a document which acts as a container is called as a virtual document. A virtual document can contain other virtual documents. The document which acts as a container is called the parent document while the documents which are contained in parent document are called as child documents.

Overview on relationship:

Two built-in object types dm_relation and dm_relation_type are to be used to create relations between any two objects. The dm_relation_type object defines the behavior of the relation. The dm_relation object identifies the dm_relation_type object and the two objects between which the relation needs to be created. Pictorially it can be shown as:

Figure-1

The dm_relation_type object has following attributes:

  1. child_parent_label: It defines the child to parent feature of the relation.
  2. parent_child_label: It defines the parent to child feature of the relation.
  3. description: It gives the general description of the relation.
  4. parent_type: It defines the type of objects that will act as parents.
  5. child_type: It defines the type of objects that will act as child.
  6. direction_kind: It defines the nature of relationships between the objects. The expected values are:

a)    1 – Parent to Child

b)    2 – Child to Parent

c)    3 – Objects are at equal level

7. integrity_kind: It specifies the type of referential integrity used when either of the two related objects has to be deleted. The expected values are:

a)    0 – Any of the two related objects can be deleted.

b)    1 – As long as the relation exists, neither of the related objects can be deleted.

c)    2 – If one of the related objects gets deleted, other one also gets deleted.

      1. relation_name: Specifies a name for the relation
      2. security_type: It indicates the type of security to be used for the relation object. The valid values are:

a)    SYSTEM: If this value is used, then super-user privileges are required for creating, deleting or modifying the relationships pertaining to this dm_relation_type object.

b)    PARENT: In this case, the ACL for the relation is inherited from the parent object in the relation and RELATE permission is required to create, modify, or drop the relation. The exception to this is if the parent object is not a subtype of dm_sysobject, then no security will be enforced.

c)    CHILD: In this case, the ACL for the relation is inherited from the child object in the relation and RELATE permission is required to create, modify, or drop the relation. The exception to this is if the child object is not a subtype of dm_sysobject, then no security will be enforced.

d)    NONE – In this case, no security is applied. All users can create, modify or delete this kind of relationship.

The dm_relation object has following attributes:

  1. child_id: It is the r_object_id or i_chronicle_id of the child object in this relation. If i_chronicle_id is used, then ‘child label’ attribute can be used to bind the parent object to a particular version of child.
  2. parent_id: The r_object_id or i_chronicle_id of the parent object in the relations. If the attribute ‘permanent_link’ is set to TRUE then only use the i_chronicle_id of the object.
  3. permanent_link: If every new version of the parent object has to be related with the child object, then the value for this attribute must be set to TRUE and i_chronicle_id should be used in the parent_id attribute. By default the value is FALSE.
  4. relation_name: It specifies the value of relation_name attribute of the dm_relation_type object that defines the type of relationship.
  5. child_label <Optional>: If i_chronicle_id is used in the attribute ‘child_id’, then the label of the version of the child object is to be specified here.
  6. description <Optional>: Specifies the description.
  7. effective_date<Optional>: Not used by the system, a user-defined date. Custom logic could check this date to determine the state of the relationship.
  8. expiration_date<Optional>: Not used by the system, a user-defined date. Custom logic could check this date to determine the state of the relationship.
  9. order_no<Optional>: Not used by the system. Custom logic could use this integer value to order a set of relationships.
  • Creation of dm_relation_type object using DQL: The query used to create a dm_relation_type object is as follows:

create dm_relation_type object

set child_parent_label = ‘<Child to parent label>’,

set parent_child_label = ‘<Parent to child label>’,

set description = ‘<Description>’,

set parent_type = ‘<Document type>’,

set child_type = ‘<Document type>’,

set direction_kind = <0 or 1 or 2>,

set integrity_kind = <0 or 1 or 2>,

set relation_name = ‘<Name of Relation>’,

set security_type = ‘<SYSTEM or PARENT or CHILD or NONE>’

  • Creation of dm_relation object using DFC: Following methods which returns an object of type dm_relation can be used to create a dm_relation object.

1. addChildRelative(relationTypeName, childId, childLabel, isPermanent, description): This method has to be invoked on the object which is going to act as Parent in the relation. The parameters it takes are

a)    relationTypeName – Name of a valid dm_relation_type object.

b)    childId – The r_object_id or i_chronicle_id of the child object of the relation.

c)    childLabel – Version label of the child object. If this is ‘null’, the relation will contain no child label.

d)    isPermanent – Specifies if the link permanent. Valid values are TRUE or FALSE

e)    description – Specifies the description for the relation object. If ‘null’, the relation object will not have a description.

2.addParentRelative(relationTypeName, parentId, childLabel, isPermanent, description): This method has to be invoked on the object which is going to act as Child in the relation. It takes the same parameters as the method addChildRelative takes except instead of r_object_id or i_chronicle_id of the child object we pass the r_object_id or i_chronicle_id of the parent object as the parameter parentId.

Note: dm_relation object can be created through DQL also.

Overview on virtual document:

Virtual document provides a way for combining documents in various formats into one consolidated document. For e.g. one word document, one pdf document and one image can be combined to form one virtual document. There is no limitation regarding nesting of documents. One particular version or else all of the versions of a component can be combined with a virtual document. Two object types are used to store information about virtual documents. They are:

  1. Containment Object Type: It stores the information that links a component to a virtual document. Every time a component is added to a virtual document, a containment object is created for that component. The attributes of this object type can be set by the methods AppendPart, InsertPart, UpdatePart.
  2. Assembly Object Type:  An assembly object provides a snapshot of a virtual document at a given instance.

Creation of a virtual document using DFC:

A document can be converted to a virtual document by invoking the method setIsVirtualDocument on it. This method sets the r_is_virtual_doc of the document.

Note: Virtual documents can also be created using clients such as Webtop, DA etc as well as through DQL.

Requirement in the project:

Consider there are three main documents A, B and C. Essentially, A, B and C represent different contracts. Consider another set of documents A1, A2, A3, B1, B2, B3, C1, C2 and C3. A1, A2 and A3 are directly related to A, B1, B2 and B2 are directly related to B, C1, C2 and C3 are directly related to C. Also, A is related to B (A is child, B is parent), B is related to C (B is child and C is parent), and C is related to A (C is child and A is parent). The documents being referred here are Documentum documents of a certain system-defined or user-defined document type.

As per the requirements:

  1. For every new version of the documents the existing relations should be valid.
  2. From the document A, we should be able to navigate to A1, A2 and A3 and also to the documents B and C. Similarly for B and C.
  3. Depending on a particular attribute of main documents (A, B and C), there should be dynamic creation or deletion of relationships between contracts.

Resolution of requirement # 1:

Issue encountered:

Documentation says that when a dm_relation object is created with attribute values permanent_link = TRUE and child_label = ‘Current’ then for every new version of parent or child a new instance of the dm_relation object is created and the relation is created between the latest versions of child object and parent object. But on implementation of the same, always the latest version of the parent object was related to child object between which the relation was initially created.

Issue resolution:

To maintain the relation across the current versions of document and for easy navigation from parent to child documents the concept of virtual documents in addition to that of relationship was used.

All the main documents A, B and C were converted to virtual documents. The child documents A1, A2 and A3 were added as children to the newly converted virtual document A. For this the following DFC methods were used in the same order as specified:

  1. asVirtualDocument(lateBindingValue, followRootAssembly): This method is invoked on a virtual document (in this case on A, B and C) and it returns the virtual document representation of the virtual document object on which it is invoked. The parameters it takes are2.   getRootNode(): This method is invoked on the virtual document representation of a virtual document. It returns the root node of the virtual document. The root node is essentially the virtual document which is at the topmost hierarchy of virtual document tree. (In our case A, B and C are root nodes)
    1. lateBindingValue – the version label of the virtual document. To meet our requirement the value should be “Current”.
    2. folowRootassembly: If the value is set to TRUE, the assembly specified by the root node will be used as the virtual document.
    3. getRootNode(): This method is invoked on the virtual document representation of a virtual document. It returns the root node of the virtual document. The root node is essentially the virtual document which is at the topmost hierarchy of virtual document tree. (In our case A, B and C are root nodes
  2. addNode(parentNode, insertAfterNode, objectChronId, binding, followAssembly, overrideLateBindingValue): This method is invoked on the root node of a virtual document. This method adds a new node to the virtual document on which it is invoked. The parameters it takes are:
  • parentNode: The root node.
  • insertAfterNode: A virtual document node that will immediately precede the new node in the virtual document’s hierarchy. If this parameter is null, the new node is placed as the first child of parentNode.
  • objectChronId: i_chronicle_id of the document which is to be added as child to the virtual document. (In or case i_chronicle_id of A1, A2, A3, B1, B2, B3, C1, C2 and C3).
  • binding: The version label of the version of the child document with which we want to bind the child document with the virtual document.
  • followAssembly: It is set to TRUE if the follow_assembly attribute has to be set to TRUE for the component.
  • overrideLateBindingValue: It is set to TRUE if the version label identified in binding is to be used to resolve late-bound descendents of this component.

So using the concept of virtual document always the current versions of document are present in the parent virtual document. Thus the current versions of A and A1, A2, A3 are always related. And since A has been converted to virtual document, we can navigate to A1, A2 and A3 by just clicking on A.

Resolution of requirement # 2:

Now using the concept of relationship, a relation was created between A and B, B and C, A and C each. Thus navigation across the different contracts A, B and C was possible. Pictorially this can be shown as:

Figure-2

In the above figure the arrow denotes the relationship between two documents.

Resolution of requirement #3:

Requirement #3 states that there should be dynamic creation or deletion of relations between main documents depending on a particular attribute, say, attr. The value of attr for, let’s say, document A determines to which document, A will act as child. If the value of attr for document A is changed so as to imply that A and B are no longer related, then the relation object existing between A and B should be destroyed. If the new value points toward new document D, then a relation has to be created between A and D.

So the change in value of that particular attribute needs to be intercepted. The interception can be done as follows:

  1. Write a TBO (Type based object) for the document type to which A belongs to.                

 Note: For details on TBO refer BusinessObjectsDevelopersGuide.pdf provided by Documentum.

  1. In the TBO, override the method setString(attribute name, value of attribute), if the attribute attr is single-valued attribute or appendString(attribute name, value of attribute), if it is multi-valued attribute. These two methods captures all the attributes and their values for a document type. setString captures the single-valued attributes while appendString captures the multi-valued attributes.
  2. In either of the method, compare the old value of attribute attr with the new one. If there’s any change destroy all the existing relations which involves the document A as child. This can be done using the DFC method removeParentRelative(relationTypeName,parentId,childLabel).  Invoke this method on A. The parameters it takes are:Now use the method addParentRelative as explained, to relate document D as parent to document A.
    1. relationTypeName – Name of the relation object.
    2. parentId – r_object_id of parent object.
    3. childLabel – version label of child object.
  3. Every time the value is changed for attribute attr and the document is saved, the corresponding TBO is invoked and the above mentioned methods will be executed. Thus dynamic creation or deletion of relations can be achieved.

Conclusion: Thus the concept of relationships and virtual documents can be used together to relate objects in Documentum using Documentum Foundation Classes (DFC).

Installing Documentum TBO using Composer

May 12, 2011 3 comments

Introduction:

The Business Object Framework (BOF) is a set of functionality that provides ability to hook into any of the methods in the standard DFC object interfaces.

BOF’s are of two kinds:

  1. Type Based Object(TBO)
  2. Service Based Object(SBO)

TBO’s are used when only one object type needs its functionality overridden whereas, we use a SBO when the functionality is overridden for different object types or in case we want to use the functionality in many other TBO’s.

The main use of TBO is the ability it gives a developer to override selected functionality of the DfSysObject or any of its child types.

Module 1: Creating the TBO

Steps to be followed for creating a TBO jar

  1. Create a java class using the same name as the object type.
  2. The java class will have to extend DfDocument and will have to override its 4 functions getVersion, getVendorString (), isCompatible (String s) and supportsFeature (String s)
  3. Then it will have to override the function that the tbo is needed for example doSave () etc.
  4. Compile this class and make a jar of it.

Module 2: Installing the TBO

Steps for installing the TBO in the docbase

  1. Create a new Documentum project in Composer
  2. Right Click on Artifacts and select New>>Other. In the New screen select Documentum Artifact>> Jar
    Definition

 

Click on Next, and in the Artifact name field enter the name of the object type and click finish

 3. Now for configuring the new jardef that we created. Since we have created only an implementation of the TBO, select Type field as Implementation. And  in the jar content browse and choose your jar file that was created in the Module 1.

4. Right Click on Artifacts and select New>>Other. In the New screen select Documentum Artifact>> Module

Click on Next, and in the Artifact name field enter the name of the object type and click finish

5. Now for configuring the new module that we created. In the Info tab select TBO from the drop down menu for Type.

6. In the Core JARs tab select Add for Implementation JARs and select the jardef created in previous step. Now click on Select in front of class Name this will display the class details of the jar in the jardef select the appropriate class.

7. Right click on Project and select the “Install Documentum Project” menu item.

Enter the username and password and click on Login button. The user will be authenticated and the Next and Finish buttons will become active. Click Finish to install the TBO into the docbase. This may take some time.

 Now whenever an object of the type for which the TBO was created is invoked or created the TBO will be fired. The TBO can be found at Cabinets>>System>>Modules>>TBO

 Module 3: Re-Installing the TBO

In case the java class has been modified, then the TBO needs to be re-installed. The steps to re-install TBO are as follows

  1. Delete the folder with the TBO name in the location (Cabinets/System/Modules/TBO)
  2. Recreate the jar using the new java file.
  3. In Composer remove the jar file from the jardef and add the new jar file
  4. Reinstall the Project to the docbase.

How to Use the savelock() and checkInEx(…) methods in TBO ?

May 11, 2010 Comments off

1.saveLock (…) Method:

saveLock method can be overridden when not using a template for creation of document as discussed in my earlier post.

Also the method can be overridden in following scenario:

For modifying a document’s metadata, one doesn’t have to checkout a document in WebTop. Any validations which need to be done if metadata for a document is changed can be incorporated in this method.

Code snippet:

public void saveLock() throws DfException{
IDfSession session = null ;
IDfPersistentObject docObject = null ;
try{
session = getSession() ;
docObject = session.getObject(getObjectId()) ;

}catch( Exception e ) {

// failed to create

if( e instanceof DfException )
throw (DfException)e;
throw new DfException( DfException.DM_NOTDFC_E_JAVA,
e.toString() );
}

// CREATING FOLDER STRUCTURE WHEN NO TEMPLATE

if(docObject.getString(“subject”).equals(“false”)){
// create folder structure
docObject.setString(“subject” ,”true”);
}

// CAN DO ANY VALIDATIONS IF META DATA IS MODIFIED.

super.saveLock() ;
}

2.checkInEx(…) Method:

The method will be invoked before the document which is checked out gets checked in. The operations which can be done in this method can be like applying life cycle to the document, maintaining relationships between different types of documents.

Code snippet:

public IDfId checkinEx( boolean fRetainLock, String strVersionLabels,
String strOldCompoundArchValue, String strOldSpecialAppValue,
String strNewCompoundArchValue, String strNewSpecialAppValue)
throws DfException {

//applying lifecycle

//applyLifeCycle(docId, “”) ;

// CAN DO OTHER OPERATIONS BEFORE CALLING SUPERCLASS’S METHOD.

IDfId docId = super.checkinEx( fRetainLock, strVersionLabels,
strOldCompoundArchValue,strOldSpecialAppValue,
strNewCompoundArchValue, strNewSpecialAppValue );
return docId ;
}

Categories: DOCUMENTUM Tags: , ,

How and When to Use Save() method in TBO ?

May 10, 2010 Comments off

The save method can be used in TBO class to extend the default behavior and provide own custom implementation for validations and so on.

Generally , Creating a document in WebTop involves 3 steps: filling the ‘Create’ tab, ‘info’ tab, and ‘Permissions’ tab. User has to click on Next and Finish buttons to complete the activity of creating document. Also user has the option to select a document template in the ‘Create’ tab. This selection of template and clicking of buttons Next and Finish needs to be captured.

Consider a case in which a new document is created in WebTop and based on attributes entered in the document metadata (fields in ‘Info’ tab) a folder structure needs to be created.

save() method can be overridden in the TBO class for different scenarios: When document is created in WebTop using a template and when not using a template.

CASE 1 : When a template is used for creating document in WebTop, before the Finish button is
clicked,

1) The version label attribute (r_version_lablel) of the document object is always updated as ‘1.0, Current, _NEW_’.

2) Also, save() method in the TBO class is called twice, once when NEXT button is clicked on ‘Create’ tab and second time when Finish button is clicked.

CASE 2 : When no template is used for creating document (for example: creating documents without
any content)

1) The version label is always 1.0, Current.

2) The save() method is called only once, when NEXT button is clicked in ‘Create’ tab. When Finish button is clicked, the method called is saveLock().

While using TBO for custom object type, we can use a dummy attribute and r_version_label attributes to keep track of which button is clicked in the above two scenarios. The reason for this kind of check is the folder structures should get created only when Finish button is clicked. Otherwise the folder structure created needs to be deleted if the user clicks on Cancel button while creating document.

Below if the Code Snippet illustrating the same:

public void save() throws DfException {
IDfSession session = null ;
IDfPersistentObject docObject = null ;
try{
session = getSession() ;
docObject = session.getObject(getObjectId()) ;
}catch( Exception e ) {

// failed to create

if( e instanceof DfException )
throw (DfException)e;
throw new DfException( DfException.DM_NOTDFC_E_JAVA,
e.toString() );
}

// THE ATTRIBUTE ‘subject’ CAN BE A DUMMY ATTRIBUTE

if(docObject.getString(“subject”).equals(“”)){
docObject.setString(“subject” ,”false”) ;
}
super.save();
try{
docObject = session.getObject(getObjectId()) ;

// RETRIEVING THE VALUES OF THE ATTRIBUTE ‘r_version_label’

String str =
docObject.getAllRepeatingStrings(“r_version_label”,”,”) ;
if(str.indexOf(“_NEW_”) > 0 ){

// WITH TEMPLATE

docObject.setString(“subject”,”true”) ;
super.save();
}else{
if(docObject.getString(“subject”).equals(“true”)){

// WITH TEMPLATE, FINISH button

docObject.setString(“subject”,”false”) ;

// can create folders

}
}
}catch( Exception e ) {

// failed to create

System.out.println(“exception :”+e.toString());
if( e instanceof DfException )
throw (DfException)e;
throw new DfException( DfException.DM_NOTDFC_E_JAVA,
e.toString() );
}
}
}

In my next post i will try to discuss how to use the savelock() and checkInEx(…) methods.

How to invoke SBO from TBO ?

May 9, 2010 Comments off

One can invoke SBO from a TBO by using following code snippet in a method of a TBO class.

The method can be called from save(), checkInEx(…) method or in any custom methods
defined.

IDfSession session = getSession() ;
String docBaseName = session.getDocBaseName() ;

IDfSessionManager sMgr = session.getSessionManager() ;
IDfClient client = session.getClient();

ICreateFolderSBO folderSBO = (ICreateFolderSBO)
client.newService(ICreateFolderSBO.class.getName(),sMgr);

String documentId = session.getObjectId() ;
folderSBO.createFolder(documentId, docBaseName);

Categories: DOCUMENTUM Tags: , ,

BOF in Documentum: TBO & SBO implementation

May 6, 2010 Comments off

TBO/SBO implementation will have two java components associated with them, one will be the interface exposing methods (if necessary) to other TBO/SBO created in the application. The other component will be the implementation of the interface.

In this section, we will implement TBO for a custom object type com_test_document. The java class used for the custom object type will let you apply custom lifecycle ‘test_lifecycle’ already defined in DocBase to the document at the time of creation of document. The TBO class implemented for this custom object type will get instantiated when creating a document of the custom object type using WebTop.

To create custom object type, one can use Documentum DA. The custom object type ‘com_test_document’ will extend ‘dm_document’ (default object type) provided in the Documentum.

Following is the code snippet for the TBO interface and implementation class.

package com.test;
import com.documentum.fc.client.*;
import com.documentum.fc.common.DfException;
public interface ICacirTBO extends IDfBusinessObject {
// no methods to be exposed in this example
}

The first four methods in the next code snippet are mandatory, as these are abstract
methods in the class hierarchy.

package com.test;
import com.documentum.fc.client.*;
import com.documentum.fc.common.*;
import com.documentum.com.*;
import java.util.HashMap ;
import java.util.ArrayList ;
public class DocTestTBO extends DfSysObject implements IDocTestTBO {
public static final String strCOPYRIGHT = “Copyright (c) Documentum, Inc., 2002”;
public static final String strVERSION = “1.0”;
IDfClient client = null;
public String getVersion() {
return strVERSION;
}
public String getVendorString() {
return strCOPYRIGHT;
}
public boolean isCompatible( String s ) {
return s.equals(“1.0”);
}
public boolean supportsFeature( String s ) {
String strFeatures = “dm_document, subclassing”;
if( strFeatures.indexOf( s )== -1 )
return false;
return true;
}

/**
* Can be overridden for business logic implementation
*/

public void save() throws DfException {
super.save();
}

/**
* Can be overridden for business logic implementation
*/

public void saveLock() throws DfException{
super.saveLock() ;
}

/**
* Lifecycle applied to the document is hardcoded in this method.
* Best Practice would be to pick the lifecyle name from properties file, based on
* document type.
*/

public IDfId checkinEx( boolean fRetainLock, String
strVersionLabels, String strOldCompoundArchValue,
String strOldSpecialAppValue, String strNewCompoundArchValue,
String strNewSpecialAppValue ) throws DfException {
IDfId documentId = getObjectId() ;

// APPLYING LIFE CYCLE TO THE DOCUMENT

applyLifeCycle(documentId, “test_lifecycle”);
IDfId docId = super.checkinEx( fRetainLock, strVersionLabels,
strOldCompoundArchValue,strOldSpecialAppValue,
strNewCompoundArchValue, strNewSpecialAppValue );
return docId ;
}

/**
* The method applies lifecycle to the document, before it is
* checked in.
* The method attaches the lifecycle to the document.
* @param IDfId objectId of the document
* @param String lifecycleName, can be from properties file
* @throws DfException
*/

private void applyLifeCycle(IDfId docId, String lifecycleName)
throws DfException {
if ((lifecycleName == null) || (lifecycleName.length() == 0)){
throw new IllegalArgumentException(“No lifecycle name specified.”);
}

IDfSession session = getSession();
StringBuffer bufQual = new StringBuffer();
bufQual.append(“dm_policy where object_name='”).append(
lifecycleName).append(“‘”);

IDfId policyId =
session.getIdByQualification(bufQual.toString());
if ((policyId == null) || (policyId.isNull()))
{
String msg = “Unable to locate the lifecycle to be
applied”;
}
IDfSysObject policyObj = (IDfSysObject)
session.getObject(policyId);
String firstStateName =
policyObj.getRepeatingString(“state_name”, 0);

//apply lifecycle to the new version.

IDfSysObject sysObj = (IDfSysObject) session.getObject(docId);
sysObj.attachPolicy(policyId, firstStateName, “”);
}
}

The compiled classes should be in class path of Application server. Once the TBO classes are
written, make sure you put the entries for the object type in dbor.properties file, as mentioned above in section 2.

com_test_document=type,com.test.DocTestTBO,1.0

* 1.0 mentioned in the code snippet matches with the version mentioned in dbor.properties.

Following is the code snippet for the SBO interface and implementation class . The SBO code snippet below is for creating folder and linking the ‘document id’ passed as input parameter in the new sub folder thus created.

package com.test;
import com.documentum.fc.client.*;
import com.documentum.fc.common.*;
import java.util.* ;
public interface ICreateFolderSBO extends IDfService {

/**
* The method is exposed, can be used in other business objects.
*/

public IDfId createFolder(String objectId, String docBase) throws DfException ;
}

package com.test;
import com.documentum.fc.client.*;
import com.documentum.fc.common.DfException;
import com.documentum.fc.common.*;
import com.documentum.com.*;
import java.util.*;
public class CreateFolderSBO extends DfService implements ICreateFolderSBO {

/**
* A string providing information regarding the vendor of the BO.
*/

private String m_strVendorDescription = “Documentum Developer Program”;

/**
* Version of the service-base BO
*/

private String m_strVersion = “1.0”;
public String getVendorString() {
return “Copyright (c) Documentum, Inc., 2002”;
}
public static final String strVersion = “1.0”;
public String getVersion() {
return strVersion;
}
public boolean isCompatible(String str) {
int i =strVersion.compareTo(getVersion() );
if(i <= 0 )
return true;
else
return false;
}

/**
* The method gets called from the TBO's, for creating folder structures.
* The method unlinks the document object passed as input parameter from the current
* folder.
* The method creates subfolder under the current folder and links the document to the
* new folder.
* @ param String objectId
* @ param String DocBase Name
* @ throws DfException
*/

public void createFolder(String objectId , String docBase) throws DfException{
IDfSession session = getSession(docBase);

// dm_folder is existing object type in docbase

IDfSysObject docObject = (IDfSysObject)
session.getObject(objectId);

// Get the immediate parent folder to the document

String strSourceFolder = docObject.getFolder(0);
IDfFolder newSubFolder1 = (IDfFolder)
session.newObject(“dm_folder”);
newSubFolder1.setObjectName(“test_folder”);
newSubFolder1.link(strSourceFolder);
newSubFolder1.save() ;

// remove link from parent folder

docObject.unlink(strSourceFolder);
String strDestFolder = newSubFolder1.getObjectId().getId());

// Add link to subfolder

docObject.link(strDestFolder);
docObject.save() ;
}
}

The compiled classes should be in class path of Application server. Once the SBO classes are
written, make sure you put the entries for the object type in dbor.properties file, as mentioned above in section 2.

com.test.ICreateFolderSBO=service,com.test.CreateFolderSBO,1.0

* 1.0 mentioned in the code snippet matches with the version mentioned in dbor.properties.

Once SBO and TBO classes are properly configured, restart the Application Server. To check whether TBO is getting invoked on creation of new document (of type com_test_document) using WebTop, look at the Weblogic console for instantiation of the TBO class, alternatively check whether lifecycle is attached to the new document object created using WebTop.

Categories: DOCUMENTUM Tags: , , , , ,

DBOF Configurations

May 5, 2010 Comments off

We Know DBOF lives wherever DFC lives, either on the Content Server or Application Server, or on any of the other clients. The following Steps need to be tracked when we are trying to configure DBOF :

1) Configure DMCL.ini to both access DocBase and enable session pooling. Add the following entry to the [DMAPI_CONFIGURATION] section :

connect_pooling_enabled = T

When installing Documentum, a file with the name DMCL.ini is created in the folder

‘:/SYSROOT\system32’.

Example: C:/SYSROOT/system32.

2) Make sure dfc.jar is referenced by the CLASSPATH environment variable of your JVM running the application, dfc.jar is in ‘Shared’ folder under Documentum installation folder.

Example: C:/Program Files/Documentum/Shared

3) Make sure dmcl40.dll is in a directory referenced by the PATH variable. By default the file is placed in folder C:/Program Files/Documentum/Shared.

4) The DFC_DATA system variable must refer to the directory containing Documentum configuration information, usually C:\Documentum. This needs to be a directory that has an immediate subdirectory called C:\Documentum\config. This is where the dbor.properties file is also located.

5) Make sure TBO classes and SBO classes are configured in dbor.properties file on
Application Server.

6) The dbor.properties is editable file. As part of best practices the file should be edited by a program using IDfDbor and IDfDborEntry interfaces provided in DFC classes.The entries in dbor.properties file will
look like:

doc_request=type, com.bp.customObj.DocumentRequestTBO, 1.0
com.bp.customObj.ICreateFolderSBO=service,com.bp.customObj.CreateFolderSBO,1.0

DocumentRequestTBO, ICreateFolderSBO and CreateFolderSBO are the java classes
created for providing our own business logic.doc_request is the custom object type defined in DocBase. One can create custom object types using Documentum DA. ‘type’ represents Type Based Object followed by full class name, 1.0 represents the version number of the class to be used.

The second line represents the mapping of SBO, as the identifier ‘service’ mentions.

7) Make sure TBO and SBO compiled classes are accessible from class path variable on
Application server.

I will try to bring in how to implement the concept of BOF in Documentum in my coming Posts.

Appreciate your comments.

Categories: DOCUMENTUM Tags: , , , , , , ,
%d bloggers like this: