CMIS to Documentum Property?

ImranAdan

Hi All,

I was wondering if there are any resources available to convert a CMIS property to its respective Documentum property.

For example Description

CMIS Documentum

cmis:name ---> object_name

cmis:objectId ---> r_object_id

Is there a complete list for this. I want to have the CMIS name for All Documentum Properties below:

object_name CHAR(255)

r_object_type CHAR(32)

title CHAR(255)

subject CHAR(128)

authors CHAR(32) REPEATING

keywords CHAR(32) REPEATING

a_application_type CHAR(32)

a_status CHAR(16)

r_creation_date TIME

r_modify_date TIME

r_modifier CHAR(32)

r_access_date TIME

a_is_hidden BOOLEAN

i_is_deleted BOOLEAN

a_retention_date TIME

a_archive BOOLEAN

a_compound_architecture CHAR(16)

a_link_resolved BOOLEAN

i_reference_cnt INTEGER

i_has_folder BOOLEAN

i_folder_id ID REPEATING

r_composite_id ID REPEATING

r_composite_label CHAR(32) REPEATING

r_component_label CHAR(32) REPEATING

r_order_no INTEGER REPEATING

r_link_cnt INTEGER

r_link_high_cnt INTEGER

r_assembled_from_id ID

r_frzn_assembly_cnt INTEGER

r_has_frzn_assembly BOOLEAN

resolution_label CHAR(32)

r_is_virtual_doc INTEGER

i_contents_id ID

a_content_type CHAR(32)

r_page_cnt INTEGER

r_content_size INTEGER

a_full_text BOOLEAN

a_storage_type CHAR(32)

i_cabinet_id ID

owner_name CHAR(32)

owner_permit INTEGER

group_name CHAR(32)

group_permit INTEGER

world_permit INTEGER

i_antecedent_id ID

i_chronicle_id ID

i_latest_flag BOOLEAN

r_lock_owner CHAR(32)

r_lock_date TIME

r_lock_machine CHAR(32)

log_entry CHAR(80)

r_version_label CHAR(32) REPEATING

i_branch_cnt INTEGER

i_direct_dsc BOOLEAN

r_immutable_flag BOOLEAN

r_frozen_flag BOOLEAN

r_has_events BOOLEAN

acl_domain CHAR(32)

acl_name CHAR(32)

a_special_app CHAR(32)

i_is_reference BOOLEAN

r_creator_name CHAR(32)

r_is_public BOOLEAN

r_policy_id ID

r_resume_state INTEGER

r_current_state INTEGER

r_alias_set_id ID

i_is_replica BOOLEAN

i_vstamp INTEGER

Find more posts tagged with

Note:

If there are Accepted Answers, those will be shown by default. You can switch to 'All Replies' by selecting the tab below.

Accepted answers

lastnitescurry

Non standard CMIS properties will use their Documentum nanes

All comments

rajashankar

Hi Imran,

Please find attached document. Hope it helps

Regards,

Raja

ImranAdan

Hi Raja,

Thanks for this, even though this is not a complete list I believe that it will help anyone else stuck in a similar predicament.

Thanks you

lastnitescurry

Non standard CMIS properties will use their Documentum nanes

ImranAdan

Cheers Brain glad to know that, I have one more question. What about custom properties, as they are not standard CMIS properties will they also be using their Documentum names?

lastnitescurry

Try it and see what happens

abc123

DOCUMENTUM CMIS Reference Guide has the complete mapping list, https://support.emc.com/docu57845_Documentum-Content-Management-Interoperability-Services-7.2-Reference-Guide.pdf?language=en_US

Other document, folder and relation properties not defined by CMIS will be shown as their Documentum names, including custom properties from the extended types. CMIS 1.0 does not support data types except for document, folder and relation.

Regards,

William

Archana12

Hi William,

1. By adding non-standard CMIS properties, we are reducing inter-operability of CMIS with any other ECM vendor, correct ?

2. Can we also use non-standard CMIS types? We have a requirement to add users to certain dctm groups through CMIS, is that feasible, as I see CMIS only supports documents, folders and relationships ?

Thanks

Archana

abc123

Hi Archana,

You are right. As I see, it's difficult for big ECM vendors to make further compromise on the common data models and APIs. But without more & deeper interoperability, you actually cannot build a rich web app by just using the existing CMIS API. CMIS 1.1 later came out to allow vendor specific repositories to expose more of their own data types in CMIS APIs, but to some sense, it is not good for the interoperability. CMIS 1.1 is the answer for your question 2. Documentum for CMIS 1.1 is not public available yet, as I know.

Regards,

William

GinoVicari

Hi all,

Just as an additional remark, although CMIS was intended to provide interoperability between CM systems, one of the main features is discovering repository capabilities and allowing for loose coupling.

In fact, it allows to discover available features and talk to repositories, without imposing any explicit data model or mandatory feature set.

In short: except for some very basic ECM functionality, CMIS allows to understand and use what repositories offer., it does not impose any compliance levels, nor mandatory features, like e.g. the JCR (Java Content Repository) specification does.

Beware not to use CMIS as a feature specification and data model specification for repositories, as this is not actually how it has been designed.

Cheers,

Gino

Archana12

Agree, but as it allows document management, CRUD are the basic use cases that any web service (or wrapper) should support. And as soon as document management comes in place, there comes a data model. In practical scenario, every organization will have a custom data model in place. CMIS must expose some way of handling custom attributes, that's uniform across various CM systems to make it a practical choice in real scenarios.

Thanks

GinoVicari

You are absolutely right, and that's where to my humble opinion the standard falls a bit short, as it's up to the implemented "wrapper" to make up for the differences between the different CMS technologies behind the CMIS services. Even versioning, multi-filing, referencability, mandatory to be in a folder, FT search, metadata search, and many more obvious CM functionality (even the U from CRUD...) might not be present or at least behave in a different way depending on the technology behind the CMIS calls.

Just saying that the fact a behavior is different, or just not there, and I am not even talking about data models here (as this indeed should be discoverable, allowing to dynamically interpret custom attributes), should be taken into account when writing a CMIS consuming wrapper or application. In fact, the application that makes use of CMIS would adapt its behavior depending on the functionality that is available in context of the CMS technology behind the CMIS service call.

I'm not saying this is ideal, but that's what I found out when writing my own...

Regards

Archana12


In fact, the application that makes use of CMIS would adapt its behavior depending on the functionality that is available in context of the CMS technology behind the CMIS service call.

I'm not saying this is ideal, but that's what I found out when writing my own...

Very true sir !!

This is what I am noticing. Although I have not worked on CMIS so far, and just started to explore it, I am wondering is it really worth to use CMIS in a multi vendor environment ( we specifically are interested in all CRUD, search, user provisioning operations) only for the sake of interoperability, when we know a considerable effort is required each time for a compatible wrapper based on the CMS being used ?

Thanks

GinoVicari

That's indeed the challenge... It actually is in general the trade off you will have to do in a heterogeneous CMS environment...

If however the only reason you are on CMIS is to avoid vendor lock in, and you have only a limited amount of CMS technologies in your environment, it's worth considering the value of not going to CMIS and working with native API vs. the additional cost and lesser out-of-the-box functionality a "not being vendor locked-in" approach brings.

Ultimately, going for a CMIS based environment will add maintenance / IT responsibility, compared to using a richer API. This really depends on what your organization considers important...

Cheers

Archana12

This is an old thread now, but what maintenance/IT responsibility overheads you are talking about. I don't understand the additional cost that CMIS brings up.

Thanks