[markusweigelt]

MODORDERS-1491 - Select Claims export configs through the effective configs endpoint

Purpose

POST /orders/pieces/claim loaded all Claims export configs of the tenant, assigned them to a vendor by the CLAIMS_<vendorId> config name prefix and sent every claimed piece of a vendor to every config of that vendor. The routing rule was hard-coded in mod-orders through a naming convention, so routing by the PO line's acquisition method would have had to be implemented here a second time.

mod-data-export-spring now answers which export configs apply (GET /data-export-spring/effective-configs, MODEXPS-323). mod-orders uses that endpoint, so the rule lives in one place.

Approach

• Config lookup: PiecesClaimingService keeps the PO line's acquisitionMethod per Late piece (ClaimPiece) and calls GET /data-export-spring/effective-configs?vendorId=…&acquisitionMethod=…&type=CLAIMS once per distinct (vendor, acquisition method) through ExportConfigsCache.loadClaimsConfigsForPoLine (30 s cache). acquisitionMethod is left out when the PO line has none.
• One job per config: the pieces are grouped per returned config, keyed by config id (ClaimJob), and each config gets one job with only its pieces. A config returned for several methods gets one job with all of their pieces. A piece returned with several configs is in each of their jobs, but is updated and listed in claimingResults once.
• One piece update: all claimed pieces are updated in one updatePiecesStatuses call instead of one call per vendor, which avoids a partial update across vendors.
• Validation before any write: a piece without an applicable config rejects the whole request with 422 unableToGenerateClaimsForOrgNoIntegrationDetails, as before. A tenant without any Claims config now gets the same 422 instead of 400 cannotRetrieveConfigEntries. That code, the type==CLAIMS lookup and the data-export.config.collection.get module permission are removed.
• Error message: "…because no claims integration applies to the claimed pieces" (was "…because no claim integrations exist"), because a vendor may have configs that don't take the pieces' acquisition method. The error code is unchanged.
• Keyed by config id: ExportConfigsRetriever keys the configs by config id instead of config name, so two configs with the same name no longer overwrite each other.
• Job logs: the logs name the config id and job id of every job.
• ModuleDescriptor: requires data-export-spring 2.1 and adds the module permission data-export.effective-configs.collection.get.
• Tests: PiecesClaimingServiceTest covers routing by acquisition method, one config for several methods, several configs for one piece, configs with the same name, a PO line without a method, a piece without a config (rejected before any write) and a failing effective configs request. MockServer serves /data-export-spring/effective-configs.

Notes for review

• Merge after MODEXPS-323, in the same release. data-export-spring 2.1 is already on master through MODEXPS-316 without the endpoint, so the requirement alone doesn't guarantee it. Without the endpoint, every claim fails, and spring's 404 is returned to the client.
• Routing changes only for configs with selected acquisition methods. For configs without selected methods, the jobs and their claimPieceIds stay the same. Existing Claims integrations with saved defaultAcquisitionMethods start routing by method, and a piece whose method no config takes now gets the 422.
• Other accepted differences: configs are found by type + vendorId instead of the name prefix (this differs only for configs created by hand through the API), and there is one spring call per (vendor, method) instead of one per tenant.
• Unchanged: pieces are still set to Claim sent before the jobs are created, so a failing job leaves the pieces Claim sent.

Depends on

folio-org/mod-data-export-spring#389

[markusweigelt]

@SerhiiNosko Both red jobs require secrets that are currently missing (Docker Hub credentials and a Sonar token). Is there anything I can do to get these jobs running successfully again?

[markusweigelt]

@SerhiiNosko Sorry, my fault! 🙈 I created the PR under the wrong organisation, so Docker Hub credentials and a Sonar token are not available. I'll open a new PR under the correct organisation and close this one.

[markusweigelt]

Created another PR from a branch within the same repository organisation to avoid SonarCloud and GitHub permission-related issues. #1358