DFS - Getting file name of checked out document

Hi there,

I'm amazed, surprised and very disappointed with DFS 6.7 SP1 and UCF.

I have an application that checks out a document. So far so good, at check out time, I get the content file name.

Now, the thing is that if the user exits the application, without checking in or cancelling the check out. I can't get the file name

After searching on the ECN, I saw it doesn't seem possible.

What's the point of DFS then, seems to me like a basic functionality or does EMC expect that working on a document can and SHOULD be done in a day so users can check in in the evening before going home....

Anybody found a way around that ?

Find more posts tagged with

Note:

If there are Accepted Answers, those will be shown by default. You can switch to 'All Replies' by selecting the tab below.

Accepted answers

abc123

Hi,

For your 1st question. It is possible to specify a client program. Please take a look at ContentProfile.SetPostTransferAction().

Sets the command to handle the contents on client side after the transfer has been completed. It is used only for UCF transfer mode. (ContentTransferMode.UCF)

Command examples:

"dfs:view"	runs the default viewer for each returned content
"dfs:edit"	runs the default editor
"dfs:edit?app=notepad"	runs the custom editor (notepad)
"dfs:edit?app=java&-cp&\"c:\\Program Files\\javacustomapp\\app.jar\"&com.emc...ContentHandler"	runs the custom content handler OS equivalent is: c:\> java -cp "c:\Program Files\javacustomapp\app.jar" com.emc...ContentHandler ContentsFileName

For your 2nd question, I am sorry I just remembered it doesn't work by default. There has been an enhancement in DFS 6.7 for this problem but it was not published as for internal use. So following approach is just for you to experiment:

serviceContext.SetRuntimeProperty("RUN_UCF_ACTION_ON_SUBSEQUENT_CHECKOUT", "true");

This runtime property will make the 2nd checkout workable if both checkout are performed by UCF. Hopefully you can see it in user guide of next major release.

Regards,

William

All comments

Francois Dauberlieu

I completely agree with you, it seems indeed basic to me too

Let us know if you find a work around, might be interesting for every developer

abc123

Hi,

Can you please share more about "Now, the thing is that if the user exits the application, without checking in or cancelling the check out. I can't get the file name"? How do you get the file name of a checkedout document with DFS operation? What is the error?

Sample code is appreciated.

Thanks,

William

Buddy

William,

Actually, I don;t get any errors, it's more a How To.... question:

Basically, my app is a specific XML editor. It's a VB.NET windows form application

The user runs the app, connect to the docbase to get an XML doc.

The XML Doc is checked out and opens in the app's editor.

So far so good.

Now, the thing is that the user can close the application without needing/wanting to check in the document (coffee/smoke break or whatever other reason).

When the user restart the application, he could re-open the file from the file system, which is not handy because then he has to know where it is and to be bullet proof, I have to assume my user is bad (now, that's something a developer has never heard of ;-).

The user connects to the CS, browse the docbase and get to his document, which is already checked out/

Here comes the issue I'm facing:

I can find out if the document is already checked out or not. If it is not, no problems, I check it out and get the content info from the DataPackage

However, and that's the problem, if it's checked out already, by this user on this machine, how do I find the local file ?

I couldn't find anything in the doc about that and when I searched the ECN, all the infos I found where that it's not implemented in DFS. As said before, I find it a bit weird as this is quite a basic operation an application would do and an application shouldn't have to reinvent the wheel by maintaining it's own kind of checked out docs register, which shouldn't be too big to do but would be redundant since the UCF already has its own register

Any pointer you could give me would be more than welcomed

abc123

Hi,

DFS web service opreation is stateless, meaning the subsequent operation doesn't know the context of previous operations. The exception is for UCF content transfer. As you probably knows, UCF client writes the file info to registry for a checkout or an export operation. So it is feasible to ask UCF client to re-open the local working copy file.

Here is an example -- the file path is same for multiple checkout as long as you havn't checked it in

public void RepeatableCheckoutForEdit(string id)

{

IServiceContext serviceContext = getServiceContext("core");

IVersionControlService versionService = ServiceFactory.Instance.GetRemoteService<IVersionControlService>(

serviceContext,

"core",

"url" );

ContentTransferProfile ctp = new ContentTransferProfile();

ctp.TransferMode = ContentTransferMode.UCF;

ContentProfile cp = new ContentProfile(FormatFilter.ANY, "", PageFilter.ANY, 0, PageModifierFilter.ANY, "");

cp.PostTransferAction = "dfs:edit";

OperationOptions options = new OperationOptions(null, ctp, cp);

ObjectIdentitySet idset = new ObjectIdentitySet(new ObjectIdentity(new ObjectId(id), getDefaultRepository()));

DataPackage result = versionService.Checkout(idset, options);

Console.WriteLine("Document is open for editing..." + result.DataObjects[0].Contents[0].GetAsFile().FullName);

}

As long as you remember the checkedout doc ID by your application. Next time when the user restarts the application again, just call checkout for the 2nd time. UCF client just reopens previous working copy.

Does this approach resolve your issue? Or please let me know if it doesn't work on your side.

Regards,

William

Buddy

Seems to be what I'm looking for

will test and let you know (and mark the answer as correct, hopefully ) However, I can;t do it until much later today or tomorrow, we'll see

Buddy

William,

Just found a couple of minutes ot test and it doesn;t work for 2 reasons:

1. The 1st time I check out the document, it opens automatically in the default eidting application, which is not mine. In this instance, since it's an XML, by default, Windows opens it in Internet Explorer. I can't change the default XML handling application on the OS because of the risk of breaking other apps.

2. when I do the check out the second time, I get the following error:

System.ServiceModel.FaultException`1[Emc.Documentum.FS.Runtime.SerializableException]: "Checkout" operation failed for object: /Temp/My Obj. Failed to execute DFC operation: Document 'My Obj' was locked by you in a previous checkout. If you continue now, a read-only copy of this document will be used. (Fault Detail is equal to Emc.Documentum.FS.Runtime.SerializableException).

abc123

Hi,

For your 1st question. It is possible to specify a client program. Please take a look at ContentProfile.SetPostTransferAction().

Sets the command to handle the contents on client side after the transfer has been completed. It is used only for UCF transfer mode. (ContentTransferMode.UCF)

Command examples:

"dfs:view"	runs the default viewer for each returned content
"dfs:edit"	runs the default editor
"dfs:edit?app=notepad"	runs the custom editor (notepad)
"dfs:edit?app=java&-cp&\"c:\\Program Files\\javacustomapp\\app.jar\"&com.emc...ContentHandler"	runs the custom content handler OS equivalent is: c:\> java -cp "c:\Program Files\javacustomapp\app.jar" com.emc...ContentHandler ContentsFileName

serviceContext.SetRuntimeProperty("RUN_UCF_ACTION_ON_SUBSEQUENT_CHECKOUT", "true");

This runtime property will make the 2nd checkout workable if both checkout are performed by UCF. Hopefully you can see it in user guide of next major release.

Regards,

William

Buddy

You're them man William,

Setting the property indeed works and by using a dummy name for the custom editor, my app goes on and I can get the content file name from the DataPackage object and then do what I need

Thank you a lot for that