report serveur

8/6/2019 Report Serveur

http://slidepdf.com/reader/full/report-serveur 1/23

Advanced Techniques for the Oracle Reports Server

An Oracle Technical White Paper

March 2000




March 2000

2

INTRODUCTION

The benefit of Internet Computing, that is universally accessible information, is also one of the

greatest causes of concern for those whose job it is to administer the web site. That is, the web site

must scale to meet the requirements of the increased user community and also ensure that only those

authorized to see the information can do so.

User satisfaction for a web site is determined not only by the information served, but also by the

speed at which it is delivered. If the site is unable to serve information in a timely manner due to

increased load, users are less likely to use the site. Therefore it is extremely important that the

underlying architecture scales to meet the user expectations.

In addition, it is often the case that user authorization is defined not only by the privileges on the data

itself (that is, database object level privilege) but also the functions performed on it. As access to a

web document is through the use of its Uniform Resource Locator (URL), knowledge of the URL

allows access to any unprotected document. To combat this, most web servers allow for the

securing of the directory in which the documents may be found but are unable to secure individual

files within that directory. The use of CGI executables to serve up dynamic pages has allowed

many organizations to personalize the users’ view of the available information. These complex CGI

coding techniques have not really addressed the issue of application-level security. Hence, it has been

difficult for most web sites or information Portals to implement much more than the most

rudimentary of security models.

This paper focuses on the security and scaleability issues faced by system administrators when

implementing a centralized reporting infrastructure. Specifically, it looks at the functionality available

within the Oracle Reports Server to address these issues, and indicates the tasks required to

implement it. It does not cover the design of the Reports Server and assumes a basic understanding

of the architecture and the methods required to implement it.

N ote: For further information on the Oracle Reports Server please refer to the white paper “E nterprise Reporting” available from http:/ / www.oracle.com.

FUNCTIONAL SECURITY

In it’s simplest form, an authorization scheme designed to enforce application level security (one

based on the right of the user to access the function as well as the data) should allow for the

definition of the following criteria:




March 2000

3

• Who has the appropriate privileges to access the defined function or object.

• What business functions and objects are available to be accessed.

• When may the defined function or object be accessed. That is, is the availability determined byeither organizational or procedural controls (e.g. only available during business hours or after the‘close of books’ in a financial period).

• How may the function be implemented by the user. That is, given the authorization to accessgiven function a user may only specify certain parameters to that function (e.g. may only specify

output formats or printers).

SECURE ORACLE REPORTS SERVER

By integration with the Oracle WebDB security model Oracle Reports is able control user access to

defined reports being run against the Oracle Reports Server. As a user makes a request for a given

report to be generated, Oracle Reports uses the information stored within WebDB to verify their

access rights to run the requested report at that time and on the requested server.

The security model of WebDB is tightly tied to that of the database itself. That is, the definition of

a user within the WebDB environment matches a schema within the Oracle RDBMS. The use of

roles allowing for the definition of both functional groups (e.g., DEVELOPER, CLERK) and a

hierarchical security structure. The Report itself is represented as a packaged procedure containing

the relevant information on how to run the report.

Once a user is defined within WebDB they may be included within the security framework of

Oracle Reports.

Though the creation of a user within WebDB results in the creation of a user within the Oracle

database it is not required that the report being executed connect to the database as that user. Oracle

Reports differentiates between an application user and the database user used to connect to the data

server (though they are often one and the same). The use of AUTHID (discussed later in this

document) allows the Site administrator to differentiate the application user from the database user.

N OTE : A pplication users are currently authenticated as a user defined within the database, futurereleases of W ebDB, however, will allow for the authentication of users in a number of different ways, from a lightweight authentication model to use of external sources, such as an L DA P server.




March 2000

4

In order to implement the Secure Reports Server it is first necessary to perform a number of steps

prior to the definition of the security model itself.

1. The definitions held within the WebDB repository which relate to the running of secured Oracle

Reports are an extension to the standard WebDB installation. As such, it is necessary to insert therequired object definitions and related menu structure into the Administration area of the WebDBapplication environment. This is achieved by running the supplied installation script

