Beruflich Dokumente
Kultur Dokumente
Overview
An Application User is an authorized user of the Oracle Applications and/or Self-Service Web Applications
(OSSWA). A user is uniquely identified by an application username. Use the System Administrator Responsibility
to define users.
Define User
Navigate to: Security > User > Define
Tip: Tab through the fields when completing this form and watch the status bar for field specific prompts
User Name: Enter the name of an application user. An application user enters this
username to sign on to Oracle Applications and/or Oracle Self-Service
Web Applications. The following guidelines apply to this field:
Can only be one word
Define a standard naming convention such as first initial, last name.
User name is always in Upper Case
Alphanumeric ('A' through 'Z') and Numeric ('0' through '9') are
permitted.
Description: Enter a description for this user. Enter a user friendly name as
description e.g. Jane Doe.
Tip: You may also enter html tags in this field to format how the users
name is displayed, for example, entering <font color=red>Jane
Doe</font>, will display the users name in red on the OSSWA home
page.
Password: Enter the initial password of an application user. The user will be
prompted to change this password the first time they sign in. The
following guidelines apply to this field:
Must be at least 5 characters and no more than 100.
Alphanumeric ('A' through 'Z') and Numeric ('0' through '9') are
permitted.
Note: You will need to enter this field twice for verification
Person: If this user is an employee select the employee's full name from the LOV.
Customer: If this user is a customer select the customer's name from the LOV.
Supplier: If this user is a supplier select the supplier's name from the LOV.
E-Mail: Optionally enter the email address for this user.
Fax: Optionally enter the fax number for this user.
Password Expiration> Maximum number of days between password changes.
Days:
Password Expiration> Maximum allowed number of sign-ons to Oracle Applications or Self-
Accesses: Service Web Applications allowed between password changes.
Password Expiration> Select none if you do not wish to have passwords expire by number of
None: days or accesses.
Effective Dates>From: Optionally enter a start date when this user can begin accessing the
applications.
Effective Dates>To: Optionally enter an end date when this user can no longer access the
applications.
Responsibility: Select a responsibility you wish to assign this user.
Note: In order for a user to access the applications they must be assigned
at least one responsibility. Once a user is assigned to a responsibility it
cannot be deleted, therefore, you must deactivate the responsibility by
entering an end date. If you want to reactivate a deactivated
responsibility for a user change the end date to a date after the current
date or highlight the current end date and delete.
Responsibility> Optionally enter a start date when this user can begin accessing the
Effective Dates>From: applications with this responsibility.
Responsibility> Optionally enter an end date when this user can no longer access the
Effective Dates>To: applications with this responsibility.
Securing Attributes
Securing Attributes are used by the Oracle Self-Service Web Applications. Securing Attributes allow rows of data to
be visible to specified users or responsibilities based on the values contained in the row. Securing Attributes must
be assigned at both the user and responsibility level.
Example: If you want to restrict the user Jane with responsibility of 'Admin' to see only those rows where
customer_id = 1000 then assign the securing attribute ICX_CUSTOMER_ID to the responsibility 'Admin' then the
securing attribute ICX_CUSTOMER_ID and value of 1000 to the user, Jane.
Excluding Attributes
Excluding Attributes are used by the Oracle Self-Service Web Applications and are defined at the responsibility
level. Please refer to the AOL Application Responsibilities Training.doc
Note: Once assigned a responsibility, a user is excluded from any columns defined as excluding attributes for that
responsibility.
Responsibilities
A responsibility is a level of authority that determines the specific data users can access and the specific menu they
see. Each application user must be assigned to at least one responsibility and several users can share several
responsibilities. Responsibilities cannot be deleted. Use the Effective Dates>To field to disable a responsibility.
Use the System Administrator Responsibility to define responsibilities.
Define Responsibility
Navigate to: Security>Responsibility>Define
Responsibility Name: Enter an intuitive, unique name for the responsibility you are defining.
Application: Select the name of the application you wish to associate with the
responsibility from the LOV.
Note: This name does not preclude the user of this responsibility from
accessing other applications forms and functions if they are defined in
the responsibilitys menu.
Responsibility Key: Enter a unique name for this responsibility to be used by loader
programs.
Description: Enter a user-friendly description for the responsibility
Effective Dates>From: Enter the start date on which this responsibility becomes active.
Effective Dates>To: Optionally enter the end date on which this responsibility becomes
inactive.
Example: You want the Payable Clerk to select invoices for payment, and print a Preliminary Payment Register but
you do not want the Clerk to format payments or print the checks immediately.
Solution: In order to restrict the options that the Payables Clerk can perform when generating a check run, simply
exclude the SUBFUNCTIONS the Clerk should not be able to perform (such as Payment Batches Confirm, Payment
Batches Format, Payment Batches Print) from his/her responsibility. In the 'Define Responsibility' form, query the
clerks current responsibility and in the Function and Menu Exclusions block, choose a type of Function, and in the
LOV choose the subfunctions mentioned above. The next time the clerk signs into AP, he/she will be restricted to
only select, build, print payment registers, etc. outside of the subfunction exclusions.
Menu Exclusions> Type: Select Menu to exclude all menu entries, functions, and sub-menus
from the responsibility.
OR
Select function to exclude all occurrences of that function from the
responsibility
Menu Exclusions> Select the name of the function or menu to exclude from the
Name: responsibility.
Securing Attributes
Securing Attributes are used by the Oracle Self-Service Web Applications. Securing Attributes allow rows of data to
be visible to specified users or responsibilities based on the values contained in the row. Securing Attributes must
be assigned at both the user and responsibility level.
Example: If you want to restrict the user Jane with responsibility of 'Admin' to see only those rows where
customer_id = 1000 then assign the securing attribute ICX_CUSTOMER_ID to the responsibility 'Admin' then the
securing attribute ICX_CUSTOMER_ID and value of 1000 to the user, Jane.
Securing Attributes> Select an attribute from the LOV to be used to determine which records
Attributes: this user can access.
Excluding Attributes
Excluding Attributes allow columns of data to be visible to specified users or responsibilities. Excluding Attributes
must be assigned at the responsibility level.
Example: If you want to restrict the user Jane with responsibility of 'Admin' from seeing prices in the ICX_PRICE
column, then assign the excluding attribute ICX_PRICE to the responsibility 'Admin'.
Excluded Items> Name: Select an attribute from the LOV to be excluded from the users access.
Responsibility Level: Used to control access to reports, request sets, and concurrent programs for a particular
responsibility. A request group assigned to a responsibility is referred to as a Request Security Group. A request
security group is a collection of requests, request sets, and concurrent programs that users who have been
assigned a given responsibility can run.
Form Level: A request group is assigned a code, which is passed as a parameter to the Submit Requests
Window. The code helps define the function that calls the Submit Requests Window.
Note: Form Level Security Groups are not covered in this document at this time.
Define Request Group (Responsibility Level)
Value Set Name: Enter a unique name for this value set.
None: Values are not validated. Users will not have a list of values to
select from if you choose this validation type.
Table: This validation type is a table-validated value set with a
predefined list of values from an application table. You can limit the
values included in a table-validated value set by using a WHERE
clause.
Special: This validation type allows for a 'flexfield-within-a-flexfield'
functionality. It is primarily used for Standard Report Submission
parameters using validation routines you define to provide another
flexfield as a value set for a single segment.
Pair: This validation type is similar to a Special validation type
allowing 'flexfield-within-a-flexfield' functionality. It is used for
Standard Report Submission parameters using validation routines
you define to provide a range flexfield as a value set for a pair of
segments
Independent: This validation type provides a predefined list of
values for a segment.
Dependent: A dependent value set is similar to an independent
value set except that the values available depend on the independent
value chosen in a prior segment.
Translatable Independent: Similar to an independent value set
except the value may be translated.
Translatable Dependent: Similar to a dependent value set except the
value may be translated.
Note: Always define independent value set before dependent value set.
Table Application: From the LOV select the application that the validation table belongs to.
Note: If you are going to display columns from more than one table in
your LOV, you should leave this field blank.
Table Name: Enter the table you want to use to validate your value set. If you plan to
display columns from more than one table then enter multiple tables in
this field separated by commas. If you want to use table aliases then
enter them here.
Example: ra_customers rac, ra_addresses_all raa
Note: If you want to use a custom table then you must do the following
prior to navigating to this form:
Create the validation table in the database
Register the table with the Oracle Application Object Library
Create the necessary grants and synonyms.
Allow Parent Values: Select this option if you want to allow parent values.
Value Name: Enter the name of the column in your validation table that contains the
values you want to use to validate a value entered for a segment or
report parameter. You can also use a SQL expression in place of a column
name but you cannot use bind variables.
Note: If you specified a format type of Number then you can only specify
columns that have been defined as a Number or Char format. For a
format type of Date you can only specify columns of type Date and Char,
for a format type of Char you can only specify columns of type Char.
Value Type: This field will be automatically populated with the data type of the
column you selected. If you use a SQL expression in place of a column
name then you must select the value type you expect the expression to
return.
Size: This field will be automatically populated with the size of the column
you selected. If you use a SQL expression in place of a column name then
you must select the value type you expect the expression to return.
Meaning Name: Enter the name of the column in your validation table that contains
descriptions for your values. If you leave this field blank, the value set
automatically uses the value column as the description but leaves this
field blank.
ID Name: Enter a name of the column in your validation table that contains values
you want to use to validate a value but that you do not want to display.
Note: If you select a column other than the value name selected above
the report parameter window passes this value to your report. For
flexfields this value is stored in your segment column rather than the
value name identified above.
Where/Order By: Enter a SQL WHERE clause and/or an ORDER BY clause. You can use
special bind variables here:
:$FLEX$.Value_Set_Name
:block.field (used for backward compatibility only)
:$PROFILE$.profile_option_name
Additional Columns: Enter any additional columns you want displayed for a segment that
uses this value set.
Special/Pair Validation
Create special validation routines for value sets of type Special or Pair.
Edit: Calls the special validation routine when your user's cursor
enters the segment in a data entry mode.
Validate: Calls the special validation routine when the user's cursor
leaves the segment or closes the pop-up window, or when a default
value is copied into the segment or report parameter. It also fires after
a query to generate value descriptions for queried values.
Load: Calls the special validation routine immediately after a query
to populate your segment.
Note: The following events are present in Oracle Applications for
compatibility with future versions, and you should not use them.
Insert/Update
Query
Edit/Edit
ListVal
Function: Enter your user exit syntax exactly as you would call it from a form
trigger, except you do not need to include the # sign.
Dependent Validation
Associate your dependent value set with an independent value set
Note: You must define independent values before related dependent values.
Name: The name of your Independent value set will appear here.
Dependent Value Set: Leave blank
Independent Value: Leave blank
Value: Enter the values you want to assign to this independent value set.
Description: Enter a description for this value.
Enabled: Select this option to enable the value. Values cannot be deleted so if you
do not want users to select this value any longer then deselect this option
or enter an end date.
Effective From: Optionally enter a start date for when this value becomes active.
Effective To: Optionally enter an end date for when this value becomes no longer
active.
Naming Standards
File Names and Extensions
File names must not exceed 8 characters and the first three letters represent the Module Name.
In the file name wherever English alphabet letters are used they should be in UPPERCASE.
File Name should not contain any special characters i.e. , -, $, %, #, @, * and others.
Program Type Directory File Type Extension
PL/SQL sql Package specification Pks
Package body Pkb
SQL*Plus sql SQL script Sql
Spool file Lst
install/sql Install script Sql
SQL*Loader bin Control file Ctl
Data file Dat
Log file Log
Error file Err
Discard file Dis
UNIX bin Shell Script Sh
SQL*Forms 4.5 or 6.0 forms Binary Fmb
Executable Fmx
Source Fms
SQL*Forms 2.3 or 2.4 forms Executable Frm
Source Inp
Oracle Reports 2.0, 2.5 or 6.0 srw Binary Rdf
Executable Rpt
Source Rex
Please note the custom objects need to be prefixed with the following to clearly define the module:-
CFI Financial
CMF Manufacturing
CSA Sales Administration
CCO Conversion
For a given design, there will be one and only one MOD number -even though it may contain package
procedures, SQL scripts, SQL*forms and Oracle Reports. MOD numbers must be unique across modules.
Nomenclature
Module Prefix + Mod Number
Example
CFI0001 Mod 1 is for Finance
CMF0002 Mod 2 is for Manufacturing
CSA0003 Mod 3 is for Sales Administration
CMF0004 Mod 4 is for Manufacturing
A MOD may have multiple objects of the same type, therefore suffix the object with an English letter
(A through Z).
Nomenclature
Module Prefix + Mod Number + Letter
A database schema can be composed of various objects i.e. tables, indexes, sequences, views, synonyms,
procedures, triggers, packages, functions and database links. Please ensure the following naming
convention is followed:
Object name can be a maximum of 30 characters long. Please reserve the first three characters to identify the
application. The naming convention should facilitate in distinguishing the objects. The norm to adopt is as
follows:
Object Type Standard Meaning Example
Table 30 characters long CSA_SO_HEADERS
Index Xn X=(U)nique or (N)on-Unique CSA_SO_HEADERS_U1
n=Index Sequence Number
View V V = View CSA_SO_HEADERS_V
Sequence S S = Seqeunce CSA_SO_HEADERS_S
Trigger XIUD_TRG X=(B)efore or (A)fter CSA_SO_HDRS_BIU_TRG
I=Insert/U=Update/D=Delete
TRG=Trigger
Package PK or PB PK=Package Specification CSA_SO_HDS_PK
PB=Package Body CSA_SO_HDS_PB
Function FNS FNS=Functon CSA_SO_HDS_FNS
Object name should not contain any special characters i.e. , -, $, %, #, @, * and others.
Object name should begin with an alphabetic character and may contain underscore.
Object name nomenclature should be self explanatory, having a meaningful name that is understandable
by the end users and IS groups.
Table
The sequential order in which the columns need to be defined are:
Primary key columns
WHO columns
Mandatory columns
Optional columns
Long field column
To be created under the Custom Schema, with necessary grants to APPS schema
The table name should be plural.
Use the constraint/default definitions and referential integrity definitions for the columns of the table.
Ensure that the columns are classified as NULL or NOT NULL. By default the column definition is
NULL.
Ensure that the WHO columns (CREATED_BY, CREATION_DATE, LAST_UPDATED_BY,
UPDATE_DATE, LAST_UPDATE_LOGIN, REQUEST_ID) exist.
If the data to be stored in the table is partitioned on the Operating unit then a ORG_ID column with the
default definition must exist.
Ensure that a primary key exists with a NUMBER data type.
Use the following data types to qualify a column in a table VARCHAR2, NUMBER, DATE, BOOLEAN,
LONG.
Whenever appropriate qualify the column definition to denote its purpose i.e.
_FLAG
_CODE
_TYPE
_DATE
_NAME
_ID
_VALUE
View
View on a partitioned table needs to be created in the APPS schema. Use the WHERE CLAUSE within
the view definition to dynamically partition the data on user access.
Package Procedures/Triggers/Functions
Package Procedures/Triggers/Functions to be created in the APPS schema.
Variable declarations
Variable to have a meaningful name and to be initcap. Variable to be prefixed with v
vOrderNumber
vOrganizationId
vInventoryItemId
Variable data type declaration to be associated to appropriate schema.object.field
vOrganizationId mtl_system_items.organzition_id%TYPE;
vInventoryItemId mtl_system_items.inventory_item_id%TYPE;
Cursor Definitions
Cursor to refer to object name(s) on which it is defined and to be initcap. Cursor to be prefixed with
Cur
Use aliases to uniquely identify the fields
CURSOR CurSoHdrLns IS
SELECT a.order_number order_number,
b.inventory_item_id inventory_item_id
b.warehouse_id warehouse_id
FROM so_lines a
so_headers b
WHERE a.header_id = b.header_id;
Ensure the driving table in all SELECT statements is last in the FROM clause
Ensure for every OPEN CURSOR statement there is a corresponding CLOSE CURSOR statement.
Wherever possible use FOR Record in Cursor LOOP rather than OPEN CURSOR statement
In order to debug the PL/SQL package use the DBMS_OUTPUT routine. You may need to SET
SERVEROUTPUT ON SIZE 1000000 to generate the output. Note the output is generated after the
package completes or terminates with an error. For a given session the DBMS_OUTPUT buffer is not
cleared. Do not use the routine to generate flat files or reports.
Do not include explicit commits within the package. In case the package requires processing of records
that can create rollback segment problem, please put commits at logical transaction points with
SAVEPOINT and ROLLBACK functions.
The PL/SQL design to take into account how to re-commence a terminated job, and not re-process the
processed records unless there is an explicit requirement.
Latest version provides a facility to output to a flat file
Instead of incorporating the programming logic in the Trigger or an Alert it is better to write the logic as
a package procedure. The advantage is the package is compiled, parsed and stored in the database and
therefore it requires primarily to fetch and execute.
Exception Handling
Ensure that at least the following exceptions are handled in the PL/SQL constructs
NO_DATA_FOUND
TOO_MANY_ROWS
OTHERS
The error number must contain the mod number + the sequence of exception.
Please use the ERRBUF and ERRCODE parameters as an output. They must be the first two parameters
in the PL/SQL package
It is advisable to maintain a central repository/library of PL/SQL packages with the small description. This
library may comprise packages called from different routines. You need to ensure nobody modifies the
shared package procedure. Also if time permits the packages may be defined and developed to be generic
in nature, which will enhance the library.
Ensure all BUTTONS in Oracle Application look and behave the same
Ensure all BUTTONS in Oracle Application use BUTTON Property Class
Define Property Class and include in the Object Group
Apply the Property Class to objects to ensure uniformity in the functionality and visual appearance
Build forms based on the View definitions. The first column in the view should be the ROWID and be
given the alias name of ROW_ID.
De-normalize the Foreign Key references by building views, this will avoid network traffic and make the
PRE-QUERY and POST-QUERY triggers to populate the non-database fields redundant
In order to insert/update/delete call the ON-INSERT, ON-UPDATE, ON-DELETE, ON-LOCK triggers
to access the base table rather than the view
Correction and enhancements on view will be at the server level rather than in several source code
which may or may not reside on the server
Do not use the ROOT_WINDOW, as it affects the toolbar functionality
When defining the MODAL WINDOW (e.g. dialog box) code the logic for OK and CANCEL
buttons in advance. If not done, as the key triggers and menu is disabled on invoking the modal
window, there will be no way to exit the form.
Modify the template procedures APP_CUSTOM.OPEN_WINDOW or
APP_CUSTOM.CLOSE_WINDOW to meet the requirements on opening or closing a form
Try writing package procedure and store in the server. Number of procedures to a package
recommended by Oracle to be less than 25
While referencing a field on the form qualify it with the block name :BLOCK_NAME.FIELD_NAME
Use explicit cursors in triggers and handle all possible exceptions
Use RAISE_FORM_TRIGGER_FAILURE to stop processing at the client level
Use APP_EXCEPTION.RAISE_EXCEPTION to stop processing at the server level
CALL_FORM routine is in-compatible with OPEN_FORM
To exit Oracle Application suite, copy Y to GLOBAL.APPCORE_EXIT_FLAG, and then call the
DO_KEY_EXIT_FORM
Use APP_ITEM_PROPERTY.SET_PROPERTY and APP_ITEM_PROPERTY.SET_VISUAL_ATTRIBUTE
to get the Oracle Application standard behavior
Use APP_ITEM_PROPERTY.GET_PROPERTY to get Oracle Application specific property
Replace OPEN_FORM with FND_FUNCTION.EXECUTE as security depends on the latter
Replace CLEAR_FORM with DO_KEY(CLEAR_FORM) as the latter raises the
FORM_TRIGGER_FAILURE if there is an invalid record
Replace COMMIT with DO_KEY(COMMIT_FORM) as the latter raises the FORM_TRIGGER_FAILURE
if there is an invalid record
Replace EDIT_FIELD/EDIT_TEXTITEM with DO_KEY(EDIT_FIELD) as the latter raises the calendar
when the current item is a DATE
Extensive comments are recommended
Triggers that can be modified, but do not delete the APP_STANDARD.EVENT call within the respective
triggers
KEY-CLRFRM
POST-FORM
QUERY-FIND
ACCEPT
SQL*Loader
The basic SQLLOAD command is
SQLLOAD
USERID = Oracle Username/password
CONTROL = Control file name
LOG = Log file name
BAD = Bad file name
DATA = Data file name
DISCARD = Discard file name
DISCARDMAX = Number of discard allowed default is ALL
SKIP = Number of records to skip default is 0
LOAD = Number of records to load default is ALL
ERRORS = Number of errors allowed default is 50
SILENT = Suppress messages during run
CONCATENATE
CONTINUEIF
Generating Data
The data may be generated and inserted into the table column by calling one of the functions within the
SQL*Loader script CONTROL file:-
CONSTANT - set the column to a constant value. Do not use to assign NULL to a column. To set a
column to NULL do not specify the column
RECNUM - sets the column with the logical record number from the load. The initial value from a new
load is 1. If the Option SKIP is used then the RECNUM begins with SKIP+1 as the initial value
SYSDATE - sets the column to system date. The CHAR column only stores the date whereas the DATE
column stores date and time
SEQUENCE - Ensures a unique value for a column. Please note that sequence increases for loaded or
rejected records but does not increase for the discarded or skipped records
DEFAULTIF use the keyword to set the column to zero when specified field test condition is TRUE
NULLIF use the keyword to set the column to null if when the specified field test condition is TRUE
To refer to the field name preceed the field name with a colon (:)
SQL string to be enclosed in double quotes
SQL string is evaluated after the NULLIF and DEFAULTIF clause but before the DATE format mask
SQL strings may not be used on RECNUM, SEQUENCE, CONSTANT, SYSDATE fields
SQL operators that may be used include
LOWER
RTRIM
LTRIM
TRANSLATE
DECODE
SUBSTR
TRUNC
NVL
TO_DATE
TO_CHAR
Concurrent Executable/Programs
Same as execution file name in uppercase.
Example: CFI0001a
DefineConcurrent Program
Name must have INITCAP i.e. all words must have the first letter in upper case. The name must contain
the prefix to identify the module.
Example: CFI AP Invoice Print
Short Name must be the same as the executable name. If the same executable is being used for more than one
concurrent program, then use underscore and number as suffix.
Example: CFI0001a_1
CFI0001a_2
A set of customizations for one or more products is installed as an application. Thus it has a product directory and
an Oracle user account.
Directory Structure
The directory structure for an installed product is as follows:
$APPL_TOP
|
<product short name>
|
<product version>
___________________________ |___________________________
| | | | | | | | |
admin bin conversions forms log out reports sql wf
| |
_________________________ ______
| | | | | | |
aropen coa customers fa pricelist wft sql
The product short name is a two to eight character abbreviation of the product (i.e. GL, PO, INV, etc.). The short
name for Rapid Oracle Implementation custom applications will be (CUSTOM NAME).
The product version subdirectory level allows multiple versions of a product to be available within a single
Applications installation. The naming convention is <major version>.<minor version>.<patch level> (i.e. 4.1.0). The
standard is to begin with 1.0.0 for a new product regardless of the general release number or Oracle Applications.
Custom Tables
New tables required by your custom programs should be created in an Oracle user created exclusively for
customizations. For convenience, it should match the application short name of your custom application
((CUSTOM NAME)). Grants and synonyms will allow other Oracle users to access your custom tables.
To access custom forms exclusively, you must register the custom Oracle ID (CUSTOM NAME) in the Application
Object Library. If custom forms will be accessed from responsibilities that also access standard forms, simply create
grants and synonyms so that the Oracle user associated with the responsibility can access the custom tables.
Your Development Account
The development account will be given the username of (CUSTOM NAME) to conform to (CUSTOM NAME)
standards. While individual programmers and analysts may own code in development, the UNIX (CUSTOM
NAME) account will be the owner of all completed custom code.
Custom development should be done within a Korn shell with Korn shell scripts and PL/SQL scripts being the
tools of choice for data processing.
You should develop and test custom modules under the $(CUSTOM NAME)_TOP portion of the directory tree. If
they have not been previously created, you may have to create the directories: admin, bin, conversions, forms, log,
out, reports, sql, and wf (log and out can be soft links to the actual log and out directories).
When modifying or creating forms, it is not necessary to save them to the database. Instead use the LOAD and
GENERATE options of SQL*Forms 6.0 to read and write the source code file directly. Also, your form cannot be
saved to the database when you register it with Application Object Library.
Any text editor can be used for C programs, SQL*Plus, and PLSQL programs. The vi editor will be used because it
comes standard with UNIX.
Procedure:
To create the work tables required in the customization process under Oracle ID (CUSTOM NAME). The naming
convention described in the naming convention standards section of this document should be followed. All custom
objects should be moved to the custom $(CUSTOM NAME)_TOP directory. There are sub-directories for all of the
object types.
All custom objects i.e. tables, menus, reports, forms, views, and sequences should be registered under '(CUSTOM
NAME) Custom Application' application name. This is done for Database and Form objects through the
Application Developer Responsibility.
Custom reports will appear in the Application in the same screen as the Standard reports, but the code will reside
in $(CUSTOM NAME)_TOP directory. When a existing standard report requires modification, a clone of the report
should be made. The new report should then be renamed with a (CUSTOM NAME) - naming convention. The
(CUSTOM NAME) title will help identify the report as custom report.
2. Register the program under the '(CUSTOM NAME) Custom Application' application.
1. Add the modified or custom program to a request group. See the document AOL
Request Groups Setup for additional information.
The output of the report and the log will be created in the regular application's $OUT and $LOG directory.
Option 1 is preferred because it reduces the number of synonyms and grants that need to be established.
Option 1:
To execute a custom form, report, or concurrent program from the standard oracle applications it is necessary to
assign the application name '(CUSTOM NAME) Custom Application' to the custom form, report, or program.
Synonyms need to be created under the particular standard Oracle ID to allow access to the (CUSTOM NAME)
Custom Application objects. Grants need to be created under the applications (CUSTOM NAME) Custom
Application ID to allow access to the specific standard Oracle ID.
R2i Custom Application Standard Oracle Applications
Register Tables,
Create synonyms for
Views, Sequences
the objects created
Forms, Reports and
under oracle Id R2I
Concurrent Programs
Option 2:
To execute customized code from the (CUSTOM NAME) Custom Application,
Synonyms need to be created under the applications (CUSTOM NAME) Custom
Application ID to allow access to the specific standard Oracle objects. Grants need to
be created under the particular standard Oracle ID to allow access to the (CUSTOM
NAME) Custom Application ID.
R2i Custom Application Standard Oracle Applications
Register Tables,
Views, Sequences
Forms, Reports and
Standard Oracle
Concurrent Programs
Applications
Create different
Responsibility for each
application in which
customization is done
Naming Standards
A database schema can be composed of a variety of structures, generically referred to as objects.
The term "objects" as used in this document, refers to any of a variety of user defined structures within the database
such as, tables, views, synonyms, indexes, stored procedures, etc.
General Rules for Object Naming
The following set of rules apply broadly to all objects within the database. Specific types of objects may have
additional limitations imposed, but should share these common characteristics. In addition, Appendix "A" of this
document provides a list of standard abbreviations to be used whenever it is necessary to use abbreviations in an
object name.
Be named using the plural form representing the notion of a set or collection -- e.g. USER_CONFIGURATIONS
not USER_CONFIGURATION
Begin with a unique application prefix of the form (CUSTOM NAME)_ to clearly
define and designate custom in-house tables or applications.
Be named using the singular form representing the notion of a single member of the set or collection representing
the table. e.g. CUSTOMER_NAME not CUSTOMER_NAMES.
Be consistent between tables clearly representing the keys to be joined and the
consistency of the values to be used.
Not use table name prefixes except for special circumstances. e.g.
CUSTOMER_NAME not CM_CUSTOMER_NAME for the column contained in the
customer master table.
Use table name prefixes when part of the primary key. e.g. For an ID column in the
CUSTOMERS table use CUSTOMER_ID.
Use table name prefixes to allow proper foreign key relationships to maintain the
same name. e.g. This allows the use of the name CUSTOMER_ID in the ORDERS
table which may also contain an ID column of its own.
Another frequently used example is the use of flags. A flag column contains a simple Y/N character value use the
domain suffix flag to represent this type of item. For example, a shipment confirmation flag containing either a 'Y'
or an 'N' would be named SHIP_CONFIRM_FLAG.
_FLAG _CODE
_TYPE _DATE
_NAME _OWNER
_VALUE
Coding Standards
Specific coding and testing standards are well documented in other Oracle documentation. I have chosen not to
duplicate that information here. However, here are some major points to remember:
Use modular coding techniques
Use comments extensively. Always think about someone else reading your code.
Select a style for indentation, variable names, etc. and use it consistently.
Include meaningful error messages when your program encounters an exception
condition.
In spite of the use of REM in the following sample templates, /* and */ should be
used whenever possible to delineate comments.
Command syntax and keywords such as SELECT...FROM...WHERE should be
capitalized. Variable names should be in lower case. Comments should be in mixed
case. For example:
/* Test Code */
SELECT table_name
FROM user_synonyms
WHERE synonym_name like INV_%;
Using Templates
Establishing templates for common types of programs is a good way to standardize. Developers can copy standard
templates and may need to modify them to conform to (CUSTOM NAME) standards such as for program
comments and case-sensitivity.
SQL*Plus Concurrent Program Template
Included below is a template for concurrent programs written in SQL*Plus. This is a working template that will
print a simple report of organizations defined in Oracle Inventory. It implements the cosmetic standards
established for Oracle Manufacturing reports.
REM ==========================================================================+
REM Copyright (c) 20XX <Company Name> |
REM All rights reserved.
|
REM
|
REM ==========================================================================+
REM
REM PROGRAM NAME: XXXXXXXX (Explanation)
REM
REM PURPOSE: Sample concurrent report in SQL*Plus
REM
REM CALLING FORMAT:
REM Testing: sqlplus mfg/mfg @XXXXXXXX <org id>
REM Concsub: CONCSUB mfg/mfg MFG 'Oracle Manufacturing' MFGCON CONCURRENT
REM (CUSTOM NAME) XXXXXXXX <org id>
REM Forms: #FND CONCURRENT (CUSTOM NAME) XXXXXXXX <org id>
REM
REM CALLED BY: Oracle Manufacturing Form XXXXXXX
REM
REM HISTORY
REM DD MON YY First Last - Initial coding
REM
REM ==========================================================================
REM --- Get command line parameters
define org_id = '&1'
REM --- Set report dimensions
define report_width = 132
SET LINESIZE &&report_width
SET PAGESIZE 64
REM --- Define and set imbedded header variables
COLUMN today NEW_VALUE _sysdate NOPRINT
COLUMN organization_name NEW_VALUE _orgname NOPRINT
BREAK ON today
SELECT TO_CHAR(SYSDATE, 'DD-MON-YY HH24:MI:SS') today,
organization_name
FROM org_organization_definitions
WHERE organization_id = &&org_id
/
CLEAR BREAKS
SET HEADING ON
NEWPAGE 0
CLEAR COLUMNS
Custom Programs
Overview
This document explains how to setup custom programs in Oracle Applications. In order to protect your custom
programs from upgrades it is recommended that you register a custom application and directory structure and
assign your custom programs to this application.
Executable Program
Build Executable Source File
Before registering your custom program you must first:
Write the program/report you wish to execute from the Standard Request Submissions window of the Oracle
Applications. You can write your executable source file by using any of the following methods:
Host Script
Oracle Reports
PL/SQL Stored Procedure
SQL Script
SQL*Plus Script
C or Pro*C Program
Move the execution files to their proper place on the operating system in use. The following table shows where
these execution files should be placed in a Unix environment:
Tool Ext. Directory
Sql*Plus & PL/SQL .sql $CUSTOM_TOP/$APPLSQL
Oracle Reports .rdf $CUSTOM_TOP/$APPLREP
Sql Loader .ctl $CUSTOM_TOP/$APPLBIN
Note: The program name is case sensitive and must exactly match the Execution file you defined previously.
Executable: Enter a name for your concurrent program executable. (You assign this
name to your concurrent program.)
Short Name: Enter a short name for your concurrent program executable. (You assign
this name to your concurrent program.)
Application: From the LOV select the application you wish to associate with your
executable. The concurrent managers use this value to determine in
which directory structure to look for your execution file. It is
recommended that you define a custom application with its own
directory structure in order to protect your programs during an upgrade.
Description: Optionally enter a description for this executable.
Execution Method: From the drop-down list select one of the following execution methods:
Host: The execution file is a host script.
Oracle Reports: The execution file is an Oracle Reports file.
PL/SQL Stored Procedure: The execution file is a stored procedure.
SQL*Loader: The execution file is a SQL script.
SQL*Plus: The execution file is a SQL*Plus or PL/SQL script.
Spawned: The execution file is a stand-alone C or Pro*C program.
Immediate: The execution file is a program written in C or Pro*C to
run as a subroutine of the concurrent manager. Immediate programs
are linked with your concurrent manager and must be included in
the manager's program library, for this reason it is recommended that
you use either a PL/SQL stored procedure or a spawned C program
instead.
Request Set Stage Function: PL/SQL stored function that can be
used to calculate the completion statuses of request set stages.
Note: The execution method cannot be changed once you have assigned
the executable to a concurrent program.
Execution File Name: Enter the operating system name of your execution file. Do not include
spaces or periods (.) in the file name unless the execution method is
PL/SQL stored procedure or Request Set Stage Function.
Note: The name entered here should match exactly with the file name, as
some operating systems are case sensitive.
Subroutine Name: If this is a C or Pro*C program subroutine then enter the name of the
subroutine program here. Do not include spaces of periods (.).
Parameter: Enter a name for the parameter. The name you enter here will be
displayed in the Stage Functions Parameter window of the Request Set
form.
Short Name: Enter a short name that will be used by the function to reference the
parameter.
Description: Optionally enter a description of the parameter.
Concurrent Program
Define Concurrent Program
Navigate to: Concurrent>Program>Define
Program: Enter a descriptive name for your concurrent program. This is the name
users will see when submitting a request.
Short Name: Enter a short unique name. Oracle Applications uses this name to
associate your concurrent program with an executable.
Application: From the LOV select the application you wish to associate your program
with. It is recommended that you define a custom application with its
own directory structure in order to protect your programs during an
upgrade. The Oracle Applications uses this to determine what ORACLE
username this program runs in and where to place the log and output
files.
Enabled: You cannot delete a concurrent program but you can disable it by un-
checking this box. Disabled programs do not show up in the users lists
or appear in the concurrent manager queues.
Executable>Name: From the LOV select the executable that runs your program. You can
define multiple programs that use the same executable.
Executable>Method: This field will be automatically populated with the execution method
that was selected when the executable was defined.
Note: You can switch between Spawned and Immediate, overriding the
execution method defined in the Concurrent Program Executable
window, only if either method appears when the executable is selected
and both an execution file name and subroutine name have already been
specified in the Concurrent Program.
Executable>Options: Enter execution option values here. If your concurrent program uses
Oracle Reports 2.0 then you must enter the parameter 'VERSION=2.0b'.
Other parameters for Oracle Reports 2.0 that you can enter here are
'ORIENTATION=<value>' and 'PAGESIZE=<width>x<height>. There
should be no spaces before or after the execution options values and the
parameters should be separated by a single space.
Executable>Priority: If you do not assign a priority here then the user's profile option
Concurrent:Priority sets the request's priority at submission time.
Request>Type: Optionally enter a request type from the LOV to limit which concurrent
managers can run your concurrent program.
Request>Incrementor: Internal field used only by Oracle Applications developers
Request>MLS Function: Multilingual Support function if used by the program.
Request>Use in SRS: This must be checked if you want to be able to run this program from the
Standard Submit Request Submissions form.
Request>Allow You can only check this box if you have checked the 'Use in SRS' box.
YouD can allow users to enter disabled values (values that have been
disabled
i or expired in a value set) as parameter values.
s
a
b
l
e
d
Values:
Request>Run Alone: Check this box if your program is incompatible with all programs in its
logical database, including itself.
Request>Enable Trace: Check this box if you want to turn on SQL tracing when this program
runs.
Request>Restart on Check this box if you want this program to be automatically restarted
System Failure: when the concurrent manager is restored after a system failure.
Request>NLS Check this box if the program allows the submission of requests that will
Compliant: reflect a language and territory different from the language and territory
the users are operating in.
Example: Users in the United Kingdom, enter orders in the English,
using the United Kingdom date and number formats, then generate
invoices in German using German date and number formats
Output> Format: Select the output format for your concurrent program from the drop-
down list. Valid values are Text, HTML, PDF, PS (Post Script), and PCL
(HPs Printer Control Language).
Output> Save: Check this box if you want to have the output from this program
automatically saved to an operating system file. If this box is left
unchecked then the output is deleted after printing.
Output> Print: Check this box if you want to be able to print output to a printer.
Output> Optionally enter the minimum column and row length for the program's
Columns/Rows: report output. Oracle Applications uses this information to determine
which print style to use.
Output> Style: If you want to print your program's report output then you should enter
a print style from the LOV.
Output> Style Required: If your program requires a specific print style then check this box to
enforce the print style. Normally users can change the print style at
runtime unless this box is checked.
Output>Printer: Users can change the printer the program they are submitting is sent to
unless you select a printer from the LOV for this field. This option is
useful for such things as check printing where you want to restrict to a
certain printer.
Copy Concurrent Program
Use this feature to create a concurrent program using the same executable, request and report information.
Navigate to: Concurrent>Program>Define
Select: Copy to
Session Control
Use this feature to specify options for the database session when the concurrent program is executed.
Consumer Group: Optionally enter the consumer group for the concurrent program.
Rollback Segment: Optionally enter a rollback segment to be used. This will be used up
until the first commit instead of the default rollback.
Application: From the LOV select the application the incompatible program belongs
to. Defaults to the application the concurrent program belongs to.
Name: From the LOV select the program that is incompatible with your
program.
Note: If you do not wish to display a parameter then make sure you
assign a default value to it.
Window> Display Size: Enter the field length in characters for this parameter. The size you enter
here determines the field size in the Parameters window of the Submit
Requests form.
Note: If the total of the value set maximum sizes for all your parameters,
plus the number of separators you need (number of parameters minus
one) exceeds 240 then you may see truncation of your data in some
forms.
Window> Description Enter the display length in characters for the parameter value
Size: description.
Window>Prompt: Enter a user-friendly name for the parameter. The user sees the prompt
rather than the parameter name.
Window>Concatenated Enter the display length in characters for the parameter value
Description Size: description.
Token: If your parameter belongs to an Oracle Reports program, you must enter
the keyword or parameter here. This field is case sensitive.
Example: p_date
Skip this field for other types of programs.
Concurrent Manager
Overview
Concurrent programs are typically data-intensive tasks that run simultaneously with other online operations. A
concurrent manager is itself a concurrent program that starts other concurrent programs. This document explains
how to start up, define, and configure concurrent managers. Concurrent Managers are defined and assigned one or
more work shifts. Target processes determine the number of concurrent requests that can be handled
simultaneously. Therefore, a combination of work shifts and target processes are used in order to achieve the most
efficient system performance.
Note: If the Standard manager is altered in any way, some programs may not run. We
recommend that you define additional managers to handle client-specific needs.
Conflict The Conflict Resolution Manager resolves conflicts, such as request incompatibilities. The
Resolution Conflict Resolution Manager checks concurrent program definitions for incompatibility
Manager rules. If a program is identified as Run Alone, then the Conflict Resolution Manager
prevents the concurrent managers from starting other programs in the same conflict domain.
When a program lists other programs as being incompatible with it, the Conflict Resolution
Manager prevents the program from starting until any incompatible programs in the same
domain have completed running.
Scheduler/Prer Scheduler/Prereleaser manager
eleaser Manager
Transaction Transaction Manager for diagnostics only
Manager
(Internal Only)
Note: Module specific Concurrent Managers can be deactivated and not started according to client needs.
Follow the steps outlined below to start the ICM during installation of Oracle Applications, after shutdown of
concurrent managers, or after restarting your operating system or database
Log in to the UNIX server as applmgr
Select the appropriate database environment
Use the following command: Startmgr <ORACLE_SID>
Note: CRM cannot be controlled using the administration form. The ICM cannot be
restarted using the administration form. Refer to the Oracle Applications Installation
guide for further details.
Terminate: Terminate the ICM to deactivate all concurrent managers and terminate
all concurrent requests at once. Terminate individual managers to
deactivate the selected manager and all requests handled by that
manager
Deactivate: Can be used on any manager EXCEPT the CRM and
Scheduler/Prereleaser. Deactivate the ICM to deactivate all managers or
deactivate individual managers by deactivating the selected manager.
Concurrent requests currently running are allowed to complete before
the manager(s) shut down
Note: Once deactivated, the ICM can only be activated from the server.
Activate: Use to activate previously deactivated individual concurrent managers.
Name: Intuitive name, e.g. Night Shift, Graveyard Shift, Week Days,
Weekends
Time>From: Start time for the shift in military time format (HH24:MM) e.g. 09:00
(9am)
Time>To: End time for the shift in military time format (HH24:MM) e.g. 17:00
(5pm)
Note: Workshifts cannot run across midnight i.e. they must end by 23:59
and begin on or after 24:00
Days of Week>From: First day of WorkShift, e.g. Monday for weekdays WorkShift
Days of Week>To: Last day of WorkShift, e.g. Friday for weekdays WorkShift
Date: Date value for a date-specific WorkShift, e.g. JAN-01-2000
Create an event (on insert) alert that sends a message to the Payables Manager indicating an RMA has been created
in Purchasing. The message should contain the following information:
RMA Reference
Quantity
Reason for Return
Method of Return
PO Number
User Procedures
The Alert will be activated upon insert of the RCV_TRANSACTIONS table.
Alert Description
Select: Alert Manager Responsibility
Navigate to: Alert > Define