What is the future of Documentum API?

Hi All,

i'd like to ask You: -what is the future of documentum api? Will be possible or not in D7 to use api?

Now the api calls already deprecated in DFC. For me, for example, it is very useful sometimes to use this functionality.

It is hard to imagine a good support w/o it. I mean it is not so comfortable to use requests to methods in code instead run of api script in DA for example.

Thanks in advance for your answers!

Find more posts tagged with

Comments

msroth

As far as I can tell (review of documentation), the IAPI client is still distributed with D7. I have no idea (yet) if API calls will still be supported from the DFC.

JorgKrause

Hi,

API is still handy, even if almost everything is now available through DFC methods

Especially if you need to modify stuff quickly, DA/API tester is useful.

In terms of "normal" deprecation, it should have been gone for a long time already, for sure. My best bet is that it will stay aroung until somebody rewrites all existion system methods to DFC

This will probably mean quite some time, right?

Haven't checked D7 yet, but main part of system methods (consistency checker++), is still implemented with api calls

Regards

Jørg

stephanemarcon

Hi Debis,

I did not have a look at d7 yet but I presume the iapi client is still provided and as the documentum guys have already made the iapi client call dfc methods using what is called the dmcladaptor ( if I understood the plumbering correctly), I don't think it's a big deal to make the iapi client function in newer versions.

So I would say that as long as we'll have a dfc which is similar to the one we have ( don't know what the documentum guys are preparing with the new ngis server...), api scripts will be supported.

Now, what I do not quite understand is why Documentum did not go for providing some scripting tools (and/ or examples), which would be based on newer scripting standards. They could at least provide some ant tasks which would ease scripting.

On our side, we've gone away from simpla api scripts and moved to java scripting administration scripts, using beanshell ( there are other scripting tools available, I think Java 6 already has some scripting funtionnalities). I think this sort of scripting is way more convenient than simple api scripting. Note that we also added some simple ant tasks which are used to script pre/post installation activities (we don't want to spend our time writing api or docbasic scripts). Note that you could also have asked the same question about docbasic future support :-).

Stephane

lastnitescurry

API will exist for a long time to come. Way to much legacy code to support. IAPI is great for debugging when on Content Server.

then again maybe some EMC product manager will decide this feature is of no use and ripp it out.... Personally I would perfer if they concertrated some energy on updating Composer (e.g. reference dar binaries,..)

Personally I would not write an API or DQL script for install purposes any more. Currently deploy config process is a hot deployable method (via BOF) which is called by a Job that is set to run on update. Has some limitations but great for logging, and no need for additional user names and passwords. Also simplifies my install documentation

msroth

FYI - Composer has been discontinued in D7; the xCP Designer is taking it's place. As for scripting, I used to script Documentum using Perl and the Db:Documentum module -- it was awesome. Check it out if you are interested.

Freejin

Thanks Scott.

Sounds good especially in that case that i haven't any deal with D7, yet.

@Scott, Brian

From one side It is sad to hear this about Composer (it is well known app), from another - Composer is in the list of unfriendly programmers applications (i mean for example if you try to sometimes to transfer projects from dev. env to client's test, it is lot of errors with artifacts may be. Need to spend a quite lot of time to fix). Hope xCP Designer will be better in case of work with artifacts.

Freejin

2Jorg:

Hi!

"In terms of "normal" deprecation, it should have been gone for a long time already, for sure."

- 'normal' it is right word i think. Right, it's logical We just made internal product with deprecated api's and it is working normally, tested for D6 platform only

Big THNX to guys who kept as more api's as they can

Freejin

Hi Stephane,

thanks for sharing your thoughts.

Now, what I do not quite understand is why Documentum did not go for providing some scripting tools (and/ or examples), which would be based on newer scripting standards. They could at least provide some ant tasks which would ease scripting.

+1 it is a riddle for me too. We created and improving our own tool in this matter.

On our side, we've gone away from simpla api scripts and moved to java scripting administration scripts, using beanshell ( there are other scripting tools available, I think Java 6 already has some scripting funtionnalities). I think this sort of scripting is way more convenient than simple api scripting. Note that we also added some simple ant tasks which are used to script pre/post installation activities (we don't want to spend our time writing api or docbasic scripts). Note that you could also have asked the same question about docbasic future support :-).

we also use Java but + api scripts function incide (with deprecated). You may ask -Why api? Because we have a quite a lot of tasks which can be solved faster with various api commands (support tasks).

Integration

Hi Does anyone post API doc for Documentum V7