Switch from iReport to Docmosis?

Eric Bastholm, Java Developer

I am using iReport and JasperReports to meet my reporting needs. Why should I switch to using Docmosis?

To answer that question you first need to define what meeting your reporting needs actually means. Any technology you care to use from the most expensive all singing all dancing report generation tools to a simple text editor will eventually give you what you you want but at what cost? How long will it take? Who can do it? Do I need to tie up my developer's time or can I do it? How does this affect my deadline and cost? Stepping back and looking at the whole picture will reveal some enlightening insights.

Before looking at that big picture, though, let us tell you what Docmosis will offer:

• Microsoft Word or Open Office input and virtually any data source to produce Microsoft Word, Open Office or PDF output.
• True separation of presentation and data.
• Decrease development time of reports and reduce the workload on application developers by using existing documents for your report layout design.
• Allow the business to own the report layout by using existing documents, which the business can edit and maintain.
• Allow the business to post-edit report if Word or Open Office output is chosen.
• Developer is free to spend more time on application development.
• Save time. Save money.

If you are already using a reporting framework or tool in your organization, such as iReport-Jasper, you may be thinking that the report building exercise, especially for complicated formatted reports,  is taking too long and costing too much. You may also be frustrated with the quality or format of the output. These are some of the problems that you may be facing. Feel free to check these off:

• Our report implementation is making us to go over time and budget.
• Our output report layout does not look exactly like our requirement examples.
• The customer is very particular about how their documents look.
• While my developers spend time on report layout they aren't fixing bugs in the application.
• My developers say they spend too much time altering layout and it is tedious and annoying.
• My developers are highly skilled sought after professionals and they cost more than I do!
• Our real requirement is to have Microsoft Word output so we can post-edit the report.
• The customer already has a heap of Word document templates which we wish we could use directly.
• We are using iReport because ... well ... because we always have (be honest).
• Our organization recently changed its logo and now I have to get a developer to spend an age changing our 47 reports!

Meeting your reporting needs, or indeed meeting any requirement, means satisfying the need within a certain time and with the minimum of effort. Only then are you achieving the goal with optimal cost. Reporting functionality, usually left at the end of the project, can be an expensive and time consuming exercise utilizing expensive resources at a time when the project is likely to be under some deadline and budget pressure. The last thing you want is your developers slaving over the finer points of a report layout (how do I get those table columns to line up?) when they should be helping with the system integration, testing and bug fixing.

We argue here that Docmosis allows you, your developers and your customers, together, to satisfy your enterprise reporting requirements by apportioning the development effort in such a way as to have different tasks performed by specialists; primarily in report layout and data specification, to produce a better result quicker and more reliably than is possible with iReport.

The advantage that Docmosis has over the iReport/Jasper solution is in the degree of coupling of the specification of the data for the report and the specification of the report layout or the receptacle for the data. A tight coupling of these aspects of report design, as is found in iReport, means that the whole task will need to be performed by your expensive developer resources. While a more relaxed coupling of these aspects, as in Docmosis, means that you can put the right person on the right job; the developer to design the mechanism to obtain and manipulate the data, and business analyst, or even the customer to provide the layout in the form of a Word document with standard merge field markup.

Often, an existing marked up document can be used without changing it at all. So, the work involved in the report layout task can be quite minimal.

To appreciate the difference between iReport and Docmosis as report development environments let's look at a typical workflow in iReport first. In iReport the data and the layout are specified in the same place: within the iReport tool, meaning it is tightly coupled. The iReport environment is definitely the domain of the developer. It is not a tool that a non-developer member of your team is able to use. It is powerful and flexible, but this makes it difficult for non-technical people to do any of the non-programming tasks of report design like the report layout. The report is really like an object hierarchy and the specification of it is more like a graphical programming exercise which requires a technical (ok, geeky) mind to do it well. This is especially the case for reports that are complicated and have nested or repeating sections. Another issue is that the two tasks cannot be separated as they are developed within the same file resource. The developer cannot construct the query and define the reports fields, variables and data transformations while someone else does the fiddly layout bits at the same time.

