It is often a question whether data should be
presented to the user by using a custom report in the Reporting framework, or
by using the specification print capabilities in GSM. There are advantages to
both options, including usability, but a large factor in determining which
approach to take will have to do with the complexities in retrieving the data.
In the end, Printing is a good option if the data is
already available in the out-of-the-box print models. If all the data is not
present, then retrieving the extra data can be challenging. Minor additions may
be acceptable. We recommend for larger changes, such as pulling in other specifications
or objects, should be performed as a custom report.
Printing
· Initiated
directly from a specification with no additional parameters. The intent is to
report on details of the viewed specification only. Customizations can be made
to the print layout by altering the XSL/XSL:FO. See the Oracle Agile
Product Lifecycle Management for Process Print Extensibility Guide for more
information.
· With
printing, data objects are mapped to XML through a model. If the resulting XML
does not contain all the data required, minor updates can be made to the model
as described in the Oracle Agile Product Lifecycle for Management for
Process Print Extensibility Guide. Updating the print models requires
significant knowledge of the underlying data objects and therefore is not
recommended to make significant changes or include data from related specifications.
· Print
Managers define the printing flow. The XSL/XSL:FO steps may be omitted by
defining a Print Manager that pipes the XML directly to BI Publisher. Print
Managers are configured in the PrintSettings.config file which contains a
sample configuration for piping the XML directly to BI Publisher.
· A BI
Publisher report template will need to be created to consume the XML. The
various output types (PDF, XLS, RTF, etc.) would be available based on the template
created.
Custom Reporting
· Initiated
from the Reporting module (RPT) and optionally from the specification through
contextual reporting. This framework provides the ability to report across the
entire database. The user can select filters and custom SQL is executed to
retrieve the desired results.
· Configure
report parameters that utilize available selection controls: EQT searches,
single and multi-select lists, dates, free text.
· Use the
CustomerReportExtensions.xml file to configure parameters and report links
directly to BI Publisher report templates. Parameter selections will be passed
to the report templates where direct SQL can be generated to produce the
dataset within BI Publisher. See the Oracle Agile Product Lifecycle
Management for Process Custom Report Configuration Guide included with the
Extensibility Pack for more information on configuring custom reports.
· Security
must be considered when designing custom reports. By creating direct SQL to
the database, the application’s built-in security is by-passed. Security must
be built-in to the SQL or control user’s access to each report through the
configurations.
|
Printing/Reporting skills matrix
|
|
Skills/Required knowledge
|
Printing
|
Reporting
|
|
|
XML
|
Y
|
|
|
|
XML Models
|
Y
|
|
|
|
C# for custom handlers
|
Y
|
|
|
|
PLM4P object model
|
Y
|
|
|
|
BI Publisher
|
Y
|
Y
|
|
|
PLM4P data schema
|
|
Y
|
|
|
SQL
|
|
Y
|
|
|
|
|
|
|
