The making of DragonFly

You can Download the latest release, here,
You can get deploy information here

The background behind the IBM Data Merge Utility is somewhat convoluted. I guess you could say that it's roots are in the creation of a set of dBase templates that when used in conjunction with a text editor search/replace feature allowed me to significantly improve my personal productivity as a developer. Years later, the manager I worked for at the time told me he thought that was the most important thing I had done for him. At the time it didn't seem that significant, just the result of a lazy programmer faced with a repetitive task.

The next time I found myself faced with a repetitive task was in the creation of complex proposal documents. I found my self re-using a base set of content, combined in different ways and all tied back to an master spreadsheet that seemed to have most of the critical data needed to piece together a draft. The tools that arose from that job were a set of template based merge tools that used Excel tables as a data source, and Microsoft Word templates that were merged using VBA code. I should note that this was my first major VBA development effort, and the project went through several phases before stabilizing. Once it was stabilized however, I was able to complete a significant portion of my work in much less time, and now had time to explore other potential uses for the idea.

The next iteration of the tool was written in Perl, and used XML formatted templates and CSV data files for merge data. An initial proof of concept of this tool allowed me to collect deployment configuration data for a complex multi-server environment, and generate software installation and configuration scripts for each individual component based on re-usable scripts being combined in different ways. The utility of this tool was becoming more evident, and an opportunity presented itself to create a real industrial strength tool based on the concepts of search/replace and insert.

In migrating the tool to a web interface I was not too worried about moving the actual merge process to Java, as the VBA code was OO (as much as VBA is OO), and the Perl code was all done in OO-Perl, so the Java migration should be pretty smooth. I was however presented with the challenge of developing a client-server web application to replace the XML text files that had previously hosted the templates. 

As a software architect I periodically do a survey of technology that is used to create software applications. My last serious survey of new technology occurred during the emergence of the SOA design revolution around the turn of the century and covered Asynchronous Messaging, Web Services as well as J2EE (Servlets and JSP) with a brief look at JavaScript. In the fifteen years that have passed, Messaging technologies have continued to provide a more and more robust service bus architecture. WebServices and J2EE and have remained the at the top of service provider technologies in use, but the newcomers PHP and nodeJs are gaining popularity. In the service consumer area, the Web Browser UI backed by new jQuery, AJAX and JSON technologies are accelerating software development. 

This is the full technology stack I selected:

  • MySQL - You should be able to use any JNDI data source
  • TomCat - You should be able to use any J2EE container
  • PHP - Used by optional for Template Editor tools
  • jQuery - Used by optional Template Editor tools

After finding the jQuery libraries at www.datatables.net, and familiarizing myself with the jQuery and PHP languages I was astounded at how quickly the Editor and Training UI's came together. They are admittedly primitive, and I have several ideas for a better UI, but as a replacement for Excel and Text file editors they are more than sufficient.

I tend to work on the project as time presents itself, but this effort caught my imagination, so I dedicated quite a bit of personal time to the project. Initial implementation of the Template Admin UI took only a few days, and the initial migration of the Perl code to Java was only a few days. In truth, I've probably spent more time inventing test data, and templates for testing than I actually spent coding. Performance testing was challenging, as I had a concurrency defect that didn't show up until the system was loaded above 20,000 Transaction / Minute, but when that was solved I was able to attain sustained throughput of well over 25,000 TPM on a Linux VM with only 2CPU's and 512kb of RAM. 

It wasn't to long before I found someone interested enough in the project to fund some real development work, and was able to engage two talented professional developers to contribute a professional "j2ee" polish to the application and a real single page web-app for Template Editing. As a result Version 3 of the IDMU was released and made available.

I hope you enjoy using the IDMU tool, and find it easy to use to create your output from data without programming. 

Thanks