8 Configuring Destinations for OracleAS Reports Services

8.1 Overview of Output Processing

Report output is controlled by the DESTYPE value that you specify at runtime, which, in turn, is determined by the destination output types you have registered in your server configuration file (server_name.conf) using the destination element. For more information, see Section A.3.29, "DESTYPE" and Section 3.2.1.7, "destination".

You do not need to register the following default destinations:

• Cache

• E-mail

• Printer

• File

You may need to register the following default destinations:

• OracleAS Portal: The entry for this destination is created by default in the server configuration file, but it is commented out. To start using this destination, you must uncomment the destination entry, and also provide appropriate property values (for example, the value for the portalUserid property).

• FTP and WebDAV: The entries for these destinations are created by default in the server configuration file, and are not commented out. Thus, they are registered and available by default. If you need to send the output to an FTP or WebDAV server that requires a proxy, you will need to edit the proxyinfo.xml file available in the default location (ORACLE_HOME\reports\conf), then uncomment the proxy property in the destination element and specify the complete path to the proxyinfo.xml file as the value. For example:

  <destination destype="ftp" class="oracle.reports.plugin.destination.ftp.DesFTP"> <property name="proxy" value="D:\\oracle\\reports\\conf\\proxyinfo.xml"/> </destination>

You can also define custom output types, such as fax, Oracle's Internet File System (iFS), or any new destination type you define using the OracleAS Reports Services Destinations API. This API enables you to define new destination types and build handlers to usher your reports to custom destinations.

The OracleAS Reports Services architecture standardizes the way output is generated and delivered. It takes responsibility for delivering report output to the appropriate destination (through the Reports Server), yet generates output independent of its destination (through the Oracle Reports engine). This provides a significant improvement in efficiency by allowing one run of a report to be used in a number of different ways. It also opens up the output processing architecture to allow for any number of destination types.

In the past, the Reports Runtime engine was totally responsible for delivering the output. Consequently, it had to know how to communicate with output destinations. This resulted in a tight coupling between the engine and the supported destinations.

OracleAS Reports Services eliminates this tight coupling and its attendant restrictions. The runtime engine now treats all destinations alike. It doesn't need to know the destination type for which the output is being produced. The server hands output off to destination handlers that prepare the material for delivery to their associated destination types. You can use predefined destination types (with predefined handlers) or create a handler for a custom destination type you intend to support. Almost any type of destination can be plugged into Oracle Reports.

Figure 8-1 illustrates the main components of the OracleAS Reports Services output processing architecture.

Figure 8-1 Main components of destination/distribution architecture

Description of "Figure 8-1 Main components of destination/distribution architecture"

Requests flow through the output processing architecture in the following sequence:

1. The user submits a request from a client or browser to the Reports Server.

2. The server passes it along to the runtime engine.

3. The runtime engine creates/processes the destination objects (which include file lists for specific destinations as well as any properties related to those destinations) and the report output; the runtime engine sends the destination objects to the Reports Server and the report output to cache.

4. The Reports Server sends the destination objects to the Reports Server's destination component.

5. The destination component of the Reports Server fetches the report output from cache.

6. The Reports Server destination component sends the report and the destination objects (which specify how the destination device should handle the output) to the appropriate destination handler.

8.2 Registering Destination Types with the Server

Before OracleAS Reports Services can send a report to a particular destination type, the type must be a default type (printer, e-mail, cache, or file) or a type registered in the server's configuration file, server_name.conf. The configuration file contains a destination element for registering destination types that are valid for your reports. You can register anywhere from zero to any number of destination types.

Registering a destination type with the server involves:

• Setting Up a Destination Section in the Server Configuration File

• Entering Valid Values for a Destination

These tasks are described in the following sections.

<destination destype="output_type_1" class="java_class_1">
<property name="valid_destype_property" value="valid_value"/>
<property name="valid_destype_property" value="valid_value"/>
</destination>
<destination destype="output_type_2" class="java_class_2">
<property name="valid_destype_property" value="valid_value"/>
</destination>

<property name="portalUserid" value="portal_id/portal_password@portal_schema"
confidential="yes" encrypted="no"/>

<destination destype="oraclePortal" class="oracle.reports.server.DesOraclePortal">
  <property name="portalUserid" value="<the_username_password_tnsname_for_logon_to_portal>"
     encrypted="yes"/>
</destination>