Copy documents from one docbase to another(different object types)

DFC 6.7

I have a requirement to copy documents from one docbase to another using DFC. However, the trick is that, the source and target object types are different (but somewhat similar). I have a mapping for the attributes. What would be the best way to approach this from a DFC perspective? I assume idfCopy doesn't help here because of the different types.

Here is a list of high level steps I was thinking of:

- Get a session in source docbase

- Get a session in target docbase

- Read attributes from source and write to the new type in target

something like trgObject.setString("srcAttribute", srcObject.getString("trgAttribute"));

- Get content from source and set it on the target object

something like

ByteArrayInputStream baisContent = srcObject.getContent();

int numOfBytes = baisContent.available();

byte inputBuffer[] = new byte[numOfBytes];

int bytesRead = baisContent.read(inputBuffer, 0, numOfBytes);

ByteArrayOutputStream outStreamContent = new ByteArrayOutputStream(bytesRead);

outStreamContent.write(inputBuffer, 0, numOfBytes);

trgObject.setContent(outStreamContent);

Any other suggestions are greatly appreciated!

Find more posts tagged with

Documentum

Comments

Haroon_A

You are on the right track. But the only thing to consider, is to use a user that exists on both environments, because you will need to connect to both environments at the same time. i.e.

get source sessionget target session read all object ids from src docbase into a collection (select r_object_id from my_type where <...>) while (collection.has object) {          get object from src (src_session.getObject(r_object_id)           create an object in target, using target session (trg_session.newObject(my_other_type)          trget_object.setString("my_attr", src_object.getString("my_attr"))          .. so on          target_object.save()}

You may need to consider setting a flag for each object that has been successfully copied to your target docbase. i.e. updating an unused attribute. This is a good idea, say if your program needs to be run for the second time, in that case you don't want to re-do the tasks for the objects that have already been processed.

Begin T

What about creating the same object type in the target docbase? I was thinking it is easier since I could use IdfCopy (less lines of code). But I am not sure if it is a good idea to create the same object type in two docbases. I am afraid, we would end up changing the target object type attributes (add new attributes etc...), and thus they become out of synch...Does anyone have any insight into this?

By the way, I should have mentioned this in my original post. The copy is not a one time operation. The requirement is that...user would initiate this copy request fromt he application...to copy certain objects to another docbase real time.

DCTM_Guru

First of your, the problem you are trying to solve is very complex and I applaud you for trying to tackle this challenge.

With respect to changing the object type definition, this depends on who is the "owner" of the object type definition. The same question applies to your existing problem of mapping values from one type to another type. Which type is the "master" definition?

Let me use simple example.

srcAttribute defined as str(32), trgAttribute defined as str(16)

How are you handling this now? I'm guessing you truncate the value or put this in exception processing. By truncating, the target is really the owner. If you decide to extend the length, then the source is the owner. If you feel like that the source is the "owner" more times than not, then replicating the new attribute definitions is acceptable.

This is how OOTB object replication between docbases work - same object type must exist in both source and target.

Haroon_A

If you know your type changes, then IMO, it's better to copy it as your new type -- avoiding a conversion later. Another thing to consider, if you are dealing with versions (multiple versions of the same object), then IDfCopy operation only copies the current version.

Begin T

Thanks Johnny and Ahmad for your valuable inputs.

First of all, we wouldn't be facing this issue if there was only one docbase! The second docabse got created on a better hardware, so we are trying to take advantage of the newer hardware (for performance reasons etc..) To answer Johnny's question, source is going to be the master.

Ahmad, all documents will have only one version. I do understand that there will be a massive conversion later. We have done that kind of conversions/migrations before. So we are prepared to do that. The more I think about it, I am leaning towards creating the same object type in the target docbase.

sanjeev6282

Using DFC operations would never give you the real time data, its gonna be slow, especially when you are to establish 2 sessions [ Source, Target] and then initiate the copy.

Any possibilities you have access to any of the ETL tool, suggesting this here because you mentioned that you want to place the copied content under new object type and there can be addition/deletion of attributes, which could very well be handled in the "Transform" stage.

If "ETL Tool" is not the option, then in my opinion, you will have to write 2 DFC code:

1) one to extract the content and the metadata from the source.

2) The second code to connect to the target, transform each content file and then load them to the target.

Haroon_A

You may want to refer to this thread, might be of some interest; once I had to deal with this type of scenario.

https://community.emc.com/thread/21565?start=0&tstart=0

Nickie

You may want to try OpenMigrate: http://www.tsgrp.com/Open_Source/OpenMigrate/open-migrate.jsp.

It is designed to easily execute migrations from one repository to another and supports object type and metadata mapping as well. OpenMigrate is open source and its download contains a number of sample migrations that make getting a basic migration up and running very simple.

I am the OpenMigrate product manager for TSG. Feel free to contact me or openmigrate@tsgrp.com with any questions.