This presentation was given by Manoj Turlapati (MavenWire) on the January 11, 2011 OTM SIG call. It covers our experiences moving from Oracle Reports (OTM v5.x) to Oracle's BI Publisher (OTM v6.x).

1. Migrating Oracle Reports to
BI Publisher
Tips and Tricks

2. Agenda
Format Template 3
Query Template 4
DB Packages 5
Summary 6

3. Format Template: Report Presentation
Format template defines the presentation of the data in the defined
layout format using the RTF template.
• Use the Report conversion tool to generate the RTF (BI Publisher format) report from the
RDF file (Oracle Reports format).
• Oracle reports can have conditional formatting, field display formats etc. The formatting
options are not migrated fully to RTF format. These need to be crosschecked manually.
• Report parameters need to be added manually to the RTF report format.
• Report totals are not converted using the conversion tool. These need to be added
manually to the RTF format.
• If report group functions like, report data model grouping or format layout grouping are
used to define grouping, these are not fully migrated to RTF. These potentially have to
tweaked manually. Grouping that is defined in the SQL is not impacted.

4. Query Template: The Data Layer
Query template defines the SQL that queries the data from the source
database and is formatted by the format template to display the report.
• The conversion tool generates the RTF file with ALL user parameters that are in RDF file.
Not all of them are not required. These need to be manually adjusted.
• The report SQL statement is not converted as it is defined in the original Oracle Report. For
each report, the new generated SQL query in the xml must need to be validated against the
one query in the original report.
• If any DB links or DB fields are used in the Oracle Reports data modal, those fields need to
be checked or revise the SQL statement.
• If any custom functions in the report (Lexical Parameters section), they are copied to the
DB package and are linked from XML. Some of the fields never have the data due to
invalid package calls. This requires the XML data element changes.
• Validate the XML format is as per OTM standard format.

5. DB Packages: The helper packages
There are numerous helper packages defined in the original report are
converted to DB packages. We noticed the following after conversion.
• Generates additional functions that are not required causing report compilation errors.
These packages need to be deleted.
• Generated DB packages have VPD set in multiple places. The redundant VPD calls need
to be removed.
• OTM user preferences are used to set the format of the fields in the report. After conversion
this doesn’t function well. User preferences need to be reviewed to confirm proper setting.
• The report parameters were displayed on the first page of the report. These parameters
need to be assigned to new parameters and passed to format template to display them in
the first page of the RTF report.
• Dynamic SQL generation was not as per the new OTM standards. The packages need to
be modified.
• Report parameter values were not passed to DB package correctly.

6. Summary
Based on the conversion projects that we have completed, here are a few
things to consider when doing the conversion projects…
• If the reports specifications and latest report RDF files are available it is prudent to
create the report from ground up instead of using the convert report utility due to
numerous issues listed above
• It was noticed that the new RTF reports take considerably longer to return the results
than the RDF reports due to non standardized conversion of the report SQL. Clear
specifications of the report will help in tuning the report SQL statements
• As with all the projects, testing is very crucial part of the conversion projects.

7. MavenWire NA
MavenWire EMEA
640 Freedom Business Ctr
21 St Thomas Str
3rd Flr
Bristol, UK BS1 6JS
King of Prussia, PA 19380
+44 1285 652 835
+1 866.343.4870
www.MavenWire.com