(%ORA CL E _H OME %\ Reports60\ Server\ Security\ RW W W V IN S) within the same schema that wasused to install WebDB itself. The script will create the appropriate Object definitions and menuentries as well as define the RW_BASIC_USER, RW_DEVELOPER, and

RW_ADMINISTRATOR roles.

N OTE : In order to define Reports access security via the Oracle Reports Security Wizardswithin Oracle W ebDB the user must be granted the RW _A DMIN ISTRA TOR role (otherwise

R eports Security Option will not appear as the user menu structure). In addition the user must

have “ BU IL D IN ” privileges to any schema that will own the Reports Pack aged Procedure or L ist of V alues used within a parameter form.

1. The Reports Server must know where to look in order to find access privilege information. That isthe server must be told the name of the database instance in which WebDB and the security

repository have been installed. It is necessary to:

1.1 Add an alias in the TNSNAMES.ORA file on the machine where the Reports Server is

located which points to the instance where WebDB is installed.

1.2 Add an entry SECURITYTNSNAME= ”<tnsname alias>” in the Reports Serverconfiguration file (e.g. RepServer.ora) which references the alias to the WebDB SID.

Once the SECURITYTNSNAME entry has been added to the server’s configuration file (and the

Reports Server restarted) access control will be enforced. Users who request a report run against

this server will be challenged and required to identify themselves for subsequent authentication.

Once the WebDB integration has been installed and the Report Server started as a secure server it is

possible to define the required access security model. From the “Oracle Reports Security” page (linked

to the WebDB “A dminister” page), it is possible to define the objects which define the criteria of the

security model.




March 2000

5

Figure 1: Reports Security Administration

What:

As a given report may reside on more than one Reports Server the definition of a user’s access

privileges must go beyond the report itself to include the available hardware on which that report

may be executed/ output. For example, a given report resides on both the central Reports Server

and the one used by senior management. Even though a given user may have the right to run the

report, he/ she should be prevented from executing it on the management server. As such, the

Oracle Reports Security allows for the securing of a number of different objects relating to the

execution of a report.

Printer Access:

• What local or network printers are available.

• Who has the appropriate privileges to use a given printer.

• When is this printer available for printing reports.

Servers Access:




March 2000

6

• What Report Servers have been registered within the WebDB repository and hence are available

to accept job requests.

• What Printers are available on a given Reports Server.

• Who has the appropriate privileges to submit job requests to a given Reports Server.

• When is a given Reports Server available to accept job requests.

• What is the URL required to call a given server via the Web.

• Can a given Reports Server run any available report or only those registered with WebDB thathave secure access control.

Report Definition File Access:

• What Oracle Reports *.RDF, *.REP, or *.XML files have been registered for secure access.

• What is the name by which a given report will be known within the WebDB environment.

• Who has the appropriate privileges to run a given report.

• Which Reports Servers have a given report available.

• When is a given report available for execution.

When:

It is often the case that a user’s ability to access a report, server, or printer is determined by the point

in time the job was submitted to execute. With the universal access afforded by the web, the simple

physical security of not being able to access the appropriate hardware (PC, Printer etc.) outside of a

defined time period is removed, hence the need to define an availability window as part of the

report/ object definition becomes paramount. For example, it has been decided that a given report

may only be accessed during standard business hours. By applying an availability calendar which

defines standard business hours employees would not be able to log-in from home after hours and

access the report.

The secure Oracle Reports Server supports the ability to define availability calendars for either:

• The individual report.

• The Reports Server on which jobs may be executed.

• The printers to which the report output may be sent.




March 2000

7

In all cases, the availability calendar determines when the specific object is accessible for processing.

There are two different availability calendar types, simple and combined.

− Simple: An availability calendar based on a single rule (e.g., between 9:00am and5:00pm daily).

− Combined: A compound availability calendar determined from the addition of two or moresimple calendars. The definition of a combined calendar supports both the inclusion and

exclusion of the time periods specified within included simple calendars. That is, thecombined availability calendar may be defined as

Availability := (Sum of all included Calendars) - (Sum of all excluded Calendars)

For example, to define a standard business hours availability calendar, it would first be

necessary to create two simple calendars to be included/excluded as follows;

1. 9:00am - 5:00pm repeat every day. (Include)

