Apr 1, 2010

More About Oracle Reports....

What are Oracle Report Triggers :
As a general rule, any processing that will affect the data retrieved by the report should be performed in the Before Parameter Form or After Parameter Form triggers. (These are the two report triggers that fire before anything is parsed or fetched.) Any processing that will not affect the data retrieved by the report can be performed in the other triggers.
Report Builder has five global report triggers. You cannot create new global report triggers. The trigger names indicate at what point the trigger fires: 

Before Report trigger :
Description The Before Report trigger fires before the report is executed but after queries are parsed and data is fetched.
Definition Level report
On Failure
Displays an error message and then returns to the place from which you ran the report .

After Report trigger :
Description The After Report trigger fires after you exit the Runtime Previewer, or after report output is sent to a specified destination, such as a file, a printer, or a mailid. This trigger can be used to clean up any initial processing that was done, such as deleting tables. Note, however, that this trigger always fires, whether or not your report
completed successfully.
Definition Level report
On Failure
Does not affect formatting because the report is done. You can raise a message, though, to indicate that the report did not run correctly. For example, you could put the system time in a variable in the Before Report trigger and then compare it against the system time in the After Report trigger . If the report took longer than a certain time to run, you could raise an error.
Usage Notes
* The After-Report trigger does not fire when you are in the Live Previewer.

Between Pages trigger :
Description The Between Pages trigger fires before each page of the report is formatted, except the very first page. This trigger can be used for customized page formatting. In the Runtime Previewer or Live Previewer, this trigger only fires the first time that you go to a page. If you subsequently return to the page, the trigger does not fire again.
Definition Level  report
On Failure
Displays an error message when you try to go to the page for which the trigger returned FALSE. The pages subsequent to the page that returned FALSE are not formatted. If the trigger returns FALSE on the last page, nothing happens because the report is done formatting. The Between Pages trigger does not fire before the first page. If the trigger returns FALSE on the first page, the first page is displayed, but, if you try to go to the second page, an error message is displayed.

Before Parameter Form trigger :
Description The Before Parameter Form trigger fires before the Runtime Parameter Form is displayed. From this trigger, you can access and change the values of parameters, PL/SQL global variables, and report-level columns. If the Runtime Parameter Form is suppressed, this trigger still fires. Consequently, you can use this trigger for validation of command line parameters.
Definition Level report
On Failure
Displays an error message and then returns to the place from which you ran the report .

After Parameter Form trigger :
Description The After Parameter Form trigger fires after the Runtime Parameter Form is displayed. From this trigger, you can access parameters and check their values. This trigger can also be used to change parameter values or, if an error occurs, return to the Runtime Parameter Form. Columns from the data model are not accessible from this trigger. If the Runtime Parameter Form is suppressed, the After Parameter Form trigger still fires. Consequently, you can use this trigger for validation of command line parameters or other data.
Definition Level report
On Failure
Returns to the Runtime Parameter Form. If the Form is suppressed, then returns to place from which you ran the report .

Report trigger must explicitly return TRUE or FALSE. The following table describe what happens when the report trigger returns FALSE.


         REPORT TRIGGER
 WHAT HAPPENS IF TRIGGER RETURNS FALSE 
Before Report
Displays an error message and then returns to the place from where the report was executed.
After Report
Does not effect formatting because the report is done.You can raise a message, though, to indicate that the report did not run correctly.
Between Pages
Displays an error message when you try to go to the page for which the trigger returned FALSE. The pages subsequent to the page that returned FALSE are not formatted.
Before Parameter Form
Displays an error message and then returns to the place from where the report was executed.
After Parameter Form
Returns to the Runtime Parameter Form.If the form is suppressed, then returns to the place from where the report was executed.


