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.


ISIS Papyrus WebArchive Client for iPhone

We are very excited to announce the availability of the ISIS Papyrus WebArchive Client for iPhone on the Apple Appstore through using its Papyus EYE Mobile technology. It enables mobile access to documents stored on a remote Papyrus WebArchive. These documents can be generated by any kind of application or can be part of a business process or case file. Users can access Business Documents, add remarks (Stickers) and locate the person’s address. The user can upload any file on his iPhone to the WebArchive, including pictures taken with the iPhone. If the user is properly authorized he can change the state of viewed documents and thus take part in business processes without the need for a particular workflow client! ISIS Papyrus also announces its plans to make all Papyrus EYE Mobile applications available for Windows Mobile 7 and Android.

Papyrus WebArchive opens the world of mass customer documents distribution from the mainframe or Unix servers to the corporate Intranet and also to the MOBILE world. Corporations with a large number of customers regularly addressed with mass printing, now have the option to offer company wide document access, as well as customer direct access via Internet technology as a value added service to those same documents. This functionality is an essential feature for CRM Customer Relationship Management.

Applications for Banking, Insurance and Telecoms:

The WebArchive can be utilized to distribute customer documents and bank statements for collection of the documents by the customer. Customer folders can be defined on a number of WebArchive servers which can be accessed by internal and agent staff. Any customer query can be answered immediately. Customer documents can be printed, faxed or e-mailed as copy from the original document file. Customer billing information is not only available to the company personnel, but also to the customer himself via the Internet and through mobiles.

Features and Benefits

  • Completely secure access protocol without browser!
  • Access to document inbox from mobile
  • Change document state and thus case state
  • Alternative or value added services
  • No duplicate document generation
  • Constant quality for print and Web presentation
  • Reduced print and mail costs
  • Link to other Web based services
  • View AFP documents to lossless PDF conversion

Papyrus WebArchive enables the use of mainframe and Client/Server mass produced documents in WWW based Intranets or the Internet and now on mobiles with first the iPhone. Supported input formats are AFP documents or line-mode files with mixed Xerox DJDE or AFP controls, SAP R/2, R/3 and any other format supported by Papyrus DocEXEC. The z/OS JES2/3 connected Papyrus Host component provides transparent document transfer to the WebArchive from the print queue. Processing of the documents can be performed on the mainframe or the server as required.

ISIS Papyrus WebArchive Client for iPad available in Mai 2010!

BPMN/XPDL Execution in Papyrus

Those who follow my blogs might already be bored with my frequent bickering about process management. That I am not the only one to criticize the BPM market you can read in Terry Tschurter’s paper on the BPM State of the Nation 2009.

The worst thing I could do is to complain about something that I do not know much about. Therefore I would like to show to you that we at ISIS Papyrus are no strangers process management concepts, as easily proven by this announcement of the BPMN/XPDL Editor of our Papyrus Platform. I will not go into the details of either BPMN and XPDL here.

Keith Swenson is the authority on XPDL and BPMN and covers the relationship in this post: The Diagram is the meaning.

Let me just say that BPMN is a modeling notation for designing processes and XPDL is a superset that also contains graphical features of the actual drawing. Therefore we decided to cover both in the Papyrus Platform. Why did we do that if I am so opposed to BPM? As you might know, my opposition is mostly related to the huge, disconnected analysis and optimization process bureaucracy. Therefore we defined standard BPMN/XPDL to be used as execution engine:

BPMN/XPDL in the Papyrus Platform can be created and edited while you work and executed AS-IS.

It is fully executable by linking with the UML data models, content artifacts and Natural Language Rules defined in our Papyrus WebRepository. Also BPMN/XPDL is stored in the WebRepository using Papyrus’ change management and automatic, distributed deployment capability. All additional logic necessary is cleanly encapsulated in those classes and is not created during BPMN conversion into BPEL or by expansion with Java. BPMN in Papyrus is mostly used to define sub-processes in our Adaptive Process concept. The user interface is handled by our Papyrus EYE widgets so there is no XSD/XSLT mapping and Ajax forms programming. The business data are simply accessed through the UML classes linked to our Service Adapters (SOA and others). Finally, BPMN can be used in an Adaptive Process environment and allow 100% runtime editing.

Here is the Papyrus Platform BPMN/XPDL 2.0 Designer:

Free ISIS Papyrus AFP Viewer

I am truly happy to be able to share the news with you that ISIS Papyrus in cooperation with the AFP Consortium (AFPC),  has released its AFP Viewer V7.00 – a browser plug-in  that enables Web viewing of documents created or stored in AFP, or Advanced Function Presentation – on Windows as freeware for individual business users. As a founding board member, ISIS Papyrus played a strong role in the formation of the AFP Consortium and is committed to support of the AFP standard for printing, archiving and presentation.

When most document production vendors were still formatting to native printer formats (and most still do), we have decided 20 years ago that a stable and well-defined printing standard such as AFP – which was originally defined by Brian Platte of IBM – is of benefit to a business. My critical position to the XML based ‘open standards’ comes from their lack of timely, practical and realistic functionality. AFP was always way ahead.

AFP has been there for over 20 years and thus much longer than PDF and is still much better suited for high-volume document applications. Because of the PDF history of the Postscript graphics language it has to be rendered and therefore has a number of drawbacks. PDF/A was created only recently as a subset to resolve some of the issues.

For TransPromo, e-discovery and the electronic delivery of business documents such as bills, statements, and policies, AFP has powerful advantages over PDF as it supports very high print speeds, output integrity and centralized, automated server-based management. With advanced functionality, the Papyrus AFP Viewer provides superior accuracy and speed of presentation including embedded AFP resources, making it ideal for business and production environments that demand superior user interface and presentation of colors, as well as reliable and efficient archiving.

Individual users can now enjoy the professional features of the AFP Viewer for free, enabling businesses to send and present documents in the original AFP format to their customers without conversion. Software vendors who want to embed the viewer into their products can do so through OEM agreements.

As a V7 product it is based on the same powerful, platform-independent GUI technology that is also the base for Papyrus EYE and thus tremendous presentation speed advantages over previous versions have been achieved. Support for Chinese, Japanese, Korean, Thai, Arabic and Hebrew and all other complex languages is integrated. The AFP Viewer does not substitute fonts but loads them from a defined location or from embedded resources.

Papyrus AFP Viewer Features & Capabilities

  • View AFP files from any system (z/OS, Unix, Windows)
  • 100% WYSIWYG on any output channel
  • View any AFP document from online archive or file system in the browser
  • Fast navigation, search and zooming the AFP File
  • Broad support for AFP functionality
  • Print on any laser printer with highest fidelity
  • Full usage of the original AFP resources (Fonts, Images, Formdef, etc.)
  • Linux and Mac versions will be available soon.

The ISIS Papyrus AFP Viewer is available for free download by visiting the ISIS Papyrus Web site (

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!