CMIS for EMC Documentum
Nov 25, 2011 | by jgoldhammer | 0 Comments

After the first blog article about CMIS in general, the second part of the series deals with the new Documentum CMIS product. In addition to DFC and DFS programming interfaces, EMC released the new interface with the Documentum version 6.7 in May this year. Documentum supports full CMIS 1.0 specification, so that you can use CMIS clients to communicate with the Content Server. In the following blog article I will describe the most interesting topics about the new interface.

1 Installation/Deployment

The EMC CMIS implementation for Documentum is implemented as a standalone J2EE application. The supported environments can be found in the document ‘EMC Documentum Content Management Interoperability Services Version 6.7 Release Notes‘.
The deployment of CMIS for Documentum is very easy. You only have to deploy the CMIS application (emc-cmis.war for Servlet containers or emc-cmis.ear for several J2EE containers) with a modified dfc.properties file which contains the correct docbroker and bof-registry settings.
With Documentum 6.7 the CMIS application is installed on the methodserver by default. This provides an easy way to test CMIS, but it is not recommended to use this installation on a productive system.

Landing page of EMC CMIS App

2 Architecture of CMIS for Documentum

The application is based on Documentum Foundation Classes to communicate with the Content Server in the backend and on JAX-WS/Jersey to provide the API for clients. The CMIS functionality is directly mapped to DFC operations. For example, the CMIS queries will be translated to DQL queries. Other functionality like creating a document will be mapped to the concrete methods of Documentum Foundation Classes.

Documentum CMS

Suppose, you want to connect your customer specific application to a CMIS Server, e.g. the Documentum CMIS application and want to read all documents from the repository for a logged-in user. The following steps show how the application flow would look like:

1. Connecting to a CMIS server from a client perspective can be done in several ways. There are some CMIS frameworks out now which encapsulate the API (later more). On lowest level the application has to open a HTTP connection to the CMIS Server and send a HTTP request with a payload (SOAP message or ATOM message, both described in XML). Following code snippet shows the ATOM message from the client to the server to request the results of the given CMIS Query „SELECT cmis:objectId FROM cmis:document“.

Grafik 3

2. The Documentum CMIS Server handles the incoming request, either by using JAX-WS for SOAP or Jersey for REST. In both cases, XML message will be translated into Java Objects which will be used for translating the given CMIS query into a DQL query.

3. The DQL Query can now be executed against the Content Server repository in the user context. As you may know, Documentum expects valid credentials for the user for doing anything. But how does the CMIS application know the current user and repository? Yes, you have to send the information within the request to the CMIS-server.

4. After processing the DQL query the Content Server returns with the results which are read by the DFC integrated in the CMIS Server. There might be some caching for paging functionality in CMIS, but it is not transparent to the user because the source code is not available.

5. Now again, the translation of the Java Objects into the response format can be done. The Java Objects will be mapped to XML (SOAP or ATOM, specific for the used binding).

6. The generated message will be send over the wire via HTTP response to the CMIS Client. The CMIS Client will than process the message and for example, show the documents in the custom application.

Grafik 4

Grafik 5

3 Comparison of DFC and CMIS

The following table compares Documentum Foundation Classes (DFC) and Documentum CMIS interface

Criteria

DFC

CMIS

Communication

DFC communicates with the RPC protocol with the Content server. The session is hold on the client.

Message-based communication which means to transfer the complete context in each message.

Example:

To move a document via CMIS, you have to send the repository-ID, the document-ID, the source-folder-id and the target-folder-id with the request.

Authentication

You have to authenticate one time in a session with username and password for a specified repository.

Each request has to contain the username and password (because it is based on stateless protocol HTTP!).

SOAP-Binding:
Usage of WS-Security-Standard.

REST-Binding:
Usage of http basic authentication. Encryption needed by using SSL.

Performance

Through the underlying protocol only changed data is transferred only when its needed. The object state is ‚hold‘ on client side.

You can use DQL for mass updates or deletions.

Each action must open a http connection, request a resource, get back the resource and end the http connection (or keep alive the connection). Yes, some CMIS frameworks like Apache Chemistry provide an object cache, but that´s not what you wanted in all cases.

The transfer of messages is quite expensive due to the XML format and transformation.