Report trigger order of execution :
The order of events when a report is executed is as follows:
Before Parameter Form trigger is fired.
1 Runtime Parameter Form appears (if not suppressed).
2 After Parameter Form trigger is fired (unless the user cancels from the Runtime Parameter Form).
3 Report is “compiled.”
4 Queries are parsed.
5 Before Report trigger is fired.
6 SET TRANSACTION READONLY is executed (if specified via the READONLY argument or setting).
7 The report is executed and the Between Pages trigger fires for each page except the last one. (Note that data can be fetched at any time while the report is being formatted.) COMMITs can occur during this time due to any of the following-- user exit with DDL, SRW.DO_SQL with DDL, or if ONFAILURE=COMMIT, and the report fails.
8 COMMIT is executed (if READONLY is specified) to end the transaction.
9 After Report trigger is fired.
10 COMMIT/ROLLBACK/NOACTION is executed based on what was specified via the ONSUCCESS argument or setting.


Cautions
·        In steps 4 through 9, avoid DDL statements that would modify the tables on which the report is based. Step 3 takes a snapshot of the tables and the snapshot must remain valid throughout the execution of the report . In steps 7 through 9, avoid DML statements that would modify the contents of the tables on which the report is based. Queries may be executed in any order, which makes DML statements unreliable (unless performed on tables not used by the report).
·        If you specify READONLY, you should avoid DDL altogether. When you execute a DDL statement (e.g., via SRW.DO_SQL or a user exit), a COMMIT is automatically issued. If you are using READONLY, this will prematurely end the transaction begun by SET TRANSACTION READONLY.

Report trigger restrictions:
·       If you are sending your report output to the Runtime Previewer or Live Previewer, you should note that some or all of the report triggers may be fired before you see the report output. For example, suppose that you use SRW.MESSAGE to issue a message in the Between Pages trigger when a condition is met. If there are forward references in the report (e.g., a total number of pages displayed before the last page), Report Builder may have to format ahead to compute the forward references. Hence, even though you have not yet seen a page, it may already have been formatted and the trigger fired.

·        In report triggers, you can use the values of report-level columns and parameters.
            For example, you might need to use the value of a parameter called COUNT1 in a condition (e.g., IF :COUNT1       = 10).
Note, though, that you cannot reference any page-dependent columns (i.e., a column with a Reset At of   Page) or columns that rely on page-dependent columns.
·        In the Before and After Parameter Form, and Before and After Report triggers, you can set the values of parameters (e.g., give them a value in an assignment statement, :COUNT1 = 15). In the Before and After Report triggers, you can also set the values of report-level, placeholder columns.
·       In the Between Pages trigger, you cannot set the values of any data model objects.

Note also that the use of PL/SQL global variables to indirectly set the values of columns or parameters is not recommended. If you do this, you may get unpredictable results.

·        If you run a report from Report Builder Runtime (i.e., not the command line or SRW.RUN_REPORT), you should commit database changes you make in the Before Parameter Form, After Parameter Form, and Validation triggers before the report runs. When running in this way, these triggers will share the parent process’ database connection. When the report is actually executed, however, it will establish its own database connection.

·       A lexical reference cannot be used to create additional bind variables after the After Parameter Form trigger fires. For example, suppose you have a query like the following (note that the WHERE clause is replaced by a lexical reference): SELECT ENAME, SAL FROM EMP &where_clause
If the value of the WHERE_CLAUSE parameter contains a reference to a bind variable, you must specify the value in the After Parameter Form trigger or earlier.
You would get an error if you supplied the following value for the parameter in the Before Report trigger. If you supplied this same value in the After Parameter Form trigger, the report would run.


·       GROUP FILTER :
Description: A group filter is a PL/SQL function that determines which records to include in a group , if the Filter Type property is PL/SQL. The function must return a boolean value (TRUE or FALSE). Depending on whether the function returns TRUE or FALSE, the current record is included or excluded from the report. You can access group filters from the Object Navigator, the Property Palette (the PL/SQL Filter property), or the PL/SQL Editor.
Definition Level group
On Failure Excludes the current record from the group .



·       FORMULA :
Description: Formulas are PL/SQL functions that populate formula or placeholder columns. You can access the PL/SQL for formulas from the Object Navigator, the PL/SQL Editor, or the Property Palette (i.e., the PL/SQL Formula  property). A column of datatype Number can only have a formula that returns a value of datatype NUMBER. A column of Datatype Date can only have a formula that returns a value of datatype DATE. A column of Datatype Character can only have a formula that returns a value of datatype CHARACTER, VARCHAR, or VARCHAR2.
Definition Level column
On Failure No value is returned for the column.