2. Saturday/Sunday repeat every week. (Exclude)

The resultant availability calendar would only allow access during the period of 9am to 5pm,

Monday to Friday.

N ote: combined availability calendars can also include/ exclude other combined calendars. H ence it is possible to create complex calendar definitions from a hierarchy of both simple and complexcalendars.

Only one availability calendar can be applied to a given secured Reports Server object (i.e., report

definition, server or printer). Hence, if more complex time frames are required, it is necessary to

build a single combined calendar (through the addition or exclusions of simpler calendars), which

reflects the desired time period.




March 2000

8

“EveryDay”

Availability Calendar

“Week-Ends”

Availability Calendar

Rule: 9:00am to 5:00pm

Frequency: EverydayRule: 12:00am Saturday to

12:00am MondayFrequency: Ever y week

“Business Day” Calendar

þ ý

Include Exclude

How:

It is often important not only to specify which report a user may access (and when) but also how

that user may interact with the report. The secure Reports Server achieves this by restricting the

report request options (i.e. required and optional report parameters), which are exposed to a given

user at job submission. By specifying which parameters are exposed, the administrator can allow

different users or groups to apply different options to the same physical report definition file.

For example, a given report may limit not only the server and printers to which it may be run but

also the possible values for DESTYPE and DESFORMAT. In this case, the administrator wants to

restrict the report to Web viewing only, hence DESTYPE will be fixed at CACHE and the possible

options for DESFORMAT limited to HTML and HTMLCSS.

SINGLE SIGN-ON SUPPORT

Unless the username/ password is hard coded into the server side keymap file (or supplied as part of

the URL), any user accessing the Oracle Reports Server will be challenged to identify themselves for

authentication purposes. As the HTTP 1.0 protocol is stateless, that is, each call to the server is

effectively independent of all others, it would result in the user needing to authenticate themselves for

each report request.




March 2000

9

To solve this issue, and to allow a user to authenticate only once, the report makes use of client side

cookies to store the required authentication information within the browser for the current session.

Once the user is authenticated, an encrypted cookie is created in the browser allowing for multiple

report jobs to be submitted without the need to re-authenticate at each request.

N OTE : If there is a requirement to force a re-authentication on the submission of a given report,use the SH OW A UTH and A UTH TY PE command line arguments or include a %D in therespective report entry in the k eymap file (use of %D will force the user to re-enter their usernameand password each time the report is called) .

It is often the case that within a given Web site that users will access reports which run against

multiple instances of the Oracle database (or ODBC data sources). To minimize the number of

times a user must authenticate themselves (once to each different server), multiple encrypted cookies

are created. Each cookie is keyed to the SID used in the connection string.

If a report is submitted using the place holder $<username> in conjunction with a SQL*Net80

database alias, a separate cookie will being created in the browser for each referenced SID.

For example the following keymap file entries

RE P1: Report=R ep1.rdf userid=$username@ OR CL D estype=CA CH E D esformat=H T ML

RE P2: R eport=R ep2.ref userid=$username@ PROD D estype=C A CH E D esformat=H TML

would result in the user being authenticated against the two different servers and two encrypted cookies beingcreated in the browser. One for OR CL and one for PROD .

With any subsequent request for either server the User name and Password will be retrieved from the

appropriate cookie and used to authenticate the user against that server.

If no connect string is defined in the command line (i.e. either no USERID is defined or no

SQL*Net80 alias is specified), the Oracle Reports CGI executable will use the last database connect

string which achieved a successful connection. This value is stored in a separate cookie within the

client browser ("lastdbid").

The cookies will be removed if the user closes the browser session, but it is also important to limit

the lifetime of the cookie within a given session. For example, a user may have logged on then

gone off to lunch leaving the browser session open! To control this type of security breach the




March 2000

10

administrator may define the REPORTS60_COOKIE_EXPIRE environment variable on the

server. When the Oracle Reports CGI executable (or OWS cartridge) receives a job request from

the client it will compare the time saved in the cookie with the current system time. If the time is

longer than the number of minutes defined in the environment variable (e.g., 30 minutes), the cookie

is rejected and the user again challenged to identify themselves for authentication.

Environment Variables effecting user Authentication

