Search Results get_error_message_text

Overview

CSL_SERVICEL_WRAPPER_PKG is an Oracle E-Business Suite PL/SQL package owned by the APPS schema and classified under the Service / Field Service (CSL) module. It is declared with AUTHID CURRENT_USER, meaning that its SQL statements execute against the privileges of the invoking session rather than the package owner. The package serves as a server-side wrapper layer for the Service Logistics (Servicel) mobile and client-change processing framework, exposing entry points that coordinate synchronization between a remote or disconnected client and the central EBS database. Its responsibilities include applying queued client changes, retrieving translated and token-substituted error messages, removing successfully applied records from the in-queue, and deferring or rejecting records that fail validation.

The object is referenced by twelve other packages and was last updated in the 115.10 revision of the source file csllwrps.pls, indicating a longstanding, stable component of the Service Logistics transaction-processing chain.

Key Procedures and Functions

The documented API surface contains ten procedures and functions:

• APPLY_CLIENT_CHANGES — The primary wrapper procedure, accepting a user name and transaction identifier. It drives the application of a batch of publication items received from the client.
• GET_ERROR_MESSAGE_TEXT — A function returning a translated error message string. When its API-error flag is FALSE, it fetches the message identified by MESSAGE_NAME from FND_NEW_MESSAGES and substitutes up to three supplied token name/value pairs. When the flag is TRUE, it returns the API error currently on the FND_MSG_PUB message stack. This is the function targeted by the search term get_error_message_text.
• DELETE_RECORD — Called by the APPLY_CLIENT_CHANGES wrapper when a record applies successfully and must be purged from the in-queue. It accepts user, transaction, sequence, primary-key, object-name, and publication-name identifiers and returns an error message plus a return status.
• DEFER_RECORD — Invoked when a record fails processing and must be deferred and rejected from the mobile client.
• REJECT_RECORD — Marks a record as rejected within the synchronization queue.
• POPULATE_ACCESS_RECORDS — Establishes access records, typically populating user-level accessibility data needed during change application.
• DELETE_ACCESS_RECORDS — Removes previously created access records, providing the counterpart cleanup operation.
• AUTONOMOUS_MARK_DIRTY — Marks records as dirty using an autonomous transaction, allowing status updates to be committed independently of the caller's transaction boundary.
• TO and HANDLER — Supporting utility routines used internally by the wrapper plumbing.

Tables Accessed

The package operates against three documented tables via APPS synonyms:

• FND_NEW_MESSAGES — The message repository read by GET_ERROR_MESSAGE_TEXT to resolve a message name into a translated, token-substituted error string.
• ASG_USER — The user assignment table consulted when resolving access records and user identity during change application.
• PLITBLM — A PL/SQL index-by table type (publication item list table) used to hold publication item lists in memory while APPLY_CLIENT_CHANGES determines whether a given item name is present and removes it once matched.

Usage Notes

CSL_SERVICEL_WRAPPER_PKG is invoked primarily from the Service Logistics mobile synchronization flow. APPLY_CLIENT_CHANGES acts as the top-level entry point, and the remaining routines function as internal helpers called by it: DELETE_RECORD on success, DEFER_RECORD and REJECT_RECORD on failure, and AUTONOMOUS_MARK_DIRTY to record status changes outside the main transaction. GET_ERROR_MESSAGE_TEXT is commonly called by client-side or custom code that requires a consistent, translated error string, and it is the routine most often referenced in diagnostic and customization work. Because the package relies on AUTHID CURRENT_USER and on FND_MSG_PUB stack semantics, callers should ensure the message stack is properly initialized before relying on the API-error mode. Customizations should call the documented public routines rather than reproducing their logic, since twelve dependent packages rely on this wrapper's interface remaining stable.