Search Results pre_integration

Overview

OKS_OMIB_INT_EXTNS_PUB is a public PL/SQL package body owned by APPS within the Oracle E-Business Suite Service Contracts (OKS) module. Its purpose is to expose extension hooks that the Order Management Integration Broker (OMIB) invokes at defined points when service contract lines are created, updated, or otherwise manipulated through order-to-contract integration flows. The OMIB process synchronizes Oracle Order Management order lines with Service Contracts instances, and OKS_OMIB_INT_EXTNS_PUB provides the extension framework that development teams can use to inject custom pre-processing and post-processing logic into that synchronization without modifying Oracle's seeded code.

The package is classified as a PUB (public) API and follows Oracle's standard PL/SQL API conventions, including the FND_API message-handling model, FND_MSG_PUB initialization controlled by the p_init_msg_list parameter, and the FND_LOG instrumentation for debugging. Global constants such as G_PKG_NAME, G_MODULE_CURRENT, and G_APP_NAME (set to 'OKS') establish the logging and error-token framework used throughout the body. Because it is an extension point, the seeded implementation generally performs minimal work by default, returning a process status that instructs the caller to continue with standard processing.

Key Procedures and Functions

The documented public interface contains two procedures:

• PRE_INTEGRATION — Invoked immediately before the integration logic that links an order line to a Service Contracts instance. Its parameters carry the API version, message-list initialization flag, a flag indicating whether the call originates from the integration layer, the transaction type and date, the order line identifier, and the old and new instance identifiers. The procedure exposes output parameters for process status, return status, message count, and message data. In the seeded body, the logic initializes the message stack when requested, sets x_process_status to 'C' (Continue), assigns the standard FND_API return status, and writes a begin marker to the FND log. This gives implementers a controlled interception point to validate data, derive attributes, or abort processing before the core integration executes.
• POST_INTEGRATION — Invoked after the integration processing completes, allowing custom code to react to the newly created or modified contract instance. It follows the same API conventions as PRE_INTEGRATION, using the shared global constants and message-handling routines defined at the top of the package body.

Both procedures follow the standard EBS API signature pattern, including NOCOPY OUT parameters for performance, and both are registered for FND_LOG procedure-level tracing.

Tables Accessed

The ETRM metadata for this package does not document any direct table references through APPS synonyms. This is consistent with its role as a lightweight extension stub: the seeded implementation performs only message initialization, logging, and status assignment, delegating all persistent data manipulation to the OMIB integration packages that call it. Customers implementing the extension points would introduce their own DML against Service Contracts, Order Management, or custom tables, but such references are not part of the delivered package.

Usage Notes

OKS_OMIB_INT_EXTNS_PUB is referenced by two other packages, which act as its callers within the integration flow. Rather than being invoked directly from a form or concurrent program, it is called programmatically during order-to-contract integration processing. The "pre_integration" search term reflects the most common reason developers locate this object: they need a hook that fires before the integration commits changes, so they can inspect or alter the order line and instance mapping. Typical customization patterns include copying order line descriptive flexfield values into contract attributes, performing validation that should prevent integration, or recording audit information. Because the procedure returns x_process_status, customizations must respect the contract that 'C' means continue; returning other values can influence whether the caller proceeds. Implementations should preserve the FND_API error-handling structure, raise errors through FND_MSG_PUB rather than unhandled exceptions, and be mindful that this package exists in both 12.1.1 and 12.2.2 with essentially unchanged behavior. All modifications should be applied through the supported customization mechanism rather than direct edits to the seeded APPS package.