Search Results ota_ra_con_api




Overview
Explore in AI Chat

Overview

APPS.OTA_RA_CON_API is a public PL/SQL API package in the Oracle E-Business Suite (EBS) Release 12.1.1 and 12.2.2 environments, owned by the APPS schema and classified in the ETRM repository as an API. The package encapsulates the create and maintain operations for contact records within the Oracle Learning Management (OLM) and Oracle Training Administration (OTA) module, specifically for the delegate booking functionality. Its naming convention (OTA_RA_CON_API) follows the OTA module prefix combined with the RA_CONTACTS base table upon which the package operates, with the "_API" suffix signalling that it forms part of the supported programmatic interface rather than an internal helper unit. The package exists to provide a controlled, business-rule-enforcing entry point for inserting and updating contact data, insulating callers from the underlying table structures and from the evolution of the contact data model.

Key Procedures and Functions

Three procedures are documented for this package.

  • INSERT_CONTACT — Inserts a new contact into RA_CONTACTS using the contact's name and customer identifier. The contact ID is returned as an OUT parameter. Per the source header, this procedure is currently used only by Delegate Bookings, indicating that its primary consumer is the OTA delegate booking flow rather than general-purpose contact maintenance.
  • UPDATE_CONTACT — Updates an existing contact record in RA_CONTACTS, identified by the contact ID, applying revised last name, first name, and title values. This is the procedure matching the user's search term "update_contact". Like INSERT_CONTACT, the documented comment states it is currently used only by Delegate Bookings.
  • INSERT_ROW — A table-handler style procedure that performs a lower-level insert against the contact record, accepting standard who-columns (created by, creation date, last updated by, last update date) together with contact attributes such as customer ID, last name, first name, originating system reference, status, address ID, contact key, and job title. The contact ID and originating system reference are IN OUT NOCOPY parameters.

Tables Accessed

Although the package's own header references RA_CONTACTS, the documented ETRM table usage for this object, reached through APPS synonyms, spans the following:

  • HZ_PARTIES — the TCA party master, holding the underlying party record for each contact.
  • HZ_ORG_CONTACTS — the organization contact relationship records that link a party to a customer organization.
  • HZ_CUST_ACCOUNTS and HZ_CUST_ACCOUNT_ROLES — the customer account and account role records that establish the contact's customer context.
  • HZ_RELATIONSHIPS — relationship definitions between parties and organizations.
  • HZ_CONTACT_NUMBERS_S — the contact number sequence used to allocate contact identifiers.
  • DUAL — used for single-row expression evaluation and sequence retrieval.

These tables indicate that the package operates against the Trading Community Architecture (TCA) model rather than exclusively against a legacy RA_CONTACTS table, meaning contact creation and update also maintain party, organization contact, and relationship data.

Usage Notes

OTA_RA_CON_API is a server-side API and, per the ETRM metadata, is referenced by zero other packages, so it is invoked directly by its consumers rather than being nested inside other documented APIs. Its documented sole consumer is the Delegate Bookings feature of Oracle Learning Management, which calls INSERT_CONTACT and UPDATE_CONTACT when a delegate's contact details are captured or amended during enrollment and booking. The procedures may also be called from Oracle Forms, concurrent programs, or custom PL/SQL integration code that needs to create or update delegate contacts while respecting the underlying TCA entity relationships. The INSERT_ROW procedure exposes additional who-columns and attribute parameters for callers that require more explicit control than the higher-level INSERT_CONTACT offers. Because the package writes to TCA contact and party tables, callers should ensure the correct customer context is supplied and avoid direct DML against the underlying tables in favour of these API entry points.