Environment Variable Description

REPORTS60_COMMON_AUTH Specifies the template used to determine the common properties

of the authentication form, such as the size of the form and

whether a toolbar is visible. This template is used in

conjunction with the HTML template set in the

REPORT60_DB_AUTH environment variable.

Default: Value=common.htm

REPORTS60_DB_AUTH Specifies the database authentication template used to

authenticate the user name, password, and database.

Default: Value=dbauth.htm

REPORTS60_ENCRYPTION_KEY Specifies the encryption key used to encrypt the user name and

password for the cookie. The encryption key can be any

character string.

Default: Value=reports6.0




March 2000

11

REPORT SERVER SCALEABILTY

The Oracle Reports Server allows for the automatic load balancing of report execution across anumber of pre-spawned runtime engines. However, if the user community is sufficiently large,

there will be a point where, as new runtime engines are spawned, the processing power of a single

computer is consumed and new report requests are forced to be queued rather than executed

immediately. While the number of report requests at which this occurs is determined by the

complexity of the report, the number of CPUs in the machine and operating system, there will

always be a limit to the scaleabilty that may be achieved from a single computer.

The scaleabilty achievable on a single server is directly proportional to the number of CPUs available

and the nature of the reports being executed on the server. If a report spends the majority of it’s

execution within the RDBMS (i.e., running the query) more CPU cycles are available to process other

reports on the middle tier. If, however, the majority of time is actually spent in formatting the final

output then the CPU cycles available to process other reports will be decreased.

It is possible to determine where the report is spending most of its time by use of the profile

options available within Oracle Reports

REPORTS PROFILE

The Reports Profile option, when set, produces a log file that gives accurate figures as to where the

report spent its processing time. To set the profile option, use the PROFIL E =<filename> command

line argument, where <filename> is the name of the required log file. A typical profile is shown

below:

+------------------------------+

| Reports Profiler statistics |+------------------------------+

TOTAL ELAPSED Time: 29.00 secondsReports Time: 24.00 seconds (82.75% of TOTAL)

ORACLE Time: 5.00 seconds (17.24% of TOTAL)

UPI: 1.00 secondsSQL: 4.00 seconds




March 2000

12

TOTAL CPU Time used by process: N/ A

From the profile it is possible to see the total execution time for the report, the amount of time that

was spent formatting the retrieved data (Reports Time), and the amount of time spent waiting for

the data to be retrieved (ORACLE Time). UPI time is the time spent establishing the database

connection, and parsing and executing the SQL, whilst the SQL time is the time spent performing

the RDBMS fetches and execution of SRW.DO_SQL() statements.

N ote: From initial internal testing within the Oracle Tools Division it was found that the number of Runtime engines which could be supported by a given CPU was as follows;

− Format Intensive reporting: 2 E ngines per available CPU

− D ata Intensive Reporting: 4 E ngines per available CPU

REPORT SERVER CLUSTERING

In order to scale beyond the bounds of a single machine, the Oracle Reports Server is able to

leverage more of an organizations existing hardware, by implementing a heterogeneous cluster of

individual servers. The result is almost infinite scaleabilty.




March 2000

13

1 2 4 8

With Clustering

Without Clustering

Clustered vs.

Unclustered

Clustered vs.

Unclustered

# Reports Engines

T

i m e

By registering individual Reports Servers into a cluster (maintained through a master server), they are

able to act as a single logical, but distributed, reporting engine. As jobs are submitted to the Reports

Server they are automatically re-routed to an available engine running on any machine within the

cluster. In this manner, if the reporting needs of the user base is such that performance is

degrading, it is simply a matter of defining a new machine to the cluster, to further extend the

available processing power. As machines are added to the cluster the Reports Server will

automatically recognize their existence and start to issue job requests to them. Conversely, if one of

the machines becomes unavailable (due to failure or shutdown) the server will automatically cease to

issue requests to that specific machine. The automatic ‘Plug-n-play’ nature of an Oracle Reports

Server cluster means that scaleabilty is limited by the total number of available machines, and not bythe processing power of any one computer.

CONFIGURING THE SERVER FOR HETEROGENEOUS CLUSTERING

