Search Results jtf_rs_group_usage

Overview

The APPS.JTF_RS_GROUP_USAGES_PUB package is a public PL/SQL API in Oracle E-Business Suite that maintains information about resource group usages within the CRM Foundation (JTF) product. Resource groups represent logical collections of resources, and a "group usage" associates a specific usage code with a resource group, thereby governing how and where that group may be applied. This package provides the supported entry point for creating and deleting these group-usage associations against the underlying JTF_RS_GROUP_USAGES table.

The package is declared with AUTHID CURRENT_USER, meaning it executes with the privileges of the calling user rather than the package owner. Per the ETRM classification it is registered in the JTF product with an internal scope and a business entity of JTF_RS_GROUP_USAGE, with the display name "Group Usages Package." Its header identifies it as a public API whose procedures invoke corresponding logic in the private package jtf_rs_group_usages_pvt, which performs business validations and the actual inserts and updates. This two-layer pattern—PUB wrapper over PVT implementation—is the standard Oracle Application Framework API convention and ensures that validation logic remains centralized and consistent across all callers.

Key Procedures and Functions

The documented public interface exposes two procedures:

• CREATE_GROUP_USAGE — Creates a resource group usage based on input values passed by the calling routine. The documented parameter set includes the API version, an initialization flag, a commit flag, the group identifier and group number, the usage code, and output parameters for return status, message count, message data, and the unique internal identifier of the newly created group usage. Its display name in the repository is "Create Group Usage," and it is classified as internal scope.
• DELETE_GROUP_USAGE — Removes an existing resource group usage record. As with the create procedure, validation and database maintenance are delegated to jtf_rs_group_usages_pvt; the public procedure serves as the supported, message-enabled entry point.

Both procedures follow the standard Oracle API contract: an API version parameter, message-list initialization and commit flags, and the standard X_RETURN_STATUS, X_MSG_COUNT, and X_MSG_DATA output parameters that allow callers to detect success or failure and retrieve user-facing error messages. Callers should always check return status rather than relying on exceptions alone.

Tables Accessed

The package operates on the JTF_RS_GROUP_USAGES table, reached through an APPS synonym. This table stores the association between a resource group and a usage code, and it is the sole documented table referenced by the API. The create procedure inserts new association rows, while the delete procedure removes them. All direct DML is performed through the private implementation package after business validations—such as confirming that the group and usage code are valid and that no duplicate association exists—have been applied. Because access is mediated by the private layer, the public API remains the only sanctioned means of maintaining this table and preserves referential and business integrity.

Usage Notes

This package is typically invoked from resource-management forms, concurrent programs, and custom extensions that need to programmatically associate or disassociate usage codes with resource groups. In Oracle EBS 12.1.1 and 12.2.2, it is referenced by five other packages, indicating it is an embedded dependency of higher-level resource and group management flows rather than a standalone utility.

When calling the API, developers should initialize the message list, set the commit flag appropriately within a transaction boundary, and validate the returned status and message data before proceeding. Because the package uses AUTHID CURRENT_USER, the calling schema requires appropriate privileges on the underlying table and on the private implementation package. Direct DML against JTF_RS_GROUP_USAGES should be avoided, as it bypasses the validations enforced by this API and may leave inconsistent resource group definitions.