Month: June 2004

Finally got my Cocoon Documentum Transformer fully functional this evening thanks to the good folks at the Cocoon Users Mailing List. My problem was that the Documentum xDQL query was returning a full XML document. When I tried to parse that, the extra startDocument and endDocument calls were causing the runtime exception (archived mailing list thread).

Now that I have my transformer working, I can configure any number of XML docs I want, each with any number of xDQL queries against any docbase my server can see. This is real handy because there are times when you want to run the same query against multiple docbases. I’ve currently got the pipeline configured to style the query results using a generic xDQL-to-HTML stylesheet, but now that I’ve got everything working, the sky is the limit. Here are some ideas…

Documentum admin portal

Go to one page and see very quickly what the status is of key metrics across all Documentum servers, docbases, and environments (Dev, QA, Prod). This is easily done using Cocoon’s aggregation of my styled query results. If I really wanted to get fancy I could use the Cocoon portal framework and create an honest-to-goodness portal with multiple users and profiles (different users might want to monitor different things on different docbases) as well as security.

But, at some point, this thing starts to approach the out-of-the-box Documentum Administrator client and I’m definitely not up for reinventing that wheel. So, this one is a lower priority.

Documentum RSS alerts

Create one or more RSS feeds that will syndicate alerts for things in the environment that need attention. To do this, I’ll add another transformation in my pipeline that will apply business logic to the query results and format “alerts” as XML. I will then add an alert-XML-to-RSS stylesheet. (I’m separating the two because I might want to format alerts in HTML). Once that is in place, I can use a news aggregator like Amphetadesk or NewsMonster to poll my Documentum RSS alerts periodically for things that need attention.

This one is nice because it does not force the admins to go to a web page–they just leave their aggregator running on their desktop.

Return Documentum Query Results in a Spreadsheet

Sometimes you’d like to be able to query multiple docbases and have the results in a spreadsheet so you can then do some analysis or whatever. Today you have to query each docbase and then cut-and-paste the results. With my transformer in place, I ought to be able to spit my query results into an Excel spreadsheet, PDF, SVG, whatever.

Open source and visible source.

Zope Corp.’s layered strategy of engagement with open source and visible-source communities is a compelling blend of the strengths of free and commercial software development. In two previous columns, Open source citizenship and Giving back to open source, I explored the tendency of enterprises to fork open source projects rather than join them. Pedhazur suggests that a commercial entity supporting both an open source base and a visible-source layered product can reduce the need to fork. By outsourcing code enhancements, the argument goes, an enterprise can enjoy single-throat-to-choke control without seceding from a project’s community. It remains to be seen how broadly this model can apply, but in cases where it does, what’s not to like? [Full story at InfoWorld.com]

In this two-minute clip, Zope Corp.’s Chairman Hadar Pedhazur describes the visible source model as a middle-ground option between the few large open source projects, whose direction an enterprise cannot easily influence, and the many smaller ones that enterprises can influence, but typically fork in order to do so. … [Jon’s Radio]

Documentum Puts Foot in BPM Market. Further challenging the borders of Enterprise Content Management companies and definitions, Documentum today announced the immediate availability of its Documentum Business Process Management (BPM) solution. The Documentum BPM solution consists of several new products, including Documentum Business Process Manager, Documentum Business Process Services, Documentum Forms Builder, and the latest version of Documentum’s enterprise collaboration solution, Documentum eRoom. Unique to this… [cmswire]

Ektron joins the forms-as-content race. It was perhaps inevitable that e-forms and content management would begin to converge at some level. For the past couple of years, various CMS vendors — especially the hosted sol… [CMSWatch Trends and Features]

I’m floored that the ECM vendors haven’t filled this gaping hole already. Customers spend hundreds of thousands or millions of dollars on an ECM footprint. Then, when they get it up-and-running, they ask the simple yet inevitable quesiton–How do I put some forms in my portal that can pump the data right into my ECM platform’s workflow and repository? The answer has been, “Just whip up a webapp. Here’s the API reference.” It’s a huge step backward. Not to be Old Lotus Notes Guy here, but hello? It should be nearly code-free at this point, particularly as standards like XForms gain momentum.

Netflix and Cocoon steal time from blog

Two things are stealing time away from the time budget previously allocated to blogging:

1. Netflix. Having a constant supply of movies on-hand that have been on my to-be-watched list for some time is awesome, and I love that I’m getting caught up. But, the blog has suffered.

2. Integrating Documentum with Cocoon. I got my DQL Transformer working some time ago but I ran into a problem transforming the DQL query result with my stylesheet. What sucks is that I had to upgrade my DFC and all of my WDK apps because of my current project, and after that, I discovered the problem. So now I’ve got to figure out if it was the upgrade or something else.

Until now I hadn’t been able to get logging to work from my custom transformer but this problem forced me to work through that. It turned out to be a simple thing that just wasn’t documented clearly. The solution was to use the logger attribute on my transformer declaration in sitemap.xmap like this:

<map:transformer name=”dqlquery” src=”com.navigatorsystems.cocoon.dctm.transformation.XdqlTransformer” logger=”sitemap.transformer.dqlquery”>

The category declaration in logkit.xconf matches up with that like this:

<category log-level=”DEBUG” name=”sitemap.transformer.dqlquery”>
  <log-target id-ref=”dqlquery”/>
  <log-target id-ref=”error”/>
</category>

The DQL Transformer works like the SQL Transformer. It receives SAX events looking for a query element. When it finds it, it executes the query against Documentum as an XDQL query (ie, the DQL query results get returned as a well-formed XML document). The XML that gets returned gets sent to the next component in the pipeline (like another transformer or a serializer).

I am now back to running on Cocoon 2.1 instead of the version that came with the Cocoon book. And I’m running it on Tomcat 4.1.