UEM for Documentum
Hi all,
One of our customers have asked us about our capabilities to use UEM for the documentum browser based UI. Obviously, as this is a tomcat web server there should probbaly be no special technical challenge, but the customer said Documentum is using a generic url structure which is making monitoring it and using business transactions very difficult.
Does anyone have any experience in using UEM for Documentum ?
Thanks,
Gil.
Hi
You should have no problems with UEM. As for the generic URL structure. UEM will pick up the "User Action" name which should give you a good indication on what the user actually did. If that doesnt help you can always pick up HTTP Parameters through the Servlet Sensor or maybe instrument some custom methods that will give you more details. We have some internal KB Entries on Documentum where a colleague shared his Sensor Pack for Documentum. I will double check if it is safe to make it public or at least share it with you
Andi
Hi Andreas
We are planning a PoC with a Documentum Client and I would appreciate it if you could share the above information regarding the KB articles and Documentum sensor. The Client would like us to put together a brief on how we will monitor Documentum for them.
Many thanks
Dean
I've attached a sensor pack that was used by some of my colleagues. Give it a try. One thing you may want to disable in that sensor pack are some of the generic rules for "com.documentum". I think the sensor pack may have been created prior to Auto Sensors. So - give it a try but then you may want to disable some of these rules in case they instrument too many fast running methods.
Also - here is another hint from our internal document::
Database Access: Documentum does not rely on JDBC to access the DB. This is achieved by the C++ layer but the SQL statement is actually passed to a Java object very similar to a JDBC Statement (com.documentum.fc.client.DfQuery). As the SQL statement does not show in the database dashlet, we've created a business transaction which group PurePaths based on the SQL statement (String param of parseDqlStmt). Unfortunately as this is a custom sensor, the measurement is just the PurePath response time, and not execution time of this particular statement. I should probably have added the max response time of the DfQuery.execute as well, but again it would not have pointed me to the exact problematic statement.
Attributes: Documents have attributes. They can have a lot of them, and these attributes can be complex thus leading to long execution time when loading
Hope this helps
Hi Andreas
Thank you for the assistance. The information will be very helpful in preparing us for the PoC and I will update you on the outcome.
Many thanks
Dean
Hi Dean,
I'm interested in the outcome of the POC you did on Documentum? We are experiencing some performance issues in one of our documentum environments and before we just deploy another agent there I'd like to know if it was useful?
Regards
Connor
Hi Dean,
Can you provide more info about how you instrumented documentum and did you disable anything in the sensor pack?
Thanks
Kamod
