Seeting Up OAF

Application:

• Functional grouping of forms, reports, programs, menus, libraries, and other objects

Application Short Name:

• Identifies application in directory and file names, and in application code such as PL/SQL routines.

Oracle Schema:

• Database user name used by application to access the database. Also known as 'Oracle ID' or 'Oracle User'.

Environment Variables:

1. $APPL_TOP
2. Application Basepath

Setup Application Directory Structure:

• Place application components in appropriate directories on appropriate machines so that AOL can find them.

Register Application:

• Register application's name, short name, basepath and application description with AOL. AOL uses this information to identify application objects such as responsibilities, forms, etc.
• To reduce risk that your custom application short name could conflict with a future Oracle Applications short name, name it as XX___

Add Application to a Data Group:

• Oracle Applications are installed as part of the Standard Data Group. Use Data Groups window to make a copy of standard data group and add your Application-Oracle ID pair to new data group.
• Specify APPS as Oracle ID (instead of custome schema) if you have integrated your application tables with the APPS schema.
• (N) : System Administrator responsibility- Security -> ORACLE -> Data Group

Application window:

• Register application to get AOL identify your application objects (e.g responsibilities, forms etc.) as belonging to your application. This identification with custom application allows Oracle Applications to preserve your application objects and customizations during upgrades.
• Define an environment variable that translates to your application basepath.
• Setup a directory structure for your custome application.
• Create a database if custome custom application resides in a database other than the database where Oracle Alert resides.

1. Application:
2. Short Name: XX_
3. Basepath: Name of environment variable that represents the directory of your application's directory tree. Oracle Applications search specific directories beneath the basepath for executables. [Correspond to GL_TOP,AR_TOP etc. e.g. ACX_TOP]

Building Database Objects:

• Oracle Applications upgrade technology relies on Record History(WHO) information to detect and preserve customization.
• Add WHO columns to tables, and WHO logic to custom forms and stored procedures, to track changes made to application data.
• Represent each of WHO columns as hidden fields in each block of custom form. Call FND_STANDARD.SET_WHO in PRE-UPDATE and PRE-INSERT.

1. CREATED_BY: TO_NUMBER(FND_PROFILE.VALUE(USER_ID))
2. CREATION_DATE: SYSDATE
3. LAST_UPDATED_BY:
4. LAST_UPDATE_DATE: SYSDATE
5. LAST_UPDATE_LOGIN: TO_NUMBER(FND_PROFILE.VALUE(LOGIN_ID)), NULL allowed.

• Any table that may be updated by a concurrent program also needs additional columns used for Record History.

1. REQUEST_ID: is foreign key to table- FND_CONCURRENT_REQUESTS
2. PROGRAM_APPLICATION_ID: is foreign key to table- FND_CONCURRENT_PROGRAMS
3. PROGRAM_ID: is foreign key to table- FND_CONCURRENT_PROGRAMS
4. PROGRAM_UPDATE_DATE: is foreign key to table- PROGRAM_UPDATE_DATE

• To set Record History information, use event handlers in forms. Store logic in PRE-INSERT and PRE-UPDATE event handlers, which are called from PRE_INSERT and PRE_UPDATE block level triggers.
• Any constraint that is associated with a table should be duplicated in form so that user receive immediate feedback if a constraint is being violated.
• If you create additional constraints on Oracle Applications tables, disable them before upgrading Oracle Applications.

1. NOT NULL: Declare corresponding field in Oracle form as "Required"=True.
2. DEFAULT: Do not use this feature due to locking problems with Oracle Forms. * Defaulting column values can make batch programs simpler. Possible default values are SYSDATE, USER, UID, USERENV(), or any constant value.
3. UNIQUE: Only fields that user can enter should have a uniqueness check within form. System generated unique values should be derived from sequences.
4. CHECK:
5. PRIMARY KEY: Define a primary key for all the tables.

Standard Request Submission

• Provides standard interface for running and monitoring reports.
• Single form to submit any request, concurrent program. Another form to see report's progress and to review report online.
• Submit Request form: easy-to-use interface.
• Automatic Resubmission.
• Request Sets: define sets of reports, Submit an entire set at same time.
• Request Set options: Run order, printer, no. of copies etc.
• Request Set Log File:Single log file containing the completion status of all reports in set.
• Viewing Requests: Monitor report's progress using View Request form.

• Child Request: or a sub-request submitted by any other concurrent request(Parent Request)

• Parameter: A value you specify when you run a request.

* A request set is parent request and all reports in set are child requests

Value Set: A set of values against which AOL validates values, the ned user enters when running a concurrent program.

Controlling Access to Reports:

• Create related group of reports and request sets.
• Define responsibility and assign a report security group to that responsibility.

Request Sets:

• A collection of reports/programs that are grouped together. Allow to submit reports or programs in a request set all at once using a single transaction.
• Request set can be defined to submit requests depending on the completion status of previously submitted requests in the set.

Stage:

• Component of a request set used to group requests within a set. All requests in a stage are executed in parallel. Request set executes one stage at a time., following links from stage to stage.
• Links that are followed depend on the completion status of the individual stages. A stage completes when all the requests contained in the stage have completed.
• PL/SQL functions calculate the completion status of a stage
• Three status of a stage:

1. Success
2. Warning
3. Error

Stage Evaluation function:

• Provided by AOL, computes the stage completion status from the completion statuses of the specified requests in set.
• Function returns a

1. Success: If all requests completed with a status of "Success".
2. Warning: If one or more requests in set completed with warning and no request completed with error.
3. Error: If any request in set completed with error.