Search Results g_running

Overview

JTM_CON_QUERY_REQUEST_PKG is an Oracle E-Business Suite PL/SQL package owned by the APPS schema and classified as an OTHER API within the ETRM (E-Business Suite Technical Reference Manual) taxonomy. Its name and interface indicate that it belongs to the JTM (TeleService / Field Service) product family and specifically to a "CON" (contact or connection) query-request validation subsystem. The package provides the server-side engine that evaluates the integrity and configuration of query requests, most notably those driven by Oracle's descriptive flexfield (DFF) infrastructure. Its responsibilities centre on executing diagnostic queries against attributes belonging to contacts, resources, and public users, and on reporting the resulting status back to the caller through OUT parameters. The presence of constants such as G_FINE, G_WARNING, G_ERROR, and G_RUNNING demonstrates that the package implements a lightweight status-classification model, permitting calling code to distinguish a clean result from a warning, a fatal error, or an in-progress execution. In release terms, the header comment (jtmconqs.pls 120.1, dated 2005) shows the package is a long-standing component carried forward from 11i into 12.1.1 and 12.2.2 with no structural change; it is not a public, supported integration API but a utility package, and only one other package references it, confirming its narrow internal role.

Key Procedures and Functions

• RUN_QUERY_REQUESTS — the principal entry point. Two overloads exist: one that returns a status and a message to the caller, and one without OUT parameters. The procedure executes the collection of diagnostic queries that the package is designed to perform and, in the overloaded form, communicates the outcome using the G_FINE / G_WARNING / G_ERROR / G_RUNNING constants. It is this procedure that the search term "run_query_requests" resolves to.
• WORKAROUND — a remediation routine whose name indicates it exists to correct or bypass a known defect or data condition detected by the query requests. It is typically invoked after RUN_QUERY_REQUESTS reports a non-Fine status.
• FIX_DFF_ACC — a corrective procedure, again exposing status and message OUT parameters, targeted specifically at the DFF access ("ACC") tables. It is used to repair or resynchronise descriptive flexfield accessibility data for the relevant JTM entities.

Tables Accessed

The package reads and writes a mixture of base application tables (through APPS synonyms) and JTM-owned shadow or accumulator ("_ACC") tables. The base tables include ASG_PUB_ITEM, ASG_USER, and ASG_USER_PUB_RESPS from the resource/user model, together with the flexfield definition tables FND_DESCR_FLEX_COLUMN_USAGES and FND_FLEX_VALUES. The query-request data itself resides in JTM_CON_QUERY_REQUEST_DATA and JTM_CON_REQUEST_DATA. The remaining objects — JTM_FND_DESCR_FLEXS_ACC, JTM_FND_DESC_FLEX_COL_USG_ACC, JTM_FND_DESC_FLEX_CONTEXT_ACC, JTM_FND_FLEX_VALUES_ACC, JTM_FND_FLEX_VALUE_SETS_ACC, and JTM_PUB_ACC — are the JTM-side mirrors of the corresponding FND flexfield structures. This pattern reveals the package's purpose: it validates that the JTM copies of the descriptive flexfield metadata are consistent with the FND master data, and FIX_DFF_ACC repairs any divergence it finds. The inclusion of DBMS_SQL and PLITBLM shows that queries are constructed dynamically and that PL/SQL index-by tables are used for intermediate result sets.

Usage Notes

JTM_CON_QUERY_REQUEST_PKG is not exposed through concurrent program registration or a public API layer; it is invoked from Oracle TeleService and Field Service application logic and from the single dependent package that references it. In practice it is executed during setup verification, post-patch validation, or troubleshooting of contact and resource query behaviour in 12.1.1 and 12.2.2, where an administrator or support engineer runs the query requests to confirm flexfield-driven selections resolve correctly, and then applies WORKAROUND or FIX_DFF_ACC if errors are returned. Because it manipulates flexfield accessibility data directly, it should be invoked only in controlled diagnostic scenarios, with FND flexfield structures already compiled, and never from custom code that assumes an unsupported interface.