I’ve created a custom top for APEX integration with Oracle EBS R12 12.2.10 recently & by mistake choose 5001 instead of 50000+ for application id. Then I wanted to do it correct and proceeded with the documented procedures.
perl adDeregisterCustomProd.pl
This script errored out as the application id was less than 20000 (unfortunately, I didn’t copy the exact error messages). So, started a session with gemini3, that I recently subscribed. Well, although the AI helped to a great extend, finally I had to refer a blog that helped me to resolve the related issues & finally come up with a clean context file.
Lets’ see how it works. Shutdown the application instance & start deleting the custom top specific entries from related tables. As user “apps”
DELETE FROM fnd_product_installations WHERE application_id = 5001
/
DELETE FROM fnd_application_tl WHERE application_id = 5001
/
DELETE FROM fnd_application WHERE application_id = 5001
/
DELETE FROM fnd_oracle_userid WHERE oracle_id = 5001
/
commit
/
Now, delete the entry for your custom application from fnd_oam_context_custom, a step that shouldn’t be missed. Use the select statement to find out specific information about your custom application
DELETE FROM fnd_oam_context_custom WHERE upper(oa_var) LIKE '%XXAPEX%'
/
COMMIT
/
Now, as Oracle user “system” you need to drop the custom schema. I wanted to drop the custom schema “XXAPEX”
SELECT editions_enabled FROM dba_users WHERE username = 'XXAPEX'
/
DROP USER XXAPEX CASCADE
/
Now, remove the physical path for the custom application
rm -rf $XXAPEX_TOP
Usually, one should proceed with auto config and do an adop fs_clone to replicate the changes while using dual file systems. For me, after auto config, I was still seeing the custom top entry within the context file & no questions will help the AI to pinpoint my issue. Suggestions after suggestion auto config recreated the entry for the custom top inside the context file.
I gave the AI some rest time & started scavenging through blogs & came across the below one
Here the blogger is dealing with a situation that was raised while using “adDeregisterCustomProd.pl”. Fortunately, the blogger has copied the entire log of the activities and I found a very interesting entry
XXAR entry in topfile.txt is removed succesfully ..!
Well, that was it! I hurried to AI once again and asked for the physical location for the topfile.txt & removed the custom top entry from the list. Manually deleted the line from context file & ran auto config once again on “run” environment. Once the config completed, there were no more entries for the custom application to be found.
As we are using SSL for the EBS instance, restarted the application and proceeded with fs_clone. I am noting the fs_clone issues while using SSL to avoid another post. If you initiate the fs_clone without the application server being up using SSL, you are prone to hit the error
[user: applmgr] [VirtualHost: main] (13)Permission denied: make_sock: could not bind to address [::]:443
The solution is simple, start the application server if it was shutdown & try fs_clone once again.




















