How to Compile Forms , Reports & Custom.pll in R12.2

How to Compile Custom.pll 

 cd $AU_TOP/resource

 cp CUSTOM.plx CUSTOM.plx_bkup

 cp CUSTOM.pll CUSTOM.pll_bkup

 frmcmp_batch module=CUSTOM.pll userid=apps/apps output_file=CUSTOM.plx module_type=LIBRARY batch=yes compile_all=special

How to Compile Forms

Ensure that the $FORMS_PATH includes $AU_TOP/resource, $AU_TOP/resource/stub, and $AU_TOP/forms/US

Custom [ any forms customizations  used -CUSTOM.pll ]:

frmcmp_batch.sh module=$AU_TOP/forms/US/xxxxxxx.fmb userid=apps/apps output_file=$PER_TOP/forms/US/xxxxxxx.fmx module_type=form compile_all=special

Seeded:

frmcmp_batch.sh module=$AU_TOP/forms/US/xxxxxxxxx.fmb userid=apps/apps output_file=$PER_TOP/forms/US/xxxxxxxx.fmx module_type=form

How to Compile Reports

rwconverter.sh userid=APPS/APPS source=$FND_TOP/reports/US/FNDATJAP.rdf stype=rdffile dtype=rdffile overwrite=yes batch=yes compile_all=yes

rwconverter.sh userid=APPS/APPS source=$FND_TOP/reports/US/FNDATJAP.rdf dest=/tmp/FNDATJAP.rdf stype=rdffile dtype=rdffile overwrite=yes batch=yes compile_all=yes

EBS: R12.2 Rapidwiz fails due to insufficient diskspace on Solaris/AIX

Rapidwiz failed while performing prereq check due to insufficient diskspace on /tmp directory.  So we tried to set env variable TMPDIR & restarted rapidwiz. however solaris platform doesn't  take the value from env variable TMPDIR and it failed again. 

Finally , We set below variables in order to resolve this issue. Please set TEMP,TMP,TMPDIR,TEMPDIR to the different folder where we have enough space & invoke rapidwiz again.

export TEMP=/u01/temp

export TMP=/u01/temp

export TMPDIR=/u01/temp

export TEMPDIR=/u01/temp

./rapidwiz

How to Create Defaults file in R12 for adadmin?

Note: Default file location should be $APPL_TOP/admin/$TWO_TASK in R12.2

adadmin defaultsfile=$APPL_TOP/admin/DSDEV/adadmin_defaults.txt

Answer the questions below:

Your default directory is '/app/dsdev/fs1/EBSapps/appl'.

Is this the correct APPL_TOP [Yes] ? 

AD Administration records your AD Administration session in a text file

you specify.  Enter your AD Administration log file name or press [Return]

to accept the default file name shown in brackets.

Filename [adadmin.log] : 

You can be notified by email if a failure occurs.

Do you wish to activate this feature [No] ? 

Please enter the batchsize [1000] : 

Applications System Name [DSDEV] : DSDEV *

You are about to use or modify Oracle E-Business Suite product tables

in your ORACLE database 'DSDEV'

using ORACLE executables in '/app/dsdev/fs1/EBSapps/10.1.2'.

Is this the correct database [Yes] ? 

AD Administration needs the password for your 'SYSTEM' ORACLE schema

in order to determine your installation configuration.

Enter the password for your 'SYSTEM' ORACLE schema:  

The ORACLE username specified below for Application Object Library

uniquely identifies your existing product group: APPLSYS

Enter the ORACLE password of Application Object Library [APPS] :  

AD Administration is verifying your username/password.

Backing up restart files, if any......Done.

         Generate Applications Files

   ----------------------------------------

   1.    Generate message files

   2.    Generate form files

   3.    Generate report files

   4.    Generate product JAR files

   5.    Return to Main Menu

Now Press ctrl +c or ctrl+d

Here after you can use the below command to call adadmin

adadmin defaultsfile=$APPL_TOP/admin/DSDEV/adadmin_defaults.txt  logfile=arall.log

Types of Patches in Oracle Apps 11i/R12

E-Business Suite patching is very broad topic. so Decided to split it into two logical parts.


Part 1) Oracle E-Business Suite patch terminology

patch type hierarchy

patch naming convention

naming differences between 11i and R12


Part 2) Querying patches, patchsets, family packs

how to check if a patch was applied

