Search Results create_servicerequest

Overview

The APPS.CS_SERVICEREQUEST_IUHK package body is an internal hook (IUHK) implementation within the Oracle E-Business Suite Service (CS) module. Its role is to provide user hook extension points around the core service request lifecycle operations exposed by CS_ServiceRequest_PVT. Specifically, it defines pre-processing and post-processing stubs that fire before and after the creation and update of a service request. These stubs allow Oracle or customer extensions to inject custom logic at well-defined points in the service request transaction flow without modifying the base private API.

In the Oracle EBS 12.1.1 and 12.2.2 architecture, the _IUHK suffix denotes an "Internal User Hook" package. The package is owned by APPS and classified as OTHER in the ETRM repository. Its header comment identifies it as a no-ship internal component (noship), indicating it is a delivered, unmodified hook shell rather than a customer-facing API. All four documented procedures delegate to CS_ServiceRequest_UTIL.call_internal_hook, passing the target API name, the operation name, and a timing indicator to route control to the appropriate subscribed hook.

Key Procedures and Functions

The package exposes four documented procedures, all of which return a single x_return_status output parameter indicating the outcome of the hook dispatch.

• CREATE_SERVICEREQUEST_PRE — Executed before the CS_ServiceRequest_PVT.Create_ServiceRequest operation. It invokes call_internal_hook with the 'B' (before) timing flag, enabling validation, defaulting, or attribute enrichment prior to record creation.
• CREATE_SERVICEREQUEST_POST — Executed after Create_ServiceRequest completes. It uses the 'A' (after) timing flag to trigger follow-on actions such as notifications, integration messages, or dependent record creation once the service request exists.
• UPDATE_SERVICEREQUEST_PRE — Runs before CS_ServiceRequest_PVT.Update_ServiceRequest, again with the 'B' timing flag, allowing pre-update validation or capture of prior values.
• UPDATE_SERVICEREQUEST_POST — Runs after Update_ServiceRequest with the 'A' timing flag, supporting post-update side effects such as audit logging or downstream synchronization.

Tables Accessed

The ETRM metadata records no direct table references for this package via APPS synonyms. This is consistent with its design as a thin dispatch layer: all substantive database access is performed by the target API CS_ServiceRequest_PVT and by whichever customer or Oracle hook implementations are registered through CS_ServiceRequest_UTIL.call_internal_hook. Any tables read or written during pre/post processing are therefore determined by the subscribed hook bodies rather than by this package itself.

Usage Notes

This package is not intended for direct invocation by forms, concurrent programs, or custom code. It is referenced by one other package (per ETRM), and it functions purely as a callback target wired into the service request lifecycle. The extension mechanism is indirect: developers register their own logic against the named hooks, and CS_ServiceRequest_UTIL.call_internal_hook dispatches to those registrations using the API name, operation, and timing flag passed here.

Because the header is versioned as 120.1 and marked noship, the object should be treated as a delivered baseline that Oracle may update during patching. Customizations should never be coded directly into CS_SERVICEREQUEST_IUHK; instead, they belong in the registered hook implementations. When troubleshooting service request creation or update anomalies in 12.1.1 or 12.2.2, this package is a useful marker for confirming which pre- and post-processing hooks are wired to the CS_ServiceRequest_PVT operations, and the returned x_return_status from each procedure provides the first indication of whether a custom hook raised an error during the transaction.