EBS R12 -- patch analysis, rollback a patch (only in theory, not recommended)

As you may know, in EBS R12 there is no way or no utility that can  rollback an Applications patch which is applied with the adpatch or adop .
So, these patches are not like the rdbms patches which can applied and rolled back using the opatch utility.
Altough, there is no utility or a support document that can be used to rollback an application patch, there is a manual method to follow for rolling back an applications patch in EBS systems.
It is probably a not supported action but it is worth mentioning..
Of course , this method must not followed for big pataches like applications upgrade patches , but it can be used for small patches which are applied for fixing a couple of bugs.
Knowing the proper method for rollbacking a patch is restoring a backup, this manual method that I will explain below can also be used on your own risk as the last resort.

To rollback a patch, we first need to identify the changes delivered with it. To identifiy the changes, we unzip the patch zipfile and open the patch driver file.. The driver file is where the patching utility gets its order from.

The actions in driver file are equipped with comments , for example the following ;

# Phase TAB - Create Tables and Indexes
# file-version-parsed XXX patch/115/xdf /XXX.xdf 120.5.12020000.2

So, comments above tell us that , the patch creates some tables and indexes and the definitions for these tables and indexes are in XXX.xdf file that is stored in the patch directory, exactly in the patch/115/xdf subdirectory.

So , when we open this XXX.xdf ile, we gather te following info , as we find it properly commented there..

Primary Object Schema Name :
XXX
Primary Object Name :
    XXX_EXT
Primary Object Type :
    TABLE
Dependent Object Information :
Indexes on XXX_EXT :
    XXX_UI
    None
Sequence(s) on XXX_EXT :
    None
Policy(ies) on XXX_EXT :
    None

So, we see that the patch creates a table named XXX_EXT and also creates an index XXX_UI on table XXX_EXT.

Similary, we identify the plsql objects and form files that are created or changed with the patch using the information written in the driver file, and take the necessary actions to take them back.

Following is a snip from a patch driver file, it basically says that , this patch is designed to execute the XX_NEW.pls to create or replace some package specification ..
So, by opening the pls with an editor, we can easily see the name of the spec and find out what is changed there. So if we want to rollback that spec, we can take the definition of it using a backup or a test system and compile it back in the system where the patch is applied.

# Phase PLS - Create Package Specifications
# file-version-parsed cle patch/115/admin/sql XX_NEW.pls 120.2.12020000.1
sql xxx patch/115/admin/sql XX_NEX.pls none none none package &phase=pls
checkfile:xxx:patch/115/admin/sql:XX_NEW.pls

So, the necessary actions that we are talking about here, may be getting the definition of the changed objects from a backup or a test system and compiling them in the system where the patch is applied ..

If the changed object is an application tier object such as a form (fmb) , we should take the old version of it from the test environment or from a backup, place it in to the correct folder and compile it.

Lastly, in the driver file, we may also see a data load for seed tables with a comment like;
#Phase DAA - AOL Seed Data.
In this case, we can analyze the lct and ldt files to rollback the changes, as these seed data operations are done using FNDLOAD utility.

Once all the work for rolling back is finished, we may compile the invalid objects inside the database using adadmin-apps compile and utlrp.sql and restart our application services.

Altough, we rolled back a localization patch in EBS 12.1 using this method recently, and altough it worked for our customer, I want to remind you that, this is not a method for rolling back a patch.
You should never use this method normally!
But, of course, you can use it on your own risk, if you have nothing else to do, when you have no backup., nothing.
Moreover , if you decide to roll back a patch manually using this patch analysis method, you must know what you are doing, as it is not documented, not supported and a completely manual operation. Also, the steps in such an operation may vary according to the patch and the environment , so you must have necessary experience to analyze the patch driver file properly and take the necessary actions in the system.