Many companies face the problem of producing documents printed in a sequence coming from disparate, seemingly incompatible sources such as static text documents, scanned images, and legacy iSeries spool files. Such was the problem faced by The Londen Companies, a family-run, privately held insurance company headquartered in Phoenix, Arizona. That is, until they were able to develop a system that produces ordered meta-documents that will print in a specific order with the help of some custom programming and two software products of RJS Software Systems, Inc., iSeries Office Integrator and WebDocs.

Founded in 1963, Londen Companies provides a full range of accident, life, and health insurance products. Although family-run, Londen isn't a small operation, issuing as many as 70,000 new policies each year. Its core business applications operate on an iSeries model 520 running V5R3. Specifically, the model 520 is where Londen maintains its policies database and the applications associated with policy maintenance and issuance.

The Crux of the Problem

The core of Londen's policy issuance process is an iSeries application that also accesses some standard pages stored as Microsoft Word documents. When customers buy insurance, Londen provides them with a "policy wrap," a composite document that explains their coverage. A wrap consists of up to four parts.

First, there are static documents that are the same for every policy (e.g., standard disclosures, claim forms, HIPAA privacy notices). Second are documents that were scanned into an imaging subsystem (e.g., signed application forms) that must be reproduced along with the other policy documents. Third are customized forms and documents (e.g., personalized cover letters, beneficiary designations, statements of premium amounts and due dates). Finally, there are policy benefit and cost disclosures, which are report-type documents that are produced and printed on the iSeries. Every policy requires issuance of some or all of these document types.

In most document-management scenarios, particularly when dealing with small volumes, applications typically produce these types of documents via data files and merge templates. At Londen, even documents produced on the iSeries did not all come from a single data source. The company stored imaged documents, such as signed copies of the insured's original coverage-request forms, in an older version of IBM's Content Manager. The policy-issuance application produced other pages by using overlays and printer file DDS to produce fill-in-the-blank documents.

Londen's problem was that because these various print sources were functionally incompatible, the creation and assembly of a single policy wrap document required running of multiple processes, each of which produced its own stack of printed output, which then had to be hand collated to create a set of pages for mailing to customers. This was a process that, as the company grew, became more and more unwieldy, and needed to be replaced. Londen required a solution that would simplify the process of producing insurance policy wraps for its clients.

A New Plan

This wasn't a straightforward solution. The first plan was to build graphical overlays of all possible forms on a PC, then upload them to the iSeries. However, when project engineers calculated that there would need to be more than 100 different forms, some several pages in length, that concept had to be scrapped.

After considering many other options, the project team chose a design that required formulation and storage of every possible policy wrap document in an Adobe PDF file. This afforded the most flexibility for the policy wrap process in both production and printing. The document sources could be the iSeries, an imaged document, a static PDF file, or something else, but the final preprint document would be in PDF format. By making the wrap components PDF documents, London could print them on any PC-attached printer anywhere in the company.

Software Components

This design relied on software products from IBM and RJS, an IBM Business Partner, and just a few software components outside of standard OS/400 software. IBM's software contributions were Infoprint Designer, which provides a GUI for laying out any iSeries-based forms and for controlling the placement of data into the overlay, and Infoprint Server, which provides automated conversion to PDF format for any iSeries documents and gives users control and monitoring capabilities of the destination within the IFS where the PDF files would reside. Londen used Microsoft Word to create mail-merge documents (templates that are merged with policyholder-specific data) using data files created on the iSeries, along with end-user maintained document templates, and the full version of Adobe Acrobat to create PDF documents from the mail-merge process.

The two software products from RJS Software that were part of the solution are Office Integrator and WebDocs. Office Integrator provides controls for iSeries-to-PC communications. For purposes of the project, the most important were the abilities to transfer a merged data file from the iSeries to a client PC, to request printing of PDF documents by document name and destination printer, and to execute a mail merge on a PC, which also controls the input document template, the data file name, and the "print" destination.

WebDocs is an iSeries/PC cooperative application that lets users create indexed imaged documents (which are stored in TIF format) from either scanned or spooled documents and print them using any software that can accept TIF input. Londen undertook a second project to migrate all of its imaged documents from IBM's Content Manager to WebDocs. The policy-wrap system uses WebDocs' indexing capabilities to find and retrieve imaged documents for later printing during assembly or to wrap meta-documents.

The Policy Wrap Process

After some custom programming to make the pieces work together, Londen's new policy-wrap printing system was ready to go. The custom programming mostly involved modifying the policy-print process to create new PDF documents in place of the old conglomeration of disconnected documents and writing the sequence of document-print requests into the Document Print Data Queue. The new policy-wrap printing system works as follows (see Figure 1 for a diagram).

The wrap driver program reads print requests that tell it what policy to print on which destination printer. RJS's iSeries Office Integrator, running on a networked PC, directs nightly production runs to a high-speed system printer. Ad hoc requests from users can specify other target printers, such as a department printer centrally located near a group of customer service agents. In fact, users can request a specific policy wrap to print on any printer configured to work with the RJS software.

