Papyrus CMIS Adapter (OASIS Standard)

ISIS Papyrus is a Foundational Sponsor of OASIS and has commited to supporting the CMIS Standard. The Papyrus CMIS Adapter is available.

The Content Management Interoperability Services (CMIS) OASIS standard defines a domain model along with Web Services and Restful AtomPub bindings that can be used by applications to work with one or more Content Management repositories/systems. The CMIS interface is designed to be layered on top of existing Content Management systems and their existing programmatic interfaces. It is intended to define a generic/universal set of capabilities provided by a CM system and a set of services for working with those capabilities. CMIS enables content sharing across heterogeneous archiving systems. CMIS is vendor- and technology-neutral.

The Papyrus CMIS Adapter architectural foundation is well suited for the purpose since it promotes standard interfaces over proprietary APIs, and open protocols over custom ones. Adapters come with a library of predefined templates, to foster rapid installation and deployment cycles. To no surprise, CMIS Adapter features an out-of-the-box template, which connects the Papyrus installation to CMIS clients in few mouse clicks. CMIS Adapter contains a Server-side interface and a Client-side interface.

The Papyrus CMIS Service primary use is to extract documents from Papyrus  in order to archive them externally, and to instantiate documents in Papyrus.

The Papyrus CMIS Client primary use is to retrieve documents from an external archiving system and to store them in Papyrus. It allows to retrieve documents from third-party CMIS archives. SOAP binding publishes CMIS service URLs through a WSDL document. Once documents are imported in Papyrus, they  can trigger workflows, or be stored in Papyrus Archive.

The CMIS data model in a nutshell:

CMIS specifies a core data model to define the type system and supported operations, and includes a set of services to access and manipulate the derived entities.

CMIS provides four base types (no additional base type can be defined) upon which more types can be derived if needed by the implementation. A type defines attributes, properties and operations that the instance must/can implement:

  1. Document object type: this is the base type for physical document entities, and is arguably the most important type. Documents have attributes like: name, objectId; and properties like: creation date, content stream Id, etc.
  2. Folder object type: CMIS exposes a file-system oriented interface, and the Folder type is the container of “file-able” objects, which include folder objects themselves and documents. Folders therefore organize documents in a tree structure. The Root folder is one of a kind, since only one root exists and it cannot be created through CMIS operations.
  3. Relationship object type: represents an instance of relationship between two objects. This describes for example a mapping between customers<=>contracts. The parent-child relationship doesn’t need a dedicated relationship entity, since it is implicit with the folder<=>document link, see above.
  4. Policy object type: represents an administrative right, which may be “applied” to one or more “controllablePolicy” objects. CMIS refers to a “textual description” property, and does not commit to any precise semantic significance or vendor-specific implementation.

CMIS services are used as follows:

  • Repository service: the Papyrus Platform exposes a logical name that identifies the container accessed through CMIS. The name is a customer-defined string, and is used to reference any subsequent calls to the same target location.
  • Navigation services: CMIS Adapter supports the CMIS Navigation service and offers a simple, yet efficient way to match the CMIS model. Documents retrieved from Papyrus are directly referenced under a Root folder. The Root folder can be a physical container, like a Queue, or a logical container, like the result set of a PQL query.
  • Object services: Papyrus CMIS Adapter exposes Read and Create operations on documents, since this is the primary reason to communicate between archives.
  • Multi-filing services: multi-filing is optional to CMIS, but is a native feature of Papyrus Objects (multiple parent references is the default setting).
  • Discovery services: Papyrus Objects is a non-relational, Object-Oriented system therefore  SQL syntax is not the most natural way to interface with it. We don’t plan to support SQL queries in CMIS Adapter (service), but we may support this interface in a future release of Papyrus CMIS Client since third-party archives may be conveniently accessed in this way.
  • Versioning services: Native support for version control in Papyrus Objects is implicitly accessed through CMIS (a document can be retrieved in its Active or Development version depending on the Role of the connected User).
  • Relationship services: relationships between CMIS entities may serve to query the links between documents (for example, to link a customer together with its contracts).
  • Policy services: CMIS policy services are not implemented in Papyrus CMIS Adapter since “policies” are fully defined by the integrated Papyrus Objects role-based access control system.
  • ACL services: The list of “allowable actions” returned with each object (Object services) fully defines what methods are permitted and what are not.

Papyrus CMIS Server configuration:

  1. Instantiate the CMIS Web Service template from the Library
  2. Setup Web Service parameters like URL, and give the CMIS Repository a name
  3. Design the CMIS tree for navigation (more about this, below).

The Papyrus Repository defines a specialized class (“CMIS folder”) exposing logical links to documents (children); therefore, documents are grouped following the ontology dictated by business requirements. Documents are “connected” to the appropriate folders without need to modify physical links nor to change existing workflows: every CMIS Folder defines what documents are available beneath itself. Therefore, a CMIS tree is not a static representation mirroring database relations or file-based links; instead, CMIS folders are freely combined and nested in multiple levels for optimal user accessibility and logical aggregation.

Authorizations are handled through the Papyrus built-in authorization subsystem, based on Roles Policies and Privileges. Therefore, CMIS Clients will perform the desired actions only on those documents and folders whence permissions are granted.

Interoperability tests

Papyrus CMIS Adapter has been tested on WebServices/SOAP binding with the following third-party CMIS connectors:

  • OpenCMIS from Apache Chemistry
  • CMIS OpenWorkdesk Community from  WeWebU
  • Microsoft SharePoint 2010 CMIS Connector
  • IBM FileNet

We have proposed test with other vendors but have not been invited to do so. If you are interested to test CMIS interoperatibility please contact us.

Advertisements

Announcement: Papyrus V7 Supports Open Standard XML

This is the official announcement that all ISIS Papyrus Platform products are fully compliant to open standard XML formats. To document that fact ISIS Papyrus Software AG has joined the most relevant standards organisations and will in future participate in the formation and evolution of these standards.

We have more important things to do than to waste time discussing the subject of XML with all related problems. The Papyrus Platform has since many years various XML supporting features that were quite extended in V7. Extensive SOAP, WSDL and UDDI support is one addition. Another  is the ability to map freely any XML tag to any Papyrus internal object ID. Our rule language PQL was enhanced to allow the parsing of XML structures. Thus, the Papyrus ObjectSpace can be regarded as a fully-featured XML database, allowing queries for XML tags and values.

We will continue to recommend alternatives to XML where sensible, but happily spend the extra time and ressources to deal with XML if the project demands it. This is in principle the way we have been dealing with XML for the last ten years. Most Papyrus frameworks support since some time the use of XSD for data mapping and the use of XSL to define document components. There is no need to program XSLTs because the mapping into Papyrus object structures is automatic.

Finally: The ISIS Papyrus Platform can be considered to be fully OPEN and a STANDARD. As far as I was told that is what everyone is looking for. You ask and we give it to you!