Search Results delete_associations

Overview

The APPS.IBC_ASSOCIATIONS_GRP package is a Group-type PL/SQL API within the Oracle E-Business Suite iMarketing/IBC content management layer. It provides the programmatic interface for maintaining associations between external business objects and content items managed by the IBC (Internet Business Center) repository. An "association" is the mapping that links a content item — optionally pinned to a specific version — to one or more external objects identified by a type code and up to five generic object key columns. This mechanism allows applications such as iStore, iMarketing, and partner/customer portals to relate stored content to arbitrary business entities (for example, products, categories, or campaigns) without hard-coding foreign keys into the content schema. The package is declared AUTHID CURRENT_USER, so it executes with the privileges of the calling schema rather than the definer. A shared constant, G_OBJ_VERSION_DEFAULT (value 1), supplies the default object version used in association records. The header identifies the file as ibcgasss.pls, version 115.6.

Key Procedures and Functions

Twelve documented entry points are exposed. The singular and plural variants allow both single-record and bulk (array-based) processing, following the standard Oracle EBS API convention of an p_api_version input, an p_init_msg_list flag, an p_commit flag, and the standard x_return_status, x_msg_count, and x_msg_data outputs.

• CREATE_ASSOCIATION — Creates a single association mapping between an external object and a content item, optionally targeting a particular content item version. Object identity is passed through an association type code plus up to five generic object attributes.
• CREATE_ASSOCIATIONS — Bulk counterpart to CREATE_ASSOCIATION, processing multiple association mappings in a single call.
• DELETE_ASSOCIATION — Removes a single association mapping between an external object and a content item.
• DELETE_ASSOCIATIONS — Bulk removal of multiple association mappings.
• UPDATE_ASSOCIATION — Modifies an existing association mapping, allowing the linked content item or its attributes to be changed.
• MOVE_ASSOCIATIONS — Reassigns existing associations from one content item (or version) to another. This is the routine most commonly sought when content is reorganized, re-versioned, or migrated, since it preserves association data without requiring delete-and-recreate cycles.
• GET_ASSOCIATIONS — Retrieves association records matching the supplied criteria, returning the mapped objects and content item identifiers to the caller.
• GET_ASSOCIATION_NAMEANDCODE — Returns the descriptive name and code for an association, typically used for display and validation in user interfaces.

Tables Accessed

The package operates against the following tables through APPS synonyms:

• IBC_ASSOCIATIONS — the primary store of association mappings; created, updated, moved, queried, and deleted by the API.
• IBC_ASSOCIATION_TYPES_B — the base table of association type definitions; read to validate p_assoc_type_code values.
• IBC_CONTENT_ITEMS — the content item master; read to verify the target p_content_item_id.
• IBC_CITEM_VERSIONS_B — content item version definitions; read to validate optional version identifiers.
• PLITBLM — the standard PL/SQL message table used by FND_MSG_PUB for message stack handling.

Usage Notes

IBC_ASSOCIATIONS_GRP is an internal group API. It is not intended for direct end-user invocation; instead it is called from the IBC forms and JSP/UI layers that manage content relationships, and it is referenced by six other packages in the IBC schema. Customizations that need to relate content items to external objects should call these procedures rather than performing DML on IBC_ASSOCIATIONS directly, so that validation, message-stack population, and commit control remain consistent. Callers should always inspect x_return_status for Fnd_Api.G_RET_STS_SUCCESS and retrieve messages via the standard FND message utilities. MOVE_ASSOCIATIONS is particularly relevant during content versioning or catalog reorganization, where existing links must be transferred rather than rebuilt. Because the package runs AUTHID CURRENT_USER, the executing schema requires the appropriate grants on the underlying IBC tables; this behavior is consistent across Oracle EBS 12.1.1 and 12.2.2, where the 12.2.2 online patching editioning model does not alter the API contract.