lotuscmisibm-connectionsdotcmisopencmis

IBM Connections Files CMIS: Unable to find object at path /My Files

I am using DotCMIS with no problem to connect to Alfresco and FileNet.

I registered for an IBM Connections account, added a few files via the web interface, and tried to connect to its CMIS endpoint https://greenhouse.lotus.com/files/basic/cmis/my/servicedoc

GetRepositories on this URL gives one repository, which in turn contain the two folders below:

My Files
My Folders

But when I run GetObjectByPath("/My Files") in the same repository, I get:

DotCMIS.Exceptions.CmisObjectNotFoundException was unhandled
 Message=Not Found
 Source=DotCMIS
 ErrorContent=<?xml version="1.0" encoding="UTF-8"?><lcmis:error xmlns:lcmis="http://www.ibm.com/xmlns/prod/sn/cmis"><lcmis:code>objectNotFound</lcmis:code><lcmis:message>EJPVJ9023E: Unable to find object at path /My Files</lcmis:message><lcmis:userAction></lcmis:userAction></lcmis:error>

What does IBM Connections say Unable to find object at path /My Files despite My Files being a folder at the root of the repository?

Solution

  • The cmis:name property ("My Files", "My Folers") is localized. A non-English user would get different cmis:name property values for these two objects.

    To fetch children from these resources, you need to build the path using the cmis:path property returned on each object or construct the path relative to its parent using the cmisra:pathSegment.

    For example, the cmis:object for the resource labeled "My Files" in your scenario has the following:

    <cmis:propertyString propertyDefinitionId="cmis:path"
 localName="cmis_path" displayName="Path" queryName="cmis:path">
 <cmis:value>/files</cmis:value>
</cmis:propertyString>

    So to actually fetch the user's files, the path to call is the following:

    GetObjectByPath("/files")

    And to fetch the user's folders, the path to call is the following:

    GetObjectByPath("/collections")

    The net is to ensure you build paths using the cmisra:pathSegment or the cmis:path property, and not the cmis:name as this may not be valid in all scenarios (i.e. if the repository has same name siblings, etc.).