This is a general roadmap to improve support for parallel processing in acquisition modules. It will span several releases, and work needs to be split to make progress possible.
Some of the issues to resolve are described in a wiki.
MODFISTO-293- Error All expected transactions already processed MODORDERS-662- Piece implementation not waiting for futures MODORDERS-694- PendingToOpenEncumbranceStrategy is not thread-safe MODFISTO-303- Backend finance optimistic locking (with the goal of generating errors as opposed to silent data loss)
- Lock budgets to update totals - this resolves budget issues when updating separate orders in parallel
- Finance optimistic locking UI, to report a 409 error in a clear way
- POC of a minimal fix of the transaction API; this will resolve issues when updating transactions in parallel for the same order or invoice
- Apply the POC
UXPROD-3434, MODFISTO-260, MODFISTO-266, MODFISTO-268, MODFIN-214, MODORDERS-581, MODINVOICE-307
- Check that releasing transactions is not resulting in wrong budgets anymore (the previous fixes are likely to fix that)
- Simplify the transaction API (one endpoint for transaction summaries)
- Simplify + optimize usage of finance API in other modules (for instance redo
- Test performance impact of using more calls in parallel instead of sequentially. If little impact or improvement, revert some module changes, from sequential to parallel processing (to improve readability).
- Optimistic locking in other modules
- Support PATCH method with transaction summaries
- Update calls to use the new transactions PATCH method, to change order status, set invoiceCancelled, unrelease encumbrances etc.
- Use po line PATCH method to change payment status.
- Look for other PUT calls to replace by PATCH or new endpoints.
- UI-controlled pessimistic locking
- An alternative to the transaction summaries would be to send all the transaction operations at the same time (method+data). This would be a larger change than the ones planned above, but it would simplify implementation further.
- Implementing rollbacks and using the Saga pattern to deal with complex multi-step, multi-app operations, with Kafka. See for instance Saga Pattern in Microservices and Distributed Transactions in Microservices with Kafka Streams and Spring Boot.