CMIS checkout/checkin strange behaviour

Hi folks

I've been accessing the Dctm CMIS implementation using the Chemistry OpenCMIS Java APIs and I've noticed something weird with CO/CI, I'm wondering if anybody can help or has encountered similar.

I check out an object using the following code :

Document doc = ((Document)session.getObject(session.createObjectId("090000018004ec68")));

String pwcId = doc.checkOut().getId();

If the document is the latest version of a series (e.g. there exists versions 1.0, 1.1, 1.2 and 1.3), the above calls result in ALL versions being checked out and no indication of an error. The id specified in the call is the id of the latest version, I'm not specifying the chronicle id or an id of any of the previous versions. This only happens when I access the Dctm CMIS implementation via OpenCMIS. If I check out the same document via the WS interface the behaviour is as expected. So, I'm wondering if this is a bug in either OpenCMIS or the Atom binding interface of Dctm CMIS. I've TCP Monitored the exchange between the chemistry api on the call and the dctm cmis implementation and I can't see anything wrong with it :

POST /dctm-cmis/resources/repositories/wk_dev/checkedout HTTP/1.1

Content-Type: application/atom+xml;type=entry

Authorization: Basic ZG1hZG1pbjpkZW1vLmRlbW8=

Cache-Control: no-cache

Pragma: no-cache

User-Agent: Java/1.6.0_20

Host: 127.0.0.1:8081

Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2

Connection: keep-alive

Content-Length: 613

<?xml version='1.0' encoding='UTF-8'?>

<atom:entry xmlns:atom="http://www.w3.org/2005/Atom"

xmlns:cmis="http://docs.oasis-open.org/ns/cmis/core/200908/"

xmlns:cmisra="http://docs.oasis-open.org/ns/cmis/restatom/200908/">

<atom:id>urn:uuid:00000000-0000-0000-0000-00000000000</atom:id>

<atom:title></atom:title>

<atom:updated>2011-03-05T04:40:22Z</atom:updated>

<cmisra:object xmlns:ns3="http://docs.oasis-open.org/ns/cmis/messaging/200908/">

<cmis:properties>

<cmis:propertyId propertyDefinitionId="cmis:objectId">

<cmis:value>090000018004ec68</cmis:value>

</cmis:propertyId>

</cmis:properties>

</cmisra:object>

</atom:entry>

I've also run the same code against an Alfresco CMIS implementation and there are no issues.

If the id specified is for a document which is at version 1.0, the check out is as expected. However, when I attempt to check the document back in using code as follows :

Document doc = ((Document)session.getObject(session.createObjectId("090000018004ec68")));

ObjectId newId = doc.checkIn(false, null, cmisStream, "a minor version", null, null, null);

The checkin call does not fail, but the newId returned is the same as the id specified to get the document and when I check to see if the document has actually been checked in via DA, then it turns out not to have been. I've switched logging on in the tomcat I'm using to host the Dctm CMIS implementation and I can't see anything obvious beeing outputted and again I've monitored the call using TCPMon and can't see anything amiss:

PUT /dctm-cmis/resources/repositories/wk_dev/objects/090000018004ec68?checkinComment=a+minor+version&major=false&checkin=true HTTP/1.1

Content-Type: application/atom+xml;type=entry

Authorization: Basic ZG1hZG1pbjpkZW1vLmRlbW8=

Cache-Control: no-cache

Pragma: no-cache

User-Agent: Java/1.6.0_20

Host: 127.0.0.1:8081

Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2

Connection: keep-alive

Content-Length: 1081

<?xml version='1.0' encoding='UTF-8'?>

<atom:entry xmlns:atom="http://www.w3.org/2005/Atom"

xmlns:cmis="http://docs.oasis-open.org/ns/cmis/core/200908/"

xmlns:cmisra="http://docs.oasis-open.org/ns/cmis/restatom/200908/">

<atom:id>urn:uuid:00000000-0000-0000-0000-00000000000</atom:id>

<atom:title></atom:title>

<atom:updated>2011-03-05T05:18:37Z</atom:updated>

<cmisra:content>

<cmisra:mediatype>text/xml</cmisra:mediatype>

<cmisra:base64>PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPFJlcG9ydCBSZXBvcnRSYW5n

ZT0iV0VFS0xZIiBSZXBvcnRUeXBlPSJIU19QT0xJQ1kiPgogICAgPERvY3VtZW50PgogICAgICAg

IDxEYXRlPjEzLzAxLzIwMTE8L0RhdGU+CiAgICAgICAgPE5hbWU+SFMgUG9saWN5IDEueG1sPC9O

YW1lPgogICAgICAgIDxSZWFzb25fZm9yX0NoYW5nZT50ZXN0IG5ldyB3b3JrZmxvdyBmb3IgZ2Vu

