Results for “per_jbr_bus”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

PER_JBR_BUS is the business-rules layer of the Oracle E-Business Suite Human Resources product family, generated by the Oracle Forms/Table Handler (TAPI) pattern used throughout the PER schema. It is declared AUTHID CURRENT_USER and, per its header comment (pejbrrhi.pkh), forms part of the internal table handler implementation for the job requirements entity. The package encapsulates validation logic that must be executed before a row is inserted, updated, or deleted in the underlying job requirement structures, keeping that logic separate from the persistence logic performed by the shared handler (PER_JBR_SHD) and the row-level PL/SQL API surface.

Within EBS 12.1.1 and 12.2.2 this package is classified as an OTHER API in the ETRM registry. It is not intended as a public, callable application programming interface; the source comments explicitly state that access status is "Internal Table Handler Use Only." Its role is therefore supporting rather than functional: it exists so that the generated table handler for the journey/job requirement entity can delegate business-rule enforcement to a single, maintainable location.

Key Procedures and Functions

ETRM documents three procedures on this package, corresponding to the three DML verbs supported by the table handler:

• INSERT_VALIDATE — controls execution of all insert business-rule validation. It is a private procedure invoked from the handler's insert routine, accepting a PL/SQL record structure representing the row being created. On success processing continues; on failure any error is raised only if explicitly coded.
• UPDATE_VALIDATE — controls execution of all update business-rule validation, called from the handler's update routine with the same PL/SQL record structure argument convention. It applies the same success/failure contract as the insert variant.
• DELETE_VALIDATE — controls validation performed when a job requirement row is removed, ensuring referential and business constraints are honoured before the delete proceeds.

The documented design guidance advises that the actual rules be implemented as straight procedure or function calls, avoiding conditional branching within these procedures where possible, so that the validation body remains a readable manifest of the rules applied.

Tables Accessed

The package accesses two tables through APPS synonyms:

• PER_ANALYSIS_CRITERIA — stores the analysis criteria definitions against which requirement content is evaluated; validation logic reads it to confirm that referenced criteria exist and are valid for the row being processed.
• PER_JOB_REQUIREMENTS — the primary entity table holding job requirement rows (for example, competency or qualification requirements attached to a job or position). Insert, update and delete validation all operate in relation to this table.

Usage Notes

PER_JBR_BUS is never invoked directly by end users. It is called internally by the generated table handler when the corresponding DML operation is performed, and in turn it is referenced by three other packages in the ETRM dependency graph. Typical trigger points include the Job and Position definition forms in Oracle HRMS, the corresponding self-service pages, and any concurrent or batch program that maintains job requirements through the supported API layer. Custom code should not call the validation procedures directly; instead, use the public row-level API and allow it to route validation through this package. Because the package is generated and shipped by Oracle, it should not be modified, and any customer-specific rule should be added to the appropriate user hook rather than to these procedures.