Using Script API, DQL and EBS in the era of Content Server 7.2 and Composer

Cyborg85

Often with co-workers joke saying that if the DAB had still been supported by the client operating systems, they never stopped using it, even if it is no longer supported, and the alternative, the Composer, is derived from a solid IDE.

But where does this reluctance? it's just laziness in learning a new tool?

The truth is that the Composer could not cover all the needs of Docbase. This is why many will rely in part to the script, to the point that at some point the use of the Composer becomes really marginal.

When talking about scripts in documentum, you think about old tools and old technology, outdated and no longer maintained. Certainly the appearance of text tools iAPI and iDQL is not inviting for a new resource that you approach the various activities on the content server, above all when the alternative is graphic tools like Composer or dqMan (though not official). Likewise could be said of ebs script, those who know them yet? Now a new resource can write the same things in a more strong way in java (BOF 2.0).

The point however is that most likely in spite of all these methods seem a trail of Documentum 4i and the 5.x, the skilled resource continue to rely on these scripts to the various activities of development and maintenance of the content server. Think about how many times in designing a new application to create the various Groups, ACLs, Folders you have resorted to the script (apior dql) saved ordered between your project documentation, ready to be refined and then be released on various Docbase Quality and Production. We want to mention the creation of the types? although the Composer in a very similar manner to the DAB allows us to model quickly attributes and constraints, surely you happen instead of doing it also via script.

That said, in what situation are you? Manage a new application only with the Composer? you also use scripts? For what you happen to use them more? What your needs the Composer fails to cover?

I am interested in collecting these opinions to assess whether and where there is a lack of tools.

PanfilovAB

At first, "era of Content Server 7.2 and Composer" sounds ridiculous - CS didn't get any major changes since version 6.0, if my memory serves me right, the last major changes in Composer had came in version 6.7 when EMC had combined process and activity descriptors into single xml, so, in case of Documentum, if software continuously gets new version labels, it does not mean that this software is actively developed or maintained.

At second, in my opinion, composer has following disadvantages:

• it is nailed down to eclipse and embedded ant
• XMLs, it produces, are a piece of dog ****, especially US-ASCII encoding and attributes, which contain another XMLs
• it is unreliable when we want to load objects into repository
• it is slow when overriding existing types and process definitions

after some trials and errors I had worked out following approach:

• to load types and process definitions into repository we use composer with our custom plugin (https://github.com/andreybpanfilov/prodctm/tree/master/prodctm-composer/prodctm-composer-plugin)
• to load objects into repository we use groovy and json