Search Results concurrent_history




Overview
Explore in AI Chat

Overview

APPS.CSL_SERVICE_HISTORY_PKG is a PL/SQL package that supports the service history feature within Oracle E-Business Suite's field service and service request functionality. The package is responsible for identifying, calculating, and persisting historical service request data associated with a given resource, most commonly a field service technician or support agent. Its central business purpose is to allow the application to determine how many prior service requests should be retained and surfaced as history for a resource, and to maintain that history as incidents are closed and new work is processed.

The package version header indicates a single-line revision (120.0, dated 2005) with the "noship" designation, meaning this is an internal, non-shipped component typically leveraged by other EBS modules rather than exposed directly to end users. In ETRM 12.2.2 the package is classified as API classification OTHER and is owned by APPS.

A notable integration characteristic is that the package is referenced by one other package, indicating that its functions are consumed programmatically rather than through a standalone interface. The function that most users and developers search for, GET_HISTORY_COUNT, is the entry point that determines the retention threshold applied throughout the package's other operations.

Key Procedures and Functions

The package exposes four documented subprograms:

  • GET_HISTORY_COUNT — A function that returns the history count permitted for a specified resource. It accepts a resource identifier and returns a numeric value. This value governs how many historical service requests are preserved and presented for that resource.
  • CALCULATE_HISTORY — A procedure that calculates the history of service requests for a given service request and resource pairing. It applies the retention logic to determine which records should be considered part of the resource's service history.
  • DELETE_HISTORY — A procedure that removes all history records associated with a given service request and resource. This supports cleanup and the maintenance of the retention boundary defined by the history count.
  • CONCURRENT_HISTORY — A procedure designed to be invoked from a concurrent program. It loops over an accumulation table to gather incidents and process them into history records in bulk.

These four subprograms operate as a cohesive set: the function establishes the retention rule, CALCULATE_HISTORY applies it for individual requests, DELETE_HISTORY enforces it by purging excess records, and CONCURRENT_HISTORY scales the population process across the incident accumulation table.

Tables Accessed

The package reads and writes several base and interface tables through APPS synonyms. The primary accumulation source is CSL_CS_INCIDENTS_ALL_ACC, which CONCURRENT_HISTORY loops over to gather incidents for history generation. Service request data is drawn from CS_INCIDENTS_ALL_B and CSL_CS_INCIDENTS_ALL_ACC, while status context comes from CS_INCIDENT_STATUSES_B. The history records themselves are stored in and removed from CSL_SERVICE_HISTORY.

Task-related information is sourced from JTF_TASKS_B, JTF_TASK_ASSIGNMENTS, JTF_TASK_STATUSES_B, and JTF_TASK_TYPES_B, reflecting the linkage between service requests and the tasks assigned to resources. Resource and user context is obtained from ASG_USER. Additional supporting data comes from JTM_CON_REQUEST_DATA, and PLITBLM is referenced as a PL/SQL index-by table type used for in-memory processing during the concurrent loop.

Usage Notes

CSL_SERVICE_HISTORY_PKG is typically invoked by other EBS packages rather than called directly from forms. The presence of CONCURRENT_HISTORY indicates that a concurrent program is registered to periodically process accumulated incidents and materialize history records. Developers customizing or extending service history behavior should call GET_HISTORY_COUNT to retrieve the applicable retention threshold before invoking CALCULATE_HISTORY or DELETE_HISTORY, and must supply valid incident and resource identifiers consistent with the calling context. Because the package is internal and non-shipped, its behavior should be validated against the supported EBS release (12.1.1 or 12.2.2) before reliance in custom extensions.