When in a clustered configuration, all interaction with the Reports Server is performed via the

master server, which both controls the number of engines spawned on each slave server, as well as

the allocation of jobs to those slaves. This allocation process currently uses a ‘round-robin’

algorithm.

N ote: It is possible for a slave server to be a fully functional R eports Server in its own right. That is, it may start and own it’s own runtime engines independent of the Master server. In this case,any job submission would be to the slave server directly rather than the master and would be localto that server. That is, the master server would be unaware of any direct requests to the slave and hence would be unable to either check for a duplicate request or use any cached output.




March 2000

14

All servers in the cluster must be able to share a file system such that the reporting engines on each

slave are able to write their output to a centralized cache. A central cache ensures that the master

server is able to serve duplicate job requests, both current and those within tolerance, regardless of

the server on which a job request was processed.

N ote: A further benefit of a shared file system is the use of a centralized source directory whichwould eliminate the need to copy the report definition files to each slave server.

Reports Servers within a cluster communicate via SQL*Net80 and as such each individual server

must have an entry in their tnsnames.ora which refers to any server with which it will need to

communicate. That is, each slave must have an entry referencing the master server and vice versa.

The following examples show the tnsnames.ora file for both master and slave servers.

Master Server (RepServ)

RepServ.world =

(Address=(Protocol=TCP)(Host=RepServ)(Port=1949))

RepSlave1.world =


RepSlave2.world =


Slave Server1 (RepSlave1)

RepServ.world =


RepSlave1.world =


Slave Server2 (RepSlave2)

RepServ.world =


RepSlave2.world =




March 2000

15


When the master server is started, it evaluates the value of the CLUSTERCONFIG parameter

within its own configuration file. From this parameter it is able to determine which remote Reports

Servers are slaves and how many engines are to be started on each.

Master Server Configuration File (RepServ.ora)

MaxConnect=4096

SourceDir=”P:\Rep60\Source”

CacheDir=”P:\Rep60\Cache”

CacheSize=50

MinEngine=1

MaxEngine=4

InitEngine=4MaxIdle=60

EngLife=50

ClusterConfig=”(RepSlave1

MinEngine=1

MaxEngine=2

InitEngine=2

CacheDir=”M:\ReportsCache”)

(RepSlave2

MinEngine=1

MaxEngine=3

InitEngine=3

CacheDir=”/Shared/Cache”)

In this example the master server would start two engines on the slave server RepSlave1 , and three

on RepSlave2. The MinEngine and MaxEngine parameters within the ClusterConfig would specify

the minimum and maximum number of engines the server should control on each of the respective

slave Reports Servers. It is not necessary that each slave server see the shared cache directory by the

same name, nor do they have to be based on the same operating system. As long as each can write

to the shared drive.

N ote: To allow more even distribution of load across the available servers, it is important to haveboth the max imum allowable idle time and engine life be consistent across all runtime engines. A ssuch, the values of M A X ID L E and E N GL IFE defined for the master server’s engines areimplied for all slave engines.




March 2000

16

PLUG AND PLAY SERVERS

As the master server in the cluster is started, it will attempt to contact each of the slave servers

defined within the CLUSTERCONFIG parameter in a top down manner. If the slave is up and

running the master will:

• Enter the slave server’s information into its list of active servers.

• Instruct the slave server to spawn the specified number of runtime engines.

• Take control of each engine and add it to its list of available runtime engines.

Communication is now directly to the runtime engines, rather than through the slave server. The

master only contacts the slave if there is the requirement to spawn further engines on that machine.

If the master cannot communicate with one or more of the slaves defined in the list, they will be

assumed to be off line, and hence unable to accept job submissions. In this case, the ‘round-robin’

based job assignment will jump over this server and send the request to the next one that is in the list

of active servers.

In order for the master server to determine when new cluster members have become available, it

explicitly polls for those machines that are in the cluster definition but not in it’s list of active servers.

N ote: The polling interval is approximately every five seconds. H owever, polling only tak es placeduring the times when the server is in an idle state, i.e., when there have been no job submission for the previous five seconds.

Once the slave indicates it is available (i.e. the server is now up), the master will automatically add it

to its list of active servers, obtain control of the appropriate number of runtime engines, and start

