Documente Academic
Documente Profesional
Documente Cultură
What is an API?
manipulation.
data; the API procedures are executed when they are called by other
PL/SQL modules, by a
direct SQL*Plus call, or through a front end such as the Data Pump.
systems that have used modified APIs, because HRMS data integrity
could be compromised.
that Oracle HRMS data is modified only through the call to the
delivered API.
FND_PROGRAM.EXECUTABLE ( )
FND_PROGRAM.DELETE_EXECUTABLE( )
FND_PROGRAM.REGISTER( )
FND_PROGRAM.DELETE_PROGRAM( )
FND_PROGRAM.PARAMETER( )
FND_PROGRAM.DELETE_PARAMETER( )
FND_PROGRAM.INCOMPATIBILITY( )
FND_PROGRAM.DELETE_INCOMPATIBILITY( )
FND_PROGRAM.REQUEST_GROUP( )
FND_PROGRAM.DELETE_GROUP( )
FND_PROGRAM.ADD_TO_GROUP( )
FND_PROGRAM.REMOVE_FROM_GROUP( )
FND_REQUEST.SUBMIT_REQUEST( )
FND_CONCURRENT.WAIT_FOR_REQUEST( )
FND_REQUEST.SET_PRINT_OPTIONS ( )
FND_GLOBAL.USER_IDFND_GLOBAL.APPS_INITIALIZE(user_id in number,resp_id
in number,resp_appl_id in number);
FND_GLOBAL.LOGIN_ID
FND_GLOBAL.CONC_LOGIN_ID
FND_GLOBAL.PROG_APPL_ID
FND_GLOBAL.CONC_PROGRAM_ID
FND_GLOBAL.CONC_REQUEST_ID
FND_PROFILE.PUT(name,value)
API’S IN APPS
PO
PO_CUSTOM_PRICE_PUB
PO_DOCUMENT_CONTROL_PUB
PO_DOC_MANAGER_PUB
PO_WFDS_PUB
AP
AP_NOTES_PUB
AP_WEB_AUDIT_LIST_PUB
INV
INV_COST_GROUP_PUB
INV_ITEM_CATALOG_ELEM_PUB
INV_ITEM_CATEGORY_PUB
INV_ITEM_PUB
INV_ITEM_REVISION_PUB
INV_ITEM_STATUS_PUB
INV_LOT_API_PUB
INV_MATERIAL_STATUS_PUB
INV_MOVEMENT_STATISTICS_PUB
INV_MOVE_ORDER_PUB
INV_PICK_RELEASE_PUB
INV_PICK_WAVE_PICK_CONFIRM_PUB
INV_RESERVATION_PUB
INV_SERIAL_NUMBER_PUB
INV_SHIPPING_TRANSACTION_PUB
Posted by Nil at 5:43 PM 1 comments Links to this post
Cursor lpn is
l_num_lpn varchar2(50);
begin
open lpn;
close lpn;
return(l_num_lpn);
end;
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~
V_ORG_NAME VARCHAR2(100);
begin
SELECT organization_name
INTO V_ORG_NAME
FROM org_organization_definitions
return(V_ORG_NAME);
RETURN NULL;
exception
when others then
return(null);
end;
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
uname VARCHAR2(100);
begin
return(uname);
RETURN NULL;
nd;
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~
v_Trx_quantity number;
v_lot_number number;
v_expiration_date date;
begin
Select moq.transaction_quantity
, mln.lot_number
, mln.expiration_date
into
v_Trx_quantity
, :cp_lot_number
, :cp_expiration_date
-- :cp_lot_number :=v_lot_number;
SRW.MESSAGE(021, v_Trx_quantity );
SRW.MESSAGE(022, :cp_lot_number );
SRW.MESSAGE(023, :cp_expiration_date );
return(v_Trx_quantity);
exception
return(null);
SRW.MESSAGE(024,'Error out!!!' );
end;
Posted by Nil at 5:03 PM 0 comments Links to this post
Syantax :
CREATE MATERIALIZED VIEW schema.name
PCTFREE integer
PCTUSED integer
TABLESPACE tablespace_name
BUILD IMMEDIATE
INITRANS integer
STORAGE CLAUSE
AS (SQL statement);
Posted by Nil at 4:59 PM 0 comments Links to this post
Apr 1, 2010
Advance SQL Queries....
1. Query for finding the nth maximum salary ?
Select distinct a.sal from emp a where (&n-1) = (select count (unique sal ) from
emp b where b.sal > a.sal)
Select a.sal from emp1 a where (&n-1) = (select count (unique sal) from emp1 b
where b.sal < a.sal)
Select empno from emp where sal = (select max(sal) from emp where sal <>
(select max(sal) from emp));
Select sum(x.sal) from emp1 x, emp1 y where y.rowid >= x.rowed group by y.row
order by sum(x.sal)
Select * from emp where rowed not in (select empno, ename from emp where
(empno,rownum) in (select empno,mod(rownum,2) from emp));
12. Query to delete duplicate rows by leaving one row deleted on specific
condition ?
Delete from emp where deptno = 10 and rowid not in (select min(rowid) from emp
where deptno = 10);
13. Query to delete duplicate rows but leaving one row undeleted ?
Delete from emp where deptno = 10 and rowid not in (select min(rowid) from emp
where deptno = x.deptno);
14. Query to select all columns, rowid with out specifying the column name
?
Report trigger must explicitly return TRUE or FALSE. The following table describe what happens when the report trigger returns FALSE.
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.
• 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).
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., ",").
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.
SQL*loader is one of the Oracle tool which will be used to transfer the data
from Flat-File to oracle Database table.
We can find the fallowing files in SQL*loader
1. Flat or Data File
2. Control File
3. Bad File
4. Discard File
5. Log File
Flat Or Data File: This file contains the records in a special format; these
records will be fetching for other legacy. The extension of these files might
be .dat, .txt, or .csv (comma separated view).
Control File: This is SQL loader execution file, which will be used to transfer
the date from file to table. In side of these control file, we will mention the
Data file path, table name, column mapping. The extension of control file is
.ctl
Control File Creation:
Load data
INFILE ‘Data File Path’
INSERT INTO ‘Table Name’
FIELD TERMINATED BY ‘,’
WHERE deptno = 10
TRAILING NULL COLS(column1 , empno
column2, ename
column3, deptno)
Once we develop the control file we will execute this by using fallowing
command
C:\> sqlldr user/passward @ Database Control = name of control file (with
extension .ctl)This command will start the control file execution, and it will
try to read the data and inserting into table. After completion of this
execution, automatically three files will gets created
Bad file
Discard file
Log file
Bad File: Bad file contain the records, which are rejected by the SQL*loader.
SQL*loader will reject the records, when ever the Flat file format is not correct
or if any internal error occurs it will rejected. The extension of bad file is .bad
Discard File: Discard file contains the records which are rejected by the
control file, control file reject the records, if record is not satisfying the
conditions, which we have mentioned inside of control files the extension of
discard file is .dis
INSERT: When we are using this statement, table should be empty. SQL *
loader will insert the new data form the file.
APPEND: This mode will be use to attach the new record to the existing
records.
REPLACE: This will replace the existing records with new records.
C:\> sqlldr userid/passward@Database control=text1.ctl path=direct
SQL* Loader Paths: We can execution SQL* loader in two paths or nodes
Direct
Conventional
By default SQL*loader will be running in conventional mode, if we want to run
in direct mode will use the fallowing syntax
C:\> sqlldr userid/passward@Database control=text1.ctl path=direct
Direct mode will disable the table and column constrains and it will insert the
data.
Conventional path will check every constrains, if it is satisfied it will insert the
record
Conventional path is just like ‘insert statement’
SQL Commands Limitations:
to_date, to_char, upper, lower, Initcap, string, decode, nvl
when clause
sequence_name.next_value, Ref-Cursor
sysdate, ltrim, rtrim, constant
Posted by Nil at 4:29 PM 0 comments Links to this post
Labels: Concurrent programming, Working with SQL Loader
Syntax:
CREATE OR REPLACE PROCEDURE Procedure_Name
(errbuf OUT VARCHAR2,
recoded IN VARCHAR2,
x IN NUMBER,
y IN NUMBER) AS
BEGIN
PL/SQL statements;
Fnd_file.put_line (fnd_file.output, ’message’variables);
Fnd_file.put.line (fnd_file.log, ’message’variables);
END ;
ERRBUF: Used to get the error messages in to the log file if any errors occur in
side of procedure.
RETCODE: Used to get the status of Concurrent Program
Inside of procedure body we can use all valid PL/SQL statements except
DBMS_OTUPUT.PUT_LINE Instead of this we will use fallowing to API’S
(Application Programming Interface).
API is nothing but a package.
• Fnd_file.put_line(fnd_file.output,’message’variables); - is write for the
output file.
• Fnd_file.put.line(fnd_file.log,’message’variables); - is used for log file.
Prompt *****************************
Prompt This is SQL* Plus Script
Prompt *****************************
Range:
When ever we have to restrict the user with in the given values we use Range.
For example when ever our parameter is having “From Date and To Date” we
have to use Range option to restrict the user to enter the values between Low
and High.
Note:
Pre defined value set for date is “FND_DATE” and its default format is “DD-
MON-YY”.Alias name is mandatory when we are specifying ‘:$FLEX$’ and
Column Name in ‘Additional Column’.
Posted by Nil at 3:05 PM 0 comments Links to this post
Labels: Value Sets
Jul 22, 2008
What is Value Sets? What are Types Of
Value Sets?
Oracle Application Object Library uses values; value sets and validation
tables as important components of key FLEXFIELDs, descriptive FLEXFIELDs, and
Standard Request Submission. This section helps you understand, use and
change values, value sets, and validation tables. When you first define your
FLEXFIELDs, you choose how many segments you want to use and what order
you want them to appear. You also choose how you want to validate each of
your segments. The decisions you make affect how you define your value sets
and your values. You define your value sets first, either before or while you
define your FLEXFIELD segment structures. You typically define your individual
values only after your FLEXFIELD has been completely defined (and frozen and
compiled). Depending on what type of value set you use, you may not need to
predefine individual values at all before you can use your FLEXFIELD.
You can share value sets among segments in different FLEXFIELDs, segments in
different structures of the same FLEXFIELD, and even segments within the
same FLEXFIELD structure. You can share value sets across key and descriptive
FLEXFIELDs. You can also use value sets for report parameters for your reports
that use the Standard Request Submission feature.
Because the conditions you specify for your value sets determine what values
you can use with them, you should plan both your values and your value sets at
the same time. For example, if your values are 01, 02 instead of 1, 2, you
would define the value set with Right–Justify Zero–fill set to Yes.
Value set is nothing but List of Values with validations. We can use the Value
Sets when ever the Concurrent Program has parameters and while defining the
Flex Fields. We have to attach the value sets to the Concurrent Program.
Validations are depending on Client Requirement.
Value sets are of 8 types.There are several validation types that affect the
way users enter and use segment or parameter values:
1. None (not validated at all)
2. Independent
3. Dependent
4. Table
5. Special (advanced)
6. Pair (advanced)
7. Translatable Independent
8. Translatable Dependent
You cannot change the validation type of an existing value set, since your
changes affect all FLEXFIELDs and report parameters that use the same value
set.
None: You use a None type value set when you want to allow users to enter any
value so long as that value meets the value set formatting rules. That is, the
value must not exceed the maximum length you define for your value set, and
it must meet any format requirements for that value set. For example, if the
value set does not allow alphabetic characters, your user could not enter the
value ABC, but could enter the value 456 (for a value set with maximum length
of three). The values of the segment using this value set are not otherwise
validated, and they do not have descriptions. Because a NONE value set is not
validated, a segment that uses this value set does not provide a list of values
for your users. A segment that uses this value set (that is, a non–validated
segment) cannot use FLEXFIELD value security rules to restrict the values a user
can enter.
Independent > An Independent value set provides a predefined list of values
for a segment. These values can have an associated description. For example,
the value 01 could have a description of ‘Company 01’. The meaning of a value
in this value set does not depend on the value of any other segment.
Independent values are stored in an Oracle Application Object Library table.
You define independent values using an Oracle Applications window, Segment
Values.
Table > A table–validated value set provides a predefined list of values like an
independent set, but its values are stored in an application table. You define
which table you want to use, along with a WHERE cause to limit the values you
want to use for your set. Typically, you use a table–validated set when you
have a table whose values are already maintained in an application table (for
example, a table of vendor names maintained by a Define Vendors form). Table
validation also provides some advanced features such as allowing a segment to
depend upon multiple prior segments in the same structure.
It will ask the Database connection. Provide User id, Password and Connection
string (DB host) – APPS/APPS@ORCL.
Prompt: This field will use to display the string while submitting the
Concurrent Program in the Parameter Form.
Token: It is a field which is use to give the link between Concurrent Program
Parameter and report Bind Variable. When we create Bind Variables in report
those may or may not be in the same sequence. So we can map these bind
Variable with the Token fields.
Required Check Box: If we uncheck this, the parameter is optional, otherwise
it is mandatory.
Default Types: There are 4 default types.
· Constant
· Profile
· SQL Statement
· Segment
Constant: We can select this default type if we have to pass the constant value
to parameter of the Concurrent Program. We can mention the value in the
“Default Value Field” at right side.
Profile:
SQL Statement: If we have to set the default value as SQL Query result set
then we should select default value type is SQL Statement and we have to
enter the SQL Query in the ”Default Value field”.
Segment: If we want to get previous parameter value as default to the next
parameter, we have to select the default type as Segment and we have to give
the previous parameter name in “Default Value Field”.
Note: The query which we have to enter in default value field should give only
one value
Using the format trigger we can hide or display the “Layout Object”. This
layout object can be a Field or Text.
We can display input parameter values in the first page (or any other pages) by
using Bind Variables.