Additionally, CMIS only allows operations on one object at the same time. You can only get the ACL of one object at one time.

Designing a communication concept is the most important work at the beginning of developing with CMIS to get an acceptable performance.

Additionally, the performance impacts various from one vendor to another. CMIS for Documentum is a separate application, so using it instead of DFC means an additional server between custom application and Content Server. This means, CMIS must always be slower than using DFC!

Alfresco, for example, integrates CMIS into the repository server itself, so it is using the same Repository API as webscripts. So there is no additional impact besides the XML transformation.

Using caches for type definitions etc. on client application side is recommended to avoid unnecessary requests.

Transactions

For most parts of DFC you can easily wrap transactions around several actions. You can create several documents and if one creation failed, you can easily rollback the transaction in the code with a few lines of code.

CMIS is based on a stateless protocol. Due to this reason, each action (e.g. creating a folder) has its own transaction, so that a transaction for multiple actions is not possible out of the box.

Instead the developer has to ensure that the code is written in the way that the rollback works. For example, when creating 5 folders and one fails, you have to delete the other folders by calling 4 times deleteFolder to rollback…

Afterwards there are some questions with the answers listed, which might be interesting for new CMIS developers.

Question

Answer

How can I create a new document?

You can use the createDocument -method of the ObjectService.

How can I create renditions with CMIS?

CMIS does not allow to create or update renditions. You can request renditions via getRenditions-method of the ObjectService.

How can I copy a document?

You can use the createDocumentFromSource-method of ObjectService.

How can I move a document?

Operation moveObject in ObjectService.

How can I delete a folder?

Empty folders can be deleted with the deleteObject -method of the ObjectService.

To delete folders with content, use deleteTree -method of the ObjectService.

How can I search for objects?

You can use the query-method of the Discoveryservice. The query itself is based on CMIS-SQL, a SQL subset. The syntax is very similar to DQL, the Documentum Query Language. There are additional operators to request repeating attributes or the fulltext of the repository.

How can I create a new object type?

CMIS does not allow to create new type definitions. If you want to create a new definition, please use the tools of the vendor (e.g. Composer of Documentum). There are ideas to provide this functionality in future versions.

How can I create a link for a document?

You can use the addObjectToFolder of the MultifilingService. To remove the link, you can use removeObjectFromFolder . Be careful, this is repository specific. The repository does not have to provide it.

What about permissions in CMIS?

Reading and apply ACLs are supported by CMIS, but this is very basic. EMC extends the model of CMIS (cmis:read, cmis:write, cmis:all) with the specific Documentum rights. Because the ACL consists of users, groups or roles with specific permissions, it is not possible to determine the own rights or rights of other users via CMIS. It is only possible to get the allowed actions for the current user on one object.

How can I see which functionality is supported by the CMIS server?

The getRepositoryInfo-method of the Repository Services can be used to determine information about the capabilities of the specific CMIS implementation for the underlying ECM product.

For example, Alfresco does not support to query the versionSeriesId property.

Additionally, the service can be used to get the type definitions with all property definitions like name, datatype and cardinality.

Are concepts like virtual documents, workflows etc. supported?

These concepts are beyond the scope of CMIS. If you need them, it is not the correct use case for using CMIS. Some concepts, e.g. subscriptions might be possible with the use of relationships. Maybe next versions of CMIS will contain new functionality like Records Management.

4 Summary

CMIS for Documentum allows you to access documents and folders in the Documentum repository. The installation and configuration of the CMIS Documentum web application is very easy. You can really produce quick results as a developer and the services and methods are in general well designed. Due to protocol constraints and the early version, the CMIS specification in general has some shortcomings:

  1. It is not fully prepared yet to allow batch CRUD operations, e.g. create a folder hierachy because of performance and transactions reasons.
  2. It does not allow to create, update or delete objects via CMIS SQL.

Nevertheless, CMIS is the first step in the right direction. It will help developers to access different repositories with the same API.

Please always check in your projects if CMIS is the correct abstraction layer for the customer requirements. If you need total flexibility and enhanced functionality like workflows, use DFC. If you want to integrate different repositories from different vendors, CMIS is a good option.

Kommentare sind geschlossen.