According to the EMC Documentum CMIS Reference Guide (ver 6.7), the two
Repository Capabilities are false:
capabilityPWCUpdatable - This capability cannot be implemented because
Documentum does not have a PWC feature.
capabilityPWCSearchable - This capability cannot be implemented because
Documentum does not have a PWC feature.
The ID of the original doc is passed back when:
ObjectId pwcId = document.checkOut();
However, if in the same session you call:
document.cancelCheckOut()
the LinkCache for "self" is the actual checkedout link which works.
The issue comes in if you are opening a new session for a docuemnt that is
already checked out and you want to cancel out an item you checked out in a
previous session or in some other application. If you retrieve the document
using:
session.getCheckedOutDocs()
The LinkCache result for "self" when calling cancelCheckOut() gives you the
working-copy link. However, you have to iterate over the collection of checked
out docs to get the right document.
-----Original Message-----
From: Florian Müller [mailto:[email protected]]
Sent: Friday, June 10, 2011 12:18 PM
To: [email protected]; Degroff, Nathan
Subject: Re: VersioningService.cancelCheckOut() and working-copy vs self rel
link
Hi Nathan,
Thanks for your report!
I can't really comment on the EMC Documentum CMIS implementation because I
haven't had a chance to test it extensively.
Could you describe how you get the PWC id in the first place?
Did you do something like this: ObjectId pwcId = document.checkOut();
If so, EMC does not return the PWC entry but the document entry, which would be
a bug on their end.
Using the working-copy relation would be a valid workaround. Let me play with
that a bit and if it works with other repositories, I'll open an issue and
change it.
Thanks,
Florian
On 10/06/2011 16:22, Degroff, Nathan wrote:
> To whom it may concern,
>
> Topic: VersioningService.cancelCheckOut()
> Binding: AtomPub
> Issue: Deletion of object rather than cancelling checkout
> Repository: EMC Documentum
>
> We encountered an issue with utilizing the OpenCMIS client where depending on
> how you retrieve the Document, the system would send a DELETE for the actual
> object:
>
> DELETE
> http://<host>:<port>/<app>/resources/repositories/<repository>/objects/<roid>
>
> instead of the working copy:
>
> DELETE
> http://<host>:<port>/<app>/resources/repositories/<repository>/checkedout/<roid>
>
> There are many ways around it by retrieving the doc using the
> Session.getCheckedOutDocs() and then calling cancelCheckOut() from that
> object or just calling the SOAP version (which calls the checkout operation
> directly), but I was wondering if this is a culmination of:
>
> -) CMIS 1.0 Spec specifying the "self" relationship while calling
> cancelCheckOut() instead of using the "working-copy" relationship link
> -) EMC CMIS implementation not supporting a PWC
>
>
> After tracing and inspecting to the LinkCache, I can see that if (atompub
> package) VersioningServiceImpl used Constants.REL_WORKINGCOPY it would work
> in all instances whether you checked the doc out in the same "OpenCMIS"
> session or if you are pulling it back from a new session.
>
> public void cancelCheckOut(String repositoryId, String objectId,
> ExtensionsData extension) {
> // find the link
> String link = loadLink(repositoryId, objectId,
> Constants.REL_WORKINGCOPY, Constants.MEDIATYPE_ENTRY);
>
> if (link == null) {
> throwLinkException(repositoryId, objectId,
> Constants.REL_WORKINGCOPY, Constants.MEDIATYPE_ENTRY);
> }
>
> delete(new UrlBuilder(link));
> }
>
> We were able to pull back many different ways to deal with it especially
> pulling back the "checkedOutDocs" collection, but any thoughts would be
> appreciated. Pulling the doc directly without having to iterate through a
> collection to find the doc one needs.
