Search Results create_profile

Overview

JTF_PERZ_PROFILE_PVT is an Oracle E-Business Suite private PL/SQL package that belongs to the personalization framework of the CRM/Applications Technology stack. Its stated purpose in the package header is to provide a private API for managing common functionality across the personalization framework. In practice, the package encapsulates the low-level database operations required to persist and retrieve personalization profiles — reusable collections of attributes that govern how the E-Business Suite user interface behaves for a given user, responsibility, or application context.

The package is authored against the APPS schema and is classified as a Private (PVT) API in ETRM. That classification is significant: private APIs are not intended for direct invocation by customers or integrators. They are internal building blocks invoked by the corresponding public API layer, JTF_PERZ_PROFILE_PUB, which exposes the same logical operations with a supported, version-controlled interface. The package header carries the CVS identifier $Header: jtfzvpfs.pls 120.2 2005/11/02, and the history block traces its creation to June 1999, with the Create_Profile routine amended in September 1999 to accept a caller-supplied profile identifier. This lineage confirms the package has been stable for well over a decade across the 12.1.1 and 12.2.2 releases.

Key Procedures and Functions

ETRM documents four procedures within the package:

• CREATE_PROFILE — Inserts the profile header row together with its associated profile attribute rows. The procedure accepts a profile identifier, name, type, and description, plus a PL/SQL table of attribute definitions. It delegates work to two internal helpers, insert_profile() and insert_profile_attributes(), keeping the public signature clean while isolating the two physical insert operations. The routine returns the resulting profile name and identifier to the caller.
• UPDATE_PROFILE — Modifies an existing profile header and its attribute set, added to the package in June 1999 alongside the retrieval routine.
• GET_PROFILE — Retrieves a profile and its attributes, populating an output table structure for consumption by the caller. Because personalization data is read far more frequently than written, this is the routine most heavily exercised at runtime.
• CHECK_PROFILE_DUPLICATES — Validates that a proposed profile name does not collide with an existing row. A companion routine, check_prof_attrib_duplicates, performs the equivalent check at the attribute level.

All routines follow the standard EBS API contract, accepting API version, message-list initialization, and commit-control parameters, and returning return-status, message-count, and message-data outputs.

Tables Accessed

The package reads and writes four personalization tables through APPS synonyms. JTF_PERZ_PROFILE and its translated counterpart JTF_PERZ_PROFILE_S hold the profile header, storing the identifier, name, type, and description. JTF_PERZ_PROFILE_ATTRIB and JTF_PERZ_PROFILE_ATTRIB_S store the individual attribute definitions that belong to each profile. The CREATE_PROFILE path inserts into both the header and attribute tables; the duplicate-check routines query them to enforce uniqueness before insertion. The package also depends on DBMS_SQL for dynamic SQL construction and PLITBLM for PL/SQL table manipulation utilities.

Usage Notes

Because this is a private API, the supported invocation path is through JTF_PERZ_PROFILE_PUB rather than direct calls. ETRM records that five other packages reference JTF_PERZ_PROFILE_PVT, indicating it sits beneath several personalization consumers in the dependency chain. Forms-based personalization administration, the profile maintenance UI, and any concurrent program that seeds or migrates personalization definitions will ultimately reach this package. Custom code should never call these procedures directly: the signatures are not guaranteed stable between patch levels, error handling assumes the calling public API has already initialized the message stack, and commit semantics are deliberately delegated to the caller through the p_commit flag. Developers searching on "create_profile" should treat the match here as an implementation detail and direct their integration work to the public wrapper.