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.


The User-Trained Agent has an EYE on Goals

This is Papyrus Platform specific information related to ‘Adaptive Process and Goal Orientation‘.

Rather than the approach chosen by Social-BPM or other collaborative process design tools, Papyrus pushes for ‘Design by Doing’ where the users are empowered to create processes interactively without analysis and then can execute or change as required. Therefore the Papyrus ACM (Adaptive Case Management) implementation is especially suited for the knowledge workers who produce the high-value, innovation workload of a business – without which it will not survive or at least fall behind against the competition.

ISIS Papyrus Platform and Adaptive Case Management utilizes adaptive technology to provide business user access to data and content in structured and unstructured processes. Authorizes user can at any point in time add data entities, content, rules, or participants and assign work tasks to them. The tasks can be standalone or linked by dependencies or rules to other tasks. Because of the object-oriented models stored in the object-relational database, all elements of an executed process are available and can be archived. The process can even be ‘restarted’ and resimulated while watching it play out as it was executed along a timeline scale. A Gantt chart is used to display the process as a PLAN with activities and GOALS. But at any point in time it is possible to turn to the BPMN chart display, that will show all tasks, even the ones that were added by the UTA on the fly. This is how flexible the direct model execution is to man and machine.

Papyrus ACM – BPMN View in user Inbox

Papyrus uses the patented User-Trained Agent that will recommend next steps to the business users based on choices made by previous user roles. These choices are however not made in terms of which steps were followed in which sequence, but which data patterns were the repeated pattern for a follow-on action. The process is termed Transductive Training. Even without the User-Trained Agent, the process engine will expose to the user all the possible next steps in terms of fulfilled prerequisites and — if so defined — will select the fastest or lowest-cost step leading to the same goal outcome. Actor roles can be assigned to act based on shortest work queue or round-robin.

All aspects and information of the execution runtime is exposed within the system and therefore it is very easy to define charts displays to show process execution monitoring, activity monitoring or performance indicators from the real business data in real-time. Users can enter business rules at runtime to create additional goals and monitor their effectiveness immediately. Using sample data, processes can be simulated in a safe TEST sandbox environment.

User presentation of the processes, goals and outcomes is through the Papyrus EYE Widgets user interface that presents all data entities in a user-definable manner. The presentation is either through the Papyrus EYE Desktop or the Payprus EYE GUI in Flash. Other graphics engines are also being developed as is presentation to Mobile platforms such as the WebArchive support for the iPhone. Because all data entities are modeled in the repository it is simple to create GUIs, rules, content and validate them for correctness.

ACM Dashboard in Papyrus Platform

A key difference to all other BPM and Case Management products (adaptive, agile or dynamic) is the state-of-the art embedded content management capability of the Papyrus Platform. The inbound and outbound content software functions can be instantiated on any node and mostly any number of times. A complex network of automated and intelligent agents can be set up to execute in any kind of complexity required. Peer-to-peer node communication powers the Papyrus enterprise service bus with its long list of messaging (i.e. SOA) adapters and database type-managers. All changes to the process, including its content is fully change and version managed with automatic deployment and roll-back to any number of users. Depending on the setup, processes that are already being executed can be selectively updated with new functionality. All process execution elements are archived and remain fully auditable. Any process can at any time be reinstantiated and continued should the process concept allow for that.

The technology of the Papyrus Platform is unique with its object-relational database and distributed execution engine in a peer-to-peer kernel developed in platform portable C++. It was designed in 1997 and became first available in 2001 in major installations with up to 5000 users. As a unique niche player, ISIS focuses on complex and exceptional projects and needs rather than a let’s-do-it-all mass market.

The Papyrus Platform is unique in the sense that it is an application modeling and model execution infrastructure that supports the creation of standalone business applications, integrated GUI front-ends for desktop and portal, as well as a powerful goal oriented business process environment.  It is most likely that a mix of all three types of user interaction will be the norm in the future.