Search Results p_security_group_id

Overview

CS_SR_TSK_TMPL_SEQ_RULES_PKG is a private PL/SQL package body in the APPS schema that provides the data-access layer for the CS_SR_TSK_TMPL_SEQ_RULES table. This table stores the sequencing rules that determine the order in which service request task templates are applied during the task generation process in Oracle TeleService / Service (CS) modules. The package encapsulates the standard Oracle EBS "table handler" pattern: it centralizes the Create, Update, Delete, Lock, and Load operations so that the base table is never manipulated directly by forms or concurrent programs.

The source header ($Header: cstskrlb.pls 120.0 2006/03/07) indicates the package body has been stable since the R12 development cycle and is shipped unchanged into 12.1.1 and 12.2.2. Its classification in the ETRM repository is OTHER, meaning it is an internal implementation package rather than a public, supported API.

The parameter p_security_group_id that the user searched for appears on most of the package's procedures. It carries the Multi-Org / security-group context that Oracle Applications use to partition data by operating unit or security group, and is persisted directly into the SECURITY_GROUP_ID column of the base table.

Key Procedures and Functions

• INSERT_ROW — Inserts a new sequencing-rule row. It accepts the row's business columns (search rule code, sequence, active flag, object version number, security group id) plus the standard WHO audit columns, and returns the generated ROWID to the caller so that the form can re-query the block. P_SECURITY_GROUP_ID is written straight into the SECURITY_GROUP_ID column.
• LOCK_ROW — Issues a SELECT ... FOR UPDATE NOWAIT against CS_SR_TSK_TMPL_SEQ_RULES keyed on SEARCH_RULE_ID and OBJECT_VERSION_NUMBER, then compares the fetched ACTIVE_FLAG, SECURITY_GROUP_ID, SEARCH_RULE_CODE, and SEARCH_SEQUENCE against the values passed in. This implements optimistic locking: if the row has changed underneath the user, the form raises a "record has been modified" error rather than silently overwriting.
• UPDATE_ROW — Updates an existing rule row, carrying the same column set as INSERT_ROW and re-validating the object version number.
• DELETE_ROW — Physically removes a sequencing-rule row identified by its primary key.
• LOAD_ROW — Performs the insert-or-update logic used by the Applications seed/loader utilities, allowing rows to be uploaded from .ldt definitions without generating duplicates.

Tables Accessed

The package touches a single documented table, CS_SR_TSK_TMPL_SEQ_RULES, accessed through its APPS synonym. INSERT_ROW and LOAD_ROW write to it; UPDATE_ROW and DELETE_ROW modify or remove rows; LOCK_ROW reads it with a row-level lock. The SECURITY_GROUP_ID column is one of the columns written and compared, reinforcing the multi-org-aware design. No other tables are referenced, and the package is referenced by zero other packages, confirming its role as a leaf-level table handler.

Usage Notes

Because the ETRM classification is OTHER and no external package depends on it, CS_SR_TSK_TMPL_SEQ_RULES_PKG is normally invoked indirectly. In a standard EBS 12.1.1 or 12.2.2 environment it is called by the Oracle Forms block that maintains task-template sequencing (the CSE/CS forms family) and by concurrent or loader programs that seed sequencing rules. Custom code should not call INSERT_ROW, LOCK_ROW, UPDATE_ROW, or DELETE_ROW directly; instead, developers should treat the underlying table as owned by Oracle and use the supported Service APIs, or, where absolutely required, call LOAD_ROW during controlled data migrations. Direct DML risks bypassing the object-version and security-group checks embedded in this package and can leave rows inconsistent with what the forms expect.