VALIDATION TRIGGER :
Description: Validation triggers are PL/SQL functions that are executed when parameter values are specified on the command line and when you accept the Runtime Parameter Form. (Notice that this means each validation trigger may fire twice when you execute the report.) Validation triggers are also used to validate the Initial Value
property of the parameter. The function must return a boolean value (TRUE or FALSE). Depending on whether the function returns TRUE or FALSE, the user is  returned to the Runtime Parameter Form. You can access validation triggers from the Object Navigator, the PL/SQL Editor, or the Property Palette (Validation Trigger property).
Definition Level parameter
On Failure The user is returned to the parameter value in the Runtime Parameter Form
where they can either change it or cancel the Runtime Parameter Form.


·       FORMAT TRIGGER :
Description Format triggers are PL/SQL functions executed before the object is formatted. The trigger can be used to dynamically change the formatting attributes of the object. The function must return a Boolean value (TRUE or FALSE). Depending on whether the function returns TRUE or FALSE, the current instance of the object is included or excluded from the report output. You can access format triggers from the Object Navigator, the Property Palette, or the PL/SQL Editor.
Definition Level layout object
On Failure Excludes the current instance of the object from the output.
Usage Notes
* Format triggers do not affect the data retrieved by the report. For example, if a format trigger returns FALSE for a field, the data for the field is retrieved even though the field does not appear in the output.
* If a format trigger suppresses report output on the last page of the report, the last page will still be formatted and sent to the appropriate output and the page will be included in the total number of pages.



·       ACTION TRIGGER :
Description Action triggers are PL/SQL procedures executed when a button is selected in the Runtime Previewer. The trigger can be used to dynamically call another report (drill down) or execute any other PL/SQL. You can access action triggers from the Object Navigator, the Property Palette (PL/SQL Trigger property), or the PL/SQL Editor.
Definition Level button
Usage Notes
PL/SQL action triggers cannot be tested in the Live Previewer because the buttons are not active there. You must use the Runtime Previewer (choose View Runtime Preview from the Live Previewer).
You cannot use the PL/SQL Interpreter to debug action triggers because it is not available from the Runtime Previewer and buttons cannot be activated in the Live Previewer. To get around this, you can move your action trigger code to a report trigger to test it from the Live Previewer.


Which are User Exits used in Apps Reports?

·       FND FLEXSQL
Call this user exit to create a SQL fragment usable by your report to tailor your SELECT statement that retrieves flexfield values. This fragment allows you to SELECT flexfield values or to create a WHERE, ORDER BY, GROUP BY, or HAVING clause to limit or sort the flexfield values returned by your SELECT statement. You call this user exit once for each fragment you need for your select statement. You define all flexfield columns in your report as type CHARACTER even though your table may use NUMBER or DATE or some other datatype.

Syntax:
FND FLEXSQL
CODE=”flexfield code
APPL_SHORT_NAME=”application short name
OUTPUT=”:output lexical parameter name
MODE=”{ SELECT | WHERE | HAVING | ORDER BY}”
[DISPLAY=”{ALL | flexfield qualifier | segment number}”]
[SHOWDEPSEG=”{Y | N}”]
[NUM=”:structure defining lexical” |
MULTINUM=”{Y | N}”]
[TABLEALIAS=”code combination table alias”]
[OPERATOR=”{ = | < | > | <= | >= | != | ”||” |
BETWEEN | QBE}”]
[OPERAND1=”:input parameter or value”]
[OPERAND2=”:input parameter or value”]



