Repository navigation
fix: order the bike carried by the bikeId process variable - #10
Merged
Merged
Conversation
The order worker now reads the bikeId process variable and hands it to OrderBikeService, which stores it on the application and orders it. An alternative chosen through the Tasklist form therefore reaches the domain just like one chosen through the REST endpoint. The form gains a required bikeId field, and the endpoint answers 400 for an accepted alternative that names no bike. Related to miragon-blueprints/zeebe-example#29
The diff-scoped mutation gate saw gaps in the classes the bikeId fix touches: the clarify-alternative task lookup, the unwrapping of failed correlations, and the unknown-application branches of the order and select-alternative services. Related to miragon-blueprints/zeebe-example#29
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.
Related to miragon-blueprints/zeebe-example#29 — same defect, same fix as miragon-blueprints/zeebe-example#35, translated to this engine.
Problem
The order-bike handler only read the application id and
OrderBikeServicetook the bike from the database. ThebikeIdvariable set on completingClarify alternative with customerwas never read, andclarify-alternative.formhad nobikeIdfield. Completing the task in the Tasklist withalternativeFound = truere-ordered the same out-of-stock bike and looped back into the clarification.Change
The
bikeIdprocess variable is now the single source for the bike to order.bikeIdfrom the process and passes it toOrderBikeUseCase.orderBike(id, bikeId).OrderBikeServiceputs it on the application and stores it, also when the alternative is unavailable too.SelectAlternativeServiceno longer writes the bike itself. It still registers the bike model in the portfolio and completes the task.POST …/clarify-alternativewithalternativeFound = trueand nobikeIdis refused with a 400.clarify-alternative.formgets a requiredbikeIdtext field, shown when an alternative was found.bikeIdis declared on the user task and the order task for the generated process API. Engine behaviour is unchanged by that.README.mdupdated; new scenario10-alternative-via-tasklistcompletes the task through the engine REST API with the variables the form submits.Verification
The full build is green locally, with no drift in
openapi/openapi.jsonor the generated process API. The Bruno scenarios were not run locally; they run in this PR's pipeline.