Search Results tasks_post_update

Overview

CSF_ACCESS_PKG is a procedural PL/SQL package owned by the APPS schema in Oracle E-Business Suite, classified under the ETRM API taxonomy as OTHER. The package supports the access-control and event-propagation layer of the Oracle TeleService and Field Service product family, operating primarily against the ASG (Access Server Gateway / mobile access) tables and the core customer-service schema. Its declared header uses AUTHID CURRENT_USER, meaning that name resolution and privilege checks are evaluated against the invoking schema rather than the package owner.

Functionally, the package performs two related roles. The first is maintenance of mobile-user access records, exemplified by UpdateMobileUserAcc, which synchronizes a resource and server combination against the ASG access tables. The second and larger role is the execution of database trigger handlers. Rather than embedding logic directly inside the DML triggers on service-request, task, and task-assignment tables, Oracle delivers the trigger bodies as thin wrappers that call procedures in CSF_ACCESS_PKG. The convention is reflected in the procedure names: POST_INSERT, PRE_UPDATE, POST_UPDATE, and PRE_DELETE variants exist for incidents, tasks, and task assignments.

Key Procedures and Functions

The 18 documented procedures divide into three groups.

• Access maintenance: UpdateMobileUserAcc maintains mobile-user access rows for a given resource and server.
• Trigger handlers (DML phase): INCIDENT_POST_INSERT, INCIDENT_PRE_UPDATE, and INCIDENT_POST_UPDATE handle service-request lifecycle events. TASKS_POST_INSERT, TASKS_PRE_UPDATE, TASKS_POST_UPDATE, and TASKS_PRE_DELETE cover the JTF task entity. TASK_ASSIGN_POST_INSERT, TASK_ASSIGN_PRE_UPDATE, TASK_ASSIGN_POST_UPDATE, and TASK_ASSIGN_PRE_DELETE cover task assignments. Each returns an x_return_status OUT parameter so the calling trigger can raise an error and roll back the transaction.
• Trigger handlers (business-event): INCIDENT_TRIGGER_HANDLER, TASKS_TRIGGER_HANDLER, TASK_ASSIGN_TRIGGER_HANDLER, SR_CONTACT_TRIGGER_HANDLER, and CUST_RELATIONS_TRIGGER_HANDLER receive old and new column values together with a trigger_mode argument. This mode string is the discriminator that tells the handler which DML operation fired (INSERT, UPDATE, or DELETE), allowing a single routine to service multiple trigger points and to evaluate attribute changes between the o_ (old) and n_ (new) parameter sets. INCIDENT_TRIGGER_HANDLER, for example, compares old and new customer identifiers to detect reassignment of a service request. CUST_RELATIONS_POST_INSERT supplements this set for the customer-relations entity.

Tables Accessed

Access is performed through APPS synonyms. The ASG tables — ASG_DEVICE_USERS, ASG_INCIDENT_ACC, ASG_PARTY_ACC, ASG_SERVER_RESOURCES, and ASG_TASK_ACC — hold the mobile access-control mappings that determine which devices, servers, parties, and resources may view service requests and tasks. The service-data tables are CS_INCIDENTS_ALL and CS_INCIDENTS_ALL_B (service requests), JTF_TASKS_B and JTF_TASK_ASSIGNMENTS (tasks and their assignments), JTF_TASK_TYPES_B (task-type lookup), CS_HZ_SR_CONTACT_POINTS and CSP_RS_CUST_RELATIONS (contact points and customer relations), and the TCA tables HZ_CUST_ACCT_SITES_ALL and HZ_PARTY_SITES for account-site and party-site context. DBMS_SQL appears as a referenced package, indicating dynamic SQL is used somewhere within the implementation.

Usage Notes

CSF_ACCESS_PKG is not a user-invoked API. It is an internal implementation package whose procedures are bound to database triggers on the CS and JTF base tables; the handlers execute implicitly whenever a service request, task, or task assignment is inserted, updated, or deleted through the standard TeleService forms, the Service Requests window, or the HTML-based service applications. Because the DML-phase handlers return x_return_status, failures surface to the end user as form or page errors rather than silent exceptions. The ETRM metadata records zero dependent packages, so direct calls from custom code are not an intended integration path; extensions should attach to the documented trigger points or use the supported CS_SERVICEREQUEST_PUB and task public APIs instead. The trigger_mode parameter is meaningful only inside the handler calls and is populated by the firing trigger, not by external callers.