Search Results okc_wf_notify_s1




Overview
Explore in AI Chat

Overview

OKC_ASYNC_PUB is the public asynchronous processing interface within the Oracle Contracts (OKC) module of Oracle E-Business Suite. Its function is to deliver contract-related notifications, calls, and document dispatches through Oracle Workflow without blocking the calling session. Rather than executing a contract action synchronously, the package queues a Workflow item and lets the Workflow Engine raise events, send notifications, and invoke resolvers in the background. This design is what allows contract authoring, approvals, and lifecycle events in ETRM (Enterprise Contracts) to proceed interactively while downstream notification work is handled asynchronously.

The ETRM metadata classifies OKC_ASYNC_PUB as a PUB (public) API, meaning it is intended for invocation by other application code and by custom extensions, not merely as an internal helper. In Oracle EBS 12.1.1 and 12.2.2 the package body carries a status of VALID in the APPS schema. It is self-contained in the sense that it is not referenced by any other database object, but it depends on a small set of core Workflow and Contracts packages to carry out its work.

Key Procedures and Functions

The ETRM documentation records eight documented procedures/functions. Their names indicate the asynchronous call patterns they support:

  • PROC_CALL — the general-purpose entry point that initiates an asynchronous call through Workflow, typically used to defer a contract procedure for background execution.
  • MSG_CALL and PROC_MSG_CALL — variants that pair an asynchronous call with a message payload, allowing structured data or notification content to be delivered with the deferred operation.
  • RESOLVER_CALL — raises the call so that a Workflow function/notification resolver can be resolved later, which is the mechanism used to link contract data to an outbound Workflow notification.
  • SEND_DOC — dispatches a contract document as part of the asynchronous notification flow.
  • PROC_STOP — terminates or halts an in-flight asynchronous operation associated with the Workflow item.
  • LOOP_CALL — supports iterative or repeated asynchronous calls, for example notifying multiple recipients or processing a set of contract lines.

The absence of PROC_START in the documented list, combined with the presence of PROC_CALL, indicates that the package is oriented toward enqueueing and controlling Workflow-driven work rather than opening a long-running synchronous session.

Tables Accessed

The package references three documented tables via APPS synonyms:

  • OKC_WF_NOTIFY_S1 — the key Workflow notification staging table in the Contracts module. It holds the data needed to build a Workflow notification for a contract event. Because the object name searched (okc_wf_notify_s1) is a Contracts Workflow notification table, it is the primary data source for OKC_ASYNC_PUB's notification calls and is central to MSG_CALL, PROC_MSG_CALL, RESOLVER_CALL, and SEND_DOC.
  • WF_ITEMS — the Oracle Workflow runtime item table. The package reads/uses it to locate and manage the Workflow item representing the asynchronous operation, which is essential for RESOLVER_CALL and PROC_STOP.
  • DUAL — used for single-row expressions and lookups standard in PL/SQL packages.

In addition, the dependency list shows the package relies on FND_API, FND_PROFILE, OKC_API, OKC_ASYNC_PVT, OKC_DEBUG, WF_ENGINE, and OKC_WF_NOTIFY_S1. These supply API error handling, profile lookups (for things such as the notification workflow and mailer settings), contract API helpers, the private async implementation, and the Workflow Engine that actually starts the item and processes the async queue.

Usage Notes

OKC_ASYNC_PUB is normally invoked indirectly. ETRM forms, contract approval flows, and concurrent programs call the public Contracts APIs; those APIs in turn call OKC_ASYNC_PUB to enqueue Workflow notifications rather than sending them inline. Custom code and workflow callbacks can also call the package directly to raise a notification for a contract event or to send a document to a recipient.

Because the package is a PUB API, it is the supported customization point: extensions should call PROC_CALL, MSG_CALL, RESOLVER_CALL, or SEND_DOC rather than the private OKC_ASYNC_PVT. When customizations are made, they must remain compatible with the Workflow item structure defined by OKC_WF_NOTIFY_S1 (the item type and item key), because RESOLVER_CALL and PROC_STOP depend on locating that item in WF_ITEMS. In 12.2.2 the object documentation lists it as referenced by seven other packages, confirming it is a shared dependency across the Contracts and Workflow notification stack rather than a standalone utility.