DFC 6.5 SP2 - checkout / checkin and replace content

Based on one of our process requirements, we need to create a major version of an object and replace the content with another object.

I know it's possible using the combination of the following methods / classes

IDfCheckOut and IDfCheckIn operations and use IDFSysObject's getContent and setContent methods.

Before I jump into it, I wanted to check with all the experts out there, is there an efficient / better way of doing this ? is there a way to replace the next major version an object with another object ? (both in documentum) or something completely different ??

E.g

object A - version 1.0

object B - version 1.0

after the "magic" process

object A - version 2.0 (with the content of object - doesn't matter what happens to object B, if its still a separate object.

Thanks a lot in advance.

Find more posts tagged with

Documentum

ApplicationXtender

Comments

Amit Gaikwad

Hi Fenil,

The procedure you have mentioned in standard process. Please see the below api for CheckIn:

checkin

IDfId checkin(boolean keepLock, String versionLabels) throws DfException

Creates a new version of this object and removes the lock from the previous version.

To use the checkin method, the following conditions must be met:

The object must have been retrieved from the repository with a checkout method.
The user must have at least Version permission on the object.
The user must have at least Write permission on the cabinet or folder in which the object is stored if the repository is running with folder security.

Note: Folder security is on by default when a repository is configured. The folder security setting is recorded in the folder_security attribute of the docbase config object. The checkin method unlocks an object and saves any changes you may have made to either its attributes or its content. (Note that to make changes to the content, you must issue explicit methods, such as getFile and setFile, to get and set the content after you checkout the object and before you issue the checkin).

Executing this method clears the object's r_lock_machine, r_lock_owner, and r_lock_date attributes and sets the a_archive attribute to FALSE. Additionally, if the object is a policy object, the method sets the r_definition_state to DRAFT for the new version and clones the following attributes:

entry_criteria_id
user_criteria_id
action_object_id
user_action_id
type_override_id

The primary content associated with the new version is stored in the storage area specified in default_storage attribute of the content's dm_format object if that attribute is set. If the storage area is not defined in the format object, the content is stored in the storage area identified in the default_storage attribute of the object's object type. You can override either default storage area by executing an explicit method to set the a_storage_type attribute of the object before the check in.

The following code example demonstrates how to checkin an object using the default version labels, and to not retain a lock on the newly created version:

 IDfSysObject sysObj = (IDfSysObject)sess.getObject(new DfId("0900d5bb8001fd49")); if (sysObj.isCheckedOut()) { sysObj.setFile(sysObj.getObjectName()); IDfId newSysObjId = sysObj.checkin(false, ""); }

Parameters:: keepLock - set to true to place a lock on the newly created version.; versionLabels - defines the version label for the new version. You can specify more than one label. If you do not define a label, the server automatically gives the new version an implicit version label and the symbolic label "CURRENT".
Returns:: the object id of the new version of the object.
Throws:: DfException - if a server error occurs.

Thanks and Regards,

Amit G

fenil

Thanks Amit for the your reply. I could not find anything different either than what I had described in my question so going ahead with that process.

PanfilovAB

You can use IDfSysobject.bindFile if your sysobjects have same content-type

fenil

Thanks. I had no idea about this method. Need to give this a try but after reading about it seems like its a viable option.

Haroon_A


PanfilovAB wrote:

You can use IDfSysobject.bindFile if your sysobjects have same content-type

PanfilovAB - Just for my info. What will happen to object A's content if you update (check-in with new content) content of objects B, which are bind? Will it then split the content in to two separate physical content? or it will change the content of second object as well with the same content and keeps only single physical content at all times?

fenil

This link may answer your question

EMC Documentum Platform Essentials: How to set the same content on multiple objects

Haroon_A

Thanks for the link. but it still doesn't address the question (if the content of second object is replaced as well when doing a check-in on first object).

PanfilovAB


Ahmad Sakhi wrote:

What will happen to object A's content if you update (check-in with new content) content of objects B, which are bind?

Nothing

bacham2

Content Server always creates a new dmr_content object (even if you checkin as same version) and never overwrites files on the file system. So if two objects share a dmr_content file, after changing one of them, the latter will point to a new dmr_content object and file. So there are no issues here.

In other words, bindfile is just an technical optimisation and doesn't have any functional impact.

Haroon_A

Thanks for the info, Hacham. So, even the two objects have now two separate dmr_content. Now the underlying actual physical content (Document) on the filestore as well duplicated (one for each object?), correct? If yes, then my question was is this 'copy' of content happens when you bind? or when you do a 'check-in' of one o bind.PNG.png f the two objects with new content?

Haroon_A

So I did a few test myself and this is what I observed.

object 1 = TestA (Doc1.pdf)

object 2 = TestB (Doc2.pdf)

did a bindfile of the two objects TestA as target. Now

object 1 = TestA (Doc2.pdf)

object 2 = TestB (Doc2.pdf)

Now I did a checkout of TestB (with content Doc3.pdf), and result

object 1 = TestA (Doc2.pdf)

object 2 = TestB (Doc3.pdf)

Now I did a check out of TestA (with content Doc4.pdf), and result

object 1 = TestA (Doc4.pdf)

object 2 = TestB (Doc3.pdf)

So, it seems that when bind happens, both objects have the same content, but when any one of the objects is checked in with new content, they no longer have the same content. Exactly what you two suggested. Thanks guys.

But one thing is still not clear to me. In step 2) when we do bindfile, does the content server create a copy of the physical document (Doc2.pdf) in the filestore? or the same document is referenced by both objects?

bacham2

It doesn't make a copy. That's the point. Since there is only one dmr_content object, there can be only one file.