LIDB / CNAM response process updating the extract table Incorrectly (Doc ID 814309.1)

Last updated on MARCH 18, 2019

Applies to:

Symptoms

-- Problem Statement:

Invoke the updateLidbDataRequest XML API with a response for a record whose EXTRACT_STATUS_CD = "U" (unmatched) on the LIDB_EXTRACT table and there exists multiple pending orders, the wrong row is responded too.  Two different PSR orders are performing a move for a telephone number (TN) causing a suffix 0 for the disconnect (one PSR order) and a suffix 1 for the new service (second PSR order) row to be written to the LIDB_EXTRACT table. The disconnect PSR order LIDB_EXTRACT row is extracted but not responded to in the next LIDB response batch causing the EXTRACT_STATUS_CD to be set to "U" (unmatched). In the next LIDB response batch the disconnect suffix 0 TN record is included to be processed and when the LIDB response executes the PSRAncillary code it does a max suffix for this TN and responds to the second PSR suffix 1 row thus causing a mismatch extract status code to be written to the suffix 1 row which has never even been extracted (no GROUP_EXTRACT_ID on the LIDB_EXTRACT table) . The PSRAncillary LIDB response should use the GROUP_EXTRACT_ID included in the LIDB response record to alleviate responding to the wrong record.

-- Steps To Reproduce:
1. Create disconnect PSR order for TN - order finish the PSR so that the LIDB_EXTRACT row is written
2. Create insert (new service) PSR order assigning the pending disconnect TN used in step 1-order finish the PSR so that the LIDB_EXTRACT row is written
3. Work the tasks for the disconnect PSR order from step 1 and initiate the All LIDB gateway event so that the EXTRACT_INDICATOR_ID will be set to "Y" so that the row can be extracted
4. Execute getLidbDataRequest XML API
5. Execute the updateLidbDataRequest XML API but do not send a response record for the disconnect
TN (suffix 0 record)
6. Execute the updateLidbDataRequest XML API sending a response for the disconnect TN (suffix 0
record)
7. Notice that the suffix 1 row has been responded too and the EXTRACT_STATUS_CD set to "M" for
mismatch

-- Business Impact:
The wrong row is being responded too on the LIDB_EXTRACT table, cannot successfully respond to the
disconnect TN (suffix 0) row on the LIDB_EXTRACT table.

Changes

Cause

My Oracle Support provides customers with access to over a million knowledge articles and a vibrant support community of peers and Oracle experts.