Testing D2 development and REST services

After the summer, I’ve found myself with some spare time between projects that I’ve used to review some EMC products:

  • D2 4.1

Over the years, we’ve developed a webtop based solution that includes several custom developed components like import from external source, TBO’s/SBO’s used to name documents/folders, etc.

So after attending several D2 demos, we decided to do exactly the same with D2 (or at least get as close as possible) as a testing project.

Custom naming/default object creation was the easiest part, as the autonaming and autolink features are functional enough to cover our needs.

Import from external source looked like it was going to be tough, as we couldn’t touch the default import, and the development documentation is… lacking. So after a little investigation thorugh the available documentation and the community, we decided to go with the external widget approach and it was quite easy actually: Take our custom applet from webtop, put it on a jsp and communicate with the D2 import component sending the files… no problem at all

Some other functionality that involved modifying default D2 behavior required to developed plugins, but after reviewing the API and the available examples we decided not even trying because currently is a waste of time trying to figure which method/libs you need.

  • Good: external widgtes are extremely easy to develop, and there is enough documentation to be able to communicate those widgets with D2 without killing yourself in the process.
  • Bad: plugins are useless as there’s no reliable documentation available, and it seems the API could change in future versions, making useless old plugins.

To sum up, I think D2 4.1 is more a beta/unfinished product (which it really is, as EMC is doing everything from scratch to made it compatible with browsers other than IE, and currently is missing features that were on previous versions). I’ve heard that D2 4.2 is a more mature product and that effors have been made regarding development documentation. If EMC wants to “kill” wdk application with D2 and xCP2 they better give us enough tools to do our customizations, as by now we all should realize that the idea of “configure only” is cool, but is far from our daily work…

  • REST Services:

I’ve been developeing different solutions with DFS (extra layers to the services, custom clients both in JAVA and .NET, bulk load applications, etc) since version 6.0. Afterwards I migrated everything that could be done with the CMIS standard to CMIS with Apache Chemistry; so it was clear the next step was trying the new REST services.

Before the summer I started developing an Android application with the REST preview just as a proof of concept (and as a way to learn how android applications work), and it worked quite well. Last week I’ve been updating the application using the REST 7.0 services (finally we have a working query service!!!) and cleaning/improving the android application that has now become an administrator tool that lets you check repository status, browse the repository, open files, check job status, etc.

I hope to keep improving the application and I hope EMC keeps the REST services, as there is way easier to develop with these REST services than using the monstruosity that DFS are. However, if CMIS meets your requirements, I still go that way, as it is a standard…

 

 

EMC Proven Professional Certifications (Documentum)

Recently I passed my 4th EMC Certification, and I’m currently preparing other 3 (WDK and both architech tests). At this point I wanted to post some thoughts on the program (even though some of them have alreadey been discussed here -> IIG Certification)

So, should you get certificated? Definitely yes, but probably not for the reasons you expect. If you’ve been working with Documentum long enough, most test are “easy” (as long as you’re familiar with the topics), however, if you really dedicate time to prepare the certification you’ll end up reading every document that covers information on the topics (and that takes time), meaning the fundamentals guide, administration, dfc development guide, wdk development guide, etc. And by reading I mean reading, not quickly passing page after page. This careful read will refresh concepts and features, you’ll propably learn some new things you had overviewed before in the release notes and others you had no idea about… And you’ll get a new certificate that says that you know a little bit about Documentum

And some tips on the tests I’ve taken:

  • E20-120/110 (Foundation): Easy test if you take a look to the fundamentals guide and you’re a little bit familiar with xCP. New 110 brings D7 stuff so it’s going to be harder unless you’ve gone through install/migration
  • E20-495 (xCP): Though test, many products involved. It’s going to be updated in October and it will be only about xCP 2.0. Personally, I don’t understand why this tests only covers xCP 2 and the Foundamentals covers 1.5 and 2.
  • E20-465 (Administration): Read the administration guide. Easy even with the D7 stuff included in the last revision
  • E20-405 (DFC): If you’re done some DFC coding and read the DFC development guide, it’s an easy test, though it needs an update on the topics.

On the tests I haven’t take yet:

  • E20-455 (WDK): Pretty much the same as DFC test.
  • E20-475 (System Architecture) / E20-485 (Application Architecture): Probably the hardest ones. There’s no specific documentation available, questions look outdated, and sometimes it seems you’re doing an storage certification rather than a “documentum architect”, IMHO both test should become one Documentum Architect test.

Good luck!

 

 

Composer/Repoint plugins/guides

 

This is a list of plugins/guides I’ve developed over the years:

This Composer plugin provides a button that allows you to quickly change your dfc.properties configuration from a configurable list enabling the use different environments so you don’t have to use different composers or manually change dfc.properties.

This guide will help you integrate repoint into your composer (as a perspective), so you don’t need to have multiple eclipse’s instances opened at the same time.

While repoints allows you to run API scripts from the API commands windows, it doesn’t work with DQL scripts. This plugin modifies the DQL command window so it will recognize the script sintax (@absolute_path_to_script_file)

This plugin modifies the DQL command window in repoint so you can use the auto-complete feature with default/custom document types and attributes while you type the DQL query.

 

 

UCF troubleshooting

Check the updated version of this post here: UCF troubleshooting v2

Don’t we all love troubleshooting UCF problems? Here’s a quick list of common solutions to usual problems:

UCF installation paths:

  • Windows XP: C:\Document and Settings\[user]\Documentum
  • Windows Vista/7/8: C:\Users\[user]\Documentum
  • Linux: ${home}/Documentum

Timeout/browser/jre problems:

  • Check the supported environment tables in webtop/da release notes. Most JRE versions will work even when aren’t supported, but you’d better check if the supported version works.
  • If not needed, disable ACS and BOCS.
  • If using a proxy, add host’s IP and hostname to the proxy exceptions
  • In case the UCF aplet cannot be installed, try disabling DEP protection
  • Delete the local UCF installation and try a clean installation
  • [Firefox] Check Java plugin is enabled. Mozilla automatically disables outdated JRE plugins.
  • [IE] Check Sun/Oracle JRE is the default JRE, disable ActiveX filtering, and check Java plugins are enabled in the Manage Addons window.
  • [IE/Firefox] If you are working with a 64 bit Operating System, check if you’re using a 32bit browser with 32bit JRE. 64 bit browser/JRE with UCF is probably a bad idea.
  • [IE] Check Java integration with browsers is enabled.
  • [Java control panel] Delete JRE caché
  • [Java control panel] Disable the next generation Java plug-in.
  • [Java control panel] Disable verification of mixed code security.
  • [UCF configuration] If UCF keeps throwing a timeout, disable the IPv6 compatibility by changing the following line in ucf.installs.config.xml (located in ${Documentum_UCF}/ucf/config)

true”/> tofalse”/>

Manual installation:

  • You can install the UCF applet in the client computer manually, just run the folowing bat script:
set DIRNAME=%~dp0%lib\
set URLDIR=%DIRNAME:\=/%
java -cp %DIRNAME%ucfinit.jar com.documentum.ucf.client.install.TestInstall "file:///%URLDIR%" "ucf.installer.config.xml"

This is the structure/files you need for this script to work (you can find these files in /wdk/contentXfer/):

UCFTestInstall.bat
\lib
\lib\ExJNIAPI.dll
\lib\ExJNIAPIGateway.jar
\lib\jacob.dll
\lib\jacob.jar
\lib\ucf-ca-office-auto.jar
\lib\ucf-client-installer.zip
\lib\ucf.installer.config.xml
\lib\ucfinit.jar
\lib\UCFWin32JNI.dl