Batch create pieces API

CSP Request Details

None

CSP Rejection Details

None

CSP Approved

None

Description

Create a batch api to support the creation of piece from the Serials management application. Currently if something fails when creating pieces they will create some but not all expected pieces.

Current situation or problem:

The “Serials Management” module creates multiple receiving pieces for an order line title based on the predicted pieces expected for a serial over 1 or more years. The Serials Management module has a concept of a “predicted piece set” which is a list of pieces / issues that are expected for a serial during a particular time period (in a whole number of years). These predicted piece sets have one ‘predicted piece’ per issue, and these are used to generate equivalent receiving pieces in the receiving app.

The Serials Management app currently limits the total number of predicted pieces in a predicted piece set to 366 (this was somewhat arbitrarily chosen as it is 1 year’s worth of daily issues in a leap year). When the user is ready, they can request that the receiving pieces are created for a predicted piece set. At the moment this triggers a series of API calls, one per predicted piece in the predicted piece set (so up to 366 API calls) to create the equivalent receiving pieces. If some of these calls fail, the predicted piece set is left in a situation where some receiving pieces have been created and some have not.

Proposed solution/stories

We would propose a batch API that can accept a single set of JSON to create a number (at least up to 366) receiving pieces with a single API call. It would be preferable if the API call was either successful for all pieces or fails for all pieces to avoid situations where only some of the pieces in a set are created.

The response should contain a list of all the created pieces with enough information for us to match them back to the predicted piece that created it ( this feels like a challenge - any comments on how we’d match the created pieces back to the creating piece in the case of batch creation?)

Rollback not necessary at this stage.

Links to additional info

Questions

Environment

None

Potential Workaround

None

Checklist

hide

Activity

Show:

Owen StephensFebruary 13, 2025 at 10:19 AM
Edited

Thanks . We may have further questions or feedback once we start using this new API, but for now this is looking good

Jack GoldingFebruary 12, 2025 at 5:00 PM

Looks good to me, for any future reference this will be implemented in https://folio-org.atlassian.net/browse/UISER-194

Owen StephensFebruary 7, 2025 at 11:49 AM

can you take a look at this implementation and check you are happy it will work for us?

Serhii_NoskoFebruary 7, 2025 at 7:12 AM

Implemented in scope of this PR:

https://github.com/folio-org/mod-orders/pull/1091

Open orders flow also improved to create pieces in batches that should improve performance especially if Po Line contains many pieces. Change was done in scope of this PR:
https://github.com/folio-org/mod-orders/pull/1092

New endpoint to create batch pieces also now used in karate tests, this PR introduces it:
https://github.com/folio-org/folio-integration-tests/pull/1687

Documentation how to use this new endpoint can be found as usual in Folio Reference Api: https://dev.folio.org/reference/api/ :

https://s3.amazonaws.com/foliodocs/api/mod-orders/r/pieces-batch.html#orders_pieces_batch_post or https://s3.amazonaws.com/foliodocs/api/mod-orders/p/pieces-batch.html

Looks good, closing this ticket.

Jack GoldingJanuary 22, 2025 at 11:34 AM

Apologies for the delayed response, I believe that the way in which we generate internal pieces within our module, the date and captions should be “unique” to any pieces within our set. So I think that matching back the receiving piece's receiptDate and displaySummary back to the internal piece’s date and label should be sufficient

Done

Details

Assignee

Reporter

Labels

Priority

Story Points

Sprint

Development Team

Thunderjet

Fix versions

Release

Sunflower (R1 2025)

TestRail: Cases

Open TestRail: Cases

TestRail: Runs

Open TestRail: Runs

Created May 1, 2024 at 3:07 PM
Updated February 24, 2025 at 11:29 AM
Resolved February 7, 2025 at 7:12 AM
TestRail: Cases
TestRail: Runs

Flag notifications