LIDB / CNAM response process updating the extract table Incorrectly
(Doc ID 814309.1)
Last updated on MARCH 18, 2019
Applies to:Oracle Communications MetaSolv Solution - Version 6.0.15 to 6.0.16 [Release 6.0.15 to 6.0.16]
Information in this document applies to any platform.
This problem can occur on any platform.
-- 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
7. Notice that the suffix 1 row has been responded too and the EXTRACT_STATUS_CD set to "M" for
-- 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.
To view full details, sign in with your My Oracle Support account.
Don't have a My Oracle Support account? Click to get started!
In this Document