what patchset am I on?

what family pack am I on?


Patch hierarchy in 11i:

One-off Patches:The One-off patch category was common in the older versions R11 (11.0.x) and early releases of 11i. Typically, they fix single or isolated set of bugs. They are less and less common these days. Unless they fix a very critical and isolated bug, Oracle won’t release patches as standalone, but will consolidate them into larger bundles.


Product Patchsets (formerly known as Minipacks):Standalone patchsets were common in early releases of 11i. They can enhance functionality and typically fix a large number of bugs for a single product. Once a patchset is applied, it increments the patchset level of a product (the product is sometimes also referred to as module). There are around 200 products integrated in EBS, and each product has specific patchset level. For most products, patchsets are no longer distributed as standalone (which means you won’t be able to download them from metalink), but are grouped into Family Packs.


Rollup Patches: Roll-up patches are a special kind that started to become more common as 11i matured. They are collection of bugfixes for a specific product and relate to specific patchset level. They are released outside of a patchset release cycle. If a particular patchset turns out to be buggy it can have several roll-up patches, which are usually cumulative. These patches are sometimes referred to as a number after a patchset letter, as in case of 11i.AD.I.4.


Family Packs:As the complexity and dependencies between individual products increased, it became more and more difficult to release isolated patchsets for each product. Oracle grouped all interrelated products into families fulfilling a specific functional purpose. Family packs are seta of product patchsets for a particular family (such as Financials, Project Suite, Applications Technology, and so on). The family pack’s advantage is that the patchset levels were tested together, and should therefore be more stable and require fewer pre-requisites. Despite that fact, applying a family pack is a major change to the system, and should be rolled out carefully.


Consolidated Updates: As the EBS product matured in version 11i, Oracle started to release consolidated updates. These are huge updates similar to maintenance packs. They introduce change the fourth version number. You can think of it as a set of compatible family packs. The best-known consolidated update is CU2 which upgrades your system to version 11.5.10.2.


Maintenance Packs (in R12 Release Update Packs):Maintenance packs deliver a new version of a product. Unlike major release upgrades, maintenance packs change the release number, which is the third number in a version name (for 11i). They are still considered patches, but the changes they introduce are system-wide. Often they also bring in brand new products.


Patch naming conventions:

Every patch, irrespective of kind, has an identifier in form of a seven-digit number, that particular identifier corresponds with a bug number. The bug can be just a placeholder for the consolidation of other patches that are eventually merged into a bigger patchset, family pack etc.

For one-off patches, the 7-digit number is their only identifier.

There are around 200 products in E-Business Suite, and each product has a specific product name and product abbreviation. The Patchset level naming convention has an alternative to the patch number for easier identification. It consists of version number, product abbreviation, and a letter.

For example: 11i.FND.H refers to patchset H for product FND for version 11i and it can be found under patch number 3262159.

Family packs add an additional component to the short name which is “_PF” after the product name abbreviation.

For example: the Application Technology family pack is referred to as 11i.ATG_PF.H (which corresponds with patch number 3438354), and the Financial suite family pack is referred to as 11.FIN_PF.G etc.

Consolidated updates were introduced after release 11.5.10. They append another number after the version number. So consolidated update 2 is referred to as 11.5.10.2 or simply CU2 (or as patch number 3480000).

Maintenance packs are the last piece in the puzzle. Their alternative names are same as the version number, so it’s 11.5.9, 11.5.10 etc.


Changes with R12 and new facts in the patch naming conventions

R12 introduces some new terms—codeline and codelevel—and changes the meaning of several established terms.

codeline: This refers to a point release. Every codeline delivers a unique set of features. So release 12.0 is a understood as codeline A; release 12.1 is understood as codeline B; release 12.2 will be understood as codeline C, and so on.

codelevel: Codelevel can resemble patchset level from 11i. For each codeline, there can be a set of updates, which deliver mostly bugfixes and reflects the particular product codelevel after the codeline letter.For example: R12.AP.A.4 means Account Payables product on codeline A (Release 12.0) on codelevel 4 (Part of release 12.0.4).

The important thing to understand is that if you install a specific R12 release such as 12.0.4, all products will not only be on the same codeline (A), but also on the same codelevel (4). Further updates for a specific codelevel are delivered in form of delta updates. So instead of going from 12.AD.A.4 to 12.AD.A.5 as you’d expect from 11i, you’d go from 12.AD.A.4 to 12.AD.A.4.delta1, 12.AD.A.4.delta2, and so on. The codelevel is incremented via Release Update Packs.


