Budget management functionality that FOLIO needs to stay competitive (UXPROD-3442)

[UXPROD-3434] Implement new finance transaction model to protect against parallel processing Created: 02/Dec/21  Updated: 30/May/23  Resolved: 30/May/23

Status: Closed
Project: UX Product
Components: None
Affects versions: None
Fix versions: None
Parent: Budget management functionality that FOLIO needs to stay competitive

Type: New Feature Priority: P3
Reporter: Dennis Bridges Assignee: Dennis Bridges
Resolution: Duplicate Votes: 0
Labels: acquisitions, tech-debt
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Cloners
is cloned by UXPROD-3636 Define new transaction model to prote... Closed
Defines
defines UXPROD-3666 Improve support for parallel processing In Refinement
is defined by MODFISTO-260 Transaction summaries are not designe... Closed
is defined by MODFISTO-266 Create a new model "TempTransaction" Closed
is defined by MODFISTO-267 Update table "order_transaction_summa... Closed
is defined by MODINVOICE-307 Update transaction summary API calls Closed
is defined by MODORDERS-581 Update transaction summary API calls Closed
is defined by MODFISTO-268 Option to provide a summary id parame... Closed
is defined by MODFIN-214 Option to provide a summary id parame... Closed
is defined by MODFISTO-314 POC: fix the transaction API Closed
is defined by MODFISTO-259 Releasing 2 transactions at the same ... Blocked
Release: Nolana (R3 2022)
Epic Link: Budget management functionality that FOLIO needs to stay competitive
Front End Estimate: Out of scope
Development Team: Thunderjet
PO Rank: 0
Rank: Cornell (Full Sum 2021): R2
Rank: Duke (Full Sum 2021): R2

 Description   

Current situation or problem: When 2 users or separate mods run operations in parallel, they can send both summaries before sending the operations. mod-finance-storage is not saving previous summaries with the same id (which in practice is the order id for encumbrances), so one of the summaries sent will have no effect, resulting in an error for the second one:

"All expected transactions already processed"

In scope

Redesign transaction summaries to allow parallel usage. Using unique ids (as opposed to for instance order ids)  could be part of the solution, but we don't want to accumulate too many records in the summary tables, so they would have to be deleted when no longer in use.

 When redesigning, care should be taken to avoid requiring a check for 404 errors, as was done in mod-orders' TransactionSummariesService.java for MODORDERS-545 Closed (normal operations should not report errors in the logs).

Out of scope

Use case(s)

Proposed solution/stories
Wiki : https://folio-org.atlassian.net/wiki/display/DD/Support+for+transaction+processing+by+two+or+more+users+in+parallel

Links to additional info

Questions



 Comments   
Comment by Dennis Bridges [ 16/Dec/21 ]

We continue to encounter issues relating to processing transactions in parallel. As a result I have increased the priority of this issue. 

Comment by Mikita Siadykh [ 31/Jan/22 ]

would be nice to discuss with SA, BE estimate is TBD 

Comment by Damien [ 30/May/23 ]

This is replaced by UXPROD-4321 Open .

Generated at Fri Feb 09 00:31:58 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.