-
Notifications
You must be signed in to change notification settings - Fork 563
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Introduce broker client to service layer #19573
base: main
Are you sure you want to change the base?
Conversation
9fa6670
to
369526f
Compare
8aae768
to
c901195
Compare
@romansmirnov, can you look specifically at the authentication and how I used this here, please? I'm uncertain I used this as intended by the services infrastructure. Is this something that can change with every service call? |
Adds the broker client to the service layer in the existing services.
Adds broker rejection and error capabilities to the CamundaServiceException. This allows wrapping broker errors and rejections into a common service exception for consumers.
Creates UserTaskServices that handle task completion, assignment, and update. The services use the broker client to communicate with the broker. Authentication is added to the broker requests transparently. Callers need to invoke "withAuthentication" before calling a service method to enable passing on authentication data.
Creates the required beans to provide user task services for Spring applications. Adds the broker client to the services layer for Spring applications.
Creates a StubbedBrokerClient and StubbedTopologyManager for service layer tests. The broker client is required not for services and the stub class helps configuring it easily for test cases where needed.
c901195
to
947c494
Compare
Replaces explicit broker client handling in the user task REST controller by using the provided user task service and its domain-specific methods. Authentication data, e.g. the token, is attached to the broker request by the service. The service method invocation hands over the authentication data known to the REST controller. The REST controller and mapper use specific container records for validated and transformed request data instead of broker command request classes.
The job REST controller reuses generalized infrastructure provided by the RestErrorMapper to avoid code duplication.
Modifies the user task REST controller tests to adhere to the service layer usage instead of the broker client. Simplifies the mocking and verification based on the service API. Rejection and error handling is simulated by the service returning failed futures containing CamundaServiceExceptions with rejections, errors, and exceptions.
Creates a job services class that supports job activation. The job activation method does not directly return jobs but requires a response observer that can handle activated jobs. The caller provides the observer to handle the jobs accordingly.
The camunda services configuration for Spring contains a bean for job services based on the REST data classes. The job services are typed to a specific data type, handled by the job activation handler and consumed by the response observer that is passed on to the job services' "activateJobs" method.
Replaces the ActivateJobsHandler in the job REST controller with the job services. This helps encapsulate logic and dependencies in the services rather than leaking them into the controller.
Introduces the job services to the job REST tests. Maps the request object from the REST mapper to the broker request data type. Increases the max wait timeout for probing to prevent flakiness as the probing can take a bit.
947c494
to
732af64
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@tmetzke, I like the changes very much! LGTM! 🚀 (Went through the code, tested it locally, works for me)
Description
Related issues
closes #19524