issuing submissions to be executed on that platform .

The master server also maintains a connection to all slaves in its active list. If a given slave server was

to go down for some reason, this connection would be broken and hence the master would remove

it from the active list of servers. Depending upon the cause of the break in connection the

following will result:

1. If the slave Reports Server process dies, the runtime engines controlled by the master are stillavailable. In this case, job submissions would continue until the currently spawned engines are

either saturated or they expire through idle time or engine life. No new engines can be spawned,hence if all the current engines are processing reports, this server will be skipped in the ‘round-robin’.




March 2000

17

2. The entire machine is taken off line, no runtime engines are available. With the connections to bothslave server and runtime engines broken, the master would skip this machine until it was notified

(via poll) that the slave node was once again available to receive job requests.

Runtime

Engine

Runtime

Engine

Runtime

Engine

Runtime

Engine

RepSlave1 - OnLine

RuntimeEngine

RepSlave1

Runtime

Engine

RepSlave2 - OffLine

ClusterConfig=“(RepSlave1)

(RepSlave2)”

Ping Slave until it

comes on-line &

available

Engines owned

by Master server

Local Engine

owned bySlave

RepServ

(Master)

RepSlave2

Runtime

Engine

þý

Once the cluster has been defined, the actual nodes may be added or removed at any time and the

Reports Server will adjust accordingly.

In a master/ slave hierarchy the failure of the master node can result in the breakdown of the cluster

structure (though each slave server may still act independently). If a high availability solution is

required, the Oracle Reports Server tightly integrates with Oracle Fail-safe to allow for the automaticswitching of the master server if it should go down. In this manner the Reports Server may not only

scale to the required number of users but also support a 24x7 environment.

N ote: information on Oracle FailSafe may be found on the Oracle web site(http:/ / www.oracle.com)

KEEPING TRACK OF SERVER USE

The move to a centralized reporting infrastructure introduces the requirement to supply certain

operational information.

1. Users want to know the status of any report they have submitted

2. Administrators need to know how many concurrent users there are on the Reports Server. This isuseful for both sizing the environment and to ensure license compliance.




March 2000

18

The Oracle Reports Server makes it possible to answer both of these questions, by posting the

current Report queue to the database each time a job request is submitted. This information is

inserted into a table RW_SERVER_QUEUE and includes such data as:

• The name of the Job

• Who submitted it

• What output format was chosen

• The job’s current status

• When it was queued, started, and subsequently finished

(See appendix for description of the RW_SERVER_QUEUE table structure.)

By granting users SELECT access to this, they may query the job submission of interest anddetermine it’s current status. In the same manner it is possible to implement a Reports Server

Queue screen directly within the Web site itself simply by creating a report based directly on this

table. In this case the queue report itself would appear as a job submission by the user!

N ote: For Oracle Forms based applications the basing of a block against the RW _SE RV E R_QU E UE table would allow users to track their reports without the need toleave the forms environment or resort to use of the W eb.Show_Document built -in.

Conversely, the real time update of the table with the status of jobs submissions makes it very easy

for administrators to know exactly how many concurrent users have requested jobs to be executed

on the Reports server.

By counting the number of entries in the RW_SERVER_QUEUE table which have a status code

indicating that the job has been queued but not completed, it is possible to return an accurate

number of the current active users on the server.

E.g.

SELECT Count(*)FROM RW_SERVER_QUEUE

WHERE STATUS_CODE IN (1, -- ENQUEUED

2, -- OPENING

3 -- RUNNING)

AND JOB_TYPE != ‘Scheduled’




March 2000

19

N ote: W hereas the table contains the date and time a report was Queued, R un, and subsequentlyFinished, it is not a good idea to use a query based on the that fact that a job has a defined ‘QU E UE D’ and ‘ST A RTE D’ time but no ‘FIN ISH E D’ value. If a report terminates dueto an unexpected error, such as an invalid input, the FIN ISH E D column will remain N UL L ,however, the ST A TUS _COD E and ST A TUS _M E SSA GE will both indicate that therehas been a failure and the cause thereof. (See appendix for definition of available status codes.)

CONFIGURING THE SERVER TO UPDATE DATABASE WITH QUEUE ACTIVITY.

