Results for “final_failure_date”

8 results




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

Overview

The table XNP.XNP_SV_FAILURES is a core operational entity within the Oracle EBS Number Portability (XNP) product module. It stores a record of service providers that failed to download subscription version (SV) data during number portability processing. Each row captures a specific failure event, associating a service provider with the subscription version order (SOA) that could not be successfully retrieved, along with timing and retry statistics. The table resides in the XNP schema and is marked VALID in the ETRM 12.2.2 repository, with the same structure documented across the 12.1.1 and 12.2.2 releases.

From a Data Vault modeling perspective, the heuristic classification mined from the foreign key structure is link. This classification is a modeling suggestion rather than a physical attribute: the table primarily resolves many-to-many interactions between service providers and subscription version orders, rather than acting as a standalone hub of business entities or a pure descriptive satellite. The presence of SV_FAILURE_ID as a unique surrogate and a composite business key reinforces its role as an associative or transactional link capturing failure occurrences.

Key Information Stored

The most significant columns in XNP_SV_FAILURES are:

The business-key candidate XNP_SV_FAILURES_U2 is defined over SP_ID, SV_SOA_ID, and FAILURE_DATE, distinguishing it from the surrogate primary key. This composite uniqueness ensures a service provider cannot have duplicate failure entries for the same SV order at the same timestamp.

Common Use Cases and Queries

Typical use cases focus on monitoring, troubleshooting, and reconciliation of number portability download failures. Common query patterns include:

  • Listing all failures for a given service provider within a date range, filtering on SP_ID and FAILURE_DATE.
  • Identifying SV orders with repeated or high ATTEMPTED_RETRIES values to prioritize remediation.
  • Joining to XNP_SERVICE_PROVIDERS and XNP_SV_SOA to produce diagnostics reports showing provider names against failed subscription versions.
  • Aggregating failure counts by FAILURE_DATE for trend and SLA reporting, or comparing FAILURE_DATE to FINAL_FAILURE_DATE to measure resolution latency.
  • Applying SECURITY_GROUP_ID filters to restrict results to the appropriate operating unit or security group.

A representative query might join XNP_SV_FAILURES to XNP_SERVICE_PROVIDERS on SP_ID and to XNP_SV_SOA on SV_SOA_ID, restricting by FAILURE_DATE and ordering by ATTEMPTED_RETRIES descending to surface the most problematic interactions.

Related Objects

The following objects are most significant in relation to XNP_SV_FAILURES:

  • XNP_SERVICE_PROVIDERS — Referenced via XNP_SV_FAILURES.SP_ID; provides the service provider identity.
  • XNP_SV_SOA — Referenced via XNP_SV_FAILURES.SV_SOA_ID; provides subscription version order context.
  • FND_SECURITY_GROUPS — Referenced via XNP_SV_FAILURES.SECURITY_GROUP_ID; governs data access partitioning.
  • Indexes XNP_SV_FAILURES_PK, XNP_SV_FAILURES_U1, and XNP_SV_FAILURES_U2 — Enforce surrogate and composite uniqueness constraints.

Together these relationships position XNP_SV_FAILURES as the associative link between number portability service providers and subscription version orders, enabling operational tracking of download failures within Oracle EBS 12.1.1 and 12.2.2.