Troubleshooting with IAPI

May 9, 2007 at 10:29 pm | Posted in Troubleshooting | 2 Comments

IAPI stands for the Interactive API interface, a command line utility for submitting Documentum API calls to the server. IAPI is part of the Unix Content Server installation. On Windows it is called IAPI32 – presumably the extra ’32’ is a reference to the 32-bit windows platform; I guess the original 16-bit Windows implementation was called IAPI but that was before my time!

Since the API is the lowest level interface to the Content Server IAPI is a great tool for troubleshooting when you want to cut the higher-level interfaces out of the equation. Normally you run IAPI directly on the Content Server machine, however there are circumstances where you are able to successfully test functionality on the Content Server but access from other machines (like WDK running on a remote application server) is still failing.

In this case it is often not clear whether the problem is with the DMCL layer on the app server trying to connect to the content server or maybe a problem higher up in the ‘stack’. One quick way to confirm whether the problem exists at the (remote) DMCL layer is to copy iapi/iapi32.exe plus the corresponding DMCL shared library ( or dmcl40.dll) to the App server and then test the remote DMCL by running IAPI remotely.

However there is a problem if your remote DMCL is running on a different platform from the Content Server (e.g. app server is on windows and the app server is on Solaris) as IAPI will only run on the platform it was compiled for. In this case you should be able to download the corresponding Content Server installation and extract the required files.

It would be great if Documentum would make IAPI/IAPI32 generally available as a separate download. On a similar note Documentum 6 is likely to remove the need for a separate DMCL shared library by moving all the DMCL code into the DFC java layer. Will they be providing a similar tool that allows simple low level API tests? I hope so.



RSS feed for comments on this post. TrackBack URI

  1. I built the original iapi as a testing tool. We wanted the API to be character-based so that people could actually see what was going on. The terse format was not a whole lot longer than a binary format and was easy to integrate into things like OLE and DDE before that.

    iapi would read the string and execute it. It could also read a set of strings from a file so that we could use it as automated test tool. The QA team could also record what they were typing in. (Is Sophie Amerbikian still there?)

    What I am now surprised about is that the structure of the API and how we dealt with the string structure and the very basic commands was very REST-like 10 years before the concept was invented. Because DFC is not really string-oriented and is very object-oriented, it is difficult to see how it could expose a comparable interface.

  2. Good to hear from you John. Having had a look at the Documentum 6 pre-release it looks like iapi is still being shipped but appears to be using DFC. I’m not sure at this point exactly where it is hooking in, I’ll likely post about this in a week or so. It’s slightly intriguing as it looks like the flat API is being mapped to object-oriented DFC. And since DFC arose as an object-oriented wrapper around the API I wonder who is holding up the bootstraps?

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Create a free website or blog at
Entries and comments feeds.

%d bloggers like this: