The original name of BI Publisher was XML Publisher. The original name emphasized the basis of the tool--XML. At its debut, it was one of the only, if not the only tool that leveraged the power of the XML open standard to retain its core metadata. This is still true, even though the name of the tool has changed. XML is ubiquitous throughout the Web. Just about all major report vendors and web technologies can consume, parse, or otherwise leverage XML to produce dynamic information. A good example of this would be the Portable Document Format (PDF) standard, with which BI Publisher interacts seamlessly.
The basic development functionality of BI Publisher is straightforward and provides excellent results. However, the greatest flexibility of developing with BI Publisher comes when knowledge about advanced XML formatting can be leveraged. In BI Publisher's core all details, datasets, templates, and other data are stored as XML. These XML files can be manipulated manually or via the GUI interface. For basic efforts, manual editing of the XML is likely not required. However, when attempting novel solutions and advanced customizations, manual editing of the XML is preferred. Ramping up on your XML knowledge is a great idea in general and it is highly recommended when engaging with BI Publisher development.
Yes, BI Publisher is now published reporting.
Reports created in BI Publisher should be called a published report. This is to differentiate from ad-hoc reports in the rest of the OBIEE system, which we have discussed, for example, analyses. Keep in mind that Oracle BI cannot create an ad-hoc analysis request with the same pixel-perfect perfection that a published report from BI Publisher can. So the distinction in nomenclature is warranted from both a technical and functional perspective.
The act of creating an analysis request, dashboard, dashboard prompt, filter, or condition is referred to as interactive reporting. You can see this description, Analysis and Interactive Reporting, from the Oracle BI 12c portal Home page under the Create... section. You can also see a link to Published Reporting (what we are concerned with in this chapter) in the same section in the following screenshot:
Ultimately, the gist is that there is some overlap. This is largely due to Oracle integrating multiple standalone products into its reporting suite. The overlap will drive the need to clarify on terms and nomenclature. There is no doubt that nomenclature will become more refined as the Oracle BI roadmap goes forward. For now, it can't be emphasized enough that every organization should ensure that consistent nomenclature and terminology is used, so that confusion is mitigated.
When to use Oracle BI instead of Oracle BI Publisher is a common question. The question has become more frequent since the integration of Oracle BI Publisher inside the Oracle BI Enterprise Edition platform. Unfortunately, the answer to the question is itself a question--what are the primary reporting requirements? The reason for the rebuttal question is due to the subtle differences in the tools. Oracle BI and Oracle BI Publisher have their individual strengths and weaknesses. A few follow-up questions like these might follow:
- Will the reports be delivered externally to clients for formal presentation?
- Do these reports need to be printed in a certain format consistently?
- Do reports need to be available in both online and print format?
- Will the documents need to be sent automatically to a printer or fax?
- Will reports get built dynamically or programmatically via code?
- Can the report developers upload their own data sources?
- Do watermarks need to be added to reports?
If the answer is yes to any of these questions, that places a check in the column for Oracle BI Publisher. Clearly more questions along these lines should be asked with the purpose of exposing the pros and cons of each. Operational reporting is another scenario that gets brought into the conversation when determining which tool to leverage. Both tools can be used for Operational Data Store (ODS) type reporting requirements, but with Oracle BI Publisher's Interactive Viewer, another check just may go into the column for BI Publisher. OBIEE can also handle this, but with more of a top-down approach and enterprise deployment cycle.
Ultimately, OBIEE contains analysis and interactive reporting tools for building ad-hoc queries, dashboards, and distributed reporting architecture. Oracle BI Publisher reports can be displayed in Oracle BI portal dashboards and can also be distributed via the Oracle BI platform's distributed reporting and delivery architecture, or via its own standalone tools and configuration. With such flexibility and each having certain unique capabilities, it is not a surprise that these two tools are now seamlessly integrated into the Oracle BI 12c software product suite.
Following are the new features and enhancement.
The rewrite that took place on the Oracle BI 12c platform also applies to Oracle BI Publisher 12c. The clean Web 2.0 interface makes the user experience (UX) working with BI Publisher much more intuitive. In addition to new graphics, layout, and features, the biggest enhancement that relates to the look and feel is the improved ability to create the pixel-perfect template and reports within the web-based interface. There are many changes, such as custom fonts, which enable you to present your reports in a more attractive manner. This has built in the massive step forward from the previous 11g version.
Oracle, in line with industry trends, has placed a lot of emphasis on the cloud. In 12c, as well as all of the other normal destinations for a report, you can deliver reports to Oracle's cloud storage, ready for others to access.
12c also allows the enabling of encryption so that files uploaded to the cloud are secure. You can also enable the use of PGP keys very easily, so only authorized persons can view your reports.
As we have mentioned, the integration between BI Publisher and OBIEE can be confusing. Aside from basic terminology, it is important to note the nuances that exist because of this integration. That is to say, many people assume that basic items such as data sources are one and the same for BI Publisher as they are for Oracle BI, which is false. This section highlights a few basic terms that will be used throughout this chapter when stepping through the development of reports. It will also highlight when to go where for what as it relates to basic management of BI Publisher and the integration with Oracle BI 12c.
Several components must be configured before adding a table, dropdown, or otherwise building a report in BI Publisher. Here are the basic items that will comprise most reports that you will develop.
BI Publisher must use one or more data sources and/or subsets of data datasets that can be used in one or more reports. The structure in which these items are defined is referred to as a data model. It also provides the structure and relationship between datasets. Both complex datasets and simple data sets (such as a list of values, parameters, and other metadata) are configured here.
A data model usually has the ability to configure one or more data sets, event triggers, flexfields, list of values, parameters, and bursting property options. A BI Publisher data model is not an RPD. It cannot be leveraged as a source for creating ad-hoc analysis requests in Oracle BI presentation services.
In order for data to be presented as desired in a report, there first must be a design. A layout consists of a template file and a set of properties for rendering the template file. Legacy template design tools such as MS Word and MS Excel still exist. However, with Oracle BI 12c, the template design can dynamically take place in the BI Publisher GUI for true Web 2.0 functionality.
BI Publisher allows for both catalog translation and template translation. Both are achieved via an export, translate, and import process, and by leveraging the open standard XML Localization Interchange File Format (XLIFF) to handle the structuring of this process. The template translation is ultimately a way to translate just the final report presented by metadata. A catalog translation can potentially translate all objects in the BI Publisher catalog. Both translation types can handle multiple local code translations.