I have started working on an idea introducing Spring Batch specific Actuator Endpoints but before proceeding I'd like your opinion.
The goal is to expose some basic metadata information that can be leveraged i.e. on E2E testing or third-party integration tools like Spring Boot Admin.
I'm guessing Spring Boot is the right place for this (spring-boot-actuator and spring-boot-actuator-autoconfigure Maven submodules) and not Spring Batch directly. The BatchEndpointAutoConfiguration will be based on registered JobExplorer (ConditionalOnBean) and if found then it will expose some of its methods.
For Examples:
/actuator/batch/{jobExecutionId} -> JobExecution => underneath will be calling and transforming on JobExecution getJobExecution(Long executionId);
/actuator/batch/{jobInstanceId} -> JobInstance => underneath will be calling and transforming on JobInstance getJobInstance(Long instanceId);
This is not meant to be a full REST representation but strictly limited to some of the methods of JobExplorer. The same limited caveat goes for the returned JSON representations in that they will not be exhaustive.
What do you think?
Also I would appreciate if @benas could provide feedback from the Spring Batch side of things.
many thanks
Comment From: fmbenhassine
Adding such actuator endpoints means that batch jobs should be packaged and executed in a single webapp JVM running 24/7 exposing this REST API (unless we want to expose a REST API just for the duration a batch job running in its own JVM.. which does not make sense to me).
This monolithic packaging model suffers from many issues (unflexible deployments, noisy neighbors due to shared memory, etc) which were the main reasons for deprecating Spring Batch Admin in favor of SCDF where the recommendation is to package each job separately as single non-web app (for all the good reasons of making one thing do one thing and do it well).
Moreover, SCDF already provides a comprehensive REST API for batch jobs, so adding this in boot may lead to duplicate efforts and possible source of confusions.
I will leave the decision to the boot team, but I would not add a feature that implicitly requires a non-recommended packaging/execution model and which may interfere with a similar feature provided by a different product from the portfolio.
Comment From: snicoll
Thank you @benas.
@dimitrisli we are not going to pursue this based on the context @benas shared. Thanks for the suggestion in any case.
Comment From: dimitrisli
No problem, thanks @benas and @snicoll for the feedback. I still believe there would have been benefit in this especially for monolithic Spring Batch applications that are not able to migrate to the SCDF model but I also understand the new direction towards lighter, easier deployable, non-web app job artefacts where this REST API approach is already offered.