Oracle Application Server Reports Services Publishing Reports to the Web 10g (9.0.4) Part Number B10314-01 |
|
This chapter describes how to use OracleAS Portal to deploy your Oracle Application Server Reports Services reports. It includes the following sections:
Before you deploy reports, both OracleAS Portal and Oracle Application Server Reports Services must be installed and configured.
See also:
The following resources for further information:
|
If you use the security features in OracleAS Portal to control access to your reports, you must register all of your Reports users in the Oracle Internet Directory (OID) and assign security privileges to all of them through OracleAS Portal.
In OracleAS Portal, security privileges can be granted to individual users and to named groups of users. Named groups are useful for streamlining the process of granting access privileges. You can assign a set of access privileges to a named group, and grant the entire set of privileges to an individual simply by adding that person to the group.
Note:
When you use features like OracleAS Portal Security, Portal Destination, and Job Status Repository, the JDBC database connections made by Oracle Application Server Reports Services may override the initial |
The next sections provide overview information on how to create users and groups in OracleAS Portal. They include:
When you install OracleAS Portal, Reports-related groups are created for you automatically. These include the following groups:
You need to assign appropriate privileges to these groups to enable group members to perform any desired functions on reports through OracleAS Portal. For example, for each report object that you want members of a group (e.g., RW_BASIC_USER) to be able to run, you have to grant the Execute privilege to that group from the Access tab of the report object. Similarly, if you want members of a group (e.g., RW_ADMINISTRATOR) to be able manage Reports Servers, printers, and reports, you have to grant the Manage privilege to that group from the Access tab of those objects.
While you can assign object privileges to individual users, we recommend that every person who will access your reports belong to one of these groups or a group that you create yourself. If users try to run reports without being a member of one of these groups, by default, they are assigned the privileges of a basic user.
Should the security check fail, the users in RW_BASIC_USER see less detailed error messages than the users in other Oracle Reports groups, such as:
Security Check Error
Typically, you will want to assign this group minimal privileges. For example, you probably will want to give RW_BASIC_USER the privilege to execute reports and no more.
In addition to the privileges of the RW_BASIC_USER group, the RW_POWER_USER group sees error messages that are more detailed than those displayed to basic users. For example, if they are not permitted to run to HTML, but they try anyway, they might get the message:
Cannot run report to HTML
This is more detailed than the message an RW_BASIC_USER would receive for the same error.
In addition to the privileges of the RW_POWER_USER groups, the RW_DEVELOPER group can run Web commands, such as SHOWENV and SHOWMAP, which show the system environment.
Typically, you would assign privileges to this group needed by a developer who is testing reports. Depending upon your installation, you might even assign them limited administrative privileges.
In addition to the privileges of RW_DEVELOPER, these users also have access to the administrator's functionality in the Oracle Reports Queue Manager, which means they can manage the server queue, including rescheduling, deleting, reordering jobs in the server, and shutting down a server. RW_ADMINISTRATOR also has the privilege to run Web commands through rwservlet
.
Typically, you will want to assign to this group some (but probably not all) of the same privileges assigned to the PORTAL_ADMINISTRATORS group.
OracleAS Portal uses the Delegated Administration Service (DAS) interface to the Oracle Internet Directory (OID) to register users for access to Portal. You can enter the DAS interface through Portal to create new users. The creation of new users and groups is discussed in the Oracle Application Server Portal Configuration Guide available on the Oracle Application Server documentation CD.
When you create groups, you need to assign appropriate privileges to them to enable group members to perform any desired functions on reports through OracleAS Portal. For example, for each report object that you want members of a group (e.g., RW_BASIC_USER) to be able to run, you have to grant the Execute privilege to that group from the Access tab of the report object. Similarly, if you want members of a group (e.g., RW_ADMINISTRATOR) to be able manage Reports Servers, printers, calendars, and reports, you have to grant the Manage privilege to that group from the Access tab of those objects.
Ideally, you should provide a user with the necessary privileges on objects by assigning them to a group that has appropriate privileges for their role. For example, if you are creating a user who needs to be able to run but not manage reports, you could assign her to RW_BASIC_USER. If need be, you may assign object privileges to individual users (e.g., JSMITH) rather than groups, but this approach is more difficult and time consuming to manage.
Before you begin, you must have a sufficient level of privileges in OracleAS Portal to access the portlets and complete the tasks required for setting access controls. In order to manage reports in OracleAS Portal, you must belong to both the PORTAL_ADMINISTRATORS and RW_ADMINISTRATOR groups. If you only belong to RW_ADMINISTRATOR, you will encounter errors when you attempt to create report objects.
For more information about joining privilege groups in OracleAS Portal, refer to the Oracle Application Server Portal Configuration Guide.
This section outlines the necessary steps to go about:
Defining availability calendars is an optional step that allows you to further restrict access to reports, servers, and printers by specifying when they can and cannot be accessed. Availability calendars are not necessary if the reports, the Reports Servers, and printers are always available for processing.
This section provides information on:
You can associate only one availability calendar with a report, a Reports Server, or a printer. If your production environment requires more than one availability rule, then you can combine availability calendars.
A simple availability calendar defines a single availability rule (for example, Sunday through Saturday from 12:00 a.m. to 10:00 p.m.).
To create a simple availability calendar:
Under Duration, specify the length of time that comprises a unit of duration (or duration period). For example, if you plan to set this calendar up to allow report access from 9:00 AM to 5:00 PM on a given day, then both Start and End would be the same month, day, and year, but the hour and minute setting for Start would be 9:00 AM and for End would be 5:00 PM. In this example, the duration of availability of a report on a given day is from 9:00 AM to 5:00 PM.
Under Repeat, specify how frequently the duration period is repeated:
The resulting page summarizes your settings for this calendar. On this page, you can edit your settings, get detailed information about the calendar, or delete it.
You can combine this calendar with other calendars or apply it "as is" to registered Oracle Application Server Reports Services components.
A combined availability calendar combines two or more availability calendars into a single availability calendar. This is useful when you want to set up an availability period, then exclude specific days, such as holidays, from that period.
When you combine calendars, you can indicate that all the days on one of them be excluded from all the days on the other. For example, one calendar could describe availability Monday through Friday; another could describe availability only on Wednesday. You could combine these, excluding the Wednesday calendar, so that the combined calendar describes availability Monday, Tuesday, Thursday, Friday.
Conceivably, you could create a simple calendar that covers the weekdays of an entire year, then multiple additional simple calendars, where one excludes New Years, another excludes a second holiday, another excludes a third, and so on. You could combine all these calendars, excluding all the holiday calendars, so that components were available only on the days your company is open for business, between certain times of day, throughout the year.
To combine availability calendars:
This page lists the availability calendars that have been defined for the same Portal DB Provider under which you are creating this combined availability calendar.
These are the calendars with dates on which you wish to withdraw availability.
If your exclusion isn't showing up, select a different view. For example, instead of the monthly view, select the weekly.
If you want to change the combination, close the calendar and click the Previous button one or more times to return to the desired page.
The resulting page summarizes your settings for this calendar. On this page, you can edit your settings, get detailed information about the calendar, or delete it.
You can combine this calendar with other calendars or apply it "as is" to registered Oracle Application Server Reports Services components.
It is not required that you register a printer within the security framework of OracleAS Portal. You can run a report on any printer as long as it is available to the Reports Server. However, you might want to confine OracleAS Portal users to a subset of those printers, constrain the use of a printer for certain periods of time, or identify a particular printer to be used for printing output of certain reports.
Printer registration with OracleAS Portal is meaningful for reports that you run through OracleAS Portal as well as those you run through a stand-alone URL.
Once printers are registered within OracleAS Portal, you can associate them with a Reports Server. Many printers can be registered. However, only printers associated with particular Reports Servers are available to print when you register a report with OracleAS Portal and choose those Reports Servers.
You can choose to restrict even further the registered subset of printers that a registered report can be sent to. For example, an Reports Server might be connected to the printer in the office of the CEO, but its selection should not be available to employees running the general ledger report, unless it is the CEO who is running the report. A subset of printers can be listed to the OracleAS Portal user running a report request to select where output should be sent.
Property | Sample Value |
---|---|
Name (internal name) |
|
Display Name |
|
Portal DB Provider |
|
OS Printer Name |
|
Availability Calendar |
|
To register a printer:
UNIX: printer_name Windows: \\printer_server\printer_name (for a remote printer) printer_name (for a local printer)
This printer must be available to the Reports Server.
Creating an Availability Calendar
For more information on how to create an Availability Calendar.
See Also:
The resulting page summarizes your settings for this printer. On this page, you can edit your settings, get detailed registration information about the printer, or delete it altogether.
You have completed registering a printer with OracleAS Portal. This registration is meaningful for reports that are run through OracleAS Portal as well as those run outside of OracleAS Portal.
Before you can define access controls for the Reports Server, you must register your server within OracleAS Portal. Registration provides OracleAS Portal with the information it needs to identify and locate all available Reports Servers. This becomes particularly important when you register individual reports; during this process you are required to choose from a list of Reports Servers, and servers must be registered to appear on this list.
This section describes how to register Reports Servers in OracleAS Portal.
To register a Reports Server:
rwserver -install
repservername
or rwserver server=
repservername
.
http://your_web_server.domain:port/
For example:
http://myias.mycomp.com:7779/
http://your_web_server.domain:port/virtual_path_to_rwservlet/rwservlet
See Also:
Chapter 3, "Configuring OracleAS Reports Services" For more information on specifying the virtual path. |
For example:
http://myias.mycomp.com:7778/reports/rwservlet
Leave this box unchecked if you want this Reports Server to accept any report definition file, including those not registered in OracleAS Portal, as long as the user who submits the report request has access privileges to this Reports Server.
Chapter 7, "Configuring Destinations for OracleAS Reports Services"
For more information on custom destination types.
See Also:
Creating an Availability Calendar
For more information on how to create an Availability Calendar.
See Also:
The resulting page summarizes your settings for this Reports Server. On this page, you can edit your settings, get detailed registration information about the Reports Server, or delete it altogether.
You have registered a Reports Server. Now you can register a report.
Registering a report is a required step that allows you to define who can run a report, when a report is available to run, which server(s) can be used to process report requests, how a report is delivered, and the printer(s) to which a report can be sent.
In addition to using registration to designate which users have access to a report, you can also specify, via a OracleAS Portal parameter form, how users are to interact with the report.
User parameters are created in Reports Builder at the time of designing the report. You can assign values to these parameters when you run the report in OracleAS Portal.
Registering a report within OracleAS Portal creates an OracleAS Portal component that can be deployed as a portlet through Portal. We recommend that you register only one instance of a report file in OracleAS Portal. If you define multiple OracleAS Portal report objects for one report, all are given security checks at runtime. If any of them fail the security check, then all fail, and the job will not run.
To register a report:
The report definition file can be an .rdf
, .jsp
, or .xml
file. If the path to this file is included in your REPORTS_PATH
environment variable, do not enter it here. If the path is not included in REPORTS_PATH
, include it here along with the filename. Do this for all report definition files except those you will run as stand-alone JSPs. For JSPs, you need to define the name as virtual_path
/reportname
.jsp
.
Use the availability calendar to limit the days and times this report can be run.
See Also:
Creating an Availability Calendar For more information on how to create an Availability Calendar. |
Use validation triggers to create conditional restrictions that cannot be defined on either the Required Parameters page or the Optional Parameters page. Validation triggers are PL/SQL functions.
The function that you specify as a validation trigger must return a boolean value (TRUE or FALSE). If the function returns TRUE, the job is run. If the function returns FALSE, an error message is displayed and the job is not run.
The resulting page summarizes your registration information and provides the opportunity to perform additional actions on your report.
See Also:
Publishing a Report in OracleAS Portal For more information on how to run your report from OracleAS Portal. |
Table 11-4 summarizes the options available on this page.
Option | Description |
---|---|
Run Report |
Click to run this report with the specified parameter values. |
Save Parameters |
Click to save the parameter value selections. |
Server |
Select the Oracle Reports Server that you want to receive this report request. Only the servers that you chose at the time of registering the Report are displayed in this list box. |
Printer |
Select the printer that you want to print your report output. Only the printers that you chose at the time of registering the report are displayed in this list box. |
Destype |
Select the destination type. Only the destination types that you chose at the time of registering the report are displayed in this list box. |
Desformat |
Select the destination format. Only the destination format that you chose at the time of registering the report are displayed in this list box. |
Desname |
Enter the name of the output file when |
SSOCONN |
Enter one or more SSO connection strings. Separate multiple strings with a comma (but no spaces). For more information about |
Visible to user |
Check each parameter that you want to make available in the runtime parameter form when users run this report request. If the box in not checked, then the parameter is not displayed to users. |
CGI/Servlet Command Key |
Optionally, enter the key from the |
Portlet Width |
Use this field to control the width of the portlet. You can enter the value as a percentage of the page (e.g., 90%) or in pixels (e.g, 700). If no value is specified, OracleAS Reports Services uses its default value (640 pixels wide). |
Portlet Height |
Use this field to control the height of the portlet. You can enter the value as a percentage of the page (e.g., 50%) or in pixels (e.g, 400). If no value is specified, OracleAS Reports Services uses its default value (320 pixels high). |
Additional User Parameters |
Use this field to enter additional user parameters. For example, you can use this field to enter the path and name of the distribution XML file that defines how this report should be distributed. Use the same syntax you would use to specify these values in a command line request or within the cgicmd.dat file. If you wish to enter multiple additional parameters, simply separate each entry with a space. For more information about the distribution XML file, see Chapter 15, "Creating Advanced Distributions". |
Use the Manage portlet page to perform actions on existing Oracle Portal portlets; for example, executing, editing, copying, dropping, or viewing information about the portlet.
The actions you can perform on the portlet depend on your privileges. Also, not all actions listed here are available for all portlets. The name of the portlet on which you can perform these actions appears in the upper left corner of the page.
Table 11-5 details the fields and descriptions listed in the Develop tab.
Table 11-6 details the fields and descriptions listed in the Manage tab.
Table 11-7, Table 11-8, Table 11-9, Table 11-10, Table 11-11, Table 11-12, and Table 11-13 details the fields and descriptions listed in the Access tab.
Field | Description |
---|---|
Clear Cache |
Clears the cached version of the data, so that the next data request will be filled from the database. |
|
![]() Copyright © 2003 Oracle Corporation. All Rights Reserved. |
|