Oracle9iAS Reports Services Publishing Reports to the Web Release 2 (9.0.2) Part Number A92102-01 |
|
Modern business processes often require the blending of automation into the work environment through the invocation of behind-the-scenes functions and procedures. Behind-the-scenes tasks can include the automatic production of output such as an invoice that prints automatically when an order is processed, a Web site that is automatically updated with current data, or an automatic e-mail with fresh report output when a transaction is completed.
Automatic output in response to events used to be a fairly complicated effort, particularly if you wished to produce the same results possible through interactive, RAD development tools, such as Oracle9i Reports Developer.
To address the requirement of automatic output, Oracle introduced a scheduling mechanism in Oracle9iAS Reports Services that enabled the invocation of reports on a scheduled basis without requiring additional user interaction. But this left one requirement unresolved: the ability to automatically run a report in response to an event in the database, such as the insertion of a record or the change of a value.
With the Oracle9iAS Reports Services Event-Driven Publishing API, you can automatically run a report in response to an event in the database, such as the insertion of a record or the change of a value. The Event-Driven Publishing API is a PL/SQL API that allows for the automatic submission of jobs to Oracle9iAS Reports Services from within the database.
This chapter provides a look at the Event-Driven Publishing API and includes examples of its use. It includes the following sections:
The Event-Driven Publishing API is a PL/SQL Package that provides the basic functions required for the development of procedures that respond to events in the database. Event-driven jobs are submitted using the HTTP protocol. The server assigns a unique job_ident record to every call, useful for tracking the status of the job.
The API consists of several key elements:
These API elements are discussed in more detail in the following sections.
The API is installed together with Oracle9iAS Reports Services Security and Oracle9iAS Portal, but neither is required. Installation scripts are also available separately should you want to install the API into a database that does not also hold Oracle Portal:
A parameter list is a PL/SQL variable of type SRW_PARAMLIST. A variable of this type is an array of 255 elements of type SRW_PARAMETER, which itself consists of two attributes: NAME and VALUE. The API provides procedures for manipulating parameter lists, including:
These procedures allow you to manipulate your parameter lists. They are discussed briefly in this section. You'll find more information in the Oracle9iAS Reports API documentation.
Whenever you use a parameter list for the first time, it must be initialized before you can add parameters to it. For example:
DECLAREmyPlist SRW_PARAMLIST;BEGINmyPlist := SRW_PARAMLIST(SRW_PARAMETER('','')); srw.add_parameter(myPlist,'myParameter','myValue');END;
Both attributes of a parameter (NAME and VALUE) are of type VARCHAR2 and may not exceed a length of 80 characters for the NAME and 255 characters for the value.
The ADD_PARAMETER function has a third--optional--attribute, called MODE. MODE determines whether a parameter will be overwritten or an error raised in the event that a parameter with the same name already exists. To specify that an error will be raised in the event of duplicate names, use the constant CHECK_FOR_EXISTANCE. This is the default value for the MODE attribute. To specify that a parameter will be overwritten in the event of duplicate names, use the constant OVERWRITE_IF_EXISTS.
Use REMOVE_PARAMETER to remove a parameter from a parameter list. Call the procedure, and pass the parameter list from which you want to remove a parameter along with the name of the parameter you want to remove.
For example:
DECLAREmyPlist SRW_PARAMLIST;BEGINmyPlist := SRW_PARAMLIST(SRW_PARAMETER('','')); srw.add_parameter(myPlist,'myParameter','myValue'); srw.remove_parameter(myPlist,'myParameter');END;
To remove ALL parameters from your list, use CLEAR_PARAMETER_LIST. For example:
DECLAREmyPlist SRW_PARAMLIST;BEGINmyPlist := SRW_PARAMLIST(SRW_PARAMETER('','')); srw.add_parameter(myPlist,'myParameter','myValue'); srw.clear_parameter_list(myPlist);END;
This will remove all parameters from your list.
A parameter list contains all vital parameters for submitting a job. The job type determines which parameters are required on the list to enable the Reports Server to process the request.
The listed parameters are the same ones that you must specify when you submit a job from a browser to the Reports Servlet. In such a case, if the job is a report you will need at least the following parameters but may have more:
Each request returns a job_ident record that holds the information required to identify the job uniquely. This information is stored in variable of type SRW.JOB_IDENT. Be aware that this is a PACKAGE-TYPE and must be referenced SRW.JOB_IDENT; while the parameter list is an OBJECT-TYPE and must be referenced SRW_PARAMLIST.
For example:
DECLAREmyPlist SRW_PARAMLIST; myIdent SRW.Job_Ident;BEGINmyPlist := SRW_PARAMLIST(SRW_PARAMETER('','')); srw.add_parameter(myPlist,'GATEWAY','http://...'); srw.add_parameter(myPlist,'SERVER','mySVR'); srw.add_parameter(myPlist,'REPORT','myReport.RDF'); srw.add_parameter(myPlist,'USERID','me/secret'); myIdent := srw.run_report(myPlist);END;
The API method RUN_REPORT takes a parameter list that contains all vital information as input (via ADD_PARAMETER), creates and submits the request, and returns the job_ident record.
The job_ident record contains the following parameters:
These parameters are needed by the SRW.REPORT_STATUS function to get status information for a submitted job.
The Event-Driven Publishing API provides a two-way communication with the Reports Server. You submit a job to the server, and you can query the status of this job from the server using the SRW.REPORT_STATUS function.
This function will return a record of type SRW.STATUS_RECORD that holds the same information you would see in the job-status display if you were using the Reports Servlet's SHOWJOBS command.
For example:
DECLAREmyPlist SRW_PARAMLIST; myIdent SRW.Job_Ident; myStatus SRW.Status_Record;BEGINmyPlist := SRW_PARAMLIST(SRW_PARAMETER('','')); srw.add_parameter(myPlist,'GATEWAY','http://...'); srw.add_parameter(myPlist,'SERVER','mySVR'); srw.add_parameter(myPlist,'REPORT','MyReport.RDF'); srw.add_parameter(myPlist,'USERID','me/secret'); myIdent := srw.run_report(myPlist); myStatus := srw.report_status(myIdent);END;
You can use the returned status record for fetching information about the status of your job.
The status record contains processing information about your job. It contains the same information found in the server queue (SHOWJOBS). Additionally, it contains information about the files produced for finished jobs and the lineage for scheduled jobs.
The most important information in the status record is the current job status and the status text, used in turn to check for runtime errors and their causes.
You can use timing information to determine if a job is subject to cancellation because it has exceeded its predicted time for completion.
One way to use the status record is to cancel a job. The Event-Driven Publishing API offers a method for cancelling a job that has been submitted to the server. This might be handy if you want to remove a job that has exceeded its allowed time to run or if you simply have scheduled jobs you want to cancel.
To cancel a job, use the following procedure:
DECLAREmyPlist SRW_PARAMLIST; myIdent SRW.Job_Ident; myStatus SRW.Status_Record;BEGINmyPlist := SRW_PARAMLIST(SRW_PARAMETER('','')); srw.add_parameter(myPlist,'GATEWAY','http://...'); srw.add_parameter(myPlist,'SERVER','mySVR'); srw.add_parameter(myPlist,'REPORT','myReport.RDF'); srw.add_parameter(myPlist,'USERID','me/secret'); myIdent := srw.run_report(myPlist); srw.cancel_report(myIdent);END;
As evident in this example, you cancel a report by calling the CANCEL_REPORT procedure (srw.cancel_report) and passing it the job_ident record of the job you want to cancel. The procedure takes an optional parameter list to enable you to pass any additional parameters you might need.
Because these processes all run behind the scenes, there is no actual place where debugging information is produced during normal execution. Therefore, the API has two procedures that toggle a special debugging mode that produces extensive debugging information via DBMS_OUTPUT:
To switch on debugging mode simply call SRW.START_DEBUGGING and to stop it call SRW.STOP_DEBUGGING. The debugging-mode must be started immediately before you run your actual logic. It stays on as long as the current instance of the package is loaded.
One way you can display this information is by setting SERVEROUT to ON in SQL*PLUS before you run your script.
In addition to this method of debugging, the API has a set of pre-defined exceptions to be used for error handling. You'll find examples of these exceptions in the srw_test.sql script provided with your Oracle9iAS Reports Services installation. Additionally, see the Reports API reference documentation for a detailed explanation of these exceptions.
Database triggers are the primary mechanism for invoking reports using the Event-Driven Publishing API. The Oracle database allows you to define various scopes of triggers that fire in response to various events. To submit a database-driven job, you use the code described in the previous sections within a database trigger.
There are many ways to use event-driven publishing. One way is to create security protocols using a trigger that fires whenever a grant is done or a user logs on or off. Another way is to create automated processes that respond to certain types of changes to data in a table. For example, a database trigger could fire when the status of an expense report changes to DONE; in turn, a report could automatically be sent to an employee's manager.
For example:
CREATE TRIGGER EXP_REP_TRGAFTER INSERT OR UPDATE on EXP_REP FOR EACH ROW myPlist SRW_PARAMLIST; myIdent SRW.Job_Ident;BEGINIF (:new.ExpStat = 'DONE') THENmyPlist := SRW_PARAMLIST(SRW_PARAMETER('','')); srw.add_parameter(myPlist,'GATEWAY','http://...'); srw.add_parameter(myPlist,'SERVER','fooSVR'); srw.add_parameter(myPlist,'REPORT','foo.RDF'); srw.add_parameter(myPlist,'USERID','foo/bar'); srw.add_parameter(myPlist,'ExpenseID',:new.ExpID); myIdent := srw.run_report(myPlist);END IF;END;
This trigger will fire after each update on the EXP_REP table. In the event the status changes to DONE, the report request is run.
If you want your request to run against a key specified in the cgicmd.dat file, specify the CMDKEY
parameter in lieu of the REPORT
parameter. If the key contains user ID information, you can omit the USERID
parameter as well. For example:
CREATE TRIGGER EXP_REP_TRGAFTER INSERT OR UPDATE on EXP_REP FOR EACH ROW myPlist SRW_PARAMLIST; myIdent SRW.Job_Ident;BEGINIF (:new.ExpStat = 'DONE') THENmyPlist := SRW_PARAMLIST(SRW_PARAMETER('','')); srw.add_parameter(myPlist,'GATEWAY','http://...'); srw.add_parameter(myPlist,'SERVER','fooSVR'); srw.add_parameter(myPlist,'CMDKEY','keyvalue'); srw.add_parameter(myPlist,'ExpenseID',:new.ExpID); myIdent := srw.run_report(myPlist);END IF;END;
Additionally, if you have defined an advanced distribution model via a distribution XML file, you can specify that file with the DIST
parameter. For example:
CREATE TRIGGER EXP_REP_TRGAFTER INSERT OR UPDATE on EXP_REP FOR EACH ROW myPlist SRW_PARAMLIST; myIdent SRW.Job_Ident;BEGINIF (:new.ExpStat = 'DONE') THENmyPlist := SRW_PARAMLIST(SRW_PARAMETER('','')); srw.add_parameter(myPlist,'GATEWAY','http://...'); srw.add_parameter(myPlist,'SERVER','fooSVR'); srw.add_parameter(myPlist,'REPORT','foo.RDF'); srw.add_parameter(myPlist,'USERID','foo/bar'); srw.add_parameter(myPlist,'DISTRIBUTE','YES'); srw.add_parameter(myPlist,'DESTINATION','filename.xml'); srw.add_parameter(myPlist,'ExpenseID',:new.ExpID); myIdent := srw.run_report(myPlist);END IF;END;
This is one way to move this kind of logic from your application into the database and use the database as a central storage for business processes.
Oracle Advanced Queuing is a means for building an asynchronous request/response mechanism around a so-called queue and two processes: ENQUEUE, which puts MESSAGES into a queue, and DEQUEUE, which reads the queue.
Advanced queuing provides sophisticated mechanisms for distributing messages across queues and for queue subscription. These mechanisms are all built on top of these basic elements (ENQUEUE, DEQUEUE, and MESSAGES).
With the Event-Driven Publishing API you can use these queues to store and transmit report jobs. You can even build your own queuing mechanism if the one provided with Oracle9iAS Reports Services does not fit your needs.
A queue is a table in the database that holds, along with several administrative columns, an object column that represents a message. In our case the message is the parameter list.
The dbms_AQadm
package, provided with Advanced Queuing, contains all the administrative functions required for setting up an advanced queuing system.
Use dbms_AQadm.Create_Queue_Table
to create the physical table in the database. You must pass it a name for the table and a name for the object type that will define the message for this queue.
For example:
... execute dbms_AQadm.Create_Queue_Table(queue_Table=>'queuename._tab', queue_Payload_Type=>'SRW_ParamList_Object', compatible=>'9.0');
In earlier examples, we created the object type SRW_PARAMLIST_OBJECT that encapsulates the SRW_PARAMLIST type in object notation so it can be used as a message.
After creating the queue table, you must create the queue with dbms_AQadm.Create_Queue
and start the queue with dbms_AQadm.Start_Queue
.
For example:
... execute dbms_AQadm.Create_Queue(Queue_Name=>'queuename',Queue_Table=>'queuename._tab');prompt ... starting queue execute dbms_AQadm.Start_Queue(Queue_Name=>'queuename');...
Having created and started the queue, what you need now is a procedure that creates a message in this queue and a procedure that reads out the queue and submits the job to the server. These are discussed in the following sections.
The enqueuing procedure is responsible for putting a message into the queue. This procedure can be part of your application, called by a database-trigger, or provided via an external mechanism. In this section, we will provide an example of creating a stored procedure that puts a simple message in this queue.
Because our message is the parameter list itself, the procedure is fairly easy. We use the same code we used in earlier sections to create a parameter list. In addition to the variables we used, we define an object
variable to hold the message we will put into the queue.
... plist_object SRW_ParamList_Object; ...
After creating the parameter list we create the actual message object using the object constructor.
... plist_object := SRW_ParamList_Object(plist); ...
Then we enqueue the message using the enqueue procedure provided by Advanced Queuing.
... dbms_aq.enqueue(queue_name => 'myQueue',enqueue_options => enqueue_options, message_properties => message_properties, payload => PList_Object, msgid => message_handle);...
The message is put into the queue. Because we did not set up any message distribution, the message will stay in the queue until it is fetched by a dequeuing-procedure, which is discussed in the next section.
A dequeuing procedure reads out all available messages in a queue and processes them. In our case, we want to read out the message and submit a job to the server using the parameter list that was attached to the message.
To accomplish this, we follow this example:
BEGINdequeue_options.wait := 1;loopDBMS_AQ.DEQUEUE(queue_name => 'myQueue',dequeue_options => dequeue_options, message_properties => message_properties, payload => PList_Object, msgid => message_handle);COMMIT; plist := plist_object.params; r_jid := SRW.run_report(plist);end loop; exception when aq_timeout thenbeginNULL;end;END;
This code example will read out the queue until all messages have been processed. Time allowed for processing is determined by the time-out defined in the second line of code. This time-out defines the amount of seconds the dequeue procedure should wait for a message before creating a time-out exception.
The DBMS_AQ.DEQUEUE
built-in is provided by Advanced Queuing for reading out messages. It puts the payload of the message, the object that holds the information, into the object defined by the payload parameter.
Using plist
, we extract the information from the payload object. As mentioned before, our object holds a parameter list. It is stored in the attribute PARAMS
inside the object. The extracted parameter list is then handed over to SRW.RUN_REPORT
for submitting the job.
If you want to avoid the need for invoking this dequeuing procedure by hand, you can run it as a job inside the database.
|
![]() Copyright © 2002 Oracle Corporation. All Rights Reserved. |
|