Cutting TeamSite Meta Tag Form Load Times From 30+ to 2 Seconds

Many long time OpenText TeamSite implementations populate metadata dropdowns (taxonomic tags, product types, category lists) using the original pattern: an <inline command> that executes a custom Perl script for that field’s options.

<inline command="d:/Interwoven/TeamSite/iw-perl/bin/iwperl.exe
                 d:/Interwoven/TeamSite/local/bin/category_list.ipl"/>

This legacy behavior works, but it’s resource intensive, slow and response times scale with the number of fields with Perl scripts and files selected to tag. Every one of those tag fields launches a separate iwperl.exe process. Each launch pays for Perl interpreter start up, additional driver loading, and depending on the source of the tag options, potentially databsae queries or API calls.

Customer Case Study

We were engaged by a customer whose authors had to endure wait times of 30+ seconds to load before they could fill out the tag field values. This led to a very inefficient content authoring experience.

Upon investigation, the slow response times were caused by their custom Perl tag field population scripts requesting the options from an Oracle Database. Each tag field was being populated by its script, but each script was generally just executing a SQL Select query. Each field execution required a new database connection.

Conversion of Perl to the TeamSite Java Data Source Framework

The Java Data Source Framework runs natively within the TeamSite application, so new new processes are needed. Additionally, TeamSite already includes the required depenencies to provide a pool of database connections that can be shared across the application. The elimination of additional processes and opening and closing a database connection for each field dramatically reduces the wait time.

The diagram below illustrates the before and after meta tag field option population flow:

Solution Details

Given our analysis discovered that the majority of custom Perl scripts was just making a database select query, we created a single Java Data Source that performs a database query and returns the results as field options.

We provided a database connection pool using the Java Web Application ServletContextListener interface which guarantees it is loaded and available on deployment of the TeamSite UI.

Converting an existing field is two steps:

1. Register the query. Add one <datasource> block to the TeamSite DataSourceConfig.xml file with that field’s required SQL query:

    <datasource>
        <name>CategoryListDataSource</name>
        <classname>com.example.teamsite.datasource.QueryDataSource</classname>
        <param name="sql">SELECT ID, CATEGORY FROM table_name ... ORDER BY CATEGORY</param>
    </datasource>
   

2. Point the field at it. Swap the Perl inline command in the meta tagging .cfg configuration file with a reference to the name of the Data Source defined in the previous step:

    <!-- Before -->
    <inline command="d:/Interwoven/TeamSite/iw-perl/bin/iwperl.exe
                     d:/Interwoven/TeamSite/local/bin/category_list.ipl"/>
   
    <!-- After -->
    <inline command="Datasource:executeComponent:CategoryListDataSource"/>
   

No new Java class, no new code path, just a query and a unique datasource name.

Same four fields represented both ways. Left, each one opens and tears down its own database connection. Right, all four share a pool of connections.

Why the Savings Scale

The benefit scales with how a meta tag form is used by content authors. A single field options lookup now costs a few milliseconds instead of several hundred, but the real win shows up when working with batches of files: tag ten files with five fields, fifty database queries now borrowing an open connection from the pool, instead of fifty individual process launches and query executions each setting up and tearing down its own database connection.

The Result

A tag field options lookup that used to mean starting an interpreter, loading modules, and opening a fresh database connection now runs in a few milliseconds against a connection that’s already open and waiting in the pool. Forms with several dropdown fields now render about as fast as a user can click into them, and adding another tag field with database populatd options is just a configuration change, not a development project.

Dicovering and optimizing poor content author experiences is exactly the kind of problem Klish Group’s team of experts can track down and resolve.

Talk to Us About Your Poor Author Experience