The wrap driver accesses a file of document requirements based on policy and plan information. This file, in conjunction with the policy file, controls the selection of documents and reports. Based on those requirements, the system can call another iSeries program to produce a report (B), use WebDocs to request that an imaged document be printed (C), or print a static or merged Word document (D). The final output from any of these is a PDF document stored in the IFS (E). For iSeries output (B), the system uses an Infoprint Server output queue that's configured to convert the spooled file to a PDF. Infoprint Server can convert any spooled file to a PDF document and store that document in the IFS. After the conversion, Infoprint Server writes an entry to a Completion Data Queue, which is a queue Infoprint Server creates automatically each time it completes a spooled file-to-PDF conversion. The format of the entry is explained more completely in Appendix B of "IBM eServer iSeries Printing VII: Infoprint Server Implementation" Redpaper at www.redbooks.ibm.com/abstracts/REDP3752.html?Open.

A monitor program waits for applications to write entries to the Completion Data Queue. If an entry is identified as being part of the policy wrap process, it's reformatted and written to the Document Print Data Queue for eventual conversion and printing as a PDF document. The Document Print Data Queue is keyed by job, policy, and sequence number and controls the printer used and the order of document printing.

The PC running iSeries Office Integrator also runs a complete version of Adobe Acrobat and handles all print-to-PDF processing for imaged documents and any status/merged Word documents. With this software combination, the driver program can send commands to the PC to print to a named PDF file using an Adobe PDF writer process.

From the IFS folder (E in Figure 1), documents move to the user's selection of network-attached target printers configured for use with the wrap process. The print monitor process, which is the interface between the stored documents and the various printers distributed throughout the building, accesses the printer specifications and names for each printer stored in a database file on the PC.

Word documents, whether static or requiring a merging of a template and data file, are processed in a similar manner. The wrap driver program sends a command to Office Integrator on the PC, after which either a simple print request or a merge-to-print request passes to Word. The printed output goes to the Adobe writer. The output PDF file is a shared IFS folder that has been mapped to a drive letter on the PC so it's easily accessible by the PC-based software. Print requests for these documents are written directly to the Print Data Queue for handling by the print monitor.

Processing Print Requests

The actual processing of print requests takes place between the IFS and a user-specified output printer. The Print Data Queue Monitor program handles the printing of policy wraps by reading entries from the Document Print Data Queue and then sending a print command specifying a particular PDF document and the output printer and paper drawer. After printing, it archives the printed documents into appropriate IFS directories. This queue is keyed using the following sequence:

• Sequence Number — a six-digit sequence number that indicates the start of a block of entries (this number begins at 000000 within a job; the last entry for a job number is always 999999, regardless of the number of intervening entries)
• Job Number — the number of the iSeries job that created the entries
• Job Qualifier — a four-character code that lets users subclassify the entries within a job (although not actually used in the current policy-wrap driver design, it was included for possible future use)

For each detail (sequence number between 000001 and 99998) the monitor program verifies the document's existence, then uses print control information in the data queue to determine how the particular document is to be printed. This information includes the physical printer and the data queue entry, which specifies the paper drawer the printer should use and whether the document is to be printed simplex or duplex. The driver program uses this information to read a physical file that correlates these attributes with a printer specified within iSeries Office Integrator.

Within iSeries Office Integrator, the driver program must tie each unique printing mode to a specific document because it isn't possible to control printer drawers or simplex/duplex mode when executing an automatic document print with Adobe Acrobat. Each named printer therefore requires default document print properties defined for one print mode. The printing monitor then instructs iSeries Office Integrator to, for example, print document "X" on printer "AgentsDrawer1Duplex."

After a complete policy wrap is printed, the driver program copies the documents to dated folders within temporary directories on the IFS. This provides archival storage for processed policy wraps. Separate "clean up" processes delete documents and directories older than a specified number of days.

It's a Wrap

With this new system, Londen can print its policy-wrap documents as complete sets instead of scattered piles of paper that must be manually collated. Users can print the policy wraps on any printer on the company LAN/WAN as long as the target printer is configured within iSeries Office Integrator and users add the necessary printing mode entries to the printer lookup file.

The new system also gives Londen more flexibility, for example, in its ability to implement changes to portions of the policy wraps. Previously, wrap changes would have required some combination of programming changes, DDS changes, and possibly redesign of overlay objects. Instead, users can now implement most changes by simply adding or modifying the underlying Word and PDF documents and making corresponding changes to the necessary control files.

Londen is pleased with the project results. "Our goal is to be able to print policies on any printer in the building instead of relying on our one large production printer. This will give our users instant access to any prints instead of waiting for operations to print and distribute them," notes Carol Berger, Londen's project manager. "Another goal is to let us print using different fonts and features that are tedious to program on the iSeries, for example, spell check, line wrapping, and justified margins," she adds.

"An additional benefit is that the various people in charge of the wording on printed documents can modify wording themselves without having to wait for a developer to make changes in a DDS," Berger concludes.

A project of this type is suitable for any company that needs to produce printed output that includes some standard documents and varying alternatives. By combining the iSeries, a client PC, and the RJS products, enterprises can blend these components to provide a useful system without the expense of building a complete custom application.

Chip Milosch is president of Griffin Computing, a company that specializes in iSeries consulting. Chip focuses on implementation and user training for Infoprint Designer and Server, iSeries-to-PC integration, WDSc, and output distribution modernization. He has been a speaker on system-output related topics at several iSeries DevCon conferences. You can reach Chip at chip@griffincomputing.com.