ZXJhdGluZyBQREYgcmVuZGl0aW9uczwvUmVhc29uX2Zvcl9DaGFuZ2U+CiAgICA8L0RvY3VtZW50

PgoJPERvY3VtZW50PnR3aXQgdHdvbywgdHdpdCB0d29vPC9Eb2N1bWVudD4KPC9SZXBvcnQ+</cmisra:base64>

</cmisra:content>

<cmisra:object xmlns:ns3="http://docs.oasis-open.org/ns/cmis/messaging/200908/">

<cmis:properties />

</cmisra:object>

</atom:entry>

Any help, thoughts or pointing out glaring errors I've made would be much appreciated.

Cheers

Merv

Find more posts tagged with

Comments

imshambles

Update :

I was wrong about not seeing the weird CO behaviour via the web service binding, though CI with the web service binding seems to be OK.

samuel

Hi imshambles,

This is an expected behavior according to CMIS spec, although it seems weird if compared to Documentum native behavior.

Please check out CMIS spec section 2.1.9.4, "Services that modify Version Series"

http://docs.oasis-open.org/cmis/CMIS/v1.0/os/cmis-spec-v1.0.html#_Toc243905414

After a successful checkout operation is completed, and until such time when the PWC is deleted (via the cancelCheckOut service) or checked-in (via the checkIn) service, the effects on other Documents in the Version Series MUST be as follows:The repository MUST throw an exception if the checkout service      is invoked on any Document in the Version Series. (I.e. there can only be      one PWC for a version series at a time.)The value of the cmis:isVersionSeriesCheckedOut property      MUST be TRUE.The value of the cmis:versionSeriesCheckedOutBy property      MAY be set to a value indicating which user created the PWC. (The      Repository MAY still show the “not set” value for this property.)The value of the cmis:versionSeriesCheckedOutId property      MAY be set to the ObjectId of the PWC. (The Repository MAY still show the      “not set” value for this property). The repository MAY prevent operations that modify or      delete the other Documents in the Version Series.

Essentially, in CMIS, if a document in a version series is checked out, the entire version series is checked out because "The repository MUST throw an exception if the checkout service is invoked on any Document in the Version Series" and "The value of the cmis:isVersionSeriesCheckedOut property MUST be TRUE".

imshambles

Hi Yue

Thanks for your reply, but I'm sorry I have to disagree with your reading of the spec. The spec states a set of conditions which the server must honour with regard to CO/CI/CCO, but it does not state how it should honour those obligations i.e. it does not state that all previous versions should necessarily have a lock placed on them, it merely says that the version series should be identified as locked via the CMIS interface. Checking out all versions in a hybrid client environment has the potential to cause havoc unless there are plans for the D6.7 release to alter current server behaviour.

For example, if I CO a document via the CMIS connector this will currently result in all versions in that series having a lock placed on them. If I CI/CCO the document via the CMIS connector all is fine because the CMIS connector knows that it must release the locks on the previous versions. However, if the PWC is then CI'd or CCO'd via another process e.g. workflow/job/webtop/custom client then unless these other types of client know that they have to release the locks on the previous versions too, then the locks will remain on those previous versions. That is not a good situation where there are potentially multiple customisation points for any given customer solution.

If you take each of the points made in the spec :

The repository MUST throw an exception if the checkout service is invoked on any Document in the Version Series. (I.e. there can only be one PWC for a version series at a time.) - This can be achieved by simply querying against all versions of the document to check if there is an existing CO before proceeding with a CO.

The value of the cmis:isVersionSeriesCheckedOut property MUST be TRUE. - This value can be computed via query when the object is returned, it is not dependent on the lock status of the object being requested.

The value of the cmis:versionSeriesCheckedOutBy property MAY be set to a value indicating which user created the PWC. (The Repository MAY still show the “not set” value for this property.) - Again, this value can be ascertained via a query against all versions rather than necessitating a lock on each version in the series.

The value of the cmis:versionSeriesCheckedOutId property MAY be set to the ObjectId of the PWC. (The Repository MAY still show the “not set” value for this property). - Previous points about querying all versions of the document apply.

The repository MAY prevent operations that modify or delete the other Documents in the Version Series. - Current Documentum behaviour prevents deletion of CO'd objects and I can see that in order to honour this COing every version provides a means of meeting this criteria. However, the key word in the spec is MAY - this isn't an obligation, it is up to the implementer. Again, this doesn't stop the CMIS connector from meeting the obligation by querying all versions to see if one is CO'd prior to a delete operation.

Is it possible that this behaviour could be configured (i.e. the ability to tweak or switch if off) in the final release?

Once again, thanks for your reply.

Cheers

Merv