XML to PDF
Some History
XML to PDF is another product that has its roots in two particular quirks of the iSeries. As with database conversions, in its older incarnations the iSeries was very unfriendly to transporting data to different platforms. Also, at a moment (perhaps the older readers will remember) IBM shipped a product called Office Vision as part of OS/400. This product was essentially a word processor. I believe that it grew out of an old PC Dos IBM product called Display Write which was in competition with Multimate and Wordstar and Wordperfect and the like. By the late 1990's when compared to PC word processors like MS Word this product was utterly terrible, however it had three great advantages. Firstly it ran on the iSeries. Then, with some training and effort it allowed one to create fairly reasonably laid out documents. Lastly and perhaps most importantly it had a built in (very sophisticated) mail merge type of facility that could be used merge a template document with database information thus providing a good way to send invoices or statements or policy schedules to end users. But then the world changed as it so often does. Around the time when the iSeries transitioned from CISC to RISC architecture, IBM decided that Office Vision was no longer a strategic product, and dropped support for. I do not know whether this was as a direct consequence of the underlying hardware change (unlikely as the back-end library executed right up until V5R4M0) or a marketing initiative to get iSeries folk onto Lotus Notes. In all events the last release on the iSeries where the back-end merge facility and the on screen editing all worked was at V4R5M0.
Office vision allowed one to mix a standard mail merge (where each source record would generate a new document populated with Name / Address and etc.) with a bunch of replicating merges within the document. Thus a typist proficient in Office Vision could set up a template for an customer order with address information order header information and line item information which could be batch merged on the iSeries to produce fully formatted documents. In addition Office Vision had the capability to include graphics (logos, line item illustrations, and etc.) dependant on database content.
Hence the requirement for a means to generate fancy end user documents with all of the magic that was built into Office Vision. While all the PC word processor offerings and Lotus Notes had a mail merge facility, none of could come close to Office Vision's proficiency in this field. Neither did any of the (very expensive) commercial offerings purporting to replace Office Vision have the required flexibility. After many many months of investigation and trials I figured the best way forward was to roll my own product, and xml2pdf is the end result.
The actual product
The core of the application takes XML data and merges it with an Open / Libre Office document to generate a resolved pdf document. XML can be sent into the application with a web service call, or it can be ftp'd to the server running the application for batch processing. The final or resolved document can be sent via email or ftp. Aside from the work required to get an application to export XML data, the application allows creation of professional client facing documents without programming intervention. It will interface with anything that can invoke web services, or even anything that can ftp XML documents to the application. Open / Libre Office is an open source office suit similar to the Microsoft Office suit. Crafting of template documents is simple word processing, and with a bit of training any competent typist can build the templates.
The application is able to merge several template documents into one final resolved document. e.g. for a new client, one could publish a welcoming letter combined with an insurance policy schedule and then append some cross marking material or a policy holder protection document.
Correspondence can be "white labelled" in by including images depending on data items in the XML e.g. different banners or logos in the resolved document depending on the product supplier.
It is able to show or hide entire sections of text depending on XML content. e.g. only relevant clauses can be generated depending on which sections of insurance cover is provided for a client.
It can send to many recipients at once. e.g. mail to the client, mail to an insurance assessor, publish to the internal repository, and ftp to different document repository
Money Talk
The simplest method of deploying the product is in a drop and play virtual machine which provides a full range of functionality. The VM is Debian linux, and it comprises Windows or Samba file sharing of documents to be edited, and a web/ftp server to access resolved documents. The VM includes a built in web site that allows resolved documents to be published for fetch functionality rather than a document push. This VM can pe purchased outright, or licensed for use with support.
For people that wish to integrate this with their own application, a binary C library is available. As with database conversion, I am not very keen to release PHP code; that is not copy protectable in any real fashion. However if you are in a PHP environment where such functionality would be useful and you have some $$$ to spend, I am willing to discuss.