Search Results ota_lp_enrollment_api




Overview

OTA_LP_ENROLLMENT_API is a public PL/SQL API package in the APPS schema that provides the programmatic interface for managing learner enrollments in Oracle Learning Management (OLM), the training and certification module of Oracle E-Business Suite. The package encapsulates the business logic required to create, modify, and remove enrollments that associate a learner with a learning path, and to subscribe a learner to a path so that the enrollment records for its constituent members are generated. It is classified in the ETRM metadata as an API, indicating that it is intended for supported, direct invocation by other application code rather than being an internal helper package.

The package is among the core facilities of the OLM enrollment layer. Because learning paths are hierarchical containers whose members may themselves be offerings, the enrollment process must reconcile path-level intent with individual member-level records. OTA_LP_ENROLLMENT_API centralises that reconciliation so that forms, concurrent programs, and integrations all apply consistent validation and data integrity rules.

Key Procedures and Functions

  • CREATE_LP_ENROLLMENT — Establishes a new enrollment of a learner onto a learning path, inserting the corresponding enrollment record and performing the validations required before the enrollment is accepted.
  • UPDATE_LP_ENROLLMENT — Modifies an existing learning path enrollment, allowing attributes of the enrollment to be changed while preserving referential integrity with the learner and path definitions.
  • DELETE_LP_ENROLLMENT — Removes a learning path enrollment, applying the deletion rules that govern whether an enrollment may be withdrawn and cleaning up related records as required.
  • SUBSCRIBE_TO_LEARNING_PATH — Subscribes a learner to a learning path, driving the creation of enrollments for the members belonging to that path. This is the entry point used when a learner is to be enrolled in an entire curriculum rather than in a single offering.

All four procedures are exposed as documented API entry points. Parameter lists should be obtained from the package specification in the target instance, as signatures vary by patch level.

Tables Accessed

  • OTA_LEARNING_PATHS — The learning path definition header, read to validate that the target path exists and is eligible for enrollment.
  • OTA_LEARNING_PATH_MEMBERS — The membership rows that define which offerings or sub-paths compose a path, used by SUBSCRIBE_TO_LEARNING_PATH to determine the enrollments to generate.
  • OTA_LP_ENROLLMENTS — The primary enrollment table into which this package inserts, updates, and deletes learning path enrollment records.
  • WF_ITEMS — The Oracle Workflow item table, referenced to support notification and workflow-driven processing associated with the enrollment lifecycle.

Access is performed through APPS synonyms, consistent with standard EBS API design.

Usage Notes

OTA_LP_ENROLLMENT_API is not typically called directly by end users. It is invoked from the OLM enrollment forms, from concurrent programs that process bulk or batch enrollments, and from custom PL/SQL integrations that must enrol learners without using the user interface. The dependency metadata shows it is referenced by OTA_BULK_ENROLL_UTIL, OTA_LP_ENROLLMENT_SWI, OTA_LRNG_PATH_MEMBER_UTIL, OTA_LRNG_PATH_UTIL, and OTA_TRAINING_PLAN_UPGRADE, confirming that it sits beneath the bulk enrollment utility, the self-service web interface layer, the learning path utility packages, and the training plan upgrade path.

Because the package is a supported API, custom code should call it rather than inserting into OTA_LP_ENROLLMENTS directly. Callers should operate on a committed, valid learning path and learner, and should expect the API to apply the same validation logic as the standard forms. The presence of the SWI reference indicates the same API supports both administrative and self-service (learner-facing) enrollment flows, so behavior must remain consistent across both channels. As with all EBS APIs, testing in a cloned environment prior to production use is recommended.