Friday, August 16, 2013

One Reason to Use EGL: External Types

Whew! I just finished working on a major software feature for my ultra-conservative corporate customer. It provides me with one great reason to use EGL, and specifically, the EGL Development Toolkit (EDT).

I was asked to do the (seemingly) impossible: Duplicate an existing process to create form letters. A few thousand different forms needed to be converted to the new process. While BIRT might have been a general solution to the problem of producing PDFs, there wasn't enough time. I've used BIRT successfully. Generally, I would recommend it. But, designing a few thousand BIRT reports didn't seem to be the right answer.

I used EGL to prototype the PDF generation process. While the development environment was strictly Rational Business Developer, I chose EDT as the tool to build the prototype. And, I'm really glad I did. EDT provides a New | External Type feature, to generate external types from an existing Java library. I imported the iTextPdf library (at www.itextpdf.com). I bought the electronic book: iText in Action.

Within a few minutes, I generated my first PDF. It wasn't much. Writing the code in EGL made it easy to think about the problem in high-level, business-logic terms. I was able to change my mind several times while exploring different designs without the complexity of refactoring Java source code. And yet, external types enable me to use the off-the-shelf iTextPdf library, with all of its power to read and write PDFs.

I connected my PDF generator to a frame library (Framing Software, XVCL) to store key-value pairs in an SQL database. In this specific case, an analysis of a few thousand forms showed a very distinctive pattern and consistency of purpose for the form letters. Knowing exactly what needed to be produced, I was able to create a custom form letter editor. The letter editor provides a mechanism for variable substitution (lifted directly from Apache Ant).

And then, it hit me. The original form letters were composed with Microsoft Word and stored in an open document format. Tapping again into the power of EGL and external types, I imported the text (but not formatting) of the existing form letters into the frame table, using an EGL business logic library. With the text of the form letter in the editor, it was (relatively) quick and easy to add formatting to recreate the original form.

Importing from Microsoft Word to a BIRT report is beyond my technical skill at the moment. This turned out to be the right answer to the specific problem facing the customer. They needed a new way of generating form letters in their production system and, with demands from their customers, they only had thirty days to do it.

Working with EGL alone, I wouldn't be able to finish the project. And working with Java alone, I wouldn't be able to quickly build a succession of prototypes, trying and working through different design ideas.

The best design was selected and imported into Rational Business Developer. While the syntax is similar, EGL written with EDT did not simply drop into the customer's version of RBD. It had to be reworked, especially lack of support for a question mark (?) at the end to indicate a nullable type. At the end of thirty days, end-users were generating customizable PDFs using production web application.

Now, that's a good reason to use EGL. What do you think?