Inforama Document Automation System 1.2 Released

Discussions

News: Inforama Document Automation System 1.2 Released

  1. Inforama is a Java based Document Automation system which allows document templates to be created quickly and easily using OpenOffice. Templates are populated with data from parameters and databases before being generated into PDFs for printing and emailing. Version 1.2 includes some significant enhancements and bug fixes. Hibernate and POJOs integration Inforama can retrieve data from Hibernate and POJO data sources. Tables and other document elements can be created dynamically based on Hibernate and POJO datasets. For more on this feature go to http://in4ama.org/web/guest/community/wiki/-/wiki/Main/Java%20Beans Excel integration It's now possible to merge documents with data from spreadsheets. This is particularly useful where data has been extracted from a main database in order to carry out one-off mailshots. Spreadsheet data can be extracted using SQL-like syntax providing more control over the rows which are included. More output formats Inforama now allows OpenOffice documents to be merged with data and returned as OpenOffice documents which can be edited further. This merging doesn't require OpenOffice to be installed on the machine running the Inforama engine which means that documents can be generated this way on Inforama Enterprise without having to launch OpenOffice. Plug-in support Inforama 1.2 introduces some basic plug-in development architecture which allows custom datasources and user screens to be defined. This feature will be extended further with some industty specific plugins in future versions. Look out for the plug-in which allows documents to be generated from data in Salesforce. Visit the Inforama website at http://www.in4ama.org For a quick overview of how Inforama works have a look at the webcasts at http://in4ama.org/web/guest/documentation/webcasts
  2. Interesting. I plan on checking this out.
  3. Did a quick look a the screencasts. In our system, we document what things were "sent" and what the data was that was put in the form fields. I would need to figure out how to incorp this. I like how OpenOffice is used.
  4. Hi Mark, In Inforama Enterprise you have the option to save the generated documents into a number of document repositories. You can store the documents on the file system and each generated PDF will be stored along with an XML file describing what parameters were sent to the Inforama Engine. It will also save information about what email address(es) it was sent to or what printer was used. There is also in integration for Alfresco and Jackrabbit which will allow you to automatically store generated documents into these document management systems. Val
  5. Hi Mark,

    In Inforama Enterprise you have the option to save the generated documents into a number of document repositories.

    You can store the documents on the file system and each generated PDF will be stored along with an XML file describing what parameters were sent to the Inforama Engine. It will also save information about what email address(es) it was sent to or what printer was used.

    There is also in integration for Alfresco and Jackrabbit which will allow you to automatically store generated documents into these document management systems.

    Val
    For form documents, I only store the original document and the "Sent" documents are all the key/value pairs for the fields plus some metadata. Does Inforama have an API that can be called?
  6. Hi Mark, Inforama does have a full API and it was built with extensibility and scalability in mind. It's possible to hook into callback events during the document generation process. In these events you have access to datasets, parameters and generated documents so that custom logic and operations can be applied. Your approach of storing the original document with the key/value pairs is interesting but we have separate bindings files for PDF forms so that more complex bindings can be applied - for instance where you might want to carry out some arithmetic on a number of fields or parameters. I'm not sure if storing the key/values on their own would be sufficient to let you know just how the final document appears. Are you comparing this to an in-house solution? Val
  7. Val, The key/values are post processing. I have written this sort of thing for 4 applications. One was for a custom labeling app, one uses RTF files and 2 use PDF forms. Some of the fields are simple but most require logic. The labeling app allows the user to do some "coding" but for the others, the code is done by a developer. I could store the output files but that would greatly increase my storage. Really, the bigger issue is storing the "metadata" so the information can be used in queries and reports.
  8. OK Mark, I see what you mean. You're using the data which is populating the form fields to carry out analysis. I guess that should be pretty easy to do with a simple customization which would store the data in XML files or in a database. Val