FND FLEXIDVAL
Call this user exit to populate fields for display. You pass the key flexfields data retrieved by the query into this exit from the formula column. With this exit you display values, descriptions and prompts by passing appropriate token (any one of VALUE, DESCRIPTION, APROMPT or LPROMPT).
Syntax:
FND FLEXIDVAL
CODE=”flexfield code
APPL_SHORT_NAME=”application short name
DATA=”:source column name
[NUM=”:structure defining source column/lexical”]
[DISPLAY=”{ALL|flexfield qualifier|segment number}”]
[IDISPLAY=”{ALL|flexfield qualifier|segment
number}”]
[SHOWDEPSEG=”{Y | N}”]
[VALUE=”:output column name”]
[DESCRIPTION=”:output column name”]
[APROMPT=”:output column name”]
[LPROMPT=”:output column name”]
[PADDED_VALUE=”:output column name”]
[SECURITY=”:column name”]


·       FND SRWINIT
You call the user exit FND SRWINIT from your Before Report Trigger.FND SRWINIT fetches concurrent request information and sets up profile options. You must include this step if you use any Oracle Application Object Library features in your report (such as concurrent processing).


·       FND SRWEXIT
You call the user exit FND SRWEXIT from your After Report Trigger. FND SRWEXIT frees all the memory allocation done in other Oracle Applications user exits. You must include this step if you use any Oracle Application Object Library features in your report (such as concurrent processing).



Basic Implementation Steps

Step 1 : Call FND SRWINIT from your Before Report Trigger
You call the user exit FND SRWINIT from your Before Report Trigger. FND SRWINIT fetches concurrent request information and sets up profile options. You must include this step if you use any Oracle Application Object Library features in your report (such as concurrent processing).


Step 2 : Call FND SRWEXIT from your After Report Trigger
You call the user exit FND SRWEXIT from your After Report Trigger. FND SRWEXIT frees all the memory allocation done in other Oracle Applications user exits. You must include this step if you use any Oracle Application Object Library features in your report (such as concurrent processing).

Step 3 : Call FND FLEXSQL from the Before Report Trigger
You need to pass the concatenated segment values from the underlying  code combinations table to the user exit so that it can display appropriate data and derive any descriptions and values from switched value sets as needed. You get this information by calling the AOL user exit FND FLEXSQL from the Before Report Trigger. This user exit
populates the lexical parameter that you specify with the appropriate column names/SQL fragment at run time. You include this lexical parameter in the SELECT clause of your report query. This enables the report itself to retrieve the concatenated flexfield segment values. You call this user exit once for each lexical to be set. You do not display this
column in your report. You use this ”hidden field” as input to the FND FLEXIDVAL user exit call. This user exit can also handle multi–structure flexfield reporting by generating a decode on the structure column. If your report query uses table joins, this user exit can prepend your code combination table name alias to the column names it returns.
SELECT &LEXICAL alias, column
becomes, for example,
SELECT SEGMENT1||’\n’||SEGMENT2 alias, column
Note: Oracle Reports needs the column alias to keep the name of column fixed for the lexicals in SELECT clauses. Without the alias, Oracle Reports assigns the name of the column as the initial value of the lexical and a discrepancy occurs when the value of the lexical changes at run time.

Step 4 : Restrict report data based upon flexfield values
You call the user exit FND FLEXSQL with MODE=”WHERE” from the Before Report Trigger. This user exit populates a lexical parameter that you specify with the appropriate SQL fragment at run time. You include this lexical parameter in the WHERE clause of your report query. You call this user exit once for each lexical to be changed. If your report query uses table joins, you can have this user exit prepend your code combination table name alias to the column names it returns.
WHERE tax_flag = ’Y’ and &LEXICAL < &reportinput
becomes, for example,
WHERE tax_flag = ’Y’ and T1.segment3 < 200    The same procedure can be applied for a HAVING clause.

Step 5 : Order by flexfield columns
You call the user exit FND FLEXSQL with MODE=”ORDER BY” from the Before Report Trigger. This user exit populates the lexical  parameter that you specify with the appropriate SQL fragment at run time. You include this lexical parameter in the ORDER BY clause of your report query. You call this user exit once for each lexical to be changed. If your report query uses table joins, you can have this user exit prepend your code combination table name alias to the column names it returns.
ORDER BY column1, &LEXICAL
becomes, for example,
ORDER BY column1, segment1, segment3