Release Update Packs:What was formerly known as a maintenance pack is now called a Release Update Pack with short name of RUP. This could be confused with another RUP (Roll-Up) as it was used in context of 11i. RUPs actually upgrade all products to higher codelevel. These point release upgrades can introduce substantial changes to the system, therefore need to be carefully planned.For example: RUP2 is equivalent to R12.0.2, RUP6 is equivalent to R12.0.6 etc.

The final note for R12 is that patch numbers no longer have to be unique: the same patch can be released in multiple shapes for different codelevels.

Reset Oracle Application User Password through API

DECLARE
flag_value BOOLEAN;
BEGIN
flag_value := fnd_user_pkg.changepassword(username=> 'RJAYANTH',newpassword => 'welcome1');
IF flag_value
THEN
DBMS_OUTPUT.PUT_LINE('The password reset successfully');
ELSE
DBMS_OUTPUT.PUT_LINE('The password reset has failed');
END IF;
END;
/
COMMIT;

How To Clear The Cache Using Functional Administrator?

Examples that may require this action to be taken are as follows:

-  iProcurement Preferences (these values actually are User level profile options)

- FND Diagnostics - to enable diagnostics

- FND Debug Log Enabled 

- Personalize Self Service Defn - commonly used  to enable the Personalization Links

- Newly added responsibility is not visible

The following steps are to be utilized to clear all the cache, forcing a refresh and requery of all profile values for the user in question.

1. Login and choose the Functional Administrator responsibility - then choose Home.

2.  Choose the Core Services Tab - then the Caching Framework Sub-Menu (In the dark blue region). - Proceed to choose 'Global Configuration' from the left hand side menu that appears - In the far right choose 'Clear all Cache' button

3. A screen prompts and confirms that the action will clear all cache on the middle tier server - choose Yes. Essentially, this just forces all user sessions to engage and validate - rather than using cached values.

4.A confirmation message is displayed, confirming that all cache has been cleared across middle tiers.

Add Responsibility/End-date User through API in R12

How to End-date user & Add Responsibility through API:

Applications users cannot be deleted since records belonging to users are kept for security and monitoring purposes. In addition, the user is recorded in Who columns, so deleting would cause foreign table data integrity problems. Instead, set "End Date" for that user.

Also same for the responsibility. We cannot delete a responsibility. We can only end-date a responsibility.

So Users and responsibilities cannot be deleted, instead you should end-date it.
For menus, functions, custom applications, it is to delete them -- Navigate to the form, query the record, and click on the delete button (or Edit > Delete).

There is no API or scripts to delete user accounts in FND_USER. Deletion of an an e-business suite user account is not possible and not supported.

API To End-Date FND_USER:

begin
fnd_user_pkg.updateuser(x_user_name=>'RJAY',x_owner=>'CUST',x_end_date=>SYSDATE-5);
commit;
end;
/


x_owner can be either SEED or CUST:
To end date seeded users (i.e. sysadmin) x_owner= SEED
To end date custom users x_owner = CUST

API To add responsibility:

-- ---------------------------------------------------------- 

-- Add Responsibility to Oracle FND User 

-- ----------------------------------------------------------- 

DECLARE 

    lc_user_name                        VARCHAR2(100)    := 'RJAY'; 

    lc_resp_appl_short_name   VARCHAR2(100)    := 'SYSADMIN'; 

    lc_responsibility_key          VARCHAR2(100)    := 'SYSTEM_ADMINISTRATOR'; 

    lc_security_group_key        VARCHAR2(100)    := 'STANDARD'; 

    ld_resp_end_date                 DATE                        := NULL; 

BEGIN 

     fnd_user_pkg.addresp 

     (   username           => lc_user_name, 

        resp_app             => lc_resp_appl_short_name, 

        resp_key             => lc_responsibility_key, 

        security_group  => lc_security_group_key, 

        description         => NULL, 

        start_date           => SYSDATE-10, 

        end_date            => ld_resp_end_date 

    );

 COMMIT; 

EXCEPTION 

            WHEN OTHERS THEN 

                        ROLLBACK; 

                        DBMS_OUTPUT.PUT_LINE(SQLERRM); 

END; 

/

SHOW ERR;