The Reports Server queue is implemented through the use of a PL/ SQL based API. It functions to

clear out the queue information each time the server is restarted and to update the table with queue

information as requests are made.

N ote: Defined in %ORA CL E _H OM E %\ Reports60\ Sql\ Rw_Server.sql.

In order to implement the queue the following steps are required:

1. Create a schema which will own the report queue information and have execute privileges on the

server-queue API.

2. Set the RE POSITORY CON N parameter in the Reports Server’s configuration file to theconnection string of the schema which owns the queue data.

When the server starts it will connect as the defined user, clear out the queue table and begin to log

job submissions.

N ote: If the Reports Server and Oracle RDBM S have been installed on a single ‘stand-alone’

W indows-N T machine, the definition of RE POS IT OR Y CON N may prevent the automaticstartup of the Reports Server service as N T boots. This is due to the fact that the Oracle

R DBM S service may yet to have started, thus preventing the Reports Server from performing therequired login. Once the RDBM S has started, the Reports Server Service may be started manually.

CONCLUSION

The move to a centralized reporting infrastructure based on “Internet Computing,” allows

organizations to both minimize their costs and maximize access to information. It does, however,

introduce issues which till now have made many system administrators reticent to adopt the new

paradigm, i.e., the security implications of a Web-based solution and the need to scale to a larger

user community.




March 2000

20

Oracle Reports, in conjunction with Oracle WebDB, answers these issues by allowing for the

implementation of both a scaleable, clustered environment and user authentication and access

control.




March 2000

21

APPENDIX

STRUCTURE OF THE RW_SERVER_QUEUE TABLE

Column Name Description

JOB_TYPE States whether the job listed is CURRENT, PAST, or SCHEDULED

JOB_ID System generated job identification number

JOB_NAME Job submission name (or file name if no value for JOBNAME is

specified)

STATUS_CODE Current status of the job - (see below for definitions)

STATUS_MESSAGE Full message text relating to status code

(includes Oracle error message if reports terminated)

COMMAND _LIN E Complete command line submitted for this job submission

OWNER User who submitted the job. On the Web, the default user is the OS

user who owns the web server.

DESTYPE Format of the report output

DESNAME Name the report output if not going to the Reports Server cache.

SERVER Reports Server to which the report was submitted

QUEUED Date and time the job submission was received and queued by the given

Reports Server.

STARTED Date and time the job submission was executed

FINISHED Date and time the submitted job completed

LAST_RUN Date and time a scheduled job was last executed

NEXT_RUN Date and time a scheduled job will next execute.

REPEAT_INTERVAL Frequency on which to execute a job

REPEAT_PATTERN Repeat pattern (every minute, hour, day, etc.)




March 2000

22

JOB SUBMISSION STATUS CODES

Status Code Defined PL/ SQL Constant Description of Status code

0 UNKNOWN No such job

1 ENQUEUED Job is waiting in queue

2 OPENING Server is opening report definition

3 RUNNING Report is currently running

4 FINISHED Job submission has completed successfully

5 TERMINATED_W_ERR Job has terminated with an error

6 CRASHED Engine has crashed during execution of the job

7 CANCELED Job was canceled by user request

8 SERVER_SHUTDOWN Job was canceled due to the Server shutting down

9 WILL_RETRY Job failed and is queued for RETRY

10 SENDING_OUTPUT Job has completed and is returning output?



Oracle Corporation

World Headquarters

500 Oracle Parkway

Redwood Shores, CA 94065

U.S.A.

Worldwide Inquiries:

+1.650.506.7000

Fax +1.650.506.7200

http://www.oracle.com/

Copyright © Oracle Corporation 1999

All Rights Reserved

This document is provided for informational purposes only,

and the information herein is subject to change without notice.

Please report any errors herein to Oracle Corporation. Oracle

Corporation does not provide any warranties covering and

specifically disclaims any liability in connection with this

document.

Oracle is a registered trademark, and Oracle8 i , Oracle8,

PL/SQL, and Oracle Expert are trademarks of Oracle

Corporation. All other company and product names

mentioned are used for identification purposes only and may

be trademarks of their respective owners.

report serveur

Documents