spring-zeebe
spring-zeebe copied to clipboard
camunda-community-hub
Adding a provision to have custom result handler (enricher/transformer) in JobHandlerInvokingSpringBeans
Is your feature request related to a problem? Please describe. We want to do additional processing on the incoming and outgoing variables of the worker before they can go into/come from SaaS.
Describe the solution you'd like We have looked into the code and we see that incoming variable handling can be managed by overriding ParameterResolverStrategy. The same provision is not available for return object. We would like to have a Custom result enricher which can transform the variables before being sent to the Camunda SaaS. So a default enricher which returns the same value can be added to the class JobHandlerInvokingSpringBeans to handle it standard and then it can allow us to override the default enricher with Custom enricher to do additional processing.
Describe alternatives you've considered We have considered to have this processing in the workers but that makes the code looks unnecessarily cluttered and we want to do this processing in the background. We have also considered using aspects but that doesnt look natural and we want the provision embedded in the framework itself without impacting existing functionality.
Additional context Add any other context or screenshots about the feature request here.
Here is the Pull Request for the suggested solution. https://github.com/camunda-community-hub/spring-zeebe/pull/797
New pull request for the suggested solution which was used to close the feature. https://github.com/camunda-community-hub/spring-zeebe/pull/833
@hem-verma , @jonathanlukas "We want to do additional processing on the incoming and outgoing variables of the worker before they can go into/come from SaaS." -- could you please give an example of what this is needed for? Thank you!
@hem-verma , @jonathanlukas "We want to do additional processing on the incoming and outgoing variables of the worker before they can go into/come from SaaS." -- could you please give an example of what this is needed for? Thank you!
One example is to manage the personal data. If someone wants to keep the personal data of the customer on their own environment only. they can use the pre and post processing logic to convert personal data into reference keys and vice versa before communicating with SaaS.
The conversion logic does not have to be written inside worker class but in the processor class in an abstract way.
Hi @hem-verma, thank you for the quick reply. While what you describe is technically possible, the example does not really convince me because the desire to keep the personal data is dictated by the business requirements and hence should be implemented in the business layer IMO. Putting it deep into the technical layer obscures the implementation IMO.
Do you really use the feature?
We are going to use it soon. What do you mean by business layer here?
Also the feature is optional. If you dont override the classes, you dont use it.
I mean the code that reads the data and prepares it as variables to pass to the engine. This is something that should be handled by the "main application code" and not burried in to the framework IMO.
Of course I understand that id does not do anything by default. But still the feature exists and makes understanding the framework more difficult. It's placed structurally not in a good place in my view (if that's the purpose), that's why I asked about its purpose.
Do you plan to register a specially crafted object handler per JobWorker? (Otherwise I don't see how the handler can filter a business object -- the handler has to know the object type.) If so then why don't you just place the handler code into the worker (or one of the classes called from there)?
This is probably not the best place to have such discussions, but I don't know a better one.
Thank you again for your insights!
For us, Business Layer >> Camunda >> Workers >> Backend system. Conversion will happen before communicating with Camunda.
We are planning to write one shared incoming object handler (Parameter Resolver. already existing) for all the workers. It knows the object type from the worker method signature. Second thing is to write one shared outgoing object handler (result processor. added as part of this request) and it knows the object type from Class type of map entry.
Why we dont want to put the handler code in worker is to keep the worker minimalistic and not pollute it with data conversion logic. Also this way, not all developers has to do the same for each worker. It works generically for them.
Hope that makes sense.
@jonathanlukas Nothing for now. Just curious when 8.6 version of the client will be available with the change? :)
There will be no more release of this client. Please read the deprecation notice.
All features are ported over to the sdk linked
My bad. I meant the official SDK. Like you mentioned this feature is also added to the official SDK. when the 8.6 version is coming out for that? I remember hearing mid Oct.
Hi @jonathanlukas, I just pulled the dependency
<dependency>
<groupId>io.camunda</groupId>
<artifactId>zeebe-client-java</artifactId>
<version>8.6.0</version>
</dependency>
But I am not able to find the relevant implementation (JobHandlerInvokingSpringBeans.java or ResultProcessor.java). Could you please help me navigate?