/ Installation  

Make the Documentum CMIS to AppWorks connection work for you

Hi there AppWorks fans,

Welcome to a new installment of AppWorks tips.

The first one for this year where we’ll cover the connection between AppWorks and Documentum. AppWorks for our front-end where we create new things and handle them in process where Documentum will be our back-end system for saving the metadata and content in a structures way.

And why do we need this connection? By default, AppWorks saves it’s data in the database, but storing document/content is not recommended to be stored in a database. For that we have fast storage solutions that can be used with a Content Management System like for example Documentum.

The connection will be made via de Content Management Interoperability Services. CMIS is an open standard to connect different content management system in an ‘inter-operated’ way. It just an abstracted layer for controlling repositories via web protocols.

Let get right into it…

Spin up the VM where we also installed Documentum platform next to the AppWorks platform and make sure the all the services are up and running.

Maybe a good thing to give a small overview on what we have running at this moment of writing:

Database (PostgreSQL)
  • Port: 5432
  • Start/stop: systemctl stop|start|restart postgresql-11.service
  • Log: /var/lib/pgsql/11/data/log/*.log
  1. CARS (Repository)
    • Port: 6366
    • Start/stop: systemctl stop|start cars-slapddefaultInst.service
    • Log: /opt/opentext/cars/defaultInst/sbin/openldap.log
  2. AppWorks platform on TomEE
    • Port: sudo netstat -tulpn | grep WCP
    • Start/stop: systemctl stop|start wcpddefaultInst.service
    • Log: /opt/opentext/AppWorksPlatform/defaultInst/Logs/Monitor.xml
  3. TomEE
  4. Tomcat (OTDS)
  5. SVN (for source control)
  1. Connection Broker
    • Port: 1489
    • Start/stop: systemctl start|stop dm_connectionbroker.service
    • Log: /opt/documentum/dba/log/docbroker.win-5skkmburvo7.mydomain.com.1489.log
  2. Documentum Repository
    • Port: 47625
    • Start/stop: systemctl start|stop dm_repository.service
    • Log: /opt/documentum/dba/log/aw_repo.log
  3. Java Method Server (JMS). Running as Wildfly application server
    • Port: 9060 (
    • Start/stop: systemctl start|stop dm_jms.service
    • Log: /opt/documentum/wildfly9.0.1/server/DctmServer_MethodServer/log/server.log
  4. Tomcat (optional on our local machine for running for example Documentum Administrator)

Let’s continue the connection journey…

In the introduction we mentioned the CMIS service that we use to make the connection possible. This service can run on tomcat!

Good thing as we have a tomcat instance already running. On the VM, but only (optionally) local. As the CMIS service is part required for the connection it’s a good choice to deploy it on the tomcat instance that is running on the VM.

But as always first things first…Where to get CMIS!?

Go to the OpenText support site and go to the ‘Resource’ and ‘Download’ section and search for ‘Documentum Server’ and go to the latest 16.4 folder to find the link to ‘Documentum Content Management Interoperability Services (CMIS) Version 16.4’

Don’t be a smart guy like me to search for CMIS as you will not find it…Don’t ask me why!?

After hitting the download link, you should have a file called ‘dctm-cmis.war’. Open this file with 7-Zip and edit the dfc.properties


Make sure this information is available in the file:


After closing the file 7-zip will ask you to update the .war file…Hit yes.

After this update you can upload the file to the VM and deploy it to tomcat.

systemctl stop tomcat

mv ~/dctm-cmis.war /opt/tomcat/latest/webapps/

systemctl start tomcat

CMIS should now be available on this URL:

If not; like my deployment where I get an error in the cataline.out

java.lang.NoClassDefFoundError: javax/xml/ws/soap/Addressing

A check in the lib directory and specific the jaxws-api-2.1.jar we see that the class is indeed missing.

After some search it is the problem of the OpenJDK 11 that is used for our tomcat 8.5.43. Since Java 11 JAX-WS is removed from the modules; See JEP320

So, the best solution is to run our tomcat against a java 8 version, and you might have noticed that Documentum is installed with this version included: /opt/documentum/java64/1.8.0_152/

Let’s edit the tomcat service sudo vi /usr/lib/systemd/system/tomcat.service and update this line to the new java version and save it Environment="JAVA_HOME=/opt/documentum/java64/1.8.0_152/"

Reload the services daemonsystemctl daemon-reload

And restart tomcat to see the magic happening systemctl restart tomcat


Now open the ‘Browser Binding’, login with the ‘otadmin’ credentials and see your CMIS information passing by (Tip: use Chrome for the JSON view!):


Also, the OTDS instance should still be available

Another option is to use a CMIS client like Apache chemistry OpenCMIS Workbench


Where you also have ‘browse’ capabilities!


Next is the connection…

Now all the services are services are ready and steady. So, we have AppWorks running, Documentum running and the CMIS (V1.1) service running with will be the glue between them. Now we make sure the glue flows to the correct place!

For that we start from our AppWorks platform Explorer in the ‘AppWorks Tips’ organization (or whatever organization you created in your journey) and login with the ‘sysadmin’ account (it’s not required to login with the ?authID=OTDS parameter in the URL for now…as we learned!).

Open the ‘System Resource Manager’ artifact and get the properties of the ‘Repository’ service.

Then go to the ‘Document Store’ tab to see the default storage location of the platform (It all non-editable because we are not in the ‘System’ organization).


Now we will create the ‘Document store application connector’

  • Click Show > ‘All Service Groups’ for an empty panel to show up


  • Then click the New-button on the left side of the same bar


  • Select the ‘Document Store’ and click ‘Next >’


  • Give it a name ‘DocumentumStore’, select all the services and click ‘Next >’


  • Leave as is (although you could set the startup type to ‘automatic’) and click ‘Next >’


  • Fill in the form:
  • Click ‘Next >’ and ‘Finish’ the wizard


  • And see the changes


  • Now right-click the service and start it…Wait till it gets a nice shinny green icon!
    • In that same menu you can also view the logging when you don’t see the green icon happening for you!

The last step is to restart the TomEE instance systemctl restart tomee

Still not a good result? Then you can also try to clean some cashes with these 2 URL’s

Next is of course: What will happen on the Documentum side!?

For that we start the IDQL tool from a previous post /opt/documentum/product/16.4/bin/idql aw_repo from where can run a query like this one select r_object_id, object_name from dm_folder where folder('/otadmin', descend)

Give a go to run the query for a result like this:

1> select r_object_id, object_name from dm_folder where folder('/otadmin', descend)
2> go
---------------- ------------------------------------------------------------------
r_object_id object_name
0b12d5918000022e Workspace Customizations
0b12d5918000022f Startup Items
(2 rows affected)

This is nothing special and 2 default already available folders from Documentum in the ‘otadmin’ cabinet are shown. No AppWorks stuff…Yet!

What we than could do is create new instances of some entity types in AppWorks. Like for example the already made available ‘Category’ or ‘Member’. We build this functionality in previous posts. Only, you will still see nothing on the Documentum side…why? because Documentum is a CMS that handles content in a structured way and the ‘creation of content’ is not yet made available on the AppWorks side!

So, let us create a content creation feature on the member entity in AppWorks. For this we go to the AppWorks Explorer in our ‘AppWorks Tips’ organization. There we still have our ‘AppWorksProject’ available with the ‘entities’ folder. From the point we’ll open the ‘Member’ entity.

Follow the screenshot to add a new ‘File’ building block


Now open the ‘File’ block to see the next panel and make note of the ‘Advanced configuration’ question mark pop-up. This tells us the default location where the file will be stored.


Next is validation, publication and testing!

Go the front-end UI (/app/start) with the ‘awuser’ account (password was ‘admin’) and create a new ‘Member’ where we choose for a new ‘Developer’


On the creation screen make sure to choose the ‘Create and open’ option.


And now check out that shinny ‘Upload’ button!


After the update even more buttons are available!


And…should it, will it?

Check out Documentum now…with IDQL and the query (Or check it all with the CMIS Workbench tool)!

1> select r_object_id, object_name from dm_folder where folder('/otadmin', descend)
2> go
---------------- ------------------------------------------------------------------
r_object_id object_name
0b12d5918000022e Workspace Customizations
0b12d5918000022f Startup Items
0b12d59180003519 appworks_tips
0b12d5918000351a AppWorksTipsAppWorks
0b12d5918000351b member_developer
0b12d5918000351c 16388
(6 rows affected)

That is a knuckle-bump….Hooray…we’ve seen the light! 👊

If you made the Documentum Administrator client available (it was optional…I know!) you can also see something like this in a nice UI

You can see that it is indeed a folder structure with basic Documentum type of objects (dm_folder and dm_document)


You can play a little bit with the AppWorks ‘content’ buttons and see the result in Documentum. Here are some query to check some result with a certain action

  • Checkout/Checkin (and not checkin/checkout…imaging what could happen)

select r_object_id, i_contents_id, object_name, r_lock_owner, r_lock_date from dm_document where folder('/otadmin/appworks_tips', descend)

Show the checkout information on the document. One option I couldn’t find on the AppWorks side is the ‘Cancel checkout’

  • Upload/Versions

select r_object_id, i_contents_id, object_name, r_version_label from dm_document (ALL) where folder('/otadmin/appworks_tips', descend)

Show the version information on the document

  • Delete document (will also delete the instance of the entity!)

select r_object_id, parent_id, full_format, data_ticket from dmr_content where r_object_id in ('{i_contents_id}', '{i_contents_id}')

Not much to query on a deleted document, but if you replace the {i_contents_id} with the id’s from the other 2 queries you’ll see Documentum behaves as normal. The dm_document object is deleted and the related dmr_content object with the file on the Documentum file store are still available. These last 2 automatically cleaned with 2 Documentum jobs.

One more thing about versioning. You might see something like this once you played a bit


  • A ‘Major’ version is created with a new ‘Upload’ action
  • A ‘Minor’ versions is created with checkout/checkin

And that gives us (just before my daily walk) a greatly and successful ‘DONE’…Good job and now where’re getting somewhere with our image…Maybe time for a backup! But for next time we’ll cover something nice as we will try to manipulate the information in Documentum after the content synch is done. A good thing to know and a nice thing to play with…I CU in the next post where we continue our journey on our AppWorks platform together with a Documentum platform…great Scott…what an excitement for the year 2020!! 🎆

I hope you had a great old years evening and for all of you a very happy and bright new year…and…don’t forget to subscribe to get updates on the activities happening on this site.