Search Results csm_query_b_s

Overview

APPS.CSM_MOBILE_QUERY_PKG is a PL/SQL package body in Oracle E-Business Suite that supports the Mobile Field Service / Customer Support mobile client with respect to saved query definitions. The package name and its internal globals — g_object_name set to 'CSM_MOBILE_QUERY_PKG' and the publication names 'CSM_QUERY' and 'CSM_QUERY_VARIABLES' — identify it as part of the CSM (Customer Support / Service) mobile synchronization layer. Its primary business function is to receive query definitions and query variable definitions that a mobile client has created or modified while disconnected, and to apply those changes into the server-side repository tables so that saved queries, their parameters, and their output attributes are persisted and available to other users and processes.

The header revision string (csmuqryb.pls 120.5 2009/10/22) indicates the package is a long-standing, shipped object rather than a custom extension. The ETRM classification of the package is OTHER, and one procedure, APPLY_CLIENT_CHANGES, is formally documented for release 12.2.2.

Key Procedures and Functions

The documented package interface exposes one procedure, APPLY_CLIENT_CHANGES. Consistent with mobile synchronization design in EBS, this procedure is the entry point invoked by the mobile upload/synchronization framework to reconcile the set of query and query-variable records created on the client with the corresponding server tables. It drives the insert, update, and delete operations required to bring the server repository into agreement with the mobile client's state.

The package body source additionally exposes a procedure named INSERT_QUERY, declared with IN parameters describing the query header (query ID, name, description, type, query text, level information, parent query, saved-query flag, output format, MIME type, workflow, retention policy and days, template and template file, execution mode) and collection parameters for query variables (CSM_VARCHAR_LIST and CSM_DATE_LIST for variable name, type, character value, date value, hidden flag, and default flag), returning x_return_status and x_error_message. INSERT_QUERY is described in the source as being called during upload to insert a saved query created in the mobile client. It obtains a new key from the CSM_QUERY_B_S sequence and generates a response identifier via a cursor over the parent query ID. Because INSERT_QUERY is not listed among the procedures documented in the ETRM 12.2.2 metadata for this package, it should be treated as an internal helper rather than a published API; deployers should not depend on it directly.

Tables Accessed

The package operates over the query repository and its mobile staging/inbound counterparts:

• CSM_QUERY_B and CSM_QUERY_B_S — the base query definition table and its sequence, holding query headers and supplying new query identifiers.
• CSM_QUERY_TL — the translation table for query names and descriptions.
• CSM_QUERY_VARIABLES_B — the base table storing query variable definitions (name, type, value, flags).
• CSM_QUERY_INQ — the inbound queue table read by the package's c_query cursor, keyed by tranid$$ and clid$$cs.
• CSM_QUERY_VARIABLES_INQ — the inbound queue for query variables, read by the c_query_var_inq cursor and further filtered by QUERY_ID.
• ASG_USER — the resource/user assignment table, consulted to resolve the mobile client user to a valid server-side owner.
• DUAL and PLITBLM — the sequence-selection and PL/SQL index-by table utility objects used internally.

Usage Notes

CSM_MOBILE_QUERY_PKG is not intended for direct invocation by end users. It is called by the mobile synchronization infrastructure when a client uploads its transaction records; the INQ cursors keyed on tranid$$ and clid$$cs reflect the standard CSM mobile inbound-queue conventions. It may also be referenced by one other package, per the ETRM dependency data. Customizations should avoid calling INSERT_QUERY directly and should instead use the documented APPLY_CLIENT_CHANGES entry point, ensuring that x_return_status and x_error_message are validated after each call. Because the package pre-dates 12.1.1 and remains shipped through 12.2.2, any extension should be implemented as a wrapper rather than by modifying the seeded package body.