Oracle XML Publisher / BI Publisher

Editor's Notes

• #8: BI Publisher Concept BI Publisher breaks the three components apart and treats them separately at design time At runtime the three are brought back together by BI Publisher to generate the final formatted, translated output Results: More flexibility than the current model A single data definition can support multiple layouts Multiple translations can be applied at runtime to generate translated output Leads to a reduction in maintenance costs for all concerned
• #11: BI Publisher is made up of the four modules: Data: Data engines are registered with the data handler Can be any XML source or any engine that generates XML such as Oracle Reports Template: Layout templates to be used for the final output are stored and managed in the Template Manager Templates are created using familiar desktop tools such as MS Word, MS Excel or Adobe Acrobat Translation: Manages the translation that is required at runtime Delivery Server: Takes the output document and delivers it to the printer, email, and etc
• #12: Oracle BI Publisher has been built on open standard technologies. Pure Java – the product is a pure java solution Pluggable data in XML – the data source is XML Output formats in PDF, RTF, HTML, EXCEL – standard output formats BI Publisher technology is based on an implementation of the W3C XSL-FO standard to transform XML data into an FO object; this contains both data and formatting information that can then be further transformed to an output format such as PDF. Added to the implementation are features to improve performance, increase security, support MLS and extensions to the FO standard to support more complex reporting objects. WebDAV  Web Distribution, Authoring, and Versioning
• #13: Performance and Scalability The XSL-FO engine that has been developed is not only robust but also fast, this is vital. XML data by its nature generates large objects or files and these can cause serious memory issues during processing. BI Publisher has a stream based implementation that reduces this memory footprint allowing large XML input files to be processed.
• #26: No single system can currently do all this, you need to invest in 3rd party software and often a dedicated server to achieve this. This leads to an increase in costs and very complex systems. Of course if you have all these extra servers and software on your system you will need skilled engineers to maintain them. Further cost to you and extremely labor intensive.
• #28: To summarize, all parties win from report developers to the end user when using Oracle BI Publisher. End User – The end user is presented with a richer report offering from the e-Business Suite. Reports in multiple formats with multiple delivery options are now available directly from the applications suite; the language and locale options have been improved and this all comes through a consistent user interface. Business Consultant – traditionally the business consultant would gather the business requirements and then describe the report that was required in a document and pass this to the IT consultant for implementation. The business consultant now has a set of familiar desktop applications that can be used to design the report format itself, this will ensure the report will meet all the business requirements that are in scope and it will look exactly as the consultant has designed it. IT Consultant – the IT consultant will now receive a document that is the actual report format as designed by the business consultant. The time to develop, deploy and test will be greatly reduced; the cost of on going maintenance will also be reduced. Development – are now able to focus on generating XML data from the e-Business Suite schema to satisfy multiple requirements, now development is free from ‘1 data definition : 1 report layout’ there is a move toward generating larger data engines that can satisfy a larger requirement set. This will provide end users with far greater choice and control over the content of the reports they want to see from the suite.
• #29: Classic reporting approaches combine the data definition, the layout format and translation in a single source. This leads to large numbers of report files; a single data definition (query) could support several layouts but due to the nature of the report definition file the user has to create and maintain a separate report for each combination. Now add the required translation and the number of report definitions has become huge. Typically the tools used to create these reports are powerful but complex and require a high level of technical training to be used effectively. If a company takes a development delivered report and has to customize it the only option they have is to take a copy of that report definition, make the changes they require and then use it. If development upgrade the base report then any changes will need to be propagated through to the customized report. These three factors lead to an increase in maintenance and customization costs and an extremely difficult and complex upgrade.
• #30: The classic approach to reporting is to combine all of the elements of a report into a single entity: Data definition Layout Translation Results: Report file is very unwieldy and causes problems due to its inflexibility If a report is required that has even a minor layout change a new report file must be created to support the new requirement even thou the data definition is exactly the same If another version of a report is required at runtime in a different language then a new report file must be created to support the new language This model leads to more time and expense in maintaining report files
• #31: Oracle BI Publisher simplifies the whole customization process and combines this with reducing costs. The traditional approach of combining the data definition, format and translation in a single entity is thrown out in favor of breaking the three components apart. With the three pieces now separated the whole model is simplified. Data Definition - The data definition exists as a single entity, an Oracle Report, PL/SQL package, Service Bean, etc but it now just becomes an ‘XML Data Engine’ that can service not only a reporting need but can fulfill other requirements e.g. B2B communication along with other reports. Report Templates – The technology behind BI Publisher is a W3C standard, XSL-FO. There are many XSL editors currently in the market that can be used to create report formats. BI Publisher also allows the user to create layouts using Microsoft Word, Microsoft Excel and Adobe Acrobat, these familiar desktop tools make report template design and much simpler proposition for users and can be designed comfortably by business analysts rather than an IT specialist. Translation – BI Publisher is able to extract the report boilerplate to an XLIFF format. These files can then be translated by 3rd party translation companies. At runtime the three components are brought together by BI Publisher to generate the required output.