Search Results replayed_on




Overview

The JTS.JTS_CONFIG_VERSIONS_B table is a core configuration repository within the Oracle E-Business Suite JTS (Configuration/TeleService) schema. It stores configuration versions as described on the Version Summary page, functioning as the authoritative record of every iteration of a configuration object. Each row represents a discrete, versioned snapshot of a configuration, capturing both the descriptive identity of the version and its lifecycle status, including replay and queue-processing metadata.

The table resides in the APPS_TS_TX_DATA tablespace with a PCT Free of 10, reflecting a transactional data store with moderate update activity. It contains 32 documented columns and is classified as VALID under FND Design Data JTS.JTS_CONFIG_VERSIONS_B.

Under a heuristic Data Vault classification mined from its foreign key structure, this object models as a satellite. It carries descriptive and state attributes (version name, version number, status codes, replay metadata, audit columns) attached to the version and configuration identifiers it references. The classification is a modeling suggestion only; the physical schema uses standard EBS _B-style column conventions with WHO audit columns and a SECURITY_GROUP_ID rather than a normalized Data Vault structure.

Key Information Stored

The surrogate primary key is VERSION_ID, enforced by unique index JTS_CONFIG_VERSIONS_B_U1. It is the immutable row identifier and also serves as a foreign key to VEA_VERSIONS.

Two business-key candidates are documented via unique indexes:

The most significant columns are:

  • VERSION_ID — surrogate primary key and reference to the master version record.
  • OBJECT_VERSION_NUMBER — optimistic locking token used by the EBS framework for concurrency control.
  • VERSION_NAME — user-facing label of the configuration version (up to 80 characters).
  • CONFIGURATION_ID — identifier of the parent configuration to which this version belongs.
  • VERSION_NUMBER — numeric sequence indicating the ordinal version of a configuration.
  • VERSION_STATUS_CODE — state of the version in its lifecycle.
  • REPLAY_STATUS_CODE — status of replay processing for the version.
  • REPLAYED_ON / REPLAYED_BY — timestamp and user identifier of the last replay action.
  • QUEUE_NAME — associated advanced queue used for deferred processing.
  • SECURITY_GROUP_ID — foreign key to FND_SECURITY_GROUPS, enabling multi-organization data segregation.
  • WHO audit columns — CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, and LAST_UPDATE_LOGIN track row provenance.
  • DESCRIPTIVE flexfields — ATTRIBUTE_CATEGORY and ATTRIBUTE1 through ATTRIBUTE15 provide extensible descriptive attributes.

Common Use Cases and Queries

Typical reporting scenarios include retrieving the current version of a configuration, auditing replay activity, and listing all versions for a given configuration.

Sample: retrieve all versions for a configuration.

SELECT VERSION_ID, VERSION_NAME, VERSION_NUMBER,
       VERSION_STATUS_CODE, REPLAY_STATUS_CODE
FROM   JTS.JTS_CONFIG_VERSIONS_B
WHERE  CONFIGURATION_ID = :p_configuration_id
ORDER BY VERSION_NUMBER;

Sample: identify versions pending replay or recently replayed.

SELECT VERSION_ID, VERSION_NAME, REPLAY_STATUS_CODE,
       REPLAYED_ON, REPLAYED_BY
FROM   JTS.JTS_CONFIG_VERSIONS_B
WHERE  VERSION_STATUS_CODE = :p_status
AND    REPLAY_STATUS_CODE IS NOT NULL;

Common patterns also include joining to VEA_VERSIONS for top-level version metadata and filtering by SECURITY_GROUP_ID to respect organization access. The flexfield columns support reporting against customer-extended attributes without schema changes.

Related Objects

  • JTS.JTS_CONFIG_VERSIONS_B.VERSION_ID → JTS.VEA_VERSIONS — joins each configuration version to its master version record.
  • JTS.JTS_CONFIG_VERSIONS_B.SECURITY_GROUP_ID → FND_SECURITY_GROUPS — joins to the security group definition controlling visibility and data segregation.
  • FND_SECURITY_GROUPS — referenced by SECURITY_GROUP_ID, supporting multi-organization access.
  • VEA_VERSIONS — parent version entity providing header-level version semantics.
  • Indexes JTS_CONFIG_VERSIONS_B_U1 (VERSION_ID) and JTS_CONFIG_VERSIONS_B_U2 (CONFIGURATION_ID, VERSION_NAME), both in APPS_TS_TX_IDX, drive uniqueness and fast lookup.
  • Configuration child tables keyed by CONFIGURATION_ID or VERSION_ID depend on this table for version context.

The combination of surrogate-key uniqueness and configuration/name uniqueness makes this table the reliable integration point for configuration versioning queries and audit reporting.