-
Bug
-
Resolution: Done
-
Medium
-
Casablanca Release
-
None
-
None
Reporter: Mahendra from amdocs
"
The issue happens when we have multiple service orders in a single request to NBI where orders are supposed to be executed in a specific sequence. We used the reliesOn feature to effect the sequencing wherein NBI waits for the order to complete before firing next dependent order to SO.
Problem we were facing occurs as NBI stores the mariadb sequence Id (internal to NBI) in place of the order Id sent in the request to define the dependency. Let me explain this with an example:
Lets say we received a request with 3 orders with order Ids 11,12 and 13 where in order id 12 relies on 11 and order id 13 relies on 12.
NBI stores these orders in the mariadb with say with internal ids (auto generated and start with 1) 112,113 and 114 respectively.
Internal Id | OrderId | ReliesOn |
112 | 11 | |
113 | 12 | 11 |
114 | 13 | 12 |
Now NBI tries to replace the ReliesOn Ids (till now they were orderIds which we sent in the request) with the internal Ids to make the data map like below:
Internal Id | orderId | ReliesOn |
112 | 11 | |
113 | 12 | 112 |
114 | 13 | 113 |
But here it searches the strings like 11 and 12 and tries to replace them with internal Ids which corrupts the data as 12 can be found in 112 as well and resulting data becomes like:
Internal Id | OrderId | ReliesOn |
112 | 11 | |
113 | 12 | 1113 |
114 | 13 | 113 |
Now even though the first order with internal id 112 is completed but next order (113) is not sent to the SO as NBI assumes that this order is waiting for 1113 id to be complete which was never fired. And when internal ids reach to 1113 this order may be fired accidently.
This problem could be avoided if we use very long values for order ids (as DB internal ids are started with 0 so we may not see this issue for years), but still it’s better to fix this issue."
- blocks
-
EXTAPI-179 Bump up nbi version for OOM
- Closed