Details
-
Story
-
Status: Closed (View Workflow)
-
P3
-
Resolution: Done
-
None
-
None
-
-
ACQ Sprint 64, ACQ Sprint 65
-
3
-
EBSCO - FSE
Description
Overview:
We need to handle the following scenario gracefully:
- the order gets to mod-gobi, it gets mapped, and send to mod-orders. mod-orders successfully creates the po/pol in pending, then something about the order causes the transition from PENDING -> OPEN to fail
- mod-orders then says whoops, this order wasn't successfully placed because of that and returns an error, which is propagated back to GOBI
- GOBI says, let me try again... and again, and again
until it finally gives up - the result is a whole bunch of pending orders
Upon order placement look for an order with the vendor Reference Number and only create a new order if one isn't found. If one is found get the composite purchase order, update the status to OPEN and try to update it via PUT. This will essentially retry the transition to OPEN. If this fails again, return the poLineNumber even though the order was not successfully transitioned to OPEN. There isn't anything GOBI can do about it, and really all GOBI cares about is the poLineNumber, which we could return to them, even if the order is still in PENDING state in FOLIO. The end result is that GOBI will stop retrying and the order will need some attention from a human - probably a good candidate for using alerts once they've been implemented.
{ "field": "VENDOR_REF_NO", "dataSource": { "from": "//YBPOrderKey" } }
Acceptance Criteria:
- Duplicate orders are not created (at least not as a result of the scenario described above)
- The poLineNumber is returned on the first retry of an order which failed to transition to OPEN
- Unit tests are updated
- API tests are updated
- Module descriptor is updated (module permissions associated with checking if the order exists)
TestRail: Results
Attachments
Issue Links
- relates to
-
MODORDERS-176 Failure in inventory interaction, fails the order
-
- Closed
-