When working with iReport the developer will generally perform the following steps: first, a query is written to extract data from some data source which must be configured within the iReport environment. The query accepts parameters and specifies a number of fields which constitutes the data for the report. Now, a report layout is designed within the wisywig iReport layout editor to produce a template that meets the customer's layout requirement. Usually, this requirement will be in the form of an actual example document or perhaps a template. Getting this layout right can be quite difficult to do if there is an existing format which needs to be copied, especially if it is complicated with lots of tables with repeating rows, or nested or multiple sections. During this process it may be necessary for the developer to derive a number of variables from the parameters and/or fields and maybe specify some data translations or conditional rendering. This is done by developing expressions, which are essentially written in Java with a sort of markup. The developer will now go through what is very similar to a edit, build, test software engineering cycle, albeit a tightly wound, rapid cycle, to tweak the report data, associated expressions and its layout until the desired result is achieved. For complicated reports this is the bit where the developer is most likely to appear stressed. The developer will now integrate the resulting JasperReport definition into their application.

Even with this brief description of the process it is evident that only a developer would be able to use this process for report development and, apart from the provision of an example report to copy from, the business analyst or customer can do nothing except comment on the results. Also, in my experience, the number of iterations through the cycle described can be large.

It would better if the developer can concentrate on the data aspects of the report and the business analyst can concentrate on what concerns them the most, which is the layout and formatting of the report. Now let's contrast the same workflow in Docmosis with a business analyst performing the role of report designer. In Docmosis the data is defined outside of the report rendering system and delivered to it in one or more of a set of general formats or data providers familiar to developers while the report layout is defined within a Word document. The data set specification is done in Java (where developers feel at home) via one of several means, but for this analysis let's say it is coming from a database query, and because the report format is specified in Word, your business analyst will feel comfortable fulfilling that role. As an added advantage both these activities can occur at the same time because different file resources and different environments are used. The developer can write and test the data access and data transformations using their favourite application development environment and, of course the report designer can use their beloved Word (or OpenOffice) application.

Before the developer and the business analyst go off and do their separate tasks, they meet and decide on the mapping between the data and the merge fields in the template Word document. They discuss what fields make up the report, which of those will be repeatable, if any, making rows in a table, and so on. Much of this may already be done if the original template document is a dynamic document with existing merge fields in it. Once the mapping has been decided on, the developer can then go off and produce the database query and code to create the dataset and the business analyst can write the document template, both which will be input to the Docmosis renderer at runtime. The developer will now integrate the report into the application without the iterating development cycle that iReport has.

Two things to note here are that these two tasks can be performed concurrently and the right tool is used for each job. Both of these things make it much quicker to implement and the use of Word for the report layout makes the output more reliably reflect the desired result. There is no layout problems above the normal stuff that Word users are already familiar with and there is no awkward expression building for controlling data format and rendering as there is in iReport. The developer does what they do best - code and interface to the database; and the business analyst or customer does what they do best - specify their business need. Once integration is complete the business analyst can tweak and edit the report format as much as they like while the developer goes back to fixing bugs in the application or working on version 2.

This process also allows the developer to use the same query specifications that they may have already defined for use in their application. iReport requires that you provide the query to it marked up with placeholders for the parameters. This generally creates a maintenance issue if the query definition changes as the same change often has to be made in two places, the application and the report.

In conclusion Docmosis offers the following benefits when developing reports:

• Separation of presentation and data.
• Developer does data, business does layout.
  
• Decrease development time of reports.
• Use of existing tools; Java environment and OpenOffice or Microsoft Word.
• Use the right tool for the job; Java for data extraction and manipulation; OpenOffice or Microsoft Word for report layout. Better result.
• Use existing documents for your report layout design; no need to redo the whole thing and hope it looks the same.
• Get the business to own their reports.
• Business can change the format and layout of their reports without a developer.
• Business can post-edit report if Word output is chosen.
  
• Developer is free to work on the application.
• Developer is free to work on the application.
• ... and did I mention that the developer is free to work on the application.