Repository navigation
MODORDERS-1491 - Select Claims export configs through the effective configs endpoint - #1358
Open
markusweigelt wants to merge 9 commits into
Open
markusweigelt wants to merge 9 commits into
markusweigelt wants to merge 9 commits into
Conversation
Ask mod-data-export-spring which integrations apply per vendor and acquisition method instead of matching the config name prefix, so the routing rule lives in one place. Each job now gets only the pieces of its integration; the result stays the same while the Claims rule is vendor-only.
The jobs are grouped by integration, so the vendor grouping only split the piece update. One call for all pieces avoids a partial update across vendors.
A tenant without any Claims integration now gets the same 422 as a vendor without one, so the extra lookup of all Claims configs and the data-export.config.collection.get permission are no longer needed. The error message now covers integrations that don't take the acquisition method.
The backend works with export configs, so the code added for config matching now uses that term. The user-facing error message keeps "integration", the name shown in the UI.
Two configs with the same configName overwrote each other in the retrieved map, so only one of them got a claim job.
The job overwrites the config id with its own, so the logs now name both. A failing effective configs request must reject the claim before any write.
SerhiiNosko
reviewed
Nov 9, 2026
| .compose(config -> { | ||
| if (CollectionUtils.isEmpty(config.getMap())) { | ||
| log.info("sendClaims:: Cannot retrieve config entries - No claims are sent"); | ||
| throwHttpException(CANNOT_RETRIEVE_CONFIG_ENTRIES, claimingCollection, HttpStatus.HTTP_BAD_REQUEST); |
Contributor
There was a problem hiding this comment.
can you verify changes with running karate tests from folio-integration-tests(acquisitions folder) and add new tests for this change if needed
Contributor
Author
There was a problem hiding this comment.
We are now verifying the behavior with the new integration tests folio-org/folio-integration-tests#2625
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
MODORDERS-1491 - Select Claims export configs through the effective configs endpoint
Purpose
POST /orders/pieces/claimloaded all Claims export configs of the tenant, assigned them to a vendor by theCLAIMS_<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
PiecesClaimingServicekeeps the PO line'sacquisitionMethodperLatepiece (ClaimPiece) and callsGET /data-export-spring/effective-configs?vendorId=…&acquisitionMethod=…&type=CLAIMSonce per distinct (vendor, acquisition method) throughExportConfigsCache.loadClaimsConfigsForPoLine(30 s cache).acquisitionMethodis left out when the PO line has none.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 inclaimingResultsonce.updatePiecesStatusescall instead of one call per vendor, which avoids a partial update across vendors.unableToGenerateClaimsForOrgNoIntegrationDetails, as before. A tenant without any Claims config now gets the same 422 instead of 400cannotRetrieveConfigEntries. That code, thetype==CLAIMSlookup and thedata-export.config.collection.getmodule permission are removed.ExportConfigsRetrieverkeys the configs by config id instead of config name, so two configs with the same name no longer overwrite each other.data-export-spring2.1 and adds the module permissiondata-export.effective-configs.collection.get.PiecesClaimingServiceTestcovers 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.MockServerserves/data-export-spring/effective-configs.Notes for review
data-export-spring2.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.claimPieceIdsstay the same. Existing Claims integrations with saveddefaultAcquisitionMethodsstart routing by method, and a piece whose method no config takes now gets the 422.type+vendorIdinstead 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.Claim sentbefore the jobs are created, so a failing job leaves the piecesClaim sent.Depends on
folio-org/mod-data-export-spring#389