Search Results update_preference

Overview

IBU_EBLAST_PREF_PKG is a PL/SQL package body owned by the APPS schema in Oracle E-Business Suite. Its source header revision identifier (ibueblab.pls, 115.3, dated 2002/12/03) indicates the package originated in the early iMarketing/iStore-era codebase and has remained largely static since. The package supports the eBlast (electronic mail blast) preference infrastructure used by Oracle iSupport and related self-service modules. Its business purpose is to manage contact preferences — specifically e-mail channel preferences — recorded against a party in the Trading Community Architecture (TCA) model. Rather than writing directly to the underlying HZ tables, the package builds TCA public API record structures and delegates the actual insert and update operations to HZ_CONTACT_PREFERENCE_V2PUB.

The package is classified as OTHER in the ETRM registry and is not part of the formally published, supported TCA public API set. Its procedures establish the boilerplate attribute values (contact level, contact type, module identifier, and start date) required to create a valid contact preference record.

Key Procedures and Functions

• CREATE_PREFERENCE — Creates a contact preference for a given party. The procedure accepts a party identifier and a preference code, then populates a CONTACT_PREFERENCE_REC_TYPE structure from HZ_CONTACT_PREFERENCE_V2PUB. The record is initialized with FND_API.G_MISS_* sentinel values so that the TCA API treats unspecified columns as null. Documented assignments include contact_level_table set to 'HZ_PARTIES', contact_type set to 'EMAIL', preference_start_date set to SYSDATE, requested_by set to 'INTERNAL', and created_by_module set to 'ISUPPORT PROFILE'. The procedure returns the generated contact preference identifier and the standard FND_API return status, message count, and message data out parameters.
• UPDATE_PREFERENCE — Modifies an existing contact preference record. It follows the same record-structure and messaging conventions as CREATE_PREFERENCE, using the TCA contact preference public API to persist changes and returning the standard FND_API status and message outputs.

Both procedures conform to the Oracle Application Object Library API messaging pattern: an OUT NOCOPY return status (typically FND_API.G_RET_STS_SUCCESS or G_RET_STS_ERROR), an OUT NOCOPY message count, and an OUT NOCOPY message data buffer.

Tables Accessed

The package does not reference application tables directly through APPS synonyms. All database interaction is routed through HZ_CONTACT_PREFERENCE_V2PUB, the TCA public API that owns the HZ_CONTACT_PREFERENCES table and its associated entities. The contact_level_table = 'HZ_PARTIES' assignment confirms that preferences are recorded at the party level, keyed by the party identifier passed into the procedure. Because no direct table access is documented, the package inherits the validation, security, and concurrency behavior of the TCA API layer, including its use of the HZ_CONTACT_PREFERENCES sequence and any dependent lookups for preference codes and topics.

Usage Notes

The package is not referenced by any other documented package in the ETRM registry, indicating it is invoked from external callers rather than forming a shared library layer. Typical invocation sources are Oracle iSupport profile-related pages and any custom concurrent program or extension that needs to programmatically establish an e-mail opt-in or opt-out preference for a party. The hard-coded 'ISUPPORT PROFILE' value in created_by_module anchors the audit trail to the iSupport application, so custom code reusing this package will inherit that attribution unless the record is amended afterward.

Because the package is unsupported and the source file has not been revised since 2002, implementations on 12.1.1 and 12.2.2 should treat it as a stable but non-upgrade-protected object. Direct dependencies on HZ_CONTACT_PREFERENCE_V2PUB mean any TCA API signature or behavior change at the database level will surface as a runtime error in these procedures. Developers extending eBlast or profile preference functionality should consider calling HZ_CONTACT_PREFERENCE_V2PUB directly rather than relying on this wrapper.