Search Results asp_svccont_content_provider




Overview
Explore in AI Chat

Overview

ASP_SVCCONT_CONTENT_PROVIDER is an Oracle E-Business Suite PL/SQL package owned by the APPS schema that supplies content for the Service Contracts Alert within the Oracle Workflow notification framework. The package header carries the header identifier aspasccs.pls 120.0, dated 19-August-2005, and its ETRM classification is listed as OTHER, indicating that it is an internal supporting component rather than a public, published API.

The package exists to bridge Oracle Service Contracts business data with the Workflow notification engine. When a Service Contracts Alert is raised, the Workflow engine requires the body of the message to be generated dynamically from the underlying contract, party, and header records. ASP_SVCCONT_CONTENT_PROVIDER performs that generation: it is the callback package responsible for composing the content that appears to the recipient of the alert. The package was created on 16-August-2005 by the developer identified in the source history as axavier, and it remains part of the shipped Service Contracts code base in both Oracle EBS 12.1.1 and 12.2.2, with no documented successor API.

Key Procedures and Functions

The package exposes a single documented routine, CREATE_CONTENT, which provides content for the Service Contracts Alert. Its purpose is to build the notification body presented to the alert recipient based on the Workflow item context passed into it.

The ETRM documentation records no additional public procedures or functions beyond CREATE_CONTENT; the header declares only public constants, datatypes, variables, and routines sections, all empty except for the routine area. Because Create_Content is documented as the sole interface, callers should treat the package as a single-purpose content provider rather than a general utility library. No parameter lists are reproduced here; the documented argument semantics are confined to the standard Workflow callback contract discussed in the Usage Notes section.

Tables Accessed

ETRM metadata identifies four underlying objects referenced through APPS synonyms:

  • OKC_K_HEADERS_ALL_B — the Service Contracts header base table, supplying the contract identity and header-level attributes used in the alert text.
  • OKC_K_PARTY_ROLES_B — the contract party role base table, providing the roles associated with the contract for addressing and contextual information.
  • OKS_K_HEADERS_B — the Service Contracts (support) header base table, which supplies service-specific contract attributes.
  • HZ_PARTIES — the Trading Community Architecture party table, used to resolve party names and identifying details displayed in the notification.

These accesses are consistent with a content provider that must join contract headers to their parties and roles in order to render a meaningful alert message. No insert, update, or delete behavior is indicated by the metadata; the package is a read-oriented content generator.

Usage Notes

ASP_SVCCONT_CONTENT_PROVIDER is invoked by the Oracle Workflow engine, not by end users directly. When a Service Contracts Alert activity executes, Workflow calls Create_Content with the item type, item key, activity instance identifier, function mode, and a result output parameter, and expects the routine to return content for the notification. This is the standard content-provider pattern in Workflow: the function mode is set by the engine to values such as RUN, CANCEL, or TIMEOUT, and the result output is returned as COMPLETE:SUCCESS or NULL. The package is therefore configured as the content provider attribute of a Workflow notification activity rather than being called from a form or concurrent program.

Because the package is classified as OTHER and is not a published API, it should not be called directly from custom code. Customizations that need Service Contracts alert content should instead extend or replicate the Workflow notification configuration. ETRM records zero packages referencing ASP_SVCCONT_CONTENT_PROVIDER, confirming that it sits at the edge of the dependency graph and is consumed only by the Workflow runtime.