Search Results jts_status




Overview
Explore in AI Chat

Overview

APPS.JTS_CONFIG_VER_STATUS_PVT is a private PL/SQL package belonging to the Oracle Setup Online Configuration Management subsystem within Oracle E-Business Suite. It is classified as a private API (PVT), meaning it is not intended for direct invocation by external or customer-developed code; instead it supports the internal processing logic that governs how configuration versions are created, tracked, and transitioned through their lifecycle. The package declares AUTHID CURRENT_USER, so its unqualified database references resolve against the privileges of the invoking schema rather than the APPS schema owner.

The package is organized around the JTS_STATUS lookup type, which the header defines through a series of constants. These constants describe both version states (NEW, PROCESS, COMPLETE) and replay outcome states (SUBMIT, NOSUBMIT, FAIL, CANCEL, SUCCESS, ERRORS, and RUNNING). Together these constants form the vocabulary the package uses to record and interpret the progress of a configuration version as it moves from creation through replay and completion. This makes the package a central bookkeeping component for version status within the broader JTS configuration management feature set.

Key Procedures and Functions

The ETRM metadata documents eight procedures and functions. Their documented purposes are as follows:

  • CREATE_VERSION_STATUS — Inserts a row into the jts_config_version_statuses table associating a specific version identifier with a status value. It is the primary mechanism for seeding the status history of a newly created version.
  • DELETE_VERSION_STATUSES — Removes status records from jts_config_version_statuses for a given version identifier.
  • DELETE_CONFIG_VER_STATUSES — Removes status records for all versions associated with a particular configuration identifier, supporting cleanup at the configuration level rather than the individual version level.
  • ANY_VERSION_REPLAYED — Checks whether any version under a given configuration has been replayed, providing a boolean-style determination used by higher-level processing logic.
  • GET_VERSION_STATUS_DATA — Retrieves status information for a version, serving as the read/query counterpart to the creation and deletion routines.
  • IN_REPLAY_STATUS — Determines whether a status value corresponds to one of the replay-related states defined by the package constants.
  • IN_VERSION_STATUS — Determines whether a status value corresponds to one of the version lifecycle states (NEW, PROCESS, or COMPLETE).
  • NOT_REPLAYED — Evaluates whether a version has not been replayed, complementing ANY_VERSION_REPLAYED.

The package does not expose these routines as public API; they are consumed internally by the configuration management modules and by the two packages documented as referencing this one.

Tables Accessed

The package reads and writes the following objects through APPS synonyms:

  • JTS_CONFIG_VERSION_STATUSES — The primary table maintained by this package; it stores the status rows created, queried, and deleted by the procedures above.
  • JTS_CONFIG_VERSIONS_B — The base table of configuration versions, referenced to resolve version identity and validate version-level operations.
  • JTS_CONFIG_VERSION_FLOWS — Stores version flow information used when evaluating replay-related status logic.
  • FND_LOOKUP_VALUES — The Oracle Application Object Library lookup table, which holds the JTS_STATUS lookup type whose codes are represented by the package constants.
  • FND_USER — The EBS user table, referenced for user context associated with status records.

Usage Notes

Because JTS_CONFIG_VER_STATUS_PVT is a private package, it is not designed for direct invocation from forms, concurrent programs, or custom extensions. It is instead invoked indirectly by the public configuration management APIs and by the two referencing packages documented in the ETRM metadata, which call its routines to create status rows when versions are instantiated, to advance status as processing proceeds, and to clean up status records when versions or configurations are removed. The JTS_STATUS lookup codes surfaced through this package correspond directly to the jts_status search term, making the package the internal source of truth for how version and replay statuses are interpreted. Customers and integrators should interact with the supported public APIs rather than calling this package directly, since procedure signatures may change between releases such as 12.1.1 and 12.2.2 without notice.