Step 6 : Display flexfield segment values, descriptions, and prompts
Create a Formula Column (an Oracle Reports 6.0 data construct that enables you to call a user exit). Call the user exit FND FLEXIDVAL as the Formula for this column. This user exit automatically fetches more complicated information such as descriptions and prompts so that you do not have to use complicated table joins to the flexfield tables. Then
you create a new field (an Oracle Reports 6.0 construct used to format and display Columns), assign the Formula Column as its source, and add this field to your report using the screen painter. You need to include this field on the same Repeating Frame (an Oracle Reports 6.0 construct found in the screen painter that defines the frequency of data
retrieved) as the rest of your data, where data could be actual report data, boilerplate, column headings, etc. The user exit is called and flexfield information retrieved at the frequency of the Repeating Frame that contains your field. In the report data case, the user exit is called and flexfield information retrieved once for every row retrieved with your query. All flexfield segment values and descriptions are displayed left justified. Segment values are not truncated, that is, the Display Size defined in Define Key Segments screen is ignored. Segment value descriptions are truncated to the description size (if one is displayed) or the concatenated description size (for concatenated segments)
defined in the form.



System Parameters:

BACKGROUND       Is whether the report should run in the foreground or the background.
COPIES                      Is the number of report copies that should be made when the report is printed.
CURRENCY              Is the symbol for the currency indicator (e.g., "$").
DECIMAL                 Is the symbol for the decimal indicator (e.g., ".").
DESFORMAT           Is the definition of the output device's format (e.g., landscape mode for a printer).  This                            parameter is used when running a report in a character-mode environment, and when                          sending a bitmap     report to a file (e.g. to create PDF or HTML output).
DESNAME                Is the name of the output device (e.g., the file name, printer's name, mail userid).
DESTYPE                  Is the type of device to which to send the report output (screen, file, mail, printer, or                                                 screen using PostScript format).
MODE                        Is whether the report should run in character mode or bitmap.
ORIENTATION       Is the print direction for the report (landscape, portrait, default).
PRINTJOB                 Is whether the Print Job dialog box should appear before the report is run.
THOUSANDS            Is the symbol for the thousand's indicator (e.g., ",").



Other Columns of Reports:

Placeholder columns :
A placeholder is a column for which you set the datatype and value in PL/SQL that you define.  You can set the value of a placeholder column in the following places:

·       the Before Report Trigger, if the placeholder is a report-level column
·       a report-level formula column, if the placeholder is a report-level column
·       a formula in the placeholder's group or a group below it (the value is set once for each record of the group) 

Summary columns:
A summary column performs a computation on another column's data.  Using the Report Wizard or Data Wizard, you can create the following summaries:  sum, average, count, minimum, maximum, % total.  You can also create a summary column manually in the Data Model view, and use the Property Palette to create the following additional summaries:  first, last, standard deviation, variance.
Note:  For group reports, the Report Wizard and Data Wizard create n summary fields in the data model for each summary column you define:  one at each group level above the column being summarized, and one at the report level.  For example, if a report is grouped by division, and further grouped by department, then a summary column defined for a salary total would create fields for the sum of salaries for each division and each department group (group-level summaries), and the sum of all salaries (report-level summary).

Formula columns :
A formula column performs a user-defined computation on another column(s) data, including placeholder columns. Formula columns should not be used to set values for parameters.

Description  Formulas are PL/SQL functions that populate formula or placeholder columns
.  You can access the PL/SQL for formulas from the Object Navigator, the PL/SQL Editor, or the Property Palette (i.e., the PL/SQL Formula property).
A column of datatype Number can only have a formula that returns a value of datatype NUMBER.  A column of Datatype Date can only have a formula that returns a value of datatype DATE.  A column of Datatype Character can only have a formula that returns a value of datatype CHARACTER, VARCHAR, or VARCHAR2.

Definition : Level  column
On Failure:  No value is returned for the column.

Thanks Lot
Nilesh

1 comment:

Pravin M Phansekar said...

Hi Nilesh,

I am Pravin , I would be interested in taking up the Oracle Apps Technical cource.. Can you please provide me the details of the course ...

Regards,
Pravin
canso59@yahoo.com

OraApps Search

Custom Search

Search This Blog