Monthly Archives: April 2015

If you ever tried to implement some kind of integration between j2ee application and Documentum, you probably know that putting DFC libraries into j2ee environment is always a pain in ass because DFC follows neither best practices nor common sense:

i.e. to leverage functionality of com.documentum.fc.client.DfDefaultPrincipalSupport class (default implementation of com.documentum.fc.client.IDfPrincipalSupport) we need to put into classpath file named “trust.properties” which must have following format:

com.documentum.fc.client.IDfPrincipalSupport – creates session for specific userprincipal, default implementation is com.documentum.fc.client.DfDefaultPrincipalSupport, custom implementation may be injected either through IDfClient.setPrincipalSupport() method or through dfc.principal.support system property, i.e. -Ddfc.principal.support=implementation_class

com.documentum.fc.client.IDfTrustManager – provides superuser’s IDfLoginInfo, used only by com.documentum.fc.client.DfDefaultPrincipalSupport, default implementation is com.documentum.fc.client.DfDefaultTrustManager, custom implementation may be injected through dfc.trust.manager system property, i.e. -Ddfc.trust.manager=implementation_class

I would suggest to check com.documentum.web.formext.session.UserPrincipalAuthenticationScheme class for understanding how this feature works on application server side. Also you may override com.documentum.fc.client.DfDefaultPrincipalSupport class to make some mapping between principals and docbase users, for example:

What is the benefit of this instead of using dmadmin credentials and creating a ticket for other users?

Both options are unreliable:

on the one hand, principal authentication allows you separate logic between different layers, it’s always good

on the other hand, by default recent DFC versions do not leverage functionality of session manager’s private session pool, this means that every IDfSessionManager#getSession() call actually performs IDfSessionManager#newSession(), that in case of “principal authentication” is accompanied by generation of new ticket and extra authentication – this is really slow

on the another hand, ticket concept is broken in DFC, I would even say that implementation was written by idiots and never worked properly, let’s explain. Every login ticket has expiration time, to prevent unexpected expiration when login ticket is in use (actual for long running workflow tasks) DFC does following:

upon successful login DFC replaces old ticket with brand new one that has expiration interval equal to max_login_ticket_timeout in dm_server_config

also DFC spawns special task (see com.documentum.fc.client.impl.session.TicketWatchdog) that intended to renew expiring tickets

code below (sorry for poor quality) demonstrates that this implementation is broken (I specially set max_login_ticket_timeout to 10 to not wait 30 days):

[dmadmin@docu70dev01 ~]$ java Test
300
600
sleeping 660000
Exception in thread "main" DfAuthenticationException:: THREAD: main; MSG: [DM_SESSION_E_AUTH_FAIL]error: "Authentication failed for user dmadmin with docbase ssc_dev."; ERRORCODE: 100; NEXT: null
at com.documentum.fc.client.impl.docbase.DocbaseExceptionMapper.newException(DocbaseExceptionMapper.java:52)
at com.documentum.fc.client.impl.connection.docbase.MessageEntry.getException(MessageEntry.java:39)
at com.documentum.fc.client.impl.connection.docbase.DocbaseMessageManager.getException(DocbaseMessageManager.java:137)
at com.documentum.fc.client.impl.connection.docbase.netwise.NetwiseDocbaseRpcClient.checkForMessages(NetwiseDocbaseRpcClient.java:310)
at com.documentum.fc.client.impl.connection.docbase.netwise.NetwiseDocbaseRpcClient.applyForObject(NetwiseDocbaseRpcClient.java:653)
at com.documentum.fc.client.impl.connection.docbase.DocbaseConnection$8.evaluate(DocbaseConnection.java:1313)
at com.documentum.fc.client.impl.connection.docbase.DocbaseConnection.evaluateRpc(DocbaseConnection.java:1072)
at com.documentum.fc.client.impl.connection.docbase.DocbaseConnection.applyForObject(DocbaseConnection.java:1305)
at com.documentum.fc.client.impl.docbase.DocbaseApi.authenticateUser(DocbaseApi.java:1867)
at com.documentum.fc.client.impl.connection.docbase.DocbaseConnection.authenticate(DocbaseConnection.java:432)
at com.documentum.fc.client.impl.connection.docbase.DocbaseConnectionManager.authenticateConnection(DocbaseConnectionManager.java:350)
at com.documentum.fc.client.impl.connection.docbase.DocbaseConnectionManager.assignConnection(DocbaseConnectionManager.java:196)
at com.documentum.fc.client.impl.connection.docbase.DocbaseConnectionManager.getDocbaseConnection(DocbaseConnectionManager.java:99)
at com.documentum.fc.client.impl.session.SessionFactory.newSession(SessionFactory.java:23)
at com.documentum.fc.client.impl.session.PrincipalAwareSessionFactory.newSession(PrincipalAwareSessionFactory.java:44)
at com.documentum.fc.client.impl.session.PooledSessionFactory.newSession(PooledSessionFactory.java:49)
at com.documentum.fc.client.impl.session.SessionManager.getSessionFromFactory(SessionManager.java:120)
at com.documentum.fc.client.impl.session.SessionManager.newSession(SessionManager.java:70)
at com.documentum.fc.client.impl.session.SessionManager.getSession(SessionManager.java:177)
at Test.main(Test.java:43)

nobody knows about this bug because typical Documentum application never lives so long (30 days) without restart 🙂

Do we have to use the dmadmin account or any other superuser?

Any superuser account

Do we have to set the dmadmin password in plain text?

You may generate aek.key (do not use aek.key installed on CS!), put it into application’s classpath and encrypt password using this aek.key. Alternatively implement your own com.documentum.fc.client.IDfTrustManager.

Share this:

Like this:

Actually, I always try do double-check anything before posting it in my blog, but today I made a mistake: I decided that comment from Dearash is a 1st April joke, but after some research I realized it was not a joke – that was a home truth about support. Dearash’s comment had came from EMC’s network:

So, it looks like Dearash wanted to emphasize that EMC support is unable to help customers with their difficulties – original quote from Sukumar is:

Because in my case i’m facing some aspect related issue which creating the object through webtop and it neither allows me to create nor open the existing document instances of that type..Looks like a bug and still SR is pending with EMC about this issue

Actually, John did want to present Documentum 10 roadmap on the upcoming EMC World, but I’m not going to attend with event, so, I’m sharing Documentum 10 roadmap in this blog. EMC realized that Content Server is a black sheep in their Documentum product stack because it is written on C/C++ (all other products are written on Java) which causes a lot of issues related to development, maintenance, performance, security, etc. And now they are going to completely rewrite Content Server on Java. What we should expect from this renovation? I bet you cannot event imagine all advantages of upcoming changes, the brief description of some of them is:

REST and DFS will be a part of Content Server – no more dedicated servers for these services

Content Server will include a generic HTTP-gateway for content transfer operations – no more ACS and thumbnail servers

you will be able to work with Documentum objects using EJB API

no more client-side TBOs – all custom logic will be proceeded on Content Server side