with DFS&UCF, who to re-open local editted, checked-out files?

Hi all,

I had this issue before in DFS6.0sp1, but ugraded to 6.5sp1.

We have a DFS-consuming web-application that servers some webpages. On the webpage we have a UCF applet, that gets the uid and jsessionid needed to start the UCF transfer in DFS.

On the client we can check a document out and open it in the associated editor. (We use hte VersionControlService.checkout). UCF takes care of all the details.

However, we want to re-open a locally editted file on the client (just like webtop -> edit does).

Using objectservice.get or versionservice.getCurrent we both get a new, read-only file, instead of the locally editted file.

In the activityinfo we pass this:

new ActivityInfo(j_session_id, null, uid, null, true);

We set this ActivityInfo in the ContentTranseferProfile of the serviceContext.

We also use OperationOptions with a contentProfile. This contentprofile has a setPostTransferAction("dfs:edit");

What should we do to re-open the locally editted file?

Thanks in advance.

Find more posts tagged with

Comments

RaviJha

Looks to me like a feature un-implemented in DFS.

But it should not be very difficult to implement it.

The current behavior of DFS can be called buggy because if you get a read-only copy then probably it is trying to re-checkout the document instead of looking for whether the file already exists in the client file system in case it is locked by same user in the repository.

As UCF has the capability to look up registry for checkout path and also launch the default/specified application to edit the document so it should be possible for DFS (which uses UCF) also to be able to do it.

I think you should raise a feature request for this.

While DFS implements this functionality, there is a (obvious) workaround:

Go to %USERPROFILE%/Documentum/ucf/<hostname>/shared/config/ucf.client.config.xml file, look for "checkout.dir" option.

The value of this option decides where edited files will go.

So you can just navigate to your files and manually edit them using your application and check them in.

AdrianBuza

Hello,

We have encountered the same issue. We need to edit an already checked out resource and can't find a way to programmatically obtain the file.

I don't find the obvious workaround very useful, at least not in a programmatic way, because the filenames of the checked out resources from the %USERPROFILE%/Documentum/Checkout (the default checkout dir) are sometimes different from the object name. This happens when you checkout several resources with the same name(one of them will be renamed and have a suffix like '_2') or a resource with a name that would be illegal in the file system. That makes the name matching approximate at best.

Does anyone have any idea if this has been addressed in 6.5SP2?

Regards,

Adrian Buza

----------------------------

Oxygen XML Editor

RaviJha

Hi,

You are correct. We can never rely on the object name to find the name of locally checked out file.

As I said before,

UCF has the capability to look up registry for checkout path given the object id of the checked out object and also launch the default/specified application to edit the document so it should be possible for DFS (which uses UCF) also to be able to do it.

Basically this is what you need to do.

I will try to find out if this is possible in DFS yet or not.

Ravi

AdrianBuza

DFS doesn't seem to have the API to do this, not even in 6.5SP2. However we have found a workaround.

So basically we are using the UCF client jars that come with the DFS SDK 6.5: 'ucf-client-api.jar', 'ucf-client-impl.jar'

and call:

IRegistryService registryService = ClientFactory.getRegistryService();
IRegistryItem registryItem = registryService.getRegistryItem(IRegistryService.CATEGORY_CHECKED_OUT_FILES, id);

The registryItem has all the needed info, including the local file path.

It works but only if we set the 'java.library.path' to point to 'UCFWin32JNI.dll'.

This is a bit of a problem because we are using it in a larger application and cannot/should not set parameters at launch time.

I'm guessing there could also be problems with our workaround because of the different versions of UCF client. The UCF client from the SDK, which we are using, is an older version than the one that is deployed from the server(6.5SP2) when making DFS calls with UCF transfer.

My first question would be: How safe is this workaround?

And my second question: Is there a better, maybe safer way of loading/using the UCF client that does not involve hacks on our part?

Regards,

Adrian Buza

----------------------------

Oxygen XML Editor

zhou_simonq

Pls refer to another discussion https://community.emc.com/thread/3992?tstart=0

From the last two posts, you can see that when can get UrlContent when ACS is enabled. This UrlContent is actually an URL link and can be used to get the content of the document. Then you can store the content in a file with a customized name.

Actually, when UCF is used to transfer the content, you can open the document in a viewer/editor. For more info, pls refer to page 174 of DFS dev guide version 6.5

-simon