Search Results contact_point_upd_wf_event_sub




Overview
Explore in AI Chat

Overview

APPS.CSM_SR_CONTACT_EVENT_PKG is a server-side PL/SQL package body that manages the contact-point access records associated with service requests in Oracle E-Business Suite. Its central responsibility is to keep the CSM_SR_CONTACTS_ACC access-control table synchronized with the underlying service-request contact points stored in CS_HZ_SR_CONTACT_POINTS, and to notify the Access Control framework (CSM_ACC_PKG) whenever those records change. In this way the package enforces per-user visibility of service-request contacts: only users who hold a row in the access table for a given SR contact point are able to view or act upon it.

The package follows the standard Oracle EBS "event package" pattern. Each DML operation on the source table is paired with a procedural entry point that marks the corresponding access rows dirty, and with a "spawn userloop" routine that fans the update out across every user holding access. The source header identifies the module as csmesrcb.pls, with a last revision dated 2005/07/25, placing it in the mature service (CS) module codebase that remains present in both 12.1.1 and 12.2.2.

Key Procedures and Functions

  • SR_CNTACT_MDIRTY_U_FOREACHUSER — Iterates the users who hold access to a single service-request contact point and invokes CSM_ACC_PKG.Update_Acc for each one, propagating the publication item CSF_M_SR_CONTACTS. It is the row-level workhorse called by the insert, update, and delete events.
  • SR_CNTACT_MDIRTY_I — Marks access records dirty following an insert into the service-request contact point table.
  • SR_CNTACT_MDIRTY_D — Marks access records dirty following a delete, removing or invalidating the corresponding access entries.
  • SPAWN_USERLOOP_SR_CONTACT_INS — Initiates the per-user access loop for newly created SR contact points, typically by deferring the user-by-user processing.
  • SPAWN_USERLOOP_SR_CONTACT_DEL — The delete-side counterpart, initiating the user loop that cleans up access when an SR contact point is removed. This is the procedure referenced by the search term spawn_userloop_sr_contact_del.
  • CONTACT_POINT_UPD_WF_EVENT_SUB — A Workflow event subscription handler that reacts to contact-point update events raised through the WF_EVENT_T queue, driving the dirty-marking logic in response to business events rather than direct DML.

Tables Accessed

  • CSM_SR_CONTACTS_ACC — The access-control table that stores one row per user/SR contact point combination. The package reads it to determine which users require notification and updates it via CSM_ACC_PKG.
  • CS_HZ_SR_CONTACT_POINTS — The base service-request contact point table whose inserts, updates, and deletes trigger the dirty-marking procedures.
  • CSM_INCIDENTS_ALL_ACC — Access records for incidents, consulted as part of the access-control framework linkage.
  • HZ_CONTACT_POINTS — The TCA contact-point master from which SR contact points are derived.
  • WF_EVENT_T — The Oracle Workflow event queue used by CONTACT_POINT_UPD_WF_EVENT_SUB to receive and process business events.

Usage Notes

CSM_SR_CONTACT_EVENT_PKG is not normally invoked directly by end users. It is called by the service-request forms and by database triggers on the service contact point tables so that access records remain consistent whenever a contact point is added, changed, or removed. Administrators and developers encounter the SPAWN_USERLOOP_SR_CONTACT_DEL and SPAWN_USERLOOP_SR_CONTACT_INS procedures when diagnosing why a user can still see, or can no longer see, a service-request contact after it was modified.

The package is referenced by two other packages, which typically invoke it as part of the service request contact maintenance flow. Because the publication item is registered as CSF_M_SR_CONTACTS, any customization that alters SR contact visibility must respect the CSM_ACC_PKG contract; bypassing this package will leave the access table out of step with the contact points and produce incorrect visibility in the Service Request forms. Use FND_LOG diagnostics (via CSM_UTIL_PKG.LOG) when tracing execution, since the procedures emit entry and exit messages at procedure level.