CMIS compatibility and technical reference

<< Click to Display Table of Contents >>

Navigation:  Bizagi Studio > Document Templates > ECM integration >

CMIS compatibility and technical reference


Bizagi ECM integration feature consists of storing those documents and files which are uploaded in Bizagi, directly into your corporate documents repository, as described at ECM integration.

This integration relies on the CMIS 1.0 standard (Content Management Interoperability Services), which consists of a generic set of Web services that expose the capabilities of the ECM, empowering a service oriented architecture designed to handle metadata, provide check in and check out options, and consider all other relevant capabilities usually as provided by these type of systems (also often referred to as DMS).


CMIS compatibility in Bizagi

Bizagi complies to the CMIS version 1.0 standard. Web services supported and invoked by Bizagi are those which follow the SOAP standard protocol.


Typically, the set of Web services provided by ECM systems complying to CMIS version 1.0 are:

RepositoryService: A web service providing getRepositories, getRepositoryInfo, getTypeChildren, getTypeDescendants, and getTypeDefinition, methods which are useful to discover information about the repository, including information of the object-types (metadata).

NavigationService: A web service providing getDescendants, getChildren, getFolderParent, getObjectParents, and getCheckedoutDocs, methods which are useful to traverse the folder hierarchy in a CMIS Repository, and to locate Documents that are checked out.

ObjectService: A web service providing the basic CRUD (Create, Retrieve, Update, Delete), operations on objects in a Repository, through the ID-based methods such as createDocument, getObject, getProperties, updateProperties, or deleteObject, among others.

VersioningService: A web service providing checkOut, cancelCheckOut, getPropertiesOfLatestVersion, getAllVersions, and deleteAllVersions, methods which are useful to navigate or update a "Document Version Series".

DiscoveryService: A web service providing search capabilities (to search for query-able objects within the Repository through the query method).

RelationshipService: A web service providing a way to retrieve the dependent objects associated with an independent object (through the getObjectRelationships method).

MultiFilingService: A web service providing the addObjectToFolder and removeObjectFromFolder methods which are supported only if the repository supports the "multifiling" or "unfiling" optional capabilities.

PolicyService: A web service providing applyPolicy, removePolicy, and getAppliedPolicies methods which are useful to manage policies (of a "controllablePolicy object").

ACLService: A web service providing the getACL and applyACL methods which are useful to manage ACL definitions.


For more information about the CMIS standard and its services specification, refer to



Before moving on with the ECM integration, it is recommended that you make sure your ECM system complies to the CMIS standard.

Note that you may rely on CMIS clients and procedures to verify this (e.g, using external validators such as In case that your ECM does not comply to CMIS, you may always choose to implement a customized integration by means of your own code through the Connectors feature (recommended) or through Widgets.


CMIS methods invocation

This section provides in detail, the technical reference regarding which CMIS methods are invoked in Bizagi, and at what moment.

When uploading the document in Bizagi for the very first time (initial storage at the ECM), the createDocument method is invoked at the On Exit of that task, and no further options are presented at that point.

When working with documents which are already stored in the ECM, end users in Bizagi will be able to use Lock/Unlock, Edit, Delete or Update options.




The below table lists which CMIS methods are invoked, depending on the UI actions end users choose.


Option in Bizagi

CMIS method invoked

When does this happen?


UpdateProperties is invoked, provided that metadata was edited.

At On Exit of that task (upon clicking Next in Bizagi's form).


CheckOut is invoked.

Instantly, upon clicking on that Lock option.

Unlock (available after a Lock)

CancelCheckOut is invoked.

Instantly, upon clicking on that Unlock option.


CheckIn is invoked.

At On Exit of that task (upon clicking Next in Bizagi's form).

Edit + Update /

Update + Edit

CheckIn is invoked. The CheckIn invocation allows sending properties which have changed as well.

At On Exit of that task (upon clicking Next in Bizagi's form).


DeleteObject is invoked.

At On Exit of that task (upon clicking Next in Bizagi's form).


Important notes

Refer to these notes regarding the CMIS treatment featured by Bizagi.


1. Bizagi will guarantee that a document will not be left out as locked

This way, once an end user finishes working on an activity which integrates with your ECM, that document in the ECM will be left as unlocked so that others can work on it as well.


This implies that If a Lock option is used, but no Unlocking or Update is done afterward (no changes are actually made to the document), then at the On Exit of that task, Bizagi will invoke a CheckIn with no changes (if your ECM system supports the PWCUpdatable capability).

In case that your ECM system does not support this property, then a CancelCheckOut will be invoked by Bizagi (On Exit as well).


2. Other CMIS methods are invoked as well

To handle versions, metadata and document information accordingly, note that Bizagi will invoke other CMIS methods as well, such as: getAllVersions, getProperties and getTypeDefinition.

Keep in mind that the table and information above, lists the relevant methods invoked but it does not includes all of those inherent and bound to the appropriate exchange and management of information.


3. Data types belonging to the spec are supported

Bizagi supports all data types as explicitly referenced by the CMIS specification, when managing metadata of an integrated library.

Note that each ECM system may too have its own special data types, which are not part of the standard and possibly uncommon for any type of system.

Those data types which belong to the spec and which are supported are: string (xsd:string), Boolean (xsd:boolean), decimal, integer (xsd:integer), datetime (xsd:dateTime), uri (xsd:anyURI).