Spring Boot and jobExecutor override

[tomekzaremba]

Hi,
maybe a bit lame, but I can't find the way to inject custom job executor for Activiti process engine via Java configuration. I see how to obtain this via XML config, but this is not solution for me.

Looking for any hint - thanks a lot.

[tomekzaremba]

And maybe some more info: we are trying to develop throttling solution to configure serviceTasks count, which can be executed per hour. We thought that overriding implementation of job executor (for checking our throttling conditions) can be a good solution. I didn't find any built-in solution, so maybe any experienced Activiti user can judge our idea.

[jbarrez]

You can have a bean that gets the ProcesEngineConfiguration injected and change the job executor after it's instantiated.

I added this class to master https://github.com/Activiti/Activiti/blob/master/modules/activiti-spring-boot/spring-boot-starters/a... to make configuring easier

Regarding your question on service task counts: I'd use a BpmnParseHandler, to wrap the logic in a custom class that keeps track of the counts.

[tomekzaremba]

Thanks for code snippet.

One more question - you mentioned BpmnParseHandler class. Is there a way to postpone serviceTask execution from this class (serviceTask has to wait for available "slot" to call e.g some web service.)? We are looking for solution close to simple timer, which postpone execution to the moment when there is available slot for action (there is some configured slot pool, where we want to keep how many actions system may trigger in the unit of time).

[martin_grofcik]

Hi Tomek,

I would make task asynchronous with a special type and create a special job handler for handling this kind of jobs. Job handler will execute task only in the defined slot.

Regards
Martin

[tomekzaremba]

Task can't be asynchronous - if there are no slots for execution further tasks should not be executed. Order of task execution is also important.

[jbarrez]

If a job handler can't be used, you'll need to put it your service task logic itself. However … that will not be easy: you can't stall the current transaction for a long time and if you put it back in the db … it will not get revived automatically.
This requirement does feel like it should be an async job … especially the retry you need and the async pickup in case a slots are full…