Practical tips for your relaxed migration from Oracle Reports to JasperReports

What do you expect from a successful migration?

After all, it’s all about speed, quality, security and efficiency. That’s why in all our migration projects we focus on reducing complexities, safeguarding investments made, and high-performance target technologies.

Technical background:

Before starting a migration from Oracle Reports to Jasper Reports, it is advisable to get an overview of the expected tasks.We have managed projects with more than 1000 Reports in migration. It is not possible to know every Report with all its specifics. A review of such a large number of reports is already a big challenge, let alone the question of how to create the documentation.

With our approach we make it possible to reduce the complexity of the project by the following measures:

1. By loading all Reports into our ADC (Application Data Cube), all information from the „select of data from the database“, „functions for formulas and formats“, to the „position of elements in the layout“ are available for automatic documentation.
2. We compare Reports based on their structure, data access and implementation and identify potential identical Reports. Best example: In Oracle Reports, it is difficult to impossible to dynamically hide fields and use the freed space for better alignment of the remaining columns. Therefore, the unpleasant workaround in Reports was to duplicate modules and make only the layout changes that were dynamically impossible. Jasper Reports provides a much larger solution space for such tasks, allowing Reports to be harmonized again.
3. Documentation at the touch of a button.

For a documentation of the data model and a representation of the dependencies of formulas, placeholders, format triggers, group filters, etc., a click of a button is sufficient. By checking the dependencies, it also becomes clear quite quickly which legacy data is still present in the Report and can therefore be deleted before a migration.

4. Details in ExcelEach Report receives detailed individual documentation with the identified requirements based on an Excel document. Various tabs document the components of the report in such a way that a Jasper developer does not have to deal with the pitfalls of Oracle Reports to see what requirements the Report must meet.
5. Automated testing
   At the latest after the first transfer of Oracle Reports to Jasper Reports, the question arises how it can be tested efficiently. Oracle Reports may have dozens of parameters that lead to different representations of the final output. Running all variants over and over again is very time consuming and uninspiring. For this purpose we provide a unit test for Oracle Reports and Jasper Reports. After entering the different scenarios once, they can be run through automatically again and again.

Technical background:

Legacy applications are often subject to a deficit of technical and business documentation. This also affects the area of requirements documentation. While in the early days of development, requirements and/or specifications were used, the process may have changed over the last few years to an agile process with descriptive user stories in product backlogs.

Thus, at this point in time, it is difficult to find a source that describes what requirements the application should fulfill. With the runtime of common legacy applications, it is then also difficult to find those in the circle of key users or lines-of-business leaders who still have an up-to-date and at the same time complete overview of the existing requirements. Much of the application documentation is also not up to date, or if it is, then it is not so finely specified that it would suffice for a new development.

The only truth is in the code and how it is currently used by the users.

Since countless LOCs can only be read by developers and retroactively converted into a specification with great difficulty, a systematic analysis of the legacy application based on syntactic parsers and abstraction in the representation is a good way to make existing and used requirements visible without errors.

Technical background:

Usually, the timing of a migration is a good opportunity to think about general improvements in an application. True to the motto: „If I have to touch all the reports now anyway, …“. Because often, in normal everyday development, people shy away from the effort because it is rarely in proportion to the added value.

In addition to the classic situations with Oracle reports, that no longer needed objects, which were „commented out“ rather than deleted, can now finally disappear from the code and the layout, there are also improvements that are immediately visible to the „reader“ of the report.
Typically, there are thousands of date and number fields in a report landscape that have been given different format masks over the years and developers. But even with the choice of fonts, font sizes, page margins, and even uniform headers and footers, there is rarely a harmonious look across all reports.

With the Reports2Jasper Modeler, it is possible to get an error-free overview of the different variants and their usage in a matter of seconds and to implement uniform specifications for the newly generated reports.
.
But behind the output, improvements in refactoring can also enable easier maintenance and further development in the future. The biggest starting point here is the extraction of data logic from the sometimes complex select statements and functions of the reports into database packages, table-based functions or views.

Last but not least, this ensures that the same data preparation can also be guaranteed for other tools up to REST services.

If you want more practical tips and best practices, sign up for our free live webinar “Your way from Oracle Reports 2 JasperReports” on March, 9 at 10 a.m. (EST). Feel free to ask your individual questions and issues in advance, which will be discussed at the end of the event.