Search Results target_clean

Overview

The APPS.FND_CONC_CLONE package is an internal Oracle E-Business Suite utility that supports the database cloning process. Its role is to remove environment-specific concurrent processing configuration from a target database so that a cloned instance does not inherit stale node names, queue definitions, printer registrations, or request metadata from the source system. Because the package manipulates the core Concurrent Manager repository, it is classified as a restricted API. The header comments for both documented procedures explicitly warn that the API is reserved for the Rapid Install and cloning teams, and that it must not be executed by general users or developers.

The package was originally delivered in the 11i file AFCPCLNS.pls, with the version header indicating a 2003 date, and remains documented for EBS 12.1.1 and 12.2.2 within ETRM. It is declared AUTHID CURRENT_USER and executes with the privileges of the calling session, which in the supported use case is a privileged APPS or installation session.

Key Procedures and Functions

• TARGET_CLEAN — Cleans a target database for cloning purposes. The procedure takes no arguments. It is documented as part of the Rapid Install tooling and is intended only for that team. The caller is responsible for issuing the COMMIT, and the procedure does not handle exceptions internally.
• SETUP_CLEAN — Cleans the target database in a cloning scenario, specifically for the setup phase of a clone operation. It likewise takes no arguments, is intended for cloning use, requires the caller to commit, and performs no internal exception handling.

Tables Accessed

The package operates across a wide set of Concurrent Manager and installation tables, accessed through APPS synonyms:

• Concurrent manager metadata: FND_CONCURRENT_PROGRAMS, FND_CONCURRENT_QUEUES, FND_CONCURRENT_QUEUES_TL, FND_CONCURRENT_QUEUE_SIZE, FND_CONCURRENT_PROCESSES, FND_CP_SERVICES, and FND_CONFLICTS_DOMAIN. These hold queue and program definitions, translations, worker limits, and incompatibility rules that are typically environment-specific.
• Request and execution history: FND_CONCURRENT_REQUESTS, which may be scrubbed or reset during cloning.
• Environment and node information: FND_NODES, which stores registered application-tier node names that must reflect the new host after cloning.
• Output and printer configuration: FND_PRINTER and FND_PRINTER_TL, which hold printer registrations and their translations.
• Security and connectivity: FND_ORACLE_USERID, which holds Oracle schema credentials used by concurrent managers.
• Installation and profile data: FND_APPLICATION, FND_PRODUCT_INSTALLATIONS, and FND_PROFILE_OPTIONS, used to identify installed products and site-level settings that require adjustment.

Usage Notes

FND_CONC_CLONE is not surfaced through an Oracle EBS form, and it is not registered as a concurrent program for end users. It is invoked programmatically by Rapid Install and by the supported cloning and rapid cloning utilities during the post-clone configuration stage, when the target database must be reconciled with the new host, port, and service details.

Because the package references only two public procedures with no parameters and no internal exception handling, any custom invocation must wrap the call in exception handling and must explicitly commit. The metadata records zero dependent packages, so the API is self-contained with respect to other PL/SQL units, though its effects propagate into the Concurrent Manager configuration. Oracle's documentation states plainly that the API is for the Rapid Install and cloning teams; running it against a production or non-cloned instance risks corrupting concurrent manager setup and request history. It should be treated as an internal, release-specific utility rather than a general-purpose administration interface.