Search Results check_olite_schema

Overview

JTM_WRAPPER_PKG is a PL/SQL wrapper package owned by the APPS schema in Oracle E-Business Suite Release 12.1.1 and 12.2.2. It belongs to the JTM (Java-based Transaction Manager / field service mobility) product family and serves as a plated wrapper layer that exposes internal access-management and client-synchronization operations to external callers, including Java-based middle-tier components. The package is classified under the ETRM API classification "OTHER," indicating it is not a formally published public API but is nonetheless callable from the EBS runtime. Its header identifies the source as jtmwrpps.pls version 120.1, last modified in 2005, confirming the object has remained stable across the 12.1.x and 12.2.x release lines. The package is primarily responsible for maintaining the mapping between application users and the records they are authorized to access on a mobile or disconnected client, and for propagating client-side changes back into the EBS repository.

Key Procedures and Functions

The package exposes four documented program units:

• POPULATE_ACCESS_RECORDS — A procedure that accepts a user identifier and creates or refreshes the access records that define which data a given user is entitled to view or manipulate through the JTM client. It seeds the access mapping tables for the specified user.
• DELETE_ACCESS_RECORDS — A procedure that accepts a user identifier and removes the previously populated access records for that user, typically invoked when access is revoked, a user is reassigned, or access assignments are being rebuilt.
• APPLY_CLIENT_CHANGES — A procedure that accepts a user name and a transaction identifier and applies changes captured on the disconnected client back to the EBS database, using the transaction identifier to scope and reconcile the set of changes.
• CHECK_OLITE_SCHEMA — A function that returns a VARCHAR2 value indicating the status or detection result of the OLite schema. This is the object most commonly associated with the search term "check_olite_schema." OLite refers to the Oracle Lite / mobile embedded database used by the disconnected client; the function verifies the presence or configuration of that schema before mobile synchronization proceeds.

Tables Accessed

The package references the following objects via APPS synonyms:

• JTM_ACC_TABLE_S — The JTM access table seed/setup table, which defines the access table definitions used when populating user access records.
• JTM_ASG_USER_ACC — The assignment-to-user access table, which stores the actual mapping of assignments to users and is the principal target of POPULATE_ACCESS_RECORDS and DELETE_ACCESS_RECORDS.
• ASG_USER — The user assignment source table, consulted to determine which assignments pertain to the user being processed.
• FND_LANGUAGES — The Oracle Application Object Library languages table, used to resolve language-dependent values during record population.
• DBMS_SQL — The Oracle dynamic SQL built-in package, used for dynamic statement execution within the wrapper logic.
• PLITBLM — The PL/SQL index-by table manipulation package, used for in-memory collection handling.

Usage Notes

Because JTM_WRAPPER_PKG is a wrapper rather than a business-facing API, it is not typically invoked directly by end users through EBS forms or standard concurrent programs. It is called from JTM application logic, from Java or middle-tier components that manage the mobile/disconnected client, and from custom PL/SQL code that must programmatically synchronize or refresh user access. The ETRM metadata records zero packages referencing it, meaning no other APPS package has a documented dependency on it; callers therefore come from outside the PL/SQL package layer. Developers diagnosing mobile synchronization issues should note that CHECK_OLITE_SCHEMA is a function returning VARCHAR2 and should be invoked in a SELECT or assignment context rather than as a standalone statement. As with all "OTHER"-classified APIs, the package carries no formal support guarantee for external use, and any customization should account for the possibility of change in future patches.